Руководство По Проектированию для Cisco Cisco Nexus 5010 Switch

Скачать
Страница из 38
 
 
Design Guide 
© 2010 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. 
Page 13 of 38 
 
                  s - Supports-STP-Dispute 
 
Device-ID             Local Intrfce Hldtme Capability  Platform      Port ID 
 
tc-nexus7k01-vdc2(TBM12162254)Eth2/1    158    R S I s   N7K-C7010     Eth2/9      
tc-nexus7k02-vdc2(TBM12193229)Eth2/2    158    R S I s   N7K-C7010     Eth2/9    
Cisco Fabric Services over Ethernet Synchronization Protocol 
The vPC peers use the Cisco Fabric Services protocol to synchronize forwarding-plane information and implement 
necessary configuration checks. 
vPC peers must syncrhonize the Layer 2 forwarding table - that is, the MAC address information between the vPC 
peers. This way, if one vPC peer learns a new MAC address, that MAC address is also programmed on the Layer 2 
forwarding table of the other peer device. 
The Cisco Fabric Services protocol travels on the peer link and does not require any configuration by the user. 
To help ensure that the peer link communication for the Cisco Fabric Services over Ethernet protocol is always 
available, spanning tree has been modified to keep the peer-link ports always forwarding. 
The Cisco Fabric Services over Ethernet protocol is also used to perform compatibility checks to validate the 
compatibility of vPC member ports to form the channel, to synchronize the IGMP snooping status, to monitor the 
status of the vPC member ports, to synchronize the Address Resolution Protocol (ARP) table (starting from Cisco 
NX-OS 4.2(6) and future Release 5.0 releases). 
If the peer link is disconnected between two vPC peers, the synchronization between vPC peers is interrupted, which 
may lead to traffic drop for multicast traffic and to flooding for unicast traffic. 
vPC Configuration Changes When the Peer Link Fails 
The correct sequence for setting up vPCs requires that the two participating vPC switches see each other over the 
peer link and that they can communicate over the vPC peer keepalive link. 
Figure 9 illustrates this fundamental concept: the configuration depicted in Figure 9 (2) requires starting from Figure 9 
(1). If you try to configure a vPC like in Figure 9 (2) without having established vPC peer-link and vPC peer keepalive 
connectivity, vPC ports won’t go into forwarding state. 
Once you are in the state depicted in Figure 9 (1) (which is a fully formed vpc domain) the peer keepalive connectivity 
is not strictly required in order to create or modify vPCs. In other words, you can configure the vPC in Figure 9 (2) 
even if there’s a loss of vPC peer keepalive connectivity after the configuration depicted in Figure 9 (1). 
It is necessary and recommended to have functional vPC peer keepalive connectivity for the correct behavior of vPC 
in presence of failures, but from a traffic forwarding and configuration purpose, the temporary failure of the peer 
keepalive link doesn’t have any impact. 
The vPC peer-link connectivity is more important for the correct traffic forwarding operations as well as for the ability 
to create or modify vPCs.