Os incidentes de 2023 na LON2 da LINX transformaram o estado real

Resumo

Em 20 de junho de 2023, uma conexão de fibra apagada na LON2 falhou. Segundo a LINX, a perda inicial não afetou imediatamente os membros, mas reduziu a resiliência da plataforma. Essa distinção é essencial: o serviço continuava operando, porém dentro de uma condição de risco diferente. [1][2]
Em 21 de junho, a LINX observou descartes no Flowmon, oscilações em enlaces entre switches, perda de tráfego e problemas de alcance na LAN de peering. A recuperação envolveu a desativação de enlaces e, posteriormente, de uma agregação entre dispositivos de núcleo. [1]
Em 22 de junho, restavam problemas de alcance para endereços IP específicos. A LINX informou que endereços MAC apareciam na tabela de software de um equipamento de borda, mas não na tabela de hardware. A limpeza da sessão BGP L2VPN EVPN entre os VTEPs afetados repovoou a tabela de hardware. [1]
A LINX também relatou que um roteador recém-instalado havia sido usado em laboratório. Embora a configuração antiga de OSPF e Router ID tivesse sido removida e uma nova identidade implantada via NETCONF, o processo OSPF continuou usando o identificador anterior porque não havia sido limpo. [1]
O caso não demonstra que OSPF, EVPN, VXLAN, automação ou hardware desagregado sejam inerentemente inseguros. Ele demonstra que configuração pretendida, execução bem-sucedida de automação e estado operacional são evidências diferentes.
Os episódios de 29 de junho e 5 de novembro ampliam a necessidade de controles duráveis, mas não autorizam a conclusão de que todos os sintomas tiveram uma única causa. O registro inclui nova perda de alcance, manutenção de fibra por fornecedor, alteração de software, reversão e investigação ainda em andamento. [1]
O relatório anual de 2023 registrou disponibilidade de 99,997% para a LON2, abaixo da meta interna de 99,998% da LINX. O indicador confirma relevância operacional, mas não identifica todos os membros, prefixos, pacotes, sessões ou consequências. [2]
A fronteira de responsabilização está nos controles que comprovam o estado em execução: identidade única observada ao vivo, processos reinicializados quando necessário, adjacências coerentes, estado EVPN consistente, entradas instaladas em hardware, failover exercitado na topologia degradada e alcance validado na borda dos membros.
Responsabilidade distribuída não significa responsabilidade indefinida. A LINX controlava a admissão de equipamentos, a automação de configuração, o sequenciamento de manutenção, o monitoramento, o isolamento de enlaces, a limpeza de sessões e as comunicações sobre o serviço. Fornecedores controlavam partes do reparo físico e da investigação de produto. Os membros controlavam suas próprias sessões e decisões de continuidade.
O padrão final é o da rede em funcionamento. Inventário, configuração, automação e indicadores agregados são registros necessários; nenhum deles substitui a prova de que os pacotes atravessam a infraestrutura pelo caminho esperado.

Uma falha que começou como perda de resiliência

A cronologia pública começa em 20 de junho de 2023, quando uma conexão de fibra apagada da LON2 falhou. A LINX descreveu o efeito imediato como redução de resiliência, sem impacto inicial para os membros. [1] Esse detalhe impede uma interpretação simplista. A primeira falha não deve ser reescrita retrospectivamente como uma interrupção imediata do serviço. Ao mesmo tempo, não pode ser tratada como irrelevante apenas porque o tráfego ainda fluía.

Uma rede redundante pode continuar disponível depois da perda de um caminho físico. O que muda é a margem operacional. A mesma ativação de equipamento, manutenção ou oscilação de enlace que seria absorvida em uma topologia íntegra pode ganhar outra importância quando parte da diversidade já foi perdida. A rede continua funcionando, mas passa a depender de um conjunto menor de caminhos, equipamentos e estados de protocolo.

No dia 21, segundo a LINX, surgiram descartes identificados pelo Flowmon, oscilações em enlaces entre switches, perda de tráfego e problemas de alcance na LAN de peering da LON2. Engenheiros desativaram enlaces durante a recuperação. Em seguida, uma agregação de enlaces entre dispositivos de núcleo também foi desativada como contorno para restaurar o serviço de maneira mais ampla. [1]

Em 22 de junho, a condição geral havia melhorado, mas alguns endereços IP continuavam apresentando problemas de alcance. A LINX observou endereços MAC na tabela de software de um equipamento de borda que não apareciam na tabela correspondente do hardware. A limpeza da sessão BGP L2VPN EVPN entre os VTEPs envolvidos fez com que essas entradas voltassem a ser instaladas no hardware. [1]

Essa sequência atravessa várias camadas da infraestrutura. Há uma falha física de fibra, uma condição de resiliência reduzida, instabilidade em enlaces entre switches, identidade de protocolo, estado EVPN e divergência entre uma visão mantida pelo software e aquilo que o circuito de encaminhamento realmente conseguia executar. Qualquer análise que escolha apenas uma dessas camadas perde a característica mais instrutiva do incidente: registros localmente corretos podem coexistir com um caminho de pacotes incorreto.

Um sistema de gestão pode mostrar que a alteração foi aceita. A interface pode aparecer operacional. A sessão de controle pode estar estabelecida. A tabela de software pode conter o endereço MAC esperado. Ainda assim, o pacote pode não ser encaminhado se o estado necessário não tiver chegado ao hardware ou se a topologia efetiva não corresponder àquela pressuposta pelos controles.

Por isso, o primeiro evento precisa integrar a análise mesmo sem impacto imediato aos membros. A perda da fibra alterou a condição de operação dentro da qual as ocorrências posteriores foram enfrentadas. Não é necessário afirmar que a fibra causou todos os sintomas. Basta reconhecer que uma rede com redundância reduzida oferece menos espaço para que uma segunda anomalia permaneça isolada.

Redundância é um estado verificável, não uma propriedade do diagrama

A palavra “redundância” frequentemente descreve a arquitetura nominal: dois caminhos, dois equipamentos, duas plataformas ou múltiplas sessões. Em operação, porém, redundância só existe quando os caminhos alternativos permanecem independentes, configurados, observáveis e aptos a transportar o tráfego necessário após a falha considerada.

A LON2 integra a oferta de peering da LINX em Londres e existe ao lado da plataforma fisicamente separada LON1. Os materiais públicos da organização descrevem essa arquitetura de duas LANs e a evolução da LON2 para um modelo desagregado baseado em EVPN. [3][4][5][6] Essa separação fornece opções arquiteturais, mas não permite presumir como cada membro as utilizava nem se cada alternativa estava disponível para um membro específico durante os incidentes.

Depois da falha de fibra de 20 de junho, a pergunta operacional não era simplesmente quantos enlaces apareciam no desenho original. Era quais caminhos permaneciam utilizáveis, quais inter-switch links carregariam o tráfego, como as agregações reagiriam, quais VTEPs continuariam alcançáveis e se as entradas necessárias estavam realmente programadas no plano de dados.

Uma declaração de estado degradado deveria alterar as regras de mudança. Ativações não essenciais podem precisar ser adiadas. O conjunto de alterações pode ser reduzido. O canário pode exigir cobertura mais próxima da arquitetura real. Os critérios de interrupção e reversão precisam ser mais rigorosos. Se uma mudança prosseguir, o responsável deve registrar que conhece a perda de margem e quais controles compensatórios foram executados.

O material público não informa todas as decisões tomadas pela LINX naquele período. Portanto, essas exigências são consequências de engenharia derivadas do caso, não alegações sobre procedimentos internos não divulgados. A distinção importa: responsabilização técnica identifica o controle e a evidência necessários sem inventar uma falha processual específica.

O controle mais básico é tornar a degradação legível para os sistemas de operação. Se a indisponibilidade de um caminho vive apenas em uma conversa ou em um chamado isolado, ferramentas de mudança podem continuar avaliando a rede segundo a topologia nominal. O estado degradado precisa estar associado aos componentes, serviços e janelas afetados.

A etapa seguinte é testar o caminho que de fato assumiu a carga. Um canário executado apenas em um trecho saudável pode confirmar a coisa errada. Quando a exposição está no enlace alternativo, em determinada combinação de leaf e spine ou em um VTEP que ganhou maior importância após a falha, o teste precisa atravessar justamente essa condição.

Também deve existir um critério de parada definido antes da ativação: Router ID duplicado, vizinhança inesperada, aumento de descartes, oscilação de enlace, ausência de entrada no hardware ou falha de sonda voltada aos membros. A reversão se torna mais rápida quando a equipe não precisa negociar, durante o evento, se o sinal observado é grave o bastante.

A fronteira entre laboratório e produção

A divulgação tecnicamente mais significativa da LINX envolve um roteador recém-instalado que havia sido usado em laboratório. O equipamento originalmente compartilhava um Router ID com outro dispositivo em produção. A LINX informou que a configuração antiga de OSPF e do identificador havia sido removida, e que um novo Router ID fora implantado por NETCONF. Mesmo assim, o processo OSPF continuou usando a identidade anterior porque não havia sido limpo. [1]

Essa diferença é o centro do caso. O estado pretendido estava correto, mas o processo em execução não havia adotado integralmente a mudança. Um repositório de configuração poderia mostrar o valor novo. Uma transação de automação poderia confirmar que a instrução foi aceita. Um inventário poderia associar o identificador correto ao equipamento. Nenhum desses registros provaria, sozinho, que o processo OSPF abandonara o valor antigo.

Equipamentos de laboratório são, por natureza, reutilizados. Eles recebem configurações temporárias, participam de topologias variadas, executam imagens diferentes e podem ter processos reiniciados ou preservados conforme a necessidade do teste. Essa flexibilidade é útil, mas significa que um equipamento transferido à produção deve ser tratado como portador de estado não confiável até que o contrário seja comprovado.

“Limpar a configuração” não é uma definição suficientemente precisa para essa fronteira. Dependendo da plataforma, podem sobreviver estado de processo, arquivos de inicialização, adjacências, caches, credenciais, mapeamentos de VLAN ou VNI, informações de VTEP, tabelas de encaminhamento e diferenças de imagem. Nem todo componente persiste da mesma forma, e o incidente não fornece um inventário privado do que existia no roteador. O princípio aplicável é exigir uma transição de estado documentada e verificada.

Essa transição deve começar com a identificação inequívoca do hardware, da imagem de software, da função de produção, da fonte de configuração e dos identificadores que o dispositivo usará. Deve haver um procedimento conhecido de reconstrução ou sanitização, bem como uma definição dos estados que precisam ser limpos, reiniciados ou recriados.

Depois, a verificação precisa ocorrer no equipamento e no domínio ao redor dele. O roteador candidato deve informar seu Router ID atual, mas os vizinhos também devem confirmar qual identidade observam. Uma checagem negativa precisa demonstrar que o valor não está sendo usado por outro processo no domínio relevante. Verificar somente o banco de inventário seria repetir o erro conceitual revelado pelo caso: confundir o registro de intenção com o comportamento da rede.

A entrada em produção deve depender de pós-condições. Automação via NETCONF é valiosa para consistência, velocidade e auditabilidade, mas uma execução bem-sucedida precisa ser seguida por consultas que demonstrem o efeito. Se determinada alteração exige limpeza de processo, reinicialização ou reboot para assumir vigência, essa ação e seu resultado devem fazer parte do contrato de implantação.

O aprendizado, portanto, não é rejeitar automação. É torná-la mais operacionalmente exigente. O pipeline precisa perguntar não apenas “o comando foi aceito?”, mas “a identidade viva mudou?”, “os vizinhos enxergam a identidade correta?”, “as adjacências esperadas foram restabelecidas?” e “o plano de encaminhamento ficou coerente?”.

Identidade OSPF como recurso operacional

A especificação do OSPF define o Router ID como um número de 32 bits que identifica o roteador no sistema autônomo. [11] Sua função não é decorativa. Ele associa um originador aos anúncios de estado de enlace e permite que os demais participantes raciocinem sobre a topologia.

Documentação operacional de fornecedor classifica Router IDs duplicados como uma anomalia crítica e recomenda identificadores únicos. [18] Essa referência explica o risco geral do protocolo; ela não identifica o fornecedor do equipamento usado pela LINX nem atribui a ele a causa do evento. A afirmação específica sobre a identidade residual vem do relato da própria LINX. [1]

A singularidade do identificador precisa ser garantida em dois lugares. Primeiro, no sistema que o aloca: inventário, fonte de verdade ou mecanismo equivalente. Segundo, no protocolo em execução, onde o identificador produz consequências. Se esses dois planos divergem, é o plano operacional que determina como a rede se comporta.

Isso expressa uma visão disciplinada de registro e realidade. Inventários e registros são livros de controle indispensáveis: documentam a intenção, estabelecem responsabilidade e reduzem conflitos. Mas não são soberanos sobre o código em execução. A rede não encaminha pacotes porque uma linha de banco de dados afirma que deveria encaminhá-los.

A solução não é desvalorizar o registro. É vinculá-lo à observação. Uma linha de inventário para o Router ID deveria apontar para uma validação que inclua o valor pretendido, o valor informado pelo processo local, a identidade observada pelos vizinhos, a varredura de duplicidade e a ação usada para descartar o estado anterior.

O mesmo princípio alcança outros recursos de identidade: números de sistemas autônomos, endereços de loopback, endereços da LAN de peering, VTEPs, interfaces, VLANs, VNIs e endereços MAC. Cada um possui regras próprias, mas todos exigem respostas claras para quatro perguntas: quem aloca, quem aplica, como o conflito é detectado e quem pode autorizar uma exceção.

Em uma infraestrutura compartilhada, erros de identidade ultrapassam o equipamento individual. Uma identidade duplicada ou residual altera a forma como outros dispositivos interpretam anúncios e adjacências. Por isso, a admissão deve consultar o sistema de fora para dentro, e não apenas pedir ao novo roteador que declare estar correto.

O que EVPN e VXLAN acrescentam ao problema de evidência

A LINX descreveu a LON2 como uma arquitetura leaf-spine desagregada que usa EVPN sobre VXLAN. [1][3] Em termos simplificados, o VXLAN encapsula quadros de camada 2 sobre uma rede IP entre pontos de terminação de túnel. O EVPN usa BGP para distribuir informações de alcance do overlay. As RFCs 7348, 7432 e 8365 documentam esses mecanismos e sua aplicação em redes de virtualização. [13][14][15]

Essa arquitetura separa funções de maneira deliberada. O underlay fornece alcance IP estável entre os VTEPs. O plano de controle EVPN distribui informações sobre onde determinados endereços podem ser encontrados. Em seguida, o equipamento precisa transformar essas informações em entradas usadas pelo hardware para encaminhar pacotes.

A separação aumenta a escala e a flexibilidade, mas também cria superfícies distintas de verificação. A sessão BGP pode estar estabelecida sem que uma entrada específica tenha sido corretamente instalada. A tabela mantida pelo software pode conter um endereço MAC que o circuito de encaminhamento não conhece. A conectividade de gerenciamento pode permanecer normal enquanto um subconjunto do tráfego falha.

Foi exatamente essa diferença observável que tornou o relato da LINX especialmente relevante. Em 22 de junho, determinados endereços MAC apareciam na tabela de software de um equipamento de borda, mas não na tabela de hardware. Depois que a sessão BGP L2VPN EVPN entre VTEPs afetados foi limpa, as entradas voltaram a ser populadas no hardware. [1]

A conclusão deve permanecer estreita. O episódio não prova um defeito universal no EVPN, no VXLAN ou no BGP. Também não demonstra que toda entrada ausente tinha a mesma origem. Ele prova que, naquele contexto relatado, consultar apenas a visão de software não era suficiente para confirmar a capacidade de encaminhamento.

A RFC 9062 é pertinente porque descreve requisitos operacionais, administrativos e de manutenção para EVPN, incluindo a necessidade de mecanismos que relacionem as visões do plano de controle ao comportamento do plano de dados. [17] Ela não diagnostica a implementação da LINX e não identifica o defeito investigado. Sua utilidade é fornecer uma referência para o tipo de prova que o encerramento operacional precisa produzir.

Para um Internet Exchange, essa reconciliação é particularmente importante. A LAN de peering sustenta interconexões entre sistemas autônomos independentes. Membros podem estabelecer sessões bilaterais, utilizar route servers ou combinar diferentes opções. Os route servers facilitam a distribuição de rotas, mas não substituem o encaminhamento correto da malha que transporta os pacotes. [7][8][9][12]

Uma falha seletiva pode, portanto, conviver com indicadores agregados aparentemente saudáveis. A maior parte dos endereços MAC pode estar presente. O tráfego total pode continuar elevado. Algumas sessões BGP podem permanecer ativas. Ainda assim, um conjunto de destinos pode ficar inalcançável por causa de uma entrada ausente, de determinado caminho ou de uma programação incompleta no hardware.

O teste precisa operar na granularidade em que a falha acontece. Não basta verificar o estado geral do fabric. É necessário selecionar combinações representativas de leafs, VTEPs, bridge domains e caminhos; comparar as visões de software e hardware; e enviar tráfego real pelo percurso que será usado pelos membros.

Plano de controle não é plano de dados

Em redes modernas, é comum tratar a convergência do plano de controle como evidência de recuperação. Uma sessão restabelecida, uma rota reaprendida ou um endereço MAC visível pode sugerir que a situação foi normalizada. Esses sinais são necessários, mas o caso LON2 mostra por que não são conclusivos.

O plano de controle representa decisões e informações. O plano de dados executa o encaminhamento. A passagem entre os dois depende de processos de programação, sincronização e recursos do hardware. Uma divergência pode ser parcial: algumas entradas funcionam e outras não; uma tabela de alto nível está correta, mas a tabela usada para transmitir o pacote está incompleta.

Por isso, uma validação robusta precisa combinar pelo menos quatro perspectivas. A primeira é a intenção, registrada na fonte de verdade e na configuração. A segunda é o estado de protocolo, observado localmente e pelos vizinhos. A terceira é o estado de encaminhamento, incluindo a instalação no hardware. A quarta é o resultado externo: o pacote atravessou o caminho esperado de forma bidirecional?

Essas perspectivas devem compartilhar a mesma janela temporal. Uma captura da configuração feita antes da alteração não prova o estado posterior. Uma tabela coletada depois de uma limpeza de sessão não explica necessariamente o que existia no momento da falha. Sondas, telemetria, comandos operacionais e registros de mudança precisam de timestamps sincronizados e de uma distinção entre horário do evento, horário da observação e horário da ação.

O BFD pode fornecer detecção rápida de falhas de caminho em cenários apropriados, conforme a RFC 5880, mas nenhum mecanismo isolado cobre todos os estados envolvidos. [16] Um enlace ou uma sessão pode estar vivo enquanto uma entrada específica de encaminhamento está ausente. A escolha da telemetria deve acompanhar a classe de falha que a arquitetura pode produzir.

O fechamento de uma mudança em EVPN deveria, portanto, verificar pós-condições selecionadas: alcance do underlay entre VTEPs, adjacências esperadas, rotas EVPN, mapeamentos de VNI, entradas MAC/IP nas visões disponíveis, programação em hardware e sondas de pacote. Se a plataforma expõe contadores de falha de programação ou discrepâncias, esses sinais precisam integrar o gate.

A lição não é exigir a inspeção de todas as entradas da rede a cada mudança. É construir amostragem orientada a risco. Um canário pode usar endereços e caminhos conhecidos, atravessar os componentes alterados e comparar resultados antes e depois. A amostra precisa ser suficientemente representativa para detectar a classe de divergência que o incidente tornou plausível.

O 29 de junho e o 5 de novembro não devem ser comprimidos em uma causa única

A atualização da LINX também registra novos problemas de alcance em 29 de junho e um episódio em 5 de novembro, após manutenção de fibra apagada realizada por fornecedor. O documento menciona uma alteração de software destinada a tratar o comportamento da tabela MAC em hardware, a reversão dessa mudança depois do evento de novembro e a continuidade da investigação do fornecedor. [1]

Esses registros reforçam a necessidade de verificação durável. Eles não permitem afirmar que todos os episódios resultaram do Router ID duplicado ou de um único defeito. Sintomas semelhantes podem surgir de combinações diferentes de falha física, estado de protocolo, programação do hardware e sequência operacional.

O registro de junho sobre o processo OSPF é específico: a identidade antiga permaneceu ativa depois da remoção da configuração correspondente. A observação sobre as tabelas MAC também é específica: o software possuía entradas ausentes no hardware. Já a sequência de novembro envolve manutenção de fibra, uma alteração de software, reversão e investigação ainda aberta.

Uma narrativa de causa única seria mais simples, mas tecnicamente mais fraca. Recorrência de “problemas de alcance” não é suficiente para provar recorrência do mesmo mecanismo interno. A confiança aumenta quando o mesmo padrão de divergência é reproduzido sob condições comparáveis, com telemetria e estado de dispositivo que permitam conectar o sintoma ao mecanismo.

Durante a recuperação, várias ações podem ocorrer próximas: desativar enlaces, limpar sessões, reiniciar processos, reinicializar equipamentos, alterar software ou reverter uma versão. O serviço pode voltar sem que a equipe consiga isolar imediatamente qual ação foi decisiva. Isso é aceitável durante a prioridade de restauração, mas precisa ser reconhecido no trabalho posterior de investigação.

Cada ação corretiva deveria declarar a hipótese que pretende testar. Se a hipótese envolve identidade OSPF residual, a evidência é uma identidade única depois da limpeza do processo, confirmada localmente e pelos vizinhos. Se envolve divergência de tabela MAC, a evidência combina tabelas de software e hardware, estado EVPN e tráfego. Se envolve a fibra, a evidência inclui diversidade física restaurada e failover exercitado.

Uma reversão de software é um dado importante, mas não prova por si só que a versão revertida causou todos os sintomas. O registro deveria preservar versão anterior, versão implantada, horário, condição da fibra, sintomas observados, horário da reversão e resultado dos testes posteriores. Sem isso, a recuperação pode ser confundida com diagnóstico conclusivo.

Preservar incerteza não enfraquece a responsabilização. Ao contrário, evita que uma explicação conveniente se transforme em controle mal direcionado. Uma organização aprende mais quando mantém hipóteses concorrentes e especifica o teste capaz de rejeitar cada uma.

O que um registro seguro de admissão deveria demonstrar

Um registro de admissão para um roteador vindo de laboratório precisa começar antes da conexão ao fabric. Ele deve identificar o equipamento, a imagem de software, a configuração de origem, a função de produção, as interfaces previstas e os identificadores que serão usados. O objetivo é permitir que outra pessoa qualificada reconstrua o que foi aprovado.

A procedência do equipamento deve ser acompanhada por uma definição de sanitização. Não basta declarar que a configuração anterior foi removida. É preciso listar quais estados persistentes podem sobreviver na plataforma e qual ação os elimina: reconstrução, limpeza de processo, remoção de arquivos, restauração de baseline, reinicialização ou outro procedimento documentado.

A identidade vem em seguida. O registro deve mostrar o Router ID OSPF pretendido, o valor efetivamente usado pelo processo, a visão dos vizinhos e uma busca de duplicidade no domínio. Se houve mudança de identificador, precisa registrar a limpeza ou reinicialização necessária e o restabelecimento das adjacências sob a identidade nova.

O underlay requer validação própria. Loopbacks de VTEP devem estar alcançáveis pelos caminhos esperados. Estado de interfaces, métricas, agregações e adjacências precisam corresponder à topologia aprovada. Se a rede está degradada, o teste deve considerar a falha já presente e demonstrar que os caminhos restantes suportam o encaminhamento necessário.

O overlay também precisa de evidência. O equipamento deve anunciar e aprender as informações EVPN esperadas. Route targets, bridge domains, VLANs e mapeamentos de VNI devem ser comparados à fonte de verdade. Rotas, vizinhos ou endereços MAC inesperados devem bloquear a admissão até que sua origem seja compreendida.

A reconciliação de encaminhamento é o ponto decisivo. Uma seleção de entradas MAC e IP precisa existir tanto na visão de software quanto na de hardware, quando a plataforma oferece ambas. Em seguida, testes de pacote devem atravessar as combinações relevantes de leafs, VTEPs e caminhos. O relato da LINX torna inadequada qualquer regra segundo a qual a presença em software, sozinha, significa prontidão.

Testes negativos merecem o mesmo peso. Não deve haver Router ID duplicado, vizinho inesperado, VTEP residual do laboratório, VLAN não aprovada, route target não registrado nem entrada confinada ao software. Verificações de ausência são frequentemente negligenciadas porque é mais simples confirmar que um objeto esperado existe. A principal função do gate, entretanto, é encontrar o resíduo perigoso antes do tráfego real.

O monitoramento precisa estar vinculado antes da exposição. Telemetria de fluxo, estado de enlace, sessões do plano de controle, alarmes de programação de hardware e sondas voltadas aos membros devem identificar o novo dispositivo e suas dependências. Cada alerta precisa de responsável e autoridade clara para reversão.

A ativação deve usar um canário limitado, porém representativo. Dependendo do desenho, isso pode significar um conjunto controlado de caminhos ou uma janela de menor risco. O canário não pode contornar o EVPN, a fibra alternativa ou o hardware que está sendo validado, pois isso produziria uma confirmação sem relação com a exposição real.

O fechamento deve comparar intenção e observação. Checksum da configuração, imagem utilizada, saída de estado vivo, observações dos vizinhos, tabelas de encaminhamento, sondas e telemetria precisam ser preservados com horário. Se uma exceção for aceita, o registro deve indicar proprietário, duração e controle compensatório.

Esse conjunto converte “implantação concluída” em uma afirmação auditável. A mudança não é considerada segura porque a automação terminou sem erro, mas porque a rede demonstrou as pós-condições definidas antes da ativação.

A validação deve chegar à borda dos membros

Um enlace estável no núcleo não prova que um membro consegue alcançar o destino esperado. Uma sessão BGP estabelecida também não. Mesmo a presença de entradas no hardware representa apenas uma etapa do caminho. A recuperação precisa incluir uma dimensão de fora para dentro.

Sondas devem partir de pontos voltados aos membros ou de vantage points que representem realisticamente sua posição. Devem atravessar os caminhos envolvidos e testar alcance bidirecional. Quando pertinente, precisam variar tamanho de pacote ou protocolo, pois um único ping bem-sucedido oferece evidência limitada para um serviço de peering que transporta tráfego diverso.

Os resultados devem ser segmentados. Em 22 de junho, segundo a LINX, havia problemas residuais associados a endereços IP específicos. [1] Um teste amplo poderia indicar que a malha estava saudável enquanto esses casos permaneciam. O fechamento precisa reproduzir a classe exata de falha e mostrar que ela desapareceu.

Isso pode exigir a correlação entre sonda, endereço MAC, estado ARP ou de vizinhança, rota EVPN, VTEP e entrada de hardware. O propósito não é acumular comandos, mas construir uma cadeia curta de evidência: a informação foi aprendida, programada e utilizada para transmitir o pacote.

Relatos dos membros também são sinais operacionais. Eles devem ser correlacionados à telemetria, sem que um lado seja tratado como prova absoluta. Um membro pode enxergar uma falha seletiva que o monitoramento central não captura. Por outro lado, um problema externo ao exchange pode parecer falha da LAN de peering. Horários e dados de caminho compartilhados ajudam a separar as hipóteses.

A diferença entre restauração parcial e completa precisa ser preservada. A cronologia da LINX indica o uso de desativação de enlaces como contorno e a permanência de casos residuais. [1] Um único horário de “serviço restaurado” poderia esconder o período em que a maioria do tráfego havia voltado, mas parte do alcance ainda falhava.

Uma comunicação responsável deve dizer qual escopo foi restaurado, por quais observações isso foi confirmado e o que permaneceu em investigação. Evitar uma promessa universal baseada em uma amostra estreita não é apenas cautela editorial; impede que um contorno intermediário seja registrado como solução definitiva.

Route servers, sessões bilaterais e limites da inferência

Os serviços públicos da LINX incluem opções de peering e route servers que facilitam a troca de rotas entre participantes. [7][8][9] A RFC 4271 define o BGP, protocolo utilizado para intercâmbio de informações de alcance entre sistemas autônomos. [12] Esses elementos explicam o ambiente, mas não revelam a arquitetura de continuidade adotada por cada membro.

Um membro pode usar route servers, sessões bilaterais, mais de uma porta, ambas as LANs de Londres, outros exchanges ou trânsito IP. Outro membro pode ter uma combinação diferente. A presença pública dessas opções não prova que cada participante as contratou, configurou ou testou de forma independente.

Também não se pode assumir que uma segunda conexão representa diversidade efetiva. Dois circuitos podem compartilhar fibra, local, equipamento, alimentação, caminho lógico ou processo operacional. A documentação pública sobre LON1 e LON2 fornece contexto de separação, mas o impacto individual dependeria de fatos não divulgados. [4][5]

A LINX controlava a malha compartilhada da LON2 e podia verificar seu próprio encaminhamento. Os membros controlavam suas sessões, políticas de roteamento e decisões de continuidade. Essa divisão não elimina interfaces comuns. Um teste de ponta a ponta requer coordenação suficiente para relacionar o estado da plataforma ao que o membro observa.

Termos públicos de serviço podem estabelecer definições e responsabilidades contratuais gerais, mas não devem ser usados para inferir perdas, créditos ou violações em um incidente específico sem os fatos e contratos aplicáveis. [10] O registro congelado não apresenta conclusões jurídicas nem um cálculo de danos.

A pergunta produtiva é: qual parte possuía cada decisão e cada evidência? Quem sabia que a fibra estava degradada? Quem podia adiar a ativação? Quem verificou a identidade viva? Quem tinha autoridade para limpar o processo ou desativar o enlace? Quem comparou as tabelas? Quem testou o alcance na borda? Quem comunicou os casos ainda residuais?

Essa matriz é mais útil que a busca prematura por um único culpado. Incidentes de rede atravessam limites técnicos e organizacionais. Atribuir cada controle a um proprietário revela lacunas sem exigir uma acusação de negligência.

Responsabilidade distribuída sem culpa inventada

A LINX controlava o processo pelo qual o roteador entrou na malha, além da automação de configuração, do monitoramento, do sequenciamento de manutenção, do isolamento de enlaces, da limpeza de sessões e das comunicações relativas ao exchange. Essas são superfícies diretas de controle, mesmo quando hardware ou fibra são fornecidos por terceiros.

Fornecedores de fibra controlavam reparo e manutenção dentro de seus respectivos escopos. Fornecedores de equipamentos ou software controlavam investigação de produto, análise de defeitos e correções disponíveis. O fato de uma investigação ter continuado não prova responsabilidade jurídica do fornecedor; demonstra apenas que o trabalho técnico permanecia aberto.

Os membros controlavam suas próprias conexões e políticas. Não há base pública para concluir que todos tiveram a mesma exposição, que todos perderam alcance ou que qualquer desenho alternativo funcionou da mesma forma para cada participante.

Responsabilidades podem se sobrepor. O exchange opera a plataforma; o fornecedor mantém determinado componente; o membro decide como conectar sua rede. Uma boa governança transforma essa sobreposição em interfaces explícitas: quem declara a degradação, quem autoriza a mudança, quem executa o teste, quem aceita o risco e qual evidência encerra cada ação.

O mesmo rigor deve orientar a linguagem pública. O relato da LINX sustenta afirmações atribuídas sobre observações e ações. As RFCs sustentam explicações sobre protocolos. Documentos de fornecedores sustentam práticas gerais. Nenhuma dessas fontes fornece a configuração privada completa, a conduta de cada pessoa, o impacto financeiro de cada membro ou um padrão jurídico de cuidado.

Responsabilização técnica pode ser firme sem ultrapassar essas fronteiras. É possível afirmar que a admissão deveria provar a identidade em execução, que o fechamento deveria reconciliar hardware e software e que a degradação deveria alterar o gate de mudança. Não é necessário afirmar que alguém foi negligente ou ocultou evidências.

O que o número de disponibilidade mostra — e o que ele não mostra

O relatório anual de 2023 da LINX informa disponibilidade de 99,997% para a LON2, abaixo da meta interna de 99,998%, e associa o resultado a vários incidentes. [2] A diferença decimal parece pequena, mas o valor operacional depende da definição usada para serviço, intervalo, população e indisponibilidade.

Uma porcentagem agregada resume desempenho. Ela não identifica quais membros conseguiam trocar tráfego, quais portas ou VLANs estavam envolvidas, se o alcance era simétrico ou se um subconjunto permaneceu afetado por mais tempo que a maioria.

Falhas seletivas são especialmente fáceis de diluir. Se o indicador depende de tráfego agregado, participantes não afetados podem mascarar a perda de um grupo menor. Se depende do estado elétrico das portas, pode ignorar um caminho que permanece “up” sem alcançar determinados destinos. Se depende de alarmes, herda os pontos cegos do sistema de monitoramento.

A definição do indicador precisa, portanto, fazer parte da evidência. É necessário conhecer denominador, exclusões de manutenção, vantage points, sondas e limiares. Para uma malha EVPN de peering, evidências úteis incluem sondas entre posições representativas, continuidade dos route servers, sessões bilaterais selecionadas, verificações do overlay e reconciliação de tabelas MAC e de hardware.

Nenhuma medida isolada representa o serviço inteiro. O percentual anual deve ser rastreável até eventos de nível inferior, permitindo compreender por que uma ocorrência contou de determinada maneira. Isso não exige publicar topologia sensível ou dados confidenciais de membros. Um operador pode manter detalhes restritos e divulgar conclusões delimitadas sobre escopo, tempo, confiança e remediação.

A divulgação técnica da LINX é valiosa justamente porque vai além do percentual. [1][2] Ela descreve sintomas, ações e observações internas suficientes para transformar o evento em aprendizado operacional. O que permanece ausente deve continuar ausente da conclusão: não há uma lista completa de membros afetados nem base para converter 99,997% em perdas financeiras presumidas.

Um modelo de evidência para recorrências

Recorrência precisa ser analisada com pacotes de evidência versionados. Cada correção deveria registrar a hipótese tratada, a mudança esperada no sistema e o teste usado para confirmar o resultado.

Para a identidade do roteador, a hipótese é que o processo OSPF manteve o Router ID antigo. A correção esperada é uma identidade viva única depois da limpeza apropriada. A evidência inclui estado local, visão dos vizinhos e busca de duplicidade.

Para a diferença entre tabelas MAC de software e hardware, a hipótese envolve programação ou sincronização entre controle e encaminhamento. A correção esperada é consistência das entradas e passagem dos pacotes. A evidência combina tabelas, sessão EVPN, contadores e sondas.

Para a fibra degradada, a hipótese diz respeito à redução de diversidade e à topologia assumida pelos caminhos restantes. A correção esperada é a restauração da diversidade física acompanhada de failover controlado. A evidência inclui estado óptico ou de enlace, mapa de dependências, capacidade e testes sob falha.

Para uma alteração de software, a hipótese deve ser ligada a um defeito ou sintoma específico. Instalar a versão sem erro não prova que a anomalia desapareceu. Uma reversão também não demonstra, sozinha, que a versão era a causa. A sequência precisa registrar versões, horários, sintomas e resultados posteriores.

Todos esses pacotes devem usar uma linha do tempo coerente. Relógios inconsistentes podem associar incorretamente uma mudança de controle a uma perda de tráfego anterior ou posterior. Telemetria, equipamentos, registros de mudança, chamados e comunicações precisam de timestamps confiáveis.

Com essa base, incidentes podem ser comparados sem serem achatados. Se novembro reproduzir a mesma divergência de hardware sob topologia semelhante, aumenta a confiança em um mecanismo compartilhado. Se apenas o sintoma externo se repetir, a conclusão deve permanecer mais cautelosa.

Esse método também separa recuperação de aprendizado. Na fase de recuperação, reiniciar um equipamento ou limpar uma sessão pode ser a ação prudente mesmo sem diagnóstico completo. Depois, a organização precisa reconstruir qual estado foi alterado e qual teste demonstra que a mitigação continua válida.

Métricas de governança que reflitam a rede real

Taxa de sucesso de implantação e tempo médio de recuperação são indicadores úteis, mas incompletos. Uma implantação pode ser declarada bem-sucedida pelo sistema de automação enquanto um processo conserva identidade antiga. Uma recuperação pode parecer rápida em média enquanto alguns destinos permanecem inalcançáveis.

Um programa de admissão deveria medir falhas de pós-condição. Quantas vezes a identidade pretendida difere daquela observada ao vivo? Quantos equipamentos exigem uma limpeza ou reinicialização não planejada? Quantas admissões revelam vizinhos, rotas, VTEPs ou entradas residuais? Com que frequência tabelas de software e hardware divergem durante o canário?

A exposição em estado degradado também deve ser mensurável. Por quanto tempo a rede operou sem a diversidade prevista? Quantas mudanças ocorreram nesse intervalo? Quais foram explicitamente aceitas como risco? Cada uma usou um canário representativo e preservou evidência de reversão?

A validação voltada aos membros merece um indicador próprio. Em cada incidente relevante, qual parcela do serviço afetado foi testada a partir de vantage points representativos? Quanto tempo separou a restauração ampla da solução dos casos residuais? As sondas com falha e os retestes bem-sucedidos foram mantidos?

A completude da evidência pode ser medida sem virar burocracia. Um encerramento pode verificar se contém telemetria sincronizada, topologia, identidade de protocolo, estado de encaminhamento, sondas, proprietários das ações e limites das conclusões. Uma lacuna indica onde a própria organização não conseguiu provar aquilo que declarou.

Essas métricas não devem se tornar teatro de conformidade. Uma equipe pode maximizar a quantidade de checkboxes e ainda não detectar divergências reais. Amostragem independente, comparação com incidentes e testes de pacote mantêm o sistema conectado à realidade operacional.

Um gate prático para redes brasileiras

Operadores brasileiros de IX, telecomunicações, data centers e redes corporativas podem aplicar a mesma disciplina sem copiar a arquitetura da LON2. O ponto não é padronizar comandos, e sim exigir evidência equivalente para cada plataforma.

Antes da mudança, o gate deve congelar identidade do equipamento, imagem, configuração pretendida, função, dependências e condição atual da rede. Se uma rota física, um circuito ou um equipamento redundante já estiver indisponível, isso precisa aparecer como entrada explícita para a decisão.

Na etapa de sanitização, a equipe define quais estados de laboratório podem sobreviver e executa o procedimento adequado. O resultado deve ser verificável, não apenas assinado. Quando há dúvida sobre persistência, uma reconstrução conhecida pode ser preferível a uma sequência de remoções cuja cobertura não é demonstrável.

Na etapa de identidade, o equipamento e seus vizinhos são consultados. Router IDs, ASNs, endereços de loopback, VTEPs e parâmetros de peering são comparados com a fonte de verdade. Duplicidades ou resíduos bloqueiam a ativação.

Na etapa de controle, são validados underlay, sessões, rotas, mapeamentos e adjacências. Na etapa de dados, são verificadas as estruturas que o hardware usa e são enviados pacotes por caminhos representativos.

Em uma rede degradada, o canário deve atravessar o caminho remanescente, não um segmento confortável e intacto. Critérios de parada devem incluir os sinais específicos que a arquitetura pode produzir, como oscilação de enlace, divergência de tabela, perda de sonda ou identidade inesperada.

A conclusão deve ter duas assinaturas lógicas: a da intenção e a da realidade. A primeira confirma que a configuração aprovada foi entregue. A segunda confirma que o sistema em execução assumiu o estado esperado e encaminhou o tráfego.

Esse modelo é compatível com automação. Consultas, comparações, testes negativos e sondas podem integrar o pipeline. O trabalho humano se concentra nas exceções, no desenho da amostra e na decisão sobre risco residual.

O que o registro público não estabelece

As fontes disponíveis não identificam todos os membros, prefixos, sessões, sites ou volumes de tráfego afetados. Não oferecem a duração completa de cada problema de alcance nem a configuração privada dos equipamentos, o conteúdo integral das transações de automação ou o registro de defeito do fornecedor.

Elas não estabelecem que o Router ID OSPF duplicado, sozinho, explique todos os sintomas de junho e novembro. Também não demonstram que EVPN, VXLAN, OSPF, automação ou hardware desagregado sejam inerentemente inseguros.

A primeira falha de fibra não deve ser descrita como impacto imediato aos membros, pois a LINX declarou que o efeito inicial foi a redução de resiliência. [1] A disponibilidade anual não pode ser convertida em um total de perdas por cliente. [2]

O material também não estabelece negligência, violação contratual, ocultação de evidência ou responsabilidade jurídica de uma pessoa, da LINX ou de um fornecedor. A investigação aberta e a reversão de software são fatos técnicos delimitados, não decisões legais.

Esses limites definem a confiança da análise. As afirmações mais fortes são aquelas atribuídas diretamente à LINX. As RFCs explicam comportamentos de protocolo dentro de seu escopo. Orientações de fornecedor sustentam práticas gerais, sem identificar a plataforma ou a causa específica do incidente.

A rede em execução é o registro final

A lição duradoura da LON2 não é que laboratórios sejam perigosos nem que fabrics modernos tenham complexidade excessiva. É que a transição entre intenção e operação precisa ser comprovada.

Um repositório pode conter o Router ID novo. O NETCONF pode entregá-lo. O inventário pode associar o equipamento à função correta. O plano de controle EVPN pode exibir um endereço MAC aprendido. Um painel de disponibilidade pode permanecer próximo de 100%. Cada registro tem valor, mas todos podem estar corretos enquanto o caminho do pacote continua errado.

O registro operacional final é a rede em execução: identidade de protocolo única observada no domínio, adjacências atuais, estado EVPN coerente, entradas instaladas no hardware, caminhos físicos estáveis e alcance demonstrado a partir de posições representativas.

Esse padrão fortalece a automação. Uma automação que apenas entrega configuração é um mecanismo de execução. Uma automação que verifica pós-condições, compara observações independentes e bloqueia divergências torna-se parte do controle de risco.

Para um Internet Exchange, o padrão é especialmente importante porque a malha compartilhada conecta redes independentes. O exchange não controla a política de cada membro, mas pode provar o estado da infraestrutura que oferece: declarar degradação, rejeitar identidade duplicada, reconciliar controle e encaminhamento, testar caminhos representativos e preservar honestamente aquilo que ainda não sabe.

A contribuição do relato da LINX está na combinação de detalhes. Há uma fibra degradada sem impacto imediato, uma identidade OSPF antiga preservada no processo, uma diferença entre tabelas MAC de software e hardware, contornos operacionais, episódios posteriores e investigação ainda em curso. [1] Esses elementos não devem ser transformados em uma história simplista de culpa. Devem ser convertidos em gates de admissão e em evidências capazes de tornar a próxima transição entre laboratório e produção mais segura.

Nomes de arquitetura não garantem continuidade. Um caminho redundante que nunca foi exercitado é uma promessa. Uma identidade nova presente apenas na configuração pretendida é uma promessa. Uma entrada MAC visível somente em software é uma promessa. A responsabilização começa quando o operador demonstra, a partir da rede em funcionamento, que cada promessa se tornou realidade de encaminhamento.

Os incidentes de 2023 na LON2 da LINX transformaram o estado real da rede em um teste de responsabilização

Por que isso importa