vPC Control Plane – Cisco Port Channels and vPCs

vPC Control Plane

A vPC uses CFSoE as the primary control plane protocol for vPC. The CFSoE protocol runs on vPC peer-link and performs the following control plane operations:

  • Validation and comparison for consistency check
  • Synchronization of MAC addresses for member ports
  • Status of member ports advertisement
  • Primary and secondary vPC devices election
  • STP management
  • Synchronization of IGMP snooping
  • Synchronization of Address Resolution Protocol (ARP) table

Figure 4-9 illustrates the functions performed by vPC control plane.

  

Figure 4-9 vPC Control Plane

Similar to regular port channels, virtual port channels are subject to consistency checks and compatibility checks. CFSoE protocol communicates essential configuration information to ensure configuration consistency between peer switches. During a compatibility check, one vPC peer conveys configuration information to the other vPC peer to verify that vPC member ports can actually form a port channel. For example, if two ports that are going to join the channel carry a different set of VLANs, this is a misconfiguration. Depending on the severity of the misconfiguration, vPC may either warn the user (Type-2 misconfiguration) or suspend the port channel (Type-1 misconfiguration). In the specific case of a VLAN mismatch, only the VLAN that differs between the vPC member ports will be suspended on all the vPC port channels. You can verify the consistency between vPC peers by using the command show vpc consistency-parameter. In addition to compatibility checks for the individual vPCs, CFSoE also performs consistency checks for a set of switch-wide parameters that must be configured consistently on the two peer switches.

The vPC peers must synchronize the Layer 2 forwarding table (that is, the MAC address information between the vPC peers). If one vPC peer learns a new MAC address, that MAC address is also communicated to the other vPC peer using the CFSoE protocol.
The other vPC peer then programs the new MAC address information into the Layer 2 forwarding table. This MAC address learning mechanism replaces the regular switch MAC address learning mechanism and prevents traffic from being forwarded across the vPC peer-link unnecessarily.

If one vPC member port goes down on a vPC peer (for instance, if a link from a NIC goes down), the member is removed from the port channel without bringing down the vPC entirely. The vPC peer where the member port went down informs the other vPC peer using the CFSoE protocol. The vPC peer on which the remaining port is located will allow frames to be sent from the peer-link to the vPC orphan port. The Layer 2 forwarding table for the switch that detected the failure is also updated to point the MAC addresses that were associated with the vPC port to the peer-link. When all vPC member ports on one of the vPC peer switches go down, Cisco Fabric Services notifies the other vPC peer switch that its ports are now orphan ports and that traffic received on the peer-link for that vPC should now be forwarded to the vPC.

When you configure the vPC peer-link, the vPC peer devices negotiate using the CFSoE protocol and perform an election to determine the primary and secondary role of peer switches. The Cisco NX-OS software uses the lowest MAC address to elect the primary device. The software takes different actions on each device (that is, the primary and secondary) only in certain failover conditions. We will look at different failure scenarios later in this chapter. vPCs do not support role preemption. If the primary vPC peer device fails, the secondary vPC peer device takes over to become operationally the vPC primary device. However, the original operational roles are not restored if the formerly primary vPC comes up again.

Although vPCs provide a loop-free Layer 2 topology, STP is still required to provide a fail-safe mechanism to protect against any incorrect or defective cabling or possible misconfiguration. When you first bring up a vPC, STP reconverges. STP treats the vPC peer-link as a special link and always includes the vPC peer-link in the STP active topology. STP is distributed; that is, the protocol continues running on both vPC peer devices. However, the configuration on the vPC peer device elected as the primary device controls the STP process for the vPC interfaces on the secondary vPC peer device. The primary vPC device synchronizes the STP state on the vPC secondary peer device using CFSoE. The STP process for vPC also relies on the periodic keepalive messages to determine when one of the connected devices on the vPC peer-link fails. It is recommended to configure the primary vPC peer device as the STP primary root device and configure the
secondary VPC device to be the STP secondary root device. If the primary vPC peer device fails over to the secondary vPC peer device, there is no change in the STP topology. The vPC primary device sends and processes BPDUs on the vPC interfaces and uses its own bridge ID. The secondary switch only relays BPDUs and does not generate any BPDU. The vPC peer switch feature allows a pair of vPC peers to appear as a single STP root in the Layer 2 topology. In vPC peer switch mode, STP BPDUs are sent from both vPC peer devices, and both primary and secondary switches use the same bridge ID to present themselves as a single switch. This improves vPC convergence. You must configure both ends of vPC peer-link with the identical STP configuration.

The IGMP snooping process on a vPC peer device shares the learned group information with the other vPC peer device through the vPC peer-link using the CFSoE protocol. When IGMP traffic enters a vPC peer switch through a vPC port channel, it triggers hardware programming for the multicast entry on both vPC member devices. Multicast traffic is copied over the peer-link to help ensure that orphan ports get the multicast stream and to help with failure scenarios. This happens regardless of the presence of receivers on the vPC peer.

The ARP table synchronization across vPC peers uses CFSoE. The ARP table synchronization feature enables faster convergence of address tables between the vPC peers. This convergence overcomes the delay that occurs in ARP table restoration for IPv4 or ND table restoration for IPv6 when the vPC peer-link port channel flaps or when a vPC peer comes back online. This feature is disabled by default and can be enabled using the ip arp synchronize or ipv6 nd synchronize command.

Leave a Comment