Of all the videos I have made, vPC configuration is by far the most popular.
But I never really explained how vPC works… So now it’s time to go back and have a look
below the surface of vPC Before we go on, please subscribe to be notified
of any new videos, or follow me on twitter.
A vPC is a special type of Etherchannel or LAG. It connects a device to two switches,
not just one. This is why it’s part of the multi-chassis etherchannel family.
vPC is a Cisco technology, found in the Nexus platform. It’s like VSS, which is also a
Cisco technology, but for the Catalyst platform. Other vendors have similar technologies as
well. There is no special requirement on the device
end. As long as they support LACP, they’ll be fine.
The dual-active links helps with increasing
bandwidth, and decreasing the need for spanning-tree. When connecting switches with spanning-tree,
some links will be active while others get disabled. vPC is an effective way to work
around this.
vPC’s provide redundancy and dual-active paths.
As there are two or more paths to two switches, there is no single point of failure.
Even if one switch fails, traffic will still flow.
Like etherchannel, vPC is a layer-2 technology.
Frames may be sent over any link. Frames are not duplicated over links to both
switches. As we’ll see a bit later, this would be really bad.
Let’s start with a few basics. vPC uses two Nexus switches, called peers.
The two peers and their related components are collectively called a vPC domain.
Each domain has a unique value, called the Domain ID. Each switch can only be in a single
domain. One of the switches will be the primary, and
the other will be the secondary. Both switches forward traffic. The primary switch handles
the majority of control plane traffic.
vPC uses two special links to connect the
two switches. These are the peer-link and the keep-alive link
The peer switches use the layer-3 keep-alive link for sending and receiving heartbeats.
This is how one peer can see if the other peer is still alive.
Some failures could cause a situation where both switches are up, but they cannot see
each other. Both will think they are the primary switch, causing a split-brain scenario. To
prevent this, the keep alive link is isolated in a separate VRF. This gives each switch
a unique way of seeing if the peer is up. A good option for a small network is to connect
the management interfaces of the two switches. In a larger environment, the management interface
may connect to the out-of-band management network.
Another alternative is not to use the management interface at all, but use normal interfaces
in a dedicated VRF.
The peer-link is CRITICAL. It’s a high-speed link, used for forwarding traffic, and sharing
state updates. It forms a sort-of ‘backplane’ between the two peers.
The peer-link forwards broadcast and multicast traffic. Under some conditions, such as a
link failure, it will also carry regular unicast traffic as well.
MAC addresses that the switches have learned are synchronized. By sharing this information,
they can recover faster during a switch failure.
In any switch with vPC, there are two types of host ports. These are member ports and
orphan ports A member port is any port that is configured
with vPC, such as ports connected to a server. Any VLANs allowed on the member ports must
also be allowed on the peer-link An orphan port is any port that has no vPC
configuration. This is common for individual ports connected to routers. Any VLANs on these
ports do not need to be on the peer-link. vPC will check each member port for inconsistencies.
If it finds a problem, it calls them a type-1 or type-2 inconsistency error.
If a type-1 error is found, the primary switch will keep its port up, and the secondary switch
will disable its port. This allows traffic to continue to flow, without causing errors.
This type of error is common if some of the config doesn’t match on both switches.
A type-2 error is less severe. Both switches will keep their ports up, and will generate
syslog messages.
vPC is still very much like active etherchannel. Connected devices still use LACP to negotiate
the LAG. Yet, with vPC there’s a catch… In a normal LAG, each LACP device has a System-ID.
The System-ID is used to make sure that there is only one device at each end of the LAG
This is a problem for vPC, which uses two switches on the end of the LAG, not just one
Nexus switches are able to work around this. They use the domain ID, which we configure,
to generate the system MAC. They then use the system MAC to generate
the System-ID.
When generating the System-ID, LACP also uses the system priority.
This means that the system priority also needs to be the same on both switches
With the same System-ID, they now appear as
a single switch to any connected device.
The domain ID brings up an interesting point.
What happens if you have several pairs of vPC switches in the network?
To prevent problems from bad cabling, each pair should have a different domain ID, which
results in a different system ID
Duplicate frames are a very bad thing. Imagine a scenario where Server-1 is sending traffic
to server-2 Server-1 sends frames to Switch-1. What would
happen if Switch-1 forwarded the frames to Switch-2 over the peer link? Both switches
would attempt to deliver the traffic This can be annoying for some types of traffic,
but could cause serious problems for others
The good news is that vPC won’t allow this to happen
You see, vPC lives by a personal code. It
goes something like this: “If a frame is received on the peer link, and the frame needs
to be delivered to a member port, the frame will be dropped”
Let’s think about the earlier scenario. Server-1 sends a frame
Switch-1 gets the frame, and forwards it to server-2, and over the peer-link to Switch-2
Switch-2 gets the frame, and realises that it needs to go to a member port. Switch-2
recognises that Switch-1 will already have delivered the frame, and will drop it
What if traffic needs to be sent out an orphan port?
The duplicate frame prevention rule does not apply here, and Switch-2 will not drop the traffic
vPC is very useful for is limiting the negative effects of spanning-tree. But, that doesn’t
mean that you should disable spanning-tree entirely.
Think for a moment about what would happen if other switches are connected to the vPC
domain If spanning tree were disabled, a loop could
form. As you can see, spanning-tree is critical vPC switches can still run spanning-tree.
As you would expect, the vPC pair appear as a single switch
By default, only the primary switch will send and process BPDU’s. You can optimise this
with the ‘peer-switch’ command, which allows both switches to take part in spanning-tree
Even when they’re both processing BPDU’s, the vPC pair still appear as a single switch.
This is because they use the same bridge-ID, and generally would use the same bridge priority
vPC is resilient, but it is not invincible. Member ports can go down, the peer-link or
keep-alive link can go down, or an entire switch could fail.
It’s time to take a look at what will happen during a failure
Let’s start with failing member ports. This one’s quite simple. If a member port fails,
the second switch continues passing traffic And of course, you will get some messages
in your syslog.
What if an entire switch fails? This is also a pretty simple scenario. The alternate switch
continues to forward traffic Unless, of course, you have orphan ports.
Orphan ports are only connected to a single switch anyway, so these devices will be isolated
If the failed switch was the primary, the secondary will take over the primary role
What will happen when the switch has been restored? Will the failed switch become primary
again? I’ll give you a few seconds to think about this…
So what do you think? vPC switches are not pre-emptive. This means that the restored
switch will be the secondary, and the other will remain as the primary
This happens because there is a risk of traffic loss when a switch becomes the primary role
Now for some more tricky failures… The peer-link is the most critical component in the vPC
system. When the peer-link fails, both switches are
still able to see that the partner is up, thanks to the keep-alive link
This creates a two problems; duplicate frames and loops. To handle this, the secondary switch
shuts down its member ports The primary switch continues to forward traffic
as normal. Orphan ports also stay up
Let’s make this a little more interesting.
What happens if the primary switch fails now? This is a pretty unlucky scenario to be in
The secondary switch notices the failure when it misses heartbeats on the keep-alive link
The secondary does its duty, and it takes over the primary role. Its member ports are
enabled, and traffic flows again
If the keep alive link fails, there will be no heartbeats.
Pretty bad right? Well, no. Not as bad as it sounds. The peer link is still up, so the
peers are still happy Let’s look at another rare scenario where
both keep-alive and peer-link fail. The first possibility is where the peer-link
fails first, and then the keep-alive fails This isn’t too bad. The secondary has already
disabled its member ports. So when the keep alive fails, there’s no operational impact,
as only the primary is forwarding traffic anyway
Let’s imagine that you’re having a really bad day
First, the keep-alive fails. Not too bad so far…
Then, the peer-link fails. Each switch thinks that the other switch has failed.
The secondary switch does its duty and takes on the primary role
Both switches are now trying to forward traffic. This is called a ‘split-brain’ scenario.
This is where the administrator needs to intervene While this is rare, it highlights the need
to design the solution well. For example, use redundant physical links for the peer-link
That’s the high level explanation of how vPC works. You can get more detail in the
full article on the Network Direction site. I’m also considering a short video on dynamic
routing with vPC. If this is something you’d like to see, let me know in the comments below.
Don’t forget to subscribe, and thanks for watching!