So konfigurieren Sie OTT DCI in einem EVPN-Netzwerk
Anforderungen
In diesem Konfigurationsbeispiel werden die folgenden Geräte und Softwareversionen verwendet:
Spine-Geräte, bestehend aus QFX5120-32C-Switches, auf denen Junos OS Version 19.1R3-S2 in beiden DCs ausgeführt wird.
Leaf-Geräte, bestehend aus QFX5110-48S-Switches, auf denen Junos OS Version 18.4R2-S5 in DC1 ausgeführt wird.
Leaf-Geräte, bestehend aus QFX5120-48Y-Switches, auf denen Junos OS Version 18.4R2-S5 in DC2 ausgeführt wird.
Übersicht
In dieser Bereitstellung verwenden wir eine Architektur mit zwei Datencenter-Fabric-Netzwerken, die in einem ERB-Overlay-Modell (Edge-Routing-Bridging) konfiguriert wurden. Die Datencenter sind über ein Layer-3-IP-Underlay-Netzwerk miteinander verbunden. Abbildung 1 zeigt die WAN-Konnektivität, die den Underlay-Transport zwischen den beiden Datencentern bereitstellt. Wir verwenden eine Over-the-Top-EVPN-VXLAN-DCI-Architektur, um sowohl Layer-2- als auch Layer-3-Konnektivität für Endpunkte und virtuelle Maschinen in den beiden Datencentern bereitzustellen.
In diesem Beispiel sind einige VLANs so konfiguriert, dass sie nur innerhalb eines bestimmten Datencenters vorhanden sind, während sich andere VLANs über die beiden Datencenter erstrecken. Abbildung 2 zeigt die VLANs, die in den beiden Datencentern konfiguriert sind. Wir konfigurieren die VLANs wie folgt:
Die VLANs 10, 11 und 12 sind lokal in Datencenter 1. Die Endgeräte in diesen VLANs verwenden Layer-3-Routing, um andere VLANs in Datencenter 2 zu erreichen.
Die VLANs 170, 171 und 172 sind lokal in Datencenter 2. Die Endgeräte in diesen VLANs verwenden Layer-3-Routing, um andere VLANs in Datencenter 1 zu erreichen.
Die VLANs 202 und 203 sind für Datencenter 1 und Datencenter 2 gleich. Diese VLANs erstrecken sich über alle Leaf-Geräte in beiden Datencentern. Die Endgeräte in diesen VLANs verwenden Layer-2-Bridging, um die Endpunkte im anderen Datencenter zu erreichen.
Sie können ein beliebiges Routing-Protokoll im Underlay-Netzwerk verwenden. Das Underlay-Routing-Protokoll ermöglicht es Geräten, Loopback-IP-Adressen miteinander auszutauschen. In diesem Beispiel wird eBGP als Underlay-Routing-Protokoll in jeder Datencenter-Fabric verwendet. Das eBGP-Protokoll wird auch verwendet, um das Underlay-Netzwerk über die WAN-Verbindung zwischen den beiden Datencentern zu erweitern. Sie können entweder iBGP oder eBGP als Overlay-Routing-Protokoll zwischen den DCs verwenden. Die Wahl hängt davon ab, ob Sie für Ihre Datencenter die gleiche oder unterschiedliche autonome Systemnummern verwenden. In diesem Beispiel verwenden wir iBGP für das Overlay-Protokoll innerhalb einer Fabric und eBGP zwischen den beiden Datencentern. Abbildung 3 zeigt die autonomen Systemnummern und IP-Adressen, die in diesem Beispiel verwendet werden.
Konfigurieren der Border Spine-Geräte für die WAN-Konnektivität
Anforderungen
Border Spine WAN Underlay-Konfiguration
Die auf dieser Seite gezeigten Konfigurationen basieren auf einer bereits vorhandenen EVPN-Fabric mit einem betriebsbereiten Underlay- und Overlay-Netzwerk. Mit anderen Worten, in diesem Abschnitt werden nur die zusätzlichen Konfigurationen angezeigt, die erforderlich sind, um das DC-Underlay auf eine WAN-Cloud zu erweitern. Im Gegensatz dazu zeigen die detaillierten Konfigurationen die vollständige Konfiguration jedes DC-Geräts.
In diesem Abschnitt wird gezeigt, wie Sie die WAN-Underlay-Konfiguration für Border Spine-Geräte konfigurieren. Der Kürze halber zeigen wir nur die Schritte zur Konfiguration eines Spine-Geräts in jedem Datencenter. Sie können die anderen Border Spine-Geräte konfigurieren, indem Sie ähnliche Konfigurationsschritte anwenden.
Wiederholen Sie diese Verfahren für alle Border Spine-Geräte in jedem Datencenter.
Die vollständigen Konfigurationen, die in diesem Beispiel verwendet werden, finden Sie unter Detaillierte Konfigurationen für das EVPN-VXLAN-Netzwerk für die Datencenter .
Border Spine WAN-Underlay
Verfahren
Schritt-für-Schritt-Anleitung
Fügen Sie die WAN-Peering-Sitzung der vorhandenen Underlay-Gruppe in Datencenter 1 Spine 1 (DC1-Spine1) hinzu. Die Border-Spine-Geräte verwenden das WAN-Underlay-Netzwerk, um Loopback-Adressinformationen zwischen den Datencentern auszutauschen. Dies wiederum ermöglicht es den Spine-Geräten, eine eBGP-Overlay-Verbindung über die WAN-Cloud zu bilden.
set protocols bgp group UNDERLAY neighbor 172.16.1.6 peer-as 65199
In diesem Beispiel wird das WAN-Router-Peering zur bereits vorhandenen
UNDERLAYBGP-Peergruppe hinzugefügt. Da diese Gruppe bereits als Teil des Underlays des DC konfiguriert ist, müssen Sie nur den WAN-Router als Nachbarn zur vorhandenenUNDERLAYGruppe hinzufügen.Fügen Sie das WAN-Peering der vorhandenen
UNDERLAYGruppe in Datencenter 2 Spine 1 (DC2-Spine1) hinzu.set protocols bgp group UNDERLAY neighbor 172.16.1.8 peer-as 65299
Konfigurieren Sie die gemeinsame WAN-Underlay-Richtlinie, die auf den Spine- und Leaf-Geräten in beiden Datencentern verwendet wird. Wir reservieren das Subnetz 10.80.224.128/25 für die Loopback-Adresse in Datencenter 1 und das Subnetz 10.0.0.0/24 für die Loopback-Adresse in Datencenter 2. Durch die Angabe eines reservierten Bereichs von Loopbackadressen in unserer Richtlinie müssen wir die Richtlinie nicht aktualisieren, wenn ein Gerät hinzugefügt wird, solange das Gerät mit einer reservierten Loopbackadresse konfiguriert ist.
set policy-options policy-statement UNDERLAY-EXPORT term LOOPBACK from route-filter 10.80.224.128/25 orlonger set policy-options policy-statement UNDERLAY-EXPORT term LOOPBACK from route-filter 10.0.0.0/24 orlonger set policy-options policy-statement UNDERLAY-EXPORT term LOOPBACK then accept set policy-options policy-statement UNDERLAY-EXPORT term DEFAULT then reject set policy-options policy-statement UNDERLAY-IMPORT term LOOPBACK from route-filter 10.80.224.128/25 orlonger set policy-options policy-statement UNDERLAY-IMPORT term LOOPBACK from route-filter 10.0.0.0/24 orlonger set policy-options policy-statement UNDERLAY-IMPORT term LOOPBACK then accept set policy-options policy-statement UNDERLAY-IMPORT term DEFAULT then reject
In diesem Beispiel tauscht das Underlay nur Loopback-Routen sowohl innerhalb als auch zwischen den DCs aus. Die Import- und Exportrichtlinien für das Underlay sind so geschrieben, dass sie von allen Geräten in beiden DCs verwendet werden können. Beispielsweise ist die
UNDERLAY-EXPORTRichtlinie so konfiguriert, dass sie sowohl mit der lokalen als auch mit der Remote-DC-Loopback-Adresse übereinstimmt. Bei Anwendung auf ein Gerät in DC1 wird nur der10.80.224.128/25 orlongerBegriff abgeglichen. Wenn der zusätzlicheroute-filterBegriff für die Loopbackadressen DC2 zugewiesen ist, kann kein Schaden angerichtet werden, und es kann die gleiche Richtlinie auf das Underlay in beiden DCs angewendet werden.
WAN-Overlay mit Border Spine
Schritt-für-Schritt-Anleitung
Für das Fabric-Overlay konfigurieren Sie mithilfe von eBGP ein vollständiges Netz von eBGP-Peering zwischen allen Border Spine-Geräten in beiden Datencentern. Die Spine-Geräte fungieren als Overlay-Routenreflektoren innerhalb ihres jeweiligen DC. Die Overlay-Peering-Sitzung erweitert das EVPN-Overlay zwischen den DCs.
Da die Inter-DC-Overlay-Sitzung über eine WAN-Cloud ausgeführt wird, ist die bidirektionale Fehlererkennung (BFD) für diese Peergruppe nicht aktiviert. BFD kann in jedem DC ausgeführt werden, sowohl im Underlay als auch im Overlay.
Standardmäßig ändert eBGP die IP-Adresse im Feld Protocol Next-Hop so, dass bei der erneuten Ankündigung von Routen die eigene IP-Adresse verwendet wird. In diesem Fall soll das Next-Hop-Feld des Protokolls die VTEP-IP-Adresse des Leaf-Geräts verwenden, von dem die Route stammt. Um zu verhindern, dass BGP die nächsten Hops von Overlay-Routen ändert, aktivieren wir die no-nexthop-change Option in der OVERLAY_INTERDC Peer-Gruppe.
Konfigurieren Sie das WAN-Overlay-Netzwerk auf DC1-Spine1.
set protocols bgp group OVERLAY_INTERDC type external set protocols bgp group OVERLAY_INTERDC description "Group for overlay EBGP peering to remote DC" set protocols bgp group OVERLAY_INTERDC multihop no-nexthop-change set protocols bgp group OVERLAY_INTERDC local-address 10.80.224.149 set protocols bgp group OVERLAY_INTERDC family evpn signaling delay-route-advertisements minimum-delay routing-uptime 480 set protocols bgp group OVERLAY_INTERDC local-as 64730 set protocols bgp group OVERLAY_INTERDC multipath multiple-as set protocols bgp group OVERLAY_INTERDC neighbor 10.0.0.2 peer-as 64830 set protocols bgp group OVERLAY_INTERDC neighbor 10.0.0.3 peer-as 64830
Konfigurieren Sie das WAN-Overlay-Netzwerk auf DC2-Spine1.
set protocols bgp group EVPN_FABRIC type internal set protocols bgp group OVERLAY_INTERDC type external set protocols bgp group OVERLAY_INTERDC description "Group for overlay EBGP peering to remote DC" set protocols bgp group OVERLAY_INTERDC multihop no-nexthop-change set protocols bgp group OVERLAY_INTERDC local-address 10.0.0.2 set protocols bgp group OVERLAY_INTERDC family evpn signaling delay-route-advertisements minimum-delay routing-uptime 480 set protocols bgp group OVERLAY_INTERDC local-as 64830 set protocols bgp group OVERLAY_INTERDC multipath multiple-as set protocols bgp group OVERLAY_INTERDC neighbor 10.80.224.149 peer-as 64730 set protocols bgp group OVERLAY_INTERDC neighbor 10.80.224.150 peer-as 64730
Konfigurieren der Leaf-Geräte für die Unterstützung von Layer 2 DCI
Um die Layer-2-Konnektivität (VLAN) auf die beiden DCs auszudehnen, müssen wir das Netzwerk so konfigurieren, dass die Layer-2-Broadcast-Domäne für alle Endpunkte im gemeinsam genutzten VLAN erweitert wird. In diesem Beispiel gehören die Endgeräte in den VLANs 202 und 203 zur gleichen Layer-2-Domäne, unabhängig davon, ob sich die Endgeräte in den lokalen oder Remote-Datencentern befinden. Ziel ist es, diese VLANs zwischen den beiden DCs zu erweitern oder zu strecken.
Um die Layer-2-Konnektivität für diese gemeinsam genutzten VLANs zwischen den DCs zu erweitern, müssen Sie Folgendes konfigurieren:
-
Konfigurieren Sie eindeutige, auf VXLAN Network Identifier (VNI) basierende Routenziele für EVPN-Routen vom Typ 2 und EVPN Typ 3, die den ausgeweiteten VLANs unter der
protocols evpnHierarchie zugeordnet sind. -
Wenden Sie eine Importrichtlinie an, um die eindeutigen Routenziele zu akzeptieren, die an die ausgeweiteten VLANS gebunden sind, indem Sie den
vrf-importBefehl in der Hierarchieswitch-optionsverwenden. Bei den ausgeweiteten VLANs handelt es sich um EVPN-Routen vom Typ 2 und Typ 3, die vom Remote-Datencenter angekündigt werden.
Wiederholen Sie diese Vorgänge für alle Leaf-Geräte im entsprechenden Datencenter. Die unten gezeigten Befehle werden zu den vorhandenen switch-options und protocols evpn Hierarchien hinzugefügt, um die gemeinsam genutzten VLANs zwischen den beiden DCs zu strecken.
Verfahren
Schritt-für-Schritt-Anleitung
Konfigurieren Sie VNI-spezifische Ziele für die ausgeweiteten VLANs in Datencenter 1 Leaf 1 (DC1-Leaf1).
set protocols evpn vni-options vni 1202 vrf-target target:64730:202 set protocols evpn vni-options vni 1203 vrf-target target:64730:203
Konfigurieren Sie eine VRF-Importrichtlinie, die mit den VNI-Zielen für die ausgeweiteten VLANs in Data Center 1 Leaf 1 (DC1-Leaf1) übereinstimmt. Die Richtlinie stimmt auch mit den standardmäßigen EVPN-Routen vom Typ 1 überein, die für die automatische Erkennung (AD) verwendet werden. Die Richtlinie selbst wird in einem späteren Schritt definiert.
set switch-options vrf-import OVERLAY_IMPORT
Konfigurieren Sie VNI-spezifische Ziele für die ausgeweiteten VLANs im Datencenter 2 Leaf 1 (DC2-Leaf1).
set protocols evpn vni-options vni 1202 vrf-target target:64830:202 set protocols evpn vni-options vni 1203 vrf-target target:64830:203 03
Geben Sie eine VRF-Importrichtlinie an, die auf den VNI-Zielen für die ausgeweiteten VLANs in Data Center 2 Leaf 1 (DC2-Leaf1) übereinstimmen soll.
set switch-options vrf-import OVERLAY_IMPORT
Definieren Sie die VRF-Importrichtlinie, die Sie im vorherigen Schritt in der Hierarchie
switch-options vrf-importkonfiguriert haben. In diesem Beispiel verwenden wir eindeutige Routenziele für jedes Datencenter und für jede Layer-2-Domäne, die zwischen den DCs erweitert wird. Die Richtlinie ist so eingestellt, dass die AD-Route des EVPN-Typs 1, die jedem DC/POD zugeordnet ist, sowie die Routen vom Typ 2 und EVPN vom Typ 3, die von den ausgeweiteten VLANs in beiden Datencentern verwendet werden, importiert werden.Diese Richtlinie sollte auf allen Leaf-Geräten in beiden DCs konfiguriert werden.
Hinweis:In Ihrer Bereitstellung können Sie ein gemeinsames Routenziel für die Leaf-Geräte in Ihren Datencentern verwenden. Wenn Sie ein gemeinsames Routenziel verwenden, werden die Routen aus den Datencentern automatisch als Teil der impliziten Importrichtlinie importiert.
set policy-options policy-statement OVERLAY_IMPORT term 5 from community comm_pod1 set policy-options policy-statement OVERLAY_IMPORT term 5 then accept set policy-options policy-statement OVERLAY_IMPORT term 10 from community comm_pod2 set policy-options policy-statement OVERLAY_IMPORT term 10 then accept set policy-options policy-statement OVERLAY_IMPORT term 20 from community shared_202_fm_pod2 set policy-options policy-statement OVERLAY_IMPORT term 20 from community shared_202_fm_pod1 set policy-options policy-statement OVERLAY_IMPORT term 20 from community shared_203_fm_pod2 set policy-options policy-statement OVERLAY_IMPORT term 20 from community shared_203_fm_pod1 set policy-options policy-statement OVERLAY_IMPORT term 20 then accept set policy-options community comm_pod1 members target:64730:999 set policy-options community comm_pod2 members target:64830:999 set policy-options community shared_202_fm_pod1 members target:64730:202 set policy-options community shared_202_fm_pod2 members target:64830:202 set policy-options community shared_203_fm_pod1 members target:64730:203 set policy-options community shared_203_fm_pod2 members target:64830:203
Die Werte, die für die Communities und
comm_po2verwendet werden, stimmen mit den Werten überein, diecomm_pod1in der Hierarchie dervrf-target statementswitch-optionsLeaf-Geräte in DC1 bzw. DC2 angegeben sind. Dies ist das Routenziel, das allen EVPN-Routen vom Typ 1 hinzugefügt wird, die für die automatische Erkennung verwendet werden. Dieses Ziel wird auch an alle anderen EVPN-Routen angefügt, für die in der Hierarchieprotocols evpnkein VNI-spezifisches Ziel angegeben ist.In diesem Beispiel sind die ausgeweiteten VLANs für die Verwendung VNI-spezifischer Ziele konfiguriert. Daher wird die Importrichtlinie so geschrieben, dass sie auf allen drei Zielen übereinstimmt, die von jedem DC verwendet werden. Auch dieser Ansatz ermöglicht die Verwendung einer gemeinsamen Richtlinie für alle Leaf-Geräte in beiden DCs.
Anforderungen
Konfigurieren der Leaf-Geräte für die Unterstützung von Layer 3 DCI
EVPN-Routen vom Typ 5 werden für die Layer-3-Konnektivität zwischen DCs für VLANs verwendet, die nicht gestreckt sind. Eine EVPN-Route vom Typ 5 wird auch als IP-Präfix-Route bezeichnet. Mit anderen Worten, eine Route vom Typ 5 wird verwendet, wenn die Layer-2-Broadcast-Domäne auf das Datencenter beschränkt ist. EVPN-Routen vom Typ 5 ermöglichen Layer-3-Konnektivität, indem sie das IP-Präfix der IRB-Schnittstelle ankündigen, die nicht erweiterten VLANs zugeordnet ist. In diesem Beispiel sind die VLANs (10, 11, 12) auf Datencenter 1 beschränkt, während die VLANs (170, 171, 172) auf Datencenter 2 beschränkt sind. Wir stellen eine Layer-3-Konnektivität zwischen Datencentern zwischen den Mitgliedern dieser VLANs her, indem wir IP-Präfix-Routen verwenden.
Verfahren
Schritt-für-Schritt-Anleitung
Konfigurieren Sie Layer 3 DCI auf DC1-Leaf1, indem Sie eine Layer-3-VRF mit Unterstützung für EVPN-Routen vom Typ 5 definieren.
set routing-instances TENANT_1_VRF description "VRF for Tenant_1" set routing-instances TENANT_1_VRF instance-type vrf set routing-instances TENANT_1_VRF interface irb.10 set routing-instances TENANT_1_VRF interface irb.11 set routing-instances TENANT_1_VRF interface irb.12 set routing-instances TENANT_1_VRF interface irb.202 set routing-instances TENANT_1_VRF interface irb.203 set routing-instances TENANT_1_VRF interface lo0.1 set routing-instances TENANT_1_VRF route-distinguisher 10.80.225.140:9999 set routing-instances TENANT_1_VRF vrf-import VRF1_VRF1_T5_RT_IMPORT set routing-instances TENANT_1_VRF vrf-export VRF1_VRF1_T5_RT_EXPORT set routing-instances TENANT_1_VRF vrf-target target:1:65001 set routing-instances TENANT_1_VRF vrf-table-label set routing-instances TENANT_1_VRF routing-options multipath set routing-instances TENANT_1_VRF protocols evpn ip-prefix-routes advertise direct-nexthop set routing-instances TENANT_1_VRF protocols evpn ip-prefix-routes encapsulation vxlan set routing-instances TENANT_1_VRF protocols evpn ip-prefix-routes vni 9999 set routing-instances TENANT_1_VRF protocols evpn ip-prefix-routes export T5_EXPORT
Konfigurieren Sie Layer 3 DCI auf DC2-Leaf1, indem Sie eine Layer 3 VRF mit Unterstützung für EVPN Typ 5-Routen definieren.
set routing-instances TENANT_1_VRF description "VRF for Tenant_1" set routing-instances TENANT_1_VRF instance-type vrf set routing-instances TENANT_1_VRF interface irb.170 set routing-instances TENANT_1_VRF interface irb.171 set routing-instances TENANT_1_VRF interface irb.172 set routing-instances TENANT_1_VRF interface irb.202 set routing-instances TENANT_1_VRF interface irb.203 set routing-instances TENANT_1_VRF interface lo0.1 set routing-instances TENANT_1_VRF route-distinguisher 10.0.1.19:9999 set routing-instances TENANT_1_VRF vrf-import VRF1_T5_RT_IMPORT set routing-instances TENANT_1_VRF vrf-export VRF1_T5_RT_EXPORT set routing-instances TENANT_1_VRF vrf-target target:1:65001 set routing-instances TENANT_1_VRF vrf-table-label set routing-instances TENANT_1_VRF routing-options multipath set routing-instances TENANT_1_VRF protocols evpn ip-prefix-routes advertise direct-nexthop set routing-instances TENANT_1_VRF protocols evpn ip-prefix-routes encapsulation vxlan set routing-instances TENANT_1_VRF protocols evpn ip-prefix-routes vni 9999 set routing-instances TENANT_1_VRF protocols evpn ip-prefix-routes export T5_EXPORT
Konfigurieren der Layer-3-DCI-Richtlinie für alle Leaf-Geräte in DC1
set policy-options policy-statement T5_EXPORT term fm_direct from protocol direct set policy-options policy-statement T5_EXPORT term fm_direct then accept set policy-options policy-statement T5_EXPORT term fm_static from protocol static set policy-options policy-statement T5_EXPORT term fm_static then accept set policy-options policy-statement T5_EXPORT term fm_v4_host from protocol evpn set policy-options policy-statement T5_EXPORT term fm_v4_host from route-filter 0.0.0.0/0 prefix-length-range /32-/32 set policy-options policy-statement T5_EXPORT term fm_v4_host then accept set policy-options policy-statement T5_EXPORT term fm_v6_host from protocol evpn set policy-options policy-statement T5_EXPORT term fm_v6_host from route-filter 0::0/0 prefix-length-range /128-/128 set policy-options policy-statement T5_EXPORT term fm_v6_host then accept set policy-options policy-statement VRF1_T5_RT_EXPORT term t1 then community add target_t5_pod1 set policy-options policy-statement VRF1_T5_RT_EXPORT term t1 then accept set policy-options policy-statement VRF1_T5_RT_IMPORT term t1 from community target_t5_pod1 set policy-options policy-statement VRF1_T5_RT_IMPORT term t1 then accept set policy-options policy-statement VRF1_T5_RT_IMPORT term t2 from community target_t5_pod2 set policy-options policy-statement VRF1_T5_RT_IMPORT term t2 then accept set policy-options community target_t5_pod1 members target:64730:9999 set policy-options community target_t5_pod2 members target:64830:9999
Konfigurieren der Layer-3-DCI-Richtlinie für alle Leaf-Geräte in DC2
set policy-options policy-statement T5_EXPORT term fm_direct from protocol direct set policy-options policy-statement T5_EXPORT term fm_direct then accept set policy-options policy-statement T5_EXPORT term fm_static from protocol static set policy-options policy-statement T5_EXPORT term fm_static then accept set policy-options policy-statement T5_EXPORT term fm_v4_host from protocol evpn set policy-options policy-statement T5_EXPORT term fm_v4_host from route-filter 0.0.0.0/0 prefix-length-range /32-/32 set policy-options policy-statement T5_EXPORT term fm_v4_host then accept set policy-options policy-statement T5_EXPORT term fm_v6_host from protocol evpn set policy-options policy-statement T5_EXPORT term fm_v6_host from route-filter 0::0/0 prefix-length-range /128-/128 set policy-options policy-statement T5_EXPORT term fm_v6_host then accept set policy-options policy-statement VRF1_T5_RT_EXPORT term t1 then community add target_t5_pod2 set policy-options policy-statement VRF1_T5_RT_EXPORT term t1 then accept set policy-options policy-statement VRF1_T5_RT_IMPORT term t1 from community target_t5_pod1 set policy-options policy-statement VRF1_T5_RT_IMPORT term t1 then accept set policy-options policy-statement VRF1_T5_RT_IMPORT term t2 from community target_t5_pod2 set policy-options policy-statement VRF1_T5_RT_IMPORT term t2 then accept set policy-options community target_t5_pod1 members target:64730:9999 set policy-options community target_t5_pod2 members target:64830:9999
Alternative Richtlinienkonfiguration zum Importieren von Routenzielen
Anforderungen
In diesem Beispiel enthalten die automatisch abgeleiteten Routenziele die Overlay-AS-Nummer als Teil ihrer Kennung. Das Ergebnis sind unterschiedliche Routenziele für denselben VNI in Datencenter 1 und Datencenter 2.
Für eine einfachere Richtlinienkonfiguration können Sie Routenziele automatisch ableiten, indem Sie die vrf-target Anweisung mit der Option in der auto switch-options Hierarchie einfügen. Wenn Sie diese Option aktivieren vrf-target auto, erstellt Junos automatisch die Routenziele, die für Routen der EVPN-Typen 2 und 3 verwendet werden. Bei EVPN-VXLAN wird das Routenziel automatisch aus dem VXLAN Network Identifier (VNI) abgeleitet. In diesem Beispiel sind die automatisch abgeleiteten EVPN-Routenziele vom Typ 2 und Typ 3 für VNI 1202 target:64730:268436658 in Datencenter 1 und target:64830:268436658 in Datencenter 2. Diese Routenziele werden dann an zugeordnete EVPN-Routen vom Typ 2 und Typ 3 angehängt. Die vrf-target auto Anweisung erstellt eine implizite Importrichtlinie, um dieselben Routenzielwerte für diese VNIs abzugleichen und zu importieren.
Mit der einfacheren Richtlinie werden die EVPN-Routen vom Typ 2 und 3 für VLAN 202 und 203 nicht automatisch importiert. Um EVPN-Routen vom Typ 2 und 3 aus einem Datencenter mit einer anderen autonomen Systemnummer zu importieren, fügen Sie die vrf-target auto import-as Anweisung ein.
Hier ist das Konfigurationsbeispiel für Leaf 1 in Datencenter 1.
set switch-options vrf-import OVERLAY_IMPORT set switch-options vrf-target target:64730:999 set switch-options vrf-target auto import-as 64830 vni-list 1202 set switch-options vrf-target auto import-as 64830 vni-list 1203 set protocols evpn extended-vni-list 110 set protocols evpn extended-vni-list 111 set protocols evpn extended-vni-list 112 set protocols evpn extended-vni-list 1202 set protocols evpn extended-vni-list 1203 set policy-options policy-statement OVERLAY_IMPORT term 5 from community comm_pod1 set policy-options policy-statement OVERLAY_IMPORT term 5 then accept set policy-options policy-statement OVERLAY_IMPORT term 10 from community comm_pod2 set policy-options policy-statement OVERLAY_IMPORT term 10 then accept set policy-options community comm_pod1 members target:64730:999 set policy-options community comm_pod2 members target:64830:999
Überprüfung
Verfahren
Anforderungen
Übersicht
BGP-Peering verifizieren
- #verify-BGP-peering__d2091e390
- Verifizieren von VTEPs in einem Leaf-Gerät
- EVPN-Typ-1-Routen verifizieren
- Überprüfen von EVPN-Typ-2-Routen
- Verifizieren der Layer-3-DCI
Zweck
Überprüfen Sie die Underlay-, Overlay- und Inter-DC-BGP-Peering-Sitzungen.
Aktion
Stellen Sie sicher, dass alle Underlay- und Overlay-BGP-Peering-Sitzungen eingerichtet sind. Dazu gehört auch das eBGP-Overlay-Peering zwischen DCs, die über die WAN-Cloud gebildet werden.
Das Folgende stammt vom DC2-Spine1-Gerät in DC2. Alle BGP-Peering-Sitzungen sollten auf allen Leaf- und Spines-Geräten in beiden DCs eingerichtet werden.
user@dc2spine1> show bgp summary
Threading mode: BGP I/O
Groups: 3 Peers: 9 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0
10 5 0 0 0 0
bgp.evpn.0
99 99 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.0.0.14 64830 11634 11582 0 1 8:49:40 Establ
bgp.evpn.0: 36/36/36/0
10.0.0.18 64830 11646 11604 0 2 8:49:40 Establ
bgp.evpn.0: 36/36/36/0
10.0.0.19 64830 11652 11603 0 3 8:49:38 Establ
bgp.evpn.0: 36/36/36/0
10.80.224.149 64730 11621 11622 0 6 8:49:31 Establ
bgp.evpn.0: 27/27/27/0
10.80.224.150 64730 11630 11600 0 6 8:49:31 Establ
bgp.evpn.0: 27/27/27/0
172.16.0.1 65019 11640 11582 0 2 8:49:39 Establ
inet.0: 1/1/1/0
172.16.0.3 65018 11634 11583 0 1 8:49:42 Establ
inet.0: 1/1/1/0
172.16.1.5 65229 11678 11500 0 1 8:49:43 Establ
inet.0: 3/8/3/0
172.16.1.8 65229 11688 11581 0 1 8:49:43 Establ
inet.0: 3/8/3/0
Bedeutung
Die Ausgabe auf DC2-Spine1 bestätigt, dass alle BGP-Sitzungen eingerichtet wurden. Es gibt eine Underlay- und Overlay-Sitzung pro lokalem Leaf sowie die WAN-Peering-Sitzung und die 2 Overlay-Peering-Sitzungen zu den Spine-Geräten im Remote-DC. Damit erhöht sich die Gesamtzahl der Sitzungen auf 9. Die Möglichkeit, das Overlay-Peering zum Remote-DC einzurichten, bestätigt den ordnungsgemäßen Austausch von Underlay-Routen über die WAN-Cloud.
Verifizieren von VTEPs in einem Leaf-Gerät
Zweck
Überprüfen Sie die Layer-2-Verbindung zwischen zwei Leaf-Geräten in unterschiedlichen Datencentern.
Aktion
Stellen Sie sicher, dass VTEP-Schnittstellen auf den Leaf-Geräten sowohl im lokalen als auch im Remote-Datencenter aktiviert sind.
Im Folgenden finden Sie einen Ausschnitt aus der Ausgabe des VTEP-Status von einem Leaf in Datencenter 1.
user@dc1leaf1> show interfaces vtep
Physical interface: vtep, Enabled, Physical link is Up
Interface index: 641, SNMP ifIndex: 508
Type: Software-Pseudo, Link-level type: VxLAN-Tunnel-Endpoint, MTU: Unlimited, Speed: Unlimited
Device flags : Present Running
Link type : Full-Duplex
Link flags : None
Last flapped : Never
Input packets : 0
Output packets: 0
.
.
.
Logical interface vtep.32769 (Index 555) (SNMP ifIndex 539)
Flags: Up SNMP-Traps Encapsulation: ENET2
VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 10.80.224.141, L2 Routing Instance: default-switch, L3 Routing Instance: default
Input packets : 731317
Output packets: 469531709
Protocol eth-switch, MTU: Unlimited
Flags: Trunk-Mode
.
.
.
Logical interface vtep.32770 (Index 572) (SNMP ifIndex 541)
Flags: Up SNMP-Traps Encapsulation: ENET2
VXLAN Endpoint Type: Remote, VXLAN Endpoint Address: 10.0.0.18, L2 Routing Instance: default-switch, L3 Routing Instance: default
Input packets : 136973831
Output packets: 141901343
Protocol eth-switch, MTU: Unlimited
Flags: Trunk-Mode
.
.
.
Bedeutung
Die Ausgabe auf DC1-Leaf1 zeigt, dass Layer-2-VXLAN-Tunnel zwischen diesem Leaf-Gerät und den anderen Leaf-Geräten in der lokalen Datencenter-Fabric erstellt werden (die VTEP-Adresse von Leaf 2 in DC1 wird im Snippet angezeigt). Die Ausgabe zeigt auch, dass VTEPs zwischen diesem Leaf-Gerät und den anderen Leaf-Geräten in der Remote-Datencenter-Fabric gelernt werden (der VTEP für Leaf 2 in DC2 wird im Snippet angezeigt). Die Zähler für Eingabe- und Ausgabepakete überprüfen die erfolgreiche Datenübertragung zwischen Endpunkten auf diesen VTEPs.
EVPN-Typ-1-Routen verifizieren
Zweck
Vergewissern Sie sich, dass der Routing-Tabelle EVPN-Routen vom Typ 1 hinzugefügt werden.
Aktion
Stellen Sie sicher, dass die EVPN Typ1 (AD/ESI)-Route empfangen und installiert wurde.
user@dc1leaf1>show route | match 1:10.0.0.181:10.0.0.18:0::0202020201::FFFF:FFFF/192 AD/ESI 1:10.0.0.18:0::0202020202::FFFF:FFFF/192 AD/ESI user@dc1leaf1>show route extensive | find 1:10.0.0.18:0::0202020201:1:10.0.0.18:0::0202020201::FFFF:FFFF/192 AD/ESI (1 entry, 0 announced) *BGP Preference: 170/-101 Route Distinguisher: 10.0.0.18:0 Next hop type: Indirect, Next hop index: 0 Address: 0xbd78c94 Next-hop reference count: 50 Source: 10.80.224.149 Protocol next hop: 10.0.0.18 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 State: <Active Int Ext> Local AS: 64730 Peer AS: 64730 Age: 1:22 Metric2: 0 Validation State: unverified Task: BGP_64730.10.80.224.149 AS path: 64830 I Communities: target:64830:999 encapsulation:vxlan(0x8) esi-label:0x0:all-active (label 0) Import Accepted Route Label: 1 Localpref: 100 Router ID: 10.80.224.149 Secondary Tables: default-switch.evpn.0 Indirect next hops: 1 Protocol next hop: 10.0.0.18 Indirect next hop: 0x2 no-forward INH Session ID: 0x0 Indirect path forwarding next hops: 1 Next hop type: Router Next hop: 10.80.224.2 via et-0/0/49.0 Session Id: 0x0 10.0.0.18/32 Originating RIB: inet.0 Node path count: 1 Forwarding nexthops: 1 Nexthop: 10.80.224.2 via et-0/0/49.0 Session Id: 0
Zeigen Sie Informationen zu EVPN-Routing-Instanzen an. Der folgende Ausschnitt stammt von Blatt 1 in DC1.
user@dc1leaf1> show evpn instance extensive
Instance: __default_evpn__
Route Distinguisher: 10.80.224.140:0
Number of bridge domains: 0
Number of neighbors: 0
. . .
ESI: 00:00:00:00:00:02:02:02:02:01
Status: Resolved
Number of remote PEs connected: 2
Remote PE MAC label Aliasing label Mode
10.0.0.19 1203 0 all-active
10.0.0.18 0 0 all-active
ESI: 00:00:00:00:00:02:02:02:02:02
Status: Resolved
Number of remote PEs connected: 2
Remote PE MAC label Aliasing label Mode
10.0.0.19 0 0 all-active
10.0.0.18 0 0 all-active
. . .
Bedeutung
Diese Ausgaben zeigen, dass DC1-Leaf1 EVPN Typ1 (AD/ESI)-Routen vom Remote-Datencenter empfangen hat. Sie können die Ausgabe des show route extensive Befehls verwenden, um anzuzeigen, dass diese Routen das Routenziel "target:64830:999" haben und dass diese Routen erfolgreich installiert wurden. Die ESI 02:02:02:02:01 und 02:02:02:02:02 sind Ethernet-Segmente im Remote-Datencenter. Diese Ausgabe zeigt auch, dass die Remote-PEs mit den IP-Adressen 10.0.0.18 und 10.0.0.19 Teil dieser Ethernet-Segmente sind.
Überprüfen von EVPN-Typ-2-Routen
Zweck
Stellen Sie sicher, dass der Routing-Tabelle EVPN-Routen vom Typ 2 hinzugefügt werden.
Aktion
Vergewissern Sie sich, dass eine EVPN-Route vom Typ 2 empfangen und in der Routing-Tabelle auf einem Leaf-Gerät in Datencenter 1 installiert wurde.
Verwenden Sie show route, um einen Endpunkt in VLAN 203 zu finden, der sich im Remote-Datencenter befindet.
user@dc1leaf1>show route | match 00:10:94:00:00:06
2:10.0.0.18:1::1203::00:10:94:00:00:06/304 MAC/IP
2:10.0.0.18:1::1203::00:10:94:00:00:06::10.1.203.151/304 MAC/IP
Verwenden Sie die Detailansicht für Route anzeigen, um weitere Details anzuzeigen.
user@dc1leaf1> show route extensive | find 2:10.0.0.18:1::1203::00:10:94:00:00:06::10.1.203.151/304
2:10.0.0.18:1::1203::00:10:94:00:00:06::10.1.203.151/304 MAC/IP (1 entry, 0 announced)
*BGP Preference: 170/-101
Route Distinguisher: 10.0.0.18:1
Next hop type: Indirect, Next hop index: 0
Address: 0xbd78c94
Next-hop reference count: 58
Source: 10.80.224.149
Protocol next hop: 10.0.0.18
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State: <Active Int Ext>
Local AS: 64730 Peer AS: 64730
Age: 1:31 Metric2: 0
Validation State: unverified
Task: BGP_64730.10.80.224.149
AS path: 64830 I
Communities: target:64830:203 encapsulation:vxlan(0x8)
Import Accepted
Route Label: 1203
ESI: 00:00:00:00:00:00:00:00:01:01
Localpref: 100
Router ID: 10.80.224.149
Secondary Tables: default-switch.evpn.0
Indirect next hops: 1
Protocol next hop: 10.0.0.18
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.80.224.2 via et-0/0/49.0
Session Id: 0x0
10.0.0.18/32 Originating RIB: inet.0
Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.80.224.2 via et-0/0/49.0
Session Id: 0
Verwenden Sie den show vlans Befehl, um die Informationen zu VLAN 203 zu finden.
user@dc1leaf1> show vlans v203
Routing instance VLAN name Tag Interfaces
default-switch v203 203
esi.1860*
vtep.32769*
vtep.32770*
vtep.32772*
xe-0/0/1.0*
Die obige Ausgabe zeigt, dass VLAN 203 auf VTEPs "vtep.32769 - 10.80.224.141 - DC1-Leaf2", "vtep.32772 - 10.0.0.18 - DC2-Leaf2", "vtep.32770 - 10.0.0.19 - DC2-Leaf1" konfiguriert ist. Die Ausgabe zeigt auch an, dass auf diesen VTEPs Endpunkte mit VLAN v203 verbunden sind. Sie können verwenden show interfaces VTEP , um die VTEP-IP-Adresse für diese VTEPs abzurufen. Verwenden Sie die show evpn database show ethernet-switching-table Befehle und , um die MAC-Adresse und IP-Adresse für diese Endpunkte zu ermitteln.
Verwenden Sie die , show evpn database um Einträge in der EVPN-Datenbank zu finden.
user@dc1leaf1> show evpn database neighbor 10.0.0.18
Instance: default-switch
VLAN DomainId MAC address Active source Timestamp IP address
1202 3c:8c:93:2e:a8:c0 10.0.0.18 Jul 18 23:41:54 10.1.202.18
1203 00:10:94:00:00:06 00:00:00:00:00:02:02:02:02:01 Jul 19 03:16:42 10.1.203.151
1203 3c:8c:93:2e:a8:c0 10.0.0.18 Jul 18 23:41:54 10.1.203.18
Verwenden Sie den show ethernet-switching table Befehl, um Informationen für eine bestimmte MAC-Adresse anzuzeigen.
user@dc1leaf1> show ethernet-switching table 00:10:94:00:00:06
MAC flags (S - static MAC, D - dynamic MAC, L - locally learned, P - Persistent static
SE - statistics enabled, NM - non configured MAC, R - remote PE MAC, O - ovsdb MAC)
Ethernet switching table : 29 entries, 29 learned
Routing instance : default-switch
Vlan MAC MAC Logical Active
name address flags interface source
v203 00:10:94:00:00:06 DR esi.1874 00:00:00:00:00:02:02:02:02:01
Bedeutung
Die Ausgabe zeigt, dass die MAC-Adresse von einem Gerät im VLAN 203 im Remote-PE in der EVPN-Datenbank installiert wurde und sich in der Ethernet-Switching-Tabelle befindet.
Verifizieren der Layer-3-DCI
Zweck
Stellen Sie sicher, dass Layer-3-Routen in der Routing-Tabelle installiert sind.
Aktion
Stellen Sie sicher, dass eine EVPN-Route vom Typ 5 empfangen und in der Routing-Tabelle auf einem Leaf-Gerät in Datencenter 1 installiert wurde.
Stellen Sie sicher, dass Sie EVPN-Routen vom Typ 5 von 10.1.170.0/24 empfangen, dem Subnetz für VLAN 170. Dieses VLAN befindet sich lokal in Datencenter 2. Um dieses Subnetz von Datencenter 1 aus zu erreichen, ist Layer-3-Routing erforderlich.
user@dc1leaf1> show route | match 5: | match 10.1.170.0
5:10.0.1.18:9999::0::10.1.170.0::24/248
5:10.0.1.19:9999::0::10.1.170.0::24/248
. . .
Weitere Details zur EVPN-Typ-5-Route für das Netzwerk 10.1.170.0/24 finden Sie hier. Der Datenverkehr, der von diesem Leaf-Gerät für dieses Subnetz gesendet wird, wird im VXLAN-Tunnel mit VNI 9999 gekapselt und an das Remote-Leaf 10.0.0.18 in Datencenter 2 gesendet.
user@dc1leaf1> show route 10.1.170.0/24 extensive
TENANT_1_VRF.inet.0: 28 destinations, 57 routes (28 active, 0 holddown, 0 hidden)
10.1.170.0/24 (3 entries, 1 announced)
TSI:
KRT in-kernel 10.1.170.0/24 -> {composite(1742)}
*EVPN Preference: 170/-101
Next hop type: Indirect, Next hop index: 0
Address: 0xdfacd74
Next-hop reference count: 9
Next hop type: Router, Next hop index: 1738
Next hop: 10.80.224.2 via et-0/0/49.0, selected
Session Id: 0x0
Protocol next hop: 10.0.0.18
Composite next hops: 1
Protocol next hop: 10.0.0.18
Composite next hop: 0xb959d60 1740 INH Session ID: 0x0
VXLAN tunnel rewrite:
MTU: 0, Flags: 0x0
Encap table ID: 0, Decap table ID: 11
Encap VNI: 9999, Decap VNI: 9999
Source VTEP: 10.80.224.140, Destination VTEP: 10.0.0.18
SMAC: e4:5d:37:ea:98:00, DMAC: 3c:8c:93:2e:a8:c0
Indirect next hop: 0xc710304 131071 INH Session ID: 0x0
Indirect path forwarding next hops: 1
Next hop type: Router
Next hop: 10.80.224.2 via et-0/0/49.0
Session Id: 0x0
10.0.0.18/32 Originating RIB: inet.0
Node path count: 1
Forwarding nexthops: 1
Nexthop: 10.80.224.2 via et-0/0/49.0
Session Id: 0
Die Ausgabe bestätigt, dass Routen für das Subnetz 10.1.170.0/24 in diesem Leaf-Gerät vorhanden sind. Da wir Hostrouten exportieren und importieren, werden die spezifischen EVPN-Hostrouten vom Typ 5 angezeigt.
user@dc1leaf1> show route table TENANT_1_VRF.inet.0 10.1.170.0/24
TENANT_1_VRF.inet.0: 21 destinations, 35 routes (21 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
10.1.170.0/24 @[EVPN/170] 1d 06:38:11
> to 10.80.224.2 via et-0/0/49.0
> to 10.80.224.12 via et-0/0/50.0
[EVPN/170] 1d 06:38:09
> to 10.80.224.2 via et-0/0/49.0
> to 10.80.224.12 via et-0/0/50.0
#[Multipath/255] 1d 06:38:09, metric2 0
> to 10.80.224.2 via et-0/0/49.0
> to 10.80.224.12 via et-0/0/50.0
10.1.170.100/32 @[EVPN/170] 00:00:23
> to 10.80.224.2 via et-0/0/49.0
> to 10.80.224.12 via et-0/0/50.0
[EVPN/170] 00:00:22
> to 10.80.224.2 via et-0/0/49.0
> to 10.80.224.12 via et-0/0/50.0
#[Multipath/255] 00:00:22, metric2 0
> to 10.80.224.2 via et-0/0/49.0
> to 10.80.224.12 via et-0/0/50.0
Die Ausgabe zeigt Routen für das Subnetz 10.1.203.0/24 in diesem Leaf-Gerät. In diesem Fall erstreckt sich VLAN 203 über beide Datencenter. Wenn Sie die EVPN-Routen vom Typ 5 nur auf Subnetzrouten beschränken, haben Sie ein asymmetrisches Inter-VNI-Routing für L2-Stretched-VLANs. Wenn Sie lieber ein symmetrisches Modell für das Inter-VNI-Routing für L2 Stretched VLANs bereitstellen möchten, müssen Sie EVPN-Hostrouten vom Typ 5 exportieren und importieren.
In diesem Beispiel wird die auf die T5_EXPORT TENANT_1_VRF Richtlinie als Exportrichtlinie für das EVPN-Protokoll angewendet, um die Ankündigung von /32-Hostrouten zu bewirken. Daher wird in diesem Beispiel das symmetrische Routing für das Routing zwischen VLANs veranschaulicht, wenn diese VLANs zwischen DCs gestreckt werden.
user@dc1leaf1>show route table TENANT_1_VRF.inet.0 10.1.203.0/24
TENANT_1_VRF.inet.0: 28 destinations, 57 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.1.203.0/24 *[Direct/0] 1d 05:42:50
> via irb.203
[EVPN/170] 1d 05:42:50
> to 10.80.224.2 via et-0/0/49.0
to 10.80.224.12 via et-0/0/50.0
[EVPN/170] 1d 05:42:50
> to 10.80.224.2 via et-0/0/49.0
to 10.80.224.12 via et-0/0/50.0
[EVPN/170] 1d 05:42:50
> to 10.80.224.2 via et-0/0/49.0
to 10.80.224.12 via et-0/0/50.0
[EVPN/170] 1d 05:42:50
> to 10.80.224.2 via et-0/0/49.0
to 10.80.224.12 via et-0/0/50.0
[EVPN/170] 01:06:19
> to 10.80.224.2 via et-0/0/49.0
to 10.80.224.12 via et-0/0/50.0
[EVPN/170] 01:17:41
> to 10.80.224.2 via et-0/0/49.0
to 10.80.224.12 via et-0/0/50.0
10.1.203.1/32 *[Local/0] 1d 05:42:50
Local via irb.203
10.1.203.11/32 *[Local/0] 1d 05:42:50
Local via irb.203
10.1.203.52/32 *[EVPN/7] 02:52:51
> via irb.203
Bedeutung
Diese Ausgabe zeigt, dass sowohl das Subnetz 10.1.203.0/24 als auch die spezifische Hostroute für 10.1.203.52/32 (die IP-Adresse eines Endpunkts in Datencenter 2) installiert wurden. Für die Route 10.1.203.52/32 wird die Route mit mehr EVPN Typ 5 gegenüber der Route EVPN Typ 2 bevorzugt. Dies führt zu symmetrischem Inter-VNI-Routing über Layer 2 Stretched VLANs.