Hallo, Habr. Ich setze meine Artikelreihe zur VxLAN EVPN-Technologie fort, die speziell zur Einführung des Kurses von OTUS. Heute werden wir einen interessanten Teil der Aufgaben betrachten – das Routing. So banal es auch klingen mag, im Rahmen der Arbeit einer Netzwerkfabrik kann alles nicht so einfach sein.
Im letzten Teil haben wir ein Broadcast-Domain erreicht, das über die Netzwerkfabrik auf Nexus 9000v aufgebaut wurde. Aber das ist bei weitem nicht das gesamte Spektrum der Aufgaben, die innerhalb des Rechenzentrumsnetzes gelöst werden müssen. Heute werden wir die nächste Aufgabe betrachten – das Routing zwischen Netzwerken oder zwischen VNIs.
Ich erinnere daran, dass die Spine-Leaf-Topologie verwendet wird:
Zunächst untersuchen wir, wie das Routing funktioniert und welche Besonderheiten es gibt.
Um das Verständnis zu erleichtern, vereinfachen wir das logische Schema und fügen einen weiteren VNI 20000 für Host-2 hinzu. Am Ende ergibt sich:
Wie kann in diesem Fall der Verkehr von einem Host zum anderen übertragen werden?
Es gibt zwei Optionen:
- Auf allen Leaf-Switches die Informationen über alle VNIs zu speichern, sodass das gesamte Routing an dem ersten Leaf im Netzwerk erfolgt;
- Einen speziell zugewiesenen – L3 VNI zu verwenden.
Der erste Ansatz ist einfach und bequem. Es genügt, alle VNIs auf alle Leaf-Switches zu konfigurieren. Doch die Eingabe von mehreren Hundert oder Tausend VNIs auf allen Leaf-Switches erscheint bereits als komplexe Aufgabe. Daher wird dieses Verfahren in der Praxis eher selten angewendet.
Lassen Sie uns die zweite Methode betrachten, die interessanter und etwas komplexer ist, jedoch mehr Flexibilität bei der Konfiguration der Fabrik bietet.
Wir fügen der Topologie den VRF "PROD" hinzu. Darin fügen wir das Interface VLAN 10 an den Leaf-11/12-Paaren und das Interface VLAN 20 an Leaf-21 hinzu. VLAN 20 wird mit VNI 20000 assoziiert.
vrf context PROD
rd auto ! Route Distinguisher ist nicht entscheidend, und wir können den automatisch generierten verwenden
address-family ipv4 unicast
route-target both auto ! Wir geben den Route-target an, mit dem die Präfixe in/aus dem VRF importiert und exportiert werden
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-gatewayUm L3VNI nutzen zu können, muss ein neuer VLAN erstellt und mit dem neuen VNI assoziiert werden. Der neue VNI muss auf allen Leaf-Switches identisch sein, die an den Informationen über VLAN 10 und 20 interessiert sind.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! L3 VNI erstellen
vrf context PROD
vni 99000 ! L3 VNI einem bestimmten VRF zuordnenDas Schema wird wie folgt dargestellt:
Es bleibt nur noch wenig zu tun – einen weiteren Schnittstellen hinzufügen – interface vlan 99 im VRF PROD.
interface Vlan99
no shutdown
vrf member PROD
ip forward ! Auf der Schnittstelle sollte keine IP-Adresse vorhanden sein. Wird nur zur Paketweiterleitung zwischen Leaf verwendet.Die Logik für den Rahmenübertragungsweg von Host-1 zu Host-2 ist wie folgt:
- Der von Host-1 gesendete Rahmen erreicht den Leaf in VLAN 10, der mit VNI 10000 assoziiert ist;
- Leaf überprüft, wo sich die Zieladresse befindet und findet sie über L3 VNI auf dem zweiten Leaf-Switch;
- Sobald der Weg zur Zieladresse gefunden ist, packt Leaf den Rahmen in einen Header mit dem erforderlichen L3VNI 99000 – und sendet ihn zum zweiten Leaf;
- Der zweite Leaf-Switch empfängt die Daten aus L3VNI 99000. Er extrahiert den ursprünglichen Rahmen und überträgt ihn in das erforderliche L2VNI 20000 und weiter in VLAN 20.
Das Ergebnis dieser Arbeit entfernt die Notwendigkeit, auf allen Leaf-Switches Informationen über alle VNI, die im Netzwerk existieren, zu halten.
Somit wird, wenn wir den Datenverkehr von Host-1 zu Host-2 senden, das Paket in ein VxLAN mit dem neuen VNI – 99000 verpackt.
Es bleibt zu verstehen, wie genau Leaf-1 die MAC-Adresse aus einem anderen VNI erfährt. Dies geschieht ebenfalls über EVPN route-type 2 (MAC/IP).
Im Folgenden wird der Prozess der Verbreitung von Routen über ein Präfix, das sich in einem anderen VNI befindet, dargestellt:
Das heißt, die Adressen, die aus dem VNI 20000 stammen, haben zwei RT.
Erinnern wir uns daran, dass die aus dem Update erhaltenen Routen mit dem Route-Target, das in den VRF-Einstellungen angegeben ist, in die BGP-Tabelle gelangt (der Prozess ist etwas komplizierter, aber wir wollen in diesem Artikel nicht tiefer darauf eingehen).
Der RT wird nach der Formel: AS:VNI (wenn der automatische Modus verwendet wird) gebildet.
Beispiel für die Bildung von RT im automatischen und manuellen Modus:
vrf context PROD
address-family ipv4 unicast
route-target import auto - automatischer Betriebsmodus
route-target export 65001:20000 - manueller Modus zur Erstellung des RTDas obige Beispiel zeigt, dass die Präfixe aus einem anderen VNI zwei RT-Werte haben.
Einer davon ist 65001:99000 — ein zusätzlicher L3 VNI. Da dieser VNI auf allen Leaf-Knoten identisch ist und unter unsere Importregeln in den VRF-Einstellungen fällt, gelangt das Präfix in die BGP-Tabelle, wie aus der Ausgabe ersichtlich ist:
sh bgp l2vpn evpn
Netzwerk Next Hop Metrik LocPrf Gewicht Pfad
Routen-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
Routen-Distinguisher: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]/272 ! Präfix erhalten aus VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iWenn wir uns das erhaltene Update genauer ansehen, sehen wir, dass dieses Präfix zwei RT hat:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
BGP-Routing-Tabelleninformationen für VRF default, Adressfamilie L2VPN EVPN
Route Distinguisher: 10.255.1.21:32787
BGP-Routing-Tabelleintrag für [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.2
0]/272, Version 5164
Pfade: (2 verfügbar, beste #2)
Flags: (0x000202) (high32 00000000) in xmit-list, nicht in l2rib/evpn, nicht in HW
Pfadtyp: intern, Pfad ist gültig, nicht beste Begründung: Nachbaradresse, kein beschrifteter Nexthop
AS-Pfad: KEINE, Pfad interne Herkunft zu AS
10.255.1.20 (Metrik 81) von 10.255.1.102 (10.255.1.102)
Ursprung IGP, MED nicht gesetzt, localpref 100, Gewicht 0
Erhaltener Label 20000 99000 ! Zwei Labels für den VxLAN-Betrieb
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Zwei Werte für Route-Target, auf deren Grundlage dieser Präfix hinzugefügt wurde
Router MAC:5001.0005.0007
Ersteller: 10.255.1.21 Clusterliste: 10.255.1.102In der Routing-Tabelle auf Leaf-1 kann auch das Präfix 192.168.20.20/32 beobachtet werden:
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 99000Haben Sie das Fehlen des Hauptpräfixes 192.168.20.0/24 in der Routing-Tabelle bemerkt?
Genau, das gibt es dort nicht. Das bedeutet, dass entfernte Leaf Informationen nur über die Hosts erhält, die in Ihrem Netzwerk vorhanden sind. Und das ist das richtige Verhalten. Wie in allen Updates oben zu sehen ist, kommen Informationen mit dem Inhalt MAC/IP. Es gibt keine Rede von irgendwelchen Präfixen.
Hier kommt das Protokoll Host Mobility Manager (HMM) ins Spiel, das die ARP-Tabelle füllt, aus der anschließend die BGP-Tabelle gefüllt wird (wir lassen diesen Prozess im Rahmen dieses Artikels außen vor). Auf der Grundlage der aus HMM erhaltenen Informationen werden EVPN-Routen vom Typ 2 gebildet (MAC/IP wird übertragen).
Was ist jedoch zu tun, wenn es notwendig ist, Informationen über einen bestimmten Präfix zu übertragen?
Für diese Art von Informationen gibt es EVPN-Routen vom Typ 5 — dies ermöglicht die Übertragung von Präfixen über die address-family l2vpn evpn (dieser Routen-Typ befindet sich zum Zeitpunkt des Schreibens des Artikels nur in der Entwurfsversion, , daher kann das Verhalten dieses Routen-Typs bei verschiedenen Herstellern abweichen.)
Um Präfixe zu übertragen, müssen im BGP-Prozess für die VRF die Präfixe hinzugefügt werden, die angekündigt werden sollen:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! In diesem Fall kündigen wir die Präfixe, die direkt mit dem Leaf in VNI 20000 verbunden sind, an
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Wir geben an, welche Prefixliste verwendet werden soll
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0\/24 ! Wir geben an, welche Netzwerke in den EVPN route-type 5 fallen werdenAm Ende wird im Update Folgendes stehen:
Schauen wir uns die BGP-Tabelle an. Neben EVPN route-type 2 und 3 sind Routen des Typs 5 aufgetaucht, die Informationen zur Netznummer enthalten:
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 mit der Präfixnummer
10.255.1.10 0 100 0 ?
* i In der Routing-Tabelle ist das Präfix ebenfalls aufgetaucht:
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, hmmDamit schließen wir den zweiten Teil des Artikels über VxLAN EVPN ab. Im nächsten Teil werden wir verschiedene Routing-Optionen zwischen VRF betrachten.
Quelle: habr.com
