Cisco Cisco Nexus 5010 Switch Guida Alla Progettazione

 

Design Guide 

 

© 2010 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information. 

Page 20 of 28

 

As you can see, the vPCs are kept up on both systems, and they are recognized as valid PortChannels from the 
access layer device: 

51    Po51(SU)    Eth      LACP      Eth2/1(P)    Eth2/2(P)   

While not intuitive, if both the vPC peer link and Peer Keepalive link fail, it is still possible and desirable to continue 
forwarding traffic from the access layer to the aggregation layer without drops for existing traffic flows, provided that 
the Address Resolution Protocol (ARP) tables are already populated on both Cisco Nexus 7000 Series peers for all 
needed hosts. 

If new MAC addresses are to be learned by the ARP table, issues may arise because the ARP response from the 
server may always be hashed to one Cisco Nexus 7000 Series device and not the other, making it impossible for the 
traffic to flow correctly. 

Suppose, however, that before the failure in the situation just described, traffic was equally distributed to both Cisco 
Nexus 7000 Series by a correct PortChannel and by Equal Cost Multipath (ECMP) configuration. In that case, server-
to-server and client-to-server traffic continues with the caveat that single-attached hosts connected directly to the 
Cisco Nexus 7000 Series will not be able to communicate (for the lack of the peer link). Also, new MAC addresses 
learned on one Cisco Nexus 7000 Series cannot be learned on the peer, as this would cause flooding for the return 
traffic that arrives on the peer Cisco Nexus 7000 Series device. 

First, vPC needs to be enabled: 

agg(config)# feature vpc 

A domain needs to be defined (as indicated by the domain-id) as well as priorities to define primary and secondary 

in the vPC configuration. The lower number has higher priority, so it wins. For two switches (vPC peers) to 

form a vPC system, the domain-id of these switches need to match. As previously described, the domain-id is used to 
generate the LAGID in the LACP negotiation. 

agg1(config)# vpc domain <domain-id> 

 

agg1(config-vpc-domain)# role priority 100 

 

agg2(config)# vpc domain <domain-id – same as agg1> 

 

agg2(config-vpc-domain)# role priority 110 

It should also be noted that the role is nonpreemptive, so a device may be operationally primary but secondary from 
a configuration perspective. Because spanning tree is preemptive, this may result in a mismatch between the 
spanning tree root and the vPC operational primary device with no consequences to traffic forwarding. 

While mismatched Spanning-Tree and vPC priorities do not any impact on traffic forwarding, it is still desirable to 
keep the priorities matched so as to have Spanning-Tree root and vPC primary on the same device and Spanning-
Tree secondary root and vPC secondary on the same device. The main benefit is easier management. 

In case after failovers the vPC operational primary and vPC operational secondary do not match the original 
configuration, you can restore it following these easy configuration steps: 

From the vPC operational primary you can change the role priority to the highest value 32768, then do a shut/no shut 
on the peer-link PortChannel.