[routing-wg] New on RIPE Labs: BGP Zombies

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: </ripe/mail/archives/routing-wg/attachments/20190424/c1b4342d/attachment.sig>