I mis-spoke... Naturally, only one of the routes will make it into the actual routing table (unless there are two equal cost paths, and you have enabled 'maximum-paths 2' or better). I should have said that these routes were not in the Loc-RIB table...
A 'show ip bgp' revealed a single entry for each prefix, where there ought to have been two (one learned via the eBGP peer, and a second learned via the iBGP peer). Under normal circumstances, the eBGP learned prefix would be flagged with the '>', indicating that it was the perferred route, and installed in the actual routing table. ----- Original Message ----- From: "Przemyslaw Karwasiecki" To: "W. Alan Robertson" Cc: "Groupstudy - CCIELAB" ; "Groupstudy - Cisco Certification" Sent: Tuesday, February 05, 2002 5:37 PM Subject: Re: Undocumented iBGP Behavior (Confirmed by Cisco) > Correct me if I am wrong but this: > > > 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). > > is perfectly normal, standart behaviour. > If your Genuity route is better, you will select this route > in your routing table, and if by any chance before you had > there UUNET route which you have advertised, you need > to send update with new, better, selected route. > > BGP will never advertise both routes. > This is distant vector after all. > > So if during convergence phase your route selection > is shuffling your routes in your Loc-RIB, you should > to expect series of updates to follow up. > > Przemek > > > On Tue, 2002-02-05 at 16:45, 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=34546&t=34546 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
