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=34554&t=34554 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
