Resumo

  • Quando um speaker muda o next hop, RFC 10005 permite remover, reapresentar sem alteração ou regenerar a comunidade Link Bandwidth; a implementação deve expor o default e permitir ajuste por sessão.
  • Manter o valor transfere uma declaração antiga para um caminho novo; regenerá-lo cria uma nova declaração. A prova deve registrar o next hop, a fonte do cálculo, as rotas constituintes, a política receptora e os pesos realmente instalados na FIB.

Antes da repropagação, o número descrevia uma capacidade atrás do vizinho original. Depois, o roteador fez next-hop-self. Para o downstream, o primeiro salto agora terminava em outro lugar, com outra interface local e possivelmente outro conjunto de caminhos internos. Ainda assim, o mesmo número continuou anexado à rota.

Isso pode ser uma decisão válida. O valor pode representar capacidade agregada que permanece disponível por meio do novo next hop. Também pode ser um erro silencioso: a declaração remota é preservada embora o caminho local tenha um gargalo menor. O protocolo não consegue distinguir os dois casos porque a diferença está no modelo operacional.

RFC 10005, publicado em junho de 2026 como Proposed Standard, trata essa fronteira diretamente. Quando há mudança de next hop, o speaker pode adotar como default remover, conservar ou regenerar Link Bandwidth. A implementação deve permitir alterar o comportamento por sessão e revelar qual default usa.

Três ações, três afirmações

Remover a comunidade significa: “não possuo evidência suficiente para transportar este número ao novo caminho”. É a opção mais conservadora semanticamente, mas pode levar o receptor ao balanceamento igual se uma rota do conjunto ficar sem valor.

Conservar significa: “a declaração anterior continua sendo uma descrição útil depois da mudança de next hop”. Isso pode fazer sentido quando o novo speaker apenas representa a mesma capacidade agregada. Também pode ocultar a interface local de 50 unidades diante de um remoto que dizia 70.

Regenerar significa: “eu, neste limite, produzo uma nova declaração”. O novo valor pode derivar de velocidade de interface, de rotas multipath, de capacidade de servidores ou de uma função local. A partir daí, a autoria operacional deixa de ser apenas do originador inicial.

Quando o next hop não muda, inclusive em route reflection, o RFC diz que a comunidade não deve ser alterada. Essa assimetria oferece um teste claro: qualquer modificação com next hop estável precisa de explicação; qualquer mudança de next hop precisa de uma escolha registrada.

O formato não transporta a fórmula

Link Bandwidth usa Type 0x00 na forma transitiva ou 0x40 na não transitiva, sempre com SubType 0x04. O Local Administrator é um float IEEE 754 de 32 bits em bytes por segundo. O Global Administrator tem dois octetos, deveria levar o ASN do roteador que anexa a comunidade e usa AS_TRANS quando o ASN não cabe. Esse identificador não altera a semântica e não autentica a origem.

O RFC deixa fora de escopo a determinação do valor. O draft atual de casos de uso chama de remote bandwidth o valor recebido e de local link bandwidth a velocidade descoberta na interface da sessão. A configuração pode escolher um deles ou uma função de ambos, como o mínimo. O resultado vira contributing bandwidth.

O mesmo draft descreve cumulação opcional quando o next hop muda. O speaker pode somar valores de caminhos que participam do multipath e pode basear a soma em remoto, local ou contributing bandwidth. Se uma fonte exigida estiver ausente, ela pode contribuir como zero. Logo, três configurações válidas geram três totais diferentes sobre as mesmas rotas.

No caso de serviço anycast, a unidade operacional pode ser número de servidores. Em outra topologia, os números podem ser apenas pesos proporcionais. O campo em BGP continua parecendo bytes por segundo, mas a política precisa preservar a convenção que lhe dá sentido.

O receptor ainda decide o efeito

Após a repropagação, o downstream precisa primeiro qualificar caminhos para multipath. Link Bandwidth não deve ser usado na seleção de best path. Quando todos os caminhos contribuintes têm valores não zero, seus números ou razões podem orientar weighted load balancing.

Se houver mistura de zero e não zero, ou todos forem zero, a política local decide. Se faltar comunidade válida em qualquer caminho, o default recomendado é balanceamento igual, salvo override. Múltiplas comunidades levam por padrão ao menor valor, inclusive zero e sem considerar transitividade. Valores negativos são ignorados; zero é válido.

Por isso, remover uma comunidade pode ter efeito maior que simplesmente “não informar capacidade”. Pode alterar o conjunto de regras que o receptor aplica a todas as rotas. Conservar ou regenerar pode manter weighted forwarding, mas com um significado diferente. A política de reanúncio e a política receptora devem ser avaliadas em conjunto.

As implementações tornam o limite concreto

O manual Arista EOS documenta regeneração local de Link Bandwidth para vizinho ou peer-group, com divisão e agregação. A documentação Cisco ASR 9000 mostra valores definidos por política e comportamento associado à interface. Juniper documenta valor configurado, detecção e agregação.

Essas fontes demonstram que o operador dispõe de controles diferentes. Não demonstram equivalência de defaults nem o estado de uma versão específica. Para cada upgrade, a organização precisa testar a combinação efetiva de release, address family, tipo de comunidade e direção da sessão.

A transição entre formas adiciona outra armadilha. Uma rota pode carregar simultaneamente comunidades transitive e non-transitive com valores que deveriam coincidir. Um equipamento antigo pode entender só uma. Se a regeneração atualizar apenas a outra, downstreams diferentes usarão pesos diferentes. Atualizar somente o route reflector não é objetivo de interoperabilidade do RFC.

Registrar o momento em que a autoria muda

Para cada reanúncio, guardar next hop recebido e anunciado; comunidade antes e depois de import policy; Local-RIB e caminhos constituintes; ação remove/retain/regenerate; fonte e função do novo valor; transitivity; Global Administrator; e comunidade efetiva em Adj-RIB-Out. O ticket deve nomear quem aprovou a continuidade semântica ou o novo cálculo.

No receptor, conservar multipath candidates, motivos de elegibilidade, tratamento de zero/ausente/múltiplo, função local/remota e pesos da FIB em hardware. Medir participação real de tráfego, fila, perda, latência e resultado de aplicação. Um anúncio correto não prova que o ASIC mudou.

A Running-Code Primacy de Heng Lu obriga a verificar essa cadeia no sistema vivo. A Minimum Initial Specification preserva no plano comum apenas formato, interoperabilidade e segurança; a fórmula e a aceitação de risco permanecem locais.

Quando o next hop muda, o silêncio não é neutralidade. Preservar, remover e regenerar são três atos de autoridade.