From: Przemyslaw Karwasiecki (karwas@xxxxxxxxxxx)
Date: Tue Feb 05 2002 - 23:11:30 GMT-3
So what you are implying is that after better route was selected,
the worse one (looser) was never withdrawn?
In which IOS?
My test was done on 12.1.12a
Now I am seriously scared. I am counting days to my T day,
and you have shake my world (at least my confidence of BGP
understanding).
I was always thinkig that BGP router would never advertise
route it will not use by itself.
Refer to RFC1771 section 9.1.3 "Route dissimination"
"All routes in the Local-RIB shall be processed into
a corresponding entry in the associated Adj-RIB-OUT"
For me it means that if route is not in Local-RIB,
it will never be passed to Adj-RIB-OUT, and consequently
to BGP peers.
Moreover -- any changes of Local-RIB should be reflected
in Adj-RIB-OUT and either UPDATEd or WITHDRAWn
Maybe my brain is fried from studying too much,
but for me this behaviour is perfectly normal,
and I would expect that anything other would be
in violation to RFC
Przemek
On Tue, 2002-02-05 at 21:03, W. Alan Robertson wrote:
>
> ----- Original Message -----
> From: "Przemyslaw Karwasiecki" <karwas@ifxcorp.com>
>
> > 5) In phase 5 some of eBGP routes which has lost
> > in BGP selection in phase 3 and has been advertised
> > over iBGP in phase 2 needs to be withdrawn
>
> Yes, that's exactly what is happening, but that represents a change!
> (And is ultimately the point of my original post)
>
> The selection process hasn't changed... All of the old rules apply...
> The change is that the iBGP peers never used to issue withdraws in the
> past. Those alternative, less attractive paths always remained in the
> Adj-RIB-in table of a router, and if the installed route for a prefix
But only this router which is learning them via eBGP.
> needed to come out due to the loss of an external peer, or a withdraw
> from that peer, the formerly less attractive route could be promoted,
> and installed.
>
> Now, instead of the local router promoting the less attractive route
> itself, it does not have that route in it's Adj-RIb-in. It forwards
> the withdraw notice to it's iBGP peer, which turns around and
> advertises that prefix back to the peer, and it then gets installed.
>
> This represents a change in the way the Cisco code is treating these
> less preferred routes.
>
> As I mentioned in another post, this is a very clever change, in that
> it reduces the amount of memory consumed by these less preferred
> routes, and from a functional standpoint, all of the redundancy of
> full peering connections to multiple upstream ISPs is preserved.
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:12 GMT-3