ip multicast (pim sparse mode) over gre tunnels

Hey everyone,
today I am going to show how the usage of GRE tunnels in combination with multicast (PIM sparse mode) works.

So here is the challenge and our topology:

What we have:
– we have 4 routers.
– each router has a loopback of its number, e.g. 1.1.1.1/32…2.2.2.2/32
– the topology is fully converged
– we are running PIM sparse mode
– R2 is the rendezvous-point
– R3 is NOT capable of multicast (at least we dont configure “ip multicast-routing”)
– R1 sends packets destined to the multicast-group 239.100.100.100
– R4 will be the multicast receiver

Challenge:
– R4 shall receive the packets
– As R3 is not running multicast, we need to think about a solution to overcome his

Solution:
– For this problem we can establish a GRE tunnel between R1 and R2 and then run multicast over it

First we need to have a look into the problem.
Here is the relevant config of the routers:

NOTE:
R1 has DR priority of “0” because when initiating a PIM register message the multicast source and the machine who sends the PIM register (the DR of a segment) cannot be the same. This does not work

R1:
!
hostname R1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet1/0
ip address 172.16.21.1 255.255.255.252
ip pim dr-priority 0
ip pim sparse-mode
ip ospf 1 area 0
duplex auto
speed auto
!
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
redistribute connected subnets metric-type 1
!
ip pim rp-address 2.2.2.2
!
ip multicast-routing
!

R2:
!
hostname R2
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet1/0
ip address 172.16.32.1 255.255.255.252
ip ospf 1 area 0
duplex auto
speed auto
!
interface FastEthernet1/1
ip address 172.16.21.2 255.255.255.252
ip pim sparse-mode
ip ospf 1 area 0
duplex auto
speed auto
!
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
redistribute connected subnets metric-type 1
!
ip pim rp-address 2.2.2.2
!
ip multicast-routing
!

R3:
!
hostname R3
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet1/1
ip address 172.16.32.2 255.255.255.252
ip ospf 1 area 0
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 172.16.43.2 255.255.255.252
ip ospf 1 area 0
duplex auto
speed auto
!
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
redistribute connected subnets metric-type 1
!

R4:
!
hostname R2
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface FastEthernet1/0
ip address 172.16.43.2 255.255.255.252
ip ospf 1 area 0
duplex auto
speed auto
!
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
redistribute connected metric-type 1
!
ip pim rp-address 2.2.2.2
!
ip multicast-routing
!

In R4 no Interface is running PIM at this point of time as there is no possible directly connected

neighbor.
So as PIM is a point to point protocol we need to establish a direct adjacency between R4 and R2 due to the inablility of R3 to handle PIM or even multicast packets.

Here is what we do:

R2:
R2(config)#int tun 0
R2(config-if)#
*Mar 8 12:23:52.127: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R2(config-if)#tunnel source lo0
R2(config-if)#tunnel dest 4.4.4.4
R2(config-if)#tunnel mode gre ip
*Mar 8 12:24:06.451: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R2(config-if)#ip address 10.10.10.2 255.255.255.0

R4:
R4(config)#int tun 0
R4(config-if)#
*Mar 8 12:25:01.707: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R4(config-if)#tunnel source lo0
R4(config-if)#tunnel dest 2.2.2.2
R4(config-if)#tunnel mode gre ip
*Mar 8 12:25:09.519: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
R4(config-if)#ip address 10.10.10.4 255.255.255.0

Then as multicast shall run over this direct link, we need to enable pim sparse mode on the tunnel interfaces.

R2:
R2(config)#int tun 0
R2(config-if)#ip pim sparse-mode

R4:
R4(config)#int tun 0
R4(config-if)#ip pim sparse-mode

You should then see the PIM adjacency:

R2:
R2#sh ip pim neigh
PIM Neighbor Table
Mode: B – Bidir Capable, DR – Designated Router, N – Default DR Priority,
S – State Refresh Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
172.16.21.1 FastEthernet1/1 00:45:43/00:01:19 v2 0 / S P
10.10.10.4 Tunnel0 00:01:20/00:01:22 v2 1 / S P

R4:
R4#sh ip pim neigh
PIM Neighbor Table
Mode: B – Bidir Capable, DR – Designated Router, N – Default DR Priority,
S – State Refresh Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
10.10.10.2 Tunnel0 00:01:41/00:01:31 v2 1 / S P

Ok so far so good we have our adjacency and now we want to try if R4 can get multicast traffic that is sourced by R1. First of all we will Generate a new loopback so that we have a dedicated interface only for the “ip igmp join-group” command.

R4:
R4(config)#int lo10
*Mar 8 12:29:43.927: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback10, changed state to up
R4(config-if)#ip address 4.4.4.100 255.255.255.255

Then lets start the multicast traffic on R1 and check the S,G entry in the RP.

R1:
R1#ping 239.100.100.100 so lo0 rep 1000

Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 239.100.100.100, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.

Check the mroute-table of the RP to if the PIM register has succeed.

R2:
R2#sh ip mroute
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,
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,
V – RD & Vector, v – Vector
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.100.100.100), 00:00:26/stopped, RP 2.2.2.2, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(1.1.1.1, 239.100.100.100), 00:00:26/00:02:33, flags: PT
Incoming interface: FastEthernet1/1, RPF nbr 172.16.21.1
Outgoing interface list: Null

(*, 224.0.1.40), 00:49:54/00:02:46, RP 2.2.2.2, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet1/1, Forward/Sparse, 00:49:54/00:02:46

Looks good. The source has been registered and the S,G and the *,G entry are in the table.
Now we will try to join the multicast-group.

R4:
R4(config)#int lo10
R4(config-if)#ip pim sparse-mode
R4(config-if)#ip i
*Mar 8 13:34:20.423: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 4.4.4.100 on interface Loopback10
R4(config-if)#ip igmp join-group 239.100.100.100
R4(config-if)#

Lets check to see if our router tries to get the stream:

R4#sh ip mroute
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,
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,
V – RD & Vector, v – Vector
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.100.100.100), 01:53:17/00:02:52, RP 2.2.2.2, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0, Mroute
Outgoing interface list:
Loopback10, Forward/Sparse, 00:00:35/00:02:52
Loopback0, Forward/Sparse, 01:53:17/00:02:42

(*, 224.0.1.40), 01:53:17/00:02:40, RP 2.2.2.2, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0, Mroute
Outgoing interface list:
Loopback0, Forward/Sparse, 01:53:17/00:02:40

Okay looks good the *,G entry is there. But there doesnt seem to be a s,G entry which says the the SPT has been built and the traffic flow. Further the ICMP packets of R1 are not reaching the reciever.

R1:
R1#ping 239.100.100.100 rep 1000

Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 239.100.100.100, timeout is 2 seconds:
…………………………………………….

So something must be wrong.
Lets do a “debug ip mpacket” and “debug ip pim” on R4! First we disable fastswitching and CEF on the interface to see every packet in the debug.

R4:
R4(config)#int fa1/0
R4(config-if)#no ip mroute-cache
R4(config-if)#no ip route-cache
R4(config-if)#int tun 0
R4(config-if)#no ip route-cache
R4(config-if)#no ip mroute-cache
R4#debug ip mpacket
IP multicast packets debugging is on
R4#debug ip pim
PIM debugging is on

We get this debug message:

*Mar 6 16:24:49.931: IP(0): s=1.1.1.1 (Tunnel0) d=239.100.100.100 id=433, ttl=253, prot=1, len=100(100), RPF lookup failed for source or RP

As we can see here, the RPF check has failed with the reason that the lookup has failed towards the RP or source. this means that the RP and/or the source cannot be reached via the same interface the multicast packets come in.
The multicast packets come in on interface “tunnel0” and the unicast routing table for the source and the RP says that those addresses can be reached via “Fa0/1” -> RPF check fails.

R4:
R4#sh ip rout
*Mar 8 14:01:20.207: %SYS-5-CONFIG_I: Configured from console by console
R4#sh ip route 2.2.2.2
Routing entry for 2.2.2.2/32
Known via “ospf 1”, distance 110, metric 22, type extern 1
Last update from 172.16.43.1 on FastEthernet1/0, 01:55:31 ago
Routing Descriptor Blocks:
* 172.16.43.1, from 2.2.2.2, 01:55:31 ago, via FastEthernet1/0
Route metric is 22, traffic share count is 1

R4#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via “ospf 1”, distance 110, metric 23, type extern 1
Last update from 172.16.43.1 on FastEthernet1/0, 01:55:22 ago
Routing Descriptor Blocks:
* 172.16.43.1, from 1.1.1.1, 01:55:22 ago, via FastEthernet1/0
Route metric is 23, traffic share count is 1

R4#sh ip mroute
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,
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,
V – RD & Vector, v – Vector
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.100.100.100), 00:21:29/00:02:40, RP 2.2.2.2, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 00:21:29/00:02:31
Loopback10, Forward/Sparse, 00:20:11/00:02:40

(*, 224.0.1.40), 00:21:29/00:02:33, RP 2.2.2.2, flags: SJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 00:21:29/00:02:33

The first reason for that message is that the client needs to perform an RPF check against the RP where the router wants to build the shared-tree to. When you have a shared tree the RPF check of packets is done against the RP (*,G). When we have a shortest path tree (SPT) the RPF check is done against the source (S,G). In this case traffic comes from the shared tree as the SPT-threshhold has not been reached. The RPF check fails due to the RP is not reachable via “tunnel0”.
We can correct that behaviour by modifying the RPF check with the help of a static route. We have to add a static route that says (for the RPF check, we are not changing any unicast routing here) RP=2.2.2.2 is reachable via tunnel interface so that the RPF check succeeds.

R4:
R4(config)#ip mroute 2.2.2.2 255.255.255.255 tun0

Verify the command:

R4#sh ip mroute 239.100.100.100
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,
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,
V – RD & Vector, v – Vector
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.100.100.100), 00:20:22/stopped, RP 2.2.2.2, flags: SJCL
Incoming interface: Tunnel0, RPF nbr 10.10.10.2, Mroute
Outgoing interface list:
Loopback0, Forward/Sparse, 00:20:22/00:02:33
Loopback10, Forward/Sparse, 00:20:22/00:02:45

(172.16.21.1, 239.100.100.100), 00:03:44/00:02:56, flags: LJT
Incoming interface: Tunnel0, RPF nbr 10.10.10.2, Mroute
Outgoing interface list:
Loopback0, Forward/Sparse, 00:03:44/00:02:33
Loopback10, Forward/Sparse, 00:03:44/00:02:45

In the output you can see the “Mroute” flag. This means that the entry is checked against a static mroute.

In the debug we can now see that we get a new PIM message:

*Mar 8 14:24:23.563: PIM(0): Received RP-Reachable on Tunnel0 from 2.2.2.2

Well that sounds good! Lets try if we the multicast packets can reach the receiver.

R1#ping 239.100.100.100 rep 100

Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 239.100.100.100, timeout is 2 seconds:
………..
Reply to request 11 from 10.10.10.4, 136 ms
Reply to request 12 from 10.10.10.4, 68 ms
Reply to request 13 from 10.10.10.4, 72 ms
Reply to request 14 from 10.10.10.4, 72 ms
Reply to request 15 from 10.10.10.4, 52 ms
Reply to request 16 from 10.10.10.4, 116 ms
Reply to request 17 from 10.10.10.4, 104 ms
Reply to request 18 from 10.10.10.4, 120 ms
Reply to request 19 from 10.10.10.4, 28 ms
Reply to request 20 from 10.10.10.4, 72 ms
Reply to request 21 from 10.10.10.4, 92 ms
Reply to request 22 from 10.10.10.4, 72 ms
Reply to request 23 from 10.10.10.4, 84 ms
Reply to request 24 from 10.10.10.4, 92 ms
Reply to request 25 from 10.10.10.4, 100 ms

Indeed they do! But as usual we are not finished here. When we take a look at the debug of R4 again we get a quite confusing error message that says…

*Mar 8 14:41:35.059: IP(0): s=1.1.1.1 (Tunnel0) d=239.100.100.100 id=818, ttl=253, prot=1, len=100(100), RPF lookup failed for source

Well the RPF check still fails but why? Okay…take a deeper look at the message. Formerly the message said “…failed for source and RP” and now it says “…failed for source”. Well obviously the traffic is arriving but he RPF still seems to fail. Well it does fail, but only for the SPT switchover. When the last hop router initiates a SPT switchover it initiates a *,G join to the first hop router and therefore does a RPF check against the source. As we checked earlier, the RPF check against the source fails because of the underlying unicast routing table. So here we also have to set a static mroute towards the source!

Before we add the static mroute, lets check the mroute table:

R4#sh ip mroute
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,
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,
V – RD & Vector, v – Vector
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.100.100.100), 00:14:10/00:02:55, RP 2.2.2.2, flags: SJCL
Incoming interface: Tunnel0, RPF nbr 10.10.10.2, Mroute
Outgoing interface list:
Loopback0, Forward/Sparse, 00:14:10/00:02:41
Loopback10, Forward/Sparse, 00:14:10/00:02:51

(1.1.1.1, 239.100.100.100), 00:00:15/00:02:44, flags: LJ
Incoming interface: Null, RPF nbr 172.16.43.1
Outgoing interface list:
Loopback0, Forward/Sparse, 00:00:15/00:02:44
Loopback10, Forward/Sparse, 00:00:15/00:02:51

(*, 224.0.1.40), 00:14:10/00:02:43, RP 2.2.2.2, flags: SJCL
Incoming interface: Tunnel0, RPF nbr 10.10.10.2, Mroute
Outgoing interface list:
Loopback0, Forward/Sparse, 00:14:11/00:02:42

Here you can see that there is no “T” flag in the entry for the 239.100.100.100 address which means that the SPT-join has not been done yet.

WE will add the static mroute now:

R4:
R4(config)#ip mroute 1.1.1.1 255.255.255.255 tunnel0

Again we check the mroute table and there it is..the “T” flag within the S,G entry

R4#sh ip mroute
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,
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,
V – RD & Vector, v – Vector
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.100.100.100), 00:17:27/00:00:11, RP 2.2.2.2, flags: SJCL
Incoming interface: Tunnel0, RPF nbr 10.10.10.2, Mroute
Outgoing interface list:
Loopback0, Forward/Sparse, 00:17:27/00:02:25
Loopback10, Forward/Sparse, 00:17:27/00:02:35

(1.1.1.1, 239.100.100.100), 00:03:32/00:02:56, flags: LJT
Incoming interface: Tunnel0, RPF nbr 10.10.10.2, Mroute
Outgoing interface list:
Loopback0, Forward/Sparse, 00:03:32/00:02:25
Loopback10, Forward/Sparse, 00:03:32/00:02:35

(*, 224.0.1.40), 00:17:27/00:02:24, RP 2.2.2.2, flags: SJCL
Incoming interface: Tunnel0, RPF nbr 10.10.10.2, Mroute
Outgoing interface list:
Loopback0, Forward/Sparse, 00:17:27/00:02:23

The ICMP traffic is still arriving (now via shortest path tree) and everything looks good since we do not get any problematic debug message here.

Thanks for reading, have fun with it and feel free to comment.

Regards!
Markus

Advertisements

About markus.wirth

Living near Limburg in Germany, working as a Network Engineer around Frankfurt am Main.
This entry was posted in Multicast and tagged , , , , , , , . Bookmark the permalink.

3 Responses to ip multicast (pim sparse mode) over gre tunnels

  1. Manny Romero says:

    Hi – are you available for consulting ? We have Industrial 3G Router based on OpenWRT and working on a Multicast application and need some help?

  2. markus.wirth says:

    Hi!
    Thanks for your comment.
    At the moment I am not available for consulting, I am moving at the moment and need to study in my free time but thanks for the offer.

    Regards!
    Markus

  3. Manuel says:

    Hello Markus,

    I read your post, and have a question.

    I have one Cisco 881 router, and need to pass the the multicast from one interface to another, inside the router.

    How can I do this?

    regards,

    Manuel

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s