Multicast Reverse Path Forwarding (RPF)

IP multicast routing is a subject that many students struggle with and we cover this subject thoroughly in all of our training material. One of the things that is almost certain to give any student a headache is RPF failure. What is it and how do we deal with it? Before we can answer that question, let’s first examine what is RPF to begin with. Next couple of articles in this series will show different methods to recover from RPF failure.One of the fundamental rules of IP multicast routing is the rule that goes along these lines: Incoming multicast packet will not be accepted/forwarded unless it is received on an interface that is the outgoing interface for unicast route to the source of the packet.

This is the essence of Reverse Path Forwarding (RPF) verification performed on every multicast packet received by any router participating in IP multicast routing. In plain English, this means that IP multicast traffic will flow from its source to its destination on the same path, but in the opposite direction that unicast traffic from destination (client) will take to the source.

Old saying says that a picture speaks louder than a 1000 words. Examine the diagram below.

Imagine that R1 is the source of our multicast traffic and that R4 has joined a group. Which way will the multicast traffic flow? The easiest way to figure this out is to use “traceroute” command… from R4 to R1. before I dive into that, let me share with you the initial configuration of our network. All relevant configuration is below.

R1:

ip multicast-routing
!
interface Loopback0
 ip address 192.168.0.1 255.255.255.255
 ip pim sparse-mode
!
interface Serial1/0
 ip address 192.168.12.1 255.255.255.0
 ip pim sparse-mode
!
router ospf 1
 network 192.168.0.0 0.0.255.255 area 0
!

R2:

ip multicast-routing
!
interface Loopback0
 ip address 192.168.0.2 255.255.255.255
 ip pim sparse-mode
!
interface Serial1/0
 ip address 192.168.12.2 255.255.255.0
 ip pim sparse-mode
!
interface Serial1/1
 ip address 192.168.23.2 255.255.255.0
 ip pim sparse-mode
!
ip pim bsr-candidate Loopback0 0
ip pim rp-candidate Loopback0
!
router ospf 1
 network 192.168.0.0 0.0.255.255 area 0
!

R3:

ip multicast-routing
!
interface Loopback0
 ip address 192.168.0.3 255.255.255.255
 ip pim sparse-mode
!
interface Ethernet0/0
 ip address 192.168.43.3 255.255.255.0
 ip pim sparse-mode
 ip ospf network point-to-point
!
interface Serial1/0
 ip address 192.168.34.3 255.255.255.0
 ip pim sparse-mode
!
interface Serial1/1
 ip address 192.168.23.3 255.255.255.0
 ip pim sparse-mode
!
router ospf 1
 network 192.168.0.0 0.0.255.255 area 0
!

R4:

ip multicast-routing
!
interface Loopback0
 ip address 192.168.0.4 255.255.255.255
 ip pim sparse-mode
 ip igmp join-group 239.4.4.4
!
interface Ethernet0/0
 ip address 192.168.43.4 255.255.255.0
 ip pim sparse-mode
 ip ospf network point-to-point
!
interface Serial1/0
 ip address 192.168.34.4 255.255.255.0
 ip pim sparse-mode
!
router ospf 1
 network 192.168.0.0 0.0.255.255 area 0
!

This is very basic configuration to support IP multicast routing. Let’s see what I was talking about just earlier. If we examine the diagram, logic implies that IP multicast traffic from R1 to Loopback0 of R4 should take the following path:

1. R1 Serial1/0 to R2 Serial1/0
2. R2 Serial1/1 to R3 Serial1/1
3. R3 Ethernet0/0 to R4 Ethernet0/0

If I perform traceroute from R4, this is what I get.

R4:

R4#traceroute 192.168.0.1 source Loopback0

Type escape sequence to abort.
Tracing the route to 192.168.0.1

  1 192.168.43.3 0 msec 0 msec 0 msec
  2 192.168.23.2 12 msec 8 msec 8 msec
  3 192.168.12.1 16 msec *  16 msec

The output above is the exact opposite of the path multicast will take. To confirm that, I will use “mtrace” command from R1.

R1:

R1#mtrace 192.168.12.1 192.168.0.4 239.4.4.4
Type escape sequence to abort.
Mtrace from 192.168.12.1 to 192.168.0.4 via group 239.4.4.4
From source (?) to destination (?)
Querying full reverse path...
 0  192.168.0.4
-1  192.168.43.4 None  [192.168.12.0/24]
-2  192.168.43.3 None  [192.168.12.0/24]
-3  192.168.23.2 PIM Reached RP/Core [192.168.12.0/24]
-4  192.168.12.1 PIM Prune sent upstream [192.168.12.1/32]

The output should be read bottom-up. We can see that multicast traffic is indeed taking the path I predicted.

Sometimes, things may not be as simple as this. Next time we’ll explore what happens when we have RPF failure and how we can recover from it.

Happy studies!

–
Marko Milivojevic – CCIE # 18427
Senior Technical Instructor – IPexpert
Join our Online Study List

Multicast Reverse Path Forwarding (RPF), 4.6 out of 5 based on 9 ratings

Tags: CCIE, CCIE R&S, CCIE Security, CCIE Service Provider, multicast, RPF, RPF Failure