Menu déroulant pour mobile

vPC order of operations

14 October 2014 | Written by Nicolas Michel | Published in Data Center

Cisco Nexus can be very temperamental or capricious (pick the one you prefer 🙂 ) and the vPC technology is not an isolated case.

There is a certain way to configure vPC and we will see that in that blogpost.

The following topology will be used:


vPC diagram

Enabling the feature

Obviously we need to activate the vPC and LACP feature in order to build a proper vPC configuration.


Peer Keepalive connectivity

The Peer Keepalive link is used to detect failure between the peers. It is definitely not used in the data plane. On N5K, the management interface is usually used for the Peer Keepalive Link and management purpose. On N7K, Cisco does not recommend to use the supervisor interface as a vPC peer-keepalive link since it can introduce failure if that supervisor crashes…..

In our example we will use the management interface in order to have IP connectivity between our vPC peers.

Now let’s check if N5K-1 can reach N5K-2

The behaviour above is normal since we are trying to ping using the global RIB and the mgmt 0 interface does not belong to that RIB. Instead it does belong to the management vrf . So if we add the “vrf management”  keywords, everything should be fine !

and it is 🙂


vPC domain and vPC peer link configuration

Now let’s create the vPC domain and the vPC peer link.

Please be aware that it is a best practice to configure an unique vpc domain ID for every pair of Nexus. The vPC domain ID will be used to build a system mac-address. So if 4 nexus are connected together created 2 vPC domains and if both vPC domains have the same system mac-address, you will experience something funny 🙂

I decided that N5K-1 will be elected as the Primary vPC peer and N5K-2 will remain Secondary vPC peer.

Please note that if you do not specify a keyword for the peer-keepalive destination command, the switch automatically use the management vrf.

As we can see above, the vPC keep-alive status is OK since we have reachability between our mgmt 0 interface.

We will now create our vPC peer-link that will be mainly used for CSF and many other things (will be detailed in a future blogpost)

Enabling the vPC peer-link on the port-channel automatically set the type to network for that interface. This means that we just enabled bridge assurance on that link. In a vPC topology, Cisco recommends to enable Bridge Assurance only on the vPC peer-link.

We can now enable the interface to check the status of our port-channel.

Our Port-channel is functionning properly so we can check the status of our vPC peer link now

Everything looks so far so good !

Do you remember when I explain about the dependencies between vPC domain and vPC system mac-address ? 🙂 here is the result

vPC Configuration

We will now create a vPC towards an LACP neighbor which in this case will be a server.

Here is the configuration used on both Nexus

Let’s assume that our server’s NIC team is already configured for LACP. Let’s now check the vPC status

Consistency parameters are matching on both vPC peers and our vPC towards that server is functional 🙂


LACP verification

The following output will confirm that we are indeed having an LACP port-channel between the server and the vPC peers

This post was a bit basic but it can get tricky to troubleshoot a vPC so be sure to follow the steps above in order to save time in your deployment/labs.

We will dig deeper on vPC tricks soon 🙂


Leave a Reply