Bonjour, Habr. Je suis actuellement responsable du cours "Ingénieur réseau" chez OTUS.
À l'approche du lancement d'un nouveau cycle pour le cours , j'ai préparé une série d'articles sur la technologie VxLAN EVPN.
Il existe une multitude de ressources sur l'utilisation de VxLAN EVPN, donc je souhaite rassembler diverses tâches et pratiques de résolution dans un datacenter moderne.
Dans la première partie de la série sur la technologie VxLAN EVPN, je vais examiner comment organiser la connectivité L2 entre les hôtes sur une infrastructure réseau.
Tous les exemples seront réalisés sur des Cisco Nexus 9000v, configurés en topologie Spine-Leaf. Nous ne nous attarderons pas sur la configuration du réseau Underlay dans cet article.
- Réseau Underlay
- Peering BGP pour l'adressage l2vpn evpn
- Configuration NVE
- Suppr-arp
Réseau Underlay
La topologie utilisée est la suivante :
Attribution des adresses IP à tous les dispositifs :
Spine-1 - 10.255.1.101
Spine-2 - 10.255.1.102
Leaf-11 - 10.255.1.11
Leaf-12 - 10.255.1.12
Leaf-21 - 10.255.1.21
Host-1 - 192.168.10.10
Host-2 - 192.168.10.20Vérifions qu'il y a une connectivité IP entre tous les dispositifs :
Leaf21# sh ip route
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 accessible via deux Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 2/0 ! Leaf-12 accessible via deux Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.21/32, ubest/mbest: 2/0, attached
*via 10.255.1.22, Lo0, [0/0], 00:02:20, local
*via 10.255.1.22, Lo0, [0/0], 00:02:20, direct
10.255.1.101/32, ubest/mbest: 1/0
*via 10.255.1.101, Eth1/4, [110/41], 00:00:06, ospf-UNDERLAY, intra
10.255.1.102/32, ubest/mbest: 1/0
*via 10.255.1.102, Eth1/3, [110/41], 00:00:03, ospf-UNDERLAY, intraVérifions si le domaine VPC a été créé et si les deux commutateurs ont réussi à passer le test de cohérence et que la configuration est identique sur les deux nœuds :
Leaf11# show vpc
vPC domain id : 1
État du pair : l'adjacence des pairs formée correctement
État du keep-alive vPC : le pair est vivant
État de cohérence de la configuration : succès
État de cohérence par VLAN : succès
État de cohérence de type-2 : succès
Rôle vPC : primaire
Nombre de vPC configurés : 0
Passerelle de pair : Désactivée
VLANs exclus en double actif : -
Vérification de cohérence en douceur : Activée
État de récupération automatique : Désactivé
État de restauration différée : Minuteur est éteint. (timeout = 30s)
État de restauration différée SVI : Minuteur est éteint. (timeout = 10s)
Routeur de pair opérationnel Layer3 : Désactivé
État du vPC
----------------------------------------------------------------------------
Id Port État Cohérence Raison VLANs actifs
-- ------------ ------ ----------- ------ ---------------
5 Po5 up succès succès 1Peering BGP
Nous pouvons enfin passer à la configuration du réseau Overlay.
Dans le cadre de l'article, il est nécessaire d'organiser un réseau entre les hôtes, comme indiqué sur le schéma ci-dessous :
Pour configurer l'Overlay réseau, il est nécessaire d'activer BGP sur les commutateurs Spine et Leaf avec le support de la famille l2vpn evpn :
feature bgp
nv overlay evpnEnsuite, il faut configurer le peering BGP entre Leaf et Spine. Pour simplifier la configuration et optimiser la diffusion des informations de routage, nous configurons Spine en tant que Route-Reflector server. Nous inscrirons tous les Leaf dans la configuration via des modèles afin d'optimiser la configuration.
Ainsi, la configuration sur Spine est la suivante :
router bgp 65001
template peer LEAF
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
route-reflector-client
neighbor 10.255.1.11
inherit peer LEAF
neighbor 10.255.1.12
inherit peer LEAF
neighbor 10.255.1.21
inherit peer LEAFLa configuration sur le commutateur Leaf ressemble également :
router bgp 65001
template peer SPINE
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
neighbor 10.255.1.101
inherit peer SPINE
neighbor 10.255.1.102
inherit peer SPINESur Spine, nous vérifierons le peering avec tous les commutateurs Leaf :
Spine1# sh bgp l2vpn evpn summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.255.1.11 4 65001 7 8 6 0 0 00:01:45 0
10.255.1.12 4 65001 7 7 6 0 0 00:01:16 0
10.255.1.21 4 65001 7 7 6 0 0 00:01:01 0Comme nous le voyons, il n'y a eu aucun problème avec BGP. Passons à la configuration de VxLAN. La configuration suivante sera effectuée uniquement du côté des commutateurs Leaf. Spine agit uniquement comme le cœur du réseau et se charge uniquement du transfert de trafic. Tout le travail d'encapsulation et de définition du chemin se fait uniquement sur les commutateurs Leaf.
Configuration NVE
NVE — interface virtuelle réseau
Avant de commencer la configuration, introduisons un peu de terminologie :
VTEP — Virtual Tunnel End Point, un dispositif sur lequel commence ou se termine un tunnel VxLAN. VTEP n'est pas nécessairement un appareil réseau. Un serveur prenant en charge la technologie VxLAN peut également agir en tant que tel. Dans notre topologie, tous les commutateurs Leaf sont des VTEP.
VNI — Virtual Network Index — identifiant de réseau au sein de VxLAN. On peut faire une analogie avec VLAN. Cependant, il existe certaines différences. Lors de l'utilisation d'une usine, les VLAN deviennent uniques uniquement au sein d'un commutateur Leaf et ne sont pas transmis sur le réseau. Mais chaque VLAN peut avoir un numéro VNI associé, qui est déjà transmis sur le réseau. Comment cela se présente et comment cela peut être utilisé sera examiné ci-après.
Activer la fonctionnalité pour travailler avec la technologie VxLAN et la possibilité d'associer des numéros VLAN avec le numéro VNI :
feature nv overlay
feature vn-segment-vlan-basedNous allons configurer l'interface NVE, qui est responsable du fonctionnement de VxLAN. Cette interface est justement responsable de l'encapsulation des trames dans les en-têtes VxLAN. On peut faire une analogie avec l'interface Tunnel pour le fonctionnement de GRE :
interface nve1
no shutdown
host-reachability protocol bgp ! nous utilisons BGP pour transmettre les informations de routage
source-interface loopback0 ! interface à partir de laquelle nous envoyons des paquets loopback0Sur le commutateur Leaf-21, tout se crée sans problème. Cependant, si nous vérifions la sortie de la commande show nve peers, elle sera vide. Il est nécessaire de revenir à la configuration de VPC. Nous voyons que Leaf-11 et Leaf-12 fonctionnent en paire et sont regroupés dans un domaine VPC. Cela entraîne la situation suivante :
Host-2 envoie une trame vers Leaf-21, afin qu'il puisse la transmettre sur le réseau vers Host-1. Cependant, Leaf-21 constate que l'adresse MAC de Host-1 est accessible via deux VTEP. Comment Leaf-21 doit-il agir dans ce cas ? Cela signifie qu'il pourrait y avoir une boucle dans le réseau.
Pour résoudre cette situation, nous devons faire en sorte que Leaf-11 et Leaf-12 agissent également comme un seul dispositif dans le cadre de la fabrique. Cela se résout assez simplement. Sur l'interface Loopback à partir de laquelle nous construisons le tunnel, nous ajoutons une adresse secondaire. L'adresse secondaire doit être identique sur les deux VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryAinsi, du point de vue des autres VTEP, nous obtenons la topologie suivante :
C'est-à-dire que maintenant le tunnel sera construit entre l'adresse IP de Leaf-21 et l'IP virtuelle entre Leaf-11 et Leaf-12. Maintenant, il n'y aura plus de problèmes pour étudier l'adresse MAC des deux dispositifs et le trafic peut passer d'un VTEP à l'autre. Qui des deux VTEP traitera le trafic est déterminé par la table de routage sur le Spine :
Spine1# sh ip route
10.255.1.10/32, ubest/mbest: 2/0
*via 10.255.1.11, Eth1/1, [110/41], 1d01h, ospf-UNDERLAY, intra
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra
10.255.1.11/32, ubest/mbest: 1/0
*via 10.255.1.11, Eth1/1, [110/41], 1d22h, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 1/0
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intraComme on peut le voir ci-dessus, l'adresse 10.255.1.10 est accessible via deux Next-hop.
À ce stade, nous avons compris la connectivité de base. Passons à la configuration de l'interface NVE :
Nous allons immédiatement activer le Vlan 10 et l'associer au VNI 10000 sur chaque Leaf pour les hôtes. Configurons un tunnel L2 entre les hôtes.
vlan 10 ! Activation de VLAN sur tous les VTEP connectés aux hôtes nécessaires
vn-segment 10000 ! Associe le VLAN au numéro VNI
interface nve1
member vni 10000 ! Ajoute le VNI 10000 pour le fonctionnement via l'interface NVE. pour encapsulation en VxLAN
ingress-replication protocol bgp ! Indique que nous utilisons BGP pour la propagation des informations sur l'hôteVérifions maintenant les pairs nve et la table pour BGP EVPN :
Leaf21# sh nve peers
Interface Peer-IP État Type d'apprentissage Durée Mac-Router
--------- --------------- ----- --------- -------- -----------------
nve1 10.255.1.10 Up CP 00:00:41 n/a ! Nous voyons que le pair est accessible depuis l'adresse secondaire
Leaf11# sh bgp l2vpn evpn
Réseau Prochaine Hop Métrique LocPrf Poids Chemin
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! De qui est venu ce l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]\/88 ! EVPN route-type 3 - indique notre voisin qui connaît aussi l'l2VNI10000
10.255.1.10 100 32768 i
*>i[3]:[0]:[32]:[10.255.1.20]\/88
10.255.1.20 100 0 i
* i 10.255.1.20 100 0 i
Route Distinguisher: 10.255.1.21:32777
* i[3]:[0]:[32]:[10.255.1.20]\/88
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iNous observons ci-dessus que les routes ne sont que des EVPN route-type 3. Ce type de routes parle du pair (Leaf), mais où sont nos hôtes ?
Le problème est que les informations sur les adresses MAC des hôtes sont transmises via EVPN route-type 2
Pour voir nos hôtes, il est nécessaire de configurer EVPN route-type 2 :
evpn
vni 10000 l2
route-target import auto ! Dans le cadre de cet article, nous utilisons un numéro automatique pour le route-target
route-target export autoFaisons un ping de Host-2 à Host-1 :
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 octets de données
36 octets de 192.168.10.2: Destination Host Unreachable
Request 0 timed out
64 octets de 192.168.10.1: icmp_seq=1 ttl=254 time=215.555 ms
64 octets de 192.168.10.1: icmp_seq=2 ttl=254 time=38.756 ms
64 octets de 192.168.10.1: icmp_seq=3 ttl=254 time=42.484 ms
64 octets de 192.168.10.1: icmp_seq=4 ttl=254 time=40.983 msEt ci-dessous, nous pouvons voir que dans la table BGP, des route-type 2 avec l'adresse MAC des hôtes — 5001.0007.0007 et 5001.0008.0007 sont apparus
Leaf11# sh bgp l2vpn evpn
Réseau Prochain saut Métro LocPrf Poids Chemin
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216 ! type de route evpn 2 et adresse mac de l'hôte 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]\/216 ! type de route evpn 2 et adresse mac de l'hôte 2
* i 10.255.1.20 100 0 i
*>l[3]:[0]:[32]:[10.255.1.10]\/88
10.255.1.10 100 32768 i
Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]\/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iVous pouvez ensuite consulter des informations détaillées sur la mise à jour, dans laquelle nous avons obtenu des informations sur le MAC de l'hôte. Ci-dessous, la sortie de la commande n'est pas complète.
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
Informations sur la table de routage BGP pour VRF par défaut, famille d'adresses L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! Update envoyé avec MAC de l'hôte. Pas une adresse VPC virtuelle, mais une adresse Leaf
Entrée de la table de routage BGP pour [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216,
version 1507
Chemins: (2 disponibles, meilleur #2)
Drapeaux: (0x000202) (high32 00000000) sur xmit-list, n'est pas dans l2rib\/evpn, n'est pas en HW
Type de chemin: interne, chemin valide, pas meilleur raison: adresse du voisin, pas de prochain saut étiqueté
AS-Path: AUCUN, chemin provenant de l'intérieur de l'AS
10.255.1.10 (métrique 81) de 10.255.1.102 (10.255.1.102) ! avec qui nous construisons exactement le tunnel VxLAN
Origine IGP, MED non défini, localpref 100, poids 0
Étiquette reçue 10000 ! Numéro VNI associé au VLAN dans lequel se trouve l'hôte
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Ici, on voit que le RT s'est formé automatiquement sur la base des numéros AS et VNI
Initiateur: 10.255.1.11 Liste de clusters: 10.255.1.102Voyons à quoi ressemblent les trames lorsqu'elles traversent la fabrique :
Suppress-ARP
Parfait, la connexion L2 entre les hôtes est établie et nous pourrions en rester là. Cependant, ce n'est pas si simple. Tant que nous avons peu d'hôtes, il n'y aura pas de problème. Mais imaginons une situation où nous avons des centaines ou des milliers d'hôtes. Quel problème pourrions-nous rencontrer ?
Ce problème est le trafic BUM (Broadcast, Unknown Unicast, Multicast). Dans cet article, nous examinerons une option pour lutter contre le trafic broadcast.
Le principal générateur de Broadcast dans les réseaux Ethernet est en fait les hôtes eux-mêmes via le protocole ARP.
Sur Nexus, le mécanisme suivant a été mis en œuvre pour lutter contre les requêtes ARP : suppress-arp.
Le fonctionnement de cette fonctionnalité est le suivant :
- L'hôte-1 envoie une requête APR à l'adresse Broadcast de son réseau.
- La requête parvient au commutateur Leaf et au lieu de transmettre cette requête plus loin dans la fabrique vers l'hôte-2 — le Leaf répond lui-même et indique l'IP et le MAC nécessaires.
Ainsi, la requête Broadcast n'est pas passée dans le fabric. Mais comment cela peut-il fonctionner si Leaf ne connaît que l'adresse MAC ?
C'est assez simple, le type de route EVPN 2 peut transmettre non seulement l'adresse MAC, mais aussi l'association MAC/IP. Pour cela, il est nécessaire de configurer une adresse IP dans le VLAN sur Leaf. La question se pose, quelle adresse IP attribuer ? Sur Nexus, il est possible de créer une adresse distribuée (identique) sur tous les commutateurs :
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! nous définissons le mac virtuel pour créer une passerelle distribuée entre tous les commutateurs
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! nous définissons la même IP sur tous les Leaf
fabric forwarding mode anycast-gateway ! nous indiquons d'utiliser le mac virtuelAinsi, du point de vue des hôtes, le réseau apparaîtra comme suit :
Vérifions BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
Réseau Prochain saut Métier LocPrf Poids Chemin
Identificateur de route : 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
10.255.1.21 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.10 100 0 i
* i 10.255.1.10 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
Identificateur de route : 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
*>i 10.255.1.20 100 0 iDe la sortie de la commande, on voit que dans le type de route EVPN 2, en plus de la MAC, nous voyons maintenant aussi l'adresse IP de l'hôte.
Revenons à la configuration de suppress-arp. Cette option est activée pour chaque VNI séparément :
interface nve1
member vni 10000
suppress-arpEnsuite, il y a une certaine complexité :
- Pour que cette fonctionnalité fonctionne, il est nécessaire d'avoir de l'espace dans la mémoire TCAM. Je vais donner un exemple de configuration pour suppress-arp :
hardware access-list tcam region arp-ether 256Cette configuration nécessitera un double-large. Ainsi, si vous attribuez 256, il faut libérer 512 dans la TCAM. La configuration TCAM dépasse le cadre de cet article, car la configuration TCAM dépend uniquement de la tâche qui vous est assignée et peut varier d'un réseau à l'autre.
- L'implémentation de suppress-arp doit être réalisée sur tous les commutateurs Leaf. Cependant, des difficultés peuvent survenir lors de la configuration sur des paires Leaf situées dans un domaine VPC. En cas de modification de TCAM, la cohérence entre les paires sera compromise et un nœud peut tomber en panne. De plus, pour appliquer cette configuration, un redémarrage de l'appareil peut être nécessaire après la modification de TCAM.
En conséquence, il est important de bien réfléchir à la pertinence de cette configuration dans votre situation pour une usine en production.
Nous en restons là pour cette première partie du cycle. Dans la prochaine partie, nous aborderons le routage à travers l'usine VxLAN en séparant les réseaux par différents VRF.
Et maintenant, je vous invite tous à , au cours duquel je vais détailler le programme. Les 20 premiers participants inscrits à ce webinaire recevront un certificat de réduction par e-mail dans les 1 à 2 jours suivant la diffusion.
Source : habr.com
