Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

EVPN

  • Standard-Verwerfungsrichtlinie für GBP-Filter (EX4100, EX4400, EX4650 und QFX5120)—Ab Junos OS Version 24.2R1 können Sie gruppenbasierte Richtlinien-Firewall-Filter (GBP) mit einer Standard-Verwerfungsrichtlinie konfigurieren, die angewendet wird, wenn ein Paket eine der Übereinstimmungsbedingungen nicht erfüllt.

    [Siehe Beispiel: Mikro- und Makrosegmentierung mithilfe gruppenbasierter Richtlinien in einem VXLAN.]

  • MAC/IP-Intertagging für GBP-Filter (EX4100, EX4400, EX4650 und QFX5120)—Ab Junos OS Version 24.2R1 können Sie MAC-basierte GBP-Firewall-Filter (Media Access Control) auf gerouteten Datenverkehr und IP-basierte GBP-Firewall-Filter auf geswitchten Datenverkehr anwenden. Dies wird als Inter-Tagging bezeichnet. Bisher wurden MAC-basierte GBP-Filter auf den geswitchten Datenverkehr und IP-basierte GBP-Filter auf gerouteten Datenverkehr angewendet. Durch die Aktivierung von Inter-Tagging werden Ihre MAC- und IP-basierten GBP-Filter sowohl auf gerouteten als auch auf gerouteten Datenverkehr angewendet.

    [Siehe Beispiel: Mikro- und Makrosegmentierung mithilfe gruppenbasierter Richtlinien in einem VXLAN.]

  • Erzwingung von Ingress-Richtlinien und Tag-Weitergabe (EX9204, EX9208 und EX9214): Ab Junos OS Version 24.2R1 unterstützen die Switches EX9204, EX9208 und EX9214 die Durchsetzung von Ingress-Richtlinien (GBP)-Firewall-Filter und GBP-Tag-Propagierung für /32-IP-Routen. Die Durchsetzung von Ingress-Richtlinien und die Weitergabe von GBP-Tags sparen Netzwerkbandbreite, indem getaggte Pakete am Eingang verworfen werden, die andernfalls am Ausgang verworfen würden.

    [Siehe Beispiel: Mikro- und Makrosegmentierung mithilfe gruppenbasierter Richtlinien in einem VXLAN.]

  • GBP-Tag-Weitergabe mithilfe von EVPN-Routenankündigungen vom Typ 5 (EX4400, EX4650 und QFX5120)—Ab Version 24.2R1 unterstützen wir Junos OS Verbreitung von GBP-Tags (gruppenbasierte Richtlinien) mithilfe von EVPN-Routenankündigungen vom Typ 5 von IP-Präfixen. Switches und Router verwenden in der Regel EVPN-Ankündigungen vom Typ 5 für den Austausch von Routen zwischen Datencentern. Vor dieser Version haben wir die EVPN-Routenkonvertierung Typ 2 in Typ 5 zwischen Datencentern unterstützt, was dazu führte, dass /32-IP-Routen anstelle von IP-Präfixrouten ausgetauscht wurden.

    [Siehe Beispiel: Mikro- und Makrosegmentierung mithilfe gruppenbasierter Richtlinien in einem VXLAN.]

  • Unterstützung für Zugriffssicherheit in EVPN-VXLAN-Overlay-Netzwerken (EX4650, QFX5120-32C, QFX5120-48T, QFX5120-48T-VC, QFX5120-48Y, QFX5120-48Y-VC und QFX5120-48YM)—Ab Junos OS Version 24.2R1 unterstützen wir Zugriffssicherheitsfunktionen auf bestimmten EX-Serie- und QFX-Serie-Switches, die als Layer-2-VXLAN-Gateways in einem zentral gerouteten Ethernet VPN-Virtual Extensible LAN (EVPN-VXLAN) Overlay-Netzwerk (zweischichtige IP-Fabric) fungieren. Wir unterstützen die folgenden Funktionen auf Layer 2-Schnittstellen mit Servern, die mit VXLAN-zugeordneten VLANs verknüpft sind:

    Die Zugriffssicherheitsfunktionen funktionieren in einer EVPN-VXLAN-Umgebung genauso und werden auf die gleiche Weise konfiguriert wie in einer Nicht-EVPN-VXLAN-Umgebung. Beachten Sie jedoch die folgenden Unterschiede:

    • Wir unterstützen diese Funktionen nicht auf Multihomed-Servern.

    • Diese Funktionen haben keinen Einfluss auf den VXLAN-Tunneling- und -Kapselungsprozess.

  • MAC-VRF-Instances mit EVPN-VXLAN (EX4100-48MP, EX4100-24MP, EX4100-48P, EX4100-48T, EX4100-24P, EX4100-24T, EX4100-F-48P, EX4100-F-24P, EX4100-F-48T, EX4100-F-24T, EX4100-F-12P, EX4100-F-12T und EX4300-MP) – Die Unterstützung für den mac-vrf Instance-Typ umfasst vlan-based, vlan-awareund vlan-bundle Servicetypen nur für EVPN-Unicast-Routen.

    [Siehe Übersicht über MAC-VRF-Routinginstanztypen, MAC-VRF und Servicetyp.]

  • MAC-VRF mit EVPN-VXLAN (EX9204- und EX9208-Switches): Datencenter-Service Provider müssen mehrere Kunden mit ihren eigenen Routing- und Bridging-Richtlinien im selben physischen Netzwerk unterstützen. Um dieser Anforderung gerecht zu werden, können Sie jetzt mehrere kundenspezifische EVPN-Instanzen (EVIs) des Typs mac-vrfkonfigurieren, von denen jede einen anderen EVPN-Servicetyp unterstützen kann. Diese Konfiguration führt zu kundenspezifischen virtuellen Routing- und Weiterleitungstabellen (VRF) mit MAC-Adressen auf jedem Gerät von Juniper Networks, das als virtueller Tunnelendpunkt (VTEP) im EVPN-VXLAN-Netzwerk (Ethernet VPN-Virtual Extensible LAN) dient.

    Anmerkung:

    Wir unterstützen MAC-VRF-Routing-Instanzen nur für EVPN-Unicast-Routen.

    Zur Unterstützung dieser Funktion führen wir eine einheitliche Routing-Instanzkonfiguration ein, die RFC 7432, BGP MPLS-basiertes Ethernet-VPN, entspricht. Durch die einheitliche Konfiguration entfallen Hardware-Beschränkungen, die die Anzahl der EVIs und die Kombinationen von EVIs mit ihren jeweiligen Richtlinien, die gleichzeitig existieren können, begrenzen. Die allgemeine Konfiguration umfasst die folgenden neuen CLI-Elemente:

    • Das mac-vrf Schlüsselwort auf der [edit routing-instances name instance-type] Hierarchieebene.

    • Die service-type Konfigurationsanweisung auf der [edit routing-instances name] Hierarchieebene. Wir unterstützen VLAN-basierte, VLAN-fähige und VLAN-Bundle-Servicetypen.

    • (Nur Switches der QFX10000-Reihe) Die forwarding-instance Konfigurationsanweisung auf der [edit routing-instances name] Hierarchieebene. Mit dieser optionalen Konfigurationsanweisung können Sie mehrere Routinginstanzen einer einzelnen Weiterleitungsinstanz zuordnen. Wenn Sie diese Konfigurationsanweisung nicht einschließen, wird die Standardweiterleitungsinstanz verwendet.

      Wir unterstützen weiterhin die vorhandene Methode der Routing-Instanzkonfiguration zusammen mit der neuen einheitlichen Routing-Instanzkonfiguration.

      [Siehe EVPN-Benutzerhandbuch.]

  • sFlow-Unterstützung für EVPN-VxLAN-Multicast (EX4100-48MP, EX4100-24MP, EX4100-48P, EX4100-48T, EX4100-24P, EX4100-24T, EX4100-F-12P, EX4400-24MP, EX4400-24P, EX4400-24T, EX4400-24X, EX4400-48F, EX4400-48MP, EX4400-48P und EX4400-48T)—Ab Junos OS Version 24.2R1 können Sie die sFlow-Technologie verwenden, um EVPN-VxLAN-Multicast-Datenverkehr zu erfassen, der auf Schnittstellenebene konfiguriert ist.

    Wir unterstützen Sampling mit Kollektor, der über ein normales Layer-3 (L3)-Gateway (Underlay), Management-IP (erreichbar über Standard- oder Nicht-Standard-Routing-Instanz) oder VXLAN-Tunnel (Overlay) erreichbar ist.

    Um bekanntes Multicast-Sampling zu aktivieren, verwenden Sie den CLI-Befehl set forwarding-options sFlow egress-multicast enable.

    [Siehe Überblick über die sFlow-Technologie.]

  • EVPN-VXLAN-Fabric mit IPv6-Underlay (EX4100-48MP, EX4100-24MP, EX4100-48P, EX4100-24P und EX4100-24T)—Ab Junos OS Version 24.2R1 können Sie eine EVPN-VXLAN (Ethernet VPN-Virtual Extensible LAN)-Fabric mit einem IPv6-Underlay konfigurieren. Sie können diese Funktion nur mit MAC-VRF-Routinginstanzen (alle Servicetypen) verwenden. Sie müssen entweder ein IPv4- oder ein IPv6-Underlay für die EVPN-Instanzen in der Fabric konfigurieren. Es ist nicht möglich, IPv4- und IPv6-Underlays in derselben Fabric zu mischen.

    Um diese Funktion zu aktivieren, führen Sie die folgenden Schritte aus, wenn Sie das EVPN-Underlay konfigurieren:

    • Konfigurieren Sie die Quellschnittstelle des Underlay VXLAN Tunnel Endpoint (VTEP) als IPv6-Adresse:

      set routing-instances mac-vrf-instance-name vtep-source-interface lo0.0 inet6

    • Auch wenn das Underlay die IPv6-Adressfamilie verwendet, müssen Sie die Router-ID in der Routinginstanz mit einer IPv4-Adresse konfigurieren, damit BGP-Handshake im Underlay funktioniert:

      set routing-instances mac-vrf-instance-name routing-options router-id ipv4-address

    Wir unterstützen die folgenden EVPN-VXLAN-Funktionen mit einem IPv6-Underlay:

    [Siehe Grundlegendes zu EVPN mit VXLAN Data Plane-Kapselung und EVPN-Benutzerhandbuch.]

  • L2PT mit Q-in-Q-over-VXLAN-Tunneln in EVPN-VXLAN-Bridged-Overlay-Netzwerken (EX4100-48P, EX4400-48F, QFX5120-32C, QFX5120-48T, QFX5120-48Y und QFX5120-48YM)—Ab Junos OS Version 24.2R1 unterstützen wir Layer-2-Protokoll-Tunneling (L2PT) mit Q-in-Q für den Datenverkehr von einer Zugriffsschnittstelle zu VXLAN-Tunnelzielen in einem Bridged Overlay (BO) Ethernet VPN-Virtual Extensible LAN (EVPN-VXLAN)-Netzwerk. Sie können diese Funktion mit Zugriffsschnittstellenkonfigurationen im Service Provider- oder Enterprise-Stil verwenden.

    Sie können L2PT-over-VXLAN-Tunnel mit allen Q-in-Q-Anwendungsfällen verwenden, die wir für ein EVPN-VXLAN-Netzwerk unterstützen. Bei Q-in-Q tunnelt das Gerät getaggte Frames über VXLAN unter Verwendung des VNI des VLANs im Frame und tunnelt nicht getaggte Frames mit dem VNI des nativen VLANs.

    Um diese Funktion zu aktivieren, konfigurieren Sie die l2pt Anweisung auf der [edit protocols layer2-control] Hierarchieebene mit dem Namen interface name der Zugriffsschnittstelle und den folgenden erforderlichen Optionen:

    • destination vxlan-tunnel– Aktivieren Sie L2PT für den Datenverkehr zu einem VXLAN-Tunnelziel.

    • protocol protocol-name: Geben Sie ein Protokoll für das Tunneln an. Fügen Sie zusätzliche protocol Anweisungen für jedes Protokoll ein, das Sie tunneln möchten.

    [Siehe Layer 2-Protokoll-Tunneling über VXLAN-Tunnel in EVPN-VXLAN-Bridged-Overlay-Netzwerken, Beispiele: Tunneling von Q-in-Q-Datenverkehr in einem EVPN-VXLAN-Overlay-Netzwerk und L2PT (Zieltunnel).]

  • EVPN-Hostrouten vom Typ 5 von DCI zu DC unterdrücken (EX4400-24MP, EX4400-48F, MX304, QFX5120-32C, QFX5120-48T, QFX5120-48T-VC, QFX5120-48Y, QFX5120-48Y-VC und QFX5120-48YM)—Ab Junos OS Version 24.2R1 können Sie Hostroutenankündigungen vom Typ 5 von EVPN unterdrücken, die von der Vernetzung des Datencenters (DCI) zum lokalen DC zurückkehren. Mit dieser Funktion können Sie eine bessere Skalierung und Leistung auf Leaf-Geräten erzielen.

    [Siehe suppress-host-routes-from-dci-to-dc.]

  • Verbessertes OISM in EVPN-VXLAN ERB-Overlay-Netzwerken mit einem IPv6-Underlay (EX4100-48MP, EX4100-24MP, EX4100-48P, EX4100-48T, EX4100-24P, EX4100-24T, EX4100-F-48P, EX4100-F-24P, EX4100-F-48T, EX4100-F-24T, EX4100-F-F -12P, EX4100-F-12T, EX4400-24MP, EX4400-24P, EX4400-24T, EX4400-24X, EX4400-48F, EX4400-48MP, EX4400-48P, EX4400-48T, EX4650, QFX5120-32C, QFX5120-48T, QFX5120-48Y und QFX5120-48YM)—Ab Junos OS Version 24.2R1 können Sie Enhanced Optimized Intersubnet Multicast (OISM) für IPv4- und IPv6-Multicast-Datenverkehr mit einem Ethernet VPN-Virtual Extensible LAN (EVPN-VXLAN) Edge-Routed Bridging (ERB)-Overlay-Netzwerk mit IPv6-Underlay konfigurieren. So konfigurieren Sie diese Funktion:

    • Richten Sie die EVPN-VXLAN-Fabric mit einem IPv6-Underlay ein:

      • Sie können entweder externes BGP (EBGP) oder OSPFv3 mit IPv6-Adressierung für das IPv6-Underlay verwenden.

      • Verwenden Sie diese inet6 Option, wenn Sie die Quellschnittstelle des VXLAN Tunnel Endpoint (VTEP) auf die Geräte-Loopback-Schnittstelle in der EVPN-Instanz (EVI) festlegen:

    • Konfigurieren Sie die erweiterten OISM-Elemente für Ihre Multicast-EVPN-VXLAN-Umgebung auf die gleiche Weise, wie Sie diese Elemente in einem EVPN-VXLAN-Netzwerk mit einem IPv4-Underlay konfigurieren würden.

      Sie können jede der unterstützten Plattformen als erweiterte OISM-Server-Leaf-Geräte konfigurieren und nur EX4650- und QFX5120-Switches als erweiterte OISM-Border-Leaf-Geräte.

    [Siehe EVPN-VXLAN mit einem IPv6-Underlay und optimiertem Intersubnet-Multicast in EVPN-Netzwerken.]

  • Statische Identifizierung von Multihoming-Peer-OISM-Leaf-Geräten in einem EVPN-VXLAN-Netzwerk mit erweitertem OISM (EX4100-24T, EX4300-MP, EX4400-24MP, EX4400-24P, EX4400-48F, EX4400-48MP, EX4650, QFX5120-32C, QFX5120-48T, QFX5120-48T-VC, QFX5120-48Y, QFX5120-48Y-VC und QFX5120-48YM)—Ab Junos OS Version 24.2R1 können Sie ein Multihoming-Peer-Leaf-Gerät statisch so konfigurieren, dass es seine Peers in einem Ethernet VPN-Virtual Extensible LAN (EVPN-VXLAN)-Netzwerk identifiziert, das erweiterte optimierte Intersubnetz-Multicast (OISM) verwenden. EVPN-VXLAN Provider Edge (PE)-Leaf-Geräte sind Multihoming-Peers, wenn sie ein Ethernet-Segment (ES) für einen mehrfach vernetzten Host gemeinsam nutzen. Wenn die Leaf-Geräte statische Informationen über ihre Multihoming-Peers haben, können sie mit erweitertem OISM Multicast-Datenverkehrsverluste vermeiden, wenn ihre Peer-Geräte herunter- und wieder hochfahren.

    Konfigurieren Sie auf jedem Multihoming-Peer-Leaf-Gerät die multihoming-peer-gateways [peer-device-IPv4-address … ] Anweisung auf Hierarchieebene [edit protocols evpn] , um die Multihoming-Peers des Geräts zu identifizieren. Geben Sie eine Liste von Peeradressen in eckigen Klammern an, oder geben Sie eine einzelne Peeradresse ohne eckige Klammern an.

    [Siehe Statisches Identifizieren von Multihoming-Peers mit erweitertem OISM zur Verbesserung der Konvergenz.]

  • Nicht rückgängig machende, präferenzbasierte DF-Auswahl in EVPN-MPLS-Netzwerken (EX4400-24P, MX960 und vMX): Ab Junos OS Version 24.2R1 können Sie eine nicht rückgängig machende, präferenzbasierte DF-Auswahl (Designated Forwarder) für einen Ethernet Segment Identifier (ESI) in einem Ethernet VPN-MPLS-Netzwerk konfigurieren. Standardmäßig ist die präferenzbasierte DF-Auswahl für einen Ethernet Segment Identifier (ESI) umkehrbar, was bedeutet:

    • Wenn das EVPN Provider Edge (PE)-Gerät, das sich derzeit in der DF-Rolle befindet, ausfällt, wird das nächste bevorzugte PE-Gerät zum neuen DF.

    • Wenn das alte DF wieder aktiviert wird, wird die DF-Rolle auf das alte DF zurückgesetzt.

    Das häufige Ändern der aktuellen DF-Rolle für eine ESI-Datei kann sich auf den Datenverkehrsfluss auswirken. Um rückgängig gemachte DF-Rollenänderungen zu vermeiden, können Sie die non-revertive Option jetzt auf Hierarchieebene [edit interfaces name esi df-election-type preference] festlegen.

    Wir bieten auch neue Optionen, die Sie konfigurieren können, um die DF-Auswahl pro EVPN-Instanz (EVI) oder pro ESI basierend auf dem niedrigsten konfigurierten Präferenzwert oder dem höchsten konfigurierten Präferenzwert wie folgt auszugleichen:

    • Auf EVI-Ebene: Verwenden Sie die designated-forwarder-preference-least Option oder die designated-forwarder-preference-highest Option auf der [edit routing-instances evpn-instance-name protocols evpn] Hierarchieebene.

    • Auf ESI-Ebene: Verwenden Sie die least Option auf der Hierarchieebene oder [edit interfaces interface-name esi df-election-type preference] [edit protocols evpn interconnect esi df-election-type preference] .

    [Siehe df-election-type und evpn].

  • EVPN-VXLAN DCI-Multicast-Unterstützung mit erweitertem OISM (EX4400-24MP, EX4400-24P, EX4400-48F, EX4400-48MP, EX4650, QFX5120-32C, QFX5120-48T, QFX5120-48Y und QFX5120-48YM)—Ab Junos OS Version 24.2R1 unterstützen wir Ethernet VPN-Virtual Extensible LAN (EVPN-VXLAN) zu EVPN-VXLAN nahtlose Datencenter-Verbindung (DCI) mit erweitertem optimiertem Intersubnet Multicast (OISM). Ohne diese Funktion leiten die DCI-Gateway-Geräte Multicast-Datenverkehr über das WAN weiter, das sie miteinander verbindet. Flooding verbraucht erhebliche WAN-Bandbreite, wenn Ihr Netzwerk viele Multicast-Datenströme oder hohe Multicast-Datenverkehrsraten aufweist. Diese Funktion ersetzt nahtlos das Multicast-Flooding-Verhalten. Um die Multicast-Weiterleitung über ein DCI zu optimieren, gehen die OISM-Leaf-Geräte in jedem Netzwerk wie folgt vor:

    • Ankündigung von SMET-Routen (Selective Multicast Ethernet Tag) (EVPN-Routen Typ 6), wenn ein Empfänger einen Multicast-Flow abonniert. Die DCI-Gateways geben die SMET-Routen nahtlos über die DCI auf dem OISM SBD weiter.

    • Senden Sie Multicast-Datenverkehr basierend auf den empfangenen SMET-Routen nur an die Remote-Empfänger im DCI, die diesen Multicast-Flow abonniert haben.

    So konfigurieren Sie diese Funktion:

    • Konfigurieren Sie die DCI-Gatewaygeräte auf die gleiche Weise wie die Geräte ohne Multicastunterstützung.

    • Konfigurieren Sie erweitertes OISM in den Netzwerken auf beiden Seiten des DCI.

      • Mit erweitertem OISM können Sie jedes OISM-Gerät nur mit den VLANs konfigurieren, die das Gerät hostet, außer auf Multihoming-Peer-OISM-Geräten und den Peer-DCI-Gateways in den einzelnen Datencenter-Netzwerken. Auf diesen Peer-Geräten müssen Sie die OISM-Umsatz-VLANs symmetrisch konfigurieren.

      • Konfigurieren Sie dieselbe OISM-SBD (Supplemental Bridge-Domäne) in den entsprechenden VRF-Instanzen (Virtual Routing and Forwarding) des Mandanten auf beiden Seiten der DCI.

    Als OISM-Geräte folgen die DCI-Gateways dem erweiterten OISM-Betriebsmodell, um den Datenverkehr an andere OISM-Geräte in ihrem eigenen Netzwerk oder über das DCI weiterzuleiten. Sie senden den Multicast-Datenverkehr:

    • Über die DCI zu den anderen DCI-Gateways nur auf der OISM-SBD.

    • für andere Nicht-Multihoming-PE-Geräte (Peer Provider Edge) in ihrem Netzwerk nur auf dem OISM-SBD.

    • nur an ihre Multihoming-Peer-PE-Geräte im Quell-VLAN.

    Sie können ein DCI-Gateway auch als OISM PIM EVPN-Gateway (PEG) konfigurieren. Das Gerät fungiert sowohl als DCI-Gateway als auch als OISM-PEG-Border-Leaf-Gerät, um Multicast-Datenverkehr mit Geräten außerhalb eines der beiden Netzwerke auszutauschen.

    [Siehe Optimiertes Intersubnet-Multicast in EVPN-Netzwerken.]

  • Generierung von EVPN-Routen vom Typ 3 auf dynamisch zugeordneten 802.1X-Schnittstellen (EX4100-24MP, EX4300-MP, EX4400-24P, QFX5120-32C, QFX5120-48T und QFX5120-48Y)—Ab Junos OS Version 24.2R1 unterstützen wir die Generierung von Ethernet-VPN-Typ-3-Routen (EVPN) über Schnittstellen, die vom 802.1X-Protokoll dynamisch einer Virtual Extensible LAN (VXLAN) Extended Bridge Domain (BD) zugeordnet werden.

    [Siehe dot1x.]