In the previous article about the basics of multicast, we discussed how Sparse and Dense modes work. Additionally, we learned how to configure static RP for PIM Sparse Mode and specify RP for a multicast group using access-lists. In this article, we will learn about the Cisco proprietary “automagical” way of discovering RPs which is Auto-RP.

After Auto-RP, the standards based Bootstrap Router (BSR) protocol was developed and both protocols are still used in Cisco routers nowadays. We will have another article that will cover the setup and configuration of BSR as this will focus on Auto-RP. Auto-RP has two main components which are Candidate RP (cRP) and Mapping Agents (MA). A Candidate RP is any routing device that announces itself as willing to become an RP. The cRPs send out announcements to the multicast IP 224.0.1.39 port 496. There can be many cRPs for a particular multicast group but the MA will choose only one per group. In case the chosen RP fails, one of the other RPs will be elected to serve as backup. The Mapping Agents listen in to the multicast announcements from the group 224.0.1.39 and gather information on the candidate RPs and then announce it out to the multicast group 224.0.1.40 port 496 through Dense mode. There can only be one active Mapping Agent per multicast group and it is elected through the highest IP address. The Mapping Agents announce only one RP with the highest IP address for a particular multicast group. The cRP and MA can be configured in one router. The other routers that are non-cRP and non-MA listen in to the multicast group announced by the MAs, which is 224.0.1.40 and there discovers the RPs for a multicast group. RPs discovered through Auto-RP or BSR for that matter has precedence over static RPs. To make the static RP configuration take precedence over the RP discovered dynamically, the “override” keyword could be used along with the “ip pim rp-address” command.

Now that we have tackled the concept of Auto-RP, we will be doing the tasks below in this lab. OSPF has been pre-configured and is announcing all interfaces of all devices into Area 0.

Note: Depending on your IOS version and platform, GNS3 might have bugs on the multicast functionality. If you don’t get the desired results after making a configuration, save running-configs and topology and then reload the devices.

Tasks:

1. Configure all corresponding interfaces as “ip pim sparse-mode”.
2. R1 and R2 should be RPs for all multicast groups. R3 and R4 should be configured to become mapping agents. Check and troubleshoot if there are issues. R5 and R6 should learn the RP mapping through Auto-RP.
3. Revert the PIM configuration back to “ip pim sparse-mode” and use a different solution to fix the problem.
4. R1 should be the RP for 239.1.0.0/16 while R2 is the RP for 239.2.0.0/16. Make sure that both multicast groups can still work in case their RP goes down. Simulate by shutting R1’s Loopback0.
5. Un-shut R1’s Loopback0. Configure both Mapping Agents to filter announcements for 239.2.0.0/16.

Diagram:

Task 1: . Configure all corresponding interfaces as “ip pim sparse-mode”.

Let’s start with the basics and configure all appropriate interfaces as “ip pim sparse-mode”.

R1(config)#ip multicast-routing
R1(config)#ip multicast-routing
R1(config-if)#int fa0/0
R1(config-if)#ip pim sparse-mode
R1(config-if)#int fa0/1
R1(config-if)#ip pim sparse-mode
R1(config-if)#int fa1/0
R1(config-if)#ip pim sparse-mode

R2(config)#ip multicast-routing
R2(config)#int fa0/0
R2(config-if)#ip pim sparse-mode
R2(config-if)#int fa0/1
R2(config-if)#ip pim sparse-mode
R2(config-if)#int fa1/0
R2(config-if)#ip pim sparse-mode

R3(config)#ip multicast-routing
R3(config)#int fa0/0
R3(config-if)#ip pim sparse-mode
R3(config-if)#int fa0/1
R3(config-if)#ip pim sparse-mode

R4(config)#ip multicast-routing
R4(config)#int fa0/0
R4(config-if)#ip pim sparse-mode
R4(config-if)#int fa1/0
R4(config-if)#ip pim sparse-mode

R5(config)#ip multicast-routing
R5(config)#int fa0/0
R5(config-if)#ip pim sparse-mode

R6(config)#ip multicast-routing
R6(config)#int fa0/0
R6(config-if)#ip pim sparse-mode

Let’s check and verify PIM neighborship.

R1#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
14.14.14.4 FastEthernet0/1 00:02:14/00:01:28 v2 1 / DR S
15.15.15.5 FastEthernet0/0 00:01:04/00:01:40 v2 1 / DR S
13.13.13.3 FastEthernet1/0 00:03:23/00:01:20 v2 1 / DR S

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
24.24.24.4 FastEthernet0/0 00:02:33/00:01:40 v2 1 / DR S
23.23.23.3 FastEthernet0/1 00:03:30/00:01:41 v2 1 / DR S
26.26.26.6 FastEthernet1/0 00:00:45/00:01:29 v2 1 / DR S

Task 2: R1 and R2 should be RPs for all multicast groups. R3 and R4 should be configured to become mapping agents. Check and troubleshoot if there are issues. R5 and R6 should learn the RP mapping through Auto-RP.

R1(config)#ip pim send-rp-announce Loopback0 scope 255
Must first configure PIM mode on the interface: Loopback0
R1(config)#interface Loopback0
R1(config-if)#ip pim sparse-mode
R1(config-if)#ip pim send-rp-announce Loopback0 scope 255

R2(config-if)#interface Loopback0
R2(config-if)#ip pim sparse-mode
R2(config-if)#ip pim send-rp-announce Loopback0 scope 255

R3(config)#ip pim send-rp-discovery Loopback0 scope 255
Non-IP or PIM interface ignored in accepted command.
R3(config)#interface Loopback0
R3(config-if)#ip pim sparse-mode
R3(config-if)#ip pim send-rp-discovery Loopback0 scope 255

R4(config)#interface Loopback0
R4(config-if)#ip pim sparse-mode
R4(config-if)#ip pim send-rp-discovery Loopback0 scope 255[/code]
The "send-rp-announce" is used to announce the device as the cRP. On the other hand, "send-rp-discovery" is configured in MAs to send out the RP information. The Loopback0 is where the announcements are sourced from and as a requirement this interface should have PIM enabled on both cRPs and MAs. Scope is the TTL and will let you control how many hops you will allow for the announcement. It is best practice to put a proper value to the scope to limit the announcements to a specific network boundary and secure the multicast network.

Let's check if we are actually getting the RP mappings through Auto-RP in R5.
R5#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:04:27/stopped, RP 0.0.0.0, flags: DP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(1.1.1.1, 224.0.1.39), 00:01:26/00:01:33, flags: PT
Incoming interface: FastEthernet0/0, RPF nbr 15.15.15.1
Outgoing interface list: Null

(*, 224.0.1.40), 00:15:17/00:02:53, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 00:15:19/00:02:51

R5#sh ip pim rp mapping
PIM Group-to-RP Mappings

We don’t see any discovered mappings through Auto-RP. We can only see the announcement of 224.0.1.39 from 1.1.1.1 which is the cRP announcement which is not really that useful to R5. The reason that this is not working is that R5 and R6 can’t reach 224.0.1.40 because as you can see from the output above the flag is DCL and the “D” means that this is in Dense mode. Since the interfaces are configured as Sparse, there is no way for R5 and R6 to reach this group. Let’s solve this problem by configuring another mode of PIM.

R1(config)#int fa0/0
R1(config-if)#ip pim sparse-dense-mode
R1(config-if)#int fa0/1
R1(config-if)#ip pim sparse-dense-mode
R1(config-if)#int fa1/0
R1(config-if)#ip pim sparse-dense-mode

R2(config)#int fa0/0
R2(config-if)#ip pim sparse-dense-mode
R2(config-if)#int fa0/1
R2(config-if)#ip pim sparse-dense-mode
R2(config-if)#int fa1/0
R2(config-if)#ip pim sparse-dense-mode

R3(config)#int fa0/0
R3(config-if)#ip pim sparse-dense-mode
R3(config-if)#int fa0/1
R3(config-if)#ip pim sparse-dense-mode

R4(config)#int fa0/0
R4(config-if)#ip pim sparse-dense-mode
R4(config-if)#int fa1/0
R4(config-if)#ip pim sparse-dense-mode

R5(config)#int fa0/0
R5(config-if)#ip pim sparse-dense-mode

R6(config)#int fa0/0
R6(config-if)#ip pim sparse-dense-mode

The “ip pim sparse-dense-mode” command will make the interface function on both modes. For groups without RPs, dense mode will be used.

Let’s verify if Auto-RP is working. By right R2 should be discovered as RP and R4 as mapping agents.

R5#sh ip pim rp mapping
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:15:45, expires: 00:02:07

We will configure Loopback0 of R5 to join multicast group 239.5.5.5 and R6 will be the source. We will use pings from R6 to simulate data from the multicast traffic source and test if our configuration is working.

R5(config)#int Loopback0
R5(config-if)#ip pim sparse-mode
R5(config-if)#ip igmp join-group 239.5.5.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.5.5.5, timeout is 2 seconds:

Reply to request 0 from 15.15.15.5, 64 ms
Reply to request 1 from 15.15.15.5, 92 ms
Reply to request 2 from 15.15.15.5, 92 ms
Reply to request 3 from 15.15.15.5, 92 ms
Reply to request 4 from 15.15.15.5, 84 ms

Task 3: Revert the PIM configuration back to “ip pim sparse-mode” and use a different solution to fix the problem.

For the purpose of brevity, I will not post the sparse configs. Below are the modes of the PIM interfaces of R1 after changing back to sparse mode. Under Ver/Mode column “S” means Sparse. Previously it was “SD” for Sparse-Dense.

R1#sh ip pim interface

Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
1.1.1.1 Loopback0 v2/S 0 30 1 1.1.1.1
15.15.15.1 FastEthernet0/0 v2/S 1 30 1 15.15.15.5
14.14.14.1 FastEthernet0/1 v2/S 1 30 1 14.14.14.4
13.13.13.1 FastEthernet1/0 v2/S 1 30 1 13.13.13.3

All Routers
!
ip pim autorp listener

The “ip pim autorp listener” will enable the routers to listen to 224.0.1.40 without configuring dense mode. In sparse mode only environments, this command is recommended rather than configuring sparse-dense mode.

Task 4: R1 should be the RP for 239.1.0.0/16 while R2 is the RP for 239.2.0.0/16. Make sure that both multicast groups can still work in case their RP goes down. Simulate by shutting R1’s Loopback0.

R1(config-std-nacl)#ip access-list standard R1-GROUP
R1(config-std-nacl)#permit 239.1.0.0 0.0.255.255
R1(config-std-nacl)#permit 239.0.0.0 0.255.255.255
R1(config)#ip pim send-rp-announce Loopback0 scope 255 group-list R1-GROUP

R2(config)#ip access-list standard R2-GROUP
R2(config-std-nacl)#permit 239.2.0.0 0.0.255.255
R2(config-std-nacl)#permit 239.0.0.0 0.255.255.255
R2(config-std-nacl)#exit
R2(config)#ip pim send-rp-announce Loopback0 scope 255 group-list R2-GROUP

Anything that is denied in the access-list means that those groups will be in Dense mode. This includes the implicit deny at the end of each access-list.

We will now check the RP mappings. We then will configure R5’s Loopback0 to join multicast groups 239.1.1.1 and then 239.2.2.2. Likewise, we will use R6 as the source.

R5#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 239.0.0.0/8
RP 2.2.2.2 (?), v2v1
Info source: 4.4.4.4 (?), elected via Auto-RP
Uptime: 00:00:51, expires: 00:02:05
Group(s) 239.1.0.0/16
RP 1.1.1.1 (?), v2v1
Info source: 4.4.4.4 (?), elected via Auto-RP
Uptime: 00:04:13, expires: 00:02:48
Group(s) 239.2.0.0/16
RP 2.2.2.2 (?), v2v1
Info source: 4.4.4.4 (?), elected via Auto-RP
Uptime: 00:01:27, expires: 00:02:31

R5(config-if)#interface Loopback0
R5(config-if)#ip igmp join-group 239.1.1.1
R5(config-if)#ip igmp join-group 239.2.2.2

R6#ping 239.1.1.1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 15.15.15.5, 84 ms
R6#ping 239.2.2.2

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.2.2.2, timeout is 2 seconds:

Reply to request 0 from 15.15.15.5, 84 ms

Similar to unicast routing, the RP that has the most specific or longest match announcement of a multicast group becomes the RP. Using a summarized multicast IP address range can be some sort of a backup.

To test if the 2 RPs really backup each other, we will shutdown R1’s Loopback0 to simulate failure. The pings from R6 to R5 using 239.1.1.1 should still have responses and R2 as the new RP.

R1(config)#int Loopback0
R1(config-if)#shut

R6#ping 239.2.2.2

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.2.2.2, timeout is 2 seconds:

Reply to request 0 from 15.15.15.5, 92 ms

Task 5: Unshut R1’s Loopback0. Configure both Mapping Agents to filter announcements for 239.2.0.0/16.

Before configuration:

R6#sh ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 239.0.0.0/8
RP 2.2.2.2 (?), v2v1
Info source: 4.4.4.4 (?), elected via Auto-RP
Uptime: 00:08:01, expires: 00:02:24
Group(s) 239.1.0.0/16
RP 1.1.1.1 (?), v2v1
Info source: 4.4.4.4 (?), elected via Auto-RP
Uptime: 00:03:54, expires: 00:02:06
Group(s) 239.2.0.0/16
RP 2.2.2.2 (?), v2v1
Info source: 4.4.4.4 (?), elected via Auto-RP
Uptime: 00:08:37, expires: 00:02:45

Configuration:

R3(config)#ip access-list standard R2-GROUP-DENY
R3(config-std-nacl)#deny 239.2.0.0 0.0.255.255
R3(config-std-nacl)#permit any
R3(config)#ip access-list standard R2-RP
R3(config-std-nacl)#permit host 2.2.2.2
R3(config)#ip pim rp-announce-filter rp-list R2-RP group-list R2-GROUP-DENY

R4(config)#ip access-list standard R2-GROUP-DENY
R4(config-std-nacl)#deny 239.2.0.0 0.0.255.255
R4(config-std-nacl)#permit any
R4(config-std-nacl)#ip access-list standard R2-RP
R4(config-std-nacl)#permit host 2.2.2.2
R4(config)#ip pim rp-announce-filter rp-list R2-RP group-list R2-GROUP-DENY

After configuration:

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

Group(s) 239.0.0.0/8
RP 2.2.2.2 (?), v2v1
Info source: 4.4.4.4 (?), elected via Auto-RP
Uptime: 00:01:28, expires: 00:02:28
Group(s) 239.1.0.0/16
RP 1.1.1.1 (?), v2v1
Info source: 4.4.4.4 (?), elected via Auto-RP
Uptime: 00:01:50, expires: 00:02:10

The “ip pim rp-announce-filter” can be configured in the mapping agents to filter RP announcements. By configuring this, we have successfully filtered the announcement of 239.2.0.0/16 with R2 as the RP. Since we permitted the rest of the group, we can still see that R2 is announced as the RP for 239.0.0.0/8.

References:

http://www.cisco.com/c/en/us/td/docs/ios/solutions_docs/ip_multicast/White_papers/rps.html

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ip-multicast/whitepaper_c11-508498.html

http://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/9356-48.html