PDF(92.7 KB) View with Adobe Reader on a variety of devices
Updated:January 17, 2014
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes how to determine which interface to use for the Reverse Path Forwarding (RPF) check with an Emulated Switch-ID (ESID).
Cisco recommends that you have knowledge of basic FabricPath terminology and concepts. Specifically, users should be familiar with Forwarding Tags (FTAGs) and how they are used. For more information on FTAGs, see Mapping Out the Multidestination Tree for a FTAG.
Note: The terms FTAG, Trees, and FTAG Trees are used interchangeably in this document. At the time this document was written, only FTAG1 and FTAG2 have been implemented. There might be additional FTAGs in the future.
The information in this document is based on the Nexus 7000. Some commands might vary on other Nexus platforms, but the concepts will remain the same.
Note: This is only a partial topology. There is another Spine1 connected to Spine2 and both Leaf1 and Leaf2, but it is excluded from this document for simplicity. Spine1 is the root for FTAG1 and Spine2 is the root for FTAG2.
In a FabricPath domain, each switch is identified by a switch-ID (SID). In the case of a Virtual Port Channel+ (vPC+) setup, each peer switch has two SIDs. One for the physical switch and one for the logical switch that is formed by vPC+. The logical SID is shared on both peers and is known as an ESID.
When a multidestination packet is received on a vPC+ interface and forwarded into the FabricPath domain, the packet is encapsulated with a FabricPath header and the source SID is set to the ESID. Once this packet is received on a FabricPath core port, an RPF check is performed in order to ensure the packet was received on the correct interface. In short, the RPF check cross references the source SID and FTAG of the packet to the interface it was received on. If it was not received on the RPF interface, the packet fails the RPF check and is dropped.
RPF checks only come into play for multidestination packets which include unknown unicast, multicast, and broadcast packets. RPF checks are not performed on unicast packets because they can come in multiple interfaces with Equal-Cost Multi-Pathing. Multidestination packets should only come in one interface per source SID based on the FTAG tree.
In this document, the RPF check for an ESID is investigated. An ESID represents a vPC+ domain. This means it is one logical switch that consists of two physical switches. If you consider the topology diagram, you will see that there are two physical links to one ESID which is typically the case. Remember, the RPF check only allows multidestination packets to be accepted in one interface based on the FTAG tree.
Step 1. Check the RPF State
In this example, Spine2 is the root for FTAG2. First, check Spine2 for the current RPF interface for the ESID 34 and FTAG2. There are two places to check the RPF status, which are in the software and in the hardware. Both outputs show that that Eth4/41 is the RPF interface for FTAG2, ESID 34.
In order to understand why Spine2 chose Eth4/41 to Leaf1 instead of Eth4/45 to Leaf2 when both are part of the ESID, you must first understand the concept of an affinity.
In a non-vPC+ setup, multidestination packets are primarily forwarded on the first tree in the topology, which is Tree1. In a vPC+ environment, each tree (FTAG1 or FTAG2) has an affinity for one or the other peer switch. In this situation, broadcast, unknown unicast, and non-IP multicast frames traverse the tree for which the particular peer switch has an affinity.
You need to check which peer has the affinity for FTAG2. In order to do this, log in to one of the leaf switches in the vPC+ domain. The check can be done from either peer switch because both should know their peer's affinity as well as their own.
Leaf1# show fabricpath isis database detail | i Affinity|Hostname|Nickname
With this information you can see that if a multidestination frame is received on Leaf1, the switch forwards it along the FTAG2 tree. If the frame is received on Leaf2, it is forwarded along the FTAG1 tree.