BFD (Bidirectional Forwarding Detection — RFC 5880) est un protocole de détection de panne ultra-rapide. Il permet aux protocoles de routage (OSPF, BGP, EIGRP, IS-IS) de détecter la perte d'un voisin en millisecondes, là où les timers natifs prennent plusieurs secondes voire minutes.
Le problème que BFD résout
Sans BFD, la détection d'une panne dépend des timers du protocole de routage :
| Protocole | Timer de détection natif | Avec BFD |
|---|
| OSPF | Dead interval : 40s (défaut) | ~1s ou moins |
| EIGRP | Hold timer : 15s (défaut) | ~1s ou moins |
| BGP | Hold timer : 90s (défaut) | ~1s ou moins |
| IS-IS | Hold timer : 30s (défaut) | ~1s ou moins |
| Static route | Jamais (pas de détection) | ✅ Détection possible |
Comment BFD fonctionne
BFD établit une session indépendante entre deux peers et envoie des petits paquets de contrôle à intervalles réguliers. Si un certain nombre de paquets consécutifs ne sont pas reçus, la session est déclarée DOWN et le protocole de routage associé est immédiatement notifié.
Routeur A
BFD session
⇆
Paquets BFD
toutes les X ms
⇆
Routeur B
BFD session
Lien tombe
→
BFD session DOWN
après multiplier paquets perdus
→
Notification
protocole routage
→
Convergence
immédiate
Architecture : Control Plane vs Data Plane
BFD peut fonctionner dans deux plans selon la plateforme :
| Mode | Plan | Performance | Disponibilité |
|---|
| Software BFD |
Control Plane (CPU) |
Timers ~300ms minimum en pratique |
Toutes plateformes |
| Hardware BFD |
Data Plane (ASIC) |
Timers ~10ms possibles |
Plateformes haut de gamme (ASR, NCS…) |
Le hardware BFD survit même à un crash du control plane (NSF/SSO). Le software BFD s'arrête si le CPU est surchargé.
Cas d'usage typiques
| Scénario | Intérêt BFD |
|---|
| Lien point-à-point entre routeurs | Détection panne physique en <1s |
| BGP eBGP avec transit provider | Failover rapide sans attendre hold timer 90s |
| Route statique vers next-hop | Tracking du next-hop — retire la route si down |
| MPLS LDP / RSVP | Détection rapide pour re-signaling LSP |
| Lien agrégé (LAG/port-channel) | Détection micro-BFD par membre du bundle |
BFD a peu de prérequis mais ils sont stricts — notamment CEF qui est obligatoire sur toutes les plateformes IOS.
🚨 CEF obligatoire — prérequis absolu
BFD utilise le plan de forwarding (CEF) pour envoyer et recevoir ses paquets de contrôle rapidement. Sans CEF actif, BFD refuse de s'établir. C'est le prérequis le plus souvent oublié.
! Vérifier que CEF est actif
show ip cef
show ip cef summary
! Activer si nécessaire
ip cef ! IPv4
ipv6 cef ! IPv6
Résumé des prérequis
| Prérequis | Obligatoire ? | Notes |
|---|
| CEF | ✅ Oui | Absolument requis — BFD ne fonctionne pas sans |
| Adjacence L3 existante | ✅ Oui | BFD surveille — il ne crée pas la session routing |
| Support IOS | ✅ Oui | IOS 12.4(11)T+ / IOS-XE 3.x+ |
| Même subnet | ✅ Oui (single-hop) | Pour BFD multi-hop : peut traverser des routeurs |
| UDP 3784/3785 ouvert | ✅ Oui | Paquets BFD — ne pas les filtrer avec ACL |
| Support hardware | ⚠️ Optionnel | Requis uniquement pour hardware BFD offloaded |
Ports UDP utilisés par BFD
| Port | Usage |
|---|
| UDP 3784 | BFD Control packets (single-hop et multi-hop) |
| UDP 3785 | BFD Echo packets |
| UDP 4784 | BFD multi-hop (RFC 5883) |
⚠️ ACL sur interfaces
Si des ACL filtrent le trafic UDP sur l'interface, s'assurer que les ports 3784/3785 sont autorisés dans les deux sens. Une ACL bloquant BFD provoque des sessions qui ne s'établissent pas — sans message d'erreur clair.
BFD single-hop vs multi-hop
| Single-hop (RFC 5881) | Multi-hop (RFC 5883) |
|---|
| Scope | Voisins directement connectés | Peers séparés par plusieurs sauts |
| Utilisé pour | OSPF, EIGRP, IS-IS, interfaces | BGP eBGP multi-hop, routes statiques distantes |
| TTL | 255 (vérifié à la réception) | Pas de vérification TTL stricte |
| Config IOS | bfd interval sur interface | ip route static bfd ou neighbor fall-over bfd multi-hop |
Les timers BFD définissent la vitesse de détection. Ils sont négociés entre les deux peers — c'est toujours le plus lent des deux qui s'impose.
Les 3 paramètres timer
interface GigabitEthernet0/0
bfd interval 300 min_rx 300 multiplier 3
! ^tx(ms) ^rx(ms) ^paquets manqués
| Paramètre | Rôle | Valeur défaut | Range |
|---|
interval |
Intervalle d'envoi des paquets BFD (Desired Min TX) |
— |
50ms – 999ms |
min_rx |
Intervalle minimum de réception acceptable (Required Min RX) |
— |
50ms – 999ms |
multiplier |
Nombre de paquets manqués consécutifs → session DOWN |
— |
3 – 50 |
Négociation des timers entre les deux peers
Chaque peer annonce son Desired Min TX et son Required Min RX. Le timer effectif est :
Timer TX effectif :
MAX(Desired Min TX local, Required Min RX remote)
! Exemple de négociation :
! Routeur A : interval 200 min_rx 100
! Routeur B : interval 150 min_rx 300
!
! TX de A vers B = MAX(200, 300) = 300ms ← min_rx de B impose
! TX de B vers A = MAX(150, 100) = 150ms ← Desired de B
!
! Detection time A = 300ms × multiplier(A) = 300 × 3 = 900ms
! Detection time B = 150ms × multiplier(B) = 150 × 3 = 450ms
Calcul du temps de détection
Detection Time :
Timer TX effectif × Multiplier
| Config | Timer effectif | Multiplier | Detection time |
|---|
interval 300 min_rx 300 multiplier 3 | 300ms | 3 | 900ms |
interval 100 min_rx 100 multiplier 3 | 100ms | 3 | 300ms |
interval 50 min_rx 50 multiplier 3 | 50ms | 3 | 150ms |
interval 300 min_rx 300 multiplier 5 | 300ms | 5 | 1500ms |
Recommandations pratiques
| Contexte | Config recommandée | Detection time |
|---|
| LAN Gigabit (production) | interval 300 min_rx 300 multiplier 3 | 900ms |
| WAN / liens lents | interval 500 min_rx 500 multiplier 3 | 1500ms |
| Environnement stable (DC) | interval 100 min_rx 100 multiplier 3 | 300ms |
| Liens instables / jitter | Augmenter multiplier à 5 | Évite les flaps |
⚠️ Timers trop agressifs = CPU overload
Des timers <100ms en software BFD génèrent beaucoup de trafic CPU. Sur des routeurs avec nombreuses sessions BFD (core/aggregation), descendre sous 300ms doit être testé en lab. En hardware BFD, 50ms est courant.
BFD supporte trois modes de fonctionnement. Le mode asynchrone est le plus utilisé. Le mode echo est le plus efficace pour tester le chemin de forwarding. Le mode demand est rare.
Mode Asynchrone (défaut)
Les deux peers envoient des paquets BFD Control périodiquement. Si l'un ne reçoit plus les paquets de l'autre au-delà du detection time, il déclare la session DOWN.
R1 envoie
BFD Control
→
R2
→
R2 envoie
BFD Control
→
R1
Actif par défautPas de config spéciale
TraficBidirectionnel permanent
DétectePanne dans les deux sens
Mode Echo
Un seul peer envoie des paquets BFD Echo qui reviennent via le plan de forwarding du peer distant (sans remonter au CPU). Cela teste le chemin de forwarding réel — pas seulement le control plane.
R1 envoie
BFD Echo
→
R2 forwarde
(data plane)
→
R1 reçoit
son propre paquet
! Activer le mode echo sur l'interface
interface GigabitEthernet0/0
bfd echo
! Ou désactiver le echo si non souhaité
no ip bfd echo ! global
AvantageTeste le data plane réel
CPU R2Non impliqué (forwarding uniquement)
TimersPeuvent être plus agressifs
⚠️ Echo et interfaces point-à-point
Le mode echo peut poser problème sur les liens point-à-point si le routeur distant a no ip redirects ou si le TTL est décrémenté. Vérifier que les paquets echo reviennent bien avec show bfd neighbors detail.
Mode Demand
Les paquets périodiques sont supprimés une fois la session établie. Des paquets Poll/Final sont envoyés à la demande pour vérifier l'état. Très peu utilisé en pratique.
Rare en production
Réduit le trafic BFD
Détection moins réactive
Récapitulatif des modes
| Mode | Trafic périodique | Plan testé | Usage |
|---|
| Asynchrone | Oui, les deux sens | Control plane | ✅ Standard — le plus utilisé |
| Echo | Oui, un seul sens | Data plane | ✅ Recommandé sur hardware |
| Demand | Non (poll/final uniquement) | Control plane | ⚠️ Rare |
La configuration BFD se fait en deux étapes : activer BFD sur l'interface avec les timers, puis lier BFD au protocole de routage. Sans la deuxième étape, BFD s'établit mais ne notifie rien.
Étape 1 — Activation sur l'interface
! Obligatoire sur chaque interface où BFD est souhaité
interface GigabitEthernet0/0
bfd interval 300 min_rx 300 multiplier 3
! Vérifier que la session s'établit
show bfd neighbors
Sans protocole liéSession BFD UP mais protocole non notifié
SensConfig requise sur les deux peers
Étape 2 — Liaison au protocole de routage
─── OSPF ───────────────────────────────────────
router ospf 1
bfd all-interfaces ! toutes les interfaces OSPF
! Ou par interface :
interface GigabitEthernet0/0
ip ospf bfd ! cette interface uniquement
! Désactiver sur une interface spécifique (si bfd all-interfaces actif)
interface GigabitEthernet0/1
ip ospf bfd disable
─── EIGRP (Classic mode) ───────────────────────
router eigrp 100
bfd all-interfaces
! Ou par interface :
bfd interface GigabitEthernet0/0
─── EIGRP (Named mode) ─────────────────────────
router eigrp CAMPUS
address-family ipv4 unicast autonomous-system 100
af-interface GigabitEthernet0/0
bfd
─── BGP ────────────────────────────────────────
router bgp 65001
neighbor 10.0.0.1 fall-over bfd
─── IS-IS ──────────────────────────────────────
router isis
bfd all-interfaces
─── Route statique ─────────────────────────────
ip route static bfd GigabitEthernet0/0 10.0.0.1
ip route 0.0.0.0 0.0.0.0 10.0.0.1 ! route utilisant ce bfd
Configuration complète — exemple OSPF
! ── Routeur A ──────────────────────────────────
ip cef ! prérequis
interface GigabitEthernet0/0
ip address 10.0.0.1 255.255.255.0
bfd interval 300 min_rx 300 multiplier 3
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
bfd all-interfaces
! ── Routeur B ──────────────────────────────────
ip cef
interface GigabitEthernet0/0
ip address 10.0.0.2 255.255.255.0
bfd interval 300 min_rx 300 multiplier 3
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
bfd all-interfaces
! Résultat : si le lien tombe → OSPF converge en ~900ms
BFD multi-hop — BGP eBGP
! Pour BGP eBGP multi-hop (peers non directement connectés)
router bgp 65001
neighbor 203.0.113.1 remote-as 65002
neighbor 203.0.113.1 ebgp-multihop 2
neighbor 203.0.113.1 fall-over bfd multi-hop
! Configurer BFD multi-hop (template)
bfd-template multi-hop MULTI-HOP-PEER
interval min-tx 300 min-rx 300 multiplier 3
bfd map ipv4 203.0.113.1/32 MULTI-HOP-PEER
Chaque protocole de routage interagit différemment avec BFD. Voici les spécificités, comportements et commandes pour chacun.
OSPF + BFD
BFD remplace le mécanisme de détection basé sur le Dead Interval. Quand BFD déclare la session DOWN, OSPF retire immédiatement le voisin sans attendre le Dead Interval (40s par défaut).
router ospf 1
bfd all-interfaces ! activation globale
! Par interface (granularité fine)
interface Gi0/0
ip ospf bfd
interface Gi0/1
ip ospf bfd disable ! exclure cette interface
! Vérification
show ip ospf neighbor ! colonne BFD state
show bfd neighbors
Dead Interval ignoré si BFD DOWN
Convergence <1s possible
Fonctionne avec OSPFv3 aussi
EIGRP + BFD
BFD remplace le Hold Timer EIGRP (15s par défaut). L'adjacence est immédiatement retirée dès que BFD déclare la session DOWN.
! Classic mode
router eigrp 100
bfd all-interfaces
! ou sélectif :
bfd interface GigabitEthernet0/0
! Named mode (préféré)
router eigrp CAMPUS
address-family ipv4 unicast autonomous-system 100
af-interface default
bfd ! toutes les interfaces
af-interface GigabitEthernet0/1
no bfd ! exclure cette interface
! Vérification
show ip eigrp neighbors
show bfd neighbors
BGP + BFD
BGP utilise fall-over bfd par voisin. C'est particulièrement utile pour les sessions eBGP où le hold timer de 90s est inacceptable pour la production.
router bgp 65001
! eBGP single-hop
neighbor 10.0.0.1 remote-as 65002
neighbor 10.0.0.1 fall-over bfd
! eBGP multi-hop
neighbor 203.0.113.1 remote-as 65003
neighbor 203.0.113.1 ebgp-multihop 3
neighbor 203.0.113.1 fall-over bfd multi-hop
! iBGP (même AS)
neighbor 10.1.1.1 remote-as 65001
neighbor 10.1.1.1 fall-over bfd
! Vérification
show ip bgp neighbors 10.0.0.1 | include BFD
⚠️ BGP fall-over et route flap
Avec fall-over bfd, si la session BFD flap (instabilité lien), la session BGP tombe aussi. Sur des liens instables, augmenter le multiplier BFD ou utiliser le BGP Graceful Restart pour limiter l'impact.
IS-IS + BFD
router isis
bfd all-interfaces
! Par interface
interface GigabitEthernet0/0
isis bfd
! Désactiver sur une interface
interface GigabitEthernet0/1
isis bfd disable
! Vérification
show isis neighbors
show bfd neighbors
Route statique + BFD
BFD peut tracker la disponibilité d'un next-hop et retirer automatiquement une route statique si le next-hop devient injoignable — sans protocole de routage dynamique.
! Déclarer le tracking BFD pour le next-hop
ip route static bfd GigabitEthernet0/0 10.0.0.1
! Routes statiques utilisant ce next-hop
ip route 0.0.0.0 0.0.0.0 10.0.0.1
ip route 192.168.100.0 255.255.255.0 10.0.0.1
! Si BFD déclare 10.0.0.1 DOWN → les routes statiques sont retirées
! Si BFD revient UP → les routes sont réinstallées
! Vérification
show ip route static
show bfd neighbors
Pas besoin de protocole dynamique
Idéal pour default route avec SLA
Nécessite interface config BFD aussi
La vérification BFD se fait en deux niveaux : l'état des sessions BFD elles-mêmes, et la confirmation que les protocoles de routage utilisent bien BFD.
Commandes de base
! Vue d'ensemble de toutes les sessions BFD
show bfd neighbors
! Exemple de sortie :
! Neighbor Address LD/RD RH Holdown(mult) State Int
! 10.0.0.2 1/1 Up 869(3) Up Gi0/0
!
! LD = Local Discriminator
! RD = Remote Discriminator
! RH = Remote Heard (Up/Down)
! Holdown = timer restant avant détection
! Détail d'une session
show bfd neighbors detail
! Filtrer par interface
show bfd neighbors interface GigabitEthernet0/0
! Filtrer par voisin
show bfd neighbors 10.0.0.2 detail
Lecture de "show bfd neighbors detail"
OurAddress: 10.0.0.1
NeighAddr: 10.0.0.2
LD/RD: 1/1 ← discriminators (identifiants session)
State: Up ← état de la session
SessionType: SW ← SW=software, HW=hardware
Registered protocols: OSPF ← protocoles qui utilisent cette session
Uptime: 00:15:32
Last packet: Version:1 ← infos du dernier paquet reçu
Diag: No Diagnostic
I Hear You bit: 1 ← 1 = voisin a reçu nos paquets
Demand bit: 0
Poll bit: 0
Final bit: 0
Multiplier: 3
Length: 24
My Discr.: 1
Your Discr.: 1
Min tx interval: 300000 ← en microsecondes = 300ms
Min rx interval: 300000
Demand mode: 0
Tx interval: 300ms, Rx interval: 300ms
Registered protocols: OSPF
Vérification par protocole
! OSPF — vérifier BFD dans les neighbors
show ip ospf neighbor detail | include BFD
! EIGRP
show ip eigrp neighbors detail | include BFD
! BGP
show ip bgp neighbors 10.0.0.1 | include BFD
show ip bgp neighbors 10.0.0.1 | include fall.over
! IS-IS
show isis neighbors detail | include BFD
! Route statique
show ip route static bfd
Statistiques et debug
! Compteurs de paquets BFD
show bfd neighbors statistics
! Debug BFD (prudence — verbeux)
debug bfd event
debug bfd packet
debug bfd all
! Désactiver
undebug all
! Logs syslog lors d'un changement d'état :
! %BFD-6-BFD_SESS_CREATED: BFD session to neighbor 10.0.0.2 on interface Gi0/0 created
! %BFD-5-BFD_SESS_DOWN: BFD session to neighbor 10.0.0.2 on interface Gi0/0 is DOWN
! %BFD-6-BFD_SESS_UP: BFD session to neighbor 10.0.0.2 on interface Gi0/0 is UP
Checklist de diagnostic rapide
| # | Vérification | Commande |
|---|
| 1 | CEF actif ? | show ip cef summary |
| 2 | Session BFD établie ? | show bfd neighbors |
| 3 | Protocole enregistré dans BFD ? | show bfd neighbors detail → "Registered protocols" |
| 4 | Timers négociés correctement ? | show bfd neighbors detail → Tx/Rx interval |
| 5 | ACL bloque les paquets BFD ? | Vérifier UDP 3784/3785 sur l'interface |
| 6 | Config présente sur les deux peers ? | show run int Gi0/0 sur les deux routeurs |
Les pièges BFD sont souvent subtils — la session peut s'établir sans pour autant être utile si le protocole n'est pas correctement lié.
🚨 Piège #1 — CEF désactivé = BFD ne s'établit pas
Sans ip cef, BFD refuse silencieusement de fonctionner. Aucun message d'erreur explicite. La session reste à l'état DOWN indéfiniment. Toujours vérifier CEF en premier.
! Symptôme : show bfd neighbors = vide ou session toujours DOWN
! Diagnostic :
show ip cef summary
! Si CEF disabled → ip cef → relancer BFD
🚨 Piège #2 — Interface config sans liaison protocole
Configurer bfd interval sur l'interface et voir la session UP dans show bfd neighbors ne suffit pas. Si le protocole de routage n'est pas lié (bfd all-interfaces sous OSPF par exemple), BFD ne notifie rien en cas de panne.
! Vérifier que le protocole est bien enregistré
show bfd neighbors detail
! → "Registered protocols: OSPF" doit apparaître
! → Si "Registered protocols: (none)" → protocole non lié
⚠️ Piège #3 — Config asymétrique (un seul peer)
BFD doit être configuré sur les deux routeurs. Si un seul a bfd interval sur l'interface, la session ne s'établit pas. Le peer distant doit aussi avoir la config BFD.
⚠️ Piège #4 — Timers trop agressifs = flapping
Des timers très bas (50ms × 3 = 150ms) sur des liens avec jitter peuvent provoquer des flaps BFD → flaps protocoles de routage → instabilité réseau. Toujours tester en lab avant de déployer des timers <300ms.
! Sur un lien instable, augmenter le multiplier
interface GigabitEthernet0/0
bfd interval 300 min_rx 300 multiplier 5
! Detection time = 1500ms — moins sensible aux micro-interruptions
⚠️ Piège #5 — ACL bloquant UDP 3784
Une ACL sur l'interface bloquant le trafic UDP 3784/3785 empêche les paquets BFD de passer. La session ne s'établit pas et aucun message d'erreur clair n'est généré. Toujours vérifier les ACL en entrée et en sortie.
! Vérifier les ACL actives sur l'interface
show ip interface GigabitEthernet0/0 | include access list
show ip access-lists NOM_ACL
! S'assurer que UDP 3784 est permis
ip access-list extended ALLOW-BFD
permit udp any any eq 3784
permit udp any any eq 3785
⚠️ Piège #6 — BFD et NSF/SSO
Lors d'un switchover SSO sur des plateformes avec RP redondant, les sessions BFD software tombent puis se re-établissent. Cela peut déclencher des reconvergences inutiles. Utiliser BFD Graceful Restart (RFC 5882) ou du hardware BFD offloaded pour survivre au switchover.
! BFD Graceful Restart (OSPF)
router ospf 1
nsf ! NSF actif
bfd all-interfaces
⚠️ Piège #7 — BFD multi-hop et TTL
Pour BFD multi-hop, le TTL du paquet doit être assez élevé pour traverser les sauts intermédiaires. Par défaut, certaines implémentations utilisent TTL=255 et vérifient à la réception. S'assurer que le TTL n'est pas décrémenté sur le chemin.
Arbre de dépannage BFD
| Symptôme | Cause probable | Action |
|---|
| Session BFD jamais UP | CEF désactivé, ACL, config asymétrique | show ip cef + vérifier les deux peers |
| Session UP mais protocole ne converge pas | Protocole non lié à BFD | show bfd neighbors detail → Registered protocols |
| Sessions BFD flap fréquemment | Timers trop agressifs, jitter lien | Augmenter multiplier ou interval |
| BFD UP mais pas dans show ospf neighbor | BFD non activé sous OSPF | Ajouter bfd all-interfaces sous router ospf |
| Session DOWN après SSO | Software BFD ne survit pas au switchover | Activer NSF/Graceful Restart |
Cliquez sur une carte pour révéler la réponse.
Quel est le prérequis absolu pour que BFD fonctionne sur IOS ?
CEF (ip cef) doit être activé. Sans CEF, BFD ne s'établit pas.
cliquer pour révéler
Que signifient les 3 paramètres de bfd interval 300 min_rx 300 multiplier 3 ?
interval = envoi toutes les 300ms. min_rx = accepte des paquets espacés de 300ms max. multiplier = 3 paquets manqués → session DOWN.
cliquer pour révéler
Comment est calculé le detection time BFD ?
Detection time = Timer TX effectif × Multiplier. Le timer TX effectif = MAX(Desired Min TX local, Required Min RX remote).
cliquer pour révéler
Quelle est la différence entre BFD asynchrone et BFD echo ?
Asynchrone : les deux peers envoient des paquets (control plane). Echo : un peer envoie des paquets qui reviennent via le data plane du peer distant.
cliquer pour révéler
Quelle commande lie BFD à OSPF pour toutes les interfaces ?
Sous router ospf : bfd all-interfaces
cliquer pour révéler
Quelle commande lie BFD à BGP pour un voisin spécifique ?
neighbor X.X.X.X fall-over bfd sous router bgp.
cliquer pour révéler
Comment vérifier que le protocole de routage est bien enregistré dans BFD ?
show bfd neighbors detail → chercher "Registered protocols: OSPF/EIGRP/BGP".
cliquer pour révéler
Quels ports UDP utilise BFD ?
UDP 3784 (control packets), UDP 3785 (echo packets), UDP 4784 (multi-hop).
cliquer pour révéler
Quel est le detection time avec interval 300 min_rx 300 multiplier 3 ?
300ms × 3 = 900ms — moins d'une seconde pour détecter une panne.
cliquer pour révéler
Comment utiliser BFD pour retirer une route statique si le next-hop tombe ?
ip route static bfd GigabitEthernet0/0 10.0.0.1 + configurer bfd interval sur l'interface.
cliquer pour révéler
Pourquoi une session BFD peut-elle flapper fréquemment ?
Timers trop agressifs sur un lien avec jitter. Solution : augmenter le multiplier (ex: 5) ou l'interval.
cliquer pour révéler
Quelle est la différence entre BFD single-hop et multi-hop ?
Single-hop : voisins directement connectés (TTL=255 vérifié). Multi-hop : peers séparés par plusieurs sauts, utilisé pour BGP multi-hop.
cliquer pour révéler
Comment exclure une interface spécifique du BFD OSPF global ?
Sur l'interface : ip ospf bfd disable
cliquer pour révéler
Que se passe-t-il lors d'un SSO avec du software BFD ?
Les sessions BFD software tombent pendant le switchover. Utiliser BFD Graceful Restart (NSF) ou hardware BFD pour survivre au basculement.
cliquer pour révéler