Hallo Habr. Ich setze die Artikelreihe zur VxLAN EVPN-Technologie fort, die wurden speziell für den Start des Kurses geschrieben von OTUS. Und heute werden wir einen interessanten Teil der Aufgaben betrachten – das Routing. So abgedroschen es auch klingen mag, im Rahmen der Arbeit einer Netzwerkfabrik kann jedoch nicht alles so einfach sein.
Im letzten Teil haben wir eine Broadcast-Domäne erreicht, die auf einer Netzwerkstruktur auf einem Nexus 9000v aufgebaut ist. Dies ist jedoch nicht die gesamte Bandbreite an Aufgaben, die im Rahmen des Rechenzentrumsnetzwerks gelöst werden müssen. Und heute betrachten wir die folgende Aufgabe – Routing zwischen Netzwerken oder zwischen VNIs.
Ich möchte Sie daran erinnern, dass die Spine-Leaf-Topologie verwendet wird:
Zunächst analysieren wir, wie das Routing abläuft und welche Funktionen es hat.
Zum besseren Verständnis vereinfachen wir das Logikdiagramm und fügen einen weiteren VNI 20000 für Host-2 hinzu. Das Ergebnis ist:
Wie können Sie in diesem Fall Datenverkehr von einem Host auf einen anderen übertragen?
Es gibt zwei Optionen:
- Behalten Sie Informationen über alle VNIs auf allen Leaf-Switches bei, dann erfolgt das gesamte Routing auf dem ersten Leaf im Netzwerk;
- Verwenden Sie dediziertes L3 VNI
Der erste Weg ist einfach und bequem. Da Sie nur alle VNIs auf allen Leaf-Switches starten müssen. Allerdings scheint es keine leichte Aufgabe mehr zu sein, ein paar Hundert oder Tausende von VNIs auf dem gesamten Leaf auszuführen. Daher wird es in der Arbeit recht selten verwendet.
Wir werden Methode 2 analysieren, da sie interessanter und etwas komplizierter ist, aber mehr Flexibilität beim Aufbau der Fabrik bietet.
Fügen wir „PROD“ zur VRF-Topologie hinzu. Fügen wir Schnittstellen-VLAN 10 auf dem Blatt-11/12-Paar und Schnittstellen-VLAN 20 auf Blatt-21 hinzu. VLAN 20 ist mit VNI 20000 verknüpft
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-gatewayUm L3VNI verwenden zu können, müssen Sie ein neues VLAN erstellen und es dem neuen VNI zuordnen. Der neue VNI muss auf allen Leafs, die an VLAN 10- und 20-Informationen interessiert sind, gleich sein.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Создаем L3 VNI
vrf context PROD
vni 99000 ! Привязываем L3 VNI к определенному VRFAls Ergebnis sieht das Diagramm folgendermaßen aus:
Es bleibt noch ein wenig zu beenden – fügen Sie eine weitere Schnittstelle hinzu – Schnittstelle VLAN 99 in VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между LeafDaher lautet die Logik für die Weitergabe des Frames von Host-1 an Host-2 wie folgt:
- Ein von Host-1 gesendeter Frame kommt auf einem Leaf in VLAN 10 an, das VNI 10000 zugeordnet ist.
- Leaf prüft, wo sich die Zieladresse befindet und findet sie über L3 VNI auf dem zweiten Leaf-Switch;
- Sobald die Route zur Zieladresse gefunden ist, packt der Leaf den Frame in einen Header mit dem nötigen L3VNI 99000 – und sendet ihn an den zweiten Leaf;
- Der zweite Leaf-Switch empfängt Daten von L3VNI 99000. Ruft den ursprünglichen Frame ab und überträgt ihn an den erforderlichen L2VNI 20000 und dann an VLAN 20.
Als Ergebnis dieser Arbeit entfällt mit L3VNI die Notwendigkeit, Informationen über alle VNIs im Netzwerk auf allen Leaf-Switches aufzubewahren.
Wenn wir Datenverkehr von Host-1 an Host-2 senden, wird das Paket daher in VxLAN mit dem neuen VNI – 99000 gepackt:
Es bleibt abzuwarten, wie genau Leaf-1 die MAC-Adresse von einem anderen VNI erfährt. Dies geschieht auch mit Hilfe des EVPN-Routentyps 2 (MAC/IP).
Im Folgenden wird der Prozess der Weitergabe einer Route über ein Präfix in einem anderen VNI gezeigt:
Das heißt, von VNI 20000 empfangene Adressen verfügen über zwei RTs.
Ich möchte Sie daran erinnern, dass die von Update empfangenen Routen mit dem in den VRF-Einstellungen angegebenen Routenziel in die BGP-Tabelle fallen (der Vorgang ist etwas komplizierter, aber wir werden in diesem Artikel nicht darauf eingehen).
Der RT selbst wird durch die Formel AS:VNI gebildet (wenn der Automatikmodus verwendet wird).
Ein Beispiel für die RT-Bildung im automatischen und manuellen Modus:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RTDaher können Sie oben sehen, dass Präfixe von einem anderen VNI zwei RT-Werte haben.
Einer davon 65001:99000 ist ein zusätzlicher L3-VNI. Da dieser VNI auf allen Leafs gleich ist und unter unsere Importregeln in den VRF-Einstellungen fällt, gelangt das Präfix in die BGP-Tabelle, was aus der Ausgabe ersichtlich ist:
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 iWenn wir uns das erhaltene Update genauer ansehen, können wir erkennen, dass dieses Präfix zwei RTs hat:
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
<......>In der Routing-Tabelle auf Leaf-1 können Sie auch das Präfix 192.168.20.20/32 sehen:
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 99000Ist Ihnen das fehlende Primärpräfix 192.168.20.0/24 in der Routing-Tabelle aufgefallen?
Stimmt, er ist nicht da. Das heißt, Remote-Leafs erhalten nur Informationen über die Hosts, die sich in Ihrem Netzwerk befinden. Und das ist das richtige Verhalten. Oben können Sie in allen Updates sehen, dass die Informationen den Inhalt von MAC/IP enthalten. Es gibt keine nennenswerten Präfixe.
Hierbei handelt es sich um das Host Mobility Manager (HMM)-Protokoll, das die ARP-Tabelle füllt, aus der die BGP-Tabelle weiter gefüllt wird (wir werden diesen Prozess im Rahmen dieses Artikels weglassen). Basierend auf den vom HMM empfangenen Informationen werden EVPNs vom Routentyp 2 gebildet (übertragen per MAC/IP).
Was aber, wenn Informationen über ein Präfix weitergegeben werden müssen?
Für diese Art von Informationen gibt es den EVPN-Routentyp 5 – er ermöglicht das Senden von Präfixen über die Adressfamilie l2vpn evpn (dieser Routentyp ist zum Zeitpunkt des Verfassens dieses Artikels nur in der Entwurfsversion verfügbar). Aus diesem Grund kann es bei verschiedenen Herstellern zu einem unterschiedlichen Verhalten dieser Art von Route kommen.)
Um Präfixe zu übertragen, müssen im BGP-Prozess für VRF Präfixe hinzugefügt werden, die angekündigt werden:
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 5Infolgedessen wird das Update wie folgt aussehen:
Schauen wir uns die BGP-Tabelle an. Zusätzlich zum EVPN-Routentyp 2,3 sind Routen vom Typ 5 aufgetaucht, die Informationen zur Netzwerknummer 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 с номером префикса
10.255.1.10 0 100 0 ?
* i
<.......> Das Präfix erschien auch in der Routing-Tabelle:
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 ist der zweite Teil einer Artikelserie über VxLAN EVPN abgeschlossen. Im nächsten Teil betrachten wir verschiedene Optionen für das Routing zwischen VRFs.
Source: habr.com