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

Le standard aujourd’hui en terme des architectures en DC (Datacenter) est de les concevoir en topologie CLOS Fabric « Leaf & Spine », les protocoles VxLAN et EVPN sont élus comme standards par l’ensemble de la communauté pour assurer le fonctionnement de cette Fabric :

• VxLAN est un protocole d’encapsulation sur IP plus adaptés aux besoins DC. (RFC 7348)
• EVPN (Ethernet VPN) est une extension du protocole BGP (encore lui !) qui permet de fournir une complète isolation de niveau 2 et 3. (RFC 7432)

D’ailleurs, pour les environnements Data Center (DC), le draft draft-ietf-bess-evpn-overlay préconise l’utilisation du VxLAN pour le plan de donnée (Data Plane) et BGP EVPN pour le plan de contrôle (Control Plane).

Dans cette série d’articles, nous n’allons pas détaillé le fonctionnement de ces deux protocoles, on va plutôt s’intéresser à une couche souvent mise de côté et oubliée par plusieurs constructeurs : la couche Underlay.

Cette couche de « transport » de l’architecture est pourtant très essentielle et très critique aussi : si l’Underlay présente des faiblesses et des perturbations, toute l’infrastructure DC sera impactée même si elle implémente le meilleur Overlay du monde, c’est comme si vous construisez une maison sans trop vous soucier de ses fondations et les sécuriser, en cas de perturbations (exemple violente tempête), la maison toute entière sera impactée.

La couche Underlay a une seule et unique mission principale : assurer et garantir la connectivité IP entre les Leafs (VTEP) et Spines afin de leur permettre de construire le réseau Overlay (VxLAN/EVPN).

En terme d’implémentation, la couche Underlay doit permettre et garantir la connectivité IP entre des interfaces Loopbacks configurées sur les équipements Leafs et Spines afin d’établir des sessions EVPN et permettre aussi l’encapsulation VxLAN.

Dans cette série d’articles, nous allons aussi nous intéresser aux différentes options qui s’offrent à nous pour l’implémentation du routage dans cette couche de transport, quels sont les avantages et inconvénients de chacun de ces protocoles (EIGRP, OSPF, IS-IS, iBGP, eBGP) ? Quel protocole faut-il privilégier ? Quel protocole faut-il écarter ? Quelles sont tout simplement les bonnes pratiques ?

Pour faire cet exercice, étudions un cas concret d’architecture de Fabric DC : Conception d’une Fabric VxLAN/EVPN constituée de 200 Leafs et 4 Spines.

Le diagramme ci dessous résume cette architecture DC:

Besoins Underlay :

Le fonctionnement du routage de la couche Underlay est assez simple, il est résumé en quelques lignes comme suit :

• 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.

Intéressons-nous maintenant aux différentes options possibles pour le choix du protocole de routage de la couche Underlay :

EIGRP

Ce protocole a été certes bien conçu dès le départ et promettait un bel avenir, malheureusement sa ratification IETF a trop tardé (RFC 7868, année 2016) et très peu de constructeurs l’ont adopté et ne l’ont implémenté que partiellement (absence de fonctionnalité STUB), EIGRP ne permet pas aussi de fournir une vision topologique de l’architecture du routage ce qui pourrait être utile dans le cas où la couche Overlay (ex Contrôleur SDN) a besoin de connaitre l’architecture physique détaillée de l’Underlay (au même titre que l’utilisation de la fonctionnalité « BGP LS » pour les protocoles Link States).

Même si ce protocole répond favorablement au besoin d’un point de vue technique, je pense que son manque d’implémentation chez les constructeurs le pénalise fortement, par conséquent, ce protocole ne constitue pas une bonne option pour le routage de l’Underlay, si malgré tout cela vous souhaitez l’implémenter pour d’autres raisons, c’est que vous avez un excellent commercial Cisco 🙂

Link State Protocole (IS-IS ou OSPF)

Ces deux protocoles de la famille des protocoles à état de liens (Link State) sont très anciens et très similaires aussi dans leur fonctionnement : le domaine de flooding (LSP) en IS-IS est défini par niveau (level 1 ou 2) tandis qu’en OSPF (LSA) il est défini par aire, pour plus d’informations un article décrit ces deux protocoles dans notre blog.

Concernant les besoins exprimés plus haut pour l’Underlay à savoir annoncer deux interfaces loopback/Leaf sur 200 équipements, les deux protocoles peuvent les satisfaire assez facilement :

• En IS-IS, tous les équipements de la Fabric VxLAN/EVPN sont dans le même domaine de flooding (L1 ou L2) et annoncent les interfaces Loopback nécessaires au fonctionnement de l’Overlay (lo1 et lo2).
• En OSPF, tous les équipements de la Fabric VxLAN/EVPN sont dans la même aire backbone 0 et annoncent les interfaces Loopback nécessaires au fonctionnement de l’Overlay (lo1 et lo2).
• Annoncer 400 loopback sur ces deux protocoles est une mission assez facile aujourd’hui pour les deux protocoles surtout sur la génération d’équipements qu’on dispose en environnement DC (plusieurs CPUs et beaucoup de Mémoire).

Ce qui est souvent reproché à ses deux protocoles avec mon (humble) avis sur la contrainte :

• OSPFv2 n’implémente pas l’IPv6, il faut un autre protocole OSPFv3 avec les contraintes du dual stack : peu important dans notre contexte pour le routage Underlay de la Fabric, en effet, les interfaces loopback déclarées sur les Leafs &Spines sont statiques et leur configuration ne sera pas amené à être changé, l’OSPFv2 sera implémenté sur un support IPv4, sinon OSPFv3 pour un support IPv6 (VxLANv6). (à noter que pour certains constructeurs, OSPFv3 supporte aussi l’échange de route IPv4).
• OSPF/IS-IS ne permettent le filtrage de route au sein d’un même domaine de Flooding (Level/Area) : c’est tout à fait correct, mais cette contrainte n’existe pas pour l’Underlay de la Fabric, toutes les loopback des VTEPs doivent être joignables sans exception.
• OSPF/IS-IS sont très sensibles aux évènements, au moindre changement (métrique sur un lien, coupure de lien, perte d’équipement) les équipements exécutent le SPF pour définir un nouveau chemin de routage, par conséquent, le domaine d’impact (blast radius) est très important : c’est tout à fait correct, mais en environnement DC, on ne s’amuse pas vraiment à changer les métriques des liens (ECMP privilégié), et les liens intra-Fabric (contrairement au WAN) sont aussi généralement très stables, les interfaces loopback ne tombent pas d’elles même ! Et même s’il y a coupure, les équipements sont ultra performant en CPU pour exécuter assez facilement un SPF sur un graphe avec 200 nœuds ou chaque nœud annonce deux loopback (stub network).
• Les Bases de données OSPF/IS-IS sont très larges pour les architectures Leaf/Spine (partiel Mesh) et demandent un temps d’exécution important : argument valable sur les routeurs des années 90 avec processeur à 500 Mhz, aujourd’hui ce n’est plus valable, à noter aussi qu’on peut réduire considérablement la taille de la LSDB avec quelques optimisations OSPF et IS-IS (ex suppression des liens de transit).
• Les protocoles OSPF/IS-IS sont très bruyants et bavards dans les architectures Leaf/Spine : en environnement DC, les coupures de liens/équipements au sein de la Fabric sont vraiment très rares ce qui permet d’atténuer les échanges du plan de contrôle, maintenant, si cet argument ne suffit pas à vous convaincre, il est possible de réduire les échanges protocolaires par l’implémentation des fonctionnalités (Mesh group et Dynamic Flooding) dont le principe est restreindre l’échange (LSA/LSP) sur un nombre de lien pré-défini.

En conclusion, je pense que les deux protocoles IS-IS et OSPF restent des choix tout à fait valides pour le routage de l’Underlay de la Fabric, ma petite préférence va pour l’OSPF pour la simple raison qu’il est plus connu et maitrisé en environnement DC (Entreprise).

OSPF permet aussi d’être exécuté sur un support de type IPSEC (ex VTI chez Cisco) ce qui est pratique si besoin d’étendre l’Underlay (exemple Remote Leaf, Extension Cloud, ..).

Cependant, si vous êtes plus confortable avec l’IS-IS, privilégiez le pour le routage de votre Underlay !

Dans la deuxième partie de cette série d’articles, nous allons étudier le protocole BGP (iBGP et eBGP) en configuration Underlay de la Fabric VxLAN/EVPN, oui, j’ai bien dis BGP en IGP 🙂 il y a beaucoup de choses intéressantes à dire sur le sujet et je donnerai comme d’habitude mon humble avis sur le sujet, vous pouvez accéder à l’article ici.

Si vous avez des questions 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.