Resumo

  • A AMS-IX opera dois servidores de rotas em Amsterdã sob o AS6777, rs1.ams-ix.net e rs2.ams-ix.net; participar significa abrir sessão com os dois.
  • A norma impõe um único comportamento, entregar o NEXT_HOP sem modificação, e trata a preservação de AS_PATH e MED como recomendações com motivo declarado.
  • A única alocação explícita de responsabilidade no material publicado coloca a coerência da lista de prefixos e a conformidade da configuração no participante.

Uma rede que adere ao servidor de rotas da praça de Amsterdã deixa de montar uma sessão BGP por par e passa a montar uma só, voltada a uma máquina que reanuncia o que os demais anunciam. A AMS-IX publica duas: rs1.ams-ix.net em 80.249.208.255 e 2001:7f8:1::a500:6777:1, e rs2.ams-ix.net em 80.249.209.0 e 2001:7f8:1::a500:6777:2, ambas falando como AS6777. As condições são concretas — conectar-se aos dois, anunciar a mesma quantidade e o mesmo comprimento de prefixos em cada sessão, abrir a porta TCP 179 — e a documentação da AMS-IX sobre o servidor de rotas as enuncia sem rodeios.

O que essa documentação não faz é comprometer o operador com um conjunto simétrico de garantias. Ela descreve comportamento. As obrigações que detalha são do participante.

A única coisa que a norma não negocia

O RFC 7947 define o servidor de rotas de um ponto de troca, e sua exigência mais firme recai sobre um endereço: “the NEXT_HOP attribute MUST be passed unmodified” (seção 2.2.1, setembro de 2016). Essa frase explica por que um servidor de rotas não é um roteador em nenhum sentido que importe a um pacote. O próximo salto que o cliente vê é o endereço do par anunciante na matriz de comutação; o tráfego cruza a matriz de par a par e nunca passa pela máquina que falou BGP em seu nome. O RFC 7948, documento de operação do mesmo mês, traça a mesma fronteira: distribuir informação de alcance não é encaminhar tráfego.

Todo o resto na seção de atributos é mais brando, e de propósito. O servidor de rotas “SHOULD NOT prepend its own AS number” ao que retransmite (seção 2.2.2.1). Ele propaga o MULTI_EXIT_DISC e “SHOULD NOT modify its value” (seção 2.2.3). A seção 2.2 fixa a transparência de atributos como padrão e ao mesmo tempo admite exceções explícitas quando a configuração local as exige; a seção 2.1 permite filtragem por política sem mais.

O próprio RFC declara por que parou no SHOULD e não no MUST no AS_PATH: existe uma base instalada de clientes antigos que rejeita uma sessão cujo primeiro AS é inesperado, e uma regra imperativa os teria deixado de fora. Por isso a norma exige das implementações permitir desativar a checagem do primeiro AS, de preferência por par, em vez de assumir a garantia mais pesada. É um compromisso de engenharia vestido de nível de exigência, e importa a quem acreditava que a praça havia aceitado o dever absoluto de não mexer nos atributos de caminho.

O que o operador põe no registro

A AMS-IX publica a sua metade do arranjo. Não insere o AS6777 nos AS_PATH das rotas que retransmite, e as checagens do primeiro AS devem ser desativadas onde couberem. Os pares de exportação são escolhidos por entradas RPSL e comunidades: a comunidade 0:6777 bloqueia todas as exportações, 6777: habilita um par escolhido, e sessões novas passam por padrão por filtragem combinada de IRRDB e RPKI. As rotas aprendidas podem servir ao participante e a seus clientes a jusante, mas a redistribuição para trânsitos, pares externos ou o servidor de rotas de outro ponto de troca é proibida.

Duas frases desse material merecem segunda leitura. A primeira avisa que os dados de IRRDB e RPKI não trazem garantia de validade e não devem ser usados sozinhos — a descrição, feita pelo próprio operador, da filtragem que aplica por padrão. A segunda é a cláusula de responsabilidade: “Participants are responsible for ensuring that their routing configuration complies with this policy.”

O RFC 7948 já havia chegado à mesma alocação. Ele descreve a responsabilidade do cliente de garantir que sua lista declarada de prefixos seja compatível com o que anuncia (seção 4.3), recomenda mitigação de vazamentos do lado do operador e pede comparação automatizada entre rotas recebidas e listas configuradas onde houver filtragem de entrada por cliente. O papel que os documentos desenham é administrativo, não tutelar: o servidor de rotas filtra, seleciona e reanuncia, o operador publica o que faz, e ninguém assume um dever de verificação enumerado diante de cada participante individual.

O que eu procurava e o que o texto diz

Eu procurava um negócio documentado: uma sessão para cada membro em troca de uma lista publicada do que a praça deve a você. Os documentos sustentam apenas a primeira metade. O negócio é real — a contagem de sessões desaba de verdade — mas é cobrado em exposição, não em nível de serviço. Um MUST categórico mantém os pacotes fora do falante compartilhado. Dois SHOULD, um argumento de compatibilidade e uma porta aberta para a configuração local deixam as mãos do operador livres no caminho e no MED.

A leitura útil, portanto, não é que o servidor de rotas da AMS-IX seja descuidado. É que a peça foi desenhada como um administrador com mandato delimitado: autorizado a tomar decisões de plano de controle, proibido de encaminhar um único pacote e responsável sobretudo por texto publicado. Esse enquadramento é meu, não do IETF nem da praça, e nenhuma posição formal o enuncia.

O que um participante consegue conferir de fato

O registro de diretório deste servidor de rotas reúne os mesmos fatos publicados num só lugar, e o problema de verificação está justamente no que eles deixam aberto. Um participante não audita a conformidade interna do falante compartilhado lendo uma página de política. O que ele pode é ler as rotas que recebe e confirmar que o próximo salto visto é o par, não o servidor de rotas. Pode observar se 0:6777 e 6777: produzem a exportação descrita. Pode manter as duas sessões e comparar o que cada servidor envia, para que uma divergência apareça como divergência e não como mistério.

A documentação não tem data na versão publicada, foi consultada em 12 de novembro de 2026 e sua vigência na data de publicação não está confirmada. O comportamento em produção não foi testado aqui, e a página examinada não estabelece que os padrões de filtragem e as comunidades de exportação se comportem de forma idêntica em rs1 e rs2. Foi localizada uma única cláusula explícita de responsabilidade, sobre coerência da lista de prefixos; a ausência de garantia mais ampla do operador naquela página é uma observação sobre aquela página, não prova de que tal texto não exista em outro lugar.

O resumo honesto da troca

Um servidor de rotas fala, não carrega, e o papelório tem esse formato: uma promessa incondicional que mantém o tráfego fora da caixa e duas promessas condicionais que deixam à praça as mãos livres nos atributos que o orientam. Uma rede que precise de mais garantia não vai encontrá-la no texto de política. Vai encontrá-la, ou não, nas próprias rotas recebidas — exatamente onde os documentos já situam a responsabilidade.