Auto-RP and PIM-SM Issues

GWilliams · ‎05-25-2017

I have five 3850s connected in a routed ring (EIGRP) running Auto-RP and PIM-SM.Â Each 3850 has a few subnets hanging off them that I need to provide multicast routing for and for the life of me I can't get the RP mapping to include all the appropriate RPs for the different multicast subnets. I have been banging my head on this problem for two days now and I don't know where else to turn. Where I think my problem lies is in the forwarding of the Auto-RP-Announcements (224.0.1.39).Â When I inspect the multicast routing tables I am missing (S,G) entries for some of the routers. One in particular I only see the (S,G) entry for him self on him self only. Neither of his neighboring routers have his (S,G) entry in there multicast routing table. In my days of searching for an answer I finally came across a decent troubleshooting guide (Troubleshooting Multicast Routing) and while processing through it the only anomaly I found was in the mtrace outputs.

CCTV-D-C#mtrace 10.21.161.211
Type escape sequence to abort.
Mtrace from 10.21.161.211 to 10.21.161.247 via RPF
From source (?) to destination (?)
Querying full reverse path...
0 10.21.161.247
-1 10.21.161.247 ==> 10.21.161.247 PIM [10.21.161.211/32]
-2 10.21.161.246 ==> 10.21.161.211 PIM_MT [10.21.161.211/32]
-3 10.21.161.211
CCTV-D-C#

The topology is as so, /->R-J1<->R-A<->R-B<->R-C<->R-D<-/, R-D is Connected to R-J1 to complete the loop with each router servicing 2 subnets one with stream sources and the other with receivers. These are all Routed links running PIM sparse mode and every router has Auto-RP enabled. Currently R-D is the mapping agent but the problem persists no matter which router is configured as the mapping agent. The goal is to have each router be the RP for there attached subnets as they will contain the multicast sources and there will be multiple destinations for the stream spread across the other routers.

I have done a few small tests and as long as the RP for the attached subnet is being mapped the multicast session works as intended. I just can't seem to resolve why router R-A is not forwarding any of the 224.0.1.39 traffic to facilitate the Auto-RP mapping agent. 224.0.1.40 is propagating through the network just fine from what I can tell as each router knows about all the same RPs as the mapping agent and I can see the (S,G) entries in there multicast routing tables.

Any help on this would be greatly appreciated. I just don't know what to look for any more.

chrihussey · ‎05-26-2017

Not to say there may be a configuration or bug issue, but I'll just put this out there. Taking into account the ring topology and the dense mode requirement of Auto-RP, it is easy to see how there may be occasional issues with information looping or getting lost.

This network does not appear to be that large. Is it possible that a multicast group(s) could be assigned to each switch, configure static RPs, and eliminate Auto-RP altogether? It would be far more manageable and I'm sure stable.

Like I said, just a thought.

GWilliams · ‎05-26-2017

I have definitely entertained the Idea of static RPs my self. I was hoping to have Auto-RP working on this network before we walk away from it as in the future they may add more areas. I don't want to have to touch all five of these switches if they add a 6th or more. I am definitely no well versed in the multicast domain but you have to start somewhere you know?

a.alekseev · ‎05-26-2017

you can try anycast rp and msdp session between RP's

GWilliams · ‎05-30-2017

Well looks like my configuration was all correct and I ran into a software bug. It took some time to coordinate with the facility but after updating all the switches to the current recommended Firmware version all the switches show the correct RP mappings.

show ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback1)

Group(s) 239.21.160.0/24
RP 10.21.161.208 (?), v2v1
    Info source: 10.21.161.208 (?), elected via Auto-RP
         Uptime: 00:24:31, expires: 00:02:23
Group(s) 239.21.162.0/23
RP 10.21.161.208 (?), v2v1
    Info source: 10.21.161.208 (?), elected via Auto-RP
         Uptime: 00:24:31, expires: 00:02:27
Group(s) 239.21.164.0/23
RP 10.21.161.209 (?), v2v1
    Info source: 10.21.161.209 (?), elected via Auto-RP
         Uptime: 00:11:07, expires: 00:02:47
Group(s) 239.21.166.0/23
RP 10.21.161.210 (?), v2v1
    Info source: 10.21.161.210 (?), elected via Auto-RP
         Uptime: 00:09:06, expires: 00:02:54
Group(s) 239.21.168.0/23
RP 10.21.161.211 (?), v2v1
    Info source: 10.21.161.211 (?), elected via Auto-RP
         Uptime: 00:04:55, expires: 00:02:03
Group(s) 239.21.170.0/23
RP 10.21.161.212 (?), v2v1
    Info source: 10.21.161.212 (?), elected via Auto-RP
         Uptime: 00:04:06, expires: 00:02:51

prashant1990 · ‎08-27-2019

The requirement for auto-rp to work correctly is that you have to enable pim sparse-dense mode on all of the links in the network. What this does is that flooding of 224.0.0.39 and 224.0.0.40 groups in dense mode. So all the routers will know about these groups. The other solution would be configure auto-rp listner feature on all of the layer3 devices. This feature only floods 224.0.0.39 and 224.0.0.40 in dense mode, everything else will be running according to sparse mode. The sparse-dense mode does allow for dense mode fallback in case the RP fails, the auto-rp listner feature does not allow you to do that.

Giuseppe Larosa · ‎08-27-2019

Hello Prashant1990,

Auto-RP groups are 224.0.1.39 and 224.0.1.40 (they are routable over more then one router hop) the rest of your explanation is valid and correct.

Hope to help

Giuseppe