Multicast PIM sparse mode requires an RP (Rendezvous Point) as a meeting point in the network for all multicast traffic. In our first PIM sparse mode lesson, we manually configured the RP on all routers.
For a small network, this is no problem. On large multicast networks, it’s not a good idea. First of all, it takes time to manually configure each router, but it’s also prone to errors. When your RP fails, there’s no automatic way to recover from it. You’ll have to configure all routers to use another router as the RP.
Luckily for us, there are two discovery protocols that we can use to automatically find an RP on the network:
- PIMv2 bootstrap router (BSR)
This lesson is about Auto-RP so we’ll cover BSR in another lesson. Auto-RP is a Cisco proprietary protocol that uses two different roles:
- Candidate RP
- Mapping Agent
The candidate RP is a router that announces itself that it wants to be an RP for the network. It does so by sending RP announcement packets to the 188.8.131.52 multicast address.
The mapping agent listens to the RP announcement packets from our RP candidates and makes a list of all possible RPs. It will then elect an RP and informs the rest of the network with RP mapping packets that are sent to multicast address 184.108.40.206.
Let’s look at an example:
Above we have a small network with 6 routers. R1 and R5 are advertising themselves as rendezvous points in the network. These two routers will send their RP announcements packets to 220.127.116.11 on all directly connected interfaces where PIM is enabled. One of our routers will become the mapping agent, take a look below:
Above you can see that R3 is the mapping agent in our network. It has received the RP announcement packets from R1 and R5, and has elected R5 as the RP that will be advertised to the network. When two candidate RPs want to become RP for the same group(s) then the mapping agent will prefer the RP with the highest IP address.
R3 will advertise RP mapping packets that contain the RP address of R5 and the groups that it will serve. These are sent on all directly connected interfaces where PIM is enabled.
So far so good, there is one problem though. Above you can see that R3 sends these packets to R1, R4 and R5. These routers have now learned which RP they can use.
What about R2 and R6? Take a look below:
R2 and R6 didn’t receive the RP mapping packets. Why?
Keep in mind we are using PIM sparse mode here, multicast traffic is only forwarded when a router requests it with a PIM join message. This PIM join message is sent to the RP.
- R1 and R4 are not going to forward multicast packets to 18.104.22.168 to R2 unless R2 requests it.
- R5 and R4 are not going to forward multicast packets to 22.214.171.124 to R6 unless R6 requests it.
PIM dense mode works the other way around. Multicast traffic is flooded everywhere and then pruned with PIM prune messages.
It’s a classical chicken and egg problem. When R2/R6 want to receive traffic from 126.96.36.199, they’ll have to send a PIM join to the RP address for 188.8.131.52. However, they have no idea what the RP address is…
How do we solve it? There are two options:
- PIM Sparse-Dense mode
- PIM Auto-RP Listener
PIM sparse-dense mode is an extension to PIM sparse mode. It allows our multicast routers to use dense mode for multicast groups that don’t have an RP configured. When your router knows the RP, it will use sparse mode. If it doesn’t know the RP…it will use dense mode. This allows traffic to 184.108.40.206 to be flooded throughout the network so that R2 and R6 can also learn the RP address.
The second option, auto-rp listener is a bit similar. If you enable this then the router will use dense mode only for the 220.127.116.11 and 18.104.22.168 addresses.
Let’s take a look at Auto RP in action. To demonstrate this, I will use the following topology:
Above we have 4 routers. Our goal is that all routers should learn the RP address. R1 is the RP, R2 is the mapping agent. OSPF has been pre-configured so that all networks are reachable.
First, we need to enable multicast routing on all routers:
R1, R2, R3 & R4 (config)#ip multicast-routing
Let’s enable PIM sparse mode on all interfaces:
R1(config)#interface GigabitEthernet 0/1 R1(config-if)#ip pim sparse-mode
R2(config)#interface GigabitEthernet 0/1 R2(config-if)#ip pim sparse-mode R2(config)#interface GigabitEthernet 0/2 R2(config-if)#ip pim sparse-mode
R3(config)#interface GigabitEthernet 0/1 R3(config-if)#ip pim sparse-mode R3(config)#interface GigabitEthernet 0/2 R3(config-if)#ip pim sparse-mode
R4(config)#interface GigabitEthernet 0/1 R4(config-if)#ip pim sparse-mode
Before we configure the RP and mapping agent, let’s take a look at the multicast routing tables:
Based on the below entry:... Continue reading in our forum
"Above you can see that R2 is receiving the RP announcement traffic from R1. Let’s check R3:
I accidently mixed the interface numbers in the topology picture. Just fixed them so it should make more sense now
Thanks for letting me know!
Why would R2 send it to R3 ? SHouldn’t R3 have sent a PIM join to start recieving the traffic ?
Do you mean in the configuration example?
By default, all routers are listening to 22.214.171.124 once you enable PIM. They’ll listen for messages from a mapping agent.
The mapping agent will automatically send messages on its directly connected PIM enabled interfaces.
So, is this a property of mapping agent ? I will tell you where I am confused. As soon as we configure PIM on routers, they automatically have a **, 126.96.36.199) entry in their MRT. In order for them to generate PIM joins in sparse mode, some host needs to generate traffic. But in our example, we do not have any hosts which send an IGMP join to R3 and yet R2 sends the information about RP to it. Is this specific Mapping agent behaviour ?