Stackvora.tech

Cisco Nexus vPC: end-to-end configuration walkthrough

Cisco Nexus Virtual PortChannel (vPC) provides a loop-free, active/active server or downstream switch attachment from two distinct Nexus switches,…

Cisco Nexus Virtual PortChannel (vPC) provides a loop-free, active/active server or downstream switch attachment from two distinct Nexus switches, appearing as a single logical entity. This architecture eliminates Spanning Tree Protocol (STP) blocking on redundant links and maximizes bandwidth utilization. This guide details the end-to-end configuration of a vPC pair, including critical parameters and verification steps.

The core components of a vPC setup are the peer link, the peer-keepalive link, and the vPC member port-channels. The peer link is a high-bandwidth Ethernet PortChannel connecting the two Nexus vPC peers, primarily for control plane synchronization, MAC address learning, and data plane forwarding for specific scenarios (e.g., orphan ports, HSRP/VRRP synchronization). The peer-keepalive link is an out-of-band management link used to monitor the liveness of the vPC peer, preventing split-brain scenarios. vPC member ports are standard EtherChannels dual-homed from a downstream device to both vPC peers.

Architectural Overview and Key Components

Understanding the fundamental components is crucial for a robust vPC deployment. The Nexus 5000, 7000, and 9000 series switches support vPC, with minor command variations across NX-OS versions (e.g., older versions might not support peer-gateway or auto-recovery in the same form). This guide focuses on common commands applicable to NX-OS 7.x and later.

  • vPC Peer Devices: Two Cisco Nexus switches, typically from the same series (e.g., two Nexus 9300s). While inter-series vPC can sometimes be configured, it's generally not recommended due to potential performance and feature discrepancies.
  • vPC Peer Link: A dedicated EtherChannel (PortChannel) between the two vPC peer devices. This link carries vPC control plane traffic, HSRP/VRRP advertisements, and some data plane traffic (e.g., broadcast, unknown unicast, and multicast (BUM) traffic, or traffic destined for an orphan port). It's critical to provision sufficient bandwidth; typically, 2x10GE or 2x40GE links for smaller deployments, scaling up to 4x100GE for larger fabrics. Misconfiguration or failure of the peer link can lead to catastrophic network outages.
  • vPC Peer-Keepalive Link: A Layer 3 link used solely for detecting the liveness of the vPC peer. This link should be out-of-band (e.g., management port or a dedicated data port in a separate VRF) and independent of the peer link to avoid shared fate. It uses a simple keepalive mechanism over UDP port 3200.
  • vPC Domain: A logical grouping of the two vPC peer switches. Each domain has a unique ID (1-1000) and a system MAC address derived from this ID.
  • vPC Member Ports: EtherChannels configured on the downstream devices (servers, firewalls, or other switches) and connected to both vPC peers. These are standard 802.3ad LACP PortChannels.
  • vPC Orphan Ports: A non-vPC port on a vPC peer that connects to a single-homed device. Traffic from an orphan port might need to traverse the peer link to reach its destination on the other vPC peer.

Initial Setup and Global Configuration

Before configuring vPC, ensure basic connectivity and management interfaces are operational on both Nexus switches. This includes IP addressing for the management interface and the peer-keepalive link, and NTP synchronization for consistent logging and troubleshooting.

Common prerequisite steps (on both Nexus switches):

! Enable required features
feature vpc
feature lacp
feature interface-vlan
feature HSRP # If using HSRP with vPC

! Configure global NTP (example)
ntp server 192.168.1.1 prefer source mgmt0

The vPC domain configuration defines the relationship between the two Nexus peers. The vpc domain ID must be unique and identical on both switches.

On Nexus-A (vPC primary):

vpc domain 10
  peer-keepalive destination 10.0.0.2 source 10.0.0.1 vrf management # Use a dedicated L3 interface or mgmt0
  peer-switch                                                        # Recommended to avoid STP issues
  auto-recovery                                                      # Enables auto-recovery after peer-link failure
  auto-recovery reload-delay 300                                     # Default 240s, allows time for peer to reload
  delay restore 150                                                  # Default 30s, prevents premature bringing up of vPC ports
  peer-gateway                                                       # Recommended for better HSRP/VRRP and ARP behavior
  ip arp synchronize                                                 # Synchronizes ARP tables between peers
  mac-address-table synchronize                                      # Synchronizes MAC tables for non-IP devices (e.g., FCoE)
  role priority 100                                                  # Lower value means higher priority (Nexus-A is primary)

On Nexus-B (vPC secondary):

vpc domain 10
  peer-keepalive destination 10.0.0.1 source 10.0.0.2 vrf management # Note source/destination swap
  peer-switch
  auto-recovery
  auto-recovery reload-delay 300
  delay restore 150
  peer-gateway
  ip arp synchronize
  mac-address-table synchronize
  role priority 200                                                  # Higher value means lower priority (Nexus-B is secondary)

Notes on Global vPC Parameters:

  • peer-switch: Essential for preventing STP inconsistencies where one switch could block vPC member ports. It allows both vPC peers to process BPDUs for the same VLANs, appearing as a single STP root.
  • peer-gateway: Improves HSRP/VRRP and ARP resolution when a vPC member is dual-homed. It allows the local vPC peer to respond to ARP requests for its peer's HSRP/VRRP virtual IP, even if the destination MAC is learned via the peer link. This reduces peer link traffic and ARP-related issues with some network interface cards (NICs).
  • auto-recovery: In case of a complete peer-link failure and the primary vPC peer going down, the secondary peer will assume primary role and restore its vPC member ports after a delay (default 240 seconds, configurable with reload-delay).
  • delay restore [seconds]: This prevents vPC member ports from coming up too quickly after a peer-link restoration or switch reload, giving the control plane time to stabilize.
  • ip arp synchronize: Ensures ARP entries are synchronized across the vPC peers, which is particularly beneficial for devices that do not support LACP (e.g., static EtherChannels).
  • mac-address-table synchronize: Essential for FCoE or other non-IP environments to ensure MAC address learning is consistent.
  • role priority: Determines which Nexus switch becomes the primary vPC peer. The switch with the numerically lower priority will become primary. The primary handles some vPC control plane functions, such as processing BPDUs for vPC VLANs.

Peer Link Configuration

The peer link is a critical component for vPC functionality. It must be an EtherChannel, preferably with multiple physical links for redundancy and bandwidth. It should consist of dedicated interfaces. For Nexus 9300 series, 40Gbps or 100Gbps links are commonly used.

On Nexus-A:

interface Ethernet1/49-50      # Example: using two 40G interfaces
  description vPC_Peer_Link_to_Nexus_B
  channel-group 100 mode active
  no shut

interface port-channel100
  description vPC_Peer_Link
  switchport
  switchport mode trunk
  switchport trunk allowed vlan 1-4094 # Allow all necessary VLANs for vPC traffic
  vpc peer-link
  spanning-tree port type network      # Recommended for peer-link
  no shut

On Nexus-B:

interface Ethernet1/49-50      # Example: using two 40G interfaces
  description vPC_Peer_Link_to_Nexus_A
  channel-group 100 mode active
  no shut

interface port-channel100
  description vPC_Peer_Link
  switchport
  switchport mode trunk
  switchport trunk allowed vlan 1-4094 # Allow all necessary VLANs for vPC traffic
  vpc peer-link
  spanning-tree port type network
  no shut

Important considerations for Peer Link:

  • The vpc peer-link command is what designates this PortChannel as the vPC peer link.
  • All VLANs that will be used by vPC member ports must be allowed on the peer link. If a VLAN is missing, it will create a Type-1 consistency failure and potentially blackhole traffic.
  • spanning-tree port type network ensures that BPDUs received on this PortChannel are treated as from a network device, influencing STP root election and stability.

vPC Member Port Configuration

vPC member ports are standard EtherChannels dual-homed to the vPC pair. These are the interfaces that connect to downstream devices (e.g., servers, access switches, firewalls).

On Nexus-A (for a downstream server/switch dual-homed to Eth1/1-2):

interface Ethernet1/1-2
  description To_Downstream_Device_A
  channel-group 20 mode active
  no shut

interface port-channel20
  description vPC_Member_Po_to_Downstream_Device_A
  switchport
  switchport mode trunk
  switchport trunk allowed vlan 10,20,30 # Only allow required VLANs
  vpc 20                                # The vPC ID here must be unique per vPC member Po on each peer
  spanning-tree port type normal        # For end-device or non-network switch connections
  no shut

On Nexus-B (for the same downstream server/switch):

interface Ethernet1/1-2
  description To_Downstream_Device_A
  channel-group 20 mode active
  no shut

interface port-channel20
  description vPC_Member_Po_to_Downstream_Device_A
  switchport
  switchport mode trunk
  switchport trunk allowed vlan 10,20,30
  vpc 20
  spanning-tree port type normal
  no shut

Key points for vPC Member Ports:

  • The vpc [ID] command on the PortChannel interface designates it as a vPC member port. This ID is local to the peer-link and must match on both vPC peers for the same downstream PortChannel.
  • The physical interfaces and the PortChannel ID (e.g., channel-group 20) must be identical on both Nexus switches for the same downstream device.
  • The LACP mode must be active for both the Nexus pair and the downstream device for dynamic PortChannel negotiation. Static PortChannels (mode on) are generally not recommended with vPC.
  • switchport trunk allowed vlan lists must be identical on both vPC peers for a given vPC member PortChannel. Discrepancies cause Type-1 consistency errors.
  • spanning-tree port type normal is standard for server or access switch connections. If connecting to another network device that runs STP, consider spanning-tree port type network.

Verification Steps

After configuration, thorough verification is essential to ensure vPC is operational and stable.

! Displays a concise summary of vPC status, roles, and consistency
show vpc brief

! Detailed consistency checks, critical for identifying misconfigurations
show vpc consistency-parameters global
show vpc consistency-parameters interface port-channel 20

! Show the vPC role of the local switch (primary/secondary)
show vpc role

! Show the status of the peer-keepalive link
show vpc peer-keepalive

! Verify PortChannel status, including member links
show port-channel summary
show port-channel database interface port-channel 20

The show vpc brief command should indicate "vPC Peer-link status: up" and "vPC status: up" for all configured vPC member PortChannels. The show vpc consistency-parameters global and show vpc consistency-parameters interface commands are crucial for identifying any configuration mismatches between the two vPC peers that could lead to unexpected behavior or traffic loss. Look for "Type 1 consistency" messages, which usually mean a vPC member port is suspended.

Common Pitfalls and Troubleshooting

  • Type-1 Consistency Failures: These are the most common issues. They occur when critical parameters (VLANs allowed on peer-link or member ports, STP mode, LACP timers) do not match between vPC peers. Use show vpc consistency-parameters global and show vpc consistency-parameters interface to pinpoint the exact mismatch. Member ports involved in a Type-1 inconsistency are typically suspended.
  • Peer-Link Failure: If the peer-link goes down, the secondary vPC peer will typically shut down its vPC member ports unless auto-recovery is configured and sufficient time has passed. The primary peer will keep its vPC member ports up. This is a deliberate design to prevent split-brain scenarios. Verify the physical interfaces and the PortChannel status forming the peer link.
  • Peer-Keepalive Failure: If the peer-keepalive link fails, but the peer-link is still up, vPC functionality remains. However, if the peer-link then fails, the vPC peers might incorrectly assume the other is down, leading to both peers keeping their vPC member ports up (split-brain). Ensure the peer-keepalive path is independent and stable.
  • VLAN Mismatches: All VLANs allowed on any vPC member port must also be allowed on the vPC peer link. If a VLAN is missing on the peer link, traffic for that VLAN cannot traverse between peers, leading to blackholing.
  • STP Issues with peer-switch: While peer-switch greatly simplifies STP with vPC, ensure that STP global parameters (mode, root bridge priority) are consistent. Different STP configurations can still lead to problems.
  • Orphan Port Traffic Blackholing: Devices single-homed to one vPC peer are "orphan ports." If traffic from an orphan port needs to reach a device on the other peer via the peer-link, and that peer's link to the destination is down, traffic might blackhole. This is an inherent limitation and design consideration for orphan ports.

Back to the knowledge base · Ask the AI assistant