Resumo

  • Quadros LACP restritos ao enlace escaparam de uma relação de porta de cliente, alteraram o estado de LAGs de terceiros e fizeram sessões BGP oscilar na malha de peering compartilhada.
  • Responsabilização exige invariantes de fronteira, conformidade do provisionamento, testes entre fornecedores, alarmes exercitados, evidência de rollback e caminhos alternativos comprovadamente utilizáveis.

A pergunta de responsabilização

Uma Internet Exchange existe para permitir que redes distintas troquem tráfego de forma eficiente sobre uma infraestrutura compartilhada. O benefício econômico vem justamente do compartilhamento: várias organizações interligam seus roteadores a uma malha comum, estabelecem sessões de roteamento e evitam que todo o tráfego precise atravessar relações de trânsito mais longas ou caras. O mesmo compartilhamento, porém, transforma o isolamento entre participantes em uma propriedade fundamental.

O incidente da AMS-IX não foi apenas uma queda genérica de rede. Seu mecanismo público envolve um quadro de controle que deveria ter relevância local, dentro de uma relação adjacente, mas atravessou a fronteira de uma porta e influenciou o estado operacional de outros participantes. Quando isso ocorre, a pergunta deixa de ser apenas “qual equipamento enviou o quadro?” e passa a incluir “quais controles deveriam ter impedido que esse quadro afetasse terceiros?”.

Essa distinção é importante porque origem e contenção são responsabilidades diferentes. Um equipamento de cliente pode produzir tráfego inesperado, incorreto ou incompatível com o perfil da porta. Uma malha compartilhada, por sua vez, precisa tratar essa possibilidade como condição a ser contida. A proteção não pode depender exclusivamente de cada participante produzir apenas quadros perfeitamente alinhados à configuração registrada pelo operador.

Registros de participantes, números de sistemas autônomos, interfaces atribuídas e perfis pretendidos de porta são evidências essenciais. Eles permitem reconstruir quem estava conectado, qual serviço havia sido provisionado e qual política deveria estar em vigor. Esses registros, entretanto, não filtram pacotes. A realidade operacional é determinada pelo código executado, pela configuração efetivamente aplicada, pelo comportamento das ACLs, pelas decisões de encaminhamento dos switches, pelo estado dos LAGs, pelas sessões BGP que permanecem estabelecidas e pela disponibilidade real de rotas alternativas.

Por isso, a responsabilização neste caso não depende de acusar uma organização ou um fornecedor. Ela depende de relacionar controles a resultados observáveis. Se uma regra afirmava que quadros LACP não deveriam atravessar determinada fronteira, a evidência decisiva é demonstrar que todas as variantes de porta impunham essa regra. Se o provisionamento deveria gerar uma ACL, é necessário provar que a ACL foi criada, instalada, validada e mantida após mudanças de software.

Se caminhos alternativos faziam parte da estratégia de continuidade, é necessário mostrar que tinham capacidade e podiam ser acionados quando a malha principal se tornou instável.

Dois períodos oficiais, não uma duração presumida

A AMS-IX delimitou dois períodos afetados. O primeiro ocorreu em 22 de novembro de 2023, das 19:08 às 23:04 CET. O segundo ocorreu em 23 de novembro de 2023, das 09:38 às 10:25 CET. Essas janelas devem ser preservadas porque representam os intervalos oficiais divulgados pelo operador. Não é adequado condensá-las em uma única interrupção contínua nem ampliar a duração com base em sintomas isolados observados fora desses períodos.

Durante o primeiro intervalo, a plataforma apresentou flapping ativo de sessões LACP e BGP. “Flapping” descreve uma sucessão de mudanças de estado: uma associação ou sessão deixa de estar disponível, tenta retornar e pode cair novamente. Em uma malha de peering, esse comportamento é particularmente perturbador porque não produz apenas um estado binário e estável de “funcionando” ou “fora do ar”. Ele pode provocar repetidas reconvergências, mudanças na seleção de caminhos e respostas diferentes entre participantes.

A AMS-IX reportou que o tráfego da plataforma caiu até um ponto mínimo de 2,1 Tb/s. Também informou que o número de sessões BGP IPv4 caiu de 885 para 550 e que o número de sessões IPv6 caiu de 800 para 450. A redução simultânea do tráfego e das sessões é compatível com uma perda significativa de estabilidade na plataforma, mas não revela, por si só, como cada rede ou serviço foi afetado.

O segundo intervalo, na manhã de 23 de novembro, mostra que a primeira estabilização não encerrou de forma definitiva todos os sintomas associados ao evento. Um retorno posterior da instabilidade amplia a importância de separar mitigação imediata de reparo durável. Reiniciar, isolar temporariamente um elemento ou reduzir carga pode estabilizar uma plataforma; isso não demonstra automaticamente que a condição de fronteira que permitiu o vazamento foi eliminada em todas as portas e em todos os tipos de equipamento.

A cronologia pública também precisa ser lida ao lado das ações das redes conectadas. Alguns participantes desviaram tráfego, desativaram sessões ou recorreram a caminhos fora da AMS-IX enquanto a plataforma compartilhada ainda estava instável. Para esses participantes, parte da recuperação percebida por clientes pode ter ocorrido antes de uma estabilização completa da exchange. Para outros, a ausência de capacidade alternativa suficiente pode ter prolongado ou agravado a indisponibilidade.

Existem, portanto, pelo menos três relógios de recuperação. O primeiro é o relógio da própria plataforma: quando os elementos da malha deixaram de oscilar e voltaram a operar de forma estável. O segundo é o relógio de cada rede conectada: quando ela conseguiu retirar tráfego da área afetada, restabelecer sessões ou usar outro caminho. O terceiro é o relógio do serviço de ponta a ponta: quando usuários e aplicações voltaram a alcançar destinos com desempenho aceitável.

Misturar esses relógios cria conclusões imprecisas. Uma queda menor no tráfego da exchange pode significar que redes foram deslocadas para outros caminhos, e não que a demanda desapareceu. Uma sessão BGP restabelecida indica conectividade de controle entre dois roteadores, mas não prova que toda a capacidade ou todas as aplicações tenham retornado. Da mesma forma, uma rede que conseguiu desviar tráfego não comprova que todos os demais participantes possuíam opções equivalentes.

O que as métricas demonstram — e o que não demonstram

O ponto mínimo de 2,1 Tb/s é uma medida agregada da plataforma. Ele ajuda a visualizar a escala da redução em relação ao comportamento normal observado no gráfico da exchange, mas não informa quais fluxos deixaram de passar, quais foram redirecionados ou quais continuaram com degradação. A partir desse número isolado, não se pode calcular quantos usuários perderam conectividade nem quantas aplicações falharam.

As contagens de sessões BGP também têm um significado específico. A queda de 885 para 550 em IPv4 representa 335 sessões a menos no ponto reportado. A queda de 800 para 450 em IPv6 representa 350 sessões a menos. Essas diferenças quantificam uma alteração severa no plano de controle da plataforma, mas uma sessão não equivale a um cliente individual, a uma aplicação ou a uma quantidade fixa de tráfego. Uma rede pode manter várias sessões, e sessões distintas podem carregar volumes muito diferentes.

Também não se deve converter essas métricas em prova de uma interrupção europeia universal. A AMS-IX é uma infraestrutura importante e interliga muitas redes, mas a Internet possui relações de trânsito, outros pontos de troca, interconexões privadas e caminhos internacionais. A capacidade de contornar uma falha varia conforme topologia, contratos, automação, capacidade ociosa e decisões operacionais de cada participante.

As métricas são fortes como evidência de que a malha perdeu estabilidade e de que o evento se propagou para além de uma única porta. São fracas para atribuir perdas específicas sem dados adicionais. Uma avaliação completa exigiria, entre outros elementos, telemetria por participante, históricos de sessão, volumes por interface, perdas de pacote, latência, decisões de roteamento, alarmes, dados de serviços de ponta a ponta e informações sobre os caminhos alternativos acionados.

Essa limitação não reduz o valor dos números publicados. Pelo contrário, define corretamente o que eles podem sustentar. Eles mostram que a perturbação atingiu o plano de controle e o volume de tráfego da exchange em escala relevante. Não mostram o conjunto completo de consequências comerciais, técnicas ou sociais.

Por que um quadro LACP vazado importa

LACP coordena a agregação de múltiplos enlaces entre sistemas adjacentes. Em termos operacionais, ele ajuda os dois lados de uma relação a decidir quais portas pertencem a um grupo, quais estão aptas a encaminhar tráfego e como o conjunto deve responder a mudanças físicas ou lógicas. Seu significado depende da adjacência correta.

Um quadro LACP não é uma mensagem que deva circular livremente por toda a malha como se fosse tráfego comum de um participante. Ele é link-local: sua interpretação pertence à relação imediata entre sistemas. Quando atravessa uma fronteira de cliente, pode ser recebido por equipamentos que não participaram da relação original, mas que reconhecem o protocolo e reagem ao conteúdo.

Segundo a explicação publicada pela AMS-IX, equipamento de um cliente gerou pacotes LACP enquanto estava conectado por uma porta que não usava LACP. O switch provider edge da Juniper propagou esses quadros em vez de contê-los. Outros clientes receberam os pacotes vazados, e seus grupos de agregação reagiram. O resultado relatado foi flapping tanto de LACP quanto de sessões BGP.

A relação entre LAG e BGP é operacionalmente plausível sem que os dois protocolos sejam confundidos. LACP administra o estado de enlaces agregados. BGP estabelece sessões sobre conectividade IP. Se a base de encaminhamento que sustenta uma sessão muda repetidamente, a sessão pode cair, reiniciar ou permanecer instável. A documentação da própria AMS-IX reconhece que mudanças de topologia em agregações podem provocar flapping de BGP e recomenda temporizadores curtos para determinadas condições.

O ponto de responsabilização está na fronteira. Uma política de isolamento robusta deveria impedir que quadros LACP de uma porta de cliente alcançassem outros participantes, independentemente de a porta de origem estar configurada como agregação dinâmica, agregação estática ou conexão sem agregação. A classificação administrativa da porta pode determinar quais controles são gerados, mas não deveria abrir uma exceção que permitisse a propagação de um protocolo link-local.

Isso pode ser expresso como um invariante operacional: nenhum quadro LACP recebido em uma interface voltada a cliente deve ser encaminhado para outra relação de cliente da malha compartilhada. O invariante é mais forte que uma descrição de configuração porque define o resultado que precisa permanecer verdadeiro mesmo quando mudam modelos de equipamento, versões, sintaxe, pipelines de provisionamento ou tipos de serviço.

A porta sem LACP e a lacuna de conformidade

O detalhe de que a porta relevante não usava LACP é central. A AMS-IX informou que já possuía mitigações por ACL para LACP, mas a combinação de perfil de porta e comportamento efetivo não impediu a propagação. Isso indica uma diferença entre a intenção geral de controle e a cobertura real do controle naquele caminho.

Uma plataforma de provisionamento pode aplicar regras diferentes conforme o tipo de porta. Essa diferenciação pode ser tecnicamente legítima, mas cria risco quando um protocolo considerado “não esperado” deixa de receber uma regra explícita de bloqueio. A ausência de LACP como serviço habilitado não elimina a possibilidade de o equipamento conectado transmitir um quadro LACP. Se a malha precisa proteger terceiros, o comportamento seguro é negar a travessia, e não presumir que o quadro nunca aparecerá.

A AMS-IX declarou que o ACL de saída LACP na plataforma Juniper não estava plenamente operacional. Também informou que o ACL de saída nos switches Extreme SLX não se comportou como esperado. O operador disse que ainda não estava claro se o comportamento do SLX se devia a um bug de software ou a uma mudança de sintaxe após uma atualização.

Essa incerteza precisa ser mantida. Sem versões exatas, configurações, histórico da alteração, resultado de testes e conclusões dos fornecedores, não há base pública para escolher entre bug, incompatibilidade de sintaxe, falha de geração, instalação incompleta ou outra explicação. Tampouco há base para atribuir toda a responsabilidade a um fabricante. A política, o provisionamento, a integração e a validação da malha continuavam sob controle operacional da exchange.

O teste adequado não é verificar apenas se um arquivo de configuração contém uma linha esperada. É necessário comparar intenção, configuração renderizada, instalação no equipamento, estado ativo e comportamento observado. Uma ACL pode existir no sistema de origem, mas não ser traduzida corretamente para uma plataforma. Pode aparecer no equipamento, mas estar aplicada à direção ou interface errada. Pode ser aceita pela sintaxe e ainda não produzir a filtragem esperada em determinado caminho de hardware.

Conformidade de provisionamento significa provar que o estado final corresponde à política em todos esses níveis. Para um invariante de isolamento, o teste mais direto é injetar quadros representativos em ambiente controlado e demonstrar que eles não atravessam a fronteira. A presença de configuração é evidência; a ausência do quadro no destino proibido é a demonstração comportamental.

Da oscilação de LAG e BGP à pressão sobre recursos

O relato público descreve uma cascata, não um único mecanismo instantâneo. O gatilho atribuído pela AMS-IX foi o vazamento de quadros LACP. Outros LAGs reagiram, e sessões LACP e BGP oscilaram. Essa atividade aumentou a pressão sobre equipamentos e superfícies de controle.

A AMS-IX afirmou que houve esgotamento de recursos e buffers cheios, produzindo erros de timeout de RSVP. Equipamentos Juniper afetados enviaram mensagens Path Error, que, segundo o operador, criaram problemas adicionais em switches Extreme SLX. A sequência mostra como uma falha de isolamento de camada 2 pode interagir com planos de controle e mecanismos de sinalização utilizados pela infraestrutura subjacente.

O RSVP não deve ser apresentado como causa inicial. Na narrativa pública, ele aparece depois que o flapping e a pressão sobre recursos já estavam em curso. As mensagens Path Error pertencem à sinalização de problemas em caminhos. Seu efeito durante o incidente precisa ser entendido como amplificador dentro de uma condição de estresse, não como prova de que o protocolo RSVP seja inerentemente defeituoso.

Também não é correto generalizar o comportamento exato para todas as redes MPLS. Implementações, topologias, políticas, versões, limites de recursos e mecanismos de proteção variam. Os padrões técnicos ajudam a explicar conceitos como sinalização, caminhos e recuperação, mas não substituem os registros do incidente nem demonstram que outra rede reproduziria a mesma cascata.

A interação entre Juniper e Extreme torna o teste entre fornecedores especialmente importante. Cada plataforma pode funcionar conforme seus testes isolados e ainda reagir de forma inesperada a mensagens, estados ou volumes produzidos pela outra durante pressão de recursos. Um teste de regressão precisa exercitar a cadeia, não somente componentes separados.

Esse teste deveria incluir pelo menos o vazamento simulado de quadros link-local, flapping rápido de LAG, queda e restabelecimento repetido de sessões BGP, ocupação elevada de buffers, geração de mensagens RSVP de erro e comportamento dos switches receptores. Também deveria observar se os alarmes distinguem o sintoma inicial dos efeitos posteriores.

Sem essa separação, a equipe pode responder ao amplificador enquanto a condição de entrada permanece ativa. Pode reiniciar um processo, reduzir carga ou suprimir mensagens e obter estabilidade temporária, mas continuar vulnerável ao mesmo quadro atravessando outra porta. A análise de causa precisa preservar a ordem: fonte do quadro, falha de fronteira, reação de agregações, instabilidade BGP, pressão sobre recursos, sinalização de erro e efeitos cruzados.

Recuperação da plataforma não é recuperação de ponta a ponta

O incidente evidencia a diferença entre estabilizar uma infraestrutura compartilhada e restaurar todos os serviços que dependem dela. A AMS-IX podia trabalhar para conter os quadros, estabilizar os switches e recuperar sessões. Ao mesmo tempo, redes participantes podiam reduzir sua exposição desviando tráfego ou desativando conexões instáveis.

A Total Uptime registrou deslocamento de tráfego e posterior restauração dentro dos limites de sua própria observação. A NFOrce relatou desativação de sessões e mitigação de perda de pacotes. A EDPnet publicou uma cronologia de impacto no serviço, mencionou capacidade alternativa e registrou atualizações de recuperação. Esses relatos são evidências de decisões tomadas por redes conectadas; não constituem uma medição completa de todos os participantes.

Desviar tráfego pode proteger clientes antes que a causa na exchange esteja totalmente eliminada. A mesma ação, porém, transfere carga para outras interconexões. O caminho alternativo precisa ter capacidade suficiente, políticas de roteamento compatíveis e operação estável. Uma rota que existe na tabela, mas satura quando acionada, não oferece continuidade efetiva.

Também é necessário que a organização tenha autoridade operacional para agir. Algumas redes podem retirar sessões automaticamente quando certos limiares são atingidos. Outras podem exigir decisão humana. Uma equipe pode possuir trânsito alternativo, mas hesitar em usá-lo por impacto de custo, risco de congestionamento ou falta de confiança na automação. Continuidade depende tanto do desenho técnico quanto de capacidade, procedimentos e poder de decisão.

Peering remoto pode oferecer outra saída, mas deve ser testado como serviço real. A simples presença de uma relação contratual ou de uma configuração preparada não prova que o caminho aceite o volume necessário durante uma falha importante. O mesmo vale para trânsito IP: diversidade nominal não garante diversidade física ou operacional se os caminhos convergem em infraestrutura comum.

A recuperação deve, portanto, ser medida em camadas. Para a exchange, interessam estabilidade do plano de controle, ausência de quadros proibidos atravessando fronteiras, recuperação de sessões e normalização do tráfego. Para cada participante, interessam alcance de prefixos, capacidade dos caminhos alternativos, perda de pacotes, latência e estabilidade de sessão. Para usuários, interessa se os serviços voltaram a responder de forma aceitável.

Uma plataforma pode ser declarada estável enquanto parte do tráfego ainda percorre rotas alternativas. Uma rede pode anunciar recuperação enquanto alguns destinos continuam degradados. A honestidade operacional exige dizer qual camada foi restaurada, com quais medições e em qual momento.

O que a observação de rotas acrescenta

A análise baseada em RIPE Atlas acrescenta uma perspectiva externa à telemetria da plataforma. Em vez de observar apenas sessões e volumes dentro da exchange, medições distribuídas podem mostrar como caminhos de ponta a ponta mudaram durante o incidente.

Dentro dos limites do pacote de evidências, as observações indicaram que alguns caminhos contornaram o dano, enquanto outros falharam ou mudaram. Esse padrão é consistente com uma Internet que possui alternativas, mas não as oferece de maneira uniforme a todos os pares de origem e destino.

Uma medição de rota pode revelar que um caminho deixou de atravessar a AMS-IX, que outro passou a utilizar uma sequência diferente de sistemas autônomos ou que determinado destino se tornou inalcançável a partir de um conjunto de sondas. Ela não observa todas as redes, todos os usuários ou todas as aplicações. Sua cobertura depende da localização das sondas, dos destinos escolhidos e da visibilidade oferecida pelas respostas coletadas.

Essas limitações impedem conclusões absolutas, mas não tornam a medição irrelevante. A combinação de métricas internas da exchange, relatos de operadores conectados e observações de caminhos oferece uma visão mais equilibrada. A plataforma mostra o que ocorreu em sua malha; os operadores mostram como reagiram; as medições externas mostram parte das consequências sobre rotas observáveis.

Para responsabilização, essa triangulação é valiosa. Ela reduz a dependência de um único tipo de evidência e ajuda a distinguir estabilização interna de deslocamento externo. Também mostra por que um relatório de incidente deve incluir não apenas o momento em que equipamentos voltaram ao estado esperado, mas evidências de como o ecossistema conectado se recuperou.

Controle, evidência e responsabilidade sem acusação jurídica

O cliente não identificado controlava a fonte imediata dos quadros LACP. Isso não significa que exista evidência pública de intenção maliciosa, negligência, ilegalidade ou violação contratual. O equipamento pode ter emitido quadros incompatíveis com o perfil da porta por várias razões, e os dados públicos não revelam o dispositivo, sua configuração ou seu histórico.

A AMS-IX controlava a malha compartilhada e sua fronteira de segurança. Isso incluía o provisionamento, a geração de ACLs, a política de quadros permitidos, a seleção e integração de plataformas, o monitoramento e a comunicação. Identificar esse controle não equivale a concluir responsabilidade legal. Significa apenas reconhecer quais evidências o operador precisaria produzir para demonstrar que os controles planejados estavam ou não implementados.

Juniper e Extreme controlavam suas implementações e poderiam possuir informações sobre comportamento de software, interpretação de sintaxe e reação a mensagens durante pressão de recursos. As conclusões dos fornecedores, versões exatas e resultados de laboratório não estão disponíveis no material público. Qualquer acusação específica contra um deles ultrapassaria a evidência congelada.

As redes conectadas controlavam sua própria resiliência. Podiam decidir quanto trânsito alternativo contratar, se manteriam peering remoto, quais temporizadores utilizariam, como automatizariam a retirada de sessões e quem teria autoridade para agir. Mas suas escolhas aconteciam dentro de restrições econômicas e técnicas. Nem toda organização possui capacidade para duplicar toda a conectividade, e a existência de alternativas não elimina a obrigação da malha compartilhada de aplicar isolamento.

Usuários finais não tinham controle sobre a emissão do quadro, a política da porta, a implementação dos switches, as sessões BGP ou a capacidade alternativa. Eles dependiam de decisões distribuídas entre várias organizações. Essa assimetria é uma razão para exigir relatórios claros: as partes mais afetadas frequentemente são as que possuem menos acesso aos registros técnicos.

A responsabilização adequada não precisa antecipar uma decisão jurídica. Ela pode perguntar, de forma verificável, qual controle deveria existir, quem o operava, qual evidência mostra seu estado, como ele falhou e como a correção foi testada. Essa abordagem evita transformar incerteza técnica em acusação, sem reduzir a exigência de prova operacional.

Compromissos anunciados e reparo verificável

A AMS-IX anunciou várias ações após o incidente. Entre elas estavam aplicar ACLs a enlaces que não usavam LACP, aperfeiçoar a criação de ACLs na pilha de provisionamento, revisar ACLs de saída LACP em plataformas Juniper e Extreme, investigar alertas para BPDUs de Slow Protocols e revisar regras de comunicação em sua lista técnica.

Essas ações respondem a aspectos relevantes do evento. Aplicar filtragem também a portas sem LACP fecha a lacuna criada pela suposição de que tais quadros não apareceriam. Melhorar o provisionamento reduz o risco de políticas declaradas não chegarem aos equipamentos. Revisar plataformas diferentes reconhece que a conformidade precisa sobreviver à heterogeneidade. Alertas específicos podem reduzir o tempo até a detecção. Comunicação mais clara pode ajudar participantes a decidir quando retirar sessões ou desviar tráfego.

Ainda assim, compromissos anunciados não são sinônimo de verificação independente. O público não possui, no pacote congelado, resultados completos que demonstrem a eficácia duradoura de cada medida. Não estão disponíveis matrizes de teste, amostras de configuração atual, versões corrigidas, registros de exercícios de alarme ou conclusões finais dos fornecedores.

Uma verificação robusta deveria provar que o invariante de fronteira vale para todos os tipos de porta. Isso inclui portas com LACP, agregações estáticas e portas sem agregação. Deveria abranger plataformas Juniper e Extreme e qualquer outro equipamento capaz de encaminhar tráfego de clientes na malha.

O provisionamento deveria ser testado como cadeia completa. Uma política criada no sistema administrativo precisa gerar a configuração correta, ser aceita pelo equipamento, tornar-se ativa na direção apropriada e impedir o encaminhamento proibido. Testes posteriores a upgrades deveriam detectar mudanças de sintaxe ou semântica antes que fossem introduzidas no ambiente compartilhado.

Alarmes precisam ser exercitados. Um alerta documentado, mas nunca disparado em teste, permanece uma hipótese. A equipe deve conhecer o sinal esperado quando um quadro de Slow Protocols aparece onde não deveria, saber quem recebe a notificação e demonstrar quanto tempo leva para identificar a porta de origem e aplicar contenção.

Rollback também exige evidência. Se uma mudança em ACL ou software produzir comportamento inesperado, operadores precisam saber como retornar a um estado comprovado. Isso requer versões identificáveis, configurações preservadas, critérios de decisão e ensaios que mostrem que o rollback restaura o isolamento sem introduzir outra instabilidade.

Por fim, redes conectadas precisam verificar suas saídas. Trânsito alternativo e peering remoto devem ser exercitados sob carga realista. Capacidade nominal, rota anunciada e contrato ativo não bastam. O teste precisa mostrar que o tráfego pode ser movido, que as sessões podem ser retiradas com segurança e que o caminho substituto sustenta o serviço durante uma falha relevante da exchange.