Hi Lagapides,
What if I wanted to get my device (listener) to igmp-join a specific group say 224.2.2.2, will auto-rp automatically detect ? Do I still need to configure the igmp join request on the closes router to the device?
Hello Champion
A rendezvous point (RP) performs very specific functions in a multicast network. One of those functions is to receive multicast requests from other multicast routers, which in turn receive join messages from hosts requesting particular multicast groups.
The Auto-RP feature simply automates the selection of the RP in a multicast topology. It does not affect the way that a particular host chooses to join a multicast group. Therefore, to answer your question directly, your listener must still issue the igmp-join command to join a particular multicast group. Does that make sense?
I hope this has been helpful!
Laz
I had some doubt that i guess could be related to the @sb6392 post.
I’ve done the following topology :
R1 is the RP, R6 is the MA. R6’s directly connected PIM neighbors (R2, R5 & R7) and they are receiving the MA (224.0.1.40) msg telling them who is the RP (1.1.1.1) but as expected it’s not the same for R3, R4 & R8.
Then, i’ve issued the ip pim autorp listener only on R2 to test out if R2 forwards the MA 224.0.1.40 towards R3 and it worked as expected (R3 has the info of the RP 1.1.1.1)
Then, i’ve issued no ip pim autorp listener on R2, waited a couple of mins, and then tun0 gone down on R3 therefore it lost the info for the RP as expected.
Later, i’ve swaped R2 ↔ R3 wan ip add (R2 now has 192.168.23.3 and R3 192.168.23.2 making the R2 the PIM neigh DR for this 192.168.23.0/24 subnet) , and later R3 tun0 gone up and has again the info of RP 1.1.1.1 without needing the ip autorp listener on R2.
Hello Juan
Thanks for the detailed topology and test. It looks like you confirmed this behavior. Since R2 became the DR between R2 and R3, it was able to forward the mapping advertisements to R3 without implementing the ip autorp listener command on R2.
Thanks so much for sharing!
Laz
This is one of the best lessons on AutoRP and it’s intend. Thanks for sharing!
1 Like
Hello,
Great lesson. I have a doubt:
In this lesson, Rene only issues the command ip pim autorp listener on R3, and everything works.
However, I tried a couple different labs and I wanted to confirm something: if R3 happened to be the DR on R2-R3 then R2 needs to have the ip pim autorp listener command? Because I been stucked for days labbing this with the MA not being the DR, and I can only get it to work by issuing such command on the MA. Is this expected behaviour?
Thanks,
Jose
Hello Jose
The DR should not directly influence the distribution of auto-RP messages in multicast sparse mode. The designated router or DR is responsible for sending PIM Register messages to the RP (for sources) and joining the SPT toward the RP (for receivers), it should not affect the distribution of auto-RP messages. If, however, you see in practice that the role of the DR does affect RP announcements and RP mapping messages, that would be an interesting experiment to look at. Can you share with us in a little more detail the behavior you see with and without the DR designation? Are you able to successfully create the lab without the autorp listener command on the mapping agent? Let us know so that we can help you further.
I hope this has been helpful!
Laz
Hello Laz,
I labbed this with CML and with hardware routers c112x. Here are the results:
I think I wrote the previous question wrong:
As you said, the RP-Mapper should not depend on the DR election in order to forward RP-mapping messages to 224.0.1.40. I labbed this like 10 times switching priorities between the Rp-Mapper and its PIM Neighbors to make sure, and I can confirm it! Thanks for your answer!!
However, I observer some behaviours that I wanted to confirm:
Once R5 (the RP-Mapper) chooses the RP and sends the RP-Mapping messages out of its PIM Sparse enabled interfaces, I see that R3 and R6 receive it and incorporate the new elected RP (which in my lab is R2) successfully (and independently of which neighbor is the DR), but only by issuing the command ip pim autorp listener on both:
So far so good.
On R1, things get interesting: with the ip pim autorp listener command, again, no matter what the DR election results in, the RP-Mapping is received and processed. However, if I remove the command then the following happens:
- If R1 happens to be the DR, then the RP-Mapping reforwarded from R3 (thanks to its ip pim autorp listener command on R3) is processed successfully:
- If R1 is not the DR, then the RP-Mapping message is not processed and R1 cannot learn who is the RP of the PIM SM Domain:
Why this happens? R3 keeps fowrading RP-Mapping to R1, but R1 ignores them.
R3 MRT
R1 MRT
Is it because if R1 is not the DR, then it cannot accept Join messages for 224.0.1.40 to R3? I cannot undertsand this.
Here are configs:
R3
R1
By default, R3 is elected as DR because of higher IP address.
Thanks, any help is appreciated,
Jose
Hello Jose
That was an awesome experiment, thanks for sharing it! Now this makes more sense in how the DR affects the downstream distribution of the RP-mapping messages. This is a subtle behavior of
Now you’re looking at the situation where sparse mode is configured on these routers, and you have configured ip pim autorp listener on R3 but not R1, and R3 the DR. At this point, between the R1 and R3 routers, R3 is “elected” as the DR to forward PIM join messages to the RP.
When R3 is the DR (and R1 is NOT ) R3 is the device that will automatically forward and processes Auto-RP messages for the subnet even without ip pim autorp listener.
This aligns with PIM-SM’s DR role to handle group subscriptions (e.g., IGMP/PIM joins) for downstream hosts. It seems that the Auto-RP messages are included in the group subscriptions category of messages.
Non-DR routers ignore Auto-RP messages unless explicitly configured with ip pim autorp listener command. R3 forwards RP-Mapping messages to 224.0.1.40, but R1 discards them because R1 is not part of the 224.0.1.40 group (there is no IGMP join).
For this reason, Cisco recommends applying the ip pim autorp listener command on all routers in the multicast topology in order to ensure that the 224.0.1.39 and 224.0.1.40 addresses are handled using dense mode regardless of which routers become DRs. Great job on this experiment however, let me know what you think about the explanation…
I hope this has been helpful!
Laz
1 Like
Hello Laz,
Thanks for the reply. However there are some doubts to clarify please.
I re-labbed this to confirm some stuff:
0. The RP-announcements from R2 are sent to R6. R6 is configured with
and therefore floods the RP-announcements out of all PIM Sparse enabled interfaces, except the incoming one:
R3 MRT
However, ONLY IF R5 IS THE DR of the R6-R5 segment then the RP-announcement messages will be processed. If not, R5 will receive this messages and ignore them, so no RP can be elected:
R5 MRT
Now look what happens when I make R5 the DR of R5-R6 segment (I changed priority to 10 on R5):
Beautiful! The RP-announcement messages are processed now and the RP election can take place. In the lesson, Rene has the MA as the DR of the RP-MA segment. But if it happen to not, (which is what I labbed) then issues come. If what I labbed is correct, do you mind noting this on the lesson please? Thanks. If not correct, please correct, thanks a lot.
1. Now comes the time to send the RP-Mappings from the MA. The RP-Mapper, independently of if it is the DR or not for its segments, will flood the RP mappings to R3 and R4 once the RP is elected (this is, it will flood traffic for 224.0.1.40):
Let’s pick R3 as the example router. The RP-Mapping message (to 224.0.1.40) gets sent to R3, and R3 receives it. But… will it process it by default? Will R3 successfully create the RP entry without any configuration apart from basic PIM SM and multicast routing enabled?
By default, R3 will NOT BE THE DR of R3-R5. So it cannot send any PIM Join/Leave messages or any PIM Register messages. So… does this mean that it cannot send a PIM Join for 224.0.1.40? In theory it shouldn’t matter because the MA is already sending that traffic to R3, but…
R3 MRT
R3 does not process the RP-Mappings. Even if it becomes the DR of R3-R5 segment. Why?. The only way that R3 processes the RP-Mappings is with the command:
I cannot understand why R3 does not process the RP-Mapping without this command. I was expecting that if R3 was the DR of R3-R5, then it should be able to do it. But nothing.
- And finally, once R3 processes the RP-Mapping, thanks to the ip pim autorp listener command it will flood it towards R1. Like in the previous answer I posted, if R1 happens to be the DR of R1-R3, then no further configuration is needed on R1 to process the RP-Mapping. If not, the ip pim autorp listener command is needed.
This is what confuses me so much: why on R1, if is the DR, does NOT need the ip pim autorp listener command to process RP-Mappings sent by R3; but on R3 is needed even if R3 is the DR for R3-R5 to process RP mappings from the MA (R5)?
Why R3 does not behave the same as R1 for RP-Mapping messages received?
Thanks, Jose
Hello, everyone.
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.
I have a question. R4, R2, and R6 did not send a PIM Join thus the other routers won’t forward the multicast RP mapping to them.
However, why is R3 (the MA) generating them? Technically, no one even sent the PIM Join to R3, did they?
Thank you.
David
Hello Jose
Kudos on your labbing methodology. Let’s see if we can come to some conclusions about your experimentation.
It seems that the DR behaves differently for the RP announcement (i.e., it will process it if it is the DR in the segment) and differently for the RP mapping packets (i.e., they will not be processed even if the router is the DR on the segment.)
Why is it like this? It is a result of the design process that has been followed by the engineers creating the protocol and its operation. To be honest, I’m not completely sure, but since it was designed this way, there must be a purpose behind it.
Ultimately, it is of little consequence in a production network because best practice dictates that you should apply the auto-rp listener command on all participating routers in such a topology (or use sparse-dense mode as suggested in the lesson) to avoid the possibility of such behavior.
I will let Rene know to make any additions he deems necessary for this lesson. I will also ask him to take a look at your experiment and see if he has any further insight into the specific phenomenon.
I hope this has been helpful!
Laz
1 Like
Thanks very much Laz!
1 Like
Hello David
The MA generates these packets because that is the mechanism that is followed by the MA. When it has received the RP announcement from multiple RPs, it chooses one, and then sends RP mapping messages to 224.0.1.40 out of all of its interfaces where PIM is enabled. This takes place regardless of any join messages that may have been received or not. Now the RP mapping message will only reach directly connected multicast routers, that is R1, R4, and R5, but not R2 and R6 because of the operation of sparse mode… Does that make sense?
I hope this has been helpful!
Laz
Hi @josenogueras2233 ,
I was curious about this so I labbed it, but I’m not having any issues here.
R5#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
L - DR Load-balancing Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
192.168.3.1 GigabitEthernet0/0 00:21:09/00:01:18 v2 1 / S P G
192.168.5.2 GigabitEthernet0/1 00:21:11/00:01:41 v2 1 / DR S P GR6 is the DR. R5 has no issues:
R5#show ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP-mapping agent
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:00:21, expires: 00:02:33
Group(s): 224.0.0.0/4, Static
RP: 2.2.2.2 (?)ip pim autorp listener enabled on all routers.
This can be tricky sometimes. There’s a difference in receiving and processing though. With some commands, you can’t tell exactly what it does. Sometimes you can debug it, perhaps with debug ip pim and if you are lucky it tells you whether something is processed or ignored. It’s likely that you don’t see anything though when something like ip pim autorp listener is disabled.
There’s no way to tell exactly why, unless it is perhaps explained in a RFC how something should act. Otherwise, only those who wrote the code could tell.
Rene
Thanks for your interest Rene. I guess it is how the code has been written. I spent toomany hours to find another answer but with your response it means that you are right. If you can take a look at the PIM NBMA Mode experiment that I did, thanks.
1 Like
Hi,
I’m confused about some of the entries in your mrouting tables.
E.g., on R2 it shows:
(*, 224.0.1.40), 00:15:11/00:02:53, RP 0.0.0.0, flags: DPL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
Which seems to imply that there is no interface on R2 that has joined the 224.0.1.40, but how is that possible?
On my setup, I can see…
H3#sh ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
224.0.1.40 GigabitEthernet0/0 00:00:14 00:02:45 155.1.23.10
and…
(*, 224.0.1.40), 00:11:43/00:02:35, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/0, Forward/Sparse, 00:01:06/stopped
My labs show that the first interface I configure PIM on joins 224.0.1.40, and the mroute entry adds that interface to its OIL, which makes sense.
But why is it missing on R2 (and R3/4 further down)?
Thanks.
Sam
Hello Samir
Hmm, it seems that this output you shared:
…is actually output from R1 and not R2. 
The output on R2 is the following:
R2#show ip mroute | begin 224
(*, 224.0.1.40), 00:19:14/00:02:36, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/1, Forward/Sparse, 00:19:12/00:02:36
… and there is an outgoing interface here, which is Gi0/1, the R1-facing interface.
On your setup you are showing an outgoing interface, but I’m not sure on which router, because I see “H3” on your show ip igmp groups command, and then a route but I don’t know which router that’s on…
I think that’s what I see in the lesson too. Can you take a look to confirm?
I hope this has been helpful!
Laz
Hi Laz,
Yes, I you are correct, it’s actually R1, but I would still expect to see an output interface as all routers join 224.0.1.40…
I copied Rene’s lab including using the configs supplied in the lesson, and R1’s output is exactly as I would expect:
(*, 224.0.1.39), 02:46:39/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), 02:46:39/00:02:23, flags: PT
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list: Null
(*, 224.0.1.40), 02:46:39/stopped, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 02:46:37/00:02:23
(2.2.2.2, 224.0.1.40), 00:07:36/00:02:18, flags: LT
Incoming interface: GigabitEthernet0/1, RPF nbr 192.168.12.2
Outgoing interface list:
Loopback0, Forward/Sparse, 00:07:36/00:02:23
However, it differs from the lab output in the lesson, which shows the (*, 224.0.1.40) and (2.2.2.2, 224.0.1.40) OIL as being Null.
UPDATE:
I managed to re-create the output from the lesson by shutting down the loopback interface. This caused IGMP group 224.0.1.40 to be registered on the Gi0/1 interface instead of lo0. This resulted in the OIL becoming set to null.
Thanks.
Sam
Hello Sam
Ah, I see what you mean, my apologies. It seems that you are correct, I will let Rene know to take a look and consider making any necessary adjustments to the lesson…
Thanks for spending the time to work this one out…
Laz