Resumo

  • O contrato do draft 19 depende de ambos os peers anunciarem a capability 74; alguns produtos também oferecem comportamento unilateral ou override, que muda a autoridade da decisão.
  • O apêndice de implementação registra releases associados a revisões diferentes do draft e uma implementação sem BfdHoldTimer, portanto “supported” não é uma equivalência completa.
  • Uma migração precisa conservar a semântica nativa, testar pares heterogêneos e provar rollback antes de normalizar qualquer estado em uma plataforma central.

O inventário antigo dizia bfd_strict: true. A nova plataforma aceitou o campo e gerou a configuração correspondente em três famílias de equipamento. Em uma, true significava anunciar capability e exigir reciprocidade. Em outra, significava bloquear BGP mesmo sem anúncio remoto. Na terceira, a espera adicional usada pelo desenho central não existia naquela release.

A migração converteu todas as linhas sem erro. O significado não migrou.

Esse é o problema de gestão revelado por draft-ietf-idr-bgp-bfd-strict-mode-19. O documento ativo do grupo IDR, datado de 26 de agosto de 2026, pretende atualizar RFC 4271 se for aprovado. Ainda é Internet-Draft, com estado I-D Exists e comentários precoces que pedem esclarecimentos operacionais e de segurança. A sua contribuição central é definir um contrato explícito entre BFD e o FSM de BGP; sua existência não homogeneíza automaticamente o software já em produção.

O mesmo nome pode carregar autoridades diferentes

No modelo negociado, cada speaker inclui capability 74 no OPEN quando suporta e habilita strict mode. BfdStrictNegotiated só se torna verdadeiro depois da interseção. O peer local não ganha o direito de impor o gate apenas porque sua configuração o deseja.

No modelo unilateral, a política local pode impedir o estabelecimento de BGP mesmo se o remoto não declarou o mesmo suporte. Um override faz isso de forma deliberada para atravessar uma fase de compatibilidade ou manter comportamento anterior. Não é necessariamente um erro. É uma autoridade diferente e precisa de um proprietário explícito.

Documentação atual da Cisco separa strict mode, strict-mode negotiate e override, e registra desafios de interoperabilidade entre comportamentos não padronizados. A Juniper documenta a exigência bilateral e recomenda configurações e holddowns iguais. Uma camada de automação que traduz tudo para enabled destrói a diferença que os próprios produtos expõem.

O modelo de dados deve manter pelo menos: modo nativo, escopo do comando, release, semântica quando o peer não anuncia capability, capability enviada e recebida, resultado negociado e motivo do override. A normalização pode produzir uma visão comum depois; não pode apagar o recibo original.

Running code vem em revisões, não em uma caixa

O apêndice de implementação lista Junos 23.2R1 e posteriores com compatibilidade da revisão 17, IOS XR 24.3.1 e posteriores com a revisão 12, e Nokia 23.7R1 com a revisão 07. A entrada Nokia informa que BfdHoldTimer ainda não era suportado na implementação citada.

Essas declarações dão substância à discussão. Há código usado. Mas RFC 7942 não transforma uma lista de implementações em certificação cruzada. As entradas não dizem que todo par de plataformas foi testado com todos os eventos da revisão 19. Também não dizem que um release futuro conserva a mesma semântica de comando.

Uma migração precisa tratar versão de comportamento como dado operacional. Em vez de perguntar se o dispositivo “tem strict mode”, pergunta quais eventos do FSM implementa, como reage ao KEEPALIVE remoto recebido antes do BFD local Up, qual timer limita a espera quando BGP holdtime é zero e quando uma mudança de configuração se torna efetiva.

Depois de Established, o draft ignora BfdStrictConfigChanged na sessão corrente. A base de configuração pode mostrar o novo valor enquanto o processo ativo ainda usa o antigo até o próximo restart. Migração que valida só a configuração desejada aceita um estado dividido dentro do mesmo equipamento.

O contrato temporal precisa sobreviver à tradução

O draft adiciona BfdHoldTime, com padrão de 30 segundos, e BfdHoldTimer para o caso de BGP holdtime zero. Um hold-down pode exigir estabilidade BFD antes de Established. O valor é local; a recomendação é usar valores semelhantes, não um número negociado.

Ao converter configurações, a ferramenta deve preservar unidade, precedência e condição de uso. Um campo wait=30 pode significar espera BFD apenas quando holdtime BGP é zero em uma plataforma, hold-down geral em outra, ou nem existir na release de destino. Copiar o número não copia a regra.

O risco aparece na desigualdade. Um peer entra em Established e começa seu holdtime. O outro permanece pending durante um hold-down mais longo e ainda não envia KEEPALIVEs. O primeiro fecha a sessão. O segundo acredita estar protegendo a estabilidade. A configuração central apresenta dois valores válidos, sem mostrar que a soma de inicialização e espera excede a paciência do vizinho.

Migração segura começa por incompatibilidades

Monte a matriz por par real: origem e destino da migração, plataformas, releases, comandos, modo semântico, capability, timers, autenticação, subestados visíveis e notificações. Teste primeiro os pares heterogêneos que a produção realmente usa.

Execute entradas adversas. Retire a capability de um lado; atrase BFD local; deixe o remoto enviar KEEPALIVE primeiro; use hold-downs diferentes; faça BGP holdtime expirar; mude o modo depois de Established; suprima apenas pacotes BFD. Cada caso precisa de uma saída conhecida e de um caminho de volta.

O rollback não é restaurar o texto antigo. É restabelecer o contrato efetivo em ambas as pontas. Pode exigir remover override, confirmar que nenhum peer continua pending, reiniciar somente a sessão afetada para aplicar a semântica desejada e verificar que as rotas retornaram sob o mecanismo esperado.

Preserve o transcript de OPEN e capability, estados BFD, subestado BGP, timer ativo e notificação. Sem esses dados, uma sessão que finalmente subiu pode esconder várias tentativas incompatíveis. A taxa de sucesso não mostra quanto churn foi produzido antes do sucesso.

Segurança também tem semântica de migração

A revisão de segurança chama atenção para capability stripping, integridade do OPEN, autenticação BFD opcional e baseada em algoritmos legados, e a impossibilidade de autenticação impedir supressão de pacotes. Um atacante on-path ou congestão pode manter BFD abaixo do gate e negar BGP; depois de Established, pode causar teardown repetido.

Migrar o comando sem migrar keychain, modo de autenticação, GTSM e observabilidade altera o risco. Um dashboard pode mostrar strict mode preservado enquanto a proteção da evidência mudou. O recibo de migração precisa incluir tanto a regra de admissão quanto a origem e disponibilidade do sinal que a governa.

Running-Code Primacy oferece a ordem correta: especificação mínima, validação local, implementação, compatibilidade observada e adoção consciente. A plataforma central não cria equivalência pelo ato de traduzir. Ela deve tornar diferenças decidíveis.

O modo era estrito antes e depois. Isso não prova que a rede manteve o mesmo limite. Uma migração bem-sucedida não conta quantos campos foram convertidos; prova que dois peers continuam esperando o mesmo evento, pelo mesmo tempo, sob a mesma autoridade e com a mesma saída reversível.

Fontes