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" > > > 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. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=34569&t=34569 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
