Tag Archives: nexus

CCIE DC – 1.1.a Link Aggregation – Virtual Port Channel Example

This post examines a sample configuration of a virtual port channel. This port channel is created between two Nexus 7K systems and downstream Nexus 5K systems. This is part of the link aggregation section of the exam requirements in CCIE Data Center. Below is the diagram you can use for reference in this example. We will only demonstrate the config of a single VPC peer since the other peer is simply a mirror of this configuration.

Virtual Port Channel

Our previous post on this subject focused on the configuration steps. You can find it here: https://www.ajsnetworking.com/ccie-dc-1-1-a-link-aggregation-configure-virtual-port-channels/

The Configuration

First, we will prepare the vPC keepalive link for this scenario. Do not be thrown off by the name of our VRF. This configuration does not technically fall under the vPC config (yet!).

N7K-A# configure terminal
N7K-A(config)#  vrf context VPC-KEEPALIVE
N7K-A(config-vrf)# interface ethernet 3/18
N7K-A(config-if)# no switchport
N7K-A(config-if)# vrf member VPC-KEEPALIVE
Warning: Deleted all L3 config on interface Ethernet3/18
N7K-A(config-if)# ip addr

Next, we will configure the vPC domain (after enabling the feature of course) and configure the peer-keepalive link we prepped.

N7K-A(config)# feature vpc
N7K-A(config)# vpc domain 10
N7K-A(config-vpc-domain)# peer-keepalive destination source vrf VPC-KEEPALIVE

Now, we configure a port channel between our vPC peers and configure it as the vPC peer link.

N7K-A(config-vpc-domain)# interface ethernet 3/16-17
N7K-A(config-if)# channel-group 10
N7K-A(config-if)# interface port-channel 10
N7K-A(config-if)# vpc peer-link

Next, we will head down to the N5K and configure a “plain ole” LACP port channel.

N5K-A# config t
N5K-A(config)# feature lacp
N5K-A(config)# int e 1/1-2
N5K-A(config-if-range)# channel-group 201 mode active

Now, it is time to configure the vPC on the N7K.

N7K-A(config-if)# feature lacp
N7K-A(config)# interface e 3/21
N7K-A(config-if)# channel-group 201 mode active
N7K-A(config-if)# int port-channel 201
N7K-A(config-if)# vpc 201

The Verification

You should note that you can and should perform verifications as you go along here. For example, you can verify reachability, check the port channels that are configured, and watch the progress of the vPC as you configure it. For brevity here, we will just end this post and this example with our critical show vpc command.

N7K-A(config-if)# show vpc brief
     (*) - local vPC is down, forwarding via vPC peer-link

vPC domain id                          : 10
Peer status                            : peer adjacency formed ok
vPC keep-alive status                  : peer is alive
Configuration consistency status       : success
Per-vlan consistency status            : success
Type-2 consistency status              : success
vPC role                               : secondary
Number of vPCs configured              : 1
Peer Gateway                           : Disabled
Dual-active excluded VLANs and BDs     : -
Graceful Consistency Check             : Enabled
Auto-recovery status                   : Enabled (timeout = 240 seconds)
Operational Layer3 Peer-router         : Disabled
Self-isolation                         : Disabled

vPC Peer-link status
id Port Status  Active vlans Active BDs
-- ---- ------ -------------------------------------------------------------
1  Po10 up      1,12 -

vPC status
id     Port        Status Consistency  Active VLANs
----- ------------ ------ ----------- ----------------
201    Po201       up      success     1,12

For even more information – check out this Cisco documentation at https://www.cisco.com/c/en/us/products/collateral/switches/nexus-5000-series-switches/design_guide_c07-625857.html
Pearson Education (InformIT)

CCIE DC Written – 1.1.a Link Aggregation – vPC Data Plane


Here is an important question about the data plane with your vPC. Is the vPC peer link (typically an EtherChannel) between your vPC peer switches used for forwarding data traffic? In a “normal” network condition, the answer is no. The vPC peer link is not used for the data traffic of the vPC and is considered to be an extension of the control plane between the vPC peer switches. The vPC peer link carries the following type of traffic:

  • vPC control traffic, such as Cisco FSoE, BPDUs, and LACP messages
  • Flooding traffic, such as broadcast, multicast, and unknown unicast traffic
  • Traffic from orphan ports

So we note that the peer link is used specifically for switch management traffic and occasionally for the data packets from failed network ports. This behavior of our vPCs enables the solution to scale because the bandwidth requirement for the vPC peer link is not directly related to the total bandwidth of all vPC ports.

What about loop prevention? One of the most important forwarding rules for a vPC is exactly about that as I have shown in the illustration above. Note this sample traffic flow:

  1. A packet enters the vPC peer switch via a vPC member port.
  2. The packet then goes to the other peer switch via the peer link
  3. The packet is then not allowed to exit the switch on the vPC member port.
  4. This packet can exit on any other type of port, such as an L3 port or an orphan port.

This rule prevents the packets that are received on a vPC from being flooded back onto the same vPC by the other peer switch.

What about this traffic from orphan ports? Understand there are two types of orphan ports for this discussion:

  • The first type of orphan port is the one that is connected to an orphan device and is not part of any vPC configuration. For this type of orphan port, normal switch forwarding rules are applied. The traffic for this type of orphan port can use a vPC peer link as a transit link to reach the devices on the other vPC peer switch.
  • The second type of orphan port is the one that is a member of a vPC configuration, but the other peer switch has lost all the associated vPC member ports. For this type of orphan port, the vPC loop avoidance rule is disabled. In this special case, the vPC peer switch will be allowed to forward the traffic that is received on the peer link to one of the remaining active vPC member ports.

CFSoE is used to synchronize the Layer 2 forwarding tables between the vPC peer switches. Therefore, there is no dependency on the regular MAC address learning between the vPC peer switches. CFSoE-based MAC address learning is applicable only to the vPC ports. This method of learning is not used for the ports that are not part of the vPC configuration.