Non-Reverse Path Forwarding Traffic - Cisco Catalyst 4500 Series Configuration Manual

About IP Multicast

Non-Reverse Path Forwarding Traffic

Traffic that fails an Reverse Path Forwarding (RPF) check is called non-RPF traffic. Non-RPF traffic is
forwarded by the integrated switching engine by filtering (persistently dropping) or rate limiting the
non-RPF traffic.
In a redundant configuration where multiple Layer 3 switches or routers connect to the same LAN
segment, only one device forwards the multicast traffic from the source to the receivers on the outgoing
interfaces.
Figure 35-6
Multicast Traffic
Non-RPF Traffic
In this kind of topology, only Router A, the PIM designated router (PIM DR), forwards data to the
common VLAN. Router B receives the forwarded multicast traffic, but must drop this traffic because it
has arrived on the wrong interface and fails the RPF check. Traffic that fails the RPF check is called
non-RPF traffic.
Multicast Fast Drop
In IP multicast protocols, such as PIM-SM and PIM-DM, every (S,G) or (*,G) route has an incoming
interface associated with it. This interface is referred to as the reverse path forwarding interface. In some
cases, when a packet arrives on an interface other than the expected RPF interface, the packet must be
forwarded to the CPU subsystem software to allow PIM to perform special protocol processing on the
packet. One example of this special protocol processing that PIM performs is the PIM Assert protocol.
By default, the integrated switching engine hardware sends all packets that arrive on a non-RPF interface
to the CPU subsystem software. However, processing in software is not necessary in many cases, because
these non-RPF packets are often not needed by the multicast routing protocols. The problem is that if no
action is taken, the non-RPF packets that are sent to the software can overwhelm the CPU.
Prior to Release IOS XE 3.3.0SG and IOS 15.1(1)SG, to prevent this situation from happening, the CPU
subsystem software would load fast-drop entries in the hardware when it receives an RPF failed packet
that is not needed by the PIM protocols running on the switch. Any packet matching a fast-drop entry
would be bridged in the ingress VLAN, but is not sent to the software so the CPU subsystem is not
overloaded by processing these RPF failures unnecessarily. However, this process involved maintaining
fast-drop entries in hardware. Because the FLCAM space is limited, the number of fast-drop entries
installed in hardware was also limited.
Software Configuration Guide—Release IOS XE 3.3.0SG and IOS 15.1(1)SG
35-10
Figure 35-6 shows how non-RPF traffic can occur in a common network configuration.
Redundant Multicast Router Configuration in a Stub Network
Router A Router B
Network A
Network B
Chapter 35 Configuring IP Multicast
OL-25340-01