BladeSystem - General
1748185 Members
4072 Online
108759 Solutions
New Discussion юеВ

Re: Private Network Option in VirtualConnect

 
SOLVED
Go to solution
VijaySharma
Occasional Contributor

Private Network Option in VirtualConnect

I have configured three vNets - DMZ, APP and DB in VirtualConnect (v2.01) on c7000 and connected to three corresponding VLANS on CISCO network. For a certain application, I have to assign same vNet to multiple blades. However these blades cannot communicate to each other (even a simple PING), if I 'check' Private Network option in vNet. Our Network Administrator has checked and verified that there are no rules holding two blades on the same VLAN to communicate with each other. We have 4 different c7000 enclosures (VC versions v1.31 & v2.01) using same CISCO VLANs. Blades on same VLAN in different enclosures can communicate with each other, through CISCO network without any problem, however servers on the same vNet (within same enclosure), cannot communicate with each other if Private Network option is checked. All three vNets behave identical.
Is this a behaviour by design or am I missing something?
5 REPLIES 5
HEM_2
Honored Contributor

Re: Private Network Option in VirtualConnect

That is exactly what the private network option is intended to do. It prevents communication between blades in the same VC domain that are members of that vNet but allows communication through the uplinks.

Similar to Private VLANs in Cisco.

Private Network option is good for server hosting for example.
VijaySharma
Occasional Contributor

Re: Private Network Option in VirtualConnect

Thanks HEM.
It is still not clear. What stops network to send the network traffic back, if destination IP is on the same vNet (in the same enclosure), when it can send the traffic to other blades in other enclosures?
HEM_2
Honored Contributor
Solution

Re: Private Network Option in VirtualConnect

"What stops network to send the network traffic back, if destination IP is on the same vNet (in the same enclosure), when it can send the traffic to other blades in other enclosures?"

What stops it from being able to communicate out the uplink and then back in is simple bridging/switching.

Quick example, with 2 servers A and B connected to vNET1 with the private network option checked. These 2 servers can't communicate with each other inside the enclosure (private network is working as designed). But these 2 servers are on the same subnet, why can't they communicate? Well, if server A ARPs for the MAC address of Server B, that ARP will be flooded and go out the uplink for vnet1. In switching, any traffic that goes out 1 port will not be received back on that port (that's a loop). So server B will never see the ARP request from server A. Server A will never learn the MAC address for server B. Even if server A knew the MAC address for server B it would still not be able to communicate because as the traffic exited the enclosure through vnet1's uplink, it would not come back in to that uplink because of the same bridging/switching principle as above.

I hope this helps... For a more eloquent description of Private VLANs, I'm sure Cisco has some good documentation...
VijaySharma
Occasional Contributor

Re: Private Network Option in VirtualConnect

Thanks

That is a good explanation.
VijaySharma
Occasional Contributor

Re: Private Network Option in VirtualConnect

Explanation fits the behaviour observed including virtual machines on some of these blades running ESX 3.5.