Virtualization in the Nexus 7000 Platform
Posted by
Eric Stuhl on Fri, Apr 06, 2012 @ 10:13 AM
The concept of network based virtualization has typically been focused around logical overlays placed on a consistent physical architecture. VLANs, GRE, MPLS, and VRF allow network engineers the ability to create constructs within the network to virtually segment resources. While this is a powerful tool, the Nexus 7000 takes the capacity of the network to virtualize itself to a much higher degree.
Virtual Device Contexts, or VDCs, allows the Nexus to create multiple virtual copies of the switch on the same physical hardware. Each VDC can have its own set of VLANs, VRFs, and physical ports associated with it. When logging into a VDC, it presents itself as a unique switch and the network operator is unaware of any other VDCs that may be present on the Nexus itself. Physical ports that are associated to a given VDC do not appear on any other VDC. This creates a complete segmentation of each virtual switch on the management and data plane level.
In a typical Nexus 7000 switch, the control plane operates a single VDC. We recommend that in any Nexus deployment one would leave the default VDC for administrative purposes only and create subsequent VDCs for specific logical roles within the design. In this diagram, taken from the Cisco documentation, one can see a visual depiction of the control plane of a Nexus 7000:

Contrast that with this depiction of a Nexus operating in multiple VDC mode:

As is readily apparent, each VDC maintains completely separate control planes for all network functions. This allows for full segmentation of the device.
To create a more concrete example, we’ll create a phantom network. The customer in question has two main computer rooms, one in the north part of their campus, one in the south. Both north and south computer rooms house data center resources. Both rooms also hold switches that serve as fiber aggregators for other building switches. The following diagram shows a possible use of VDC within that customer environment:

Here, the Nexus switch will have 3 distinct VDCs, one for the Core, one for the Campus distribution and one for the Data Center distribution. In this example, the single Nexus device has replaced 3 separate devices in the network design. The logical functions of each device will remain separate and each will present itself as a unique switch.
Looking at a more expanded design for the same example customer network:
Here it is possible to collapse this entire design into four physical Nexus devices:

This creates for some slightly non-intuitive scenarios where a single physical box is redundant for a number of logical devices. In the case of the design suggested above,
Physical Device
|
VDC
|
Redundant Device
|
Redundant VDC
|
Nexus A
|
1
|
Nexus D
|
1
|
Nexus A
|
2
|
Nexus B
|
2
|
Nexus A
|
3
|
Nexus B
|
3
|
Nexus B
|
1
|
Nexus C
|
1
|
Nexus C
|
2
|
Nexus D
|
2
|
Nexus C
|
3
|
Nexus D
|
3
|
This system is still tolerant to failure, as multiple physical failures are necessary to impact service, but certainly steers away from more traditional redundancy models.
As you can see, virtualization within the Nexus platform can be an incredibly powerful tool, when used creatively.
To read more about VDCs, check out the Cisco white paper here