With the introduction of NX-OS 6.1(1) and the Supervisor 2 and Supervisor 2E modules for the Nexus 7000, a new capability called Admin Virtual Device Context (VDC) was created. Admin VDC is a feature that was created based on customer feedback, addressing the desire for additional virtualization control within the platform.
First, let’s review what VDCs on the Nexus 7000 are. VDCs are the ability to virtualize the control and data plane functions of the switch into multiple virtual devices. The number of VDCs is a direct function of the Supervisor model used with the Supervisor 1 and Supervisor 2 providing support for 4 VDCs and the Supervisor 2E providing support for 8 VDCs. The reason Supervisor 2E can support more VDCs than the other supervisors is the additional CPU and memory resources available for control plane functions. The Supervisor 2E has two quad core CPUs with 32GB of RAM while the Supervisor 2 has a single quad core CPU with 12GB of RAM. VDCs can be used in many different aspects of a design, including vertical consolidation of core and aggregation layers, for example, onto a common hardware platform while still maintaining the hierarchy. Another use is for security segmentation with the separation of DMZ networks from internal networks but with a reduction in equipment required for the segmentation. Figure 1 illustrates this concept.
Figure 1
Prior to NX-OS 6.1(1) there were two types of VDCs: an Ethernet VDC and a Storage VDC. The Ethernet VDC is capable of supporting traditional L2/L3 protocols like Spanning Tree (STP), Open Shortest Path First (OSPF), FabricPath, etc. while the Storage VDC provides support for Fibre Channel over Ethernet (FCoE) specific protocols like Fibre Channel Zoning, and FCoE Initialization Protocol (FIP) etc. In NX-OS 6.1(1) Admin, VDC has been added as a new type of VDC and can be seen as such in the CLI output below:
With Admin VDC, network administrators can perform common, system-wide tasks in a context that is not handling data plane traffic. Admin VDC also allows customers another option to secure their Nexus 7000, as they can more easily restrict access to the Admin VDC than might be possible with a traditional Ethernet or Storage VDC. The tasks that can be performed only in Admin VDC are below:
- In Service Software Upgrade/Downgrade (ISSU/ISSD)
- Erasable Programmable Logic Devices (EPLD) upgrades
- Control Plane Policing (CoPP) configuration
- Licensing operations
- VDC Configuration including creation, suspension, deletion and resource allocation
- System-wide QoS policy and port channel load balancing configuration
- Generic Online Diagnostics (GOLD) configuration
As you can see, these are tasks that are more system administration functions than typical network administration items. Moving these tasks to the Admin VDC also helps some customers gain an additional VDC. One of the recommended practices many customers who were deploying VDCs followed was not using the default VDC as a data VDC, but rather reserving it for these administrative functions. This recommendation was made to provide additional security and to isolate the system-wide functions. With Admin VDC, the VDC that was originally reserved can be used for other purposes. When using Admin VDC you’ll see a change to the way Cisco describes the total number of VDC. Traditionally with Supervisor 1 modules, the maximum number of VDCs was 4. If a customer reserved the default VDC for administrative purposes, they had 3 VDCs left to use. With Admin VDC on Supervisor 2, this is illustrated as 4+1 and on Supervisor 2E as 8+1 with the “+1” being the Admin VDC.
As mentioned before, the Admin VDC is a specialized VDC for administrative functions but also has a restriction that warrants mentioning. It is not possible to have an Ethernet interface allocated to the Admin VDC and it is not possible to have any L2 or L3 protocols in the Admin VDC. Admin VDC can be accessed only via the Console or Management ports on the Supervisor modules. No “inband” access via an interface, including loopbacks, can be configured. If you refer back to the CLI sample shown earlier, you’ll note that the linecards supported are “None”. This lack of support for linecards means that there are no forwarding resources allocated to Admin VDC, as the Nexus 7000 is a fully distributed forwarding switch. If you do require “inband” management of the switch, the management interface can always be connected into an Ethernet linecard on the switch and accessed that way, though this obviously circumvents the out-of-band management model.
So now that we’ve described Admin VDC, let’s look at how we get Admin VDC configured. The first, and easiest, option to get Admin VDC is when the switch boots without any configuration. As shown below, using Admin VDC will be prompted.
Enter the password for "admin":
Confirm the password for "admin":
Do you want to enable admin vdc (yes/no) [n]:
If “yes” is selected, the Admin VDC will be created and the switch continues to boot. After that you’ll be able to create additional VDCs, allocate resources to them, and configure them as needed. It’s also worth noting that using Admin VDC does not count against the number of licensed VDCs on the switch. So it is possible to have a system running Admin VDC and one Ethernet VDC (1+1) without needing the ADV or VDC license packages. Creation of a 3rd VDC will require a license or use of grace license.
If you select “no” during bootup, you still can use Admin VDC with two methods provided to implement it. The first is to simply convert the default VDC to Admin VDC using the commands shown below. This also assumes that you do not have any Ethernet interfaces being used in the default VDC and if you do they will be removed and allocated to VDC 0 for Unallocated Interfaces.
Prior to Conversion
Conversion
N7K-1# config
Enter configuration commands, one per line. End with CNTL/Z.
N7K-1(config)# system admin-vdc <--This command is what does the conversion from default VDC to Admin VDC
N7K-1(config)#
Post Conversion
The second method addresses what do if you have a configuration with Ethernet interfaces being used? You can still migrate to Admin VDC by using the same “system admin-vdc” command, but you must add two parameters to indicate a migration and provide a new name for the VDC where the configurations will be migrated into. It is important to note that migration is disruptive to traffic on the interfaces being migrated, so plan accordingly!
Prior to Conversion
Conversion
N7K1# config
Enter configuration commands, one per line. End with CNTL/Z.
N7K1(config)# system admin-vdc migrate Core1
2012 Apr 23 14:28:53 N7K1 %$ VDC-1 %$ %VDC_MGR-2-VDC_ONLINE: vdc 3 has come online
Post Conversion
You can see we had an OSPF neighbor on interface Ethernet 4/3 in the default VDC and that the OSPF configuration was migrated into the new VDC, Core1. Also note the uptime on the neighbor indicates it was disrupted during the migration as expected.
As you can see, Admin VDC provides the functionality many customers requested to isolate system-wide functions from data VDCs, and it also allows them to follow a recommended practice without sacrificing a VDC at the same time. Admin VDC can be implemented from the first time the Nexus 7000 is booted or migrated to for devices already in production. Admin VDC is a great feature and I hope you consider it for your Nexus 7000 implementation.
Ron Fuller, CCIE No. 5851 (Routing and Switching/Storage Networking), is a technical marketing engineer (TME) in the Nexus 7000 team for Cisco. He has 21 years of experience in the industry and has held certifications from Novell, HP, Microsoft, ISC2, SNIA, and Cisco. His focus is working with customers world-wide to address their challenges with comprehensive end-to-end data center architectures and how they can best utilize Cisco technology to their advantage. He has had the opportunity to speak at Cisco Live on VDCs, NX-OS Multicast and general design. He lives in Ohio with his wife and four wonderful children and enjoys travel and auto racing. He can be found on Twitter @ccie5851
| By Ron Fuller, David Jansen, Matthew McPherson. Published by Cisco Press. Series: Networking Technology. Published: Sep 20, 2012 ISBN-10: 0-13-288362-7 ISBN-13: 978-0-13-288362-7 |
Published by Cisco Press.
This article was featured in the December issue of the Cisco TS Newsletter. Are you subscribed?
