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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=34535&t=34535 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
