In the referenced message, Jared Mauch said:
I don't take any immediate offense but the number of
multicast connected sites is (slowly) going up. Sprint customers
can toggle their (bgp) session from nlri unicast -> unicast multicast
in order to get mbgp routes and enable pim to do forwarding. Obviously
one needs to chat with someone to get msdp going.
The routers don't tend to have very multicast related bugs anymore,
it's all people who can't configure their routers.
Of the 100+ sessions that are in sdr/sap these days I can typically
reach (at least) 65%+ of them without any problems.
The problem is that the "tier 2" and whatnot providers have [mostly]
missed the boat on it and don't have people that are able to configure
their routers for mbgp. (this is not to say all but most).
There are a lot of resources for getting help in fixing and
deploying multicast these days. It'd be nice to see more people turning it
I'm wondering how may folks are having issues with the oddities related
to Cisco doing RPF checks based on administrative distance, rather than
longest-match against the MRIB. With this, a shorter EBGP-learned route
wins out over a longer IBGP-learned route.
I know it is possible to turn on (via undocumented command) longest-match.
But, it still matches across both the URIB and MRIB equally, such that
a longer unicast prefix wins over a shorter multicast prefix.
Ideally, the RPF checks would be longest-match against the MRIB first,
and falling back to longest-match against the URIB (which is exactly
what the MSDP RPF checks presently do.)
I find it really weird when the "sh ip rpf" lists an ebgp-unicast
route as the rpf source, when an ibgp-multicast route
is available. Essentially makes even exchanging multicast nlri somewhat
pointless, when it is disregarded frequently.
The workaround I've been suggested to use is the undocumented command
and lots of static mroutes (to beat out unicast bgp), whenever problems