Académique Documents
Professionnel Documents
Culture Documents
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.
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
NordunetPE
FunetPE
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,
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é.
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).
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
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
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.
Figure 12 : NREN n’utilisant pas MPLS et pouvant ainsi reposer sur l’infrastructure 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.
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.
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.