From: Przemyslaw Karwasiecki (karwas@xxxxxxxxxxx)
Date: Tue Feb 05 2002 - 19:50:53 GMT-3
Alan,
This router with 700 routes via iBGP does have remaining 103300 routes,
but from eBGP, right?
Przemek
On Tue, 2002-02-05 at 17:33, Manny Gonzalez wrote:
> Is there a STOP command? Something to let us turn that behaviour off?
> The way I see it is, if the router with the 104000+ routes suddenly
> dies, the other router (the one with 700 routes) has to then get all
> these routes from it's remote-as peer and that could take a while (if
> never, or until refreshed) Unless I missed something in your email, this
> is not what would like my routers to behave like...
>
> :-))
>
> "W. Alan Robertson" wrote:
> >
> > Folks,
> >
> > Just to let you know, I ran across what looked like a bug in Cisco's
> > BGP code... Turns out, this is undocumented new behavior.
> >
> > We just deployed a pair of 3640s for one of our customers, for
> > dual-router, dual-homed Internet connectivity. We are taking full
> > tables from Genuity (AS 1), and Worldcom (AS 701).
> >
> > Each router was learning 104,000+ prefixes from each of the external
> > peers, but the iBGP peering was acting really strange. One of the
> > routers was learning the full table from the other, but the second
> > router was only taking like 700 prefixes.
> >
> > When we cleared the internal peer (soft or hard), we could see the
> > whole table being transferred... It would climb as though it were
> > going to learn them all, and then as it approached 100,000 prefixes,
> > it would rapidly drop back down to 700. I debugged the iBGP peer, and
> > saw it issuing withdrawls for all of these routes.
> >
> > We opened a ticket with the TAC, and they initially believed it to be
> > a bug as well. Upon further review, they came back and told us that
> > this was the desired behavior in the newer code (We are running
> > 12.0(20) on these boxes). In order to conserve memory, and processor,
> > if an iBGP peer learns that another iBGP peer already has a better
> > route to a specific prefix, it will issue a withdrawl to that peer
> > for the prefix(es).
> >
> > I spent quite a while second guessing what seemed to be a very simple,
> > straighforward configuration. I have done several near identical
> > deployments in the past.
> >
> > I guess the moral is this: If you know your config is correct, and
> > the router behavior is not what you expect, do not hesitate to call
> > the TAC.
> >
> > I hope they are as helpful on Monday, when I call them from the CCIE
> > Lab in RTP. ;)
> >
> > Regards...
> >
> > Alan
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:12 GMT-3