Multicast Tunnel RPF Failure

Multicast Tunnel RPF Failure

If you want to run multicast between two routers that are connected through a network that doesn’t support multicast then a common solution is to use a GRE tunnel to transmit your multicast traffic. If you use the GRE tunnel only for multicast traffic, you will run into an RPF (Reverse Path Forwarding) problem. This lesson explains how to configure PIM sparse or dense mode on your GRE tunnel and how to fix your RPF problem.

Configuration

Here is the topology we will use:

Multicast Tunnel Rpf Failure Topology Example

R1 and R2 are our multicast routers and connected to an ISP router. We use a default route on R1 and R2 and some static routes on the ISP router so that we have full connectivity. Since the ISP doesn’t support multicast, we use a GRE tunnel between these routers to send multicast traffic from our source (S1) to the receiver (H1).

  • Configurations
  • S1
  • R1
  • ISP
  • R2
  • H1

Want to take a look for yourself? Here you will find the startup configuration of each device.

First, we need to enable multicast routing on both routers:

R1 & R2
(config)#ip multicast-routing

Let’s create the tunnel interfaces. Here’s R1:

R1(config)#interface Tunnel 0
R1(config-if)#ip address 192.168.12.1 255.255.255.0
R1(config-if)#tunnel source 192.168.13.1 
R1(config-if)#tunnel destination 192.168.23.2

And R2:

R2(config)#interface Tunnel 0
R2(config-if)#ip address 192.168.12.2 255.255.255.0
R2(config-if)#tunnel source 192.168.23.2
R2(config-if)#tunnel destination 192.168.13.1

Dense Mode

Let’s start with PIM dense mode. We need to enable this on the GigabitEthernet 0/1 and Tunnel interfaces:

R1(config)#interface GigabitEthernet 0/1
R1(config-if)#ip pim dense-mode
R1(config)#interface Tunnel 0
R1(config-if)#ip pim dense-mode

Here’s R2:

R2(config)#interface GigabitEthernet 0/1
R2(config-if)#ip pim dense-mode
R2(config)#interface Tunnel 0
R2(config-if)#ip pim dense-mode

To test our setup, I’ll let our receiver join a multicast group:

H1(config)#interface GigabitEthernet 0/1
H1(config-if)#ip igmp join-group 239.1.1.1

Let’s try a quick ping:

S1#ping 239.1.1.1 repeat 5000
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
.....

These pings will fail. Why? Let’s take a look at the multicast routing table. Here’s R1:

R1#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, 
       Z - Multicast Tunnel, z - MDT-data group sender, 
       Y - Joined MDT-data group, y - Sending to MDT-data group, 
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute, 
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, 
       Q - Received BGP S-A Route, q - Sent BGP S-A Route, 
       V - RD & Vector, v - Vector, p - PIM Joins on route, 
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:00:04/stopped, RP 0.0.0.0, flags: D
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Tunnel0, Forward/Dense, 00:00:04/stopped

(192.168.1.101, 239.1.1.1), 00:00:04/00:02:55, flags: T
  Incoming interface: GigabitEthernet0/1, RPF nbr 0.0.0.0
  Outgoing interface list:
    Tunnel0, Forward/Dense, 00:00:04/stopped

Above you can see that R1 is receiving the multicast traffic and is forwarding it on the tunnel interface. Let’s check R2:

R2#show ip mroute 239.1.1.1

(*, 239.1.1.1), 00:05:20/stopped, RP 0.0.0.0, flags: DC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet0/1, Forward/Dense, 00:05:20/stopped
    Tunnel0, Forward/Dense, 00:05:20/stopped

(192.168.1.101, 239.1.1.1), 00:00:41/00:02:18, flags: 
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Tunnel0, Forward/Dense, 00:00:41/stopped
    GigabitEthernet0/1, Forward/Dense, 00:00:41/stopped

We see an entry on R2 but the incoming interface is “Null”. We know that R1 is forwarding the traffic so that’s a good indication that we have an RPF failure. There’s one quick command we can use to check if we are receiving traffic:

R2#show ip mroute count 
Use "show ip mfib count" to get better response time for a large number of mroutes.

IP Multicast Statistics
3 routes using 1946 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 239.1.1.1, Source count: 1, Packets forwarded: 0, Packets received: 18
  Source: 192.168.1.101/32, Forwarding: 0/0/0/0, Other: 18/18/0

Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0

Above, you see that we are actually receiving multicast packets. This is a good indication that we have an RPF failure. If you want to see that the router is actually dropping multicast packets, we’ll have to enable a debug. There’s a different method, depending if you use IOS 12.4 or IOS 15:

IOS 12.4

You need to use the debug ip mpacket command and disable the mroute-cache:

R2#debug ip mpacket
IP multicast packets debugging is on

R2(config-if)#no ip mroute-cache

IOS 15

On IOS 15, it’s simpler. There is a single command to debug multicast packets:

R2#debug ip mfib pak    
MFIB IPv4 pak debugging enabled for default IPv4 table

Once this is enabled, you will see a message like this:

R2#
MFIBv4(0x0): Pkt (192.168.1.101,239.1.1.1) from Tunnel0 (FS) Acceptance check failed - dropping

This is a nice and clear message telling us that traffic from 192.168.1.101 fails the RPF check. We can also verify this with the show ip rpf command:

R2#show ip rpf 192.168.1.101
 failed, no route exists

In our scenario, we use a default route towards the ISP router so our unicast routing doesn’t match our multicast routing. We can fix this with a static mroute for our source:

R2(config)#ip mroute 192.168.1.0 255.255.255.0 192.168.12.1

Let’s look at the show ip rpf command again:

R2#show ip rpf 192.168.1.101
RPF information for ? (192.168.1.101)
  RPF interface: Tunnel0
  RPF neighbor: ? (192.168.12.1)
  RPF route/mask: 192.168.1.0/24
  RPF type: multicast (static)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base

We now see an entry for our source. Let’s try those pings again:

S1#ping 239.1.1.1 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 192.168.2.101, 8 ms
Reply to request 1 from 192.168.2.101, 8 ms
Reply to request 2 from 192.168.2.101, 8 ms
Reply to request 3 from 192.168.2.101, 11 ms
Reply to request 4 from 192.168.2.101, 11 ms

Excellent, this is working.

  • Configurations
  • S1
  • R1
  • ISP
  • R2
  • H1

Want to take a look for yourself? Here you will find the startup configuration of each device.

Sparse Mode

Now let’s try sparse mode. I’ll need to change the PIM mode and configure an RP. Let’s use the loopback interface of R1 as the RP address. Let’s enable PIM sparse mode on R1:

R1(config)#interface GigabitEthernet 0/1
R1(config-if)#ip pim sparse-mode

R1(config)#int Tunnel 0
R1(config-if)#ip pim sparse-mode

R1(config)#int Loopback 0
R1(config-if)#ip pim sparse-mode

And configure the RP address:

R1(config)#ip pim rp-address 1.1.1.1

Let’s do the same thing on R2:

R2(config)#interface GigabitEthernet 0/1
R2(config-if)#ip pim sparse-mode 

R2(config)#interface Tunnel 0
R2(config-if)#ip pim sparse-mode 

R2(config)#ip pim rp-address 1.1.1.1

To test our setup, let’s configure our receiver to join another multicast group:

H1(config)#interface GigabitEthernet 0/1
H1(config-if)#ip igmp join-group 239.2.2.2

And we’ll send some pings…

S1#ping 239.1.1.1 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
.....

Our pings are failing, even though I do have a static mroute for our source (192.168.1.101). Let’s take a closer look at the multicast routing table:

R1#show ip mroute 239.2.2.2

(*, 239.2.2.2), 00:00:09/stopped, RP 1.1.1.1, flags: SPF
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(192.168.1.101, 239.2.2.2), 00:00:09/00:02:50, flags: PFT
  Incoming interface: GigabitEthernet0/1, RPF nbr 0.0.0.0
  Outgoing interface list: Null

R1 doesn’t have any outgoing interfaces. Let’s check R2:

R2#show ip mroute 239.2.2.2

(*, 239.2.2.2), 00:05:33/00:02:14, RP 1.1.1.1, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet0/1, Forward/Sparse, 00:01:05/00:02:14

R1 doesn’t have any incoming interfaces. If you left the debug enabled, you’ll see an RPF failure message. With sparse mode, you also need a successful RPF check for the RP address:

R2#show ip rpf 1.1.1.1
 failed, no route exists

Which we don’t have…to fix this, we’ll need to add another static multicast route:

R2(config)#ip mroute 1.1.1.1 255.255.255.255 192.168.12.1

Now take another look at the show ip rpf command:

R2#show ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
  RPF interface: Tunnel0
  RPF neighbor: ? (192.168.12.1)
  RPF route/mask: 1.1.1.1/32
  RPF type: multicast (static)
  Doing distance-preferred lookups across tables
  RPF topology: ipv4 multicast base

This is looking good. Let’s try another ping:

S1#ping 239.2.2.2 repeat 5    
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.2.2.2, timeout is 2 seconds:

Reply to request 0 from 192.168.2.101, 11 ms
Reply to request 1 from 192.168.2.101, 10 ms
Reply to request 2 from 192.168.2.101, 10 ms
Reply to request 3 from 192.168.2.101, 13 ms
Reply to request 4 from 192.168.2.101, 13 ms

Want to take a look for yourself? Here you will find the final configuration of each device.

Conclusion

You have now learned how to solve multicast RPF issues for tunnel interfaces. If you want to use a GRE tunnel only for multicast traffic, then you need to make sure that:

  • You have a matching static multicast route for dense mode traffic for your (S,G) entries.
  • You have a matching static multicast route for sparse mode traffic for your (S,G) but also one for your (*,G) entries to the RP.

Table of Content

Unit 1. Introduction to Multicast

Unit 2: IGMP (Internet Group Management Protocol)

Unit 3: Multicast L2

Unit 4: Multicast L3

Unit 5:  IPv6 Multicast