Multicast PIM Auto RP

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:

  • Auto-RP
  • 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 224.0.1.39 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 224.0.1.40.

Let’s look at an example:

Multicast PIM Auto RP 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 224.0.1.39 on all directly connected interfaces where PIM is enabled. One of our routers will become the mapping agent, take a look below:

Multicast PIM Auto RP Mapping Advertised

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:

Multicast PIM Auto RP Mapping Sparse Mode

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 224.0.1.40 to R2 unless R2 requests it.
  • R5 and R4 are not going to forward multicast packets to 224.0.1.40 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 224.0.1.40, they’ll have to send a PIM join to the RP address for 224.0.1.40. 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 224.0.1.40 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 224.0.1.39 and 224.0.1.40 addresses.

In the example above, R2 and R6 were unable to learn the RP address since they didn’t receive the RP mapping packets to 224.0.1.40. The same problem can occur with the mapping agent. Since R3 is directly connected to R1 and R5, it was able to receive the RP announce packets to 224.0.1.39. If R3 was not directly connected to the RPs, then it would not have received these packets.

Configuration

Let’s take a look at Auto RP in action. To demonstrate this, I will use the following topology:

Multicast Auto RP 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:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 785 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

1489 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: , ,


Forum Replies

  1. Rene,

    Based on the below entry:
    "Above you can see that R2 is receiving the RP announcement traffic from R1. Let’s check R3:

    R3#show ip mroute | begin 224
    (*, 224.0.1.39), 00:05:28/00:01:57, RP 0.0.0.0, flags: DC
      Incoming interface: Null, RPF nbr 0.0.0.0
      Outgoing interface list:
        GigabitEthernet0/2, Forward/Sparse, 00:05:28/00:01:57
    
    (*, 224.0.1.40), 00:27:34/stopped, RP 0.0.0.0, flags: DPL
      Incoming interface: Null, RPF nbr 0.0.0.0
      Outgoing interface list: Null
    
    (2.2.2.2, 224.0.1.40), 00:04:29/00:02:29, flags: PLT
      <strong>Incoming interface: 
    ... Continue reading in our forum

  2. Hi Jose,

    I accidently mixed the interface numbers in the topology picture. Just fixed them so it should make more sense now :slight_smile:

    Thanks for letting me know!

    Rene

  3. Why would R2 send it to R3 ? SHouldn’t R3 have sent a PIM join to start recieving the traffic ?

  4. Hi Suman,

    Do you mean in the configuration example?

    By default, all routers are listening to 224.0.1.40 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.

    Rene

  5. 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 **, 224.0.1.40) 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 ?

58 more replies! Ask a question or join the discussion by visiting our Community Forum