In the referenced message, Jared Mauch said:

On Tue, Feb 05, 2002 at 04:28:39PM -0500, Stephen Griffin wrote:

...

Actually, after confirming with Cisco, the above bug is different. Essentially, if a router has two links, and a route in both iBGP and iMBGP with same igp distance, local pref, mask, etc, the unicast BGP route is chosen for RPF, rather than the multicast route. This would lead to using the "wrong" interface.

Although it is related in that, if the RPF check was done against the MRIB first, it would solve this bug.

does "ip multicast multipath" help you at all either?

that should cause it to rpf down both paths.

- jared

Based upon what I've previously been told, "ip multicast multipath" doesn't actually work yet. I've not tested it. The problems I see are related to short EBGP unicast routes beating long IBGP multicast routes due to the default checks based on administrative distance (ebgp has lower admin distance). (EBGP unicast routes beat IBGP multicast routes, even at the same prefix-length) if the knob is twiddled to do length-based checks, then the problem turns to long unicast routes beat short multicast routes, which can be a problem if someone is doing TE with no-export tagged more-specifics, such that you would have multicast connectivity via the shorter prefix, but follow the path where there is no multicast connectivity. Cisco is aware of my concerns, and the proposed solution of doing multicast RPF checks in the same manner as the MSDP checks (of sorts) with longest-match across the mrib, and falling back to longest-match across the urib (if there's no covering prefix in the mrib) but don't have any timeframe as to when that might be undertaken.