ip pim autorp – automatic election of an rp in a sparse-mode network

Hello everybody!
Today I am going to show and to train for myself how to configure cisco auto-rp for electing rendesovus-points within a sparse mode multicast environemnt dynamically.

First of all some short theoretics, as the complete theory can be read at Cisco´s website and many books.

Auto-RP is a feature that allows to dynamically assign RPs that serve particular or even all multicast groups within an multicast AS. The election of the RPs is done by so called “mapping agents” short “MA”. The MAs get the advertisements of the different RP-candidates (routers who want to be the RP) and decide which candidate-RP will be the RP for what group or set of groups.

We can also configure them redundant. I will do this in a different setup and post.

After the candidate-RPs have sent their advertisements to the RP (they send it to the multicast address 224.0.1.39). Now we have a chicken and the egg problem here. We want to elect an RP by using the 224.0.1.39 to let a router advertise himself as a candidate-RP and on the other hand we want to elect a RP because without an RP multicast does not work in a PIM sparse mode network. So how can we use multicast forwarding withhout already having an RP? Well thats an easy one…the group 224.0.1.39 is a well-known group (RP-candiate-announce) and is always used in DENSE-MODE! Does not matter what type of mode you configure, this group always uses dense mode. Which means, that as soon as a router advertises itself to this group the *,G entry and the advertisement will be flooded out the whole network.

Lets first take a look at a scenario here:

SETUP:
– All routers have a loopback corresponding to their router ID e.g. R1´s Lo0 = 1.1.1.1/32.
– OSPF is running and the whole network has converged
– ip multicast-routing on every machine is enabled
– all interfaces (including Loopbacks!!! This is necessary due to the election process of auto-rp) are configured with “ip pim sparse-mode”
– no static “ip pim rp-address” is configured

Lets have a look into the multicast-routing table of R4 (could also be any other):

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
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.0.1.40), 00:01:15/00:02:51, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 00:01:15/00:02:51

We can see the 224.0.1.40 group is already in the table even nothing is configured. This means that the router is listening to autorp messages. The group is also (this can be seen by the “D” flag) in dense-mode although we only configured sparse mode everywhere.

First of all we need to make sure that there is somebody who can judge about the elections of the RP-candidates, the mapping agent. To configure a MA we need to configure the following commands:

ip pim autorp listener
(http://www.cisco.com/en/US/docs/ios/ipmulti/command/reference/imc_04.html#wp1039806)
ip pim send-rp-discovery <interface> scope <ttl>

After the “ip pim autorp listener” command we can see a change in the multicast routing table. We can see that the physical interfaces are now forwarding traffic corresponding to the 224.0.1.40 group.

R4(config)#ip pim autorp listener
R4(config)#do 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
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.0.1.40), 00:00:01/00:02:58, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet1/0, Forward/Sparse, 00:00:01/00:00:00
FastEthernet0/1, Forward/Sparse, 00:00:01/00:00:00
FastEthernet0/0, Forward/Sparse, 00:00:01/00:00:00
Loopback0, Forward/Sparse, 00:00:01/00:00:00

After enabling the “ip pim send-rp-discovery” command we can the that R4 is also participating in the group 224.0.1.39. This group is used to send/receive advertisements for the election itseld. The 224.0.1.40 is used to send information about the RP and the corresponding group.

Here again:
224.0.1.39 -> send election packets to the MA, the MA then decides who will be the RP for what group or set of groups
224.0.1.40 -> send information about who is the RP for what group, typically from the MA to all other routers in the domain

Now as we configured the MA, we come to the candidates. First of all we will check if R3 who is our testrouter in this case has any information about an RP.

R3#sh ip pim rp map
PIM Group-to-RP Mappings

R3#

Ok there is no information about an RP. Lets configure the first candidate-RP, R1. To do this we need the following commands:

ip pim autorp listener

ip pim send-rp-announce <interface> scope <ttl>

The “ip pim send-rp-announce” will send advertisements to the 224.0.1.39 group, that will enter the MA. Lets check that.

R1(config)#ip pim send-rp-announce lo0 scope 255
R1(config)#do 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
Outgoing interface flags: H – Hardware switched, A – Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.0.1.39), 00:00:03/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:00:03/00:00:00

(1.1.1.1, 224.0.1.39), 00:00:03/00:02:56, flags: T
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:00:03/00:00:00

(*, 224.0.1.40), 00:00:14/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:00:14/00:00:00
Loopback0, Forward/Sparse, 00:00:14/00:00:00

(4.4.4.4, 224.0.1.40), 00:00:03/00:02:56, flags: LT
Incoming interface: FastEthernet0/0, RPF nbr 172.16.41.2
Outgoing interface list:
Loopback0, Forward/Sparse, 00:00:06/00:00:00

As you can see we now have S,G entries in the multicast routing table. S,G for the 224.0.1.39 group means that the source 3.3.3.3 actually sends out advertisements and the S,G for the 224.0.1.40 group means that we are getting information about RP and groups from the mapping agent. So it seems that the mapping agent already has made a decision about who is the RP and which groups it will serve. We will check that right now on that router.

R1#sh ip pim rp map
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)

Group(s) 224.0.0.0/4
RP 1.1.1.1 (?), v2v1
Info source: 4.4.4.4 (?), elected via Auto-RP
Uptime: 00:03:01, expires: 00:02:54

Indeed R1 is elected, because it is the only candidate-RP. We will now also check that on our testrouter R3.

R3#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 1.1.1.1 (?), v2v1
Info source: 4.4.4.4 (?), elected via Auto-RP
Uptime: 00:03:53, expires: 00:02:00

Perfect, it works.

What we will do now is configure a second rp-candidate and then we will have look at the scenario and what changes.

R2(config)#ip pim autorp list
R2(config)#ip pim send-rp-announce lo0 scope 255

Check what changed.

R3#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 2.2.2.2 (?), v2v1
Info source: 4.4.4.4 (?), elected via Auto-RP
Uptime: 00:00:06, expires: 00:02:50

Router R2 is now the RP. This is due to R2 has the higher ip address that corresponds with the election process (lo0). 2.2.2.2 is higher than 1.1.1.1.

NOTE: In autorp we cannot do any change to the priority so the IP address is the only trigger for the election. In BSR for PIMv2 we can actually change the priority.

On the MA we can see which RP and candidate-RPs exist.

R4#sh ip pim rp map
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4
RP 2.2.2.2 (?), v2v1
Info source: 2.2.2.2 (?), elected via Auto-RP
Uptime: 00:03:46, expires: 00:02:36
RP 1.1.1.1 (?), v2v1
Info source: 1.1.1.1 (?), via Auto-RP
Uptime: 00:09:13, expires: 00:02:42

When we now shut down the link to R2 we will surely see a change.

R2(config-if)#int fa0/0
R2(config-if)#shut
R2(config-if)#
*Mar 1 01:00:32.143: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar 1 01:00:33.143: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
R2(config-if)#

R3#debug ip pim auto-rp
PIM Auto-RP debugging is on
R3#
*Mar 1 01:00:30.851: Auto-RP(0): Received RP-discovery packet of length 48, from 4.4.4.4, RP_cnt 1, ht 181
*Mar 1 01:00:30.855: Auto-RP(0): Update (224.0.0.0/4, RP:2.2.2.2), PIMv2 v1

So far so good but the RP hasnt changed on R3:

R3#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 2.2.2.2 (?), v2v1
Info source: 4.4.4.4 (?), elected via Auto-RP
Uptime: 00:10:56, expires: 00:02:57
R3#
*Mar 1 01:02:29.635: Auto-RP(0): Received RP-discovery packet of length 48, from 4.4.4.4, RP_cnt 1, ht 181
*Mar 1 01:02:29.635: Auto-RP(0): Update (224.0.0.0/4, RP:2.2.2.2), PIMv2 v1

It even gets updated! Lets take a look at the MA. We can see it expires here:

R4#sh ip pim rp map
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4
RP 2.2.2.2 (?), v2v1
Info source: 2.2.2.2 (?), elected via Auto-RP
Uptime: 00:10:36, expires: 00:00:45
RP 1.1.1.1 (?), v2v1
Info source: 1.1.1.1 (?), via Auto-RP
Uptime: 00:16:03, expires: 00:02:54
R4#sh ip pim rp map
PIM Group-to-RP Mappings
This system is an RP-mapping agent (Loopback0)

Group(s) 224.0.0.0/4
RP 1.1.1.1 (?), v2v1
Info source: 1.1.1.1 (?), elected via Auto-RP
Uptime: 00:16:50, expires: 00:02:07

Now it should have changed on R3 too:

R3#
*Mar 1 01:02:56.655: Auto-RP(0): Received RP-discovery packet of length 48, from 4.4.4.4, RP_cnt 1, ht 181
*Mar 1 01:02:56.655: Auto-RP(0): Added with (224.0.0.0/4, RP:1.1.1.1), PIMv2 v1
R3#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 1.1.1.1 (?), v2v1
Info source: 4.4.4.4 (?), elected via Auto-RP
Uptime: 00:00:52, expires: 00:02:07

Yep we just had to wait for the expiration timer.

I hope you enjoyed it 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.

2 Responses to ip pim autorp – automatic election of an rp in a sparse-mode network

  1. Eric says:

    It will be nice if you can post all four routers configuration

  2. Tim says:

    Nice Overview…Thanks!

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