Alan, TAC engineer actually told you this is a new feature? Did you ask him since when?
BGP only tells its peers the best route it selects, this is not a new feature, AFAIK. If you consider your AS as one unit, it should look like this: For the routes that your AS prefers AS1, in your router connects to AS1, you will only see one ebgp path for this route, as this is the best path this router is using, it will tell its ibgp peers which is the router links to AS701. On the 701 router, you will see two bgp paths with the ibgp path being preferred, but there is no point for this router to advertise its ebgp path for this route to the first router, because the ebgp path is not the best path. My .02 Kent Yu ""W. Alan Robertson"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Yes it does, and that would determine which of the two available > routes makes it into the actual IP routing table... It does not > explain why the router only has one BGP learned route to choose > from... > > > ----- Original Message ----- > From: "Peter van Oene" > To: "Przemyslaw Karwasiecki" ; "W. Alan Robertson" > > Cc: "Groupstudy - CCIELAB" ; "Groupstudy - > Cisco Certification" > Sent: Tuesday, February 05, 2002 7:35 PM > Subject: Re: Undocumented iBGP Behavior (Confirmed by Cisco) > > > > cisco by default prefers ebgp over ibgp. it should not, by default, > enjoy > > the ibgp routes learned from the peer over the ebgp learned routes. > > > > > > > > At 05:37 PM 2/5/2002 -0500, Przemyslaw Karwasiecki wrote: > > >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=34555&t=34548 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
