Y a-t-il des raisons de ne pas utiliser BFD?

En cherchant à mettre en œuvre la détection de retransmission bidirectionnelle (BFD), il semble être très flexible en termes de réglage de la minuterie, léger en ce qui concerne les frais généraux et sa flexibilité en termes d'application globale semble très impressionnante.

Donc, si, par exemple, il peut être appliqué pour détecter une défaillance de liaison sur Ethernet, MPLS sur plusieurs sauts, à la périphérie du réseau, pour la convergence IGP, pour les tunnels, etc. - pourquoi ne serait-il pas utilisé dans certains scénarios peut-être et existe-t-il d'autres alternatives émergentes être au courant?

Je ne suis directement conscient que d'un problème avec BFD, qui est la demande de CPU. J'étudie actuellement un problème avec un Cisco 7301 qui, lorsqu'il pousse plus de trafic pendant nos heures de pointe, par rapport au reste de la journée, BFD arrive parfois à expiration et achemine les trajets vers le lien suivant.

Il semble que sous des volumes de trafic élevés, l'utilisation du processeur du routeur augmente (ce qui n'est pas inhabituel), mais à environ 40 à 50%, les paquets BFD du processeur ne reçoivent pas suffisamment de ressources.

Cependant, j'ai trouvé les informations suivantes qui suggèrent des problèmes supplémentaires avec BFD (De cette présentation NANOG, il y a plus dans la présentation, c'est une bonne, lisez-la!)

Quelles sont les mises en garde?

• Deux principaux:
  1. BFD peut avoir des demandes de ressources élevées en fonction de votre échelle.
  2. BFD n'est pas visible pour les protocoles de regroupement de couche 2. (LAG Ethernet ou bundles POS)

Demandes de ressources BFD

• Le nombre de sessions BFD sur chaque linecard ou routeur peut avoir un impact sur la façon dont BFD évolue pour vous. -Chaque plate-forme unique a ses propres limites.
• Des interfaces groupées prenant en charge un minimum de tx / rx de 250 ms ou 2 secondes ont été vues.
• Dans certains cas, les instances BFD sur un routeur peuvent devoir être exploitées sur le processeur de route en fonction de l'implémentation (sessions BFD non adjacentes).
• Testez votre plateforme avant de déployer BFD. Essayez de charger le processeur RP ou LC avec vos paramètres configurés. Cela peut être fait par:
• Exécution de commandes gourmandes en CPU
• Les paquets d'inondation vers TTL expirent sur la destination

Demandes de ressources BFD (suite)

• Quelles valeurs sont sûres d'essayer?
• D'après les conversations avec plusieurs opérateurs, 300 ms avec un multiplicateur de 3 (détection de 900 ms) semble être une valeur sûre qui fonctionne assez bien sur la plupart des équipements.
• Il s'agit d'une amélioration significative par rapport à certaines des alternatives.

Liaison de liaisons BFD et L2

• BFD ne connaît pas les membres sous-jacents du groupe de liaisons L2.
• Un bundle 4x10GigE L2 (802.3ad) apparaîtrait comme une seule contiguïté L3. Les paquets BFD seraient transmis sur une seule liaison membre, plutôt que sur les 4 liaisons.
• Une défaillance de la liaison avec BFD entraînerait l'échec de la contiguïté L3 entière.
• Cependant, dans certains scénarios, la liaison membre défaillante peut entraîner la suppression d'un seul paquet BFD. Les paquets suivants peuvent être acheminés sur les liens des membres actifs.

J'ai vu deux raisons pour lesquelles BFD n'a pas été implémenté:

1. L'ignorance (j'en étais coupable depuis quelque temps).

2. Coût, si vous êtes un magasin Cisco. Bien que cela puisse être négligeable en fonction de la taille de votre organisation, il existe désormais un coût de licence associé pour implémenter BFD.

À partir de la période ISR G2 / ASR, BFD n'est plus dans le package de licence "IP Base". Vous devez mettre à niveau au moins le niveau de licence "Données" pour déverrouiller BFD. Consultez ce livre blanc de Cisco.

Cette exigence de licence n'est peut-être pas un problème, car vous achetez peut-être déjà un niveau de licence plus élevé pour d'autres fonctionnalités, mais il faut en être conscient.

Quelques éléments pour compléter la réponse de Javano:

• N'oubliez pas que l'Ethernet 40g et 100g peut être considéré comme un ensemble, bien qu'il ne soit pas le même que LACP, mais 4x10, 4x25 et 10x10
• Sur certains matériels (certains des Juniper haut de gamme par exemple) BFD est géré sur la carte de ligne qui peut être un avantage (pas de perte sous une charge RE élevée) ou un déficit (pas de perte immédiate si l'ER meurt)
• L'exécution de BFD sur une liaison / un chemin qui est déjà un SPOF (par exemple, un faisceau de fibres simples) peut être pire que de simplement augmenter le retard de porteuse

BFD est une fonctionnalité qui a été inventée pour détecter les problèmes de connectivité L2 lorsqu'il y a un périphérique intermédiaire entre deux pairs. BFD est donc une fonction de détection de panne.

Généralement, nous avons besoin de BFD si nous avons 2 routeurs interconnectés via le commutateur L2 9 ou tout autre cloud L2). Dans ce cas, si un seul routeur tombe en panne, l'état de la liaison ne sera pas reflété sur un autre routeur, car le commutateur maintiendrait la liaison. S'il ne s'agissait que d'une liaison P2P (câble unique) entre les routeurs, l'interface descendrait à droite en cas de panne de l'homologue et l'IGP se reconvergerait en un intervalle d'une seconde.

Donc, le motif pour ne pas utiliser les BFD est: - BFD n'est pas pris en charge sur la boîte [es]; - BFD n'est pas nécessaire, car vous n'avez pas de périphérique intermédiaire (utilisez plutôt udld et carrier-delay).