Resumo

  • O MinRouteAdvertisementIntervalTimer limita a frequência com que um speaker anuncia mudanças do mesmo destino a um peer; ele não interrompe o processo de decisão local.
  • Se o melhor caminho mudar repetidamente durante a espera, o RFC 4271 determina que o último caminho selecionado seja anunciado no fim do intervalo. O vizinho recebe o estado atual, não toda a cronologia.
  • Um intervalo menor compra frescor com mais UPDATEs e cálculo distribuído; um maior combina a oscilação, mas pode atrasar informações úteis de falha, substituição ou reparo.

Considere um prefixo. Às 10:00:00, o caminho A é escolhido e anunciado. Quatro segundos depois, A falha e B se torna o melhor. Mais cinco segundos e uma política local passa a preferir C. O RIB local viveu três escolhas, e o FIB talvez tenha usado mais de uma. O peer pode ouvir apenas A e depois C. B existiu para a operação local, mas não se tornou uma declaração externa.

Essa compressão temporal é o Minimum Route Advertisement Interval, MRAI. O RFC 4271 o define como o tempo mínimo entre UPDATEs consecutivos enviados a um peer sobre um conjunto comum de destinos. O valor pertence à relação com o peer; a limitação tem sentido por destino. Isso não obriga todos os prefixos não relacionados a esperar em uma única fila.

A norma não exige um objeto de temporizador literal para cada destino, pois esse estado também poderia se tornar excessivo. Outro mecanismo de agendamento é aceitável se garantir a separação mínima e um limite superior constante para o atraso. O contrato compartilhado é o comportamento temporal observável, não a estrutura de dados interna.

Durante a espera, o Decision Process continua. Políticas avaliam cada UPDATE recebido, o best path pode mudar e o encaminhamento local pode acompanhá-lo. O que espera é a próxima afirmação a um vizinho específico sobre aquele destino. Se várias rotas foram selecionadas, a última é anunciada quando o intervalo termina. O receptor obtém a conclusão atual, não necessariamente os passos que a produziram.

A economia é concreta. Um estado intermediário que desaparece rápido não provoca uma mensagem e uma nova decisão em cada roteador posterior. O RFC 4271 coloca o MRAI no controle da sobrecarga de tráfego de roteamento e cita tanto largura de banda quanto computação. A vontade local de divulgação imediata, sem limite, vira trabalho distribuído para outras redes.

O estudo de instabilidade apresentado na SIGCOMM de 1997 observou, nos dados de pontos de troca analisados, muito mais anúncios patológicos do que mudanças duradouras de topologia explicariam. Seus números não são uma fotografia de 2026. Eles mostram, porém, que BGP pode produzir muito processamento sem conhecimento estável proporcional.

O trabalho da SIGCOMM de 2000 sobre convergência revelou o custo oposto. Medições passivas e injeções controladas mostraram falha, failover e reparo interdomínio levando minutos. Seleção independente e path exploration criavam perda e atraso transitórios. MRAI não era a única causa, mas um mecanismo que remove mensagens também pode estender o tempo para o conhecimento distribuído se acertar.

Diminuir o intervalo, portanto, não é sempre melhor. Uma alternativa válida pode aparecer mais cedo, mas também cada etapa da exploração pode ser exportada a muitos processos de decisão. Peers sincronizados podem criar picos de UPDATE e CPU. Por isso o RFC 4271 recomenda jitter no MRAI e em outros temporizadores: a simultaneidade pode ser mais perigosa que a média.

Aumentá-lo também não é automaticamente seguro. O valor pode combinar escolhas efêmeras e, ao mesmo tempo, esconder um reparo enquanto clientes do vizinho continuam sem alcance. O emissor talvez já use C enquanto o receptor atua sobre A, uma retirada antiga ou nenhuma rota. Proteger o controle sem um orçamento de frescor transfere o custo local para fora.

A primeira mensagem e as retiradas exigem precisão. O RFC define separação entre UPDATEs relevantes, não uma espera universal antes de toda primeira publicidade. O efeito depende do anúncio anterior, do agendador ativo e da implementação. Não há base para afirmar que toda retirada é imediata ou toda retirada é atrasada sem evidência da plataforma e versão em produção.

Relações internas e externas também diferem. O RFC 4271 reconhece a necessidade de convergência rápida dentro de um AS e recomenda intervalo menor para iBGP, ou não aplicar o procedimento às rotas enviadas internamente. Isso não ordena zerar todos os valores. Um AS não consegue agir de forma coerente sobre escolhas novas se sua própria distribuição as oculta sem necessidade.

Os valores sugeridos — 30 segundos em eBGP e cinco em iBGP — frequentemente são repetidos como padrão universal. Não são. O RFC 4273 expõe um temporizador gerenciado por peer e repete as sugestões; produtos adotam contextos próprios. A documentação Cisco IOS citada descreve, nas famílias tratadas, 30 segundos para eBGP comum, zero para iBGP e zero para eBGP em VRF. Outra versão ou plataforma pode divergir.

A hierarquia de configuração cria outra ficção. O valor pode vir de address family, neighbor, peer group, neighbor group ou session group. A precedência pode fazer a linha inspecionada ser diferente da que está em vigor. Uma saída operacional, como o intervalo mínimo entre execuções de anúncio mostrado pelo IOS XR, é evidência mais forte que a intenção da configuração superior.

Mesmo o número efetivo não prova o resultado. Para o mesmo NLRI, é preciso correlacionar os horários do best path, do Adj-RIB-Out, da fila MRAI, do UPDATE enviado, da recepção pelo peer e do FIB ou alcance. Assim se contam as seleções comprimidas e se descobre se a informação retida teria evitado perda. Menos mensagens não significa por si só roteamento saudável.

MRAI não é Route Flap Damping. Damping guarda a instabilidade histórica como penalidade decrescente e pode suprimir uma rota. MRAI não julga a história da rota; ele espaça declarações para um peer. Uma rota pode continuar selecionada e usada localmente enquanto aguarda anúncio. Ela não foi damped.

Também não é temporizador de vida. HoldTimer e Keepalive determinam a continuidade da sessão. BFD pode detectar cedo uma falha de encaminhamento. A detecção rápida adianta a escolha local, mas não prova que o UPDATE resultante ignore a cadência de saída. O RFC 7938 orienta arquitetos de data center a considerar MRAI no tempo de propagação justamente por isso.

ADD-PATH altera o que pode ser dito, não quando toda afirmação pode sair. Vários caminhos para um NLRI podem coexistir com identificadores e mostrar alternativas escondidas pelo anúncio apenas do melhor. Isso não torna valiosa toda seleção intermediária nem elimina o agendamento de saída. Visibilidade e cadência continuam superfícies separadas.

A relação BGP contém, assim, uma delegação temporal assimétrica. O emissor decide com que frequência revela mudanças; o receptor suporta a idade do conhecimento. Ele não pode forçar um UPDATE durante o intervalo, mas pode medir a chegada, negociar expectativas, diversificar upstreams e decidir quanto estado obsoleto tolera.

O princípio de especificação inicial mínima de Heng Lu cabe nessa fronteira. O protocolo comum deve dizer o bastante para interoperabilidade e carga limitada, sem impor um único intervalo a processadores, topologias, papéis e consequências distintas. A escolha permanece local porque os custos são locais, desde que os efeitos sejam observáveis por quem arca com eles.

A primazia do código em execução fornece o teste de responsabilidade. A configuração é intenção. Herança efetiva, agendador, trace de UPDATE, observação remota e entrega de pacotes formam o sistema. Se a evidência mostra que um temporizador “protetor” prolonga a perda do cliente, o commit bem-sucedido não justifica a decisão.

Três escolhas transformadas em uma mensagem não são engano nem purificação da verdade. São uma decisão de agenda. A rota final é a resposta local mais recente no momento permitido, não uma garantia de estabilidade futura. Liderar começa por nomear a troca: menos trabalho de controle em troca de conhecimento distribuído mais antigo.

Fontes