utilize the vPC. Generally, this link is the main interswitch link between the two switches. The vPC peer link must be a multi-10 Gbps EtherChannel according to the documentation. Indeed, it should be, but it will work with a single link if you need to test it in a lab. Regardless of the number of links, the interface must be a port channel. This command is the same on both the 5000 and the 7000. Here, port channel 1 is used as the peer link: NX-5K-1 (config-if)# int po 1 NX-5K-1 (config-if)# vpc peer-link Please note that spanning tree port type is changed to "network" port type on vPC peer-link. This will enable spanning tree Bridge Assurance on vPC peer-link provided the STP Bridge Assurance (which is enabled by default) is not disabled. Once this is done, you must tag the EtherChannels on each 5K that are to be linked into a single VDC. A good rule to follow is to tag the EtherChannel with the same number as the channel itself: interface port-channel 10 vpc 10 Please configure the vPC to be the same number as the port channel to which it is assigned. Having to debug a vPC where the numbers don't match is a puzzle that I don't enjoy solving when the CEO is barking at me to get the switch back up. Keep it simple. Invariably, when your vPCs don't work, you'll wonder what in the Sam Hill is going on. Luckily, Cisco saw fit to include a command or two to help us figure out the problem. vPCs rely on the configuration of each side of the link to match exactly, in much the way that an EtherChannel requires each of its component interfaces to match. The difference is that with vPCs, the configurations of two separate switches must match, and the requirements span more than just the interfaces in question. There are two types of vPC compatibility parameters: type 1 and type 2. Type -1 pa- rameters must match, or the vPC will not form (or will break if already formed). Type -2 parameters should match, but the vPCs should not break if they don't. I've worked in Nexus environments where changing type-2 parameters has caus