Reverse Path Forwarding - Multicast RPF

Multicast RPF

Multicast RPF, typically denoted simply as RPF, is used in conjunction with a multicast routing protocol such as MSDP and PIM-SM to ensure loop-free forwarding of multicast packets. In multicast routing, the decision to forward traffic is based upon source address and not on destination address as in unicast routing. It does this by utilizing either a dedicated multicast routing table or alternatively the router's unicast routing table.

When a multicast packet enters a router's interface, it will lookup the list of networks that are reachable via that interface i.e., it checks the reverse path of the packet. If the router finds a matching routing entry for the source IP of the multicast packet, the RPF check passes and the packet is forwarded to all other interfaces that are participating in multicast for that multicast group. If the RPF check fails the packet will be dropped. As a result, the forwarding of the packet is decided based upon the reverse path of the packet rather than the forward path. RPF routers only forward packets that come into the interface that also hold the routing entry for the source of the packet, thus breaking any loop.

This is critically important in redundant multicast topologies. Because the same multicast packet could reach the same router via multiple interfaces, RPF checking is integral in the decision to forward packets or not. If the router forwarded all packets that come in interface A to interface B and it also forwarded all packets coming in interface B to interface A and both interfaces receive the same packet, this will create a classic routing loop where packets will be forwarded in both directions until their IP TTLs expire. Even considering TTL expiry, all types of routing loops are best avoided as they involve at least temporary network degradation.

The underlying assumptions of RPF check are that:

• the unicast routing table must be correct and converged.
• the path used from a sender to a router and the reversed path from the router back to the sender are symmetric.

If the first assumption is not true, RPF check will fail because it depends upon the router's unicast routing table as a fallback. If the second assumption is not true, RPF check would reject multicast traffic on all but the shortest path from the sender to the router and would eventually lead to non-optimal multicast tree.

In cases where the links are uni-directional, the reverse path approach can fail altogether.