I think you are refering to cisco bugid: CSCdv47188 -- snip -- If the first entry in the Multicast Border Gateway Protocol (MBGP) routing table is supernet of the destination IP address or the MBGP route exists but does not have the best path, Reverse Path Forwarding (RPF) lookup will fail or return a unicast Border Gateway Protocol (BGP) route if a unicast BGP route exists. Workaround: Remove the first entry or add a dummy route that is smaller than the first entry. In case of a MBGP route without a best path, change the network configuration to ensure that the specified destination address has the best path. -- snip --
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.
-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.