Resumo

  • A Breizh-IX informa que refaz listas restritivas de prefixos todas as noites, consulta ROAs dos RIRs e respeita o campo “Never via route servers” do PeeringDB. A apresentação RS-API na RIPE 93 acrescenta a verificação da quantidade de rotas e da vontade do cliente de ter suas rotas redistribuídas.
  • O próprio PeeringDB chama o campo de indicação para o ponto de troca. A decisão só ganha efeito quando o operador a busca, converte em política e confere o comportamento do servidor.

A lista responde a duas perguntas. O cliente responde à terceira

Um técnico olha a tela e vê três coisas. O endereço anunciado aparece no cadastro. A rede que o anuncia está na lista esperada. O número de rotas parece normal. É fácil apertar «aceitar».

Mas aceitar uma rota e distribuí-la são atos diferentes. O AS-SET é uma lista de redes. O objeto route liga um bloco de endereços à rede que pode anunciá-lo. Nenhum dos dois documentos diz se o membro quer que o servidor de rotas entregue seu anúncio aos demais participantes do ponto de troca. Essa escolha pertence ao membro.

Evann Dreumont e Alarig Le Lay, da Breizh-IX, puseram as três verificações no resumo da apresentação na RIPE 93, marcada para 28 de outubro. Primeiro, conferir no registro IRR se a rota pertence à lista do cliente. Depois, olhar o tamanho do anúncio. Uma lista dentro de outra pode trazer uma fatia enorme da tabela mundial. Por fim, perguntar se o cliente deseja o reanúncio pelo servidor. Um computador expande listas; não manifesta a vontade do participante.

O RFC 7947 mostra por que isso importa. O servidor funciona como um intermediário entre redes. Cada participante economiza conexões diretas com todos os demais. Em troca, uma decisão sobre quem receberá a rota passa pelo mesmo servidor. Se a regra estiver errada, o erro pode alcançar vários pares. O cadastro prova uma coisa; a autorização para distribuir prova outra.

Do cadastro ao servidor, há trabalho humano

No site da própria Breizh-IX, a associação sem fins lucrativos de Rennes descreve o que já faz. Refaz listas de prefixos todas as noites com bgpq4 em modo estrito. Sem um objeto route, o prefixo é recusado. Seus servidores também verificam ROAs, que autorizam a origem de uma rota no sistema RPKI dos registros regionais, e examinam o atributo OTC. O segundo servidor consulta ainda ASPA. A associação afirma respeitar o campo “Never via route servers” do PeeringDB.

São práticas declaradas pelo operador. A apresentação de RS-API trata de juntar verificações que hoje exigem manutenção repetida. O resumo não traz código publicado nem medições de uso da nova ferramenta.

A FAQ oficial do PeeringDB chama esse campo de info_never_via_route_servers e o classifica como uma dica. A base guarda a opção marcada pela rede. O ponto de troca precisa consultá-la regularmente e cumpri-la.

O caminho entre as duas telas é o trabalho importante: buscar o valor novo, criar a regra, carregá-la nos servidores e conferir os anúncios que saem. Uma marca no perfil não reconfigura o BGP por telepatia.

O relógio pode desmentir o formulário. Um participante muda a preferência pela manhã. O servidor ainda usa o valor anterior até a próxima atualização. Nesse intervalo, perfil e operação contam histórias diferentes. O material público consultado não mostra os horários de cada mudança da Breizh-IX nem relata um caso de falha. A verificação necessária é direta: ligar a hora da escolha à hora em que ela passou a valer no servidor. Refazer o filtro IRR à noite não basta para responder.

O limite de prefixos também precisa de explicação. Uma lista pode conter outra. O programa abre as duas corretamente e acaba com muito mais rotas do que o cliente esperava. Se o teto escolhido for alto demais, o alerta nunca toca. RS-API pretende comparar o cadastro com a situação operacional sem exigir revisão manual a cada mudança. A futura prova será mostrar qual lista fez o número crescer, quem escolheu o teto e como desfazer uma exceção equivocada.

O recibo deve mostrar quem falou por quem

O membro deveria receber um histórico por versão da política. Nele estariam a lista AS-SET usada, os objetos route, a contagem final, o teto, a hora de leitura no PeeringDB e a versão carregada em cada servidor. Também apareceria quem recebeu a rota. Se o anúncio foi barrado, o histórico diria por quê. Se passou, mostraria quem autorizou o envio. Assim a pergunta sobre consentimento não se perde num ticket sobre a contagem.

Falta uma regra pública para os intervalos cinzentos. O que RS-API fará se o PeeringDB estiver indisponível, se o campo estiver antigo ou se as fontes se contradisserem? As fontes examinadas não respondem. Um padrão explícito e um log datado de aplicação mudariam o julgamento. O servidor conta prefixos; a associação decide como opera no silêncio dos dados; o participante precisa enxergar ambas as decisões.

Fontes