pim sparse mode – rp on a stick

Hi everybody!

Very often without knowing it in PIM sparse networks we encounter the situation that the RP of a network is a RP on a stick.

Take a look at the drawing to get a better understanding of the situation here.

Problem here is that the incoming traffic of the source-tree is going out the same interface down the shared tree. The PIM SM rule, that says “incoming and outgoing interface for a specific stream may not be the same due to loop prevention”, prevents the usage of this. Lets take a look what happens.

R2 registers the source in the RP with the PIM register message:

R2#ping 239.100.100.100 rep 100 so fa0/0

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

R1#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
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:02:31/stopped, RP 172.16.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(172.16.0.2, 239.100.100.100), 00:02:31/00:02:51, flags: PT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.0.2
Outgoing interface list: Null

R3 joins the shared tree by becoming a receiver in the group 239.100.100.100. But we cannot see any change in the mroute table of the RP:

R1#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
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:05:04/stopped, RP 172.16.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(172.16.0.2, 239.100.100.100), 00:05:04/00:02:58, flags: PT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.0.2
Outgoing interface list: Null

Logically for a short period of time the mroute output should look like this:

R1#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
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:05:04/stopped, RP 172.16.0.1, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(172.16.0.2, 239.100.100.100), 00:05:04/00:02:58, flags: PT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.0.2
Outgoing interface list: FastEthernet0/0

This situation will never occur because the router internally knows whats going on here.

The traffic succeeds.

R2#ping 239.100.100.100 rep 1000 so fa0/0

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 172.16.0.2
…………………………………………………………….
…………………………………………………………….
…………………………………………………………….
…………………………………………………………….
…………………………………………………………….
…………………………………………………………….
…………………………………………………………….
…………………………………………………………….
…….
Reply to request 567 from 172.16.0.3, 68 ms
Reply to request 568 from 172.16.0.3, 72 ms
Reply to request 569 from 172.16.0.3, 32 ms
Reply to request 570 from 172.16.0.3, 92 ms
Reply to request 571 from 172.16.0.3, 128 ms
Reply to request 572 from 172.16.0.3, 116 ms
Reply to request 573 from 172.16.0.3, 40 ms
Reply to request 574 from 172.16.0.3, 64 ms
Reply to request 575 from 172.16.0.3, 56 ms
Reply to request 576 from 172.16.0.3, 72 ms

The RP does not delete the entry. It sends periodic S,G join (instead of prunes, which is the normal behaviour in a case where the incoming and outgoing interfaces are equal) messages to keep the stream alive, although the OIL is “null”. This feature is called proxy-join timer.
Once the RP receives a packet that matches the proxy join timer rules, the timer is started and the router recognizes in which position he is and that he does not have to drop the multicast traffic. So multicast forwarding can occur.
The proxy join timer feature I will more dig into in a different post where I will take a deeper look into one legged rendezvous-points that have a turnaround router in front of them.
Details can be read about that in “Developing IP Multicast Networks Vol.1” from Cisco Press.

Have fun and feel free to comment!
Regards!

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.

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