Virtual Device Contexts (VDC)

What is VDC and how it works

VMware aims at server & application virtualization, while VDC is a virtualization technology for Networking devices and it enables several Virtual Multilayer Switches Instances (also named VDC instance or logical device) in a single physical Cisco Nexus device. Each Virtual Multilayer Switch Instance has its own independent and isolated control plane (a set of processes running in their protected memory space) which are, in particular, Layer 2 & Layer 3 protocols and services. Likewise, data plane can also be virtualized by allocating specific physical ports on line cards to a certain VDC instance. NX-OS is based on Cisco MDS 9000 SAN-OS platform, it introduces VDCs to enable device level virtualization. At the heart of NX-OS is the kernel and infrastructure layer. At any one point time, only a single instance of kernel will exist and provide an interface between higher layer processes and hardware resource of physical switches. Besides, only one single instance of kernel simplifies hardware resource management. VRF aims at network virtualization on Forwarding Table level, while VDC improves that to Process level, and finally, it will reach Haredware (CPU & Memory) leve.

VDC Architecture

In its default state, the control plane of Nexus device runs a single device context (called VDC #1) which is always active, enabled and can never be deleted. VDC initial setup tasks are fulfilled by management components as below:

  • VDC manager: responsible for the creation and deletion of VDCs.
  • System Manager: responsible for launching services required for VDC startup as well as launching relevant processes (such as STP, OSPF etc) when specific services are configured for the VDC instance.
  • Resource Manager: responsible for allocation and distribution of resources between VDCs. Here resources refer to VLANs, VRFs, PortChannels, physical ports etc. Below table entails resources that can or can not be allocated to VDC.
    VDC Resource Allocation
    Physical Resource: the only physical resource what can be allocated to VDC are Ethernet Interfaces. Each physical Ethernet interface can belong to only one VDC (or one Ethernet VDC & one Storage VDC concurrently) at any given time. When you allocate an interface to a VDC, all configuration for that interface is erased.
    Logical Resources: VLANs, VRFs, SPAN monitoring sessions, port channels etc.

How VDC affects behavior of control plane

Layer 2 & 3 Forwarding

  • Each line card uses a local hardware-forwarding engine to perform Layer 2 and Layer 3 forwarding
    in hardware.
  • When the default VDC is the only active VDC, learnt routes and ACLs are loaded into each line card TCAM tables so that each line card has the necessary information local to it to make an
    informed forwarding decision. In other words, CAM/TCAM/FIB entries are duplicated to every line cards and this is why VDC technology can optimize the use of CAM/TCAM/FIB tables.
  • In scenario of multiple VDCs on a single device, CAM/TCAM/FIB entries learned from physical interfaces allocated to VDC #5 on one line card will only be copied to those line cards who have physical ports allocated to the same VDC #5.

Control Plane Policing (CoPP)

Control plane policing provides a protection mechanism for the control plane by limiting the number of packets sent to the control plane for processing, and it is always system-wide significant.

Control plane policing is enabled from the default VDC and runs only in the default VDC. Its application, however, is system wide, and any packet from any VDC directed to the control plane is subject to the control plane policer in place.

Quality of Service (QoS)

Quality of Service has configuration implications that have either global or per-VDC significance.

  • Any QoS configurations specific to a physical port (such as WRED-congest management for port buffers) also have significance only to the VDC that the port belongs to.
  • Policers, which provides rate limiting action on target traffic, has per-VDC significance.
  • Classification ACLs used to identify specific type of traffic to which QoS policy will apply are also per-VDC significant. Moreover, these QoS Classification ACLs will be installed into the ACL TCAM only on those line cards that have ports in that VDC.
  • Many of the QoS maps that are used to provide services such as CoS- and DCSP-to-queue
    mapping and markdown maps for exceed and violate traffic are examples of QoS configuration
    elements that have global significance, they will affect packets entering all VDCs.

Embedded Event Manager (EEM)

An EEM policy (applet) is configured within the context of a VDC. While most events are seen by each VDC, there are some events that can be seen only from by the default VDC.

High Availability of VDC when control plane fails

The Cisco NX-OS Software platform incorporates different high-availability service levels, from service restart to stateful supervisor switchover to ISSU without affecting data traffic.

Service Restart: When control plane failure occurs for a VDC, 3 actions can be configured as reaction: restart, bringdown, and reset. The default VDC always has a high-availability option of reset assigned to it. Subsequent VDCs created will have a default value of bringdown assigned to them. This value can be changed under configuration control.

  • The restart option will delete the VDC and then re-create it with the running configuration. This configured action will occur regardless of whether there are dual supervisors or a single supervisor present in the chassis.
  • The bringdown option will simply delete the VDC.
  • The reset option will issue a reset for the active supervisor when there is only a single supervisor in the chassis. If dual supervisors are present, the reset option will force a supervisor switchover.

Stateful Supervisor Switchover: is supported with dual supervisors in the chassis. During the course of normal operation, the primary supervisor will constantly exchange and synchronize its state with the redundant supervisor. There is a software process (watchdog) that is used to monitor the responsiveness of the active (primary) supervisor. Should the primary supervisor fail, a fast switchover is enacted by the system. Failover occurs at both the control plane and data plane layers.

  • At supervisor switchover, the data plane continues to use the Layer 2– and Layer 3–derived
    forwarding entries simply by maintaining the state written into the hardware.
  • For layer 3 control plane, the graceful restart process that is part of nonstop forwarding (NSF) is used to provide failover.
  • For Layer 2, the control plane is maintained by locally stateful PSS mechanisms.

In Service Software Upgrades (ISSU): allows the administrator to install and activate a new version of software in a chassis that is running two supervisors. The software upgrade can be applied to the backup supervisor, and then a switchover to that upgraded supervisor is invoked. The other supervisor is then upgraded with the same new set of software; all the while the system maintains data flow without interruption. At this juncture, ISSU cannot be applied on a per-VDC basis. The installed software on the chassis is applicable for all active VDCs.

Guidelines for Resource Allocation to VDC Instance

  1. Physical switch ports are resources that cannot be shared between VDCs. By default, all ports on the switch are assigned to the default VDC (VDC #1). When a new VDC is created, the super user is required to assign a set of physical ports from the default VDC to the newly created VDC, providing the new VDC with a means to communicate with other devices on the network. Once a physical port is assigned to a VDC, it is bound exclusively to that VDC, and no other VDC has access to that port. Inter-VDC communication is not facilitated from within the switch. A discrete external connection must be made between ports of different VDCs to allow communication between them.
  2. Different port types can be assigned to a VDC. These include Layer 2 ports, Layer 3 ports, Layer 2
    trunk ports, and PortChannel (Cisco EtherChannel) ports.
  3. Logical interfaces such as SVIs that are associated with the same physical interface cannot be allocated to different VDCs in the current implementation. Thus, it is not possible to virtualize a physical interface and associate the resulting logical interfaces to different VDCs. However, it is possible to virtualize a physical interface and associate the resulting logical interfaces with different VRFs or VLANs. Thus, VDCs can be assigned physical interfaces, while VLANs and VRFs can be assigned logical and physical interfaces.

VDC Plan & Design

Cisco NX-OS releases prior to 6.1 can support up to four VDCs, including the default VDC, which means that you can create up to three non-default VDCs.

The storage VDC is one of the nondefault VDCs and it does need a license. However, a storage VDC does not need a VDC license as it relies on the FCoE license installed to enable the FCoE function on the modules. Beginning with Cisco NX-OS Release 5.2(1) for the Nexus 7000 Series devices, you can

run FCoE on the F1, F2 and F2E Series modules. You can create separate storage VDCs to run FCoE.
You can have only one storage VDC on the device, and you cannot configure the default VDC as a storage VDC. After you create the storage VDC, you assign specified FCoE VLANs. Finally, you configure interfaces on the Cisco Nexus 7000 Series device as either dedicated FCoE interfaces or as shared interfaces, which can carry both Ethernet and FCoE traffic.

You can have a maximum of two SPAN monitoring sessions on your physical device.

VDC Configuration Steps

Create VDC and verify

switch# conf t
switch(config)# vdc production       // production is the name of VDC
switch(config-vdc)# show vdc
vdc_id  vdc_name               state                    mac
——  ——–               —–                    —-
1    switch                    active               00:18:ba:d8:4c:3d
2    production                active               00:18:ba:d8:4c:3e

switch(config-vdc)# show vdc detail
vdc id: 1
vdc name: switch
vdc state: active
vdc mac address: 00:18:ba:d8:4c:3d
vdc ha policy: RESET

vdc id: 2
vdc name: production
vdc state: active
vdc mac address: 00:18:ba:d8:4c:3e
vdc ha policy: BRINGDOWN

a

switch# show run | begin vdc
<snip>
vdc production id 2
template default
hap bringdown
limit-resource vlan minimum 16 maximum 4094
limit-resource span-ssn minimum 0 maximum 2
limit-resource vrf minimum 16 maximum 8192
limit-resource port-channel minimum 0 maximum 256
limit-resource glbp_group minimum 0 maximum 4096
<snip>

customize resource limit or apply resource template

switch(config)# vdc production
switch(config-vdc)# limit-resource vlan minimum 32 maximum 4094

 

switch(config)# vdc resource template n7000switch
switch(config-vdc-template)# limit-resource vlan minimum 32 maximum 256
switch(config-vdc-template)# limit-resource vrf minimum 32 maximum 64
switch(config-vdc-template)# exit

switch(config)# vdc 2 template n7000switch

 

switch(config-vdc)# show vdc resource template
template::n7000switch
——–
Resource                Min        Max
———-              —–      —–
vrf                     32         64
vlan                    32         256

template ::default
——–
Resource                Min        Max
———-              —–      —–
glbp_group                0       4096
port-channel              0        256
span-ssn                  0          2
vlan                     16       4094
vrf                      16       8192
switch(config-vdc)#

Assign Physical Ports to VDC

switch(config)# vdc production
switch(config-vdc)# allocate interface ethernet 3/48

switch(config)# show vdc membership
vdc_id: 1 vdc_name: switch interfaces:
Ethernet3/1           Ethernet3/2           Ethernet3/3
Ethernet3/4           Ethernet3/5           Ethernet3/6

……

vdc_id: 2 vdc_name: production interfaces:
Ethernet3/48

Switch to VDC to perform VDC specific configuration

switch# switchto vdc production

switch(vdc)# show vdc current-vdc
Current vdc is 2
switch(vdc)#

What is VRF and why we need it.

Technical Overview of Virtual Device Contexts.