[c-nsp] BGP sanity check

[Gert Doering]

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                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20121209/74d295cf/attachment.sig>