From: John Elias (jelias_@xxxxxxxxxxx)
Date: Wed Feb 06 2002 - 15:31:33 GMT-3
Guys,
Are you talking about the routing table or the bgp table?
John E.
CCIE #8150
>From: Peter van Oene <pvo@usermail.com>
>Reply-To: Peter van Oene <pvo@usermail.com>
>To: Przemyslaw Karwasiecki <karwas@ifxcorp.com>
>CC: "W. Alan Robertson" <warobertson@earthlink.net>, Groupstudy -
>CCIELAB <ccielab@groupstudy.com>, Groupstudy - Cisco Certification
><cisco@groupstudy.com>
>Subject: Re: Undocumented iBGP Behavior (Confirmed by Cisco)
>Date: Wed, 06 Feb 2002 10:19:23 -0500
>
>I was assuming this was a choice over similar paths..
>
>At 08:27 PM 2/5/2002 -0500, Przemyslaw Karwasiecki wrote:
>>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
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:13 GMT-3