Présentation de l’architecture de dorsale réduite avec le multihébergement EVPN

Ce NCE montre comment déployer une architecture de cœur de réseau réduit pour deux centres de données dotés chacun de deux commutateurs de cœur de réseau QFX5120 et de deux commutateurs ToR de couche 2 déployés en tant que Virtual Chassis. Les datacenters sont connectés les uns aux autres via les équipements de cœur de réseau grâce à l’interconnexion du datacenter de couche 3 (DCI). Utilisez le multihébergement EVPN pour multihéberger les commutateurs ToR vers les périphériques de cœur de réseau. Les serveurs sont multirésidents sur les commutateurs ToR. La figure 1 montre l’architecture de dorsale réduite terminée.

Figure 1 : architecture dorsale réduite avec multihébergement EVPN

Pour la prise en charge du multicast, nous proposons :

• Multicast de couche 3 dans une conception QFX5120 collapsed spine à l’aide d’EVPN OISM avec des domaines de pont symétriques.

• Surveillance IGMPv2 multicast de couche 2 dans EVPN-VXLAN à l’aide de :

  • Routes EVPN Selective Multicast Ethernet Tag (SMET) de type 6

  • Les routes de synchronisation de jointure et de sortie EVPN (type 7 et type 8) lorsqu’un récepteur multicast est multihébergé au niveau de la couche 2 vers les périphériques de cœur de réseau réduits à l’aide d’un ESI-LAG.

Dans une architecture Spine réduite, les équipements Spine font office de périphériques Spine et Leaf. Étant donné que les TdR sont de couche 2 uniquement et ne prennent pas en charge VXLAN, ils n’agissent pas comme des équipements de branche. L’activité normale des équipements leaf est gérée, ou réduite, sur les équipements spine, ce qui signifie que VXLAN n’est requis que sur les équipements spine. La dorsale réduite fonctionne comme une passerelle de couche 3 et gère le trafic entre les VXLAN à l’aide d’interfaces IRB.

Dans un datacenter hérité avec une architecture spine réduite, les commutateurs ToR doivent être connectés aux commutateurs spine avec des groupes d’agrégation de liens multichâssis (MC-LAG) pour améliorer la résilience du réseau. MC-LAG fournit une redondance au niveau du nœud et au niveau de la liaison. Traditionnellement, les commutateurs centraux de ces datacenters utilisent le protocole ICCP (Inter-Chassis Control Protocol) pour fournir la fonctionnalité MC-LAG. Cependant, MC-LAG avec ICCP :

• Il s’agit d’une technologie propriétaire.

• Impossible d’étirer efficacement la couche 2 entre les centres de données.

• Ne prend pas en charge plus de deux commutateurs centraux.

EVPN est une solution de multihébergement standardisée qui s’étend horizontalement sur deux commutateurs de cœur de réseau ou plus pour offrir une résilience et une bande passante accrues en cas de défaillance du cœur de réseau. Le multihébergement EVPN, également connu sous le nom d’ESI-LAG, fournit la fonctionnalité MC-LAG pour les commutateurs ToR de couche 2 et les serveurs de cette architecture sans les inconvénients du MC-LAG basé sur ICCP.

Une architecture de cœur de réseau réduit, où les commutateurs ToR sont multirésidents sur les dorsales, est une architecture de centre de données qui prend en charge les anciens commutateurs ToR lorsqu’ils ne prennent pas en charge EVPN-VXLAN. La figure 2 illustre une architecture spine réduite avec deux commutateurs spine pour plus de simplicité et un périphérique ToR implémenté en tant que Virtual Chassis (voir Présentation de Virtual Chassis).

Figure 2 : multihébergement EVPN des commutateurs ToR

Les superpositions de réseau sont créées en encapsulant le trafic et en le canalisant vers un réseau physique. Le protocole de tunnelisation VXLAN encapsule les trames Ethernet de couche 2 dans des paquets UDP de couche 3. VXLAN permet d’établir des sous-réseaux ou des segments virtuels de couche 2 qui peuvent s’étendre sur le réseau physique de couche 3 sous-jacent.

Dans un réseau de superposition VXLAN, chaque sous-réseau ou segment de couche 2 est identifié de manière unique par un identifiant de réseau virtuel (VNI). Un VNI segmente le trafic de la même manière qu’un ID VLAN. Comme c’est le cas pour les VLAN, les terminaux d’un même réseau virtuel peuvent communiquer directement entre eux. Les points de terminaison de différents réseaux virtuels nécessitent un équipement qui prend en charge le routage entre VNI.

L’entité responsable de l’encapsulation et de la décapsulation VXLAN s’appelle un point de terminaison de tunnel VXLAN (VTEP). Chaque VTEP se voit généralement attribuer une adresse IP unique.

EVPN est l’une des extensions de BGP qui permet au réseau de transporter les informations d’accessibilité de la couche réseau (NLRI) telles que les adresses MAC de couche 2 et les adresses IP de couche 3. Cette technologie de plan de contrôle utilise MP-BGP pour la distribution des adresses MAC et IP des terminaux, où les adresses MAC sont traitées comme des routes. L’EVPN permet aux équipements faisant office de VTEP d’échanger entre eux des informations sur l’accessibilité de leurs terminaux.

L’EVPN assure le transfert multichemin et la redondance via un modèle entièrement actif. La couche d’accès peut se connecter à deux équipements de cœur de réseau ou plus et transférer le trafic sur toutes les liaisons. En cas de défaillance d’une liaison d’accès ou d’un équipement Spine, le trafic est acheminé de la couche d’accès vers la couche de cœur de réseau en utilisant les liens actifs restants. Pour le trafic dans l’autre sens, les équipements de cœur de réseau distants mettent à jour leurs tables de transfert pour envoyer le trafic vers les équipements de cœur de réseau actifs restants connectés au segment Ethernet multirésident.

Cette architecture utilise VXLAN comme protocole d’encapsulation du plan de données superposé et MP-BGP avec signalisation EVPN comme protocole de plan de contrôle superposé.

• Superposition du plan de données
• Superposition du plan de contrôle

Superposition du plan de données

Cette architecture utilise VXLAN comme protocole d’encapsulation du plan de données overlay sur les commutateurs de cœur de réseau réduits. Un commutateur qui fonctionne comme une passerelle VXLAN de couche 2 ou de couche 3 agit comme le point de terminaison de tunnel VXLAN et peut encapsuler et décapsuler les paquets de données.

Dans un déploiement de centre de données unique avec deux commutateurs centraux, la superposition VXLAN entre les commutateurs centraux est utilisée pour le trafic entre les deux appareils. Par exemple, si un serveur monohoming est connecté à l’un des équipements de cœur de réseau, la superposition VXLAN achemine le trafic vers l’autre équipement Spine, soit par conception, soit en cas de défaillance de liaison.

Comme illustré sur la figure ci-dessous, le serveur DHCP est monohoming sur le cœur de réseau 1. Le trafic du client DHCP peut être envoyé vers Spine 2 en raison du partage de charge. Spine 2 envoie le trafic au serveur DHCP via la superposition VXLAN avec Spine 1.

Figure 3 : topologie de superposition du plan de données

Superposition du plan de contrôle

Dans cet exemple, MP-BGP avec signalisation EVPN fait office de protocole de plan de contrôle de superposition. Les commutateurs de cœur de réseau établissent des sessions IBGP entre eux. La figure 4 illustre la topologie du réseau superposé.

Figure 4 : topologie de superposition du plan de contrôle

Dans les centres de données plus petits, il n’y a pas de couche super spine, de sorte que les commutateurs spine sont directement connectés les uns aux autres. Les commutateurs de cœur de réseau peuvent utiliser un protocole de routage dynamique dans l’underlay. Dans le réseau sous-jacent, la principale exigence est que tous les équipements centraux disposent d’une accessibilité en bouclage. Vous pouvez utiliser n’importe quel protocole de routage de couche 3 pour échanger des adresses de bouclage entre les équipements centraux et dorsaux.

Dans cet exemple, nous utilisons EBGP comme protocole de routage sous-jacent entre les commutateurs de cœur de réseau. EBGP offre des avantages tels qu’un meilleur filtrage des préfixes, une meilleure ingénierie du trafic et un meilleur balisage du trafic. La figure 5 illustre la topologie du réseau sous-jacent Spine

Figure 5 : topologie de sous-couche dorsale

Étant donné que les commutateurs ToR ne font pas partie de la fabric EVPN-VXLAN et fonctionnent uniquement au niveau de la couche 2, vous pouvez les implémenter en tant que Virtual Chassis. Dans cet exemple, les commutateurs ToR sont déployés en tant que Virtual Chassis à deux membres.

Les liaisons montantes entre les commutateurs ToR et les commutateurs spine sont des ports LAG trunk de couche 2 avec des VLAN pertinents pour le commutateur ToR. Chaque Virtual Chassis est multihébergé sur deux commutateurs centraux à l’aide du multihébergement EVPN. La figure 6 illustre la topologie d’un Virtual Chassis en tant qu’équipement ToR multihébergé sur les deux équipements centraux. Pour des raisons de redondance et d’amélioration de la résilience, cette figure montre des connexions spine à ToR Virtual Chassis qui sont liées à différents membres de Virtual Chassis, de sorte que le périphérique Virtual Chassis ToR reste accessible même si l’un des membres de Virtual Chassis tombe en panne.

Figure 6 : topologie du commutateur ToR

Les connexions spine to ToR Virtual Chassis dans les liaisons Ethernet agrégées de multihébergement peuvent également inclure des liens vers le même membre Virtual Chassis, c’est ainsi que cet exemple de configuration réseau est configuré. La Figure 7 montre une vue logique de la topologie de multihébergement correspondant à la configuration de ce document.

Figure 7 : topologie de multihébergement EVPN d’un commutateur ToR dans cet exemple de configuration réseau

Dans cet exemple, les serveurs de centre de données sont multirésidents sur les commutateurs ToR déployés en tant que Virtual Chassis. La connectivité serveur peut être répartie sur les deux commutateurs ToR avec LAG.

Figure 8 : topologie ToR avec des serveurs multirésidents

Dans cet exemple, nous déployons des équipements de sécurité SRX dans un cluster de châssis qui est connecté aux équipements de cœur de réseau pour fournir une sécurité avancée. Dans un cluster de châssis, deux pare-feu SRX Series fonctionnent comme un seul appareil pour assurer la redondance des appareils, des interfaces et des niveaux de service. Les fichiers de configuration et les états de session d’exécution dynamiques sont synchronisés entre les pare-feu SRX Series d’un cluster de châssis. Utilisez un cluster de châssis SRX pour :

• Évitez les défaillances d’un seul appareil entraînant une perte de connectivité.

• Assurez une haute disponibilité entre les équipements de sécurité lors de la connexion des filiales et des sites distants aux bureaux plus importants de l’entreprise.

• Assurez la connectivité en cas de défaillance d’un appareil ou d’une liaison.

Figure 9 : implémentation d’un cluster de châssis SRX