Tutti i moderni protocolli di routing, come ad esempio OSPF, IS-IS e BGP, includono un qualche meccanismo per rilevare la perdita di una adiacenza o sessione (OSPF e IS-IS hanno i messaggi HELLO utilizzati per stabilire le adiacenze, il BGP ha i messaggi KEEPALIVE). Tutti questi meccanismi funzionano allo stesso modo, a fronte della mancata ricezione di un certo numero di HELLO/KEEPALIVE, l'adiacenza/sessione viene chiusa.
Il problema principale con questi meccanismi è che possono essere lenti (soprattutto con i timer di default). I timer potrebbero essere variati su base configurazione riducendoli fino a valori molto bassi, ma questo comporterebbe un elevato carico sulla CPU a causa dell’elevata frequenza dei messaggi HELLO o KEEPALIVE. Inoltre, il tuning dei timer andrebbe fatto per protocollo, aumentando così le variabili di configurazione.
Il problema principale con questi meccanismi è che possono essere lenti (soprattutto con i timer di default). I timer potrebbero essere variati su base configurazione riducendoli fino a valori molto bassi, ma questo comporterebbe un elevato carico sulla CPU a causa dell’elevata frequenza dei messaggi HELLO o KEEPALIVE. Inoltre, il tuning dei timer andrebbe fatto per protocollo, aumentando così le variabili di configurazione.
Il BFD è un protocollo standard, inizialmente proposto da Juniper e quindi sviluppato in IETF (RFC 5880 - Bidirectional Forwarding Detection (BFD), Giugno 2010), che consente una rapida rilevazione di fuori servizio di collegamenti e/o percorsi in modo indipendente dal protocollo di routing e dai Livelli 1 o 2.
Come riportato dalla RFC 5880, il BFD ha un unico preciso compito:
"provide low-overhead, short-duration detection of failures in the path between adjacent forwarding engines, including the interfaces, data link(s), and, to the extent possible, the forwarding engines themselves".
Quando è conveniente utilizzare il BFD ? Lo scenario tipico è quello di un collegamento costituito da più segmenti, come ad esempio PVC Frame Relay/ATM o VLAN Ethernet. Non ha senso utilizzare il BFD con collegamenti back-to-back, perché con collegamenti di questo tipo, entrambe le interfacce agli estremi rilevano lo stato down, e lo comunicano immediatamente al processo di routing.
I PVC Frame Relay e ATM hanno in realtà una funzionalità di keepalive che consente di rilevare la caduta dei PVC, ma il tempo di rilevamento del fuori servizio è tipicamente alto, dell'ordine dei secondi.
Le implementazioni attuali dei maggiori costruttori, come ad esempio Cisco e Juniper, supportano il BFD sia per IPv4 che IPv6, e a supporto di tutti i maggiori protocolli di routing (Routing statico, OSPFv2/v3, IS-IS, BGP, PIM), dei più importanti protocolli di High Availability come HSRP, VRRP, Graceful Restart, e di meccanismi di tunneling come GRE, LSP MPLS-TE, Pseudowire, ecc. .
Benché ormai consolidato, il BFD è abbastanza poco utilizzato, e peggio ancora, sconosciuto ai più. Per questo in passato ho scritto un paio di post sull'argomento, per contribuire alla sua conoscenza e metterne in luce le proprietà e soprattutto gli scenari di applicazione. Successivamente ho raccolto il contenuto dei due post, con qualche aggiunta (autenticazione dei messaggi BFD, configurazioni del BFD per IS-IS e BGP, BFD over LAG), in un unico documento, che potete scaricare qui.
Può esservi utile per la vostra biblioteca tecnica.
Buona lettura !!!
Nessun commento:
Posta un commento