>From your 'sh ip bgp' output, it's a no-brainer that it selected the second route... In addition to a Local Preference, you've got AS pre-pending occurring on the path learned via 10.1.1.6. These two routes are not "equal" in the eyes of BGP... One is a single AS hop away, and the other is Four (4) AS Hops away.
You've also originated a route prefix in two separate AS's, which while technically possible (I guess), is never supposed to happen. Alan ----- Original Message ----- From: "Przemyslaw Karwasiecki" To: "Peter van Oene" Cc: "W. Alan Robertson" ; "Groupstudy - CCIELAB" ; "Groupstudy - Cisco Certification" Sent: Tuesday, February 05, 2002 8:27 PM Subject: Re: Undocumented iBGP Behavior (Confirmed by Cisco) > After siple lab experiment I need to disagree with your statement. > > > 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. > > I belive that you are overinterpreting meaning of administrative > distance. > > You are right that aministrative distance of eBGP routes is 20 > versus 200 for iBGP routes, but in the situation when BGP process > receives 2 routes for the same prefix, it applies first standart > BGP selection mechanism: > http://www.cisco.com/warp/public/459/25.shtml > and after best route is selected it is going to be inserted into > routing table with specific administrative distance. > > I have replicated following scenario in my lab. > > There are 2 external ASes 1, and 2, originating > prefix 1.1.1.0/24 and advertising it to 2 routers > r1 and r2 via eBGP. > > Routers r1 and r2 are iBGP peers. > > Prefix 1.1.1.0/24 originated from AS2 has longer AS_PATH > (as prepend applied 3 times) > > > Please see folowing commands executed on r2: > > r2#sh ip bgp > BGP table version is 4, local router ID is 172.168.32.1 > Status codes: s suppressed, d damped, h history, * valid, > best, i - > internal > Origin codes: i - IGP, e - EGP, ? - incomplete > > Network Next Hop Metric LocPrf Weight Path > * 1.1.1.0/24 10.1.1.6 0 0 2 2 2 2 i > *>i 10.1.1.8 0 100 0 1 i > r2#sh ip rou > r2#sh ip route > Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP > D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area > N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 > E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP > i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS > inter area > * - candidate default, U - per-user static route, o - ODR > P - periodic downloaded static route > > Gateway of last resort is not set > > 1.0.0.0/24 is subnetted, 1 subnets > B 1.1.1.0 [200/0] via 10.1.1.8, 00:09:26 > 172.168.0.0/24 is subnetted, 1 subnets > C 172.168.32.0 is directly connected, Loopback0 > 10.0.0.0/16 is subnetted, 2 subnets > C 10.10.0.0 is directly connected, Serial0 > C 10.1.0.0 is directly connected, Ethernet0 > r2# > > As you can see, BGP process on r2 selects route learned > from its iBGP peer over route learned via eBGP, > and this route is eventualy inserted to routing table > with administrative distance of 200 > > > Correct me if I am ovrlooking something, > and thank you for excelent idea for testing. > > > Przemek > > > On Tue, 2002-02-05 at 19:35, Peter van Oene wrote: > > 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=34556&t=34556 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
