A vPC is a special type of Etherchannel that 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. vPC is a solution to be implemented for Cisco Nexus License in NXOS mode of operation.
Component
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 will 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 of switches fail, 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.
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.
The Cisco 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 Frame Prevention
vPC lives by a personal code. 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. vPC switches can still run spanning-tree. The vPC pair appear as a single switch. By default, only the primary switch will send and process BPDU’s. You can optimize 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.
Failure Scenarios
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. If a member port fails, the second switch continues passing traffic And of course, you will get some messages in your syslog. If an entire switch fails, 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. 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.
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.
