Reducing Usenet Bandwidth

Mon Feb 4 08:11:06 UTC 2002

	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 at puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.