If you can, build your test scenario to look like this:
[eBGP ]
___[AS 1]___
| |
| |
[ eBGP ] [ eBGP ]
[ AS 2 ] [ AS 3 ]
| |
| |
| |
| |
[ BGP ] [ BGP ]
[ AS 4 ] [ AS 4 ]
| |
| |
_|___________|_
Originate a route (say the 10.0.0.0/8 route) in AS 1, and see what
happens in AS 4.
You should see two entries for the 10/8 network in 'show ip bgp'
output, one of which is learned via the eBGP peer, and gets installed
in your routing table, and the second, learned via the iBGP peer,
which does not get installed in your routing table.
That is the time-honored behavior, the behavior we've all come to know
and love since the dawn of time, etc, etc, amen. :)
Now, in 12.0(20), this behavior is changed to they behavior I have
described in this thread. I don't know when this change occurred, but
hope to have that question answered tomorrow. Most of my other BGP
customers are running 12.1 stuff...
----- Original Message -----
From: "Przemyslaw Karwasiecki"
To: "W. Alan Robertson"
Cc: "Peter van Oene" ; "Groupstudy - CCIELAB"
; "Groupstudy - Cisco Certification"
Sent: Tuesday, February 05, 2002 8:53 PM
Subject: Re: Undocumented iBGP Behavior (Confirmed by Cisco)
> 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"
> > 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=34563&t=34563
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
