<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 4 Oct 2021 at 21:58, Michael Thomas <<a href="mailto:mike@mtcc.com">mike@mtcc.com</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">
  
    
  
  <div>
    <p><br>
    </p>
    <div>On 10/4/21 11:48 AM, Luke Guillory
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      
      
      <div><br>
        <p class="MsoNormal"><span>I
            believe the original change was 'automatic' (as in
            configuration done via a web interface). However, now that
            connection to the outside world is down, remote access to
            those tools don't exist anymore, so the emergency procedure
            is to gain physical access to the peering routers and do all
            the configuration locally.<u></u><u></u></span></p>
      </div>
    </blockquote>
    <p>Assuming that this is what actually happened, what should fb have
      done different (beyond the obvious of not screwing up the
      immediate issue)? This seems like it's a single point of failure.
      Should all of the BGP speakers have been dual homed or something
      like that? Or should they not have been mixing ops and production
      networks? Sorry if this sounds dumb.</p></div></blockquote><div><br></div><div>Facebook is a huge network. It is doubtful that what is going on is this simple. So I will make no guesses to what Facebook is or should be doing.</div><div><br></div><div>However the traditional way for us small timers is to have a backdoor using someone else's network. Nowadays this could be a simple 4/5G router with a VPN, to a terminal server that allows the operator to configure the equipment through the monitor port even when the config is completely destroyed.</div><div><br></div><div>Regards,</div><div><br></div><div>Baldur</div><div><br></div><div><br></div><div> </div></div></div>