Cisco Cisco Dynamic Fabric Automation for OpenStack Troubleshooting Guide

Cisco Dynamic Fabric Automation Production Troubleshooting Guide 
 

 

 

4.  Both border leaf switches having the Layer-3 core VLAN added to the OIF is a result of LHR acorn3 hash selecting 

two different RPF neighbors for the (*,G) and (S,G). As a result of both border leaf switches having the OIF, we 
need to elect the fabric forwarder. If acorn3 had chosen the same RPF neighbor for the (*,G) and (S,G), then the 

end result would be that only that border leaf switch chosen for both would have an OIF. Thus no border leaf 

switch would be marked as the fabric forwarder loser since only one border leaf switch has the OIF, and there is 

no possibility of both border leaf switches forwarding into the fabric.  

 

To summarize the two possible scenarios: 

(1)  Both border leaf switches will have OIF, and one is denoted as fabric forwarder loser when different border 

leaf switches are chosen as (*,G) and (S,G) RPF neighbor by the LHR hash.  

(2)  Only one border leaf switch has the OIF. This is when the same border leaf switch is chosen as (*,G) and (S,G) 

RPF neighbor by the LHR hash.  

 

You have now successfully verified fabric forwarder election with redundant border leaf switches and a source outside 
of the fabric. The commands above can be used to isolate a problem if troubleshooting is required.  

 

5.1.4  vPC+ 

In vPC+ implementations within the fabric, it is always important to understand which peer is responsible for FHR 
source registration, sending BGP joins, and forwarding the traffic when we have sources and/or receivers behind a 
vPC or orphan interface. With vPC+ inside the fabric, we do not have a concept of Designated Router source registra-
tion. If a source is behind a vPC interface, then whichever peer receives the traffic (due to the downstream devices 
channel hash) will then be the device that does the FHR source registration. In Cisco Nexus 5000 and 6000 Series 
switches vPC+ scenarios, the multicast data traffic, or IGMP control packet is not forwarded across the vPC+ peer-link 
(this is different than Cisco Nexus 7000 Series switch implementations, where the data traffic and IGMP packets are 
forwarded across the peer link). Therefore, in cases where a receiver is behind a vPC, then whichever switch receives 
the join will synchronize this information to its peer using Cisco Fabric Services (CFS) messages. Both vPC+ peers will 
have this join information and forward the appropriate BGP Join messages upstream. Though both devices will send a 
BGP Join to pull the traffic to the vPC+, only one of them will forward the packets to a receiver connected to a vPC so 
that we prevent duplicates. Details on how this is determined are explained in the Multicast Data-Plane Forwarding 
section

. 

If a join is received from an orphan port, then there will be no synchronizing of information between peers.  

Let’s look at both scenarios: (1) A receiver behind vPC+ and (2) A source behind vPC+. 

In this example, we will focus on how an IGMP Join for 225.1.23.111 on VLAN 111 / VNI-16100 is handled once re-
ceived on a vPC interface.  
The vPC+ pair is made up of acorn1 and acorn2, (with an emulated Switch-ID of 501). We will not go into forwarding 
the join through the fabric, as that was covered in detail in the BGP Join Creation and Propagation section

.