Resumo

  • O route server de um ponto de troca é um intermediário do plano de controle, não um roteador de trânsito. Por isso, a RFC 7947 recomenda que seu ASN não seja acrescentado ao AS_PATH e exige que o NEXT_HOP do anunciante seja preservado.
  • O cliente recebe uma rota em que o vizinho da sessão, o primeiro AS do caminho e o roteador de encaminhamento são entidades diferentes. A exceção à verificação do primeiro AS deve ficar restrita aos servidores oficiais e não elimina os filtros locais.
  • A prova passa pelo anúncio original, validação de entrada, seleção específica do destinatário, Adj-RIB-Out, Adj-RIB-In, FIB, resolução de vizinhança e pacotes. Sessão estabelecida, contagem de prefixos e disponibilidade do host não demonstram o mesmo resultado.

O canário que tentou nomear o roteador errado

Em um ambiente sintético, com endereços e ASNs reservados para documentação, o participante A anuncia um prefixo canário a dois route servers. O NEXT_HOP correto seria a interface de A na LAN do IXP. Um segundo anúncio usa a interface do participante C.

O primeiro servidor rejeita a discrepância entre o cliente que enviou a rota e o AS dono do próximo salto. O segundo a aceita e a oferece a B. As sessões estão estabelecidas nos dois casos. O AS_PATH começa com A, não com o ASN do servidor, e B não dispõe de informação suficiente na sessão agregada para saber se A tinha autorização para nomear C.

Quando recebe a versão legítima, B desativa a checagem de primeiro AS apenas para o vizinho oficial do route server. A rota entra na tabela e a FIB aponta diretamente para A. O tráfego atravessa a LAN compartilhada entre os dois participantes, sem passar pela máquina que transmitiu o UPDATE.

O cenário não descreve um incidente real. Ele expõe o contrato incomum do serviço: o intermediário deve validar uma afirmação que não pode substituir por sua própria identidade e deve distribuí-la sem se apresentar como parte do caminho de dados.

Um broker operacional, não um observador passivo

Em um IXP, vários sistemas autônomos compartilham uma infraestrutura de camada 2. O peering bilateral entre todos os membros exige uma malha crescente de sessões e acordos operacionais. O route server reduz esse custo: cada cliente troca alcance com muitos participantes por meio de poucas sessões.

Esse sistema não é um route collector. Um coletor recebe feeds para análise; o route server participa da distribuição de rotas usadas em produção. Ele pode rejeitar um prefixo, escolher entre candidatos, interpretar instruções de distribuição e construir uma saída diferente para cada cliente.

Também não é um roteador de trânsito. Embora execute BGP e mantenha RIBs, não deve encaminhar os pacotes relativos às rotas que intermedeia. A entrega ocorre diretamente entre os membros sobre o tecido do IXP.

Essa fronteira explica por que AS_PATH não deve funcionar como lista de presença de todo software que processou o anúncio. O atributo representa o caminho de sistemas autônomos usado por políticas e detecção de loops. Inserir o ASN do broker por causa da sessão inventaria um salto e poderia mudar a decisão do receptor.

O servidor tem poder, mas um poder delimitado: controlar a corretagem de alcance sem reivindicar uma posição no percurso de encaminhamento.

Transparência não significa ausência de decisão

Na operação eBGP comum da RFC 4271, um locutor externo acrescenta seu próprio AS ao anunciar uma rota. A RFC 7947 recomenda que o route server não faça isso por padrão e não altere o AS_PATH sem configuração explícita. Um AS adicional pode aumentar o caminho, acionar filtros ou mudar preferências.

Para NEXT_HOP, o texto exige preservação. Se A originou o anúncio no IXP, B deve enviar pacotes diretamente à interface de A. Reescrever o atributo para o servidor atrairia tráfego para um componente que não participa do encaminhamento.

Outros atributos também devem, em geral, atravessar o broker sem alteração, salvo política local publicada. A transparência impede que o intermediário modifique silenciosamente os insumos de decisão dos clientes.

Mesmo assim, ele continua ativo. Pode validar origem e prefixo, aplicar política individual, interpretar Communities e escolher uma rota. A ausência do ASN no caminho não apaga essa influência. Ela transfere a prova para registros operacionais: Adj-RIBs, resultado de validação, versão de política e saída por cliente.

Há, portanto, dois registros complementares. Os atributos documentam a informação de encaminhamento. O estado do route server documenta a mediação. Nenhum dos dois, isolado, conta a história inteira.

A exceção de primeiro AS precisa caber em um único vizinho

Muitos equipamentos verificam se o AS mais à esquerda no caminho corresponde ao ASN do vizinho eBGP. Em trânsito ou peering bilateral, essa coerência detecta erros úteis. No route server transparente, o primeiro AS é o anunciante original.

A RFC 7947 determina que clientes possam desligar a verificação e recomenda granularidade por peer. A segurança está no escopo. ASN, endereços, famílias e identidade do route server devem vir da fonte oficial do IXP, e a exceção deve existir somente nesses objetos de vizinhança.

Manter a checagem faz a sessão parecer saudável enquanto descarta as rotas. Desligá-la em um perfil global de configuração enfraquece todos os futuros vizinhos externos. Uma correção local não pode virar uma renúncia geral à validação.

A exceção também não terceiriza a política de B. O cliente ainda procura seu próprio ASN no caminho, limita prefixos, valida origem conforme sua regra e decide o que entra na Loc-RIB e na FIB. O broker entrega candidatos; o participante continua sendo o decisor final.

Quando a melhor rota comum não é a melhor rota de B

O anunciante pode pedir que um prefixo seja distribuído a todos, apenas a alguns clientes ou a ninguém. A RFC 7948 cita Communities, registros de roteamento e bases acessíveis pelos membros como meios de expressão. IXP Manager, AMS-IX e LINX publicam exemplos atuais usando Communities tradicionais e Large Communities.

O rótulo não tem semântica universal sozinho. Seu significado depende do contrato do IXP, e a comprovação de execução está no Adj-RIB-Out destinado ao cliente.

O path hiding aparece quando a ordem está errada. O servidor recebe dois caminhos e escolhe A em uma RIB comum. A política de B proíbe A. Se o filtro remove apenas o caminho já escolhido, B não recebe nada, ainda que o segundo candidato fosse permitido.

A seleção global foi válida e o filtro de B também. A falha está em usar uma perspectiva única antes de responder à preferência particular de B.

A RFC 7947 descreve uma Loc-RIB por cliente como mitigação portável: filtrar primeiro e selecionar depois para cada destinatário. Implementações podem compartilhar o estado comum e guardar diferenças. Também podem anunciar múltiplos caminhos com Diverse Paths ou ADD-PATH; nesse caso, a recomendação é o route server operar em modo somente de envio para que rotas inativas dos clientes não se tornem novas entradas impróprias.

O FRRouting documenta hoje RIB dedicada por RS-client, e a AMS-IX informa o uso de secondary no BIRD. Essas afirmações precisam de teste em execução. O canário correto cria dois caminhos, proíbe o preferido para B e confirma a chegada do alternativo.

Preservar NEXT_HOP aumenta a obrigação de validar a entrada

O próximo salto de terceiros mantém o tráfego fora do servidor, mas permite que um participante tente indicar a interface de outro. Depois que centenas de anúncios chegam a B pela mesma sessão, B dificilmente consegue reconstruir a autorização de cada endereço.

A RFC 7948 recomenda que o route server compare o NEXT_HOP com a interface do cliente anunciante e descarte divergências entre ASes. Uma exceção dentro do mesmo AS pode atender organizações com vários roteadores. O IXP Manager descreve controle equivalente ao lado de verificações de caminho, prefixo, IRR e RPKI.

O broker é o lugar adequado porque ainda conhece a identidade da sessão de entrada. Preservar o atributo só é seguro depois dessa atribuição.

Ainda assim, um próximo salto autorizado pode estar indisponível. Uma falha não transitiva da LAN pode deixar B conectado aos servidores e incapaz de alcançar A. BGP permanece estabelecido, mas ARP ou NDP não resolve. Sondar somente os endereços do route server testa o plano errado.

Redundância exige igualdade de serviço observável

A RFC 7948 recomenda múltiplos servidores no domínio compartilhado e admite diversidade de software e sistema operacional. Isso pode evitar que um único defeito derrube ambos.

Entretanto, duas sessões não provam duas saídas equivalentes. Instâncias podem usar gerações distintas de política, snapshots IRR, estados RPKI, momentos de convergência ou algoritmos de visão por cliente. Contagens idênticas escondem diferenças de AS_PATH, NEXT_HOP, MED e Communities.

A comparação correta opera por cliente, família e prefixo. Normaliza os atributos relevantes, calcula uma impressão digital e exige justificativa para cada diferença esperada. A instância em execução deve revelar qual geração de configuração e de dados produziu a visão.

Diversidade sem equivalência observável gera resultados imprevisíveis. Igualdade sem independência pode duplicar o mesmo erro. Redundância real combina domínios de falha distintos com um contrato de saída comparável.

A cadeia de evidências atravessa quatro responsabilidades

Uma rota precisa de registros encadeados:

  1. Adj-RIB-Out de A ou captura do enlace mostra o anúncio original;
  2. Adj-RIB-In do servidor mostra a entrada recebida;
  3. log de validação registra prefixo, origem, primeiro AS e NEXT_HOP;
  4. visão de B e geração de política explicam a seleção;
  5. Adj-RIB-Out para B mostra os atributos enviados;
  6. Adj-RIB-In de B demonstra a travessia da sessão;
  7. RIB selecionada, FIB e ARP/NDP mostram o próximo salto instalado;
  8. contadores, probes ou capturas demonstram os pacotes indo diretamente a A.

A tabela mestre do servidor não é a visão de B. Um looking glass pode esconder candidatos rejeitados. Um arquivo de configuração desejado não comprova a versão em execução. Identidades e horários ligam os registros numa sequência causal.

As responsabilidades seguem a mesma divisão. A responde pelo anúncio; o operador do servidor, pela validação e política de distribuição; B, pela importação e seleção local; o IXP, pela entrega direta de camada 2. Nenhum pode usar o painel do outro para declarar sua etapa concluída.

Uma migração feita para testar os limites

O primeiro passo é fixar, a partir do material oficial do IXP, ASN, endereços, AFI/SAFI, capacidades e contrato de Communities dos dois servidores. A exceção de primeiro AS fica presa a esses vizinhos.

Um prefixo canário registra AS_PATH e NEXT_HOP originais. Em cada servidor, verifica-se entrada, validação, visão de B e saída. Em B, verifica-se que o primeiro AS continua sendo A, o próximo salto continua sendo A e o ASN do servidor não foi inserido para produzir aparência comum. FIB, MAC e captura comprovam o caminho direto.

Depois vêm testes negativos: permitir B e negar C; inverter; oferecer dois caminhos e negar o preferido; apresentar NEXT_HOP de outro AS e exigir rejeição; repetir em IPv4 e IPv6. As saídas dos dois servidores são comparadas atributo por atributo.

O rollback guarda as versões anteriores nos dois lados. Restaurar configuração não garante a retirada de rotas já aprendidas; route refresh, reavaliação ou ação controlada de sessão podem ser necessários. O escopo deve ser mínimo, sem reiniciar serviços que não participaram da mudança.

Fontes e limites

A base é a RFC 7947, lida com o comportamento BGP da RFC 4271. A RFC 7948 trata de redundância, vazamento, camada 2 e sequestro de NEXT_HOP. RFC 7911 e RFC 6774 sustentam os mecanismos de múltiplos caminhos.

As documentações de FRRouting, BIRD e IXP Manager fornecem exemplos atuais de implementação. As páginas oficiais da AMS-IX e da LINX mostram práticas de operação, não o estado de um IXP não identificado. O caso inicial é sintético.