Resumo

  • RFC 9764 aumenta até um valor configurado a carga de transporte que contém o PDU BFD. O preenchimento deve ser zero e, em IPv4, Don't Fragment deve estar ativo; Up passa a registrar a chegada recorrente desse tráfego no tamanho escolhido.
  • A observação pertence a um sentido e ao tratamento de encaminhamento efetivamente usado. A conclusão bidirecional requer configuração dos dois lados, e LAG ou ECMP podem deixar membros fora do fluxo BFD.
  • pdu-size é um controle compartilhado. O maior pedido entre clientes deve prevalecer, de modo que uma alteração pode derrubar uma sessão já Up e acionar outros protocolos antes de distinguir MTU estreita, incompatibilidade, filtro ou ataque.

Uma equipe aumentou o tamanho de um teste e viu BFD cair. Outra reduziu a cifra e viu Up voltar. Era tentador encerrar o incidente com uma frase: “o caminho não suporta o tamanho maior”. A sequência demonstrava uma fronteira, mas ainda não localizava sua causa. O par remoto podia rejeitar o encapsulamento, um filtro podia tratar o pacote de modo diferente, ou apenas um membro do agregado podia ser estreito.

RFC 9764 foi desenhada para tornar essa fronteira observável. Pacotes BFD comuns são pequenos. Eles verificam conectividade entre sistemas, mas uma aplicação pode precisar de um Path MTU mínimo. A RFC mantém o modo Asynchronous e amplia a carga do protocolo de transporte até bfd.PaddedPduSize.

Os bytes adicionais devem ser zero. O receptor não deve transformá-los em um novo conteúdo a validar. Em IPv4, o bit Don't Fragment precisa estar marcado. Se o pacote não couber, a rede não pode satisfazer a condição fragmentando-o em unidades menores.

O mecanismo é pequeno e verificável. A conclusão correta também precisa ser pequena.

Up confirma um piso escolhido, não descobre o teto

A máquina de estados continua sendo a de RFC 5880. A RFC 9764 não muda a semântica central do PDU. Ela aumenta o transporte; quando os controles deixam de ser aceitos ou entregues, o receptor se comporta como se não os tivesse recebido e a sessão segue a detecção normal.

Se o valor é 1.512 bytes e a sessão permanece Up, há evidência de que os controles BFD observados atravessaram nesse tamanho. Não há evidência de que 1.512 seja o máximo. O caminho pode aceitar mais. Se o MTU crescer depois, a sessão não anuncia o novo espaço; ela continua verificando o mínimo anterior.

RFC 1191 define Path MTU como propriedade de um caminho específico e faz o emissor reduzir sua estimativa diante de evidência limitada. RFC 8899 organiza sondagem na camada de paquetização para transportes por datagrama. RFC 9764 não é uma busca geral pelo maior pacote. Ela sustenta um limiar operacional que um cliente declarou necessário.

Por isso, o MTU de uma interface local não é uma escolha automática. Uma porta de 9.000 bytes pode alimentar um túnel ou salto menor. A aplicação talvez precise só de 1.400. Um valor excessivo adiciona risco sem relevância; um valor pequeno demais deixa Up uma sessão incapaz de representar a exigência real.

Cada sentido precisa produzir sua própria evidência

O nome Bidirectional Forwarding Detection não transforma uma configuração unilateral em teste dos dois sentidos. A RFC exige PaddedPduSize nas duas extremidades quando a aplicação precisa confirmar o tamanho em ida e volta.

A para B e B para A podem atravessar rotas, filas, túneis ou filtros diferentes. Há enlaces com MTU assimétrica por projeto. Nesses casos, valores diferentes podem ser corretos. O registro precisa preservar origem, destino, tamanho, instante da última recepção e época da configuração para cada direção.

RFC 5881 trata BFD single-hop. Em conexão direta, o MTU de interface costuma oferecer uma garantia local importante. RFC 5883 trata multihop, onde a primeira interface não descreve os saltos seguintes. O pacote grande é mais útil nesse caso, mas o termo “rota” também se torna mais perigoso se não vier acompanhado de sentido e escopo.

Um painel pode resumir os dois lados em uma luz. Uma auditoria não pode deixar que essa luz apague os dois fatos que a formaram.

O maior cliente muda a condição de todos

Vários protocolos clientes podem compartilhar uma sessão BFD. Se um solicita 1.400 bytes e outro 1.600, a implementação deve escolher o maior valor. Usar o menor permitiria Up sem atender ao cliente mais exigente.

Essa regra torna o pedido máximo uma decisão compartilhada. A entrada de um novo cliente pode alterar a disponibilidade observada pelos anteriores. Se o remoto suporta BFD normal, mas rejeita o payload acolchoado de 1.600 bytes, a sessão cai; clientes que só precisavam de 1.400 podem iniciar failover.

O controle de mudança deve registrar solicitante, clientes dependentes, valor anterior, novo valor, capacidade de ambos os lados, ação vinculada a Down e rollback. Sem essa genealogia, uma necessidade local se torna autoridade invisível sobre vários sistemas.

A alteração também faz parte da causalidade. Subir pdu-size em uma sessão Up pode revelar uma limitação antiga ou introduzir uma forma nova que o par nunca aceitou. “A medição encontrou falha” e “a mudança criou incompatibilidade” são hipóteses distintas.

Um silêncio no receptor comporta várias explicações

O PDU BFD interno permanece válido, porém algumas implementações não aceitam carga de transporte arbitrariamente maior ou a rejeitam por validação incorreta. Para a máquina de estados, isso se parece com uma perda no caminho.

Um equipamento intermediário pode filtrar pelo tamanho. Um atacante em rota capaz de descartar BFD seletivamente pode provocar Down. O preenchimento zero evita expor memória local não inicializada, mas não autentica a causa do descarte.

Três frases devem permanecer separadas. “Os controles grandes pararam de sustentar a sessão” é observação. “O Path MTU ficou abaixo do limiar” é diagnóstico. “Retirar a rota” é decisão. O automatismo seguro não pula da primeira para a terceira sem verificar capacidade do par, captura nas duas pontas, contadores, tamanho anterior e canário de serviço.

Down é uma entrada legítima para investigação e política. Não é um texto pronto sobre o mundo.

ECMP deixa membros invisíveis para um fluxo estável

LAG e ECMP distribuem fluxos por vários membros. Um hash pode manter BFD em um membro saudável, enquanto tráfego de cliente cai em outro com MTU menor. BFD permanece Up e parte do serviço falha.

RFC 7130 fornece BFD para membros de LAG. A RFC 9764 ressalta que não existe um mecanismo BFD multihop geral padronizado capaz de exercitar todos os links ECMP. Alguns produtos usam conhecimento interno para ampliar a cobertura; isso é comportamento específico de implementação.

O teste continua válido para o fluxo que executou. O erro é projetá-lo sobre todo valor de entropia. MTUs inconsistentes entre membros tornam a capacidade dependente do fluxo.

O artigo BTW sobre RFC 9978 já delimitou outra medida: contar controles BFD perdidos não comprova perda no plano de dados. Aqui, o limite é entre o tamanho levado pelos controles e o tamanho levado por todas as aplicações.

O valor YANG é intenção, estado e possível causa

O módulo ietf-bfd-large amplia os modelos BFD de RFC 9314 segundo a arquitetura NMDA de RFC 8342. Ele adiciona a feature padding e a folha gravável pdu-size a estruturas single-hop, multihop, LAG e MPLS.

A presença no datastore demonstra uma intenção configurada. Ainda é preciso provar o estado operacional, a versão de software, a capacidade remota, os clientes e os pacotes observados. A própria RFC avisa que escrever o valor numa sessão Up pode fazê-la cair e afetar vários clientes. O acesso a esse nó pertence ao controle de mudança e à autenticação de gestão.

RFC 7880 oferece o contexto de S-BFD, e a técnica também pode ser aplicada ali. Reuso do mecanismo não significa identidade de caminho, direção ou responsabilidade.

Repetir diminui a idade; não elimina o próximo acaso

RFC 9869 usa tokens REQ/RES em UDP Options para confirmar uma sonda de tamanho. Seu artigo BTW trata da diferença entre a sonda recebida e um datagrama futuro. RFC 9764 adiciona recorrência: o tamanho é reexercitado periodicamente por BFD.

Isso melhora a atualidade, mas o próximo pacote de serviço pode receber outro hash ECMP, encapsulamento ou fila. A observação mais honesta inclui tempo e escopo: “Up recentemente com controles de X bytes neste sentido e nesta configuração”. “A rede suporta X” apaga o sujeito da prova.

Fontes e limite probatório

O conjunto congelado contém RFC 9764, as bases BFD RFC 5880, RFC 5881, RFC 5883, RFC 7130 e RFC 7880, os modelos RFC 9314 e RFC 8342, e o contexto de tamanho RFC 1191, RFC 8899, RFC 9869 e RFC 9978.

A lente de governança vem dos textos de Heng Lu sobre Minimum Initial Specification, Running-Code Primacy e Reality Layers. A especificação comum deve produzir um fato local verificável; a decisão seguinte permanece com quem suporta o resultado.