Les architectures DC (Datacenter) de nouvelle génération sont conçues en topologie CLOS Fabric « Leaf & Spine », les protocoles VxLAN et EVPN sont élus comme standards par un grand nombre de constructeurs réseau (Cisco, Arista, Juniper, Cumulus, ..) pour assurer le fonctionnement de cette Fabric :

  • VxLAN est un protocole d’encapsulation conçu pour mieux répondre aux besoins DC (RFC 7348)
  • EVPN (Ethernet VPN) est une extension du protocole BGP (AFI : 25, SAFI: 70) qui permet de fournir une complète isolation et segmentation de niveau 2 et 3.

Dans cette série d’articles, nous allons nous intéresser de près aux opportunités offertes par ces deux protocoles pour répondre plus simplement et plus facilement à une grande partie des contraintes rencontrées sur les réseaux DC traditionnels, le schéma ci-dessous décrit succinctement la cible HLD (High Level Design) de notre DC de nouvelle génération :

Infrastructure DC en VXLAN-EVPN

Un tenant est une segmentation logique du réseau destinée à regrouper des ressources appartenant à un même domaine, il peut s’agir :

  • Clients (commanditaires, filiales, ..) avec des environnements isolés les uns des autres.
  • Applications (ou DMZ) avec un niveau de sensibilité et d’exposition bien défini
  • Infrastructures spécifiques (exemple sauvegarde) nécessitant une isolation particulière

En VxLAN/EVPN (mode symetric IRB), un tenant correspond généralement à une VRF mappée sur une L3VNI, cette VRF héberge un ou plusieurs L2VNI (VLAN) configurés sur plusieurs LEAFs comme représenté dans le schéma ci-après :

VxLAN-EVPN : Architecture cible

Dans cette série d’articles, notre DC est composé de quatre tenants :

  • Un tenant VERT qui héberge deux VMs (10.10.1.1/24 et 10.10.2.1/24) sur les Leafs 101 et 103
  • Un tenant BLEU qui héberge deux VMs (10.20.1.1/24 et 10.20.2.1/24) sur les Leafs 102 et 103
  • Un tenant ROUGE qui héberge une VM (10.30.1.1/24) sur le Leaf102
  • Un tenant ORANGE (partagé) qui héberge deux VM (10.40.1.1/24 et 10.40.2.1/24)

Les objectifs recherchés de notre DC de nouvelle génération sont :

  • Objectif 1 : Les communications intra-Tenant ne sont pas filtrées et sont réalisées à travers la Fabric VxLAN-EVPN, ce qui permet une meilleure gestion des flux Est-Ouest et aussi ne pas pénaliser les performances réseau par l’implémentation des fonctionnalités natives à VxLAN/EVPN (routage distribué (Anycast GW), gestion du flooding (ARP Suppression), ..)
  • Objectif 2 :  Toutes les communications entre les tenants (VERT, BLEU et ROUGE) sont filtrées et inspectées à travers un cluster de FW/IPS installé sur le LEAF104 (Service Leaf)
  • Objectif 3 : Toutes les communications des tenants (VERT, BLEU et ROUGE) avec le tenant ORANGE sont autorisées, il s’agit en effet d’un tenant qui héberge des ressources partagés (exemple : services d’infrastructures (DNS, NTP, SMTP, ..), services de sauvegarde (robot), ..)
  • Objectif 4 : Les communications entre les Tenants (BLEU et VERT) et le WAN sont filtrées à travers le FW (Tenants sensibles)
  • Objectif 5 : Les communications entre le Tenant ROUGE et le WAN ne sont pas filtrées (Tenant non sensible)

Ces objectifs sont décrits dans le schéma ci-après :

VxLAN-EVPN : Politique de routage

Par ailleurs, pour mieux illustrer ces concepts d’architecture, nous allons pour chaque objectif décrire aussi les lignes de configuration essentielles (avec automatisation Ansible) ainsi que les vérifications nécessaires pour vérifier le bon fonctionnement.

Enfin, pour l’implémentation technique, le matériel utilisé est celui du constructeur Arista, cependant, les concepts d’architectures restent aussi valables pour les autres constructeurs (Cisco, Juniper, Cumulus, ..) sous réserve de la bonne implémentation du VxLAN-EVPN.

LEAF101#show version
cEOSLab
Hardware version:
Serial number:
Hardware MAC address: 067d.b6d0.49e6
System MAC address: 067d.b6d0.49e6
Software image version: 4.25.1F-20005270.4251F (engineering build)
Architecture: x86_64
Internal build version: 4.25.1F-20005270.4251F
Internal build ID: 37a9ea6d-2c81-487d-9c86-579348318c0a
cEOS tools version: 1.1
Kernel version: 5.4.0-52-generic
Uptime: 0 weeks, 0 days, 8 hours and 29 minutes
Total memory: 132012876 kB
Free memory: 121567820 kB

Maintenant, il ne reste plus qu’à détailler l’architecture cible pour atteindre ces objectifs ambitieux, plusieurs articles seront nécessaires mais nous allons comme d’habitude y aller doucement en expliquant étape par étape, restez connecter et suivez nous sur notre blog !

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.

Author

Hicham est un architecte réseau avec plus de 22 ans d’expérience dans le domaine des réseaux et essentiellement sur les environnements Cisco, il dispose d’un diplôme d’ingénieur d’état dans le domaine des Réseaux et Télécoms et aussi de quatre certifications CCIE dans les domaines (Routing & Switching, Security, Service Provider et Datacenter). Durant son expérience, Hicham est intervenu sur des projets importants et complexes chez les opérateurs ainsi que les grandes entreprises sur différents domaines (LAN, WAN, DATACENTER), il réalise souvent des audits sur des architectures complexes pour les optimiser ainsi que des formations auprès de ses clients afin de démystifier les technologies pour une meilleure compréhension et simplification de l’exploitation au quotidien. Hicham est contributeur du blog MHD Experts et joignable à l’adresse : hicham.tahri@mhd-experts.com

4 Comments

  1. Merci beaucoup pour cette première partie très intéressante 🙂

Write A Comment