Yes, it does... So, if the Router with 104k routes from iBGP, and eBGP, loses one from his eBGP neighbor, he will issue a withdrawl to the iBGP peer. The iBGP peer will turn around an announce that it has a route to that prefix...
I understand why this sounds, on the surface, like a terrible thing. In practice, however, it works very well, and makes a lot of sense. I didn't open the case directly (my co-worker did while I was staring at telnet sessions, and cursing under my breath), and I didn't get a chance to ask if this behavior could be disabled. The case is still open, and I'll find out tomorrow. If there's no switch to turn it off, I'll certainly ask for it to be added. Alan ----- Original Message ----- From: "Przemyslaw Karwasiecki" To: "Manny Gonzalez" Cc: "W. Alan Robertson" ; "Groupstudy - CCIELAB" ; "Groupstudy - Cisco Certification" Sent: Tuesday, February 05, 2002 5:50 PM Subject: Re: Undocumented iBGP Behavior (Confirmed by Cisco) > 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 > > > _________________________________________________________________ > > > CCIE Security list: http://www.groupstudy.com/list/security.html > > _________________________________________________________________ > > CCIE Security list: http://www.groupstudy.com/list/security.html Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=34541&t=34541 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
