<div dir="auto"><div>I believe someone on this list reported that updates were also broken. They could not add prepending nor modify communities.</div><div dir="auto"><br></div><div dir="auto">Anyway I am not saying it cannot happen because clearly something did happen. I just don't believe it is a simple case of overload. There has to be more to it.<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">ons. 2. sep. 2020 15.36 skrev Saku Ytti <<a href="mailto:saku@ytti.fi" target="_blank" rel="noreferrer">saku@ytti.fi</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 2 Sep 2020 at 16:16, Baldur Norddahl <<a href="mailto:baldur.norddahl@gmail.com" rel="noreferrer noreferrer" 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>
</div></div>