#Mac address learning via ports upgrade
#Mac address learning via ports mac

In the absense of keepalive messages, the secondary switch thinks that the primary has failed. Before you can repair it, the peer-link fails. There is no disruption to traffic, and the roles do not change. So far, this is not a big deal, as the peer-link is still up.

#Mac address learning via ports upgrade

Let’s upgrade to a catastrophic day… You start with a healthy vPC domain, then the keep-alive link fails. Switch2(config-vpc-domain)# peer-keepalive destination x.x.x.x source y.y.y.y vrf management timeout 400

Set the keepalive interval to 400ms (up to 10000ms) Switch2(config)# vpc domain 10 This scenario results in 3-4 seconds of traffic disruption. Traffic begins flowing again.īy default, keepalive messages are sent once every second. When three consecutive messages are missed, the secondary goes into action. The secondary switch now transitions into the primary role and brings up its member ports. The secondary gets suspicious when heartbeat messages stop coming in. What’s going to happen? The keep-alive link will now fail, as the primary switch is down.

You keep it cool, ready to work on the peer-link. You know that the secondary will shut down its member ports while the primary will continue forwarding traffic. You’ve just found out that the peer-link in one of your vPC domains has failed.

Let’s imagine that you’re having a bad day. The auto-recovery command, discussed below, can help with this scenario. This happens because the peer-link is required to perform consistency checks on new ports. If existing member ports go down, they too will stay down until the peer-link outage is repaired. If new member ports are configured while there is a peer-link failure, by default, the new ports will stay down. Unfortunately, it does ‘blackhole’ any orphan ports on the secondary switch. This prevents the duplication of frames and loops from forming. In a case where the peer-link has failed, but both switches are still up, the secondary will immediately disable it’s vPC member ports. Fortunately, due to the keepalive link, both peers are able to determine that both switches are up, and they will keep their primary and secondary roles. If there is a peer-link failure, the switches can no longer share control information. The peer-link is the most critical component of the vPC domain. LACP will see the switch pair as a single device. These values match on both peers, so there is a single System ID as far as LACP is concerned.

#Mac address learning via ports mac

The system-MAC is generated from the Domain ID and a pool of virtual MAC addresses. It does this by generating the System ID from the system MAC. vPC is crafty and gets around this problem. This would cause havoc for LACP, as there would be two different LAGIDs. If there is a mismatch, the ports are excluded or the LAG stays down, depending on the implementation.īut vPC uses two switches at one end of the link. All ports in a port-channel must have the same LAGID. These four values (two at each end) create a LAGID (Link Aggregation Group Identifier). The second value is an identifier for the LAG, such as the port-channel ID. Auto assignment comes from the system priority and the System MAC address. It is a 64-bit value which can be manually assigned or automatically generated. When creating a port channel, LACP does its due diligence and compares a few values. Connecting to more than one device at a time is an error as far as LACP is concerned. The LACP standard needs all connections in a LAG to be between two devices only. They need to negotiate their parameters with LACP. The devices that connect to vPC use normal etherchannels or LAGs.