<div dir="ltr">Yeah. This actually would be a fascinating study to understand exactly what happened. The volume of BGP messages flying around because of the session churn must have been absolutely massive, especially in a complex internal infrastructure like 3356 has. <div><br></div><div>I would say the scale of such an event has to be many orders of magnitude beyond what anyone ever designed for, so it doesn't shock me at all that unexpected behavior occurred. But that's why we're engineers ; we want to understand such things. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 2, 2020 at 9:37 AM Saku Ytti <<a href="mailto:saku@ytti.fi">saku@ytti.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 2 Sep 2020 at 16:16, Baldur Norddahl <<a href="mailto:baldur.norddahl@gmail.com" target="_blank">baldur.norddahl@gmail.com</a>> wrote:<br>
<br>
> I am not buying it. No normal implementation of BGP stays online, replying to heart beat and accepting updates from ebgp peers, yet after 5 hours failed to process withdrawal from customers.<br>
<br>
I can imagine writing BGP implementation like this<br>
<br>
 a) own queue for keepalives, which i always serve first fully<br>
 b) own queue for update, which i serve second<br>
 c) own queue for withdraw, which i serve last<br>
<br>
Why I might think this makes sense, is perhaps I just received from<br>
RR2 prefix I'm pulling from RR1, if I don't handle all my updates<br>
first, I'm causing outage that should not happen, because I already<br>
actually received the update telling I don't need to withdraw it.<br>
<br>
Is this the right way to do it? Maybe not, but it's easy to imagine<br>
why it might seem like a good idea.<br>
<br>
How well BGP works in common cases and how it works in pathologically<br>
scaled and busy cases are very different cases.<br>
<br>
I know that even in stable states commonly run vendors on commonly run<br>
hardware can take +2h to finish converging iBGP on initial turn-up.<br>
<br>
-- <br>
  ++ytti<br>
</blockquote></div>