Cisco Nexus 7000 VDCs
VDCs partition a single physical device into multiple logical devices that provide fault isolation, management isolation, address allocation isolation, service differentiation domains, and adaptive resource management. In simple terms, VDCs enable the virtualization of the control plane, data plane, and management plane of a switch, along with its hardware resource virtualization. You can manage a VDC instance within a physical device independently. Each VDC appears as a unique device to the connected users. A VDC runs as a separate logical entity within the physical device, maintains its own unique set of running software processes, has its own configuration, and can be managed by a separate administrator.
VDCs virtualize the control plane, which includes all those software functions processed by the CPU on the active supervisor module. A VDC contains its own unique and independent set of VLANs and VRFs. Each VDC can have assigned to it physical ports, thus allowing for the hardware data plane to be virtualized as well. Within each VDC, a separate management domain can manage the VDC itself, thus allowing the management plane itself to also be virtualized.
In its default state, the switch control plane runs a single device context (called VDC 1) within which it will run approximately 80 processes. Some of these processes can have other threads spawned, resulting in as many as 250 processes actively running on the system at a time depending on the services configured. This single device context also has a number of Layer 2 and 3 services running on top of the infrastructure and kernel components of the OS, as shown in Figure 5-3.
Figure 5-3 Default Operating Mode with Single Default VDC
This collection of processes constitutes what is seen as the control plane for a single physical device (that being with no other virtual device contexts enabled). VDC 1 is always active, always enabled, and can never be deleted. When you create a subsequent (additional) VDC, the Cisco NX-OS software takes several of the control plane processes and replicates it for each device context that exists in the switch. When this occurs, duplication of VRF names and VLAN IDs is possible. For example, you could have a VRF called “sales” in one device context and the same “sales” name applied to a VRF in another virtual device context. Hence, each VDC administrator essentially interfaces with its own set of processes and its own set of VRFs and VLANs, which in turn, represents its own logical (or virtual) switch context. This provides a clear delineation of management contexts and forms the basis for configuration separation and independence between VDCs.
Each VDC has a minimum of two VRF instances- a default VRF instance and a management VRF instance. All Layer 3 interfaces and routing protocols exist in the default VRF instance until they are assigned to another VRF instance. The mgmt0 interface exists in the management VRF instance and is accessible from any VDC. Up to 4000 VRF instances per system are permitted. With each new VDC configured, the number of configurable VRF instances per system is reduced by two because each VDC has a default VRF instance and a management VRF instance that are not removable.
Figure 5-4 represents VDC service and protocol separation.
Figure 5-4 VDC Service and Protocol Separation