In the referenced message, Jared Mauch said: <snip>
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 on.
- Jared
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 surface.