ProHoster > Blog > Administration > VxLAN-Fabrik. Teil 2

VxLAN-Fabrik. Teil 2

Hallo, Habr. Ich setze meine Artikelreihe zur VxLAN EVPN-Technologie fort, die speziell zur EinfĂŒhrung des Kurses "Netzwerktechniker" 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.

VxLAN-Fabrik. Teil 2

Teil 1 der Reihe – L2-KonnektivitĂ€t zwischen Servern

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:

VxLAN-Fabrik. Teil 2

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:

VxLAN-Fabrik. Teil 2

Wie kann in diesem Fall der Verkehr von einem Host zum anderen ĂŒbertragen werden?

Es gibt zwei Optionen:

  1. Auf allen Leaf-Switches die Informationen ĂŒber alle VNIs zu speichern, sodass das gesamte Routing an dem ersten Leaf im Netzwerk erfolgt;
  2. 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-gateway

Um 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 zuordnen

Das Schema wird wie folgt dargestellt:

VxLAN-Fabrik. Teil 2

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:

  1. Der von Host-1 gesendete Rahmen erreicht den Leaf in VLAN 10, der mit VNI 10000 assoziiert ist;
  2. Leaf ĂŒberprĂŒft, wo sich die Zieladresse befindet und findet sie ĂŒber L3 VNI auf dem zweiten Leaf-Switch;
  3. 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;
  4. 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.

VxLAN-Fabrik. Teil 2

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:

VxLAN-Fabrik. Teil 2

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 RT

Das 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 i

Wenn 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.102

In 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, direkt
192.168.10.1/32, ubest/mbest: 1/0, attached
 *via 192.168.10.1, Vlan10, [0/0], 01:29:28, lokal
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, intern, tag 65001 ! VerfĂŒgbar ĂŒber Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Über VNI 99000

Haben 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, RFC, 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 werden

Am Ende wird im Update Folgendes stehen:

VxLAN-Fabrik. Teil 2

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.10fault, [200/0], 00:14:32, bgp-65001, intern, tag 65001 ! Remote PrĂ€fix, verfĂŒgbar ĂŒber Leaf1/2 (NĂ€chster Hop = virtuelle IP zwischen dem VPC-Paar)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! PrĂ€fix verfĂŒgbar ĂŒber L3VNI 99000

192.168.10.10/32, ubest/mbest: 1/0
 *via 10.255.1.10fault, [200/0], 02:33:40, bgp-65001, intern, 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, direkt
192.168.20.1/32, ubest/mbest: 1/0, attached
 *via 192.168.20.1, Vlan20, [0/0], 02:39:44, lokal
192.168.20.20/32, ubest/mbest: 1/0, attached
 *via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmm

Damit schließen wir den zweiten Teil des Artikels ĂŒber VxLAN EVPN ab. Im nĂ€chsten Teil werden wir verschiedene Routing-Optionen zwischen VRF betrachten.

Grundlagen des IPv6-Protokolls und dessen Unterschiede zu IPv4

Quelle: habr.com

ZuverlĂ€ssiges Webhosting mit DDoS-Schutz, VPS- und VDS-Server kaufen đŸ”„ ZuverlĂ€ssiges Webhosting mit DDoS-Schutz, VPS- und VDS-Server kaufen | ProHoster