From: W. Alan Robertson (warobertson@xxxxxxxxxxxxx)
Date: Tue Feb 05 2002 - 21:55:19 GMT-3
Yes it does, and that would determine which of the two available
routes makes it into the actual IP routing table... It does not
explain why the router only has one BGP learned route to choose
from...
----- Original Message -----
From: "Peter van Oene" <pvo@usermail.com>
To: "Przemyslaw Karwasiecki" <karwas@ifxcorp.com>; "W. Alan Robertson"
<warobertson@earthlink.net>
Cc: "Groupstudy - CCIELAB" <ccielab@groupstudy.com>; "Groupstudy -
Cisco Certification" <cisco@groupstudy.com>
Sent: Tuesday, February 05, 2002 7:35 PM
Subject: Re: Undocumented iBGP Behavior (Confirmed by Cisco)
> 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