Hi, On Wed, Apr 24, 2019 at 08:06:18AM -0700, Randy Bush wrote: > > My conclusion then was that something along the following line happens > > > > - router R1 remembers where an UPDATE was sent to > > - export policy on R1 is changed, changing whether or not a given > > peer would receive an UPDATE for a given prefix > > - R1 receives withdraw from his best (and only) path, prefix is gone > > - R1 sends withdraw to "all peers it remembers" > > - and something goes wrong if that list of peers is not reflecting the > > real set of peers, possibly due to "BGP internal state not fully in > > sync between 'export policy is changed' and 'withdraw comes in'", so > > R1 is no longer aware that one of his neighbours received the prefix > > originally. > > believable conjecture. could and should be tested in lab.
Indeed.
> but does not explain the cases where we see stuck routes on devices
> which have no config changes for a loooong time (if you believe rancid).
Well, in the scenario above, R1 would have the config change, but *on R1*
the route would be gone. A downstream router R2 would have seen the
initial UPDATE, but never received a withdraw - so R2 would claim "I have
it, and I have it from R1!" while R1 would claim "no such prefix".
So, no contradiction.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
signature.asc
Description: PGP signature
