EVPN : expérimentation et cas d'usage
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
EVPN : expérimentation et cas d’usage Anthony Brissonnet Ingénieur réseau, Infrastructures Réseaux et Centre de calcul, DNum Université de Bourgogne Yann Dupont Responsable pôle data center & calcul scientifique, CCIPL/DSIN Université de Nantes Xavier Jeannin Ingénieur réseau, RENATER Résumé Ethernet VPN (EVPN RFC 7432 (1)), est un service de VPN niveau 2 multi-points dont l’adoption se développe, car il corrige des limitations de VPLS et ajoute de nouvelles fonctionnalités spécifiques à la gestion des clouds et data-centers, tout en offrant un meilleur passage à l’échelle. Nous vous présenterons plusieurs cas d’usage pour la communauté éducation/recherche : service L2VPN multi-points chez un opérateur, fabrique de data-center, utilisation d’un cœur distribué, interconnexion de data-centers (PRA, …), L2VPN sur WAN IP, service de peering et point d’interconnexion. Un retour d’expérience sur l’utilisation d’une fabrique de data-center basée sur EVPN/VXLAN sera présentée par l’université de Bourgogne. EVPN et PBB-EVPN (2) ont été testés sur l’infrastructure MD- VPN qui permet de déployer des VPN de niveau 2/3 sur 16 pays. La démonstration de fonctionnalités avancées comme le multi-homing actif/actif, la répartition de charge par flux seront aussi présentées et particulièrement la migration de machines virtuelles à travers l’Europe par l’université de Nantes. Enfin, parmi les architectures d’interconnexion de data-centers, nous soulignerons la flexibilité des solutions basées sur VXLAN. EVPN et d’autres types de VPN sont aussi utiles pour interconnecter directement un système d’information (une université, par exemple) à un fournisseur de clouds (académique/commercial), dans un modèle de cloud hybride. Ces techniques sont donc à considérer pour l’architecture et l’interconnexion de data-centers, la connexion d’un système d’information à un cloud, mais aussi pour le développement en général de l’usage de ressources distribuées (stockage/computing). Mots-clefs L2VPN, MPLS, VXLAN, Cloud, Data-Center (DC), Point d’échange. 1 Introduction Cet article s’attache à présenter le protocole Ethernet VPN sous l’angle des cas d’usage possibles pour la communauté éducation/recherche : fabrique d’un data-center et d’un campus, interconnexion de data- center, Internet eXchange Point, extension de son SI dans un Cloud, L2VPN multi-point service pour WAN IP. Nous terminons par les architectures basées sur VXLAN (Virtual eXtensive LAN) pour l’interconnexion de data-centers, car elles offrent aux utilisateurs une souplesse et une dynamicité importantes. JRES 2017 - Nantes 1/17
2 Expérimentation EVPN dans un contexte multi-domaines
L’intérêt de déployer des VPN sur plusieurs réseaux est de pouvoir fournir des services à la communauté
éducation et recherche pour ses projets à l’échelle nationale ou européenne. EVPN rejoint les autres types
de VPN que l’on peut transporter grâce au service MD-VPN : L3VPN (IPv4, IPv6), L2VPN P2P (Kompella
et Martini), VPLS.
2.1 Expérimentation au-dessus de MD-VPN
Pour tester EVPN, nous avons utilisé un banc d’essai international qui a été réalisé grâce à des tunnels P2P
L2VPN fournis par le service MD-VPN.
L2VPN bridge
Host 1
NiffPE
PE
Host 2
ASBR
MX104
RR AmresPE
evpn-core-1
evpn-core-2
evpn-core-4
MX-d1
evpn-core-3
PE1 ASBR1
MX80 logical systems
DC switch rr-pionier
PE2 ASBR2 DfnPE
NordunetPE
FunetPE
Figure 1 : Banc d’essai multi-domaines EVPN
2.1.1 EVPN RFC 7432 et PBB-EVPN RFC 7623
Afin d’être concis, nous présentons uniquement les conclusions :
EVPN et PPB-EVPN sont compatibles avec le service MD-VPN et peuvent donc s’ajouter au
catalogue de service pour les pays et réseaux régionaux ayant déployé MD-VPN.
Pour qu’EVPN puisse intégrer le service MD-VPN, il suffit d’ajouter dans GEANT la family BGP
EVPN ou L2VPN EVPN (selon les dénominations) dans les réflecteurs de routes VPN de GEANT
qui sont utilisés pour le service MD-VPN.
Le groupe de travail recommande à GEANT de créer deux réflecteurs de routes VPN spécifiques pour
EVPN, car le nombre de routes échangées peut être très élevé. Cette opération devrait être facile et légère,
car les réflecteurs de routes VPN sont implémentés via des « logical system » (sorte de routeurs virtuels au
sein d’un routeur physique) sur les routeurs de GEANT.
2.1.2 Intégration L3 dans EVPN et gateway distribuée
Il est possible d’adjoindre à une instance EVPN un L3VPN : cela se fait par un recours à une interface
virtuelle (Integrated Routing and Bridging) qui sert à router les paquets inter-subnets. L’interface de
JRES 2017 - Nantes 2/17
routage inter-subnets peut être dupliquée (distribuée) sur chaque site, il est ainsi possible de router les paquets au plus près de la VM, même si cette dernière a été déplacée entre deux sites. Cette option, qui permet d’éviter aux flux réseau de remonter à un point unique de routage, constitue un facteur important d’optimisation dans un déploiement d’EVPN pour une fabrique de data-center ou de campus. 2.1.3 Mobilité de machine virtuelle Le data-center de l’Université de Nantes héberge de nombreuses ressources pour la communauté éducation/recherche de la région. Son offre de services en constante évolution propose désormais la mise à disposition d’infrastructures virtuelles à la demande (IaaS), qui reposent sur son infrastructure physique (serveurs, réseaux, stockage). Déplacer une machine virtuelle (VM) d’un hôte à un autre dans cet environnement maîtrisé est aisé, mais faire de même vers un data-center tiers implique des opérations de configuration concertées conséquentes. Pourtant, à terme, offrir ce service de façon simple et sécurisée depuis un ensemble de data-centers interconnectés, répartis sur un territoire étendu (région, France ou Europe) est la cible à atteindre. Le succès d’un tel projet repose sur la transparence des opérations pour l’utilisateur final et la simplicité de configuration pour les opérateurs des plateformes d’hébergement. La phase d’expérimentation EVPN comprenait le test de certains cas d’usage tels que la migration de machines virtuelles : une occasion parfaite pour tester et valider l’adéquation de ce mécanisme en grandeur nature et mesurer la simplification de la configuration de la partie réseau du service. 2.1.3.1 Banc d’essai local Afin de ne pas influer sur les opérations de production du data-center, un banc d'essai local dédié et permanent (serveurs et matériel réseau) a été implanté. Sa configuration réseau locale repose sur un unique VLAN et est donc extrêmement basique. Physiquement, notre connexion au banc d’essai EVPN se fait simplement via un port Ethernet mis à disposition par Renater et relié au banc d’essai européen déployé par Geant. Trois lames physiques de type différent ont été localement consacrées aux tests de migration et une quatrième machine, fournie par AMRES, a été installée à Belgrade. JRES 2017 - Nantes 3/17
Figure 1: banc d’essai local pour les tests de mobilité de machines virtuelles Le stockage des machines virtuelles (racines et données) est assuré par une passerelle NFS à CEPH disposant d’un double attachement réseau (d’un côté le banc d’essai EVPN, de l’autre le réseau de l'université protégé et isolé accédant au stockage CEPH). L’utilisation directe par les VM de nos plateformes CEPH de production aurait introduit une porosité et des routages spécifiques non souhaitables. L’hyperviseur KVM a été retenu, conjointement à la couche d’abstraction libvirt. Le mode de migration choisi utilise une communication directe, initiée par un canal SSH. Les hôtes partagent simplement les clés SSH et un montage NFS, contenant les images disque (qcow2) des machines virtuelles. La plateforme est simplifiée au maximum, mais la réussite des migrations dans ce cas validera de fait le fonctionnement sur les plateformes d’IaaS populaires telles qu’opennebula ou openstack. En effet, KVM+libvirt en est une couche sous-jacente classique. 2.1.3.2 Performance réseau du banc d’essai Une migration à chaud transfère, en plusieurs passes, une copie complète de la RAM de la VM via le réseau jusqu’à un point de convergence. En 2015, des tests avec la Finlande (Funet) sur une plateforme disposant d’une bande passante limitée avec une latence élevée ont montré qu’une VM sollicitée génère une activité mémoire pouvant excéder les capacités de ce réseau. La migration à froid est alors la seule option praticable. Dans le cas présent, la bande passante mesurée permet de migrer à chaud dans de bonnes conditions : 2.1.3.3 Tests de migration Diverses VM ont été migrées avec succès de Nantes vers Belgrade et vice-versa ainsi : La migration effective d’une petite VM disposant de 1 Go de ram prend moins de quinze secondes. Les variations de latence sont visibles pendant les migrations en direct (aller-retour) : la mise en surbrillance correspond au moment où la VM se déplace physiquement vers la machine hôte à Belgrade. Quelques paquets ICMP sont alors perdus et l'augmentation de la latence a des conséquences sensibles pour l’utilisateur final. Il suffit de déporter l’affichage d’applications usuelles, telles qu’un navigateur pour en ressentir l’impact. L'instant précis où la VM change d’hôte est court, mais perceptible (quelques secondes de gel de l'affichage). Après migration, les processus interactifs, tels qu’un traitement de texte, peuvent souffrir d’un léger retard d’affichage. Mais c’est l’accès à un fichier ou une bibliothèque non chargée en mémoire qui est bien plus sensible ; en effet, le stockage (NFS dans ce cas particulier) toujours localisé à Nantes va voir ses performances fortement pénalisées : chaque entrée/sortie nécessite alors près de 90 ms. Le benchmark disque « fio » avec un profil I/0 aléatoire illustre le cas : le test s’achève en 37s avec la VM à Nantes, contre 220s depuis Belgrade. La machine hôte, où le processeur est plus puissant qu’à Nantes, JRES 2017 - Nantes 4/17
n’est pas en cause ; un programme orienté vers le calcul ne sera pas affecté. Par exemple :
2.1.3.4 Futur
EVPN est un pas vers un service IaaS indépendant du data-center sous-jacent, il simplifie la configuration
du réseau et celle du stockage, mais ce dernier devant reposer sur Ethernet, les technologies classiques SAS,
SATA et Fibre Channel sont disqualifiées.
La performance du stockage après migration doit ensuite être considérée. Copier les données puis migrer
le serveur NFS lui-même serait simple, mais l’important volume des données à déplacer est incompatible
avec une migration à chaud rapide.
Un stockage CEPH global implanté dans les data-centers concernés, utilisé directement par les VM est
attirant, mais le synchronisme de la réplication interne de CEPH limitera vite les performances de
l’ensemble (d’expérience, la limite correspond à des latences supérieures à quelques ms, c’est-à-dire des
distances excédant quelques dizaines de kilomètres).
Une meilleure idée serait l'utilisation d'un média partagé répliqué de façon asynchrone. DRBD peut être un
candidat, tout comme la fonctionnalité de mise en miroir asynchrone de CEPH. Lorsqu'une machine
virtuelle migre, la quasi-totalité des données est déjà disponible de l'autre côté. Tout comme la mémoire, il
ne reste alors qu’à rapatrier la différence entre les deux data-centers avant de migrer définitivement la
machine virtuelle, qui opérera alors avec ses données locales, garantissant une bonne performance. Tous
les mécanismes sous-jacents sont disponibles, il faut désormais que les plateformes d’IaaS les intègrent.
Ces tests ont démontré la valeur de la technologie EVPN comme élément facilitateur d’une mise en place
d’une infrastructure Cloud ou IaaS opérée sur plusieurs data-centers. Cette technologie pourra également
être mise à profit pour simplifier la mise en place d’un stockage distribué, dernier point bloquant pour un
déploiement aisé.
2.1.4 EVPN Multi-homing et load balancing
Le groupe de travail GEANT et particulièrement Pionier (NREN Polonais) a testé l’implémentation du
multihoming all-active EVPN qui permet aux deux brins de connexion d’un data-center de rester actifs, ce
qui n’était pas le cas, nativement, avec VPLS. Nous constatons dans cette expérimentation que les routes
sont correctement distribuées entre les PE (Provider Edge router : routeur qui interconnecte le backbone
opérateur et le site utilisateur). Cela démontre à la fois les capacités de multi-homing et de load balancing
d’EVPN.
Dans la configuration des 2 PE, on déclare un Ethernet Segment Identifier (ESI) qui est un identifiant unique
du segment Ethernet (ensemble des liens qui relient un data-center à des PE) :
00:10:22:33:44:55:66:77:88:99. On peut reconnaître dans les routes échangées l’ESI et les labels générés
pour la gestion des ESI c.-à-d. du multi-homing active/active.
evpn-1.evpn.0: 71 destinations, 71 routes (71 active, 0 holddown, 0
hidden)
1:10.253.255.1:0::102233445566778899::FFFF:FFFF/304 (1 entry, 1
announced)
*BGP Preference: 170/-101
…
Communities: target:65222:1 target:65222:2 esi-label:all-active
JRES 2017 - Nantes 5/17
(label 304528)
…
Primary Routing Table bgp.evpn.0
Afin de réaliser le partage de charge sur le switch (EX3200) qui connecte le data-center à 2 PE, un trafic
UDP est généré en modifiant les ports UDP source et destination pour simuler plusieurs flux réseau :
En générant 100 à 1000 trame par seconde, on peut voir, sur les deux interfaces de l’EX3200 qui reçoivent
les flux, un intéressant partage de charge. C’est en poussant le débit à 10 000 trames par seconde que l’on
constate un partage de charge presque équitable :
Dernier point très intéressant, le générateur et récepteur de paquets « Spirent » ne signale aucun
réordonnancement de paquets :
Cela constitue un très bon résultat pour l’usage d’EVPN pour les data-centers : rappelons qu’il n’a pas été
fait usage de MC-LAG (Multi-Chassis Link Aggregation Group).
JRES 2017 - Nantes 6/17
3 Cas d’usage d’EVPN
3.1 L2VPN multi-point service pour network provider
Dans ce cas d’utilisation, un opérateur utilise EVPN pour fournir ses VPN de niveau 2 point-à-point (P2P)
et multi-points (MP). L’opérateur tire bénéfice des points suivants :
active/active multi-homing ;
réduction du trafic BUM (Broadcast Unknown Multicast) ;
meilleur passage à l’échelle grâce à l’usage de BGP.
Figure 2 : L2VPN multi-point service pour network provider
3.2 L2VPN over IP WAN
L’un des intérêts d’EVPN est sa capacité à fonctionner sur différents plans de commutation notamment IP ;
plus besoin de MPLS. Cela peut être très utile par exemple pour un réseau régional qui veut fournir des
VPN au-delà de son périmètre.
De même, un data-center peut prolonger un niveau 2 vers un second site au-dessus d’un opérateur IP en
créant un tunnel VXLAN et en échangeant des routes EVPN entre les 2 sites.
Figure 3 : exemple d'utilisation d'un L2VPN sur un backbone IP
3.3 EVPN sur une fabrique IP dans un data-center
Comme EVPN peut fonctionner sur plusieurs plans de commutation, il peut être utilisé dans un data-center
pour réaliser un réseau en overlay au-dessus d’une fabrique IP (IP fabric (underlay) + overlay (VXLAN)).
La fabrique IP résiste extrêmement bien à la montée en charge et est très robuste. EVPN est utilisé pour
fournir le niveau 2 entre les machines d’un même utilisateur. Il n’y a pas besoin de gérer plusieurs niveaux
2 au sein du data-center, chaque niveau 2 est dans une instance EVPN. De plus, il y a un gain de sécurité
grâce à la segmentation des utilisateurs (Multi-tenant segmentation).
JRES 2017 - Nantes 7/17
Figure 4 : EVPN pour une fabrique de data-center
3.4 Fabric campus
Au sein d'un campus, EVPN peut trouver plusieurs applications. Au même titre qu'un data-center, il permet
le transport de flux L2 sur IP ou MPLS. Cette technologie peut donc répondre à plusieurs besoins : la
mobilité des agents (affectés à plusieurs composantes par exemple) ou le transport de certaines applications
type IoT qui nécessitent une communication sur un même segment Ethernet.
En complément, notons que les réseaux de campus s'apparentent aujourd'hui à de véritables réseaux
opérateurs où il est parfois nécessaire de transporter des réseaux d'établissements partenaires en mode multi-
tenant apportant segmentation et sécurité.
Enfin rappelons qu'EVPN permet la synchronisation des @MAC et entrées ARP/NDP via BGP, ainsi que
le multi-homing (2 membres et plus). Il se révèle une très bonne alternative multi-constructeurs aux
technologies de type VSS / MC-LAG + VRRP, généralement employées en cœur de réseau campus. Cette
application est particulièrement pertinente dans une architecture de type multi-cœurs ou collapse cœur /
distribution.
Figure 5 : Fabric campus
3.5 Internet eXchange Point (GIX)
De même, il est possible d’utiliser EVPN pour le plan de contrôle d’un GIX. Les avantages seront les
mêmes que pour un opérateur : passage à l’échelle, multi-homing actif/actif et load balancing. À ces points,
il faut ajouter une meilleure politique de contrôle d’accès, car les routes MAC/L3 sont annoncées par BGP.
JRES 2017 - Nantes 8/17
Figure 6 : Internet Exchange Point
3.6 Data Center Interconnexion (DCI)
L’interconnexion de data-centers est plus facile, moins risquée et plus fiable au niveau 3 (L3VPN). De plus,
l’utilisation d’une interconnexion de niveau 2 est plus difficilement acceptée si les deux data-centers ne
sont pas gérés par les mêmes entités, comme dans le cas d’un projet scientifique (PRACE, LHCONE,
EOSC, …).
Lorsque les contraintes des applications obligent à utiliser une connexion niveau 2, EVPN est une très
bonne option. L’intérêt d’EVPN est d’offrir une solution d’interconnexion transparente de niveau 2 au
travers d’un backbone MPLS ou de niveau 3. On retrouve les avantages déjà évoqués : passage à l’échelle,
robustesse, réduction du BUM, active-active multi-homing. À cette liste, on peut ajouter la migration de
VM sans renumérotation. Le cas d’utilisation DCI avec usage d’EVPN/VXLAN est détaillé plus bas.
Dernier cas à considérer, EVPN sur VXLAN permettant de créer des VPN sur IP, il est possible de l’utiliser
pour interconnecter plusieurs data-centers par un VPN. Il suffit de placer un routeur à l’entrée du VPN (voir
figure Section « L2VPN over IP WAN ») dans les data-centers et on obtient, grâce à la souplesse
d’EVPN/VXLAN, une interconnexion de data-centers au niveau 3, et ce au-dessus d’un simple backbone
IP.
Figure 7 : Data Center Interconnect
4 EVPN pour la fabrique de data-center
4.1 Contexte
En service depuis 2016, le Green data-center de l’université de Bourgogne centralise toutes les infrastruc-
tures informatiques du grand campus bourguignon. D’une surface totale de 675 m², le bâtiment intègre des
JRES 2017 - Nantes 9/17
espaces IT de très haute densité et de très haute disponibilité, ainsi que des espaces de stockage, d’intégra-
tion et des bureaux dédiés à la Direction du Numérique.
4.2 Historique et choix technologiques
À l’ère du Cloud Computing et des technologies de virtualisation, il s’avère indispensable de construire des
infrastructures réseau de data-center flexibles, élastiques et à la demande. Leurs caractéristiques
technologiques et leur conception sont des composants essentiels pour la prise en compte des technologies
émergentes (IoT - Internet of Things, XaaS - Anything As a Service) et l’intégration des nouvelles
applications métiers. Enfin, elles doivent permettre une ouverture à la virtualisation du réseau (Service
Chaining, NFV - Network Functions Virtualization) et aux outils d'orchestration et d'automatisation (SDN
- Software Defined Networking).
Fort d’une expérience de plusieurs années dans l’exploitation des infrastructures réseaux de nos anciennes
salles machines, nous avons pu constater les limites des architectures hiérarchiques trois tiers
traditionnelles. Outre les problèmes inhérents à ce modèle, sujet aux goulets d’étranglements et aux fortes
latences (multiplication des étages, centralisation du routage au cœur), ces dernières s’appuient
généralement sur des technologies de niveau 2 comme Spanning-Tree ou MC-LAG, trop peu adaptées aux
objectifs de résilience et de passage à l’échelle. De même, les mécanismes de segmentation basés sur
802.1Q ne s’avèrent plus suffisants, notamment dans un contexte multi-tenant (limitation à 4094 segments).
Conscients de ces contraintes et des enjeux liés à la transformation du numérique, notamment dans la
modernisation des infrastructures physiques et dans nos activités d’ingénierie réseau, nous avons décidé de
construire l’architecture réseau de notre data-center sur une fabrique VXLAN à plan de contrôle MP-BGP
(MultiProtocol Border Gateway Protocol) EVPN.
4.3 Architecture Spine and Leaf
Organisée en topologie de type Spine & Leaf, cette architecture s’appuie sur des produits Cisco Nexus,
gamme spécialisée et dédiée aux environnements Cloud Computing et HPC (High Performance
Computing).
Spine (Cisco Nexus 9508) Serveurs
Réseaux externes (Campus, Resubie,
Leaf (Cisco Nexus 9300 / 9300-EX)
Renater)
Border Leaf (Cisco Nexus 7702) Raccordements 1Gbps / 10Gbps / 25Gbps
Architecture de stockage Raccordements 40 Gbps
Figure 8 : Architecture du data-center de l’université de Bourgogne
JRES 2017 - Nantes 10/17Chaque armoire de serveurs est composée d’un ou plusieurs commutateurs N9300 de type ToR (Top-of-
Rack) disposant de 48 à 96 ports 1G/10G voire 25G. Ces derniers sont intégralement raccordés à deux
commutateurs N9508 équipés de cartes 40G/100G (QSFP28) non bloquantes. Enfin, quatre Leaf
spécifiques ont également été déployées :
deux Service Leaf pour le raccordement des systèmes de stockage : Metro Cluster NetApp pour la
messagerie institutionnelle et SAN iSCSI dédiés aux infrastructures de virtualisation ;
deux Border Leaf (N7702 équipés d’une carte M3 40G) dédiées à l’intégration des services L4-
L7 : plateformes de sécurité et d’analyse, ressources extérieures.
Ce maillage garantit une homogénéité et un nombre restreint de sauts entre chaque équipement d’extrémité,
minimisant la latence pour une plus grande résilience et prédictibilité des échanges. Actuellement, notre
rapport sursouscription (différentiel entre le débit d’accès et le débit montant) est de 6:1, soit 480Gbps pour
80Gbps (avec une perspective à 4:1 d’ici 2020). Toutefois, un soin particulier a été apporté au choix du
matériel afin de proposer au besoin un ratio de 1:1 pour un transport non bloquant de bout en bout.
Ce type d’architecture se révèle parfaitement adaptée à l’intensification des flux de type Est-Ouest (entre
serveurs) que nous rencontrons et qui sont liés principalement aux infrastructures de stockages SAN
(Storage Area Network), VDI (Virtual Desktop Infrastructure), projets Big-Data/Hadoop et Mésocentre.
Enfin, elle offre une capacité d’évolutivité importante horizontale (Spine) comme verticale (Leaf / Multi-
PoD).
4.4 Fabrique IP et underlay
Dans une fabrique IP, l’intégralité des raccordements entre équipements est opérée en niveau 3. Le
protocole de routage IS-IS (Intermediate System to Intermediate System) permet l’apprentissage et
l’annonce des adresses internes. L’ECMP (Equal Cost Multi-Path) – à comparer à Spanning-Tree dans une
architecture L2 traditionnelle – rend l’ensemble des liens actifs et permet de distribuer la charge vers chaque
Spine. Enfin et pour une meilleure convergence, plusieurs optimisations ont été apportées telles que : BFD
(Bidirectionnal Forwarding Detection), réduction de la RIB (IP Unnumbering), des temps de calculs SPF
(Shortest Path First) et de propagation des LSP (Label Switched Path).
Cette approche permet la création d’une couche de communication performante, fiable et résiliente entre
l’ensemble des équipements. Cette dernière est un élément essentiel aux mécanismes de transports, décrits
ci-après.
4.5 VXLAN MP-BGP EVPN
VXLAN est un protocole d’encapsulation de type MAC-in-UDP, permettant de fournir une connectivité de
niveau 2 au travers d’un réseau IP. Dans ce contexte, chaque domaine transporté est identifié par un VNID
(Virtual Network IDentifier) codé sur 24 bits. Ainsi, 16 millions de VXLAN Segments peuvent coexister au
sein d’une même fabrique. Chaque commutateur ToR implémente alors un VTEP (Virtual Tunnel End
Point), identifié par une adresse de loopback annoncée par IS-IS. Ce dernier assure le rôle de passerelle
(VXLAN L2 Gateway) entre un VLAN (définition locale au commutateur, voire à une interface) et un
segment VXLAN transporté en UDP aux autres VTEP concernés.
JRES 2017 - Nantes 11/17Notre implémentation se base sur l’intégration de VXLAN à l’extension MP-BGP du protocole BGP. MP-
BGP permet de transporter des informations d’accessibilité (NLRI - Network Layer Reachability
Information) pour divers protocoles : IPv4, IPv6, L3VPN, L2VPN, Labeled Unicast, … et dans notre cas
EVPN.
EVPN est une famille spécifique permettant de publier les adresses MAC et le VTEP associé (EVPN route
type 2). Cette implémentation apporte les avantages et la scalabilité de BGP à la gestion des adresses MAC
et permet de séparer le plan de contrôle (décision de routage/forwarding) du plan de données (actions de
routage/forwarding). Nul besoin de recourir au flooding pour l’apprentissage d’une adresse MAC : cette
information est diffusée sur chaque ToR par deux réflecteurs de routes BGP configurés sur les Spines.
Concernant le trafic BUM, nous avons opté pour un traitement par multicast, plus scalable et moins
impactant sur les ressources CPU des ToR. Dans un souci de redondance, deux points de rendez-vous PIM
ASM (Protocol Independent Multicast Any Source Multicast) ont été configurés sur les Spines.
EVPN VXLAN supporte le multi-homing actif/actif de serveurs (cas de l’ensemble de nos hyperviseurs).
Dans l’implémentation de Cisco, cette fonction se traduit par la création d’un VPC (Virtual Port Channel,
analogue au MC-LAG et donc limité à deux équipements) et par l’introduction du concept L2 Anycast
Gateway (association des routes à une adresse de VTEP secondaire partagée par chaque membre du VPC).
Au niveau 3, le mécanisme d’IP Anycast Gateway permet de distribuer la passerelle d’un réseau sur
l’ensemble des commutateurs de la fabrique. En complément des adresses MAC, EVPN associe alors les
adresses IP (IPv4 ou IPv6) de chaque hôte dans les annonces BGP. Chaque ToR est alors capable de
répondre aux requêtes APR/NDP (fonction d’ARP Suppression).
La communication entre deux VLAN distincts peut s’effectuer soit par routage standard, soit au sein d’une
VRF (Virtual Routing and Forwarding). À l’image des mécanismes d’IP VPN basés sur MPLS, il est alors
possible de créer plusieurs tenants et de segmenter le flux par tenant (composante, laboratoire, institution,
partenaire, …) ou par domaine de sécurité (DMZ). Le routage inter-VRF est délégué à un cluster de pare-
feu Checkpoint par VRF-Lite. Les routes externes (LPM) sont alors annoncées dans la fabrique par EVPN
(route type 5).
L’intégration récente de notre réseau de collecte à cette architecture nous permet de supporter les principaux
protocoles de DCI (Data Center Interconnect). Notre inscription au projet européen MD-VPN (Multi
Domain VPN) vient renforcer ces aspects.
Les architectures de data-center basées sur les technologies VXLAN EVPN apportent donc un ensemble
d’améliorations au regard des modèles traditionnels. Parmi ces dernières, on peut retenir :
une implémentation basée sur des technologies ouvertes multi-constructeurs ;
les performances : 10G/25G en accès et 40G/100G entre commutateurs ;
la résilience et le partage de charge : ECMP et Multi-homing ;
la scalabilité et le passage à l’échelle : plusieurs dizaines de milliers d’hôtes gérés, jusqu’à 16
millions (limite théorique) de segments VXLAN supportés ;
l’évolutivité verticale et horizontale : 256 leafs au sein d’un PoD, environnement MultipoD ;
la diminution drastique du flooding : distribution des informations d’accessibilité MAC/IP de
chaque hôte, suppression et proxy ARP / NDP sur chaque ToR ;
l’élasticité par la mobilité de machines virtuelles au sein ou entre data-centers : transport L2 sur
réseau IP, IP Anycast Gateway ;
la segmentation et les capacités d’architecture multi-tenant notamment dans un objectif de
constitution d’un cloud public/académique ;
la prolongation des services par DCI sur nos autres infrastructures : campus et réseau de collecte
RESUBIE voire RENATER via MD-VPN ;
l’intégration aux technologies d’automatisation et de SDN : API REST/NxOS, interpréteur
Python, NetCONF, Openstack, Ansible, …
JRES 2017 - Nantes 12/175 Interconnexion de data-centers domaine grâce à
VXLAN/EVPN en multi-domaines
EVPN est indépendant du plan de commutation et peut ainsi tourner sur MPLS, VXLAN/IP, ... Les data-
centers connaissent VXLAN au contraire de MPLS. De même, certains NREN et réseaux régionaux
n’utilisent pas MPLS. Il est donc intéressant de pouvoir étendre un VPN fourni par VXLAN/EVPN à
plusieurs domaines réseau. Nous ne décrirons ici que l’interconnexion de niveau 2. Il existe plusieurs
scénarios que nous n’avons pas la place ici d’aborder en détail. Nous ne fournissons que les schémas et
quelques remarques importantes sur chaque architecture 1.
5.1 EVPN/VXLAN (Full IP)
Dans ce cas, il s’agit de créer un VPN de niveau 2 P2P ou MP sur une infrastructure réseau de niveau 3.
Les PE établissent des tunnels VXLAN entre eux, le point terminal du tunnel (VTEP - VXLAN Terminal
End Point) étant implémenté sur leur loopback. Le transport s’effectue sur IP.
Figure 9 : instance EVPN/VXLAN avec usage de réflecteurs de routes VPN
Avec VXLAN multicast, il est possible d’introduire des appareils pirates (rogue device).
EVPN, grâce à ses peering BGP, offre plus de sécurité. Néanmoins, une attaque en aveugle est
réalisable et le nombre d’attaquants possibles est précisément égal au nombre d’utilisateurs de
l’Internet.
Le maintien de la MTU tout au long du chemin est difficile ce qui peut impacter la performance.
Un opérateur est capable de fournir un L3VPN qui garantit la MTU et ainsi les performances.
5.2 EVPN sur VXLAN transporté via L3VPN et délivré par MD-VPN
Pour corriger les points ci-dessus, l’instance EVPN VXLAN est transporté dans un L3VPN. La sécurité est
meilleure et l’utilisateur peut bénéficier d’une MTU qui ne pénalisera pas ces performances. Un tunnel
VXLAN est instancié entre les ToR ou les hyperviseurs des 2 data-centers.
1
Pour plus d’informations :
https://intranet.geant.org/gn4/2/Activities/JRA1/Milestones%20Documents/Network%20Transport%20Solutions%20for%20e-
infrastructures%20Integration/M7-2_Network-Transport-Solutions-for-e-Infrastructures-Integration.docx
JRES 2017 - Nantes 13/175.2.1 Option 1: échange des routes clientes de l’instance EVPN avec un peering multi-
hop entre PE
Figure 10 : Instance EVPN/VXLAN transportée dans un L3VPN
5.2.2 Option 2: routes clients échangées via les réflecteurs de routes des NRENS et les
réflecteurs de routes VPN de GEANT
Figure 11 : instance EVPN/VXLAN transportée dans un L3VPN avec usage de réflecteurs de routes VPN
La solution est très flexible, car une fois le L3VPN créé, les 2 data-centers peuvent dynamiquement
créer le tunnel VXLAN et instancier l’EVPN sans intervention du NREN (EVPN on demand).
Elle est plus sécurisée et résout les problèmes de performance liés à la MTU.
Il faut une coordination pour l’adressage de VTEP et le traitement BUM.
Un seul protocole de DCI est nécessaire pour le L2 et le L3.
5.3 EVPN/VXLAN - EVPN/MPLS - EVPN/VXLAN
Il est possible d’interconnecter différents types de réseau de niveau 2 grâce à une instance EVPN.
EVPN/VXLAN étant très pratique pour prolonger un réseau niveau 2 sur un réseau de niveau 3, cela parait
un bon moyen pour interconnecter un réseau de niveau 2 à une instance EVPN/MPLS d’un opérateur. Un
NREN utilisant IP peut ainsi prolonger une instance EVPN (MD-VPN).
Dans cette section, l’interconnexion des instances EVPN/VXLAN et EVPN/MPLS est réalisée en rendant
l’instance EVPN/VXLAN cliente de l’instance EVPN/MPLS et vice-versa (back-to-back). Le plan de
contrôle des deux instances d’EVPN n’est donc pas unifié.
JRES 2017 - Nantes 14/175.3.1 Cas à point de suture interne
Pour interconnecter les 2 types d’instances EVPN, nous pouvons utiliser un lien physique ou un logical-
tunnel interne.
Figure 12 : NREN n’utilisant pas MPLS et pouvant ainsi reposer sur l’infrastructure MD-VPN
5.3.2 Cas à point de suture externe (dans le data-center)
Ici, c’est le data-center qui réalise le passage entre l’encapsulation VXLAN/EVPN et une encapsulation
compatible avec EVPN/MPLS.
Le data-center est client de l’instance EVPN/MPLS.
Figure 13 : Data-center prolongeant ses instances EVPN/VXLAN grâce à MD-VPN
Cette méthode nécessite l’intervention du NREN pour la création et la modification du VPN. On règle ce
problème en connectant le data-center à l’infrastructure MD-VPN : ceci permet au data-center de créer
dynamiquement ses instances EVPN.
JRES 2017 - Nantes 15/175.4 Perspectives
Ces différentes architectures doivent être utilisées en fonction des besoins et cas d’utilisation. Il peut être
intéressant d’utiliser plusieurs techniques pour répondre à un besoin. Par exemple, dans le cas de la mise
en place d’un plan de reprise d’activité entre 2 data-centers, on pourra utiliser un L2VPN (EVPN) pour le
stockage et un L3VPN pour les serveurs.
Par ailleurs, plusieurs architectures vont devenir disponibles, voire le sont depuis peu :
Cisco peut d’ores et déjà réaliser l’interconnexion d’instances EVPN/VXLAN et EVPN/MPLS
grâce à un principe différent de celui du tunnel interne, à savoir, « ré-originer » les routes de
l’instance EVPN-VXLAN. Le routeur, qui raboute les réseaux (stitching), envoie les routes
apprises par EVPN/VXLAN dans EVPN/MPLS avec l’option « next-hop-self » et une éventuelle
réécriture des RD/RT (route distinguisher/route target).
Juniper annonce également qu’il pourra réaliser cette même interconnexion sans recours à un
tunnel interne.
6 Conclusions générales
L’objet de cet article était de montrer les champs d’application d’EVPN (Data Center Interconnect, GIX,
Fabrique de data-center et de campus, L2VPN pour opérateur réseau, L2VPN sur IP). Comme vous avez
pu le constater, le domaine est vaste !
Si pour l’interconnexion de data-centers, le niveau 3 (L3VPN) est certainement la meilleure option, lorsque
les contraintes des applications l’obligent, EVPN est alors une très bonne solution de niveau 2.
EVPN/VXLAN permet de créer des VPN au travers d’un backbone IP.
EVPN bénéficie de nouvelles fonctionnalités par rapport à son prédécesseur VPLS (mobilité de VM, load
balancing par flot, active/active multihoming, gateway distribuée). La capacité d’EVPN à fonctionner sur
IP grâce à VXLAN augmente le nombre de cas d’utilisation et pourrait permettre aux data-centers de fournir
désormais les connexions réseau (VPN) à leurs utilisateurs aussi rapidement que les VM.
Dernier point, les travaux de GEANT ont démontré qu’EVPN fonctionne sur l’infrastructure MD-VPN et
pourra ainsi compléter la gamme de services déployés dans cette infrastructure : L3VPN (IPv4, IPv6),
L2VPN P2P, VPLS.
JRES 2017 - Nantes 16/17Annexe Bibliographie 1. RFC 7432 - BGP MPLS-Based Ethernet VPN. février 2015. 2. RFC 7623 - Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN). Septembre 2015. JRES 2017 - Nantes 17/17
Vous pouvez aussi lire
