Resumo

  • Em 26 de junho de 2025, a MIX escreveu que um operador preparado deveria absorver a falha de um IX com medidas como trânsito superdimensionado e estratégia de peering diversificada [1].
  • A mesma nota alertou que instabilidade frequente cria risco por meio da convergência de rotas e da reconvergência de tráfego, mesmo quando a LAN não é inerentemente um ponto único de falha [1].
  • A documentação atual do route server da MIX registra o ASN 61968, listas derivadas de IRR, verificações de AS_PATH, rejeição de rotas RPKI INVALID e communities para controlar a distribuição [2].
  • Esses controles regem a admissão e a divulgação de rotas; não criam capacidade alternativa, diversidade física ou prova de recuperação da aplicação.
  • A prestação de contas precisa ligar o desenho pretendido às retiradas reais, à seleção de caminho, ao tráfego deslocado, à margem restante e ao resultado do serviço.

O alcance da posição da MIX

A MIX não afirmou que um ponto de troca jamais pode sofrer interrupção. Afirmou que uma rede preparada não deveria depender de uma única LAN para toda a sua conectividade. A nota cita duas opções concretas: capacidade de trânsito com folga e diversidade de peering [1]. Assim, a continuidade não pertence apenas ao operador do IX.

O ponto de troca oferece um ambiente comum. Seus membros continuam sendo sistemas autônomos que escolhem upstreams, PNIs, outros IXs, preferências BGP, communities e limites de capacidade. A presença de uma segunda rota não prova que ela será escolhida a tempo, que todos os prefixos necessários serão aceitos ou que o caminho suportará a carga transferida.

A observação da MIX sobre reconvergência torna a tese auditável. Muitas sessões podem mudar quase ao mesmo tempo. Links de trânsito confortáveis para o desvio cotidiano podem receber uma carga correlacionada muito maior. Um teste isolado de link não mede esse comportamento coletivo.

Redundância de topologia não é resultado de continuidade

A continuidade deve ser registrada como transição entre estados executados. Antes da mudança, o participante precisa inventariar sessões externas, função de cada vizinho, conjuntos de rota esperados, local preference, communities, limites de prefixo e capacidade. Também deve indicar qual caminho receberá o tráfego quando o peering principal desaparecer.

Durante a mudança, deve guardar horários de estado de sessão, withdrawals, anúncios alternativos, decisão de melhor caminho e movimento de tráfego. Depois, deve verificar perda, latência, congestionamento, churn e sucesso das aplicações. Sem medição, a frase "houve failover" descreve intenção, não desempenho.

Dois circuitos aparentemente diversos também podem compartilhar roteador, energia, fibra ou processo de controle. Planos de capacidade diferentes podem repetir a mesma hipótese otimista. O exercício precisa incluir dependências comuns e carga simultânea.

Fabric e route server exigem provas separadas

O route server da MIX simplifica o peering multilateral. Segundo a documentação, o serviço usa o ASN 61968, cria listas de prefixos a partir de bases IRR, exige que o primeiro ASN do caminho corresponda ao ASN de peering e rejeita várias classes de rotas inválidas. Rotas com validação RPKI INVALID também são rejeitadas [2].

As communities permitem ao participante escolher os destinos de uma divulgação. O tráfego passa diretamente entre vizinhos da LAN; o route server não é o next hop e seu ASN não aparece no AS_PATH [2]. O RFC 7947 descreve esse modelo multilateral [4].

O escopo desses controles não deve ser ampliado. IRR e RPKI restringem a distribuição de rotas, mas não mantêm o transporte da LAN, não compram trânsito de reserva e não governam todas as sessões bilaterais. A auditoria deve separar o fabric compartilhado, o plano de controle do route server e as rotas próprias dos participantes.

Evidência do operador do IX

A MIX deve conseguir reconstruir o estado de switches, links internos, portas de membros e processos do route server. Para o fabric, são relevantes erros de interface, mudanças de topologia, comportamento ARP ou Neighbor Discovery, volume de broadcast, proteção do plano de controle e escopo das portas afetadas.

Para o route server, o registro deve incluir estado das sessões, quantidade de rotas aceitas e rejeitadas, versão da política, atualidade de IRR/RPKI, processamento de communities e taxa de updates. Observações externas precisam ser alinhadas no tempo, pois a gerência interna pode parecer normal enquanto um participante vê perda parcial.

Um relatório público pode preservar configurações sensíveis e ainda informar a superfície afetada, os limites de tempo, a classe de controle, o alcance, a correção duradoura e o teste negativo que demonstra contenção.

Evidência do participante

O membro deve mostrar se uma mudança no IX virou indisponibilidade para clientes. Uma tela com outra sessão BGP em Established não basta. O histórico deve indicar quais caminhos do IX desapareceram, qual trânsito, PNI ou outro IX tornou-se preferido, quanto tempo a seleção levou e quais prefixos ficaram sem alternativa.

Adj-RIB-In, decisão local e rotas anunciadas permitem diferenciar uma alternativa ausente de uma alternativa presente mas rejeitada pela política. O registro de tráfego deve mostrar carga por interconexão, margem, perda e latência. O modelo deve considerar reconvergência simultânea de muitos membros, inclusive congestionamento mais profundo no upstream.

Sondas externas de DNS e aplicação fecham a prova. BGP pode convergir e ainda assim um firewall stateful, um caminho de retorno ou uma regra de engenharia de tráfego impedir a transação. A métrica final é o serviço.

Segurança de rota e disponibilidade

A rejeição de RPKI INVALID é um controle importante [2]. Filtros IRR e verificações de caminho adicionam limites. O RFC 7454 reúne práticas de segurança BGP, e o RFC 9234 introduz BGP Roles e Only-to-Customer [5][6].

Esses mecanismos não garantem disponibilidade. Uma rota com origem correta pode ter pouca capacidade ou relação imprópria. Uma rota autorizada pode desaparecer por falha de transporte. Dados de registro desatualizados podem bloquear a rota correta de emergência. A resposta não é abrir os filtros, mas manter o livro de autorizações e testar aceitação e rejeição antes da crise.

O registro é o livro, não o resultado

A PeeringDB atualmente associa o AS16004 à MIX S.r.L. - Milan Internet eXchange [3]. Essa identidade apoia contato e provisionamento, mas não mostra qual pacote foi encaminhado nem qual rota venceu.

Essa é a superfície Heng.lu: o registro é livro e guardião de continuidade, não uma autoridade soberana sobre a rede em execução. A legitimidade operacional surge quando identidade, política pretendida, configuração implantada e rota observada são reconciliadas.

Um pacote de reconvergência auditável

O pacote deve reunir estado pretendido, cronologia, rotas antes e depois, medições de tráfego e serviço, reparo e teste repetido. Se não for possível distinguir fabric, route server ou política do participante, a incerteza deve ser declarada e a telemetria precisa ser corrigida.

A nota da MIX estabelece uma expectativa razoável: um membro preparado possui alternativas [1]. A prova conjunta determina se elas funcionaram. Redundância não é a contagem de links; é uma transição verificada entre estados sem perda inaceitável.

Fontes

  1. https://www.mix-it.net/en/the-peering-lan-is-not-inherently-a-critical-point-of-failure/
  2. https://www.mix-it.net/en/route-server/
  3. https://www.peeringdb.com/api/net?asn=16004
  4. https://www.rfc-editor.org/rfc/rfc7947.html
  5. https://www.rfc-editor.org/rfc/rfc7454.html
  6. https://www.rfc-editor.org/rfc/rfc9234.html