Cisco's virtual device context (VDC) feature allows a single Nexus 7000 hardware switch to be logically divided into multiple virtual switches. This allows a single physical switch to be shared by multiple tenants, with each VDC functioning independently as if it were its own physical device. The number of VDCs that can be created depends on the type of supervisor module, with newer modules supporting more VDCs. Physical interfaces are assigned exclusively to individual VDCs to isolate their traffic.

1. Cisco's virtual device context or vdc is basically a concept of dividing a single Nexus
7000 hardware box into multiple logical boxes in such a way that they look like
different physical device to a remote user/operator and each of the provisioned
logical devices is configured and managed as if it were a separate physical device.
For example, you have a data center where you have deployed Nexus 7k in
datacenter. Now, there are few other companies who don't have enough money to
expend in setting up Nexus 7000 so they come to you to host a data center for them.
You can simply virtualize your nexus 7000 into multiple virtual switches and can
assign one logical portion (that is called vdc) to one company. When they will login to
their logical switch (looks like a separate physical switch to user) they can do
whatever they want, other logical partition i.e. other vdc will remain unaffected. You
can create vlans with same name/number in all vdc's and they will not interfere with
each other. A particular vdc operator will not even come to know that same switch is
being used by multiple user virtually. Only Admin can create/delete vdc's and from
Admin vdc only, we can see other vdcs.
Similarly, vdc can be used to create different test and production traffic. In my
previous project, we created one vdc for test environment in order to test new
implementation/protocol etc and another vdc for production traffic. If our test used
to successful in our test environment, then only we used to put them into production.
How many vdc we can create?? It depends on which supervisor engine you are using.
If you are using SUP1, then you can create up to 4 vdc's. All of them can be used to
carry data traffic and you can create/delete vdcs from default vdc which can also be
used for data traffic.
If you are using SUP2, then you can create 1 admin + 4 data vdc. That means, you
cannot use admin vdc for data traffic. That will be used for only admin purpose i.e.
managing other vdc's.
If you are using SUP2E, then you can create 1+8 vdc, where 1 admin plus 8 production
vdc.
Within VDC it can contain 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.
Physical interfaces cannot be shared by multiple VDCs. This one-to-one assignment
of physical interfaces to VDCs is at the basis of complete isolation among the
configured contexts. However, there are two exceptions:

2. • The out-of-band management interface (mgmt0) can be used to manage all VDCs.
Each VDC has its own representation for mgmt0 with a unique IP address that can be
used to send syslog, SNMP and other management information.
• When storage VDC is configured, a physical interface can belong to one VDC for
Ethernet traffic and to the storage VDC for FCoE traffic. Traffic entering the shared
port is sent to the appropriate VDC according to the frame's EtherType. Specifically,
the storage VDC will get the traffic with EtherType 0x8914 for FCoE Initialization
Protocol (FIP) and 0x8906 for FCoE.
Physical interfaces can be assigned to a VDC with a high degree of freedom. However,
there are differences among different I/O modules because of the way the VDC
feature is enforced at the hardware level. The easy way to learn the specific
capabilities of the installed hardware is by entering the show interface x/y
capabilities command to see the port group associated with a particular interface.
Switch Resources that Can Be Allocated to a VDC:
Physical Interfaces, Port Channels, Bridge Domains and VLANs, HSRP and GLBP Group
IDs, and SPAN
Switch Resources that Cannot Be Allocated to a VDC:
CPU*, Memory*, TCAM Resources such as the FIB, QoS, and Security ACLs
* Future releases may allow allocation of CPU or memory to a VDC.
VDC Configuration Steps
Step1 Log in to the default VDC with a username that has the network-admin role.
Step2 Enter configuration modes and create the VDC using the default settings.
N7k# configure terminal
N7k (config)# vdc WDECAIB
Note: Creating VDC, one moment please...
Switch (config-vdc)#
Step3 Optional) Allocate interfaces to the VDC.
N7k (config-vdc) # allocate interface Ethernet 1/1-8
Similarly more interfaces can be assigned. Below is the screenshot of a vdc
configuration.
Initially, all physical interfaces belong to the default VDC (VDC 1). When you create a
new VDC, the Cisco NX-OS software creates the virtualized services for the VDC
without allocating any physical interfaces to it. After you create a new VDC, you can
allocate a set of physical interfaces from the default VDC to the new VDC.

3. The interface allocation is the most important part of vdc configuration. You cannot
assign ports of same port-group to different vdc. If you are unable to assign any
interface to particular vdc or some ports are being automatically being assigned,
then it could be port-grouping issue. Port group is basically how many parts are on
same hardware ASIC. So, if 4 ports are on same ASIC, then they all must be in same
vdc as they are sharing and being operated by same asic. How many port-groups
are there in my card or is there a fix formula? Basically it depends on which type of
I/O module card we are using. for example:
•N7K-M202CF-22L (1 interface x 2 port groups = 2 interfaces 100G modules)—There
are no restrictions on the interface allocation between VDCs.
•N7K-M206FQ-23L (1 interface x 6 port groups = 6 interfaces 40G modules)—There
are no restrictions on the interface allocation between VDCs.
•N7K-M224XP-23L (1 interface x 24 port groups = 24 interfaces 10G modules)—There
are no restrictions on the interface allocation between VDCs.
•N7K-M108X2-12L (1 interface x 8 port groups = 8 interfaces)—There are no
restrictions on the interface allocation between VDCs.
•N7K-M148GS-11L, N7K-M148GT-11, and N7K-M148GS-11 (12 interfaces x 4 port
groups = 48 interfaces)—There are no restrictions on the interface allocation between
VDCs, but we recommend that interfaces that belong to the same port group be in a
single VDC.
•N7K-M132XP-12 (4 interfaces x 8 port groups = 32 interfaces)—Interfaces belonging
to the same port group must belong to the same VDC. See the example for this
module in Figure 1-3.
•N7K-M148GT-11L (same as non-L M148) (1 interface x 48 port groups = 48
interfaces)—There are no restrictions on the interface allocation between VDCs.
•N7K-M132XP-12L (same as non-L M132) (1 interface x 8 port groups = 8
interfaces)—All M132 cards require allocation in groups of 4 ports and you can
configure 8 port groups.
================

4. Switching between VDC's
if you have logged into default VDC, you can use “Show VDC ” command to see what
all other vdc’s have been created.
IF you want to switch to any other vdc from default vdc, you can use “switchto vdc
<vdc name>” command as shown below and if you have logged into user created vdc
WDECAIB from default vdc using switchto command, you can use “switchback”
command to come back to default vdc, however, if you have directly ssh/telnet into
user created vdc WDECAIB here, you cannot do a “switchback” to come into default
vdc.