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