Resumo

  • O BFD Reverse Path TLV de RFC 9612 deixa o ingresso pedir um FEC de retorno para os pacotes BFD Control. Ele documenta a intenção, mas uma falha continua sendo observação do percurso completo.
  • O código 193 pode aparecer junto de BFD Up: o retorno pedido não foi encontrado, enquanto a política local autorizou outro caminho IP. Pedido recusado e controle disponível são fatos compatíveis.
  • A prova operacional liga LSP de ida, FEC reverso, resposta ao TLV, percurso efetivo, estado BFD, Reply Path, redirecionamento, aviso ao operador e entrega da aplicação.

O painel mostra BFD Up e a equipe conclui que o par de caminhos planejado continua intacto. Essa conclusão não cabe no indicador. Um pacote de controle saiu por um trecho e voltou por algum outro. A volta pode ter seguido o FEC solicitado, uma resolução nova ou um fallback IP. A continuidade do ciclo não identifica por si só as partes que o formaram.

O erro oposto ocorre quando a sessão cai. O nome do LSP de ida aparece no alerta e vira causa antes de investigação. Porém o retorno pode ter falhado, mudado de FEC ou sido recusado pelo egresso. Detectar cedo é uma propriedade valiosa; atribuir direção exige evidência adicional.

RFC 9612 é Experimental e acrescenta BFD Reverse Path TLV às solicitações MPLS LSP echo. O ingresso informa sub-TLVs Target FEC Stack permitidos para que o egresso envie BFD Control pelo LSP reverso especificado. A extensão transforma a preferência de retorno em uma mensagem interoperável.

Ela não transfere toda a operação para o protocolo. Os pares compartilham pedido, retirada e erros precisos. O egresso mantém sua política de fallback. O encaminhamento em execução decide por onde o pacote passa, e a aplicação decide se o serviço foi entregue. Uma camada não pode substituir as demais.

Uma volta verde pode esconder outra topologia

RFC 5880 define BFD como detecção rápida de continuidade. No uso MPLS de RFC 5884, a ida pode seguir um LSP e a volta usar roteamento IP. O resultado confirma comunicação entre extremos, mas não isola a saúde do LSP de ida.

RFC 9612 dá ao retorno uma identidade solicitada. O TLV tem Tipo 16384 e contém zero ou mais FECs não multicast. Um FEC multicast recebe código 192, pois não serve à semântica do retorno. O limite padrão de 128 entradas reduz o risco de uma lista inflada consumir busca e estado no egresso.

Mesmo assim, BFD continua observando o ciclo. Se o pacote não volta, a ida, a volta, a resolução do FEC ou a decisão do egresso podem ser responsáveis. Se volta, sabe-se que algum ciclo funcionou; ainda é preciso provar se foi o ciclo contratado.

Por isso o inventário precisa separar “solicitado” de “observado”. O primeiro vem da configuração e do TLV. O segundo vem da tabela de encaminhamento e dos pacotes. BFD fornece a continuidade. A disponibilidade do cliente vem de outro teste. Misturar os campos permite que uma contingência temporária seja apresentada como arquitetura estável.

O significado limitado do código 193

Quando não encontra o caminho reverso especificado, o egresso deve devolver código 193. A frase significa exatamente que o retorno pedido não foi encontrado. Não significa que nenhum BFD possa ser estabelecido.

Se a configuração local permitir, o egresso pode transmitir por uma rota diferente, tipicamente IP. O operador então recebe dois recibos verdadeiros: 193 para a intenção recusada e Up para a sessão alternativa. A política de visualização não deve escolher um e apagar o outro.

Essa combinação tem impacto próprio. Pode manter detecção e serviço enquanto perde diversidade física. Pode cumprir uma meta de disponibilidade e descumprir uma condição de risco. Um contrato que aceita apenas BFD Up não consegue distinguir as duas situações.

Um Reverse Path TLV vazio retira a seleção anterior e devolve o retorno à política local. Depois de uma seleção, uma mensagem LSP ping com BFD Discriminator TLV, mas sem Reverse Path TLV, também faz o egresso voltar à transmissão periódica segundo RFC 5884. A ausência, portanto, é uma mudança de estado e precisa de trilha.

A explicação chega em outro relógio

FECs podem mudar depois da criação da sessão. Manutenção, reconvergência e política podem alterar a resolução sem trocar o discriminador. Por isso a implementação deve suportar mudança de caminho reverso após o estabelecimento.

Depois de uma falha, o ingresso usa o Reply Path TLV de LSP ping para verificar a validade do FEC reverso. Se ele mudou, deve redirecionar a sessão para outro FEC e notificar um operador. Verificação, ação automática e prestação de contas aparecem em sequência.

Os intervalos não são iguais. BFD Control corre rápido para reduzir o tempo de detecção. A verificação de controle e dados com Reply Path ocorre bem mais devagar. Durante o intervalo, a falha é conhecida e a causa continua aberta. Preencher a direção nesse momento cria um dado falso.

Uma manutenção planejada pode mover o retorno antes da intervenção. Isso reduz alguns alarmes, mas não elimina toda mudança inesperada nem a diferença entre frequências. O procedimento deve aceitar o estado “falha detectada, direção pendente” e medir quanto tempo ele dura.

Política local exige transparência local

O ingresso pede um FEC com linguagem comum. O egresso decide se permite fallback, quantas entradas processa e que recursos dedica. Essa distribuição mantém escolhas futuras perto de quem assume custo e risco.

Mas a escolha precisa aparecer. Um fallback silencioso faz o ingresso acreditar que monitora o retorno especificado. Autonomia não é licença para representar outro caminho como se o pedido tivesse sido atendido. Telemetria deve mostrar pedido, resposta e seleção real.

Os controles de segurança reforçam o limite. A lista padrão não passa de 128 para conter inflação; uma implementação pode ser mais restritiva. O código 192 recusa um tipo incompatível de forma inequívoca. Um erro preciso preserva a capacidade de decisão das duas partes.

Experimental também é um recibo limitado. Indica a categoria do documento, não uma lista de produtos, uma implantação presente ou maturidade Standards Track. Suporte real requer ensaio da versão, configuração, hardware e rede que estarão em produção.

Construir a cadeia de custódia

Antes do incidente, registre LSP de ida, FEC reverso pedido, TLV transmitido, resposta e caminho observado. Acrescente discriminadores, intervalos e estado BFD sem sobrescrever esses dados.

Após o alarme, registre Reply Path, resolução atual do FEC, alternativa escolhida, horário do redirecionamento e notificação. Encerre com perda, latência e entrega na fronteira do serviço. Um controle vivo não comprova a experiência do usuário.

O teste deve passar por sucesso e falhas. Instale um retorno válido e capture os pacotes. Mude o FEC com sessão ativa. Peça um caminho inexistente e observe 193 com fallback habilitado e desabilitado. Envie FEC multicast para receber 192, retire com TLV vazio, omita o TLV mantendo o discriminador e ultrapasse o limite configurado.

Compare API, plano de controle, encaminhamento e captura. Software pode anunciar o novo FEC enquanto o hardware usa o antigo. Um fallback pode funcionar sem aparecer no modelo de gestão. A identidade do caminho só existe como fato operacional quando essas camadas concordam.

Um relatório útil pode dizer: “o FEC reverso solicitado sumiu; o egresso respondeu 193; BFD continuou por IP; o serviço permaneceu disponível; Reply Path encontrou um FEC substituto; houve redirecionamento e aviso”. Cada trecho pode ser auditado sem depender da cor do painel.

Fontes