Sie sind auf Seite 1von 8

Expert Reference Series of White Papers

The Four Steps to


Virtual Port Channel

1-800-COURSESwww.globalknowledge.com

The Four Steps to Virtual Port Channel


Alex Marcotte CCIE #16673, Certified Cisco Instructor

Overview
Virtual port channel (VPC) brings redundancy to a new level in the data center. Its not complicated to implement as long as you have the right hardware with the right connections. The requirements are well known and
as long as you follow the rules, VPC will work just fine. As a matter of fact, getting it to work is the easy part.
This white paper reviews the basics of VPC and the options available to tailor it to your needs.
However, as I always emphasize to my customers, you also need to understand what happens when VPC fails.
There is no point in spending time and energy configuring a redundancy strategy if you have no idea whats
going to happen when one (or all!) of the components fail. You may end up causing more harm to the network
and the availability of the data products by not understanding the doomsday scenarios that may occur. The
second half of this paper will review some potential failures and what you can do to avoid them.

Introduction to VPCs
In todays data centers, there is constant worry about high-availability and resiliency to ensure that customers
can get to their data, while meeting a service level agreement (SLA) that is very close to 100%. To achieve this,
we must look at every possible way that the network (or the gear that makes up the network) could fail without
impacting data transmissions.
With pure networking, were concerned with having multiple routes or ways to get from point A to point B. For
instance, we have routing protocols to help us at layer 3, where the routers job is to maintain visibility throughout the network and pick the optimal way to send the packet. At layer 2, we have tools like FabricPath and TRILL
that will replace spanning tree. Even when that protocol came along, we were still concerned about having the
capability of connecting switches with redundant cables and interconnecting those switches by giving them options to get to the root so the switch would take the optimal path while blocking the redundant path.
Of course, the objective nowadays has changed from preventing for example layer 2 loops to connecting devices
on the network and offering them high availability and performance. For example, a server administrator tells
you, the network administrator, that he or she needs to connect the new server to the network. Your approach is
to evaluate this with high availability in mind.
Right away you identify that a single NIC connected to a single switch is a point of failure: the cable could go
bad and drop the connection, the NIC could fail, or the switch that the server is connecting to could just stop
functioning.
Copyright 2011 Global Knowledge Training LLC. All rights reserved.

When you design something like this, you are already taking into consideration that this server may need multiple NICs that would allow multiple physical connections to an upstream switch. That would take care of layer 1
redundancy, and you could leverage port channel technology to bundle those two interfaces together and treat
them as one logical interface. Most server operating systems nowadays understand port channel, and some
even use performance algorithms to make most efficient use of both links that are presented to them.

Figure 1.

Seems like your problem is solved but is it? Going back to your diagram, you realize this switch may have
redundant layer 1 connections and may be able to use both links as a performance tool, but what happens
if the switch itself fails? Now you have a layer 2 redundancy problem, so you tell your server admin to forget
about this port channel business because you are going to have to connect this server to two different upstream
switches. If youre dealing with regular low-end switches, this type of connection with the server will become
an active/passive NIC teaming scenario, because the virtual MAC address cannot be known by both switches
independently at the same time, to avoid any inconsistencies on the network.
This is where virtual port channel technology (VPC) enters. The whole concept of VPC is to join two switches
together and make them function as if they were a single switch and act to connected devices as one logical
switch. VPC is currently available on the Cisco Nexus 5000 and 7000 series switches, as well as some high-end
Catalyst models.

Copyright 2011 Global Knowledge Training LLC. All rights reserved.

Figure 2.

There are four major components of a successful virtual port channel implementation:
1.

domain ID

If you join two switches together, they must identify with the same ID. Here you pick a number, any number, and
make sure that both switches agree on that. For example, you can say that your domain ID will be 1. Its a oneline configuration, so that should not take all day. If youre dealing with Nexus switches, you must enable two
features for this to work: VPC and LACP.
2.

peer link

In order to join the switches and synchronize their MAC address tables together, Cisco fabric services (CFS) must
run in the background. Synchronization occurs over the peer link, which requires 10 GB interfaces joined in a
port channel that may have been existing prior to your VPC configuration. The port channel part of this is not
actually required, but no one in their right mind would interconnect two switches and make them bond with
the MAC address table synchronization. That would make it a critical link to the whole process and not give the
assurance of having multiple physical interfaces carrying this load. As a matter of fact, if you are dealing with a
Nexus 7000, I recommend using interfaces that belong to two different line cards.
3.

keep alive link

The switches will synchronize using the peer link, but in order to verify their liveliness, they will use a keep alive
link. The keep alive link is simply a layer 3 link onto which the switches will ping each other. This is important,
but not as critical as the peer link.
4.

port channel groups

Once the switches are joined you will need to tell the switches which port channel groups to synchronize to the
neighbors. Basically, requirements 12 and 3 will establish the functionality of VPC, but no synchronization will
occur until you actually play some port channels into the mix.

Copyright 2011 Global Knowledge Training LLC. All rights reserved.

VPC versus VSS


You may be reading this and thinking: Wait a minute, I already have seen this before with the VSS technology.
With VPC and VSS, the goals are pretty much the same, but the way we achieve it is radically different. With VSS,
we used to join the two physical switches into one logical switch by joining not only the data plane but also the
control plane so the switches would operate with a single brain, which could cause severe problems if switches
failed. In VPC, we keep the control planes separate, and we only worry about synchronizing Mac address tables.

Traffic flow
Figure 3 shows the server at the bottom sending a frame that is destined to the host at the top of the picture. It
shows what happens with VPC when the server at the bottom of the picture is dual connected to the network
in an active/active fashion. In most design documentation, you will see that servers and other network devices,
such as switches that do not understand VPC, are called non-VPC devices.

Figure 3.

The first task of the server (Host A) is to decide on which of the two links the frame will be sent. Whatever this
server is using for NIC teaming will make a decision; in this example, the left link was picked, and the frame is
sent up. The picture shows the server is connected to Nexus 2000 fabric extenders that are children switches to
the Nexus 5000s. You can ignore the Nexus 2000 devices because they do not participate in VPC, but the Nexus
5000 switches are the ones that are paired in a VPC domain.

Copyright 2011 Global Knowledge Training LLC. All rights reserved.

The frame is forwarded from the ingress port of the Nexus 2002, to the parent Nexus 5000, which then realizes
that it is now learning a MAC address on a port channel that is member of the group. That essentially means
that one interface of this port channel may be local to the ingress switch, but another interface is present into
the peer switch, indicating that the MAC address that is learned needs to be advertised to the peer switch as
belonging to the port channel that they share.
The frame will be forwarded to the upstream link to a non-VPC switch that may be connected to the peer Nexus
5000s via normal port channel (but that is currently irrelevant in our example), and eventually the host will
receive the frame.

Return flow
Once the host on top of the picture is ready to send the traffic back, the non-VPC switch will get it, and for the
sake of this example, a different path is chosen for that frame and will then be forwarded to the right-hand
switch. Now this is where things get interesting: novice network engineers would look at this and think that
the frames on the right-hand switch would be forwarded to the left-hand switch using the peer link, but that
is not the case. When VPC is fully functional, this switch will look at the destination MAC address and realize
that it has a local link that can reach that destination MAC address and will forward the frame to its own fabric
extender, down to the destination server at the bottom of the picture.

Figure 4.

Copyright 2011 Global Knowledge Training LLC. All rights reserved.

So what do we have with VPC now? We are offering layer 1 redundancy to the server with our physical connections, we are also offering layer 2 redundancy by having the redundant switches, and we are offering performance because both links can be utilized in an active/active fashion.

What about spanning tree?


Spanning tree is the insurance policy for VPC when it fails. In the scenario presented earlier (Figure 4), you could
see that all the links were open and forwarding regardless of where they were, because of the port channels
(not necessarily VPC). Weve known that spanning tree treats port channel interfaces as one logical link, so it
is not looking at blocking redundant paths. The way the two Nexus 5000 switches work with spanning tree to
propagate BPDUs (bridge protocol data units) to the rest of the network is that one switch in the pair will be a
primary and you could say that it is the root. The secondary switch would simply repeat that BPDU identically.
This is important to know because if the primary fails, we want to avoid a reconvergence of spanning tree on
the rest of the network, and there are ways to avoid that when you configure the peers.

Failures
A few things could go wrong with VPC, and I will introduce you to a few scenarios just to give you an idea of
what to expect.
Interface in port channel group failure
If the server were to lose a NIC, its associated interface on the switch that is a member of the port channel
group would then be in down status. In the previous example (Figure 4), if the right uplink from the server
would go down and the right Nexus 5000 switch received a frame meant for that server, it would forward the
frame using the peer link to the left switch which would then send it down to the server. The reason why that
happens is because the switch on the right realizes that it has no local interfaces it can use to reach this MAC
address, but would know that the peer switch has a way to it. This is the only time where the peer links are
actually in use, other than to send CFS messages to one another. This is why these must be high capacity links,
because a failure should not impede the traffic meant for that device.
Keep alive link failure
If, for some reason, the keep alive link fails, the switches will mark VPC as inconsistent but continue with normal
operations. While not critical, the keep alive link is important, and your VPC moving to an inconsistent state
should raise an alarm for you to look into the situation.
Peer link failure
If the peer link fails, the primary switch will inquire to the secondary switch via keep alive link about his status.
If the secondary switch is still alive, the primary will instruct the secondary to shut down any VPC-enabled port
channel groups and to flush the shared MAC address table so any new traffic should not be sent to that switch.
That also means that in the example above, if the two uplinks were in a port channel group, the link that belongs to the secondary switch will be shut down as well.

Copyright 2011 Global Knowledge Training LLC. All rights reserved.

Keep alive and peer link failure


This is a doomsday scenario that nobody wants to encounter: what if both the peer link and the keep alive links
fail? This could happen in two different ways:
1. The primary or secondary switch could reboot, thereby breaking all the links. That would be the fun
scenario.
2. The links between the switches actually all failed, but the switches are still alive.
This is where you suddenly realize that my strong recommendations for having multiple links in the peer link to
make this bond as strong as possible were important after all. If this happens, the primary switch will continue
forwarding as normal because it is the primary and it cannot reach the secondary to tell it to stop forwarding to
the VPC member groups. The primary is probably just thinking that the secondary is completely off-line. On the
other hand, the secondary has the same exact thoughts about the primary and decides that it needs to take over
to assume the primary functions. This causes a split brains scenario that will wreak havoc in the traffic meant
for any hosts that are connected to the switches. Unfortunately, there is no way to avoid this but to prepare and
make this possibility of it happening as small as possible.

Conclusion
VPC now takes redundancy to the new level in the data center. If you have the right equipment, you can leverage the functionalities of VPC by making all available paths usable and giving all the bandwidth that you have
to your hosts. This white paper has explained the basics of virtual port channel and there are actually quite a
few options and configuration tools in Nexus to make sure that VPC is tailored for your needs and is as easy to
configure as you wish.

Learn More
Learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge
through training.
DCNX7 Data Center Networking with the Cisco Nexus 7000
DCNX5 Data Center Networking with the Cisco Nexus 5000 & 2000
DCNX5+7 - Implementing and Configuring the Cisco Nexus 5000 and 7000
Visit www.globalknowledge.com or call 1-800-COURSES (1-800-268-7737) to speak with a Global Knowledge training advisor.

About the Author


Alex Marcotte is a CCIE in security #16673, Cisco Certified Instructor (CCSI), and a Cisco WAN Specialist with
14 years of experience in the field. He manages a data center in Houston, Texas, for Evertech, LLC which hosts
several business applications such as remote backups, email, and virtual servers.

Copyright 2011 Global Knowledge Training LLC. All rights reserved.

Das könnte Ihnen auch gefallen