Hé Habr. Je continue la série d'articles sur la technologie VxLAN EVPN, qui ont été écrits spécifiquement pour le lancement du cours par OTU. Et aujourd'hui, nous examinerons une partie intéressante des tâches - le routage. Aussi banal que cela puisse paraître, cependant, dans le cadre du travail d'une usine à réseaux, tout n'est peut-être pas si simple.
Dans la dernière partie, nous avons réalisé un domaine de diffusion construit au-dessus d'une structure réseau sur un Nexus 9000v. Cependant, ce n'est pas toute la gamme de tâches qui doivent être résolues dans le cadre du réseau de centres de données. Et aujourd'hui, nous examinerons la tâche suivante - le routage entre réseaux ou entre VNI.
Je vous rappelle que la topologie Spine-Leaf est utilisée :
Pour commencer, nous analyserons comment le routage se produit et quelles fonctionnalités il possède.
Pour comprendre, simplifions le schéma logique et ajoutons un autre VNI 20000 pour Host-2. Le résultat est:
Comment, dans ce cas, pouvez-vous transférer le trafic d'un hôte à un autre ?
Il ya deux options:
- Conservez les informations sur tous les VNI sur tous les commutateurs Leaf, puis tout le routage se produira sur la première Leaf du réseau ;
- Utilisation dédiée - L3 VNI
La première méthode est simple et pratique. Étant donné que vous n'avez qu'à démarrer tous les VNI sur tous les commutateurs Leaf. Cependant, exécuter quelques centaines ou milliers de VNI sur l'ensemble de la feuille ne semble plus être une tâche facile. Par conséquent, dans le travail, il est utilisé assez rarement.
Nous analyserons la méthode 2, comme plus intéressante et un peu plus compliquée, mais donnant plus de souplesse dans la mise en place de l'usine.
Ajoutons "PROD" à la topologie VRF. Ajoutons-y l'interface vlan 10 sur la paire Leaf-11/12 et l'interface VLAN 20 sur Leaf-21. VLAN 20 est associé à VNI 20000
vrf context PROD
rd auto ! Route Distinguisher не принципиален и можем использовать сформированный автоматически
address-family ipv4 unicast
route-target both auto ! указываем Route-target с которым будут импортироваться и экспортироваться префиксы в/из 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 L3VNI, vous devez créer un nouveau VLAN, l'associer au nouveau VNI. Le nouveau VNI doit être le même sur toutes les feuilles intéressées par les informations VLAN 10 et 20.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Создаем L3 VNI
vrf context PROD
vni 99000 ! Привязываем L3 VNI к определенному VRFEn conséquence, le diagramme ressemblera à ceci:
Il reste à finir un peu - ajouter une interface de plus - interface vlan 99 dans VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между LeafPar conséquent, la logique de transmission de la trame de l'Hôte-1 à l'Hôte-2 est la suivante :
- Une trame envoyée par Host-1 arrive sur une feuille 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 la route vers l'adresse de destination est trouvée, la feuille emballe la trame dans un en-tête avec le L3VNI 99000 nécessaire - et l'envoie vers la deuxième feuille ;
- Le deuxième commutateur Leaf reçoit les données du L3VNI 99000. Obtient la trame d'origine et la transfère au L2VNI 20000 requis, puis au VLAN 20.
À la suite de ce travail, L3VNI supprime le besoin de conserver des informations sur tous les VNI qui se trouvent sur le réseau sur tous les commutateurs Leaf.
Par conséquent, lorsque nous envoyons du trafic de l'Hôte-1 vers l'Hôte-2, le paquet est emballé dans VxLAN avec le nouveau VNI - 99000 :
Il reste à voir comment exactement Leaf-1 apprend l'adresse MAC d'un autre VNI. Cela se produit également à l'aide d'EVPN route de type 2 (MAC / IP).
L'exemple suivant montre le processus de propagation d'une route sur un préfixe situé dans un autre VNI :
C'est-à-dire que les adresses reçues de VNI 20000 ont deux RT.
Permettez-moi de vous rappeler que les routes reçues de Update tombent dans la table BGP avec la Route-target spécifiée dans les paramètres VRF (le processus est un peu plus compliqué, mais nous n'entrerons pas dans cet article).
Le RT lui-même est formé par la formule : AS:VNI (si le mode automatique est utilisé).
Un exemple de formation RT en modes automatique et manuel :
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RTPar conséquent, vous pouvez voir ci-dessus que les préfixes d'un autre VNI ont deux valeurs RT.
L'un d'eux 65001:99000 est un VNI L3 supplémentaire. Étant donné que ce VNI est le même sur toutes les feuilles et relève de nos règles d'importation dans les paramètres VRF, le préfixe entre dans la table BGP, qui peut être vue à partir de la sortie :
sh bgp l2vpn evpn
<.....>
Network Next Hop Metric LocPrf Weight Path
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 ! Префикс полученный из VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iSi nous regardons de plus près la mise à jour reçue, nous pouvons voir que ce préfixe a deux RT :
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.21:32787
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.2
0]/272, version 5164
Paths: (2 available, best #2)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not i
n HW
Path type: internal, path is valid, not best reason: Neighbor Address, no labeled nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.20 (metric 81) from 10.255.1.102 (10.255.1.102)
Origin IGP, MED not set, localpref 100, weight 0
Received label 20000 99000 ! Два label для работы VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Два значения Route-target, на основе, которых добавили данный префикс
Router MAC:5001.0005.0007
Originator: 10.255.1.21 Cluster list: 10.255.1.102
<......>Dans la table de routage sur Leaf-1, vous pouvez également voir le préfixe 192.168.20.20/32 :
Leaf11# sh ip route vrf PROD
192.168.10.0/24, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, direct
192.168.10.1/32, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, local
192.168.10.10/32, ubest/mbest: 1/0, attached
*via 192.168.10.10, Vlan10, [190/0], 01:27:22, hmm
192.168.20.20/32, ubest/mbest: 1/0 ! Адрес Host-2
*via 10.255.1.20%default, [200/0], 01:20:20, bgp-65001, internal, tag 65001 ! Доступный через Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Через VNI 99000Remarquez le préfixe principal manquant 192.168.20.0/24 dans la table de routage ?
C'est vrai, il n'est pas là. Autrement dit, les feuilles distantes reçoivent des informations uniquement sur les hôtes qui se trouvent sur votre réseau. Et c'est le comportement correct. Ci-dessus, dans toutes les mises à jour, vous pouvez voir que les informations sont fournies avec le contenu de MAC / IP. Il n'y a pas de préfixes à proprement parler.
Il s'agit du protocole Host Mobility Manager (HMM), qui remplit la table ARP à partir de laquelle la table BGP est encore remplie (nous omettrons ce processus dans le cadre de cet article). Sur la base des informations reçues du HMM, des EVPN de type route 2 sont formés (transmis par MAC / IP).
Cependant, que se passe-t-il s'il est nécessaire de transmettre des informations sur un préfixe ?
Pour ce type d'informations, il existe EVPN route-type 5 - il vous permet d'envoyer des préfixes via la famille d'adresses l2vpn evpn (ce type de route au moment de la rédaction de cet article n'est que dans la version brouillon , à cause de cela, différents fabricants peuvent avoir un comportement différent de ce type d'itinéraire)
Pour transférer des préfixes, il est nécessaire d'ajouter des préfixes dans le processus BGP pour VRF, qui seront annoncés :
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! В данном случае анонсируем префиксы подключение непосредственно к Leaf в VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Указываем какой использовать prefix-list
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Указываем какие сети будут попадать в EVPN route-type 5En conséquence, la mise à jour sera :
Regardons la table BGP. En plus des routes EVPN de type 2,3, des routes de type 5 sont apparues qui contiennent des informations sur le numéro de réseau :
<......>
Network Next Hop Metric LocPrf Weight Path
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 с номером префикса
10.255.1.10 0 100 0 ?
* i
<.......> Le préfixe est également apparu dans la table de routage :
Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
*via 10.255.1.10%default, [200/0], 00:14:32, bgp-65001, internal, tag 65001 ! Удаленный префикс, доступный через Leaf1/2(адрес Next-hop = virtual IP между парой VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Префикс доступен через L3VNI 99000
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10%default, [200/0], 02:33:40, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN
192.168.20.0/24, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, direct
192.168.20.1/32, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, local
192.168.20.20/32, ubest/mbest: 1/0, attached
*via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmmCeci conclut la deuxième partie d'une série d'articles sur VxLAN EVPN. Dans la partie suivante, nous examinerons diverses options de routage entre les VRF.
Source: habr.com