[Article sponsorisé par NVIDIA]
Une infrastructure Datacenter (DC) a pour mission principale d’héberger les applications SI de l’Entreprise, ces dernières se sont multipliées au cours de la dernière décennie avec des exigences et des contraintes très différentes du modèle traditionnel client-serveur, par conséquent, ces changements ont un impact très important sur la conception des réseaux Datacenter de nouvelle génération.
Ces nouvelles architectures DC sont conçues en topologie CLOS Fabric « Leaf & Spine » et implémentent les protocoles standards BGP-EVPN pour le plan de contrôle (control plane) et VxLAN pour le plan de données (data plane), ces technologies permettent de fournir nativement les services de connectivité et d’extension de niveau 2 (VLAN) et de niveau 3 (VRF) à travers un réseau IP routé (Underlay).
Dans cet article, nous allons nous intéresser de près aux opportunités offertes par la solution NVIDIA Cumulus pour les raccordements des serveurs et des services (FW,SLB) sur une Fabric VxLAN/EVPN : Pour assurer la haute disponibilité, ces raccordements sensibles doivent implémenter le Multi-Homing (MH) qui consiste à les raccorder sur plusieurs équipements Leafs distincts afin d’assurer une Haute Disponibilité (HD).
La solution traditionnelle qu’on retrouve chez une grande majorité des constructeurs consiste à implémenter sur une paire de Leafs une solution virtualisation de châssis (Multi-Chassis Link Aggregation Group ou MLAG) : un VTEP logique composé de deux Leafs physique est simulé en configurant une même interface de tunnel virtuel (VTI) pour permettre à chaque Leaf d’encapsuler et décapsuler le trafic VxLAN vers les équipements finaux, le schéma ci-après résume le principe de fonctionnement de la solution :
Cette solution présente les limitations ci-dessous :
- Introduction d’une nouvelle technologie (MLAG) dans l’architecture réseau avec son lot de contraintes d’exploitation et de maintenance par les équipes.
- Solution constructeur qui s’appuie sur un protocole propre de synchronisation entre les membres du cluster à travers deux nouveaux liens qui les connectent (Peer-Links) : La perte de la synchronisation entre les deux membres (split brain) entraine des perturbations importantes sur le réseau.
- Solution MLAG limitée à deux membre seulement par cluster : les équipements finaux sont contraints de toujours se raccorder sur une même paire de Leaf, l’urbanisation de l’infrastructure DC doit en tenir compte.
- Absence de support Multi-Constructeur : les deux membres du clusters doivent appartenir au même constructeur.
La solution NVDIA implémente la technologie EVPN pour répondre au besoin de raccordement Actif/Actif (Multi-Homing) des terminaux finaux : un identifiant de segment Ethernet unique (ESI) est attribué aux interfaces Ethernet et Port-Channel sur différents Leafs qui raccordent les serveurs et permettent à la Fabric VxLAN/EVPN de réaliser une répartition de la charge sur les différents membres (Mac ECMP + Underlay ECMP).
Par ailleurs, la RFC 7432 (BGP MPLS-Based Ethernet VPN) décrit les type 1 et 4 pour la prise en charge du Multi-Homing dans un environnement EVPN :
Le type 1 « Ethernet Auto-discovery Route » est utilisé pour deux fonctions distinctes :
- la convergence rapide (Fast Convergence) par le changement dans les annonces EVPN du nexthop associé aux adresses MAC d’un segment Ethernet (ES). (couverture du cas de panne de perte d’un lien actif)
- l’Aliasing qui permet la répartition de la charge en ECMP entre plusieurs points de sorties (Leafs).
Le type 4 « Ethernet Segment Route » est utilisé pour l’élection sur un segment de l’équipement Designated Forwarder (DF) responsable de la gestion du trafic de nature BUM (Broadcast, Unknown-Unicast, Multicast).
le schéma ci-après résume le principe de fonctionnement de la solution EVPN Multi-Homing dans NVIDIA :
Cette solution présente une alternative pertinente à la solution MLAG et permet d’apporter les avantages ci-dessous :
- Leaf autonome et libre de la contrainte de synchronisation pour maintenir un état de clustering (MLAG) à travers des interfaces dédiées (Peer Links)
- Plusieurs Leafs (>2) sont supportés par la technologie : les équipements finaux peuvent former un lien d’agrégation en LACP avec plusieurs Leafs distincts et qui partagent le même Ethernet Segment Identfier (ESI)
- Support Multi-Constructeur : les Leafs peuvent appartenir à plusieurs constructeurs différents qui implémentent correctement les standards de la solution tel que décrit dans la RFC.
Sur Cumulus, la configuration du EVPN Multi-Homing avec ESI s’execute de cette façon, sur un couple de Leafs :
Étape 1 : Activer la fonctionnalité Multi-Homing :
# nv set evpn multihoming enable on
Étape 2 : Configurer les interfaces bonds ( ci-après le bond1 englobe swp1 ) :
# nv set interface bond1 bond member swp1
# nv set interface bond1 evpn multihoming segment local-id 1
# nv set interface bond1 evpn multihoming segment mac-address 44:38:39:BE:EF:AA
Étape 3 : Définir un designated forwarder (DF) sur un des deux leafs :
# nv set interface bond1 evpn multihoming segment df-preference 50000
Étape 4 : Configurer l’uplink tracking qui permet de monitorer les liens de la Fabric ( ci-après les interfaces swp51-swp54) :
# nv set interface swp51-54 evpn multihoming uplink on
Étape 5 : Appliquer la configuration sur les équipements :
# nv config apply
Pour vérifier le bon fonctionnement de la solution, les commandes à utiliser sont :
leaf01h# net show evpn es-evi
Type: L local, R remote
Type: L local, R remote
VNI ESI Type
10 03:44:38:39:be:ef:aa:00:00:01 L
leaf01# net show bgp l2vpn evpn es
ES Flags: B – bypass, L local, R remote, I inconsistent
VTEP Flags: E ESR/Type-4, A active nexthop
ESI Flags RD #VNIs VTEPs
03:44:38:39:be:ef:aa:00:00:01 BLR 10.10.10.1:3 1
03:44:38:39:be:ef:bb:00:00:01 R – 1
leaf01# net show bgp l2vpn evpn es-evi
Flags: L local, R remote, I inconsistent
VTEP-Flags: E EAD-per-ES, V EAD-per-EVI
VNI ESI Flags VTEPs
10 03:44:38:39:be:ef:aa:00:00:01 LR 10.10.10.2(V)
10 03:44:38:39:be:ef:bb:00:00:01 R 10.10.10.3(V),10.10.10.4(V)
leaf01# net show bgp l2vpn evpn route type ead
BGP table version is 3, local router ID is 10.10.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal
Origin codes: i – IGP, e – EGP, ? – incomplete
EVPN type-1 prefix: [1]:[ESI]:[EthTag]:[IPlen]:[VTEP-IP]
EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]
Network Next Hop Metric LocPrf Weight Path
Extended Community
Route Distinguisher: 10.10.10.1:2
*> [1]:[0]:[03:44:38:39:be:ef:aa:00:00:02]:[128]:[0.0.0.0]
10.10.10.1 32768 i
ET:8 RT:65101:20
Route Distinguisher: 10.10.10.1:6
*> [1]:[0]:[03:44:38:39:be:ef:aa:00:00:03]:[128]:[0.0.0.0]
10.10.10.1 32768 i
ET:8 RT:65101:30
Route Distinguisher: 10.10.10.1:7
*> [1]:[0]:[03:44:38:39:be:ef:aa:00:00:01]:[128]:[0.0.0.0]
10.10.10.1 32768 i
ET:8 RT:65101:10
Route Distinguisher: 10.10.10.2:2
*> [1]:[0]:[03:44:38:39:be:ef:aa:00:00:02]:[32]:[0.0.0.0]
10.10.10.2 0 65199 65102 i
RT:65102:20 ET:8
Route Distinguisher: 10.10.10.2:6
*> [1]:[0]:[03:44:38:39:be:ef:aa:00:00:03]:[32]:[0.0.0.0]
10.10.10.2 0 65199 65102 i
RT:65102:30 ET:8
Route Distinguisher: 10.10.10.2:7
*> [1]:[0]:[03:44:38:39:be:ef:aa:00:00:01]:[32]:[0.0.0.0]
10.10.10.2 0 65199 65102 i
RT:65102:10 ET:8
Route Distinguisher: 10.10.10.3:2
*> [1]:[0]:[03:44:38:39:be:ef:bb:00:00:02]:[32]:[0.0.0.0]
10.10.10.3 0 65199 65103 i
RT:65103:20 ET:8
Pour toute information complémentaire sur la solution, n’hésitez pas à nous contacter sur contact@mhd-experts.com
