Pagina Principal ARTIGOS Network SRX Chassis Cluster with Redundant LACP LAG trunk

BFD Detecção de Falhas rápida velocidade de convergência na rede

BFD ==> OSPF

Em ambas as redes  a convergência de aplicações críticas do negócio em uma infra-estrutura IP comum está se tornando mais comum.  Dada a criticidade dos dados, estas redes são normalmente construídas com um alto grau de redundância. Enquanto tal redundância é desejável, a sua eficácia depende da capacidade dos dispositivos de rede individual para rapidamente detectar falhas e redirecionar o tráfego para um caminho alternativo.

Essa detecção é agora normalmente realizada através de mecanismos de detecção de hardware. No entanto, os sinais a partir desses mecanismos nem sempre são encaminhados diretamente  para as camadas superiores do  protocolo. Quando os mecanismos de hardware não existem (Ethernet) ou quando a sinalização não atinge as camadas superiores, os protocolos devem confiar em suas estratégias muito mais lento para detectar falhas. Os tempos de detecção em protocolos existentes são normalmente maiores do que um segundo, e às vezes muito mais tempo. Para algumas aplicações, isso é considerado muito tempo.

O Bi-direcional Detection Forwarding (BFD) oferece tempos de rápida detecção de falha entre os mecanismos de transmissão, mantendo baixo overhead. Ele também fornece um método único e padronizado, link / dispositivo / a detecção de falhas em qualquer camada de protocolo e através de qualquer mídia.

Como funciona
BFD verifica a conectividade entre os dois sistemas. Na primeira fase de desenvolvimento, a Cisco irá apoiar o modo assíncrono BFD, que depende da transmissão de pacotes de controle BFD entre os dois sistemas.

Para entender melhor como BFD é implementada, considerar um exemplo. Imagine dois roteadores, cada um dos quais corre EIGRP, ligados através de um meio comum. Ambos os roteadores sem  nenhuma sessão BFD  estabelecida.

Em cada router, EIGRP informa o processo BFD do endereço IP do vizinho que precisa ser  monitorado. É importante notar que o BFD não descobrir seus pares de forma dinâmica. Ele se baseia em protocolos de roteamento.
O BFD em cada roteador, irá formar um pacote de controle BFD. Estes pacotes são enviados com um mínimo de um segundo  de intervalos,  sessão BFD é estabelecida. Eles podem cruzar na transmissão, embora BFD é concebido para se adaptar a essa condição. Os pacotes iniciais de ambos os lados serão muito semelhantes: Vers, Diag, o H, D, P, F e pedaços serão todos definidos para zero. Meu discriminador será definido para um valor que é único no roteador transmitir; seu discriminador é definido como zero, porque a sessão BFD ainda não foi estabelecida . Os valores do TX e RX temporizadores será definido como os valores encontrados na configuração do dispositivo.
Depois que o roteador recebe um pacote remoto, controle BFD durante a fase de iniciação de sessão, ele irá copiar o valor do “My discriminador” em seu próprio campo “Your discriminador” campo e definir o H (“I Hear You”) bit para qualquer subsequente pacotes de controle BFD ele transmite. Uma vez que ambos os sistemas vêem seus próprios discriminadores em pacotes outro de controle, a sessão é “oficialmente” estabelecida. Os sistemas continuarão a enviar em  intervalos de um segundo até que vejam o discriminadores apropriado em cada  pacotes de controle BFD.
Os valores Discriminador também pode ser usado para multiplex / demultiplex sessões se houver múltiplas conexões BFD entre um par de pares BFD, ou para permitir a mudança de um endereço IP em uma interface BFD sem causar a sessão BFD para ser reposto.

Este valor é fixado em um segundo na primeira fase. Pode ser configurável em fases posteriores. É importante notar também que o projecto de Internet para BFD define dois modos para a iniciação de sessão, Ativo e Passivo. Um nó ativo envia pacotes de controle BFD em um esforço para estabelecer uma sessão BFD. Um nó passivo não envia pacotes BFD até que ela recebe pacotes BFD de um nó ativo. Na primeira fase, os dispositivos Cisco implementação BFD será sempre nós ativos. Embora este exemplo é bom para fins ilustrativos, na verdade é bastante improvável, porque exige quase simultânea de transmissão do pacote inicial BFD por ambos os sistemas. A ocorrência mais provável é que um sistema envia o pacote inicial BFD, eo sistema de recepção responde de volta com o bit “I Hear You”, o “Meu / Seu discriminador” e outros campos relevantes povoadas.

Figura 2. Setup Sessão BFD

Concomitante com a troca de pacotes de controle para estabelecer a sessão BFD, temporizadores BFD também são negociados. A negociação dos temporizadores inicial BFD é um pouco anormal, porque, ao contrário o temporizador posteriores alterações, que ocorre sem a troca de Poll e Final (P e F) bits. Os bits de P e F são usados ​​para garantir que o dispositivo remoto recebeu o pacote solicitando a mudança do temporizador. No entanto, essa troca não é necessária durante a instalação da sessão inicial, como o fato de que o dispositivo remoto alterado o valor de “Your discriminador” e defina o bit H em pacotes subsequentes é suficiente para garantir que ele recebeu os valores temporizador solicitada no momento.
A próxima seção deste documento irá discutir os detalhes da negociação do temporizador.

BFD Negociação Temporizador

O processo de negociação temporizador BFD entre dois dispositivos BFD é um muito simples, e ocorre em algumas etapas. Um dispositivo precisa para garantir três coisas antes que ele possa negociar um temporizador BFD:

• Que o seu dispositivo de mesmo nível viu o pacote contendo o dispositivo proposto timers local

• Que ele nunca envia pacotes de controle BFD mais rápido do que o par está disposto a recebê-los

• Que os pares nunca enviar pacotes de controle BFD mais rápido que o sistema local está disposto a recebê-los

Como mencionado anteriormente, a definição de “discriminador Seu” eo bit H são suficientes para permitir que o dispositivo local para saber se o dispositivo remoto tem visto seus pacotes durante a troca temporizador inicial. Uma vez que estes temporizadores foram negociados, eles podem ser renegociados a qualquer momento durante a sessão, sem causar um reset sessão. Os temporizadores existentes são mantidos durante o período de negociação, e os temporizadores novos não terão efeito até que sejam reconhecer através de um bit Poll e troca bit Final.
O dispositivo que mudou o seu temporizadores irá definir o bit P em todos os pacotes de controle BFD subseqüentes, até que recebe um pacote de controle BFD com o bit F do sistema remoto. Esta troca de guardas bocados contra pacotes que poderiam ser perdidos em trânsito. É extremamente importante notar que a configuração do bit F pelo sistema remoto não significa que ele aceita a nova proposta de temporizadores. Ela apenas indica que o sistema remoto tem visto os pacotes em que os cronômetros foram alteradas.
Como, então, são os temporizadores realmente negociado? Cada sistema, ao receber um pacote de controle BFD vai levar o “Obrigatório Min Interval RX” e compará-lo com seu próprio “Desired Min Interval TX” e levar o maior (mais lento) dos dois valores e usá-lo como a taxa de transmissão para a sua pacotes BFD. Assim, o mais lento dos dois sistemas determina a taxa de transmissão.
Porque esta comparação é realizada de forma independente por um ou outro ponto, é possível ter taxas de transmissão assíncrona sobre o link. Isto é, um peer estará enviando pacotes de controle BFD com mais freqüência em uma direção do que o par está enviando na outra direção.
A Figura 3 ilustra tanto Poll / Final bit de uso e negociação timer:

 

Figura 3. BFD Negociação Temporizador

A Figura 3 representa o “cenário de pior caso” para BFD porque Router A propõe timers radicalmente diferente do que já existem, além disso, ele perde um pacote quando ele sugere a mudança. Aqui está o que ocorre durante este cenário:

• Router A e B Router começar tanto em um estado estável, acordado com temporizadores de 50 ms em ambas as direções

• Router A vontade de mudar sua timers para transmitir e receber em 25ms a 150 ms. Ele envia um pacote de controle BFD com o bit P. Infelizmente, este pacote é perdido em trânsito.

• Router B teriam continuado a enviar pacotes de controle BFD em intervalos de 50 ms durante essa troca. Isto não é ilustrada na Figura 3.

• Depois de outros 50 ms Router, A reenvia o seu pedido para mudar a temporizadores. Mais uma vez, define o Bit Poll. Lembre-se, porque os novos temporizadores não estão em vigor, no entanto, Router A deve continuar a honrar os temporizadores existentes. A retransmissão, assim, ocorre no intervalo de 50ms.

• Router B vê o pacote neste momento, e compara o intervalo de RX solicitou ao seu próprio intervalo de TX. O intervalo solicitado RX é maior, então B Router throttles de volta para o envio de pacotes de controle BFD em intervalos de 150ms.

• Um Router recebe o pacote com o bit F. Os temporizadores são remotas ainda fixado em 50ms e 50ms. Ele compara o intervalo de RX solicitou ao seu próprio intervalo de TX Desejado de 25ms. O intervalo solicitado RX é maior, então Router B continua a enviar em intervalos de 50 ms

• A negociação temporizador está completo: Roteador A envia em intervalos de 50ms, enquanto B Router envia em intervalos de 150ms.

Enquanto a capacidade de negociar timers prevê alguma flexibilidade de configuração, prevê-se que as implementações iniciais BFD vai usar as configurações de temporizador idêntico em pares BFD partilha os mesmos tipos de mídia. Ainda assim, a negociação do temporizador não fornecer alguma proteção contra erros de configuração. Mesmo se um peer define uma absurdamente baixo temporizador TX ou RX, o valor será negociado para cima por um par configurado corretamente.
É importante notar também que, embora os temporizadores foram negociados a valores-os novos valores reais nos pacotes BFD permanecer com as configurações localmente configurado. Por exemplo, embora Router B está transmitindo a 150ms, uma inspeção de pacote Router B de controle BFD iria mostrar a sua desejada Min Interval TX ainda definido como 50ms. Apenas um temporizador interno do dispositivo foi alterado.
Detectar o Multiplicador também é comunicada no BFD pacotes de controle, mas não é negociado, por isso, é possível ter diferentes detectar temporizador valores em ambos os lados da sessão BFD.

Detecção de Falhas BFD

Assim que a sessão BFD e temporizadores apropriadas foram negociados, os pares BFD vai enviar pacotes de controle BFD uns aos outros no intervalo negociado. Como mencionado anteriormente, este assume o modo assíncrono BFD; funções do modo BFD demanda de forma diferente. Esses pacotes de controle funcionam como um batimento cardíaco, muito semelhante a um OLÁ IGP protocolo, excepto a um ritmo mais acelerado.
Enquanto cada peer recebe um pacote BFD BFD controle dentro do período de detectar-temporizador, a sessão continua até BFD e qualquer protocolo de roteamento associados com BFD mantém suas adjacências. Se um par BFD não receber um pacote de controle dentro do intervalo de detectar, informa todos os clientes da sessão BFD (ou seja, qualquer protocolos de roteamento) sobre a falha. Cabe ao protocolo de roteamento para determinar a resposta adequada a essas informações. A resposta típica será terminar a sessão de protocolo de roteamento peering e reconverge, ignorando o peer falhou.
As informações anteriores traz três pontos importantes:

• BFD é uma “vivacidade” protocolo de detecção, mas não em si mesmo, determinar a reação correta de uma falha detectada.

• BFD pode ser utilizado em qualquer camada de protocolo. Poderia, por exemplo, detectar falhas camadas ligação física ou de dados, se os mecanismos existentes não fornecem detecção suficientemente rápida. No entanto, na primeira fase da Cisco suporte BFD, todos os clientes BFD, particularmente a camada 3 protocolos de roteamento (OSPF, IS-IS, EIGRP, BGP e) estão na camada de rede.

• Embora uma única sessão BFD poderia, teoricamente suportam protocolos de múltiplos clientes de monitoramento do mesmo posto, dispositivos Cisco vai usar uma sessão BFD por protocolo cliente na primeira fase de apoio BFD. Em outras palavras, se uma rede está funcionando OSPF e BGP através do mesmo link para o mesmo posto, ele teria duas sessões discretas BFD.

Se um dispositivo BFD não receber um pacote de controle dentro do BFD detectar-timer [(Obrigatório Mínimo Intervalo de RX) * (Multiplicador Detect)], então ele informa seu protocolo cliente que ocorreu uma falha. Cada vez que um BFD com sucesso recebe um pacote de controle BFD BFD em uma sessão, a detectar-temporizador para essa sessão é zerado. Assim, a detecção de falhas é dependente de pacotes recebidos, e é independente de quando o receptor última transmitido um pacote. Esta situação é ilustrada na

 Cenário de falha

 

Na sua BFD próximo controle pacote roteador, um vai definir o campo de diagnóstico para um valor que indica porque a sessão foi retirado. Neste caso, o diagnóstico será de 1: Tempo de Detecção de Controle Expired. Diagnósticos são úteis para diferenciar entre as falhas reais, contra atos administrativos. Por exemplo, se o administrador de rede desativada BFD para esta sessão, o diagnóstico seria 7: Administrativamente Down. Consulte Formatos Packet BFD acima para uma lista de todos os diagnósticos possíveis.

CONFIGURAÇÃO BFD

BFD podem ser configurados em duas etapas.
O primeiro passo para configurar BFD é definir os parâmetros de referência para todas as sessões BFD em uma interface. A configuração ocorre no nível da interface ea sintaxe é a seguinte:
[No] intervalo bfd <50-999> min_rx <1-999> multiplicador <3-50>
intervalo: determina a freqüência (em milissegundos) pacotes BFD será enviada para seus pares BFD.
min_rx: determina a freqüência (em milissegundos) pacotes BFD deverão ser recebidos de seus pares BFD
multiplicador: O número de pacotes consecutivos BFD que deve ser perdida de um peer BFD antes de declarar que o peer
indisponíveis, e informando os protocolos de camada mais alta da falha
Uma vez que os parâmetros de linha de base foram definidos, protocolos individuais devem ser informados de que eles estarão usando BFD para a detecção de falhas.
Na primeira versão do BFD, os protocolos suportados são OSPF, IS-IS, EIGRP e BGP. Este documento centra-se na configuração do
EIGRP.
Há dois métodos diferentes para informar EIGRP que ele deve usar BFD para detecção de falhas. BFD pode ser ativado no roteador sub-mode, se todos os vizinhos EIGRP implementaram BFD, e será universalmente empregado em todas as interfaces:
 
router eigrp 123
bfd todas as interfaces de-
 
Se o usuário não deseja ativar BFD em todas as interfaces, ele pode ser ativado em uma base por interface. Isso, novamente, está habilitado no roteador sub-mode.
 
router eigrp 123
bfd interface de Gig1 / 0

BFD IMPLANTAÇÃO

Alternativas de implantação

Ao implantar qualquer protocolo ou a funcionalidade IP, é necessário considerar todas as alternativas, e estar ciente de qualquer trade-offs estão sendo feitas. A alternativa mais próxima para BFD em implantações convencionais EIGRP é o uso de Olá modificado e mantenha temporizadores. Definindo EIGRP Olá e temporizadores para realizar seus mínimos absolutos, o protocolo EIGRP para reduzir o seu mecanismo de detecção de falha para dentro da faixa de 1-2 segundos.
 
Existem várias vantagens para BFD sobre o mecanismo temporizador reduzida:

 

• Porque BFD não está vinculado a qualquer protocolo de roteamento particular, ele pode me usado como um mecanismo genérico e consistente falha de detecção de OSPF, IS-IS, EIGRP e BGP.

• Porque algumas partes do BFD podem ser distribuídos para o plano de dados, pode ser menos CPU do que timers reduzido, o que existe em todo o plano de controle.

• Redução de timers EIGRP ter um contador de detecção mínimo absoluto de 1-2 segundos; BFD pode fornecer sub-segundo detecção de falhas.

BFD também compartilha algumas ressalvas comum com reduzida timers EIGRP:

• BFD pode potencialmente gerar alarmes de sinalização falsa uma falha de link quando um não existe. Porque os temporizadores utilizados para BFD são tão apertadas, um breve intervalo de corrupção de dados ou de congestionamento fila poderia causar BFD perder pacotes de controle suficiente para permitir a detecção de temporizador expirar. Enquanto a transmissão de pacotes de controle BFD é gerido, dando-lhes a prioridade fila de mais alta possível, pouco pode ser feito sobre priorizar pacotes de controle de entrada BFD.

• BFD vai consumir alguns recursos da CPU, embora muitas otimizações foram feitas para garantir o uso da CPU é mínima. Sobre a não-distribuídos plataformas, in-house testes mostraram um aumento de CPU menor de 2% (acima de linha de base) no apoio a cem sessões simultâneas BFD *. Em plataformas distribuídas, não há impacto sobre a CPU principal rota do processador, exceto durante a instalação da sessão BFD e desmontagem. É importante notar que, por causa dessa movimentação acelerada de pacotes de controle BFD, todos os recursos de saída são ignorados. Os usuários não podem, por exemplo, filtrar ou aplicar Quality of Service (QoS) para pacotes transmitidos BFD.

BFD usando como parte de um plano de redundância da rede

BFD pode ser uma parte importante de um plano global de redundância de rede, incluindo outras inovações como a Cisco Nonstop Forwarding (NSF) e da Hot Standby Router Protocol (HSRP). BFD deve ser implantado naqueles troços da rede, onde a detecção de falhas subsecond é necessária, mas não pode ser fornecida pelos tradicionais mecanismos de Layer 2.

Figura 5. BFD implantação em um ambiente misto L2/L3

Mesmo que haja um caminho alternativo disponível entre roteadores A e F, uma falha no roteador E vai ser escondido de seus vizinhos (Routers C, D e F) pela presença dos switches Layer 2. Os switches Layer 2 manter a conectividade para os roteadores vizinhos, o que faz com que cair para trás sobre como usar o timers na camada de protocolo OLÁ 3 a detectar a falha. No temporizador EIGRP padrão, isso pode levar até 15 segundos.
Em contraste, se Routers C, D, E e F foram todos BFD em execução, todos os vizinhos Router E poderia detectar falhas E Router em menos de um segundo, e começar imediatamente o reconvergence para o A-> B-> D-> F caminho.
Embora BFD pode ser usado em outros cenários de implantação, a exemplo switch L2 é um dos mais comuns e difíceis de resolver sem BFD.
É interessante notar que EIGRP pode proporcionar convergência quase instantânea através da utilização de rotas sucessor viável, que são essencialmente rotas pré-computadas backup. No entanto, isso resolve um problema diferente do de detecção de falhas iniciais fornecidas pelo BFD. Assim, enquanto EIGRP é o mais rápido convergente de todos os protocolos IGP, BFD ainda fornece um valor significativo.

Implantação Notes BFD

• Embora possa ser auto-evidente, deve-se afirmar que BFD fornece sua principal vantagem em dual-homed ambiente. Uma vez que uma falha é detectada pela BFD, o tráfego precisa de um caminho alternativo ao longo do qual ele pode fluir. Embora não haja nenhuma restrição contra o uso de BFD em um ambiente isoladamente-homed, os benefícios são poucos. É, no entanto, alerta o administrador de rede mais rapidamente para um problema que requer intervenção manual.

• Como uma camada adicional de proteção ou, o administrador de rede deve considerar a execução BFD em conjunto com Cisco IP evento

Se falhas de ligação são causados ​​por uma flutuação intermitente na camada física iniciada por uma fibra sujo, conector solto, GBIC mal-comportados, ou alguma outra causa, BFD fielmente detectar todas essas falhas. No entanto, ele não pode distinguir que um determinado link foi saltando para cima e para baixo. Cisco IP amortecimento evento foi destinado a mitigar precisamente este problema.

• Embora alguns protocolos como HSRP e Multicast não estão atualmente BFD-enabled, que podem obter algum benefício incremental de implantação BFD. Porque estes protocolos dependem do IGP subjacente para determinar suas reações ao fracasso, a capacidade de BFD para ajudar o IGP convergem mais rapidamente benefícios todos os protocolos de camada superior.

• Alguns cuidados devem ser usados ​​quando se utiliza BFD em conjunto com outras estratégias de alta disponibilidade. Cisco NSF, por exemplo, pode fornecer failover quase instantâneo entre um ativo e um Processador Route de espera no caso de encaminhamento de plano de controle. No entanto, dependendo da plataforma, pode haver o suficiente de uma queda de tráfego durante a transição para causar BFD prematuramente um sinal de falha no link.

• Dual-anel SONET usando Automatic Protection Switching (APS) é outro cenário de implantação, onde BFD podem ser inadequados. SONET com APS já deve fornecer proteção transição ~ 50ms, e BFD não deve ser exigida. A mesma regra deve aplicar-se Spatial Reutilização Protocol (SRP) links-ou transporte de pacotes dinâmicos (DPT) ou Anel Packet resilientes (RPR).

• Embora todos os tipos de interface apoiado na primeira fase da Cisco suporte BFD são de alta velocidade, alguns cuidados devem ser tomados uma vez BFD torna-se mais geralmente disponíveis em outras plataformas com menor velocidade links. Em particular, o Desejado Interval TX e RX Obrigatório Min Interval deve ser ajustado para valores apropriados para o tipo de link. Enquanto um batimento cardíaco 50ms será quase imperceptível em um link de 10 Gbps, ele terá um efeito mais significativo em um link de 64Kbps. Executar um PING para o ponto remoto BFD vai estimar o ajuste do temporizador correta. Os temporizadores deve ser definida para, pelo menos, tempo de resposta da medida, apesar de várias ordens de magnitude valor maior seria preferível.

BFD RESOLUÇÃO DE PROBLEMAS

A Cisco implementação BFD oferece uma grande variedade de ferramentas para determinar o status de peerings BFD, bem como para a depuração do protocolo BFD si.

Status do BFD e depuração

Os seguintes comandos são implementados para ajudar a solucionar BFD:
mostram vizinhos bfd [detalhes]
O comando show vizinhos bfd fornece uma lista linha por linha-de existir adjacências BFD. Se a opção de palavra-chave detalhes está incluído, a saída também irá mostrar parâmetros de protocolo BFD e temporizadores por vizinho.

Figura 6. Vizinhos sh detalhes bfd

As informações contidas na Figura 6 pode ser interpretado inspecionando os campos na seção Formatos BFD Packet deste documento.
pacote bfd debug [endereço vizinho]
O comando debug de pacotes bfd imprime informações sobre os pacotes de depuração BFD enviados e recebidos. O [endereço vizinho] opcional é usado para filtrar a saída com base no endereço IP do próximo. BFD Porque é projetado para enviar e receber pacotes a uma taxa muito alta, alguns cuidados devem ser usados ​​antes de ativar este comando, especialmente se houver um grande número de pares BFD. Ele só deve ser habilitado em uma rede ao vivo sob a direção do Cisco Technical Assistance Center pessoal.

Figura 7. Output Debugging BFD

A Figura 7 mostra a configuração inicial de uma sessão BFD. Como mencionado anteriormente, timers inicial estão definidos para um segundo até que a sessão é inicializado. Então a mudança temporizadores aos seus valores configurados localmente, neste caso, 50
 
milissegundos *.
evento bfd debug
Esse comando imprime informações de depuração sobre transições de estado BFD. Há quatro principais estados para uma sessão de BFD:

• Init: o estado inicial de uma sessão BFD. No BFD packets have yet been received from the peer of the session.

• Up: a BFD Control packet with the “I Hear You” (IHY) bit set to 1 has been received.

• Failing: a transitional state from the UP state. Either the detection timer is in the process of expiring, or a BFD Control packet with the “I Hear You” bit set to 0 has been received.

• Down: a BFD Control packet with the “I Hear You” bit set to 0 has been received.

As an example of state transition, if a BFD session is in the UP state, and the peer begins sending BFD packets with IHY=0, the state transition is as follows:
UP->FAILING->DOWN->INIT
 
* Remember that timers are configured in milliseconds, but their values are transmitted in BFD packets as microseconds. Thus, 50 milliseconds equates to 50,000 microseconds. This explains why we see 50000 as the tx and rx timers.
The following figure shows the transition when OSPF is cleared then restarted:

Figure 8. Debugging BFD Events

OSPF BFD Status and Debugging

As mentioned previously, BFD is only useful if it is associated with a specific upper layer protocol, and can quickly inform that protocol about changes in Layer 2 state. Therefore, a necessary part of troubleshooting BFD is being able to monitor the interaction between BFD and the upper layer protocol. In the case of OSPF, several extensions to existing commands have been implemented.
show ip ospf interface will now show if an interface is enabled for BFD.

Figure 9. show ip ospf interface

show ip ospf will also include a change to indicate if BFD had been enabled at the router-wide level:

Figure 10. show ip ospf

show ip ospf neighbor detail has been enhanced to display if a particular neighbor is being monitored by BFD:

Figure 11. debug isis adj-packets

debug ip ospf adjacency will incorporate some additional output to show when OSPF registers or de-registers with BFD.

Figure 12. debug ip ospf adjacency

Finally, if log-adjacency-changes is enabled in the OSPF router process, there will be a log message with a unique “BFD node down” string to signify that the neighbor has gone down due to a BFD notification.

CONCLUSÃ
Detecção Forwarding bidirecional fornece um método para administradores de rede para configurar camada de detecção de falhas  entre 2 os nós de rede adjacentes. Além disso, podem configurar os seus protocolos de roteamento para responder às notificações BFD, e começar a Camada de convergência em L3  quase que imediatamente.
BFD pode ser uma ferramenta poderosa e uma parte importante de um plano de disponibilidade da rede como um todo

 Fonte: https://rodbezerra.wordpress.com/2012/01/31/ospf-deteccao-de-falhas-rapida-velocidade-de-convergencia-na-rede/

.