Supongamos que se tiene un escenario como el de la figura con OSPF corriendo como protocolo de ruteo en la LAN.


En caso que uno de los routers pierda su conexión al switch, ¿Cuánto demorará el proceso de OSPF en los otros routers en declarar que ha perdido la vecindad?. Bueno, si se consideran los tiempos por defecto en links broadcast serían alrededor de 40 segundos, es decir el RouterDeadInterval que a su vez es equivalente al envío de cuatro hellos (HelloInterval de diez segundos) sin la correspondiente respuesta (estos valores para otros protocolos IGP son claramente enunciados en: Hello timer behaviors). Hoy en día este tiempo de convergencia puede ser perjudicial para redes de alta disponibilidad.

Una mejora para el caso de OSPF puede ser el uso de Fast Hellos, lo que es fácilmente configurable como se ve a continuación.

R1(config)#interface FastEthernet 0/0
R1(config-if)#ip ospf dead-interval ?
<1-65535>  Seconds
minimal    Set to 1 second

R1(config-if)#ip ospf dead-interval minimal ?
hello-multiplier  Set multiplier for Hellos

R1(config-if)#ip ospf dead-interval minimal hello-multiplier ?
<3-20>  Number of Hellos sent within 1 second

R1(config-if)#

Básicamente se configura el RouterDeadInterval a un mínimo de 1 segundo y el número de hellos dentro de ese intervalo. Pero, ¿cómo se configura esto para el resto de IGP's y BGP?... Bueno, para eso existe BFD (Bidirectional Forwarding Detection), cuyo desarrollo está en progreso y se trata en los siguientes documentos:

• Bidirectional Forwarding Detection, draft-ietf-bfd-base-09.txt
• BFD for IPv4 and IPv6 (Single Hop), draft-ietf-bfd-v4v6-1hop-10.txt
• Generic Application of BFD, draft-ietf-bfd-generic-05.txt

Cisco se refiere al respecto en BFD y BFD for OSPF. Sin embargo para quienes estén interesados en comprender cómo funciona este protocolo, se recomienda encarecidamente leer la explicación que provee NIL en este link.

Para entender su aplicación se verá su interacción con BGP. En primera instancia se evaluarán el tiempo que demora en notar R1 que su que perdió su vecindad BGP con R4 al poner en shutdown la interface que los conecta en este último router.

R4(config-if)#int f0/1
R4(config-if)#shut
R4(config-if)#
Nov  2 21:18:36.285: %OSPF-5-ADJCHG: Process 64512, Nbr 192.168.0.193 on FastEthernet0/1 from FULL to DOWN, Neighbor Down:

Interface down or detached
Nov  2 21:18:38.281: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down
Nov  2 21:18:39.281: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
R4(config-if)#
R4(config-if)#
Nov  2 21:21:01.173: %BGP-5-ADJCHANGE: neighbor 192.168.0.17 Down BGP Notification sent
Nov  2 21:21:01.173: %BGP-3-NOTIFICATION: sent to neighbor 192.168.0.17 4/0 (hold time expired) 0 bytes
R4(config-if)#

R1(config-if)#
R1(config-if)#
Nov  2 21:18:37.282: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
Nov  2 21:18:37.282: %OSPF-5-ADJCHG: Process 64512, Nbr 192.168.0.205 on FastEthernet0/0 from FULL to DOWN, Neighbor Down:

Interface down or detached
R1(config-if)#
Nov  2 21:21:00.516: %BGP-5-ADJCHANGE: neighbor 192.168.0.18 Down BGP Notification sent
Nov  2 21:21:00.516: %BGP-3-NOTIFICATION: sent to neighbor 192.168.0.18 4/0 (hold time expired) 0 bytes
R1(config-if)#
R1(config-if)#

En palabras sencilla pasaron casi tres minutos desde que el link que une a ambos equipos fuera desconectado para que BGP diera de baja la sesión entre éstos, lo que va acorde a lo esperado considerando que el Hold Timer por defecto de 180 segundos en routers Cisco como se señala en Adjusting BGP Timers. Se puede ver que en este caso OSPF da de baja la vecindad instantáneamente debido a que se trata de un enlace point-to-point, es decir en ambos extremos se ve el link abajo (más bien sin un switch entremedio). A continuación se configura BFD y se analizará cómo mejoran los tiempos.

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#int f0/1
R4(config-if)#bfd interval 50 min_rx 50 multiplier 3
R4(config-if)#
R4(config-if)#router bgp 64512
R4(config-router)#nei 192.168.0.17 fall-over bfd
R4(config-router)#

R1#
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int f0/0
R1(config-if)#bfd interval 50 min_rx 50 multiplier 3
R1(config-if)#
R1(config-if)#router bgp 64512
R1(config-router)#neighbor 192.168.0.18 fall-over bfd
R1(config-router)#

Nada muy complicado, sólo notar los diferentes parámetros:

• interval (ms): Cada cuanto tiempo se envían los paquetes de control BFD
• min_rx (ms): Cada cuanto tiempo se espera recibir los paquetes de control BFD
• multiplier: Número de mensajes que deben ser perdidos para declarar que el vecino no está disponible

Con show bfd neighbors y show bfd neighbors details se puede ver información respecto de los vecinos monitoreados, etc.

R1#sh bfd nei

OurAddr       NeighAddr     LD/RD  RH/RS   Holdown(mult)  State     Int
192.168.0.17  192.168.0.18   2/1    Up        0    (3 )   Up        Fa0/0
R1#
R1#

R1#sh bfd nei det

OurAddr       NeighAddr     LD/RD  RH/RS   Holdown(mult)  State     Int
192.168.0.17  192.168.0.18   3/2    Up        0    (3 )   Up        Fa0/0
Session state is UP and using echo function with 50 ms interval.
Local Diag: 0, Demand mode: 0, Poll bit: 0
MinTxInt: 1000000, MinRxInt: 1000000, Multiplier: 3
Received MinRxInt: 1000000, Received Multiplier: 3
Holdown (hits): 3000(0), Hello (hits): 1000(1023)
Rx Count: 1025, Rx Interval (ms) min/max/avg: 756/1012/883 last: 76 ms ago
Tx Count: 1024, Tx Interval (ms) min/max/avg: 756/64512/882 last: 708 ms ago
Registered protocols: BGP
Uptime: 00:15:02
Last packet: Version: 1            - Diagnostic: 0
      State bit: Up         - Demand bit: 0
      Poll bit: 0           - Final bit: 0
      Multiplier: 3         - Length: 24
      My Discr.: 2          - Your Discr.: 3
      Min tx interval: 1000000    - Min rx interval: 1000000
      Min Echo interval: 50000
R1#

Hora de evaluar qué es lo que se gana con esto.

R4#
R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#int f0/1
R4(config-if)#shut
R4(config-if)#
Nov  2 22:46:47.507: %OSPF-5-ADJCHG: Process 64512, Nbr 192.168.0.193 on FastEthernet0/1 from 2WAY to DOWN, Neighbor Down:

Interface down or detached
Nov  2 22:46:48.507: %BGP-5-ADJCHANGE: neighbor 192.168.0.17 Down BFD adjacency down
Nov  2 22:46:49.503: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down
Nov  2 22:46:50.503: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
R4(config-if)#

R1#
Nov  2 22:46:48.506: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
Nov  2 22:46:48.506: %OSPF-5-ADJCHG: Process 64512, Nbr 192.168.0.205 on FastEthernet0/0 from 2WAY to DOWN, Neighbor Down:

Interface down or detached
Nov  2 22:46:48.510: %BGP-5-ADJCHANGE: neighbor 192.168.0.18 Down BFD adjacency down
R1#

En otras palabras se disminuye el tiempo de espera de cerca de tres minutos a menos de un segundo ;) ....Además BFD puede ser usado por cualquier protocolo de ruteo (OSPF, BGP, etc.)

Un par de consideraciones respecto a este protocolo (BFD) serían que aún no está implementado para interfaces seriales y que para BGP no soporta aún sesiones multi-hop.