Hi, On Sun, Dec 09, 2012 at 10:37:37AM -0500, Chuck Church wrote: > I'm thinking this might be because RTR 2's eBGP has the better path to most > destinations compared to RTR 1, thus RTR 1 sees this and doesn't send those > prefixes back towards RTR 2. Does that sound right?
Exactly so.
> Here's a prefix in question:
> RTR 2:
> BGP routing table entry for 209.209.144.0/20, version 3845458
> Paths: (1 available, best #1, table default)
> Advertised to update-groups:
> 9
> 20115 1299 4323 10397, (received & used)
> 68.115.217.2 from 68.115.217.2 (96.34.212.228)
> Origin IGP, localpref 100, valid, external, best
>
> RTR 1:
> BGP routing table entry for 209.209.144.0/20, version 23114388
> Paths: (2 available, best #1, table Default-IP-Routing-Table)
> Not advertised to any peer
> <------------------------------------- This tells me it's not sent, trying
> to figure out why
Because the only peer he could send it to is RTR 2, and that's where
the best path is learned from -> paths are never sent back to origin
(and only best path is ever announced to peers).
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]
fax: +49-89-35655025 [email protected]
pgpyaTFA33p7z.pgp
Description: PGP signature
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
