North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Reducing Usenet Bandwidth
- From: Stephen Griffin
- Date: Tue Feb 05 17:41:11 2002
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.