Cisco NX-OS and VDC

Cisco NX-OS provides fault isolation, management isolation, address allocation isolation, service differentiation domains, and adaptive resource management through VDCs. An instance of a VDC can be managed independently within a physical device, and users connected to it perceive it as a unique device. VDCs run as logical entities within physical devices, maintain their configurations, run their software processes, and are managed by a different administrator.

Kernel and Infrastructure Layer

The Cisco NX-OS software is built on a kernel and infrastructure layer. On a physical device, the kernel supports all processes and virtual disks. These TCAMs serve as interfaces between higher-level processes and the hardware resources of the physical device. Scalability of Cisco NX-OS software can be achieved by avoiding duplication of systems management processes at this layer (see figure below).

It is also the infrastructure that enforces isolation across VDCs. When a fault occurs within a VDC, it does not impact services in other VDCs. Thus, software faults are limited, and device reliability is greatly enhanced.

Nonvirtualized services may have only one instance per VDC and the infrastructure layer. These services create VDCs, move resources between VDCs, and monitor protocol services within a VDC.

Example: Cisco Nexus Switches

Virtual Device Contexts (VDC) allow you to carve or divide out multiple virtual switches from a single physical Nexus switch. The number of VDCs that can be created depends upon the version of NX-OS, the Supervisor model, and the license installed. Inter-VDC communication is only via external interfaces; there is no internal switch. As a result, VDCs offer several benefits, such as a separate partition between different groups or organizations while using only a single switch. With device context, there are several virtual device context design options.

Example: Cisco ASA 5500 Series

Multiple approaches exist for firewall and load-balancing services in the data path. Design options exist for a Dedicated External Chassis ( Catalyst 6500 VSS ) with service modules inserted within the chassis or using dedicated External Appliances ( Cisco ASA 5500 Series Next-Generation Firewall). With both modes, run the services in either “routed” or “transparent” modes. Routed mode creates separate routing domains between the server farm subnet and the services layer. On the other hand, Transparent Mode extends the routing domain down to the server farm layer.

Before you proceed, you may find the following posts helpful:

1. Context Firewall
2. Virtual Data Center Design
3. ASA Failover
4. Network Stretch
5. OpenShift Security Best Practices

Back to Basics: Virtual Device Context (VDC)

Virtual Device Contexts (VDC) let you carve out numerous virtual switches from a single physical Nexus switch. Each VDC is logically separated from every other VDC on a switch. Thus, just like physical switches to trunk or route traffic between them, physical interfaces and cabling are required to attach two or more VDCs before this can happen. The number of VDCs that can be created depends upon the version of NX-OS, the Supervisor model, and the license installed. For example, the newer Supervisor 2E can support up to eight VDCs and one Admin VDC.

How does Virtual Device Context work?

VDC utilizes the concept of virtualization to create isolated network environments within a single physical switch. By dividing the switch into multiple logical switches, network administrators can allocate resources, such as CPU, memory, and interfaces, to each VDC independently. This enables them to manage and control multiple networks within a single device with distinct configurations.

Benefits of Virtual Device Context:

1. Enhanced Network Performance: With VDC, network administrators can allocate dedicated resources to each virtual device, ensuring optimal performance. By isolating traffic, VDC prevents any device from monopolizing network resources, improving overall network performance.

2. Increased Network Efficiency: VDC allows administrators to run multiple applications or services on separate virtual devices, eliminating potential conflicts. This segregation enhances network efficiency by minimizing downtime and enabling better resource utilization.

3. Simplified Network Management: By consolidating multiple logical devices into a single physical switch, VDC simplifies network management. Administrators can independently configure and monitor each VDC, reducing complexity and streamlining operations.

4. Cost Savings: Virtual Device Context eliminates the need to purchase and manage multiple physical switches, resulting in organization cost savings. By leveraging VDC, businesses can achieve network segmentation and isolation while optimizing resource utilization, thus reducing capital and operational expenditure.

Use Cases of Virtual Device Context:

1. Data Centers: VDC is commonly used in data centers to create virtual networks for different departments or tenants, ensuring secure and isolated environments.

2. Service Providers: VDC enables providers to offer virtualized network services to their customers, providing greater flexibility and scalability.

3. Testing and Development Environments: VDC allows organizations to create virtual network environments for testing and development purposes, enabling efficient resource allocation and isolation.

VDC Design

The virtual Device Context ( VDC ) feature on the Nexus 7000 series is used for another type of virtualization. The concept of VDC design takes a single Nexus 7000 series and divides it into independent devices. In this example, the second independent device creates an additional aggregation layer. Now, the data center has two-aggregation layers, the Primary Aggregation layer and the Sub-Aggregation layer. The services layer is sandwiched between the two-aggregation VDC blocks ( primary and sub-aggregation layer ), creating a concept known as the “Virtual Device Context Sandwich Model.”

Now, there are two options for access layer connections. Some access layer switches can attach to the new sub-aggregation VDC. Other functional blocks not requiring services can be directly connected to the primary aggregation layer ( top VDC ), bypassing the service function. The central role of the primary aggregation layer is to provide Layer 3 forwarding from the services layer to the other functional blocks of the network. Small sites could collapse the core in the primary aggregation VDC.

Device context validated design.

The design is validated with the Firewall Service Module ( FWSM ) running in transparent mode and the ACE module running in routed mode. The two-aggregation layers are direct IP routing peers and configurations with VLANs, Virtual Routing and Forwarding ( VRFs ), Virtual Device Contexts ( VDC ), and Virtual Contexts. Within each VDC, VLANs map to VRFs, and VRFs can direct independent traffic through multiple virtual contexts on the service devices. If IP multicast is not required, the sub-aggregation VDC can have static pointing to a shared Hot Standby Router Protocol ( HSRP ) address on the primary aggregation VDC. 

 Benefits:

1. Inserting separate aggregation layers using the VDC approach provides much better isolation than previous designs using VLAN and VRF on a single switch.
2. It also offers much better security. Instead of separating VLANs and VRFs on the same switch, the VDC concept creates separate virtual switches with their physical ports.
3. The sub-aggregation layer is separate from the primary aggregation layer. You need to connect them directly to route from one VDC to another. It’s as if they are separate physical devices.

Drawback:

1. The service chassis must have separate physical interfaces to each VDC layer. Additional interfaces must be provisioned for the inter-switch link between VDCs. Compared to the traditional method that is extended by adding VLANs on a trunk port.