Bonjour, Habr. Je continue ma série d'articles sur la technologie VxLAN EVPN, qui ont été rédigés spécialement pour le lancement du cours d'OTUS. Aujourd'hui, nous examinerons une partie intéressante des problèmes — le routage. Aussi banal que cela puisse paraître, dans le cadre du fonctionnement d'une usine réseau, tout cela peut ne pas être si simple.
Dans la dernière partie, nous avons obtenu un domaine de diffusion, construit sur l'usine réseau via le Nexus 9000v. Cependant, ce n'est pas tout le spectre des problèmes à résoudre dans le cadre du réseau du centre de données. Aujourd'hui, nous aborderons le problème suivant — le routage entre les réseaux ou entre les VNI.
Je rappelle que nous utilisons une topologie Spine-Leaf :
Pour commencer, examinons comment le routage se produit et quelles sont les particularités.
Pour simplifier la compréhension, nous allons réduire le schéma logique et ajouter un VNI 20000 pour Host-2. Cela donne au final :
Comment dans ce cas peut-on transférer le trafic d'un hôte à un autre ?
Il existe deux options :
- Conserver l'information sur tous les VNI sur tous les commutateurs Leaf, alors tout le routage se fera sur le premier Leaf du réseau ;
- Utiliser un VNI L3 spécialement dédié
La première méthode est simple et pratique. Puisqu'il suffit de faire entrer tous les VNI sur tous les commutateurs Leaf. Cependant, introduire des centaines ou des milliers de VNI sur tous les Leaf ne semble déjà plus être une tâche simple. C'est pourquoi cette méthode est plutôt rarement utilisée.
Examinons la deuxième méthode, qui est plus intéressante et un peu plus complexe, mais qui offre une plus grande flexibilité dans la configuration de l'usine.
Ajoutons à la topologie le VRF "PROD". Nous ajouterons l'interface VLAN 10 sur les Leaf-11/12 et l'interface VLAN 20 sur le Leaf-21. Le VLAN 20 est associé au VNI 20000.
vrf context PROD
rd auto ! Le Route Distinguisher n'est pas essentiel et nous pouvons utiliser celui généré automatiquement
address-family ipv4 unicast
route-target both auto ! nous indiquons le Route-target avec lequel les préfixes seront importés et exportés vers/de VRF
vlan 20
vn-segment 20000
interface nve 1
member vni 20000
ingress-replication protocol bgp
interface Vlan10
no shutdown
vrf member PROD
ip address 192.168.20.1/24
fabric forwarding mode anycast-gatewayPour utiliser le L3 VNI, il est nécessaire de créer un nouveau VLAN, de l'associer à un nouveau VNI. Le nouveau VNI doit être identique sur tous les Leaf intéressés par les informations sur les VLAN 10 et 20.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Créons un L3 VNI
vrf context PROD
vni 99000 ! Nous associons le L3 VNI à un VRF donnéAinsi, le schéma sera présenté comme suit :
Il reste juste une petite chose à faire : ajouter une autre interface — interface vlan 99 dans le VRF PROD.
interface Vlan99
no shutdown
vrf member PROD
ip forward ! L'interface ne doit pas avoir d'IP. Utilisée uniquement pour le transfert de paquets entre Leaf.Au final, la logique de passage de trame de Host-1 à Host-2 est la suivante :
- La trame envoyée par Host-1 arrive sur Leaf dans le VLAN 10, qui est associé au VNI 10000 ;
- Leaf vérifie où se trouve l'adresse de destination et la trouve via L3 VNI sur le deuxième commutateur Leaf ;
- Dès que le chemin vers l'adresse de destination est trouvé, Leaf encapsule la trame dans un en-tête avec le L3VNI nécessaire 99000 — et l'envoie vers le deuxième Leaf ;
- Le deuxième commutateur Leaf reçoit des données du L3VNI 99000. Il extrait la trame d'origine et la transfère vers le L2VNI nécessaire 20000 et ensuite vers le VLAN 20.
Le résultat d'un tel fonctionnement du L3VNI élimine la nécessité de garder sur tous les commutateurs Leaf des informations sur tous les VNI présents dans le réseau.
Ainsi, lorsque nous envoyons du trafic de Host-1 à Host-2, le paquet est encapsulé à l'intérieur du VxLAN avec un nouveau VNI — 99000 :
Il reste à comprendre comment exactement Leaf-1 apprend le MAC adresse d'un autre VNI. Cela se fait également à l'aide de EVPN route-type 2 (MAC/IP).
Ci-dessous est montré le processus de propagation de la route concernant le préfixe situé dans un autre VNI :
C'est-à-dire que les adresses obtenues à partir du VNI 20000 ont deux RT.
Je rappelle que les routes obtenues à partir de la mise à jour se retrouvent dans la table BGP avec le Route-target indiqué dans les paramètres du VRF (le processus est un peu plus complexe, mais dans le cadre de cet article, nous ne allons pas approfondir).
Le RT lui-même est formé selon la formule : AS:VNI (s'il utilise le mode automatique).
Exemple de formation du RT en mode automatique et manuel :
vrf context PROD
address-family ipv4 unicast
route-target import auto - mode de fonctionnement automatique
route-target export 65001:20000 - mode de formation manuelle du RTAinsi, il est clair que les préfixes d'un autre VNI ont deux valeurs RT.
L'une d'elles est 65001:99000 — un L3 VNI supplémentaire. Puisque ce VNI est identique sur tous les Leaf et tombe sous nos règles d'importation dans les paramètres du VRF — le préfixe entre dans la table BGP, ce que l'on peut voir dans la sortie :
sh bgp l2vpn evpn
Réseau Prochain saut Métrique 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
10.255.1.10 100 32768 i
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[32]:[192.168.10.10]/272
10.255.1.10 100 32768 i
*>l[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 32768 i
Route Distinguisher: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]/272 ! Préfixe obtenu à partir de VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iEn examinant de plus près la mise à jour reçue, il est visible que ce préfixe a deux RT :
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
Informations sur la table de routage BGP pour VRF par défaut, famille d'adresses L2VPN EVPN
Route Distinguisher: 10.255.1.21:32787
Entrée de la table de routage BGP pour [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]/272, version 5164
Chemins: (2 disponibles, meilleur #2)
Flags: (0x000202) (high32 00000000) sur la liste d'envoi, n'est pas dans l2rib/evpn, n'est pas en HW
Type de chemin : interne, le chemin est valide, pas de meilleure raison : Adresse du voisin, pas de prochain saut étiqueté
AS-Path: AUCUN, chemin provenant d'interne à l'AS
10.255.1.20 (métrique 81) de 10.255.1.102 (10.255.1.102)
Origine IGP, MED non défini, pref local 100, poids 0
Étiquette reçue 20000 99000 ! Deux étiquettes pour faire fonctionner VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Deux valeurs Route-target, sur la base desquelles ce préfixe a été ajouté
MAC du routeur : 5001.0005.0007
Originateur : 10.255.1.21 Liste des clusters : 10.255.1.102Dans la table de routage sur Leaf-1, on peut également observer le préfixe 192.168.20.20/32 :
Leaf11# sh ip route vrf PROD
192.168.10.0/24, ubest/mbest: 1/0, attaché
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, direct
192.168.10.1/32, ubest/mbest: 1/0, attaché
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, local
192.168.10.10/32, ubest/mbest: 1/0, attaché
*via 192.168.10.10, Vlan10, [190/0], 01:27:22, hmm
192.168.20.20/32, ubest/mbest: 1/0 ! Adresse Host-2
*via 10.255.1.20fault, [200/0], 01:20:20, bgp-65001, interne, tag 65001 ! Accessible via Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Via VNI 99000Avez-vous remarqué l'absence du préfixe principal 192.168.20.0/24 dans la table de routage ?
Exactement, il n'y est pas. Cela signifie que les Leaf éloignés reçoivent des informations uniquement sur les hôtes présents dans votre réseau. Et c'est un comportement correct. Plus haut, toutes les mises à jour montrent que des informations contenant MAC/IP sont reçues. Il n'y a pas de mention de préfixes.
C'est le protocole Host Mobility Manager (HMM) qui remplit la table ARP à partir de laquelle la table BGP est ensuite remplie (dans cet article, omettons ce processus). Sur la base des informations reçues de HMM, des EVPN route-type 2 (MAC/IP sont transmis) sont formés.
Cependant, que faire s'il est nécessaire de transmettre des informations sur un préfixe quelconque ?
Pour ce type d'information, il existe le type de route EVPN 5 — il permet de transmettre des préfixes via l'adresse de la famille l2vpn evpn (ce type de route, au moment de la rédaction de cet article, est uniquement disponible dans une version brouillon. , d'où le comportement de ce type de route peut varier selon les fabricants)
Pour transmettre des préfixes, il est nécessaire d’ajouter, dans le processus BGP pour le VRF, les préfixes qui seront annoncés :
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! Dans ce cas, nous annonçons les préfixes connectés directement à Leaf dans le VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Nous spécifions quel prefix-list utiliser
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Nous précisons quelles sous-réseaux seront inclus dans le type de route EVPN 5En conséquence, dans la mise à jour, nous aurons :
Regardons la table BGP. En plus des types de routes EVPN 2 et 3, des routes de type 5 apparaissent, contenant des informations sur le numéro de réseau :
Réseau Prochain Hop Métrique LocPrf Poids Chemin
Route Distinguisher : 10.255.1.11:3
* i[5]:[0]:[0]:[24]:[192.168.10.0]/224
10.255.1.10 0 100 0 ?
*>i 10.255.1.10 0 100 0 ?
Route Distinguisher : 10.255.1.11:32777
* i[2]:[0]:[0]:[48]:[5001.0007.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.0007.0007]:[32]:[192.168.10.10]/272
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
* i[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
Route Distinguisher : 10.255.1.12:3
*>i[5]:[0]:[0]:[24]:[192.168.10.0]/224 ! EVPN route-type 5 avec numéro de préfixe
10.255.1.10 0 100 0 ?
* i
<.......> Dans la table de routage, le préfixe est également apparu :
Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
*via 10.255.1.10fault, [200/0], 00:14:32, bgp-65001, interne, tag 65001 ! Préfixe distant, accessible via Leaf1/2 (adresse Next-hop = IP virtuelle entre la paire VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Préfixe accessible via L3VNI 99000
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10fault, [200/0], 02:33:40, bgp-65001, interne, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN
192.168.20.0/24, ubest/mbest: 1/0, attaché
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, direct
192.168.20.1/32, ubest/mbest: 1/0, attaché
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, local
192.168.20.20/32, ubest/mbest: 1/0, attaché
*via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmmNous allons terminer la deuxième partie de ce cycle d’articles sur VxLAN EVPN. Dans la partie suivante, nous examinerons différentes options de routage entre VRF.
Source : habr.com
