Bidirectional Forwarding Detection - Wikipedia, the free encyclopedia
vendredi 7 août 2015 à 17:36GuiGui's Show - Liens
Intéressant : un protocole qui floode (10 ms entre chaque "keepalive" par défaut avec BIRD) un ou plusieurs liens pour détecter rapidement une panne sur le lien (au sens logique, pas physique, multihop tout ça) entre deux routeurs, beaucoup plus rapidemment que les procotocoles de routage : OSPF = environ 40 secondes ; BGP = 180 secondes.
On utilise BFD en le raccrochant à un protocole de routage (BGP, OSPF,...). L'idée est de converger plus rapidement en cas de panne. Pourquoi ne pas réduire aggresivement les timers des protocoles de routage au lieu d'utiliser un nouveau protocole ?
* Car tous les protocoles de routage ne peuvent pas avoir des timers aussi aggresifs que ce que permet BFD. Exemple : l'hold timer minimal en BGP est de 20 secondes ;
* Séparation protocole de routage du protocole de vérification de la connectivité. Pas les mêmes objectifs, pas le même protocole, chacun son taff (ne faire qu'une chose mais le faire bien, tout ça, tout ça). Généricité. Le prochain protocole de routage n'aura pas à réimplémenter la détection d'erreur sur la connexion ;
* BFD fonctionne partout où y'a de l'IP, même sur des protocoles qui n'ont pas la notion de détection de fail de la connectivité (Ethernet, MPLS, circuits virtuels,...) ;
* Protocole léger, avec un état minimaliste et une charge utile légère contrairement aux protocoles de routage. La réduction des timers OSPF/BGP/autre nécessite de mettre en branle tout l'algo (sauf le recalcule des routes) comme maintenir les états... « The detection of network failures consumes most of the convergence time budget in typical designs » Russ White and Mosaddaq Turabi (both CCIE, CCDE and CCAr).
Pas de découverte automatique des voisins (OSPFv3 does), il faut config chaque routeur a la main.
Plusieurs modes sont disponibles :
* asynchrone (chaque pair envoi un message BFD Control à interval régulier, le lien est déclaré mort au bout d'un délai sans avoir rien reçu (500 ms sous BIRD par défaut)) ;
* On demand (on établie la session puis on envoie seulement quand on veut s'assurer que le pair est en vie) ;
* En complément de ces deux modes (ce n'est pas un mode supplémentaire !), on a le mode echo qui permet de vérifier que le routeur d'en face est apte à faire du transfert de paquets (ça détecte des cas de pannes en plus, quoi) en vérifiant sa capacité à nous retourner le paquet qu'on lui envoie.
Pour le protocole et les ports : UDP/3784 (BFD control) et UDP/3785 (BFD echo) dans le mode connexion directe, UDP/4784 (BFD control) et UDP/4785 (BFD echo) pour le mode multihop.
BIRD dispose d'une implémentation partielle de ce protocole (http://bird.network.cz/?get_doc&f=bird-6.html#ss6.1)
Côté configuration :
protocol bfd bfd_test {
neighbor 198.18.0.2 local 198.18.0.1;
Côté CLI :
bfd_test BFD master up 16:04:28
Preference: 0
Input filter: ACCEPT
Output filter: REJECT
Routes: 0 imported, 0 exported, 0 preferred
Route change stats: received rejected filtered ignored accepted
Import updates: 0 0 0 0 0
Import withdraws: 0 0 --- 0 0
Export updates: 0 0 0 --- 0
Export withdraws: 0 --- --- --- 0
=> Oui, la CLI est vraiment pauvre en détails... Notamment, elle indique toujours « up » même quand ce n'est pas le cas... Still in dev, tout ça. ;)
Coté réseau (tshark) :
BFD Control message
001. .... = Protocol Version: 1
...0 0000 = Diagnostic Code: No Diagnostic (0x00)
11.. .... = Session State: Up (0x03)
Message Flags: 0x00
0... .. = Poll: Not set
.0.. .. = Final: Not set
..0. .. = Control Plane Independent: Not set
...0 .. = Authentication Present: Not set
.... 0. = Demand: Not set
.... .0 = Multipoint: Not set
Detect Time Multiplier: 5 (= 500 ms Detection time)
Message Length: 24 bytes
My Discriminator: 0x1305f4bb
Your Discriminator: 0x063847cd
Desired Min TX Interval: 100 ms (100000 us)
Required Min RX Interval: 10 ms (10000 us)
Required Min Echo Interval: 0 ms (0 us)
J'ai dit plus haut que BFD s'utilise en lien avec un protocole de routage. Faisons ça :
protocol bfd bfd_test {
# options spécifiques
}
protocol bgp bgp_test {
bfd yes;
}
Quand le lien tombe, de manière quasi instantanée (< 1 seconde) :
bgp_test BGP master start 16:11:21 Idle Error: BFD session down
La remontée BGP est beaucoup plus longue, même si BFD revient très vite (en quelques secondes), puisqu'il faut attendre l'expiration de l'error_wait (240 secondes par défaut) sur les deux routeurs.
S'il s'agit d'un lien iBGP direct, ne pas oublier la directive de configuration « direct » de BIRD pour le lui indiquer sinon il enverra des paquets BFD Control multihop (et ça marche hein mais c'pas propre).
(Permalink)
Intéressant : un protocole qui floode (10 ms entre chaque "keepalive" par défaut avec BIRD) un ou plusieurs liens pour détecter rapidement une panne sur le lien (au sens logique, pas physique, multihop tout ça) entre deux routeurs, beaucoup plus rapidemment que les procotocoles de routage : OSPF = environ 40 secondes ; BGP = 180 secondes.
On utilise BFD en le raccrochant à un protocole de routage (BGP, OSPF,...). L'idée est de converger plus rapidement en cas de panne. Pourquoi ne pas réduire aggresivement les timers des protocoles de routage au lieu d'utiliser un nouveau protocole ?
* Car tous les protocoles de routage ne peuvent pas avoir des timers aussi aggresifs que ce que permet BFD. Exemple : l'hold timer minimal en BGP est de 20 secondes ;
* Séparation protocole de routage du protocole de vérification de la connectivité. Pas les mêmes objectifs, pas le même protocole, chacun son taff (ne faire qu'une chose mais le faire bien, tout ça, tout ça). Généricité. Le prochain protocole de routage n'aura pas à réimplémenter la détection d'erreur sur la connexion ;
* BFD fonctionne partout où y'a de l'IP, même sur des protocoles qui n'ont pas la notion de détection de fail de la connectivité (Ethernet, MPLS, circuits virtuels,...) ;
* Protocole léger, avec un état minimaliste et une charge utile légère contrairement aux protocoles de routage. La réduction des timers OSPF/BGP/autre nécessite de mettre en branle tout l'algo (sauf le recalcule des routes) comme maintenir les états... « The detection of network failures consumes most of the convergence time budget in typical designs » Russ White and Mosaddaq Turabi (both CCIE, CCDE and CCAr).
Pas de découverte automatique des voisins (OSPFv3 does), il faut config chaque routeur a la main.
Plusieurs modes sont disponibles :
* asynchrone (chaque pair envoi un message BFD Control à interval régulier, le lien est déclaré mort au bout d'un délai sans avoir rien reçu (500 ms sous BIRD par défaut)) ;
* On demand (on établie la session puis on envoie seulement quand on veut s'assurer que le pair est en vie) ;
* En complément de ces deux modes (ce n'est pas un mode supplémentaire !), on a le mode echo qui permet de vérifier que le routeur d'en face est apte à faire du transfert de paquets (ça détecte des cas de pannes en plus, quoi) en vérifiant sa capacité à nous retourner le paquet qu'on lui envoie.
Pour le protocole et les ports : UDP/3784 (BFD control) et UDP/3785 (BFD echo) dans le mode connexion directe, UDP/4784 (BFD control) et UDP/4785 (BFD echo) pour le mode multihop.
BIRD dispose d'une implémentation partielle de ce protocole (http://bird.network.cz/?get_doc&f=bird-6.html#ss6.1)
Côté configuration :
protocol bfd bfd_test {
neighbor 198.18.0.2 local 198.18.0.1;
Côté CLI :
bfd_test BFD master up 16:04:28
Preference: 0
Input filter: ACCEPT
Output filter: REJECT
Routes: 0 imported, 0 exported, 0 preferred
Route change stats: received rejected filtered ignored accepted
Import updates: 0 0 0 0 0
Import withdraws: 0 0 --- 0 0
Export updates: 0 0 0 --- 0
Export withdraws: 0 --- --- --- 0
=> Oui, la CLI est vraiment pauvre en détails... Notamment, elle indique toujours « up » même quand ce n'est pas le cas... Still in dev, tout ça. ;)
Coté réseau (tshark) :
BFD Control message
001. .... = Protocol Version: 1
...0 0000 = Diagnostic Code: No Diagnostic (0x00)
11.. .... = Session State: Up (0x03)
Message Flags: 0x00
0... .. = Poll: Not set
.0.. .. = Final: Not set
..0. .. = Control Plane Independent: Not set
...0 .. = Authentication Present: Not set
.... 0. = Demand: Not set
.... .0 = Multipoint: Not set
Detect Time Multiplier: 5 (= 500 ms Detection time)
Message Length: 24 bytes
My Discriminator: 0x1305f4bb
Your Discriminator: 0x063847cd
Desired Min TX Interval: 100 ms (100000 us)
Required Min RX Interval: 10 ms (10000 us)
Required Min Echo Interval: 0 ms (0 us)
J'ai dit plus haut que BFD s'utilise en lien avec un protocole de routage. Faisons ça :
protocol bfd bfd_test {
# options spécifiques
}
protocol bgp bgp_test {
bfd yes;
}
Quand le lien tombe, de manière quasi instantanée (< 1 seconde) :
bgp_test BGP master start 16:11:21 Idle Error: BFD session down
La remontée BGP est beaucoup plus longue, même si BFD revient très vite (en quelques secondes), puisqu'il faut attendre l'expiration de l'error_wait (240 secondes par défaut) sur les deux routeurs.
S'il s'agit d'un lien iBGP direct, ne pas oublier la directive de configuration « direct » de BIRD pour le lui indiquer sinon il enverra des paquets BFD Control multihop (et ça marche hein mais c'pas propre).
(Permalink)