Nexus 7k – Getting Started Examples – Part1 (basics, VDC and vPC)

So I finally had a project with Cisco Nexus switches to finally get hands on experience on these boxes. I am no longer a fanboy of Cisco, so just practically, this article is a summary of my notes and example configurations that I have put together as a documentation for myself and now I will kind of share them with you. First of all, when I started writing this article it was November 2013 and Nexus 9000 were just released, note that this articles is based on Nexus 7000 series and not the new 9000 series. Sorry, not chance to get to 9000 yet, maybe later.

Cisco Nexu Thumbnail FINAL

Let’s get started. Similarly as with my previous IOS XR Getting Started Guide (part 1 and part 2), I will go over the very quick overview and then show basically a snapshots of configuring some elemental configurations. There is actually one advantage over the IOS XR in that the NX-IOS has and that is that it is more similar to the classical IOS we all know.

Basic commands to verify hardware, software and license

So the basic show version is of course available, here is an example.

Then we can check the modules installed with show module.

What is more important on Nexus in comparison to what I consider the usual is the more strict license rules. To check what licenses are currently loaded to your Nexus, check the show license usage.

Configuration checkpoints and rollback

And this is something that I really love, you can create your something called checkpoints of the configuration so that you are very easily able to do recovery to older configurations very easily and quickly. In the following example I will create loopback 1 interface with IP, then save snapshot0 with checkpoint snapshot0 and then reconfigure interface loopback 1 with IP Once done, you can see how nicely you can recover back to the original configuration with IP

Nexus Virtual Device Context (VDC)

So lets start with the first technology, the VDC is something like VRF on steroids, you can separate the nexus system into several small individual systems with their own resources, dedicated interfaces and independent configuration files. By default you can have 8 VDC contexts on a Nexus 7000, but right now I will just use a few to illustrate what this brings to us.

Cisco Virtual Device Context (VDC) on Nexus 7000

Cisco Virtual Device Context (VDC) on Nexus 7000

First command vdc tinyVdc in global configuration mode will created the VDC that I called tinyVfc.

Then you can allocate interfaces to the created VDC with allocate interface command.

As you see, there is a limit with F2 modules, that are not by default allowed (as you can see on show vdc above) and then we can allocate the interfaces without error.

Just to check the port allocations, you can have a look on show vdc membership module command.

Each VDC has a resource limits associated with it, you can check the defaults already appeared in the running-config in vdc section. To see only this section, use show running-config vdc all command.

Connect to new VDC and initial configuration

Connecting to the new VDC command line is also easy, just use switchto vdc tinyVdc command.

The last point in this quick guide is to check if the interfaces were allocated to the tinyVdc with the show interface brief.

Configuring virtual PortChannel (vPC)

With Nexus platform, Cisco came with a neat way of having redundancy with portChannel across two physical Nexus switches and this way you can completely avoid spanning tree on major uplinks between layers (access to distribution or distribution to core).

Nexus virtual PortChannel (vPC) technology

Nexus virtual PortChannel (vPC) technology

The best thing with this logical ether channels is that the Spanning tree has no chance to block any links. To ilustrate this, imagine the typical CORE – DISTRIBUTION – ACCESS layers with Spanning Tree enabled:

Core - Distribution - Access with classical Spanning Tree (and blocked links)

Core – Distribution – Access with classical Spanning Tree (and blocked links)

This is something you can very easily avoid with Nexus switches using vPC (and even more simply with HP Switches running IRF that are cheaper 😛 – I said that I am no longer Cisco fanboy).

Nexus vPC enabled Core - Distribution - Access topology

Nexus vPC enabled Core – Distribution – Access topology

vPC example configuration

So lets create a quick vPC configuration example, this is how the LAB topology will look like.

Quick vPC lab topology

Quick vPC lab topology

Step 1 activate vpc feature

The first command we need to use is to enable the vpc feature with feature vpc command followed by creation of the vpc domain with vpc domain <#num> command.

Now that we simple enabled vpc and configured a domain, we can check the status of the domain with show vpc, but we will not see anything because nothing is really configured yet.

Step 2 Create VRF “vpc” and create an L3 keepalive link between the two Nexus switches.

First, create the VRF called “vpc”, inside will be the keepalive link and a few other features later.

Next, lets configure the synchronization lync between tinyVdc1 and tinyVdc2.

On tinyVdc1, the synchronization link is Eth4/8, this is how to configure it (repeat a mirror configuration on the neighbor).

Also a good idea before moving forward is to test the connection to the neighbor

The last part of this step is to configure this as keepalive link for the vpc domain

Before moving forward, check the keepalive status with show vpc peer-keepalive command, if you already configured also your second Nexus switch, you should see a status as “Success” just like below.

Step 3 Configure a vPC Peer Link

For the real traffic, we have to create a vPC Peer Link, on our tinyVdc1, this will be the Eth4/7.

Now we enter into port-channel 12 interface and configure it as vPC peer link

To check Peer Link status, you can use vpc consistency-parameters global command. Right now we do not have our neighbor (peer) Nexus configured, so the output looks like this:

Do the mirror configuration of Peer Link on the neighbor Nexus switch and then check show vpc consistency-parameters global for peer information again. If you did everything correctly, this is how the output should look like:

It is also a good idea to check the vpc domain if we have  “peer adjacency formed ok” in show vpc:

Step 4 Configure interface VLAN on all lab switches for VLAN 10 and VLAN 20

Now the easy (and known by all part), simply create on all three switches the interface VLANs as on the diagram below.

This is configuration on tinyVdc1 (you should know how to do tinyVdc2):

This is a configuration for the bottom “classic” IOS switch called “Switch1”:

Step 5 Configure vPC etherChannel on Nexus 7000 and classical etherChannel on IOS switch

This is the most interesting step because you will notice how simply it is now (and similar to the “normal” way of configuring it) on Nexus tinyVdc1:

Now for the Switch1:

Step 6 Verification

First, lets check our vPC with show vpc, this will not only show us the peer-link and other core information, but will display all the port-channels that exist for that vPC domain.

NOTE: In one vPC domain, you can have multiple ether-channel groups, this is not problem. Feel free to extend this lab and create another vPC ether-channel with another simple switch and assign it to the same vPC domain. It will simply show the new ether-channel in the list below.

Second test that you can make is to actually shutdown the interfaces on the IOS Switch1 below and test ping to both Nexus switches in the vPC. I will leave the commands to you as the shutdown and ping is well known, but this is how the test might look like:

vPC Test Step 1: Shutdown one interface + PING both Nexus routers

vPC test scenario 1

vPC test scenario 1

vPC Test Step 2: Shutdown the second interface + PING both Nexus routers

vPC test scenario 2

vPC test scenario 2


What can I say, Nexus product line is Cisco’s main switch for datacenter environment and features like vPC are essential for it. What however I really miss on Nexus is the virtualization technology like HP IRF (which is actually much more powerful then vPC). Something like the what is available on Catalyst 6500 called VSS that makes two physical devices to become one logical devices similarly like stacking on normal switches (actually even here is HP IRF more powerful as it doesn’t have a limit of only 2 devices and for the actual stacking HP use classical ethernet/optical 10Gbps SFP ports and not proprietary cables, this enables creating Geo-Clusters of virtual switches across two data-centers via DWDM).

In this article, I have shown the basic and essential L2 features that is needed when jumping from IOS switches like catalysts to Nexus for building L2 networks. If I will have time I plan to show a second article as “part 2” that would show another important group and that are FlexExtenders and hopefully a little FibreChannel if I get my hands on such equipment.


Peter Havrila

About Peter Havrila

Peter's Profile Page