Resumo

  • O RFD nasceu diante de um problema mensurável: atualizações BGP em excesso podiam consumir a pouca capacidade de processamento de roteadores antigos e desencadear novas quedas.
  • A penalidade acumulava mudanças, não causas. A busca do BGP por rotas alternativas depois de uma única retirada podia parecer instabilidade repetida e manter uma rota recuperada suprimida por até uma hora nos cenários estudados.
  • O poder prático estava distribuído entre especificação, software e operação. O detentor do prefixo não controlava o contador mantido por um AS remoto.
  • Depois de 2002, a resposta documentada foi desligar as implementações existentes e, mais tarde, recuperar apenas uma versão com limiares conservadores. Alterar parâmetros já disponíveis exigiu menos coordenação do que substituir o algoritmo.

Uma manutenção vista como reincidência

O ponto de partida mais revelador está em RIPE-229. Uma atualização programada de software em um roteador de backbone exigiu recarga: um flap. O software novo caiu: outro. A volta à versão antiga exigiu nova recarga: o terceiro. As três mudanças ocorreram em dez minutos.

Não há necessidade de imaginar conflito ou imprudência. O registro mostra uma atualização que falhou e foi revertida. Mesmo assim, alguns roteadores de trânsito e peering usavam parâmetros progressivos agressivos. Os /24 do operador e de seus clientes ficaram suprimidos por mais de três horas em certas fronteiras, segundo o documento. O equipamento de origem já operava; a memória remota ainda o tratava como provável fonte de instabilidade.

RIPE 27 decidiu não iniciar a supressão antes do quarto flap consecutivo e limitar a espera a uma hora após o último. A escolha foi uma correção observável do excesso anterior. Também manteve uma hora de indisponibilidade possível para um /24 que já tivesse se estabilizado.

O gargalo que tornou o RFD atraente

No começo dos anos 1990, mais prefixos eram anunciados, as redes de provedores ganhavam mais interconexões e cada retirada precisava atravessar roteadores com a tabela completa. A seleção de melhor caminho e a atualização do encaminhamento exigiam CPU. Sob carga suficiente, um roteador podia perder sessões BGP ou IGP; a própria queda produzia mais mensagens e empurrava trabalho aos vizinhos.

Documentos da RIPE situam o desenvolvimento do RFD em 1993 e sua integração em software da Cisco, ISI/RSd e GateD a partir de 1995. Quando RFC 2439 saiu, em novembro de 1998, os autores afirmavam que a técnica já existia em produtos comerciais e tinha ampla implantação. A prática antecedeu a formalização.

O mecanismo guardava uma pontuação por rota recebida de um vizinho eBGP. A retirada elevava a penalidade; reanúncios e mudanças de atributo podiam elevar também, conforme a implementação. O valor caía exponencialmente. Acima do limiar de supressão, a rota deixava de ser usada. Abaixo do limiar de reutilização, voltava. Um tempo máximo limitava a espera.

RFC 2439 queria reduzir carga e oscilações sem atrasar rotas normalmente bem comportadas. O próprio texto reconhecia que não era possível prever a estabilidade futura com precisão. A história recente tornou-se uma aproximação. Era uma escolha computacionalmente eficiente, mas incapaz de distinguir sozinha um reparo de uma falha crônica.

Padronizar o comportamento sem controlar a rede

Fabricantes entregavam valores diferentes e operadores podiam escolher meia-vida, supressão, reutilização e tempo máximo. Um prefixo podia estar acessível por uma parte da Internet e continuar retido em outra. O provedor de acesso conseguia limpar seu roteador depois do conserto, mas não o estado em redes upstream que sequer identificava.

Uma discussão em RIPE 26 levou a uma sessão BOF; RIPE 27 criou uma força-tarefa; RIPE-178 apareceu em 1998. Tony Barber, da UUNET, desenhou parâmetros que haviam funcionado por alguns meses em seu ambiente. RIPE-229 atualizou o conjunto em 2001 e recomendou sua adoção por ISPs e como padrão de fabricantes.

Essa sequência criou influência, não autoridade central. A RIPE não podia configurar roteadores alheios. Um RFC não ativava uma opção. Os fabricantes controlavam o comportamento executável e os valores iniciais. Cada operador controlava os equipamentos que possuía. A política global era o resultado composto dessas escolhas locais.

O conjunto coordenado ainda fazia uma escolha distributiva. RIPE-229 aplicava tratamento mais duro a /24 e prefixos mais longos: depois do limiar, uma hora de supressão. Prefixos mais curtos tinham intervalos menores. O argumento combinava agregação e impacto potencial sobre mais usuários. Para redes pequenas multihomed, porém, uma rota específica podia ser justamente o instrumento de redundância.

O documento criou as “Golden Networks” para isentar infraestrutura crítica em prefixos longos, como servidores raiz e de TLD. A exceção não tornou o comprimento um indicador melhor de falha. Apenas reconheceu que o erro era caro demais para determinados serviços já identificados como importantes.

A falha ocorreu uma vez; o caminho mudou muitas

Depois de uma retirada, o BGP pode explorar sucessivos caminhos AS antes de concluir que não há rota ou escolher a alternativa final. Cada melhor caminho carrega atributos diferentes. Um contador de damping pode somar essas trocas como novos sinais de instabilidade, mesmo quando o enlace de origem falhou uma única vez.

Zhuoqing Morley Mao, Ramesh Govindan, George Varghese e Randy Katz estudaram essa interação em 2002 com modelo analítico, simulações, traços e uma bancada de roteadores comerciais. Nas topologias analisadas, uma retirada seguida de reanúncio podia gerar flaps secundários suficientes para suprimir a volta da rota por até uma hora. RIPE-378 citou posteriormente uma medição em que uma retirada produziu 41 eventos BGP alguns AS adiante.

O limite da prova é importante. O artigo não mediu a implantação mundial nem garantiu o mesmo resultado em qualquer topologia. Ele demonstrou algo mais específico: penalidade alta não provava repetição de falha física. O protocolo podia estar contando sua própria convergência.

A alternativa proposta foi o damping seletivo, que deixava de penalizar mudanças monotônicas típicas da exploração após retirada. Nos cenários testados, eliminou a supressão indevida e ainda conteve uma rota que realmente alternava a cada quarenta segundos. Era um redesenho plausível, não uma implantação global verificada.

Primeiro desligar, depois estreitar o alvo

RIPE-378 registrou em 2006 que não surgira demanda da indústria de ISPs nem atividade de implementadores para incorporar a mudança de 2002. Roteadores mais fortes também haviam reduzido a pressão de CPU que justificara o mecanismo. O texto tornou obsoletas as recomendações anteriores e aconselhou não aplicar as implementações então existentes em redes de provedores.

Um Internet-Draft de 2012 reuniu 63 respostas voluntárias por listas de operadores. Treze disseram usar RFD, 49 não; quinze respostas escolheram RIPE-378 como motivo para não usar. A amostra não é representativa e não fornece taxa global. Ela mostra apenas que a desativação e o impacto sobre clientes eram decisões reconhecíveis para parte dos respondentes.

RIPE-580 e RFC 7196 retomaram o mecanismo com base em medições de concentração do ruído. Na semana analisada por RFC 7196, um limiar de 6.000 reduziu a taxa de updates em 19% diante de nenhum RFD e suprimiu 90% menos prefixos que o valor 2.000. Com 12.000, 0,22% dos prefixos foram suprimidos, enquanto a queda média de updates por hora ficou perto de 11%.

RFC 7196 recomendou pelo menos 6.000 para uso ainda agressivo, porém menos destrutivo, e pelo menos 12.000 para operação conservadora. Sugeriu também um modo que calcula sem suprimir. Ao mesmo tempo, disse que implementações não deveriam mudar silenciosamente os padrões existentes, pois poderiam quebrar configurações. O erratum 4011 esclarece que a tabela de valores Cisco e Juniper era apenas informativa.

Esse cuidado mostra o mecanismo de lock-in. O algoritmo seletivo exigia software novo, validação e adoção. Um limiar maior cabia na interface já instalada. Até um valor considerado agressivo podia sobreviver porque alterar o padrão automaticamente criava risco de compatibilidade.

Poder local, custo remoto

O detentor do prefixo controlava anúncio e reparo. O registro podia provar a titularidade do recurso. Nenhum dos dois obrigava um roteador remoto a reutilizar a rota. Operadores de trânsito e peering controlavam RFD nos equipamentos próprios. Fabricantes controlavam opções e padrões. Autores de RFC e documentos RIPE controlavam a formulação, não a execução.

O benefício direto era do AS que reduzia updates e trabalho de CPU. Nos anos iniciais, evitar uma queda em cascata podia beneficiar muitos usuários. Quando havia falso positivo, o custo mudava de organização: detentor do prefixo recuperado, clientes e pessoas tentando usar seus serviços. A investigação atravessava ASes, muitas vezes sem revelar onde a penalidade permanecia.

O operador tinha autorização local para configurar seu roteador. Isso não equivalia a mandato global de todos os afetados. As fontes tampouco provam ilegalidade ou quebra contratual. A questão de legitimidade é se uma decisão com efeitos externos pode ser observada, atribuída e contestada pelo prejudicado.

Um contrafactual honesto preserva a limitação dos anos 1990. Sem RFD, mais churn atingiria máquinas frágeis. Alternativas críveis incluem o algoritmo seletivo, limiares conservadores desde cedo, observação sem supressão e telemetria visível com um processo seguro de limpeza. Cada opção troca carga, custo de engenharia ou risco de abuso por menos penalizações falsas.

Para os titulares de recursos numéricos, a conclusão vai além do RFD. Um registro pode dizer de quem é o prefixo; o originador pode anunciá-lo corretamente; cada rede ainda decide quando confiar. Titularidade é evidência. Alcançabilidade é uma relação operacional contínua.

Fontes