BGP withdrawal convergence and shorter prefix

[Dylan Syme]

An AS owns a /20. He advertises the /20 in BGP to ispA and ispB through policies of his own decision (but he definitely advertises the prefix, and the prefix is propagated). Within the /20 is a /24, which at times he wishes to advertise via ispC. ispC propagates said route upstream and traffic traverses ispC by virtue of longest prefix. No problem.

Because the AS is just using prefix-lists and not route-maps, when he wants to move the /24 off of ispC and move it back into the regular /20 announcement, the /24 experiences downtime of up to 3 minutes because using a prefix-list means that this is actually a BGP withdrawal, which take longer to converge.

What I don't get is, given the /20 is still propagated in the internet (routers still have it in their RIB, but install the /24 in the FIB as the preferred route), why should there be downtime.

Let's say we have CarrierA -> CarrierB (carrierB is closer to ispC, and could theoretically be ispC). CarrierA hasn't received the update, so has the /24 and the /20 in his RIB, and the /24 in his FIB. Thus he sends traffic to CarrierB. CarrierB has received the update, so has the /20 only in his RIB and FIB. So should direct the traffic toward ispA and ispB.

What am I missing here?

[milan.kulik]

Hi,

ad

"What I don't get is, given the /20 is still propagated in the internet (routers still have it in their RIB, but install the /24 in the FIB as the preferred route), why should there be downtime.")

I can imagine following scenario:

Let's say ispC is not peering directly to ispA nor ispB but there is ispD (or multiple other ISPs on the path) between them.

So ispC has got the /20 prefix received from ispD in his RIB.

So at the time you sent your /24 withdrawal to ispC, it removes the /24 fro his RIB.

And let's say this withdrawal was not delivered to ispD yet.

So what happeans at that moment when ispD receives a packet with a destination address within the /24 from the Internet?

ispD still has got the /24 prefix in his RIB pointing to ispC. So it forwards the packet to ispC.

But ispC has only /20 in his RIB pointing back to ispD!

So there is a routing loop existing until  BGP gets converged by the /24 withdrawal delivery to ispD.

This was just a very simple example.

But showing your /24 might be not reachable from some parts on the Internet until the BGP is converged.

Best regards,

Milan

[Dylan Syme]

Thanks.  That's probably it.