Hallo Habr. Derzeit bin ich Kursleiter für „Network Engineer“ bei OTUS.
In Erwartung des Beginns einer neuen Einschreibung für den Kurs Ich habe eine Reihe von Artikeln zur VxLAN-EVPN-Technologie vorbereitet.
Es gibt eine große Menge an Material zum Betrieb von VxLAN EVPN, daher möchte ich verschiedene Aufgaben und Praktiken zur Lösung von Problemen in einem modernen Rechenzentrum sammeln.
Im ersten Teil des VxLAN-EVPN-Technologiezyklus möchte ich über eine Möglichkeit nachdenken, L2-Konnektivität zwischen Hosts auf einer Netzwerkfabrik zu organisieren.
Alle Beispiele werden auf dem Cisco Nexus 9000v durchgeführt, der in der Spine-Leaf-Topologie aufgebaut ist. Wir werden uns in diesem Artikel nicht mit der Einrichtung des Underlay-Netzwerks befassen.
- Unterlagenetzwerk
- BGP-Peering für Adressfamilie l2vpn evpn
- NVE-Setup
- Supress-Arp
Unterlagenetzwerk
Die verwendete Topologie ist wie folgt:
Stellen wir die Adressierung auf allen Geräten ein:
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 zwischen allen Geräten eine IP-Konnektivität besteht:
Leaf21# sh ip route
<........>
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 доступен чеерз два Spine
*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 доступен чеерз два Spine
*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 Einstellungen auf beiden Knoten identisch sind:
Leaf11# show vpc
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : primary
Number of vPCs configured : 0
Peer Gateway : Disabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Disabled
Delay-restore status : Timer is off.(timeout = 30s)
Delay-restore SVI status : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router : Disabled
vPC status
----------------------------------------------------------------------------
Id Port Status Consistency Reason Active vlans
-- ------------ ------ ----------- ------ ---------------
5 Po5 up success success 1BGP-Peering
Abschließend können wir mit der Konfiguration des Overlay-Netzwerks fortfahren.
Im Rahmen des Artikels ist es notwendig, ein Netzwerk zwischen Hosts zu organisieren, wie im folgenden Diagramm dargestellt:
Um ein Overlay-Netzwerk zu konfigurieren, müssen Sie BGP auf den Spine- und Leaf-Switches mit Unterstützung für die l2vpn-evpn-Familie aktivieren:
feature bgp
nv overlay evpnAls Nächstes müssen Sie das BGP-Peering zwischen Leaf und Spine konfigurieren. Um die Konfiguration zu vereinfachen und die Verteilung der Routing-Informationen zu optimieren, konfigurieren wir Spine als Route-Reflector-Server. Wir werden alle Blätter über Vorlagen in die Konfiguration schreiben, um die Einstellung zu optimieren.
Die Einstellungen auf Spine sehen also so 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 LEAFDas Setup am 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 SPINEÜberprüfen Sie auf Spine 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 Sie sehen, gab es mit BGP keine Probleme. Fahren wir mit der Einrichtung von VxLAN fort. Die weitere Konfiguration wird nur auf der Seite der Leaf-Switches durchgeführt. Spine fungiert lediglich als Kern des Netzwerks und ist nur an der Übertragung des Datenverkehrs beteiligt. Sämtliche Arbeiten zur Kapselung und Pfaddefinition erfolgen nur an Leaf-Switches.
NVE-Setup
NVE – virtuelle Netzwerkschnittstelle
Bevor wir mit der Einrichtung beginnen, führen wir einige Begriffe ein:
VTEP – Virtueller Tunnel-Endpunkt, das Gerät, auf dem der VxLAN-Tunnel beginnt oder endet. VTEP ist nicht unbedingt irgendein Netzwerkgerät. Ein Server, der die VxLAN-Technologie unterstützt, kann ebenfalls agieren. In unserer Topologie sind alle Leaf-Switches VTEPs.
VNI – Virtual Network Index – Netzwerkkennung innerhalb von VxLAN. Sie können eine Analogie zu VLAN ziehen. Es gibt jedoch einige Unterschiede. Bei Verwendung einer Fabric werden VLANs nur innerhalb eines Leaf-Switches eindeutig und werden nicht über das Netzwerk übertragen. Aber jedem VLAN kann eine VNI-Nummer zugeordnet werden, die bereits über das Netzwerk übertragen wird. Wie es aussieht und wie es verwendet werden kann, wird im Folgenden besprochen.
Aktivieren Sie die Funktion für die VxLAN-Technologie und die Möglichkeit, VLAN-Nummern einer VNI-Nummer zuzuordnen:
feature nv overlay
feature vn-segment-vlan-basedLassen Sie uns die NVE-Schnittstelle konfigurieren, die für den Betrieb von VxLAN verantwortlich ist. Diese Schnittstelle ist für die Kapselung von Frames in VxLAN-Headern verantwortlich. Sie können eine Analogie zur Tunnelschnittstelle für GRE ziehen:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0Auf dem Leaf-21-Switch klappt alles ohne Probleme. Wenn wir jedoch die Ausgabe des Befehls überprüfen show nve peers, dann wird es leer sein. Hier müssen Sie zum VPC-Setup zurückkehren. Wir sehen, dass Leaf-11 und Leaf-12 gepaart und durch eine VPC-Domäne verbunden sind. Daraus ergibt sich folgende Situation:
Host-2 sendet einen Frame an Leaf-21, um ihn über das Netzwerk an Host-1 zu übertragen. Leaf-21 erkennt jedoch, dass die MAC-Adresse von Host-1 über zwei VTEPs gleichzeitig verfügbar ist. Was soll Leaf-21 in diesem Fall tun? Dies bedeutet schließlich, dass eine Schleife im Netzwerk entstehen könnte.
Um diese Situation zu lösen, müssen Leaf-11 und Leaf-12 auch als ein Gerät innerhalb der Fabrik fungieren. Es ist ganz einfach gelöst. Fügen Sie auf der Loopback-Schnittstelle, aus der wir den Tunnel erstellen, die sekundäre Adresse hinzu. Die Sekundäradresse muss auf beiden VTEPs gleich sein.
interface loopback0
ip add 10.255.1.10/32 secondaryAus Sicht anderer VTEPs erhalten wir somit die folgende Topologie:
Das heißt, jetzt wird der Tunnel zwischen der IP-Adresse von Leaf-21 und der virtuellen IP zwischen zwei Leaf-11 und Leaf-12 aufgebaut. Jetzt gibt es keine Probleme mehr, die MAC-Adresse von zwei Geräten zu lernen, und der Datenverkehr kann von einem VTEP auf ein anderes übertragen werden. Welcher der beiden VTEPs den Datenverkehr verarbeiten wird, wird anhand der Routing-Tabelle auf 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 Sie oben sehen können, ist die Adresse 10.255.1.10 über zwei Next-Hops sofort verfügbar.
Zu diesem Zeitpunkt haben wir die grundlegende Konnektivität herausgefunden. Fahren wir mit der Einrichtung der NVE-Schnittstelle fort:
Wir werden Vlan 10 sofort aktivieren und es mit VNI 10000 auf jedem Leaf für Hosts verknüpfen. Richten Sie einen L2-Tunnel zwischen Hosts ein
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPSchauen wir uns nun die nächsten Peers und die Tabelle für BGP EVPN an:
Leaf21# sh nve peers
Interface Peer-IP State LearnType Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 10.255.1.10 Up CP 00:00:41 n/a ! Видим что peer доступен с secondary адреса
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! От кого именно пришел этот l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]/88 ! EVPN route-type 3 - показывает нашего соседа, который так же знает об l2VNI10000
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 iOben sehen wir nur Routen vom EVPN-Routentyp 3. Bei diesem Routentyp handelt es sich um Peer (Leaf), aber wo sind unsere Hosts?
Und die Sache ist, dass Informationen über MAC-Hosts über den EVPN-Routentyp 2 übertragen werden
Um unsere Hosts zu sehen, müssen Sie den EVPN-Routentyp 2 konfigurieren:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoLassen Sie uns von Host-2 zu Host-1 pingen:
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
36 bytes from 192.168.10.2: Destination Host Unreachable
Request 0 timed out
64 bytes from 192.168.10.1: icmp_seq=1 ttl=254 time=215.555 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=254 time=38.756 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=254 time=42.484 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=254 time=40.983 msUnd unten sehen wir, dass Routentyp 2 in der BGP-Tabelle mit der MAC-Adresse der Hosts auftauchte – 5001.0007.0007 und 5001.0008.0007
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 ! evpn route-type 2 и mac адрес хоста 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 и mac адрес хоста 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 iAls nächstes sehen Sie detaillierte Informationen zum Update, in denen Sie Informationen zum MAC-Host erhalten haben. Nachfolgend finden Sie nicht die gesamte Ausgabe des Befehls
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! отправил Update с MAC Host. Не виртуальный адрес VPC, а адрес Leaf
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216,
version 1507
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 labe
led nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.10 (metric 81) from 10.255.1.102 (10.255.1.102) ! с кем именно строим VxLAN тоннель
Origin IGP, MED not set, localpref 100, weight 0
Received label 10000 ! Номер VNI, который ассоциирован с VLAN, в котором находится Host
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Тут видно, что RT сформировался автоматически на основе номеров AS и VNI
Originator: 10.255.1.11 Cluster list: 10.255.1.102
<........>Mal sehen, wie die Rahmen aussehen, wenn sie durch die Fabrik laufen:
Unterdrücke ARP
Großartig, wir haben eine L2-Verbindung zwischen Hosts und das könnte das Ende sein. Allerdings ist nicht alles so einfach. Solange wir wenige Gastgeber haben, wird es keine Probleme geben. Aber stellen wir uns Situationen vor, in denen wir Hunderte und Tausende von Hosts haben. Mit welchem Problem können wir konfrontiert werden?
Bei diesem Problem handelt es sich um BUM-Verkehr (Broadcast, Unknown Unicast, Multicast). Im Rahmen dieses Artikels betrachten wir die Möglichkeit, den Broadcast-Verkehr zu bekämpfen.
Der wichtigste Broadcast-Generator in Ethernet-Netzwerken sind die Hosts selbst über das ARP-Protokoll.
Nexus implementiert den folgenden Mechanismus für den Umgang mit ARP-Anfragen: suppress-arp.
Diese Funktion funktioniert folgendermaßen:
- Host-1 sendet eine APR-Anfrage an die Broadcast-Adresse seines Netzwerks.
- Die Anfrage erreicht den Leaf-Switch und anstatt diese Anfrage weiter an die Fabrik in Richtung Host-2 weiterzuleiten, antwortet der Leaf selbst und gibt die gewünschte IP und MAC an.
Daher ging die Broadcast-Anfrage nicht an die Fabrik. Doch wie soll das funktionieren, wenn Leaf nur die MAC-Adresse kennt?
Alles ist ganz einfach, EVPN-Routentyp 2 kann zusätzlich zur MAC-Adresse ein MAC/IP-Bündel übertragen. Dazu muss der Leaf mit einer IP-Adresse im VLAN konfiguriert werden. Es stellt sich die Frage, welche IP man fragen soll? Bei Nexus ist es möglich, auf allen Switches eine verteilte (gleiche) Adresse zu erstellen:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! задаем virtual mac для создания распределенного шлюза между всеми коммутаторами
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! на всех Leaf задаем одинаковый IP
fabric forwarding mode anycast-gateway ! говорим использовать Virtual macAus Sicht der Hosts sieht das Netzwerk also folgendermaßen aus:
Überprüfen Sie 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 i
<......>Aus der Ausgabe des Befehls ist ersichtlich, dass wir im EVPN-Routentyp 2 neben der MAC nun auch die IP-Adresse des Hosts sehen.
Kehren wir zur Suppress-Arp-Einstellung zurück. Diese Einstellung wird für jedes VNI separat aktiviert:
interface nve1
member vni 10000
suppress-arpDann gibt es einige Schwierigkeiten:
- Diese Funktion erfordert Speicherplatz im TCAM-Speicher. Ich werde ein Beispiel für die Einstellung von suppress-arp geben:
hardware access-list tcam region arp-ether 256Für dieses Setup ist eine doppelte Breite erforderlich. Das heißt, wenn Sie 256 festlegen, muss 512 in TCAM freigegeben werden. Das Einrichten von TCAM geht über den Rahmen dieses Artikels hinaus, da das Einrichten von TCAM nur von der Ihnen zugewiesenen Aufgabe abhängt und von Netzwerk zu Netzwerk unterschiedlich sein kann.
- Die Implementierung von suppress-arp muss auf allen Leaf-Switches erfolgen. Bei der Konfiguration von Leaf-Paaren in einer VPC-Domäne kann es jedoch zu Komplexität kommen. Bei einem Wechsel von TCAM wird die Konsistenz zwischen den Paaren unterbrochen und ein Knoten wird möglicherweise außer Betrieb genommen. Darüber hinaus ist möglicherweise ein Neustart des Geräts erforderlich, um die TCAM-Änderungseinstellung zu übernehmen.
Daher sollten Sie sorgfältig abwägen, ob es sich lohnt, diese Einstellung in einer funktionierenden Fabrik in Ihrer Situation zu implementieren.
Damit ist der erste Teil des Zyklus abgeschlossen. Im nächsten Teil betrachten wir das Routing durch eine VxLAN-Fabrik mit Netzwerktrennung über verschiedene VRFs hinweg.
Und jetzt lade ich alle dazu ein , in dem ich ausführlich auf den Kurs eingehen werde. Die ersten 20 Teilnehmer, die sich für dieses Webinar anmelden, erhalten innerhalb von 1-2 Tagen nach der Übertragung ein Rabattzertifikat per E-Mail.
Source: habr.com