Menu déroulant pour mobile

Monthly Archives: October 2014

vPC order of operations

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 🙂


Cisco Expressway Setup

I am currently working on a Cisco Jabber project and my customer main requirement is that every users must be able to place calls in an easy way regardless from their location. Since the BYOD and Mobility are the trends I recommended the Cisco Expressway product line. I won’t go deep on how the expressway is working (this will be part of another blog post/series) but I’d rather share my experience regarding how to install an expressway. First and foremost I would like to say that I  have deployed 2 expressways for other customers and for my own lab and that I had no issue so far :). The problem here is specific to a particular ESXi version. I don’t have vCenter in this environment so the procedure slightly differs and I would heavily recommend to use the following documentation: Cisco Expressway VM deployment guide (8.2) When it comes to finalize the deployment I had this error :

  After a quick lookup I found many issues like that on the internet (always feel good when you are not alone right ? 🙂 ) VMware OVF Deployment KB They basically say that there is maybe an issue with the cert file when it is a multiple of 1024 and it is !!

  The workaround would be to deploy the .ova with the Open Virtualization Format Tool What I did is the following, I used that tool to recreate the OVA template from Cisco.

Let’s check both OVA files to see what it changes:


The certificate is gone from the template and you can see that ESXi can not verify the publisher


As opposed to the original OVA Template


The ESXi is running 4.1 and this issue has not happened on version 5.1 … I guess it was time to upgrade anyway 🙂 

My customer wanted me to open a TAC case to confirm that we could go live using that “hack” and Cisco told us that they are ok with that, obviously.