From: Przemyslaw Karwasiecki (karwas@xxxxxxxxxxx)
Date: Tue Feb 05 2002 - 22:53:23 GMT-3
Yes, it is no brainer.
My point will be expressed much cleaner if I will
add that second route is learned via iBGP, and first
via eBGP.
Please see:
r1#sh ip bgp summ
BGP router identifier 10.10.1.1, local AS number 100
BGP table version is 2, main routing table version 2
1 network entries and 1 paths using 133 bytes of memory
1 BGP path attribute entries using 60 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP activity 1/8 prefixes, 2/1 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
10.1.1.8 4 1 55 55 2 0 0
00:51:29 1
10.10.1.2 4 100 54 53 2 0 0
00:48:57 0
r1#
telnet-server#2
[Resuming connection 2 to r2 ... ]
r2#sh ip bgp summ
BGP router identifier 172.168.32.1, local AS number 100
BGP table version is 4, main routing table version 4
1 network entries and 2 paths using 169 bytes of memory
2 BGP path attribute entries using 120 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP activity 1/13 prefixes, 2/0 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
10.1.1.6 4 2 48 49 4 0 0
00:42:30 1
10.10.1.1 4 100 54 55 4 0 0
00:49:08 1
r2#
Please also note that r1 is not learning from r2 via iBGP any routes,
because r2 is not advertising any routes.
r2#sh ip bgp neighbors 10.10.1.1 advertised-routes
r2#
And the reason is that active (selected) bgp route on r2 is learned
from r1 via iBGP so it cannot be advertised back.
Przemek
Ps.
Sorry for line wraps, I just switched to Evolution and dont know
yet how to increase line length :-)
On Tue, 2002-02-05 at 20:44, W. Alan Robertson wrote:
>
> >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" <karwas@ifxcorp.com>
> To: "Peter van Oene" <pvo@usermail.com>
> Cc: "W. Alan Robertson" <warobertson@earthlink.net>; "Groupstudy -
> CCIELAB" <ccielab@groupstudy.com>; "Groupstudy - Cisco Certification"
> <cisco@groupstudy.com>
> 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
> > > > >
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:12 GMT-3