Resumo

  • A RFC 5880 torna o BFD uma forma independente de protocolo para detectar falhas em um caminho bidirecional de encaminhamento, potencialmente com latência muito baixa.
  • O sinal não é uma política de seleção de rota: aplicações criam e consomem sessões, enquanto temporizadores agressivos trazem custos de pacotes, processamento e falsos positivos.

Um sinal estreito com consequências amplas

O BFD observa o caminho bidirecional entre dois mecanismos de encaminhamento. Segundo a RFC 5880, esse caminho pode incluir interfaces, enlaces de dados e, quando possível, os próprios mecanismos. O protocolo é deliberadamente independente do meio, do protocolo de dados transportado e do protocolo de roteamento que consome seu estado.

Esse escopo estreito explica o valor. Um protocolo de roteamento não precisa sempre esperar seu próprio Hello ou temporizador de inatividade para saber que o caminho de encaminhamento falhou. Um serviço pode consumir o mesmo estado básico. Mesmo assim, o BFD não decide qual prefixo mover, qual próximo salto vencerá ou se uma adjacência deve ser encerrada. Ele informa estado; o cliente mantém a autoridade de política.

A RFC 5882 delimita a função: para uma aplicação, o BFD verifica a conectividade entre dois sistemas para um protocolo de dados e um caminho específicos. Não pretende provar a saúde do protocolo de controle. Um estado Down pode justificar uma reação de roteamento, mas não comprova que todos os processos de controle falharam nem que uma alternativa seja segura.

Criar uma sessão é uma decisão de autorização

O BFD não possui descoberta. A aplicação fornece o endereço remoto e os demais parâmetros. A cobertura é configurada, não presumida: um caminho nunca associado a uma sessão não fica protegido apenas porque o BFD opera em outro ponto do equipamento.

A RFC 5882 também diz que vários clientes que monitoram o mesmo caminho do mesmo protocolo de dados deveriam compartilhar uma sessão BFD. O estado passa a ser uma dependência comum. Um responsável precisa definir quais aplicações podem consumi-lo, qual família de endereços e caminho ele representa e como a mudança chega a diferentes sistemas de controle.

A operação de salto único torna as fronteiras concretas. A RFC 5881 exige sessões separadas para IPv4 e IPv6 quando ambos são monitorados no mesmo caminho. Também exige TTL ou Hop Limit 255 nos pacotes Control recebidos, limitando a aceitação ao par diretamente conectado. A autenticação pode proteger os pacotes, mas implantação e gestão de chaves continuam sob responsabilidade operacional.

A regra de compatibilidade é igualmente importante. Quando se acredita que um vizinho não oferece BFD, a RFC 5882 afirma que a adjacência do protocolo de controle não deve ser bloqueada só por isso. O BFD acrescenta um sinal de falha; não autoriza tornar a conectividade básica dependente de um recurso ausente.

Tempo de detecção é comprado com capacidade

No modo Asynchronous, cada sistema envia periodicamente pacotes Control. Se o número negociado não chega dentro do tempo de detecção, a sessão entra em Down. O modo Demand pode suspender os pacotes periódicos depois que a sessão está Up, mas somente quando outro mecanismo verifica a conectividade de modo independente. A função Echo opcional testa o caminho com pacotes devolvidos pelo plano de encaminhamento remoto.

Intervalos curtos não criam certeza gratuita. A RFC 5881 exige dimensionamento para que o BFD não congestione o enlace, as filas de entrada nem o processador. Se o monitor sobrecarrega o caminho ou o equipamento, pacotes atrasados podem parecer a falha que o próprio monitor ajudou a produzir. Um temporizador rápido reduz um black hole real, mas também pode transformar congestionamento transitório em retirada de rota ou oscilação de serviço.

A RFC 7419 reduz o risco de interoperabilidade com um conjunto comum de intervalos. Ela resolve a negociação, não a decisão de capacidade. Um valor aceito por dois equipamentos não serve automaticamente para todo volume de sessões, desenho de filas, domínio de falha ou política de recuperação.

Up não significa estável

A máquina de estados mantém a sessão Up se pacotes Control suficientes chegam dentro da janela de detecção. Perdas isoladas podem não alterar o estado. A RFC 9978, uma especificação Experimental, acrescenta a contagem de pacotes Control BFD ausentes por números de sequência meticulosos e um modelo YANG, buscando revelar deterioração antes de a sessão permanecer sem pacotes por tempo suficiente para ficar Down.

O limite é explícito: mede perda de pacotes BFD, não perda ou atraso de dados de usuários. ECMP e agregação de enlaces podem reordenar pacotes; sem compensação, uma comparação simples pode confundir reordenação com perda. O sinal pode orientar uma investigação OAM, mas não identifica sozinho a causa raiz.

Evidências e limites

As RFCs 5880, 5881 e 5882 definem mecanismo, restrições de salto único e relação com aplicações. A RFC 7419 padroniza intervalos comuns. A RFC 9978 acrescenta uma medição experimental de estabilidade.

As fontes não oferecem um temporizador universalmente seguro, um censo atual de implantação ou garantias de fornecedor. O estado BFD não identifica a causa e não escolhe a rota sobrevivente.

Fontes