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 DA 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 DA 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