BladeSystem Virtual Connect
Showing results for 
Search instead for 
Did you mean: 

Interconnecting Enclosures using Virtual Connect

Trusted Contributor

Interconnecting Enclosures using Virtual Connect

Lots of discussion was held recently about interconnecting different chassis using VC modules and stacking links or uplink ports. Here is the conversation started by  Patrick:



Is it possible to run a network connection to one virtual connect module and run a CX4 cable to the second enclosure virtual connect module? This is only a temporary configuration so they can build their servers while the network gets put into place.



Then Sam responded:



This would work if both enclosures are in the same VC domain, otherwise network traffic from VC #2 will not route to VC #1’s uplink.


Here’s a link describing multi-enclosure stacking rules that should help with the decision.



Next Dave chimed in:




                I have a site doing something similar. They have 2 enclosures, each with its own Domain. They have two stacking links between each enclosure for intra-enclosure/Domain communications. It appears to be working, but not yet in production.


He wants to know if there are any problems or reasons to not leave it in this config?

Basically, Is there any problems with interconnecting two or more Domains with stacking links?



To which Paul replied:



This is interesting.  At a minimum, there are limitations, and I think some definitions need to be understood.  When you plug a cable between two VC modules, in the same enclosure or not, the ports will exchange LLDP packets and know that another VC module is at the other end of the cable.  But if the two VC modules are not in the same domain, then the cable it is not a stacking link.  The ports being used for that connection in each enclosure would have to be included in the definition of a VC network or uplink set to allow the servers to send traffic thru those ports, so the cable is an uplink that just happens to end at another VC module.


Now, we do support connecting a single server to a VC uplink port.  That server can talk to servers inside the enclosure, and vice versa, but that server could not send packets out to the rest of the network on another uplink on the VC module.  And again, it is LLDP that is used to discover that there is a end node at the other end of the cable, as opposed to a transit port on a switch, or a port on a VC module ( a bunch of NICs).


So, you say your setup works, and that is supported by the fact that an upstream switch sees the VC port not as a transit port, but as “just a bunch of NICs”, multiple end nodes.  It makes sense that VC in domain 1 sees what is at the other end of the cable that leads to domain 2 as “just a bunch of NICs”, and the same rules would apply as described above with a single server plugged into a VC port – comm. thru that port to anything inside the enclosure assigned to VC net containing that port, but no comm. back out of the enclosure thru a different uplink that leads to the network. 


So, servers in each enclosure could talk intra-enclosure and inter-enclosure either by creating and assigning them a VCnetwork or uplink set that includes the port used as the inter-chassis link.  But servers in one chassis could not make use of uplinks from the other chassis to reach the rest of the network.



So, it makes sense that it works.  Now… supported?  Dunno.



That brought Vincent into the conversation:



Yes, it’s supported, officially since VC firmware 2.30, check the user guide and/or release notes.

Note that this is only to connect ONE VC domain to ONE other VC domain. If you throw a third one into the mix, not supported, it would become too complicated and it would consume too many ports as you would have to connect all enclosures in pairs in all possible permutations.



All good stuff. Add your comments or questions.