Cisco Cisco Dynamic Fabric Automation for OpenStack Guide De Dépannage
Cisco Dynamic Fabric Automation Production Troubleshooting Guide
72
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
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.
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
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+.
Scenario 1: Receiver 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
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
.
High-level Overview for Receiver behind vPC+