Resumo

  • As versões 10.7.1, 10.6.2 e 10.5.5 do FRRouting, de 25 de agosto de 2026, incluem a correção #22681 para valores elevados na comunidade estendida de largura de banda de BGP.
  • O modo IEEE e o formato inteiro clássico exigem resultados acumulados diferentes. Também é necessário separar o que o emissor anuncia, o que o receptor interpreta e o que o plano de encaminhamento executa.

Uma checagem aparentemente simples — somar 30 e 100 Gbit/s — pode reprovar uma atualização correta. No FRRouting, a resposta depende de como a banda acumulada será codificada para o próximo vizinho. O modo IEEE deve preservar um valor próximo de 130 Gbit/s. O formato inteiro clássico continua limitado a aproximadamente 34,36 Gbit/s.

Essa diferença explica por que o reparo listado nas notas de 10.7.1, 10.6.2 e 10.5.5 exige mais do que conferir o pacote instalado. As três versões foram publicadas em 25 de agosto. O problema corrigido está na representação numérica de um atributo de BGP, não em uma medição de capacidade física dos enlaces.

O teto era de um tipo numérico

A proposta #22681, incorporada em 28 de julho, descreve funções auxiliares que estreitavam valores de banda para inteiros sem sinal de 32 bits durante codificação, decodificação ou apresentação. BGP já mantinha a banda internamente em um inteiro de 64 bits. Além disso, a substituição da banda cumulativa aplicava o máximo de 32 bits sem distinguir a codificação.

O campo usa bytes por segundo. O máximo de 4.294.967.295 bytes por segundo equivale a cerca de 34,36 Gbit/s: daí o limiar pouco usual. Já o formato IEEE transmitido pela rede usa ponto flutuante de 32 bits, com outro alcance numérico, conforme o RFC 10005. Ter o mesmo número de bits não implica ter o mesmo intervalo de valores.

A correção amplia o tratamento interno e mantém o teto cumulativo apenas para o modo inteiro bruto clássico. Não cria um formato de 64 bits no protocolo. Tampouco elimina o arredondamento normal de ponto flutuante. Dizer que o FRRouting passou a permitir que uma porta de 100 Gbit/s superasse 34 Gbit/s confundiria o valor anunciado com desempenho físico que essas fontes não mediram.

Dois testes, duas respostas e alcances diferentes

Nos testes alterados, dois vizinhos BGP internos fornecem 30.000 e 100.000 Mbit/s. A soma exata é 16.250.000.000 bytes por segundo. Ao reproduzir as conversões de precisão simples dos valores e da soma, chega-se a 16.249.999.360. A diferença pequena é arredondamento, não reincidência do estreitamento inteiro.

Para a codificação clássica, o resultado esperado é 4.294.967.295 bytes por segundo. O teste atualizado exige esse limite, substituindo um resultado truncado menor. Nesse ramo, continuar vendo aproximadamente 34,36 Gbit/s pode ser justamente o comportamento corrigido. Um número sem o modo do vizinho e o ponto de observação não resolve o diagnóstico.

A aritmética foi conferida de forma independente para esta análise. Não executamos a topologia de testes do FRRouting. A leitura do código estabelece o que é verificado, não constitui reprodução de um ambiente de produção.

Há uma diferença adicional: o teste IEEE consulta a base de informações de rotas do equipamento que recebe as entradas, seu anúncio para um vizinho BGP externo e a base desse vizinho. O ramo de inteiros consulta apenas a representação das rotas anunciadas no emissor. Não verifica a decodificação no receptor. Nenhum deles comprova pesos instalados no hardware, divisão efetiva dos fluxos ou velocidade percebida por uma aplicação.

O acumulado merece uma medição própria

A documentação de múltiplos caminhos ponderados explica que as razões de banda orientam pesos entre caminhos que já atendem aos requisitos de multipath. O atributo não muda a seleção da melhor rota nem torna elegível uma rota que antes não era. A capacidade do sistema de encaminhamento de usar os pesos e o comportamento dos fluxos são verificações separadas.

Um equipamento pode somar várias contribuições e anunciar o total adiante. Mesmo que cada entrada fique abaixo de um teto inteiro, a soma pode ultrapassá-lo. Uma inspeção restrita às entradas deixa de fora a operação que o reparo altera.

O FRRouting ainda oferece uma opção por vizinho para a codificação antiga. A existência do reparo não autoriza recomendar sua remoção em toda a rede: o outro lado precisa interpretar corretamente os bytes recebidos. Algumas descrições atuais de limites de comandos são mais estreitas do que as entradas desses testes fixadas em uma revisão. Por isso, o procedimento operacional deve partir da compilação real e da configuração suportada, não copiar o teste como receita para todas as versões.

As fontes verificadas até 8 de setembro, às 12h40 UTC, não fornecem quantidade de clientes afetados, incidente em produção, ganho medido de velocidade ou relação completa de versões atingidas. As três notas confirmam a inclusão do reparo nelas; não permitem concluir a situação de todas as outras.

Essa separação entre mecanismo e promessa segue a orientação editorial de Lu Heng sobre realidade, não defesa de uma causa. Trata-se da aplicação do princípio pelo autor, e não de uma avaliação do FRRouting feita por Lu Heng. O avanço prático está em definir o que será aceito: modo, valor e observação no receptor, além da versão instalada.