Hallo, Habr. Derzeit bin ich Kursleiter für "Netzwerktechniker" bei OTUS.
Im Vorfeld des Starts eines neuen Kurses , ich habe eine Artikelreihe zur VxLAN EVPN-Technologie vorbereitet.
Es gibt eine Fülle von Materialien zur Arbeit mit VxLAN EVPN, daher möchte ich verschiedene Aufgaben und deren Lösungen in modernen Rechenzentren sammeln.
Im ersten Teil der Artikelreihe zur VxLAN EVPN-Technologie möchte ich die Möglichkeit der L2-Verknüpfung zwischen Hosts über ein Netzwerk-Gestell betrachten.
Alle Beispiele werden auf Cisco Nexus 9000v durchgeführt, die in einer Spine-Leaf-Topologie angeordnet sind. Wir werden in diesem Artikel nicht auf die Konfiguration des Underlay-Netzwerks eingehen.
- Underlay-Netzwerk
- BGP-Peering für address-family l2vpn evpn
- Konfiguration NVE
- Suppress-ARP
Underlay-Netzwerk
Die verwendete Topologie sieht folgendermaßen aus:
Wir werden die Adressierung auf allen Geräten festlegen:
Spine-1 - 10.255.1.101
Spine-2 - 10.255.1.102
Leaf-11 - 10.255.1.11
Leaf-12 - 10.255.1.12
Leaf-21 - 10.255.1.21
Host-1 - 192.168.10.10
Host-2 - 192.168.10.20Überprüfen wir, ob es eine IP-Verbindung zwischen allen Geräten gibt:
Leaf21# sh ip route
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 über zwei Spine verfügbar
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 2/0 ! Leaf-12 über zwei Spine verfügbar
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.21/32, ubest/mbest: 2/0, attached
*via 10.255.1.22, Lo0, [0/0], 00:02:20, local
*via 10.255.1.22, Lo0, [0/0], 00:02:20, direct
10.255.1.101/32, ubest/mbest: 1/0
*via 10.255.1.101, Eth1/4, [110/41], 00:00:06, ospf-UNDERLAY, intra
10.255.1.102/32, ubest/mbest: 1/0
*via 10.255.1.102, Eth1/3, [110/41], 00:00:03, ospf-UNDERLAY, intraÜberprüfen wir, ob die VPC-Domäne erstellt wurde und beide Switches die Konsistenzprüfung bestanden haben und die Konfigurationen auf beiden Knoten identisch sind:
Leaf11# show vpc
vPC-Domain-ID : 1
Peer-Status : Peer-Nachbarschaft erfolgreich gebildet
vPC-Herzschlagstatus : Peer ist aktiv
Konfigurationskonsistenzstatus : erfolgreich
Pro-VLAN-Konsistenzstatus : erfolgreich
Typ-2-Konsistenzstatus : erfolgreich
vPC-Rolle : primär
Anzahl konfigurierter vPCs : 0
Peer-Gateway : Deaktiviert
Dual-Active ausgeschlossene VLANs : -
Sanfter Konsistenzcheck : Aktiviert
Automatische Wiederherstellungsstatus: Deaktiviert
Verzögerungswiederherstellungsstatus : Timer ist aus. (Timeout = 30s)
Verzögerungswiederherstellungs-SVI-Status: Timer ist aus. (Timeout = 10s)
Betriebliches Layer3 Peer-Router : Deaktiviert
vPC-Status
----------------------------------------------------------------------------
Id Port Status Konsistenz Grund Aktive VLANs
-- ------------ ------ ----------- ------ ---------------
5 Po5 up erfolgreich erfolgreich 1BGP-Peering
Jetzt können wir mit der Einrichtung des Overlay-Netzwerks beginnen.
Im Rahmen des Artikels muss ein Netzwerk zwischen den Hosts organisiert werden, wie in der untenstehenden Skizze gezeigt:
Für die Konfiguration des Overlay-Netzwerks muss BGP auf den Spine- und Leaf-Switches mit Unterstützung für das l2vpn evpn-Familie aktiviert werden:
feature bgp
nv overlay evpnAls Nächstes muss das BGP-Peering zwischen Leaf und Spine eingerichtet werden. Um die Konfiguration zu vereinfachen und die Verbreitung von Routing-Informationen zu optimieren, konfigurieren wir Spine als Route-Reflector-Server. Alle Leaf-Switches werden über Vorlagen in die Konfiguration aufgenommen, um die Einstellung zu optimieren.
So sieht die Konfiguration auf dem Spine aus:
router bgp 65001
template peer LEAF
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
route-reflector-client
neighbor 10.255.1.11
inherit peer LEAF
neighbor 10.255.1.12
inherit peer LEAF
neighbor 10.255.1.21
inherit peer LEAFDie Konfiguration auf dem Leaf-Switch sieht ähnlich aus:
router bgp 65001
template peer SPINE
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
neighbor 10.255.1.101
inherit peer SPINE
neighbor 10.255.1.102
inherit peer SPINEAuf dem Spine überprüfen wir das Peering mit allen Leaf-Switches:
Spine1# sh bgp l2vpn evpn summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.255.1.11 4 65001 7 8 6 0 0 00:01:45 0
10.255.1.12 4 65001 7 7 6 0 0 00:01:16 0
10.255.1.21 4 65001 7 7 6 0 0 00:01:01 0Wie wir sehen, gab es mit BGP keine Probleme. Lassen Sie uns mit der VxLAN-Konfiguration fortfahren. Die weitere Konfiguration wird ausschließlich auf der Seite der Leaf-Switches vorgenommen. Der Spine fungiert nur als Kern des Netzwerks und kümmert sich nur um den Datenverkehr. Alle Arbeiten an der Kapselung und Pfadbestimmung erfolgen nur auf den Leaf-Switches.
Konfiguration NVE
NVE — Netzwerkvirtualschnittstelle
Bevor wir mit der Konfiguration beginnen, lassen Sie uns einige Begriffe einführen:
VTEP — Virtuelles Tunnel-Ende, ein Gerät, an dem ein VxLAN-Tunnel beginnt oder endet. VTEP ist nicht unbedingt ein Netzwerkgerät. Es kann auch ein Server sein, der die VxLAN-Technologie unterstützt. In unserer Topologie fungieren alle Leaf-Switches als VTEP.
VNI — Virtual Network Index — die Netzwerkkennung innerhalb von VxLAN. Man kann eine Analogie zu VLAN ziehen. Es gibt jedoch einige Unterschiede. Bei Verwendung einer Fabrik werden VLANs nur innerhalb eines Leaf-Switches eindeutig und nicht über das Netzwerk übertragen. Jedem VLAN kann jedoch eine VNI-Nummer zugeordnet werden, die dann über das Netzwerk übertragen wird. Wie das aussieht und wie man es nutzen kann, wird im Folgenden erläutert.
Aktivieren wir die Funktion für die Nutzung der VxLAN-Technologie sowie die Möglichkeit, VLAN-Nummern mit VNI-Nummern zu assoziieren:
feature nv overlay
feature vn-segment-vlan-basedKonfigurieren wir das NVE-Interface, das für den Betrieb von VxLAN verantwortlich ist. Dieses Interface kümmert sich um die Kapselung von Frames in VxLAN-Header. Man kann eine Analogie zu einem Tunnel-Interface für GRE ziehen:
interface nve1
no shutdown
host-reachability protocol bgp ! BGP zur Übertragung von Routing-Informationen verwenden
source-interface loopback0 ! Interface, von dem aus wir Pakete senden (loopback0)Auf dem Leaf-21-Switch funktioniert alles ohne Probleme. Wenn wir jedoch den Befehl show nve peers, überprüfen, wird die Ausgabe leer sein. Hier müssen wir zurück zur VPC-Konfiguration. Wir sehen, dass Leaf-11 und Leaf-12 im Paar arbeiten und durch das VPC-Domain verbunden sind. Daraus ergibt sich die folgende Situation:
Host-2 sendet ein Paket in Richtung Leaf-21, damit dieser es über das Netzwerk an Host-1 weiterleitet. Leaf-21 sieht jedoch, dass die MAC-Adresse von Host-1 über zwei VTEP verfügbar ist. Wie sollte Leaf-21 in diesem Fall verfahren? Das bedeutet, dass es im Netzwerk eine Schleife geben könnte.
Um diese Situation zu lösen, müssen Leaf-11 und Leaf-12 innerhalb der Fabrik als ein einziges Gerät fungieren. Dies lässt sich recht einfach umsetzen. Wir fügen auf dem Loopback-Interface, von dem aus wir den Tunnel aufbauen, eine sekundäre Adresse hinzu. Die sekundäre Adresse sollte auf beiden VTEP gleich sein.
interface loopback0
ip add 10.255.1.10/32 secondaryAuf diese Weise erhalten wir aus der Sicht der anderen VTEP die folgende Topologie:
Das bedeutet, dass der Tunnel nun zwischen der IP-Adresse Leaf-21 und der virtuellen IP zwischen den beiden Leaf-11 und Leaf-12 erstellt wird. Jetzt wird es keine Probleme mehr geben, die MAC-Adresse von zwei Geräten zu erlernen, und der Datenverkehr kann von einem VTEP zum anderen wechseln. Wer genau von den beiden VTEPs den Datenverkehr bearbeitet, wird durch die Routing-Tabelle am Spine entschieden:
Spine1# sh ip route
10.255.1.10/32, ubest/mbest: 2/0
*via 10.255.1.11, Eth1/1, [110/41], 1d01h, ospf-UNDERLAY, intra
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra
10.255.1.11/32, ubest/mbest: 1/0
*via 10.255.1.11, Eth1/1, [110/41], 1d22h, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 1/0
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intraWie oben ersichtlich, ist die Adresse 10.255.1.10 sofort über zwei Next-Hop erreichbar.
In diesem Schritt haben wir die grundlegende Konnektivität geklärt. Lassen Sie uns mit der Konfiguration des NVE-Interfaces fortfahren:
Aktivieren wir zuerst VLAN 10 und assoziieren es mit VNI 10000 auf jedem Leaf für die Hosts. Wir konfigurieren einen L2-Tunnel zwischen den Hosts.
vlan 10 ! Aktivieren Sie VLAN auf allen VTEPs, die mit den entsprechenden Hosts verbunden sind
vn-segment 10000 ! Assoziieren Sie VLAN mit der VNI-Nummer
interface nve1
member vni 10000 ! Fügen Sie VNI 10000 hinzu, um über das NVE-Interface zu arbeiten, um in VxLAN zu kapseln
ingress-replication protocol bgp ! Geben Sie an, dass BGP zur Verbreitung von Hostinformationen verwendet wird.Jetzt überprüfen wir die NVE-Peers und die Tabelle für BGP EVPN:
Leaf21# sh nve peers
Schnittstelle Peer-IP Status Lernart Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 10.255.1.10 Aktiv CP 00:00:41 n/a ! Wir sehen, dass der Peer über die sekundäre Adresse erreichbar ist
Leaf11# sh bgp l2vpn evpn
Netzwerk Nächster Hop Metrik LocPrf Gewicht Pfad
Route Distinguishers: 10.255.1.11:32777 (L2VNI 10000) ! Von wem genau kam dieser L2VNI
*>l[3]:[0]:[32]:[10.255.1.10]/88 ! EVPN-Routen-Typ 3 - zeigt unseren Nachbarn, der ebenfalls über L2VNI10000 informiert ist
10.255.1.10 100 32768 i
*>i[3]:[0]:[32]:[10.255.1.20]/88
10.255.1.20 100 0 i
* i 10.255.1.20 100 0 i
Route Distinguishers: 10.255.1.21:32777
* i[3]:[0]:[32]:[10.255.1.20]/88
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iDarüber sehen wir nur Routen des EVPN-Routen-Typs 3. Dieser Routen-Typ beschreibt den Peer (Leaf), aber wo sind unsere Hosts?
Das liegt daran, dass die Informationen über die MAC-Adressen der Hosts über den EVPN-Routen-Typ 2 übertragen werden.
Um unsere Hosts zu sehen, müssen wir den EVPN-Routen-Typ 2 konfigurieren:
evpn
vni 10000 l2
route-target import auto ! In diesem Artikel verwenden wir eine automatische Nummer für den Route-Target
route-target export autoWir machen einen Ping von Host-2 zu Host-1:
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 Datenbytes
36 Bytes von 192.168.10.2: Zielhost nicht erreichbar
Anfrage 0 hat zeitüberschreitung
64 Bytes von 192.168.10.1: icmp_seq=1 ttl=254 Zeit=215.555 ms
64 Bytes von 192.168.10.1: icmp_seq=2 ttl=254 Zeit=38.756 ms
64 Bytes von 192.168.10.1: icmp_seq=3 ttl=254 Zeit=42.484 ms
64 Bytes von 192.168.10.1: icmp_seq=4 ttl=254 Zeit=40.983 msUnd hier können wir sehen, dass in der BGP-Tabelle Route-Type 2 mit den MAC-Adressen der Hosts – 5001.0007.0007 und 5001.0008.0007 – erschienen sind.
Leaf11# 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 ! evpn route-type 2 und mac Adresse des Hosts 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216 ! evpn route-type 2 und mac Adresse des Hosts 2
* i 10.255.1.20 100 0 i
*>l[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 32768 i
Routenbezeichner: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iHier können Sie detaillierte Informationen zum Update einsehen, in dem Informationen über den MAC-Host erhalten wurden. Nachfolgend ist nicht die gesamte Ausgaben der Befehle dargestellt.
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
BGP-Routing-Tabelleninformationen für VRF default, Adressfamilie L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! Update mit MAC-Host gesendet. Keine virtuelle VPC-Adresse, sondern Adresse Leaf
BGP-Routing-Tabelleintrag für [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216,
Version 1507
Pfad: (2 verfügbar, bester #2)
Flags: (0x000202) (high32 00000000) auf xmit-list, ist nicht in l2rib/evpn, ist nicht in HW
Pfadtyp: intern, Pfad ist gültig, nicht bester Grund: Nachbaradresse, kein beschrifteter Nexthop
AS-Pfad: NONE, Pfad intern zu AS
10.255.1.10 (Metrik 81) von 10.255.1.102 (10.255.1.102) ! Mit wem genau bauen wir den VxLAN-Tunnel
Ursprünglicher IGP, MED nicht gesetzt, localpref 100, Gewicht 0
Erhaltener Label 10000 ! Nummer VNI, der mit VLAN assoziiert ist, in dem sich der Host befindet
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Hier sieht man, dass RT automatisch auf Basis von AS-Nummern und VNI gebildet wurde
Urheber: 10.255.1.11 Clusterliste: 10.255.1.102Schauen wir uns an, wie die Frames aussehen, wenn sie durch die Fabrik übertragen werden:
Suppress-ARP
Ausgezeichnet, die L2-Verbindung zwischen den Hosts ist hergestellt, und das könnte man als abgeschlossen betrachten. Allerdings ist nicht alles so einfach. Solange wir nur wenige Hosts haben, wird es keine Probleme geben. Aber lassen Sie uns die Situation vorstellen, dass wir Hunderte oder Tausende von Hosts haben. Mit welchem Problem könnten wir konfrontiert werden?
Dieses Problem ist BUM (Broadcast, Unknown Unicast, Multicast) Verkehr. In diesem Artikel betrachten wir eine Möglichkeit zur Bekämpfung von Broadcast-Verkehr.
Der Hauptgenerator von Broadcast in Ethernet-Netzwerken sind die Hosts selbst über das ARP-Protokoll.
Auf Nexus ist der folgende Mechanismus zur Bekämpfung von ARP-Anfragen implementiert: suppress-arp.
Die Funktionsweise dieses Features sieht folgendermaßen aus:
- Host-1 sendet eine ARP-Anfrage an die Broadcast-Adresse seines Netzwerks.
- Die Anfrage erreicht den Leaf-Switch, und anstatt die Anfrage weiter in die Fabrik in Richtung Host-2 zu leiten, antwortet der Leaf selbst und gibt die benötigte IP und MAC-Adresse an.
So gelangt die Broadcast-Anfrage nicht in die Fabrik. Aber wie kann das funktionieren, wenn der Leaf nur die MAC-Adresse kennt?
Das ist ziemlich einfach. EVPN route-type 2 kann neben der MAC-Adresse auch die Kombination aus MAC/IP übermitteln. Dazu muss auf dem Leaf eine IP-Adresse im VLAN konfiguriert werden. Die Frage ist, welche IP vergeben werden soll? Auf Nexus gibt es die Möglichkeit, eine verteilte (identische) Adresse auf allen Switches zu erstellen:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! Definieren Sie die virtuelle MAC-Adresse für die Erstellung eines verteilten Gateways zwischen allen Switches
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! Wir setzen dieselbe IP für alle Leaf-Switches
fabric forwarding mode anycast-gateway ! Wir konfigurieren, um die virtuelle MAC zu verwendenSo wird das Netzwerk aus der Perspektive der Hosts aussehen:
Überprüfen wir BGP l2route evpn
Leaf11# 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.21 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.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.0008.0007]:[32]:[192.168.10.20]/248
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
*>i 10.255.1.20 100 0 iAus der Ausgabe des Befehls ist ersichtlich, dass wir im EVPN route-type 2 neben der MAC-Adresse nun auch die IP-Adresse des Hosts sehen.
Kommen wir zurück zur Konfiguration von suppress-arp. Diese Einstellung wird für jedes VNI einzeln aktiviert:
interface nve1
member vni 10000
suppress-arpDann tritt eine gewisse Komplexität auf:
- Für die Funktion dieser Funktionalität wird Platz im TCAM-Speicher benötigt. Hier ist ein Beispiel für die Einstellung von suppress-arp:
hardware access-list tcam region arp-ether 256Für diese Einstellung wird double-wide benötigt. Das bedeutet, wenn Sie 256 festlegen, müssen im TCAM 512 freigegeben werden. Die TCAM-Konfiguration geht über den Rahmen dieses Artikels hinaus, da die TCAM-Konfiguration allein von der spezifischen Aufgabe abhängt und von einem Netzwerk zum anderen variieren kann.
- Die Implementierung von suppress-arp muss auf allen Leaf-Switches durchgeführt werden. Bei der Konfiguration auf verbundenen Leaf-Switches im VPC-Domain kann jedoch Komplexität auftreten. Bei Änderungen am TCAM kann die Konsistenz zwischen den Paaren beeinträchtigt werden, und eine Node könnte außer Betrieb geraten. Zudem kann ein Neustart des Geräts erforderlich sein, um die Änderungen am TCAM anzuwenden.
Daher sollte man gründlich überlegen, ob es in Ihrer Situation sinnvoll ist, diese Einstellung in einer aktiven Fabrik zu implementieren.
Damit beenden wir den ersten Teil der Reihe. Im nächsten Teil werfen wir einen Blick auf die Routing-Optionen über eine VxLAN-Fabrik mit der Trennung der Netzwerke in verschiedene VRFs.
Ich lade alle ein zu , in dem ich ausführlich über den Kurs sprechen werde. Die ersten 20 Teilnehmer, die sich für dieses Webinar anmelden, erhalten innerhalb von 1-2 Tagen nach der Übertragung einen Rabattzertifikat per E-Mail.
Quelle: habr.com
