Hey, Ravi, I thought you fixed that bug? Perhaps AS4005 is not running the fixed code. Perhaps there's another bug.
it's not 'another' bug. (received only) means that soft-reconfiguration is configured for the peer and some policy denied the route so it's not being used - yet. had he did a "sh ip route x.x.x.x" rather than "sh ip bgp x.x.x.x" he would have seen the less specific entry being used. -danny
Hey, Ravi, I thought you fixed that bug? Perhaps AS4005 is not running the fixed code. Perhaps there's another bug.
it's not 'another' bug. (received only) means that soft-reconfiguration is configured for the peer and some policy denied the route so it's not being used - yet.
Yes, I know what "received only" means in this context. It means that AS1673 was announcing the route to DIGEX, but DIGEX was filtering it. That's independent of the issue I am talking about, which is that the BGP sesson between AS3741 and AS6180 had been shut down for several hours, the route in question was no longer present in AS3741, but the route still appeared (with path "1673 1239 4005 3741 6180") at DIGEX's MAE-East looking glass. The route should have been withdrawn completely from the entire Internet when the BGP session between AS6180 and AS3741 was shut down, but the route was not properly withdrawn. DIGEX should not have seen any trace of the route (except perhaps a history entry for flap damping purposes).
had he did a "sh ip route x.x.x.x" rather than "sh ip bgp x.x.x.x" he would have seen the less specific entry being used.
Yes. --apb (Alan Barrett)
===== Alan Barrett previously wrote: ====
That's independent of the issue I am talking about, which is that the BGP sesson between AS3741 and AS6180 had been shut down for several hours, the route in question was no longer present in AS3741, but the route still appeared (with path "1673 1239 4005 3741 6180") at DIGEX's MAE-East looking glass. The route should have been withdrawn completely from the entire Internet when the BGP session between AS6180 and AS3741 was shut down, but the route was not properly withdrawn. DIGEX should not have seen any trace of the route (except perhaps a history entry for flap damping purposes).
It would not hurt to check a few other looking glasses. Such as, route-views.oregon-ix.net or route-server.cerf.net to see if the path is really there. We have found out that some of these looking glasses sometimes keep the routes much longer, at one time several hours after we see routes disppeared in our routers. Just one observation. Jun
to see if the path is really there. We have found out that some of these looking glasses sometimes keep the routes much longer, at one time several hours after we see routes disppeared in our routers.
AFAIK nitrous *is* one of "our routers" (well DIGEX's) - it's done using Cisco autocommands. Alex Bligh Xara Networks
On Fri, 6 Jun 1997, Danny McPherson wrote:
Hey, Ravi, I thought you fixed that bug? Perhaps AS4005 is not running the fixed code. Perhaps there's another bug.
it's not 'another' bug. (received only) means that soft-reconfiguration is configured for the peer and some policy denied the route so it's not being used - yet.
But that doesn't answer the question of why it is still appearing many hours after it has stopped being advertised; we have seen this happen too. Even though it doesn't hurt anything as is because it isn't being used, but what happens if the policy changes so it was being used? Would it magically process a withdrawal that presumably happened some time ago, or would it actually use the bogus route?
participants (5)
-
Alan Barrett -
Alex.Bligh -
Danny McPherson -
Jun Wu -
Marc Slemko