Resumo

  • O RFC 6428 intercala Continuity Check (CC) e proactive Connectivity Verification (CV) na mesma sessão BFD. CC usa o código G-ACh 0x0022; CV usa 0x0023. Em operação normal, pacotes CC são intercalados com um CV por segundo.
  • O CV acrescenta o TLV Source MEP-ID, que não deve ser alterado por um nó. O sink MEP usa essa identidade para detectar mis-connectivity. RDI aparece somente no campo diagnostic BFD das mensagens CC; o campo diagnostic das mensagens CV deve ser ignorado.
  • A perda de continuidade é detectada após a periodicidade da sessão multiplicada pelo Detect Multiplier remoto 3. A mis-connectivity deve ser detectada em até um segundo, e a saída desse defeito exige 3,5 segundos sem receber um CV que o exiba.

O mecanismo e as fronteiras de autoridade

O operador configura MEG, MEP-ID, periodicidade CC, estado CV desejado, estado de autenticação e chave quando usada. O discriminator do par pode ser configurado ou atribuído localmente. O MEP de origem envia evidência, mas não pode declarar sozinho que o receptor está ligado ao objeto correto. O sink MEP avalia Source MEP-ID, tipo de MEP, encapsulamento, correspondência entre discriminator e label e, quando habilitada, a autenticação.

Encapsulamento incorreto, Source MEP-ID ou tipo inesperado, discriminator associado a outra label, discriminator esperado chegando pela label errada e falha de autenticação quando ela está habilitada são condições de mis-connectivity. Ao entrar no defeito, o sink MEP sinaliza signal fail aos processos clientes. O bloqueio de tráfego, porém, deve ser decidido apenas pela defect consequent action definida pelo arcabouço OAM de MPLS-TP; a simples recepção de um pacote não autoriza o bloqueio.

O sink deve usar diagnostic 1 para expiração do tempo de detecção, diagnostic 5 depois de Link Down Indication e diagnostic 9 para mis-connectivity detectada.

Na operação coordenada, uma sessão BFD bidirecional acompanha o estado do defeito. Na operação independente, duas sessões são usadas, e uma delas pode permanecer UP enquanto recebe RDI remoto. Todas as mudanças de estado e trocas Poll/Final devem usar CC; informações de estado e Poll/Final em CV devem ser ignoradas. Assim, configuração do operador, evidência do MEP de origem, classificação do defeito pelo sink MEP e ações consequentes associadas ao RFC 6371 permanecem autoridades separadas.

Fixações de verificação para o operador

  1. Capture e confirme os códigos G-ACh 0x0022 para CC e 0x0023 para CV. Se houver GAL, confirme que ele está no fundo da pilha e que seu TTL é pelo menos 1.
  2. Verifique a alternância entre CC e um CV por segundo. Para perda de continuidade, confira o tempo normativo como “periodicidade da sessão × Detect Multiplier remoto 3”, sem inventar latência adicional.
  3. Compare o Source MEP-ID do TLV CV com o MEP esperado, confirme o tipo e procure qualquer alteração do valor por um nó intermediário.
  4. Valide que os discriminators local e remoto apontam para a mesma label; faça também a verificação inversa para o discriminator esperado que chega por uma label errada.
  5. Compare encapsulamento, MEG, MEP-ID, periodicidade CC, estado CV, ativação de autenticação e chave com a configuração do operador. Uma falha de autenticação não pode ser tratada como identidade validada.
  6. Leia RDI somente no campo diagnostic de CC e marque o diagnostic de CV como ignorado. Não use estado de sessão nem Poll/Final de CV para mudar o estado BFD.
  7. Diferencie diagnostic 1 (expiração da detecção), 5 (Link Down Indication) e 9 (mis-connectivity); confirme a saída somente após 3,5 segundos sem CV exibindo esse defeito.
  8. Registre se o modo é coordenado ou independente. No modo independente, preserve separadamente UP local, RDI remoto e o estado da direção oposta.
  9. Lembre que o TLV Source MEP-ID fica fora do comprimento do pacote de controle BFD e não entra no digest quando há autenticação por digest BFD. Isso é uma questão específica de integridade, não algo eliminado pelo sucesso da autenticação.

Caminho de decisão

Primeiro confirme encapsulamento e transporte G-ACh; depois confira label e discriminator. Em seguida, use Source MEP-ID e tipo do CV para decidir se o endpoint é o esperado, leia RDI somente do diagnostic CC e confirme modo e timers. Se houver mis-connectivity, classifique-a como defeito no sink MEP, reporte diagnostic 9, aguarde a condição de saída de 3,5 segundos e aplique somente a consequent action OAM correspondente. Se houver apenas RDI remoto, não transforme UP em “serviço saudável” no modo independente; apresente separadamente o estado local, o defeito remoto e o efeito no cliente.

CC sem CV pode mostrar continuidade, mas não estabelece a origem pretendida. Usar o diagnostic de CV para inferir RDI criaria autoridade a partir de um campo que a especificação manda ignorar. Source MEP-ID errado ou mapeamento de label errado continua sendo defeito mesmo com pacotes chegando; sessão UP não prova saúde da aplicação. O conjunto de fontes não informa quais fornecedores ou operadores implantam RFC 6428, qual modo escolhem, qual a prevalência, taxa de falso positivo, duração de impacto ao cliente, custo comercial ou resultado observado de restauração. Não há alegação de incidente ou adoção.

RFCs 5880, 5586, 5921, 5860, 6371, 5884 e 5885 entram apenas nos papéis declarados de máquina de estados, transporte, arcabouço, requisitos, ações consequentes e escopos MPLS/VCCV; nenhum substitui as regras de processamento do RFC 6428. A página de errata é apenas um snapshot de recuperação e não sustenta uma alegação adicional de correção.

Fontes