Ci sono dei motivi per non usare BFD?

Nel cercare di implementare il Bidirectional Forwarding Detection (BFD) sembra essere molto flessibile in termini di messa a punto del timer, leggerezza rispetto a qualsiasi overhead e la sua flessibilità in termini di applicazione complessiva appare molto impressionante.

Quindi, se ad esempio può essere applicato per rilevare errori di collegamento su Ethernet, MPLS su più hop, ai margini della rete, per la convergenza IGP, per tunnel ecc. Ecc. Perché forse non dovrebbe essere utilizzato in determinati scenari e ci sono altre alternative emergenti essere a conoscenza?

Sono a conoscenza direttamente di un problema con BFD, ovvero la richiesta della CPU. Attualmente sto studiando un problema con un Cisco 7301 che, quando spinge più traffico durante le ore di punta, rispetto al resto della giornata, BFD a volte sta scadendo e indirizzando i viaggi verso il collegamento successivo.

Sembra che con volumi di traffico elevati l'utilizzo della CPU del router sia in aumento (il che non è insolito) ma a circa il 40-50% i pacchetti CPU BFD non ricevono risorse sufficienti.

Tuttavia ho trovato le seguenti informazioni che suggeriscono ulteriori problemi con BFD (da questa presentazione NANOG, ce n'è di più nella presentazione, è buona, dacci una lettura!)

Quali sono le avvertenze?

• Due principali:
  1. BFD può richiedere elevate risorse a seconda della scala.
  2. BFD non è visibile ai protocolli di raggruppamento di livello 2. (GAL Ethernet o bundle POS)

Richieste di risorse BFD

• Il numero di sessioni BFD su ogni linecard o router può influire sulla capacità di BFD di adattarsi. -Ogni piattaforma unica ha i suoi limiti.
• Sono state osservate interfacce in bundle che supportano min tx / rx di 250 ms o 2 secondi.
• In alcuni casi, a seconda dell'implementazione, è possibile che le istanze BFD su un router debbano essere gestite sul route-processor.
• Testa la tua piattaforma prima di distribuire BFD. Tentare di caricare la CPU RP o LC con le impostazioni configurate. Questo può essere fatto da:
• Esecuzione di comandi pesanti per la CPU
• I pacchetti di allagamento in TTL scadono alla destinazione

Richieste di risorse BFD (seguito)

• Quali valori sono sicuri da provare?
• In base al parlare con diversi operatori, 300 ms con un moltiplicatore di 3 (rilevamento di 900 ms) sembrano essere un valore sicuro che funziona abbastanza bene sulla maggior parte delle apparecchiature.
• Questo è un miglioramento significativo rispetto ad alcune delle alternative.

BFD e L2 link-bundling

• BFD non è a conoscenza dei membri del bundle di link L2 sottostanti.
• Un bundle L2 4x10GigE (802.3ad) apparirebbe come una singola adiacenza L3. I pacchetti BFD verrebbero trasmessi su un collegamento a membro singolo, anziché su tutti e 4 i collegamenti.
• Un errore del collegamento con BFD su di esso comporterebbe il fallimento dell'intera adiacenza L3.
• Tuttavia, in alcuni scenari il collegamento del membro non riuscito può comportare l'eliminazione di un solo pacchetto BFD. I pacchetti successivi possono instradare sui collegamenti dei membri attivi.

Ho visto due motivi per cui BFD non è stato implementato:

1. Ignoranza di ciò (ero colpevole di questo per qualche tempo).

2. Costo, se sei un negozio Cisco. Sebbene possibilmente trascurabile a seconda delle dimensioni della tua organizzazione, ora c'è un costo di licenza associato per implementare BFD.

A partire dall'intervallo ISR G2 / ASR, BFD non è più nel pacchetto di licenze "IP Base". Devi aggiornare almeno al livello di licenza "Dati" per sbloccare BFD. Vedi questo white paper di Cisco.

Questo requisito di licenza potrebbe non essere un problema, poiché potresti già acquistare un livello di licenza più elevato per altre funzionalità, ma è qualcosa di cui devi essere consapevole.

Alcune cose per completare la risposta di javano:

• Ricorda che ethernet 40g e 100g possono essere considerati bundle, anche se non uguali a LACP, ma 4x10, 4x25 e 10x10
• Su alcuni hardware (alcuni dei Juniper di fascia più alta, ad esempio), la BFD viene gestita sulla scheda di linea che può essere un vantaggio (nessuna perdita con un elevato carico di RE) o un deficit (nessuna perdita immediata se la RE muore)
• L'esecuzione di BFD su un collegamento / percorso che è già uno SPOF (ad esempio un singolo bundle in fibra) può essere peggio del semplice ritardo del vettore

BFD è una funzione inventata per rilevare il problema di connettività L2 quando è presente un dispositivo intermedio tra due peer. Quindi BFD è una funzionalità di rilevamento guasti.

In genere abbiamo bisogno di BFD se abbiamo 2 router collegati tramite lo switch L2 9 o qualsiasi altro cloud L2). In questo caso, se un singolo router si arresta, lo stato del collegamento non si rifletterà su un altro router, poiché lo switch manterrebbe il collegamento attivo. Se fosse solo un collegamento P2P (cavo singolo) tra i router, l'interfaccia andrebbe giù in caso di errore del peer e IGP si riconvertirebbe in un intervallo inferiore al secondo.

Pertanto, il motivo per non utilizzare i BFD è: - BFD non è supportato sulla casella [es]; - BFD non è necessario, poiché non si dispone di un dispositivo intermedio (utilizzare invece udld e carrier-delay).