Hallo, Habr. Ich setze die Artikelreihe zur VxLAN EVPN-Technologie fort, die speziell zum Start des Kurses geschrieben wurde von OTUS. Und heute werden wir einen interessanten Teil der Aufgaben betrachten – das Routing. So banal es auch klingt, innerhalb der Arbeit einer Netzwerkfabrik kann alles nicht so einfach sein.
Im vorherigen Teil haben wir einen Broadcast-Domäne erreicht, der über die Netzwerkfabrik auf Nexus 9000v aufgebaut ist. Das ist jedoch bei weitem nicht das gesamte Spektrum von Aufgaben, die im Rahmen eines Rechenzentrumsnetzes gelöst werden müssen. Heute betrachten wir die nächste Aufgabe – das Routing zwischen Netzwerken oder zwischen VNIs.
Ich erinnere daran, dass das Spine-Leaf-Topologie verwendet wird:
Zunächst werden wir untersuchen, wie das Routing erfolgt und welche Besonderheiten es gibt.
Um es zu verstehen, vereinfachen wir das logische Diagramm und fügen einen weiteren VNI 20000 für Host-2 hinzu. Am Ende ergibt sich:
Wie kann in diesem Fall der Datenverkehr von einem Host zu einem anderen übertragen werden?
Es gibt zwei Optionen:
- Auf allen Leaf-Switches Informationen über alle VNIs halten, sodass das gesamte Routing direkt auf dem ersten Leaf im Netzwerk erfolgt;
- Einen speziell zugewiesenen – L3 VNI verwenden.
Die erste Methode ist einfach und praktisch. Es reicht aus, alle VNIs auf alle Leaf-Switches einzuführen. Allerdings scheint es bereits nicht einfach zu sein, mehrere Hundert oder Tausend VNIs auf allen Leaf-Switches einzuführen. Daher wird sie in der Praxis eher selten angewendet.
Wir werden die zweite Methode als interessanter und etwas komplizierter erörtern, aber sie bietet größere Flexibilität bei der Konfiguration der Fabrik.
Fügen wir dem Topologie VRF "PROD" hinzu. Wir fügen das Interface VLAN 10 auf dem Paar Leaf-11/12 und das Interface VLAN 20 auf dem Leaf-21 hinzu. VLAN 20 wird mit VNI 20000 assoziiert.
vrf context PROD
rd auto ! Route Distinguisher ist nicht entscheidend und kann automatisch generiert werden
address-family ipv4 unicast
route-target both auto ! Geben Sie den Route-target an, mit dem die Präfixe in/aus 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 L3 VNI zu verwenden, muss ein neuer VLAN erstellt und mit einem neuen VNI assoziiert werden. Der neue VNI muss auf allen Leafs identisch sein, die an Informationen über VLAN 10 und 20 interessiert sind.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Erstellen von L3 VNI
vrf context PROD
vni 99000 ! Verknüpfung des L3 VNI mit einem bestimmten VRFDas Schema wird folgendermaßen 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 darf keine IP vorhanden sein. Sie wird nur für die Weiterleitung von Paketen zwischen Leaf verwendet.Die Logik des Rahmenverkehrs von Host-1 zu Host-2 sieht folgendermaßen aus:
- Das von Host-1 gesendete Frame gelangt auf den Leaf im VLAN 10, das mit dem VNI 10000 verknüpft ist;
- Der Leaf prüft, wo sich die Zieladresse befindet, und findet sie über das L3 VNI am zweiten Leaf-Switch;
- Sobald die Route zur Zieladresse gefunden ist, verpackt der Leaf das Frame in einen Header mit dem erforderlichen L3VNI 99000 – und sendet es in Richtung des zweiten Leaf;
- Der zweite Leaf-Switch erhält die Daten aus dem L3VNI 99000. Er extrahiert das ursprüngliche Frame und überträgt es in das benötigte L2VNI 20000 und dann in das VLAN 20.
Das Ergebnis dieser Arbeit ist, dass L3VNI die Notwendigkeit beseitigt, auf allen Leaf-Switches Informationen über alle VNI, die im Netz vorhanden sind, zu speichern.
Infolgedessen wird, wenn wir Verkehr von Host-1 zu Host-2 senden, das Paket in VxLAN mit dem neuen VNI – 99000 – verpackt:
Es muss jedoch verstanden werden, wie genau Leaf-1 die MAC-Adresse aus einem anderen VNI erfährt. Dies geschieht ebenfalls mithilfe des EVPN route-type 2 (MAC/IP).
Unten ist der Prozess der Verbreitung der Route eines Präfixes dargestellt, das sich in einem anderen VNI befindet:
Das heißt, Adressen, die aus VNI 20000 stammen, haben zwei RT.
Ich erinnere daran, dass die Routen, die aus dem Update empfangen werden, in die BGP-Tabelle mit dem in den VRF-Einstellungen angegebenen Route-target gelangen (der Prozess ist etwas komplexer, jedoch werden wir in diesem Artikel nicht weiter darauf eingehen).
Der RT selbst wird nach folgender Formel gebildet: AS:VNI (wenn der automatische Modus verwendet wird).
Beispiel für die Bildung des 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 der RT-BildungDas Ergebnis zeigt oben, dass Präfixe aus einem anderen VNI zwei RT-Werte haben.
Einer von ihnen ist 65001:99000 – ein zusätzlicher L3 VNI. Da dieser VNI auf allen Leaf identisch ist und unter unsere Import-Regeln in den VRF-Einstellungen fällt, gelangt das Präfix in die BGP-Tabelle, was aus der Ausgabe ersichtlich ist:
sh bgp l2vpn evpn
Netzwerk Nächster Hop Metrik LocPrf Gewicht Pfad
Routenbezeichner: 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
Routenbezeichner: 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 das erhaltene Update genauer betrachten, sehen wir, dass dieses Präfix zwei RT hat:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
BGP-Routing-Tabelleninformationen für VRF standard, Adressfamilie L2VPN EVPN
Routenbezeichner: 10.255.1.21:32787
BGP-Routing-Tabelleintrag für [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]/272, Version 5164
Pfad: (2 verfügbar, bester #2)
Flags: (0x000202) (high32 00000000) auf der xmit-Liste, ist nicht in l2rib/evpn, ist nicht in HW
Pfadtyp: intern, Pfad ist gültig, nicht bester Grund: Nachbaradresse, kein benannter Nächster Hop
AS-Pfad: KEINE, Pfad stammt intern aus AS
10.255.1.20 (Metrik 81) von 10.255.1.102 (10.255.1.102)
Herkunft IGP, MED nicht gesetzt, localpref 100, Gewicht 0
Erhaltenes Label 20000 99000 ! Zwei Labels für 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 Basis dieses Präfix hinzugefügt wurde
Router-MAC:5001.0005.0007
Ursprünglicher: 10.255.1.21 Cluster-Liste: 10.255.1.102In der Routingtabelle auf Leaf-1 kann man auch das Präfix 192.168.20.20/32 beobachten:
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 ! Adresse Host-2
*via 10.255.1.20fault, [200/0], 01:20:20, bgp-65001, internal, tag 65001 ! Erreichbar über Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Über VNI 99000Haben Sie das Fehlen des Hauptpräfixes 192.168.20.0/24 in der Routingtabelle bemerkt?
Genau, das gibt es dort nicht. Das heißt, entfernte Leaves erhalten Informationen nur über Hosts, die in Ihrem Netzwerk vorhanden sind. Und das ist das richtige Verhalten. Wie oben in allen Updates zu sehen ist, kommen Informationen mit dem Inhalt MAC/IP. Von Präfixen ist keine Rede.
Das Protokoll Host Mobility Manager (HMM) arbeitet hier, das die ARP-Tabelle ausfüllt, aus der dann die BGP-Tabelle (in diesem Artikel lassen wir diesen Prozess aus). Auf Basis der Informationen aus dem HMM werden EVPN-Routen-Typ 2 gebildet (MAC/IP werden übermittelt).
Was ist jedoch zu tun, wenn es notwendig ist, Informationen über ein bestimmtes Präfix zu übermitteln?
Für diese Art von Informationen gibt es den EVPN-Routentyp 5 – er ermöglicht die Übertragung von Präfixen über die Address-Family l2vpn evpn (dieser Routentyp befindet sich zum Zeitpunkt des Schreibens des Artikels nur in der Entwurfsversion , deshalb kann das Verhalten dieses Routentyps bei unterschiedlichen Herstellern variieren)
Um Präfixe zu übertragen, müssen während des BGP-Prozesses für VRF die Präfixe hinzugefügt werden, die bekannt gegeben werden sollen:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! In diesem Fall geben wir die Präfixe bekannt, die direkt mit Leaf im VNI 20000 verbunden sind
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Wir geben an, welche Prefix-Liste verwendet werden soll
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Hier geben wir an, welche Netzwerke in den EVPN-Routentyp 5 fallenDas Update wird wie folgt aussehen:
Werfen wir einen Blick auf die BGP-Tabelle. Neben EVPN-Routentyp 2 und 3 sind auch Routentypen 5 aufgetaucht, die Informationen über die Netzwerknummer enthalten:
Netzwerk Nächster Hop Metrik LocPrf Gewicht Pfad
Routenbezeichner: 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 ?
Routenbezeichner: 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
Routenbezeichner: 10.255.1.12:3
*>i[5]:[0]:[0]:[24]:[192.168.10.0]/224 ! EVPN-Routentyp 5 mit 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.10fault, [200/0], 00:14:32, bgp-65001, internal, tag 65001 ! Entfernte Präfix, erreichbar über Leaf1/2 (Next-hop-Adresse = virtuelle IP zwischen dem VPC-Paar)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Präfix ist über L3VNI 99000 erreichbar
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10fault, [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 der Artikelreihe über VxLAN EVPN ab. Im nächsten Teil werden wir verschiedene Optionen für das Routing zwischen VRF untersuchen.
Quelle: habr.com
