Quel Underlay pour ma Fabric Leaf & Spine ? (partie 2)

Dans le premier article de cette série consacrée au choix du protocole de routage de la couche Underlay de la Fabric VxLAN/EVPN, nous avons analysé les protocoles traditionnels pour l’IGP à savoir EIGRP, OSPF et IS-IS.

Dans cet article, nous allons nous intéresser à l’utilisation du protocole BGP en Underlay, cela peut surprendre certains d’entre vous mais il y a bien une RFC qui décrit l’utilisation du BGP (uniquement eBGP) en remplacement de l’IGP pour les architectures MSDC (Massively Scalable Data Centers) : (RFC 7938 : Use of BGP for Routing in Large-Scale Data Centers), d’ailleurs certains constructeurs privilégient ce choix pour la conception de l’Underlay de leur Fabric.

Le premier avantage cité pour ce design est une simplification protocolaire de l’architecture : un seul protocole BGP pour gérer l’Underlay et l’Overlay de la Fabric ! personnellement je pense que c’est plutôt un inconvénient de mettre tous les oeufs dans un seul panier : on oublie aussi de citer que c’est plusieurs familles d’adresses (AFI/SAFI) du protocole BGP qu’il faut activer avec une configuration et exploitation très spécifique, il faut activer (IPv4 ou IPv6) pour l’Underlay,  (VRF IPv4/IPv6, EVPN) pour l’Overlay, et des fois même VPNv4/VPNv6 sur les équipements de bordure (Border Leaf) pour leur permettre la sortie sur un réseau MPLS (sortie WAN).

Le domaine d’impact devient aussi plus important car on se retrouve dans une situation de « Fate-sharing » d’utilisation du protocole BGP, si ce dernier présente des perturbations ou un crash, accrochez-vous ! Les couches Underlay et Overlay seront impactées simultanément.

Nous utiliserons le même exercice indiqué dans l’article 1 : Conception d’une Fabric VxlAN/EVPN constituée de 200 Leafs et 4 Spines :

Rappelons les besoins Underlay :

• Chaque Spine implémente une seule interface de type loopback (lo1)
• Chaque Leaf implémente deux interfaces de type loopback (lo1 et lo2)
• Lo1 permet l’établissement du protocole de plan de contrôle BGP EVPN de la Fabric (control plane)
• Lo2 permet de réalisation les opérations de plan de données (NVE) avec l’encapsulation VxLAN (data plane)
• Le protocole de routage de l’Underlay doit assurer à tout moment la disponibilité de ces interfaces loopback.

iBGP

Commençons d’abord par le cas d’utilisation iBGP en routage Underlay de la Fabric IPv4 comme indiqué dans le diagramme ci-dessous :

Sessions :

En iBGP, il faut établir des sessions BGP entre tous les Leafs/Spines, pour une Fabric constituée de 200 Leafs et 4 Spines, la bonne pratique consiste à définir des routes reflector (RR) (ou confédérations) pour limiter le nombre de sessions, concentrons-nous pour le moment sur une architecture avec RR :

Pour ce type d’architecture, la fonction RR est généralement (intuitivement aussi) portée par les équipements de type Spine (exemple : S2 et S3 dans le diagramme ci-dessus), chaque Leaf établit deux sessions iBGP avec les RR :

• Pour 2 RR, 400 sessions iBGP sont nécessaires
  • Pour 4 RR, 800 sessions iBGP sont nécessaires
• Chaque Leaf annonce dans ce cas en BGP IPv4 ses interfaces Lo1 (EVPN Control Plane) et Lo2 (NVE VxLAN Data Plane) qui vont permettre de construire dans un second temps le réseau Overlay.

Configuration :

En terme de configuration iBGP avec RR :

• Leafs : Les relations d’adjacences iBGP sont identiques sur tous les Leafs (vers les RR) et sont définis manuellement dans la configuration, cependant chaque Leaf doit annoncer ses propres loopback (lo1 et lo2).
• Spines : il faut déclarer une à une toutes les relations d’adjacences BGP avec les 200 Leafs, l’utilisation des templates « peer-group » permet de réduire considérablement les lignes de configuration à exécuter, cependant, la déclaration du voisin BGP reste statique contrairement au protocoles Link State (OSPF et IS-IS) qui permet l’auto découverte et établissement automatique des adjacences entre voisins.

=> Certains constructeurs proposent aussi la fonctionnalité « Dynamic neighbors » qui consiste à mettre le démon (daemon) bgp en mode « écoute passive» afin d’établir dynamiquement les sessions en provenance des clients, cette fonctionnalité peut être très utile sur les RR car elle réduit considérablement les lignes de configuration à exécuter, elle doit cependant être sécurisée (acl, password, max sessions) pour éviter des sessions indésirables ou déni de service.

=> A noter que les Drafts (BGP LLDP Peer Discovery, BGP Neighbor Discovery) traitent le point de découverte automatiques de voisins, soit par l’utilisation du protocole LLDP ou alors en multicast port UDP 179 (comme en IGP), la deuxième méthode nécessite cependant de revoir le code BGP et changer la fonction « BGP Hello ».

=> Certains constructeurs comme « Cumulus Network » utilisent la suite logicielle de routage réseau « FRRouting » qui permet de fournir des optimisations avancées en BGP et de simplifier drastiquement la configuration BGP par :

• La découverte automatique d’un voisin sur un segment /30 ou /31.
  • La découverte automatique du numéro d’AS voisin par l’utilisation des mots clés « internal » pour iBGP et « external » pour eBGP dans la configuration, l’AS BGP voisin est extrait à partir du message Hello d’initiation de la session BGP

Contrainte 1 : le nombre de sessions iBGP est important et hormis certains constructeurs (ex Cumulus Network), plusieurs lignes de configurations sont souvent nécessaires à déployer sur les équipements (surtout RR) pour établir une à une les relations d’adjacences iBGP.

Accessibilité du nexthop :

Ah ce nexthop qui nous rend fou en iBGP !! Par défaut, le RR ne modifie pas le next-hop dans les annonces de routes entre voisins iBGP : le Leaf L1 recevra bien les annonces de routes iBGP en provenance des autres Leafs mais il ne pourra pas les installer dans la RIB/FIB parce que le nexthop de ces routes (l’autre Leaf) n’est pas joignable !

Pour faire simple et en français cette fois-ci : pour joindre ce chemin tu dois passer par moi, mais tu dois d’abord savoir comment venir chez moi 🙂

Pour y remédier, il y a deux options :

• Configurer les RR (Spines) en nexthop dans les annonces de routes entre les Leafs (nexthop-self) : cette option va à l’encontre de la recommandation de la RFC 4456 : « In addition, when a RR reflects a route, it SHOULD NOT modify the following path attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED. Their modification could potentially result in routing loops »
• Configurer tous les Spines (RR) pour annoncer tous les liens qu’ils connectent (bgp redistribute connected) afin de permettre aux Leafs d’accéder aux des autres Leafs en recursive lookup.

Contrainte 2 : Configurations spécifiques (des fois non recommandées) à réaliser sur le protocole BGP ou annonce des réseaux de transit dans la table BGP afin de permettre l’accessibilité des nexthop sur les Leafs.

ECMP :

Par défaut, BGP n’annonce et n’installe que le meilleur chemin (BGP Path Selection), pour permettre l’utilisation de tous vos liens (40G/100G) et équipements de la Fabric, il faut activer la fonctionnalité iBGP Multipath (ECMP).

Cette fonctionnalité est aussi nécessaire dans le cas d’implémentation de solutions Multi-Chassis (MCLAG, VPC, autres ..) sur les Leafs, en effet, le fonctionnement de ces solutions consiste à annoncer une adresse virtuelle (Anycast VTEP) simultanément sur les deux équipements et qui doit être ensuite accessible en ECMP.

Contrainte 3 : BGP n’implémente pas nativement l’ECMP contrairement à l’OSPF/IS-IS, il faut l’activer manuellement dans les déclarations iBGP.

Design :

Dans le cas d’implémentation de deux RR (exemple S2 et S3), les Spines S1 et S4 doivent aussi être connectés sur les RR, sinon vous allez avoir de jolies boites très performantes dans votre réseau mais qui ne servirons à rien, elle ne verront jamais un flux de production !!

Plusieurs solutions sont possibles pour corriger ce problème :

• Raccorder physiquement ces Spines avec les RR Spines : c’est très moche et cela va à l’encontre du principe de CLOS Fabric (aucun lien physique entre les Spines), aussi en cas d’ajout de nouveau Spine il faudra penser à le raccorder aussi physiquement aux RRs, cette solution n’est pas valable.
• Permettre par des routes statiques (à travers les Leafs) aux Spines (S1 et S4) de joindre les RR (S2 et S3) afin d’établir la session iBGP : c’est malin !! mais cela veut dire en d’autre termes avoir un autre IGP (routage statique) dans l’architecture autre que BGP, or l’objectif initial était d’avoir uniquement BGP en IGP, ce choix n’est donc pas valable ni évolutif aussi.
• Implémenter la fonctionnalité RR sur tous les Spines comme indiqué dans le diagramme ci-dessous :

• Dans ce cas, les Spines forment un cluster de RR, mais attention, généralement on commence petit puis on grandit ! N’est-ce pas ? Si la Fabric démarre initialement avec deux Spines et qu’on souhaite en rajouter deux autres plus tard, il faut revoir la configuration de tous les Leafs pour déclarer ces nouveaux Spines en RR, sauf si dès le départ, ils sont présents dans le configuration mais non utilisés, dans ce cas, l’exploitant ne doit pas paniquer s’il constate des sessions BGP Idle pendant un long moment.
• Si tous Spines sont RR, on augmente aussi le nombre de lignes de configurations à déployer sur les équipements ainsi que les échanges du plan de contrôle du BGP : chaque LEAF recevra inutilement la même copie du BGP Update en provenance de l’ensemble des Spines.
• L’automatisation permet cependant de faciliter l’addition de deux nouveaux Spines dans la Fabric.

Haute Disponibilité :

Étudions un cas de panne d’une Fabric avec un Underlay iBGP composée de 2 RR  et de plusieurs Leafs :

Dans le cas de double panne comme indiquée dans le diagramme ci-dessus, les deux Leafs (L1 et L2) ne se verront plus même s’ils disposent chacun d’un lien vers un Spine RR : en effet, le RR (S1) n’apprend plus les routes de L1 pour les diffuser à L2 et le RR (S2) n’apprend plus les routes de L2 pour les diffuser à L1, un lien entre les Spines permettra de corriger ce point.

Les protocoles IS-IS/OSPF permettent de traiter ce cas de double panne, en effet les communications entre L1 et L2 seront toujours possible en passant par un Leaf de transit (L3) raccordé sur les deux Spines.

Contrainte 4 : L’implémentation de RR pour échanger les routes entre les Leafs sur la partie Underlay apporte beaucoup de restrictions et de contraintes pour ce type d’architectures.

En conclusion, je pense que déployer iBGP pour le routage Underlay apporte beaucoup plus de contraintes que de bénéfices :

• Nombre de lignes de configurations important à implémenter sur les équipements pour déclarer manuellement une à une les relations de voisinage iBGP.
• iBGP apporte quelques confusions dans le processus de sélection du meilleur chemin et gestion du next-hop, ce qui peut être problématique pour la compréhension du routage et de son exploitation au quotidien.
• Complexité supplémentaire liée à l’introduction des RR dans l’architecture : il faut gérer l’accessibilité des nexthop des Leafs dans la RIB/FIB pour permettre d’installer les routes BGP annoncées par ces Leafs.
• Duplication des échanges de plan de contrôle « BGP Updates » liés à la multiplication des RR.
• Non gestion de la double panne dans certains cas de design (voir ci-dessus)

Par conséquent, à mon humble avis, je pense que l’utilisation du protocole iBGP en pour le routage Underlay de la Fabric VxLAN/EVPN ne constitue pas une bonne pratique.

Dans la partie 3 de cette série, nous allons étudier le protocole eBGP en configuration Underlay de la Fabric VxLAN/EVPN, il permet de lever certaines contraintes de l’iBGP (RR, Nexthop, ..) mais en crée d’autres qu’on détaillera comme d’habitude en donnant un avis sur la solution.

Si vous avez des questions, des remarques ou vous avez besoin d’un complément d’informations, n’hésitez pas à laisser un message en commentaire de la page ou nous contacter directement à l’adresse : contact@mhd-experts.com.