Hallo, Habr. Zurzeit bin ich Leiter des Kurses 'Netzwerktechniker' bei OTUS.
Kurz vor Beginn des neuen Kurses , ich habe eine Reihe von Artikeln zur VxLAN EVPN-Technologie vorbereitet.
Es gibt eine enorme Menge an Materialien zur Arbeit mit VxLAN EVPN, daher möchte ich verschiedene Aufgaben und Praktiken zur Problemlösung im modernen Rechenzentrum zusammenstellen.
Im ersten Teil der Reihe zur VxLAN EVPN-Technologie möchte ich die Organisation der L2-Verbindung zwischen Hosts über die Netzwerkfabrik betrachten.
Alle Beispiele werden auf Cisco Nexus 9000v durchgeführt, die in einer Spine-Leaf-Topologie aufgebaut sind. Wir werden uns in diesem Artikel nicht mit der Konfiguration des Underlay-Netzes befassen.
- Underlay-Netz
- BGP-Peering für Adressfamilie l2vpn evpn
- NVE-Konfiguration
- Supress-arp
Underlay-Netz
Die verwendete Topologie sieht wie folgt aus:
Lass uns 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 ist über zwei Spine zugänglich
*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 ist über zwei Spine zugänglich
*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 der VPC-Domain erstellt wurde und beide Switches die Konsistenzprüfung bestanden haben sowie die Konfiguration auf beiden Knoten identisch ist:
Leaf11# show vpc
vPC-Domain-ID : 1
Peer-Status : Peer-Nachbarschaft erfolgreich hergestellt
vPC-Keep-Alive-Status : Peer ist aktiv
Konfigurationskonsistenzstatus : Erfolg
Per-VLAN-Konsistenzstatus : Erfolg
Typ-2-Konsistenzstatus : Erfolg
vPC-Rolle : primär
Anzahl der konfigurierten vPCs : 0
Peer-Gateway : Deaktiviert
Dual-Active ausgeschlossen VLANs : -
Sanfter Konsistenzcheck : Aktiviert
Auto-Restaurierungsstatus : Deaktiviert
Verzögerung-Wiederherstellungsstatus: Timer ist aus.(timeout = 30s)
Verzögerung-Wiederherstellungs-SVI-Status: Timer ist aus.(timeout = 10s)
Betriebsschicht-3-Peer-Router : Deaktiviert
vPC-Status
----------------------------------------------------------------------------
Id Port Status Konsistenz Grund Aktive VLANs
-- ------------ ------ ----------- ------ ---------------
5 Po5 up Erfolg Erfolg 1BGP-Peering
Schließlich können wir mit der Konfiguration des Overlay-Netzes fortfahren.
Im Rahmen des Artikels ist es notwendig, ein Netzwerk zwischen den Hosts gemäß dem untenstehenden Schema zu organisieren:
Um das Overlay-Netzwerk einzurichten, muss auf den Spine- und Leaf-Switches BGP mit Unterstützung für die Familie l2vpn evpn aktiviert werden:
feature bgp
nv overlay evpnAls nächstes muss das BGP-Peering zwischen Leaf und Spine konfiguriert werden. Zur Vereinfachung der Konfiguration und Optimierung der Verbreitung von Routing-Informationen wird Spine als Route-Reflector-Server konfiguriert. Alle Leaf werden in der Konfiguration über Vorlagen eingebunden, um die Einrichtung zu optimieren.
So sieht die Konfiguration auf 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 Spine überprüfen wir die Peering-Verbindung zu 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 Konfiguration von VxLAN fortfahren. Die weitere Konfiguration wird nur auf der Seite der Leaf-Switches durchgeführt. Spine fungiert lediglich als Backbone des Netzwerks und überträgt nur den Traffic. Die gesamte Arbeit der Kapselung und der Pfadbestimmung erfolgt ausschließlich auf den Leaf-Switches.
NVE-Konfiguration
NVE — network virtual interface
Bevor wir mit der Konfiguration beginnen, lassen Sie uns einige Begriffe einführen:
VTEP — Virtual Tunnel End Point, das Gerät, an dem der VxLAN-Tunnel beginnt oder endet. Ein VTEP muss nicht zwingend ein Netzwerkgerät sein. Es kann auch ein Server sein, der die VxLAN-Technologie unterstützt. In unserer Topologie sind alle Leaf-Switches VTEPs.
VNI — Virtual Network Index — die Netzwerk-ID innerhalb von VxLAN. Man kann eine Analogie zu VLAN ziehen. Es gibt jedoch einige Unterschiede. Bei der Verwendung einer Fabrik sind VLANs nur innerhalb eines einzelnen Leaf-Switches einzigartig und werden nicht über das Netzwerk übertragen. Allerdings kann jede VLAN-Nummer mit einer VNI-Nummer verknüpft werden, die dann über das Netzwerk übertragen wird. Wie das aussieht und wie es verwendet werden kann, wird im Folgenden erörtert.
Aktivieren Sie das Feature für die Verwendung der VxLAN-Technologie und die Möglichkeit, VLAN-Nummern mit VNI-Nummern zu verknüpfen:
feature nv overlay
feature vn-segment-vlan-basedWir richten das NVE-Interface ein, das für den Betrieb von VxLAN verantwortlich ist. Dieses Interface ist genau für die Kapselung von Datenrahmen in VxLAN-Header verantwortlich. Man kann eine Analogie zum Tunnel-Interface für GRE ziehen:
interface nve1
no shutdown
host-reachability protocol bgp ! wir verwenden BGP zur Übertragung von Routinginformationen
source-interface loopback0 ! Interface von dem wir Pakete an loopback0 sendenAuf dem Switch Leaf-21 wird alles problemlos erstellt. Wenn wir jedoch die Ausgabe des Befehls überprüfen, show nve peers, wird die Ausgabe leer sein. Hier ist es notwendig, zu den VPC-Einstellungen zurückzukehren. Wir sehen, dass Leaf-11 und Leaf-12 im Verbund arbeiten und durch das VPC-Domain verbunden sind. Daraus ergibt sich folgende Situation:
Host-2 sendet einen Rahmen in Richtung Leaf-21, damit dieser ihn über das Netzwerk in Richtung Host-1 weiterleitet. Leaf-21 sieht jedoch, dass die MAC-Adresse von Host-1 sofort über zwei VTEPs verfügbar ist. Wie sollte Leaf-21 in diesem Fall handeln? Das bedeutet, dass sich möglicherweise eine Schleife im Netzwerk gebildet hat.
Um diese Situation zu lösen, müssen Leaf-11 und Leaf-12 innerhalb der Fabrik ebenfalls als ein Gerät auftreten. Dies lässt sich ziemlich einfach lösen. Am Loopback-Interface, über das wir den Tunnel aufbauen, fügen wir eine sekundäre Adresse hinzu. Die sekundäre Adresse muss auf beiden VTEPs identisch sein.
interface loopback0
ip add 10.255.1.10/32 secondarySo erhalten wir aus der Sicht der anderen VTEPs die folgende Topologie:
Das heißt, der Tunnel wird jetzt zwischen der IP-Adresse von Leaf-21 und der virtuellen IP-Adresse zwischen den beiden Leaf-11 und Leaf-12 aufgebaut. Jetzt wird es keine Probleme mit der Erfassung der MAC-Adresse von zwei Geräten geben, und der Datenverkehr kann von einem VTEP zum anderen übergehen. Wer genau von den beiden VTEPs den Datenverkehr bearbeitet, wird mithilfe der Routing-Tabelle auf der 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 zu sehen ist, ist die Adresse 10.255.1.10 sofort über zwei Next-hop verfügbar.
In diesem Schritt haben wir die grundlegende Vernetzung verstanden. Lassen Sie uns jetzt mit der Konfiguration des NVE-Interfaces fortfahren:
Aktivieren wir sofort VLAN 10 und verknüpfen wir es mit VNI 10000 auf jedem Leaf für die Hosts. Wir richten einen L2-Tunnel zwischen den Hosts ein.
vlan 10 ! VLAN auf allen VTEP aktivieren, die mit den erforderlichen Hosts verbunden sind
vn-segment 10000 ! VLAN mit der VNI-Nummer assoziieren
interface nve1
member vni 10000 ! Fügen Sie VNI 10000 für die Arbeit über das NVE-Interface hinzu, um in VxLAN zu kapseln
ingress-replication protocol bgp ! Geben Sie an, dass zur Verbreitung von Hostinformationen BGP verwendet wirdJetzt überprüfen wir die nve Peers und die Tabelle für BGP EVPN:
Leaf21# sh nve peers
Interface Peer-IP State LearnType Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 10.255.1.10 Up CP 00:00:41 n/a ! Wir sehen, dass der Peer über die sekundäre Adresse erreichbar ist
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 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 Bescheid weiß
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 Distinguisher: 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 vom EVPN-Routen-Typ 3. Dieser Routen-Typ berichtet über den Peer (Leaf), aber wo sind unsere Hosts?
Das liegt daran, dass 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 ein Ping von Host-2 auf 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
Anforderung 0 hat die Zeitüberschreitung überschritten
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 unten sehen wir, dass in der BGP-Tabelle Route-Typ 2 mit den MAC-Adressen der Hosts — 5001.0007.0007 und 5001.0008.0007 hinzugefügt wurden.
Leaf11# sh bgp l2vpn evpn
Netzwerk Nächste Hop Metrik LocPrf Gewicht Pfad
Route Distinguisher: 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
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 iIm Folgenden kann man detaillierte Informationen zu dem Update einsehen, in dem Informationen über MAC-Hosts erhalten wurden. Nachfolgend wird nicht die gesamte Ausgabe des Befehls angezeigt.
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
BGP-Routing-Tabelleninformationen für VRF standard, Adressfamilie L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! Update mit MAC-Host gesendet. Nicht die virtuelle Adresse des VPC, sondern die Adresse des Leaf
BGP-Routing-Tabelleneintrag 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 gelabelter Nächster Hop
AS-Pfad: NONE, Pfad stammt intern aus AS
10.255.1.10 (Metrik 81) von 10.255.1.102 (10.255.1.102) ! mit wem genau bauen wir den VxLAN-Tunnel
Ursprung IGP, MED nicht gesetzt, localpref 100, Gewicht 0
Erhaltenes Label 10000 ! Die Nummer des VNI, die mit dem VLAN assoziiert ist, in dem sich der Host befindet
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Hier ist zu sehen, dass der RT automatisch basierend auf den Nummern von AS und VNI gebildet wurde
Ursprungsgeber: 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
Perfekt, die L2-Verbindung zwischen den Hosts ist hergestellt und man könnte hierauf enden. Allerdings ist nicht alles so einfach. Solange wir nur wenige Hosts haben, wird es keine Probleme geben. Aber lassen Sie uns eine Situation vorstellen, in der wir Hunderte und Tausende von Hosts haben. Welches Problem könnte auftauchen?
Dieses Problem ist der BUM (Broadcast, Unknown Unicast, Multicast) Verkehr. In diesem Artikel betrachten wir eine Möglichkeit, Broadcast-Verkehr zu bekämpfen.
Der Hauptgenerator von Broadcast in Ethernet-Netzen sind die Hosts selbst über das ARP-Protokoll.
Auf Nexus wurde folgendes Verfahren zur Bekämpfung von ARP-Anfragen implementiert – suppress-arp.
Die Funktionsweise dieses Features sieht folgendermaßen aus:
- Host-1 sendet eine APR-Anfrage an die Broadcast-Adresse seines Netzwerks.
- Die Anfrage erreicht den Leaf-Switch und anstatt diese Anfrage weiter zur Fabrik in Richtung Host-2 zu leiten, antwortet der Leaf selbst und gibt die benötigte IP und MAC an.
So wurde die Broadcast-Anfrage nicht an die Fabrik gesendet. Aber wie kann das funktionieren, wenn Leaf nur die MAC-Adresse kennt?
Alles ist ziemlich einfach, der EVPN-Routentyp 2 kann neben der MAC-Adresse auch eine MAC\/IP-Bindung übertragen. Dafür muss auf Leaf eine IP-Adresse im VLAN konfiguriert werden. Die Frage ist, welche IP zugewiesen werden soll? Auf Nexus besteht die Möglichkeit, eine verteilte (identische) Adresse auf allen Switches zu erstellen:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! Wir weisen eine virtuelle MAC für die Erstellung eines verteilten Gateways zwischen allen Switches zu
interface Vlan10
no shutdown
ip address 192.168.10.254\/24 ! Wir weisen allen Leafs die gleiche IP zu
fabric forwarding mode anycast-gateway ! Wir sagen, dass die virtuelle MAC verwendet werden sollSo wird das Netzwerk aus der Sicht der Hosts folgendermaßen aussehen:
Überprüfen wir BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
Netzwerk Nächster Hop Metrik LocPrf Gewicht Pfad
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 zu erkennen, dass wir im EVPN-Routentyp 2 neben der MAC jetzt auch die IP-Adresse des Hosts sehen.
Wir kehren zur Konfiguration von suppress-arp zurück. Diese Einstellung wird für jedes VNI separat aktiviert:
interface nve1
member vni 10000
suppress-arpDanach tritt eine gewisse Schwierigkeit auf:
- Für das Funktionieren dieser Funktion ist Platz im TCAM-Speicher erforderlich. Ich gebe ein Beispiel für die Konfiguration von suppress-arp:
hardware access-list tcam region arp-ether 256Für diese Konfiguration ist ein double-wide erforderlich. Das heißt, wenn Sie 256 angeben, müssen im TCAM 512 freigegeben werden. Die TCAM-Konfiguration geht über den Rahmen dieses Artikels hinaus, da die TCAM-Konfiguration nur von der Ihnen gestellten Aufgabe abhängt und von einem Netzwerk zum anderen unterschiedlich sein kann.
- Die Implementierung von suppress-arp muss auf allen Leaf-Switches erfolgen. Allerdings kann es bei der Konfiguration auf Leaf-Paaren, die sich im VPC-Domäne befinden, zu Schwierigkeiten kommen. Bei einer Änderung des TCAM kann die Konsistenz zwischen den Paaren gestört werden, und ein Knoten kann außer Betrieb gehen. Zusätzlich kann für die Anwendung der TCAM-Änderung ein Neustart des Geräts erforderlich sein.
Daher sollte man gut überlegen, ob es in Ihrer Situation sinnvoll ist, diese Konfiguration in einer laufenden Fabrik einzuführen.
Damit beenden wir den ersten Teil des Zyklus. Im nächsten Teil werden wir die Routenführung durch die VxLAN-Fabrik mit der Trennung der Netzwerke nach verschiedenen VRFs behandeln.
Und jetzt lade ich alle ein zu , in dessen Rahmen ich ausführlich über den Kurs berichten werde. Die ersten 20 Teilnehmer, die sich für dieses Webinar anmelden, erhalten innerhalb von 1-2 Tagen nach der Übertragung ein Zertifikat mit einem Rabatt per E-Mail.
Quelle: habr.com
