Multicast RPF (Reverse Path Forwarding)

One of the key differences between unicast and multicast is that for unicast routing we only care about where the destination is located and how to get there. For multicast routing we care about where the source is located. PIM (Protocol Independent Multicast) uses the unicast routing table to check what interface will be used to reach the source.

PIM will only accept multicast packets on an interface that we use to reach the source. If we receive multicast packets on an interface that we don’t use to reach the source, we will drop the multicast packets! This is called a RPF failure and it’s the #1 issues why multicast isn’t working for many networking students.

Let me demonstrate this using a very simple topology:

pim-rp-rpf-failure-data-plane

Above you see 3 routers. R1 will be the source for our multicast traffic. Between R2 and R3 we have two links…a slow serial link and a FastEthernet link. R3 has a loopback interface that we will use as the receiver for our multicast traffic. First we will enable OSPF on all interfaces to have basic connectivity:

R1(config)#router ospf 1
R1(config-router)#network 0.0.0.0 255.255.255.255 area 0
R2(config)#router ospf 1
R2(config-router)#network 0.0.0.0 255.255.255.255 area 0
R3(config)#router ospf 1
R3(config-router)#network 0.0.0.0 255.255.255.255 area 0

I will enable OSPF on all interfaces quickly using the network command above. OSPF will prefer to use the FastEthernet link and won’t use the serial link:

R2#show ip route ospf 
     3.0.0.0/32 is subnetted, 1 subnets
O       3.3.3.3 [110/11] via 192.168.23.3, 00:00:02, FastEthernet0/1

As you can see we don’t use the serial link because the FastEthernet link has a lower cost. Now i’m going to configure multicast on all routers but I will only activate it on the serial link between R2 and R3:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 662 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

515 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags:


Forum Replies

  1. Lovely… Nice and neat

  2. Hi Rene,

    What if the cost of both (FastEthernet and Serial links) are the same. In this scenario, there will be ECMP towards the source. Here, there will be both the entries in the unicast routing table. Now, even if the multicast traffic comes on the serial link, RPF check will still pass, is that right?

    Thanks.

  3. Hi Parth,

    RPF will pass but not for both links. By default, the RPF check will be done for the neighbor with the highest IP address. This means that by default, ECMP multicast load balancing is disabled.

    For example, let’s say there are two routers…R1 and R2. Between R1 and R2 we use two interfaces. These interfaces have the same metric in whatever IGP we are using. Let’s say R1 has IP address 192.168.12.1 and 192.168.21.1 on these interfaces.

    R2 will then send the PIM join to the highest IP address PIM neighbor, 192.168.21.1. That’s the interface that will be

    ... Continue reading in our forum

  4. Hi Rene,

    is this correct? i think its a mistake, its should as in the output of the command 192.168.32.2 not 192.168.23.2…

    (192.168.12.1, 239.1.1.1), 00:04:42/00:02:59, flags: LT
      Incoming interface: Serial0/0, RPF nbr **192.168.32.2**, Mroute
      Outgoing interface list:
        Loopback0, Forward/Dense, 00:04:42/00:00:00
    

    See the RPF neighbor above? It now says 192.168.23.2 which is the IP address on the serial link of R2. As a result, our multicast traffic is now being accepted:

  5. Hello Samer

    You are correct. The text should read:

    See the RPF neighbor above? It now says 192.168.32.2 which is the IP address on the serial link of R2. As a result, our multicast traffic is now being accepted:

    I will let @ReneMolenaar know.

    Thanks again!

    Laz

17 more replies! Ask a question or join the discussion by visiting our Community Forum