VXLAN-Einschränkungen für Geräte der EX-Serie, QFX-Serie, PTX-Serie und ACX-Serie

(QFX5130-32CD- und QFX5700-Switches) Wir unterstützen keine CRB-Architektur (Centrally Routed Bridging) mit einem Collapsed Spine-Modell, wenn:

• Eine Schnittstelle verwendet in der edit interfaces interface-name Hierarchie sowohl Konfigurationen im Enterprise- als auch im Service-Provider-Stil.

• Mehrere Zugriffsports in derselben VXLAN-Bridge-Domäne verwenden eine Mischung aus Unternehmens- und Service Provider-Stilen.

Konfiguration im Enterprise-Stil

Konfiguration im Service Provider-Stil

Flexible Konfiguration von Ethernet-Services

Unterstützte Szenarien:

• Ein nicht zugeklapptes Spine und kein VLAN ist mit einer lokalen Schnittstelle konfiguriert.

• Ein Collapsed Spine und einige VLANs auf dem Gerät werden ohne lokale Schnittstelle konfiguriert, während einige VLANs auf dem Gerät im Enterprise-Stil auf CE-orientierten Schnittstellen konfiguriert werden.

• Ein Collapsed Spine und alle VLANs auf dem Gerät werden mit flexible-ethernet-services Verkapselung auf einer physischen Schnittstelle konfiguriert, während mehrere logische Schnittstellen entweder im Enterprise- oder Service-Provider-Stil konfiguriert werden.

Nicht unterstützte Szenarien:

• Ein Collapsed Spine und jede lokale Schnittstelle auf dem Gerät enthält alle konfigurierten VLANs. Die Problemumgehung für dieses Szenario besteht darin, die Kapselung auf der physischen Schnittstelle zu verwenden flexible-ethernet-services .

• Ein Collapsed Spine, bei dem einige VLANs auf dem Gerät nicht auf einer lokalen Schnittstelle konfiguriert sind und einige VLANs im Service-Provider-Stil auf CE-orientierten Schnittstellen konfiguriert sind. Die Problemumgehung für dieses Szenario besteht darin, eine vlan-id.

• Ein Collapsed Spine, bei dem einige VLANs auf dem Gerät nicht Teil einer Schnittstelle sind und einige VLANs durch flexible-ethernet-services Kapselung auf mehreren, logischen Schnittstellen im Enterprise-Stil konfiguriert werden. Die Problemumgehung für dieses Szenario besteht darin, eine vlan-id.

Für die VXLAN-Unterstützung auf einem Virtual Chassis oder einer Virtual Chassis-Fabric (VCF) gelten die folgenden Einschränkungen und Empfehlungen:

• Wir unterstützen EVPN-VXLAN auf einem EX4300-48MP Virtual Chassis nur in Campus-Netzwerken.

• Eigenständige EX4400-Switches und EX4400 Virtual Chassis unterstützen EVPN-VXLAN. Für Multihoming-Anwendungsfälle können Hosts auf eigenständige EX4400-Switches multivernetzt werden, aber wir unterstützen nicht das Multihoming eines Hosts mit ESI-LAG-Schnittstellen zum EX4400 Virtual Chassis.

• Eigenständige EX4100-Switches (EX4100 und EX4100-F) und EX4100 Virtual Chassis (EX4100 und EX4100-F) unterstützen EVPN-VXLAN. Für Multihoming-Anwendungsfälle können Hosts auf eigenständige EX4100-Switches multivernetzt werden, aber wir unterstützen kein Multihoming eines Hosts mit ESI-LAG-Schnittstellen zum EX4100 Virtual Chassis.

• In Datencenter-Netzwerken unterstützen wir EVPN-VXLAN nur auf einem Virtual Chassis oder VCF, das aus allen QFX5100-Switches besteht, und nicht auf einem anderen gemischten oder nicht gemischten Virtual Chassis oder VCF. Wir unterstützen VCF in EVPN-VXLAN-Datencenter-Umgebungen mit Junos OS-Versionen ab 14.1X53-D40 und vor 17.1R1. Wir raten jedoch davon ab, EVPN-VXLAN auf einem QFX5100 Virtual Chassis oder VCF zu verwenden, da die Funktionsunterstützung nur mit der Unterstützung auf eigenständigen QFX5100-Switches mit Junos OS Version 14.1X53-D40 vergleichbar ist.

  Die VCF-Unterstützung wird ab Junos OS Version 21.4R1 generell eingestellt.

• Wenn ein QFX5100 Virtual Chassis eine MAC-Adresse auf einer VXLAN-Schnittstelle erlernt, kann es bis zu 10 bis 15 Minuten dauern, bis der MAC-Tabelleneintrag veraltet ist (das Zwei- bis Dreifache des standardmäßigen Alterungsintervalls von 5 Minuten). Dies geschieht, wenn das Virtual Chassis eine MAC-Adresse aus einem eingehenden Paket auf einem Virtual Chassis-Mitglieds-Switch erfährt und dieses Paket dann über die VCP-Links (Virtual Chassis-Port) an einen anderen Mitglieds-Switch im Virtual Chassis auf dem Weg zum Ziel weiterleiten muss. Das Virtual Chassis markiert die MAC-Adresse, wie sie beim Switch für das zweite Mitglied erneut angezeigt wird, sodass die MAC-Adresse möglicherweise nicht für ein oder zwei weitere Alterungsintervalle nach dem ersten veraltet. Das MAC-Lernen kann auf VXLAN-Schnittstellen erst beim zweiten Virtual Chassis-Mitglieds-Switch deaktiviert werden, sodass Sie die zusätzliche Verzögerung in diesem Fall nicht vermeiden können.

(Nur QFX5120-Switches) Datenverkehr, der über eine Core-seitige Layer 3-getaggte Schnittstelle oder IRB-Schnittstelle getunnelt wird, wird verworfen. Um diese Einschränkung zu umgehen, können Sie flexibles VLAN-Tagging konfigurieren. Weitere Informationen finden Sie unter Grundlegendes zu VXLANs.

(QFX5110 und QFX5120) Wenn Sie eine Schnittstelle im Unternehmensstil mit flexibler Ethernet-Services-Kapselung konfigurieren, verwirft das Gerät VXLAN-gekapselte Transit-Layer-2-Pakete auf dieser Schnittstelle. Um dieses Problem zu umgehen, konfigurieren Sie die Schnittstelle im Service Provider-Stil anstelle des Enterprise-Stils. Weitere Informationen zu Konfigurationen im Enterprise-Stil und Service Provider-Stil finden Sie unter Flexible Ethernet Services Encapsulation. Eine Übersicht über die Konfiguration flexibler Ethernet-Services in einer EVPN-VXLAN-Fabric finden Sie unter Grundlegendes zur Unterstützung flexibler Ethernet-Services mit EVPN-VXLAN.

(Switches QFX5110 und QFX5120) In EVPN-VXLAN-Fabrics unterstützen wir keine Konfigurationen im Enterprise-Stil, im Service-Provider-Stil und in nativen VLANs auf derselben physischen Schnittstelle, wenn das native VLAN mit einem der VLANs in der Service-Provider-Konfiguration identisch ist. Das native VLAN kann eines der VLANs in der Konfiguration im Enterprise-Stil sein. Weitere Informationen zu Konfigurationen im Enterprise-Stil und Service Provider-Stil finden Sie unter Flexible Ethernet Services Encapsulation.

(QFX5xxx-Switches) In einer EVPN-VXLAN-Fabric können Sie die native-vlan-id-Anweisung nicht auf derselben Schnittstelle konfigurieren, an der Sie die VLAN-Übersetzung mit der vlan-rewrite-Anweisung aktivieren.

(Switches QFX5100, QFX5110, QFX5200 und QFX5210) Wir unterstützen die VXLAN-Konfiguration in der Standard-Switch-Routing-Instanz und in MAC-VRF-Routing-Instanzen (instance-type mac-vrf).

(EX4300-48MP- und EX4600-Switches) Wir unterstützen die VXLAN-Konfiguration nur in der Standard-Switch-Routing-Instanz.

(Switches QFX5100, QFX5200, QFX5210, EX4300-48MP und EX4600) Das Routing von Datenverkehr zwischen verschiedenen VXLANs wird nicht unterstützt.

(Switches QFX5100, QFX5110, QFX5120, EX4600 und EX4650) Diese Switches unterstützen nur einen VTEP Next Hop auf VXLAN-Underlay-IRB-Schnittstellen. Wenn Sie nicht mehrere Ausgangsports verwenden möchten, aber mehr als einen VTEP-Next-Hop benötigen, können Sie als Problemumgehung einen der folgenden Schritte ausführen:

• Platzieren Sie einen Router zwischen dem Switch und den Remote-VTEPs, sodass nur ein nächster Hop zwischen ihnen liegt.

• Verwenden Sie physische Layer-3-Schnittstellen anstelle von IRB-Schnittstellen für Remote-VTEP-Erreichbarkeit.

(QFX5110-Switches) Standardmäßig ist das Routing von Datenverkehr zwischen einem VXLAN und einer logischen Layer-3-Schnittstelle – z. B. einer mit dem set interfaces interface-name unit logical-unit-number family inet address ip-address/prefix-length Befehl konfigurierten Schnittstelle – nicht aktiviert. Wenn diese Routing-Funktionalität in Ihrem EVPN-VXLAN-Netzwerk erforderlich ist, können Sie einige zusätzliche Konfigurationen vornehmen, damit sie funktioniert. Weitere Informationen finden Sie unter Grundlegendes zum Konfigurieren von VXLANs und logischen Layer-3-Schnittstellen für die Interoperabilität.

Integrierte Routing- und Bridging-Schnittstellen (IRB), die in EVPN-VXLAN-Overlay-Netzwerken verwendet werden, unterstützen das IS-IS-Routing-Protokoll nicht.

(QFX5100-, QFX5110-, QFX5120-, QFX5200-, QFX5210-, EX4300-48MP- und EX4600-Switches) Eine physische Schnittstelle kann nicht Mitglied eines VLAN und eines VXLAN sein. Das heißt, eine Schnittstelle, die die VXLAN-Kapselung und -Entkapselung durchführt, kann nicht auch Mitglied eines VLANs sein. Wenn beispielsweise ein VLAN, das einem VXLAN zugeordnet ist, Mitglied des Trunk-Ports xe-0/0/0 ist, muss jedes andere VLAN, das Mitglied von xe-0/0/0 ist, ebenfalls einem VXLAN zugewiesen werden.

(Switches QFX5110, QFX5120, EX4100 und EX4400) Wir unterstützen keine logischen VXLAN- und Nicht-VXLAN-Schnittstellen auf derselben physischen Schnittstelle mit Schnittstellenkonfigurationen im Enterprise-Stil.

(Switches QFX5120, EX4100, EX4300-48MP, EX4400 und EX4650) Bei der 802.1X-Authentifizierung für VXLAN-Datenverkehr an einem Zugriffsport wechselt der RADIUS-Server bei der Authentifizierung dynamisch den Datenverkehr vom ursprünglichen VLAN in ein dynamisches VLAN, das Sie als VXLAN-fähiges VLAN konfigurieren. Ein VXLAN-fähiges VLAN ist ein VLAN, für das Sie eine VXLAN Network Identifier (VNI)-Zuordnung mithilfe der vxlan vni vni Anweisung in der [edit vlans vlan-name] Hierarchie konfigurieren.

Wenn Sie das dynamische 802.1X-VLAN und die entsprechende VNI-Zuordnung konfigurieren, müssen Sie auch das ursprüngliche VLAN als VXLAN-fähiges VLAN mit einer VNI-Zuordnung konfigurieren. Wenn Sie den Port nicht explizit als Mitglied eines VLANs konfigurieren, verwendet der Port das Standard-VLAN. In diesem Fall müssen Sie das Standard-VLAN als VXLAN-fähiges VLAN mit einer VNI-Zuordnung konfigurieren.

Außerdem muss in Versionen vor Junos OS Version 22.2R3-S3 ein dynamisches VLAN, das einem Port zugewiesen wird, bereits statisch auf einem anderen Port des Geräts konfiguriert worden sein. Ab Junos OS Version 22.2R3-S3 gibt es diese Einschränkung nicht mehr.

Weitere Informationen zur dynamischen VLAN-Zuweisung mit einem RADIUS-Server finden Sie unter 802.1X-Authentifizierung und RADIUS-Serverkonfiguration für die Authentifizierung .

Multichassis Link Aggregation Groups (MC-LAGs) werden von VXLAN nicht unterstützt.

IP-Fragmentierung und -Defragmentierung werden auf der Layer-3-Seite nicht unterstützt.

Die folgenden Features werden auf der Layer-2-Seite nicht unterstützt:

• (Switches QFX5100, QFX5200, QFX5210, EX4300-48MP und EX4600) IGMP-Snooping mit EVPN-VXLAN.

• Redundant Trunk Groups (RTGs).

• Die Möglichkeit, eine Layer 2-Schnittstelle herunterzufahren oder vorübergehend herunterzufahren, wenn eine Sturmkontrollstufe überschritten wird, wird nicht unterstützt.

• Wir unterstützen nicht alle STP-, MSTP-, RSTP- oder VSTP (xSTP)-Funktionen mit VXLAN. Sie können xSTP jedoch am Edge (Zugriffsport) für die BPDU-Block-on-Edge-Unterstützung konfigurieren. Weitere Informationen finden Sie unter BPDU-Schutz für Spanning-Tree-Protokolle .

Sicherheitsfunktionen für Zugriffsports wie die folgenden werden von VXLAN nicht unterstützt:

• DHCP-Snooping.

• Dynamische ARP-Inspektion.

• MAC-Begrenzung und MAC-Bewegungsbegrenzung.

Einige Ausnahmen sind:

• Die MAC-Begrenzung wird auf OVSDB-verwalteten Schnittstellen in einer OVSDB-VXLAN-Umgebung mit Contrail-Controllern unterstützt. Weitere Informationen finden Sie unter Von OVSDB verwaltete Schnittstellen unterstützte Features.

• Auf diesen Geräten, die als L2-VXLAN-Gateways in EVPN-VXLAN-Bridging-Overlay-Netzwerken mit zentralem Routing dienen:

  • Multigigabit-Switches EX4300 ab Junos OS Version 19.4R1

  • EX4400-Switches ab Junos OS Version 21.1R1

  • Multigigabit-Switches EX4400 ab Junos OS Version 21.2R1

  • EX4100- und EX4100-F-Switches ab Junos OS Version 22.3R1

  • EX4100-Multigigabit-Switches ab Junos OS Version 22.3R1

  Wir unterstützen diese Zugriffssicherheitsfunktionen auf Zugriffsseitigen Layer-2-Schnittstellen, die mit VXLAN-zugeordneten VLANs verknüpft sind:

  • DHCPv4- und DHCPv6-Snooping

  • Dynamische ARP-Inspektion (DAI)

  • Neighbor Discovery Inspection (NDI)

  • IPv4- und IPv6-Quellschutz

  • Schutz für Router-Werbung (Registrierungsstelle)

  Wir unterstützen diese Funktionen nur bei Single-Homed Access Interface-Verbindungen.

Die Replikation eingehender Knoten wird in den folgenden Fällen nicht unterstützt:

• Wenn PIM für die Steuerungsebene verwendet wird (manuelles VXLAN).

• Wenn das SDN-Controller für die Steuerungsebene verwendet wird (OVSDB-VXLAN).

Die Replikation eingehender Knoten wird mit EVPN-VXLAN unterstützt.

PIM-BIDIR und PIM-SSM werden von VXLANs nicht unterstützt.

Wenn Sie eine Portspiegelungsinstanz so konfigurieren, dass der Datenverkehr gespiegelt wird, der von einer Schnittstelle ausgeht, die eine VXLAN-Kapselung durchführt, sind die Quell- und Ziel-MAC-Adressen der gespiegelten Pakete ungültig. Der ursprüngliche VXLAN-Datenverkehr ist nicht betroffen.

(Nur QFX5110-Switches) VLAN-Firewall-Filter werden auf IRB-Schnittstellen, auf denen EVPN-VXLAN aktiviert ist, nicht unterstützt.

(Switches der EX4650- und QFX5000-Serie) Unterstützung für Firewall-Filter und Policer:

• (QFX5100-Switches) Firewall-Filter und Policer werden für den Transitdatenverkehr, in dem EVPN-VXLAN aktiviert ist, nicht unterstützt. Sie werden nur in Eingangsrichtung auf CE-orientierten Schnittstellen unterstützt.

• (QFX5100-Switches) Für IRB-Schnittstellen in einer EVPN-VXLAN One-Layer-IP-Fabric werden Firewall-Filterung und -Überwachung nur am Eingangspunkt von nicht gekapselten Frames unterstützt, die über die IRB-Schnittstelle geroutet werden.

• (Switches EX4650, QFX5110 und QFX5120) Wir unterstützen Eingangsfilterung und Überwachung für geroutete VXLAN-Schnittstellen (IRB-Schnittstellen) als Eingangsroute Access Control Lists [IRACLs].

• (Switches QFX5110, QFX5120 und QFX5210) Wir unterstützen Eingangsfilterung und Überwachung auf nicht gerouteten VXLAN-Schnittstellen als Eingangsport-ACLs [IPACLs]).

• (Switches QFX5110 und QFX5120) Die Filter- und Richtlinienunterstützung für nicht geroutete VXLAN-Schnittstellen erstreckt sich auf die Ausgangsrichtung als Ausgangsport-ACLs ([EPACLs]).

(Nur EX4300-48MP-Switches) Die folgenden Arten der Schnittstellenkonfiguration werden nicht unterstützt:

• Service-Provider-Stil, bei dem eine physische Schnittstelle in mehrere logische Schnittstellen unterteilt ist, von denen jede für ein bestimmtes Kunden-VLAN reserviert ist. Der extended-vlan-bridge Kapselungstyp wird auf der physischen Schnittstelle konfiguriert.

• Flexible Ethernet-Services, bei denen es sich um einen Verkapselungstyp handelt, der es einer physischen Schnittstelle ermöglicht, sowohl Service Provider- als auch Unternehmensschnittstellenkonfigurationen zu unterstützen.

Weitere Informationen zu diesen Arten der Schnittstellenkonfiguration finden Sie unter Flexible Ethernet Services Encapsulation.

(Nur QFX5100-Switches) Mit der no-arp-suppression Konfigurationsanweisung können Sie die Unterdrückung von ARP-Anforderungen für ein oder mehrere angegebene VLANs deaktivieren. Ab Junos OS Version 18.4R3 müssen Sie diese Funktion jedoch auf allen VLANs deaktivieren. Dazu können Sie eine der folgenden Konfigurationsoptionen verwenden:

• Verwenden Sie einen Batch-Befehl, um die Funktion auf allen VLANsset groups group-name vlans * no-arp-suppression zu deaktivieren. Bei diesem Befehl verwenden wir das Sternchen (*) als Platzhalter, der alle VLANs angibt.

• Verwenden Sie einen Befehl, um die Funktion in jedem einzelnen VLAN zu deaktivieren.set vlans vlan-name no-arp-suppression

Die Switches QFX5120-48Y, QFX5120-32C und QFX5200 unterstützen hierarchical Equal-Cost Multipath (ECMP), wodurch diese Switches eine zweistufige Routenauflösung durchführen können. Alle anderen QFX5-Switchesxxx unterstützen jedoch kein hierarchisches ECMP. Wenn also ein EVPN-Paket vom Typ 5 mit einem VXLAN-Header gekapselt und dann von einem QFX5-Switchxxx entkapselt wird, der kein hierarchisches ECMP unterstützt, kann der Switch die beiden Routenebenen im inneren Paket nicht auflösen. Der Switch verwirft dann das Paket.

(Switches QFX5100, QFX5110, QFX5120, QFX5200 und QFX5210) Wenn Sie die IRB-Schnittstellen auf einem Gerät konfigurieren, das gleichzeitig konfigurierte VLANs sowohl auf einem zentral gerouteten Bridging-Overlay als auch auf einem Edge-gerouteten Bridging-Overlay unterstützt, müssen sich die IRB-MAC-Adresse und die MAC-Adresse des virtuellen Gateways auf der IRB-Schnittstelle für das zentral geroutete Bridging-Overlay von der IRB-MAC-Adresse und der virtuellen Gateway-MAC-Adresse auf der IRB-Schnittstelle für das Edge-Routed Bridging-Overlay unterscheiden.

Die folgenden Einschränkungen gelten sowohl für VXLANs als auch für VLANs.

• (Nur QFX5-Switchesxxx ) Bei der Konfiguration von Routenverlusten zwischen virtuellen Routing- und Weiterleitungsinstanzen (VRF) müssen Sie jedes Präfix mit einer Subnetzmaske angeben, die bei IPv4-Präfixen gleich oder länger als /16 bzw. bei IPv6-Präfixen gleich oder länger als /64 ist. Wenn eine von Ihnen angegebene Subnetzmaske diese Parameter nicht erfüllt, werden die angegebenen Routen nicht durchgesickert.

• (Nur QFX5120-Switches) Standardmäßig weisen QFX5120-Switches 5 MB eines gemeinsam genutzten Puffers zu, um Ausbrüche von Multicast-Datenverkehr zu absorbieren. Wenn ein Burst von Multicast-Datenverkehr 5 MB überschreitet, verwirft der Switch die Pakete, die der Switch empfängt, nachdem der Pufferspeicher überschritten wurde. Um zu verhindern, dass der Switch in dieser Situation Multicast-Pakete verwirft, können Sie einen der folgenden Schritte ausführen:

  • Verwenden Sie die shared-buffer Konfigurationsanweisung auf der [edit class-of-service] Hierarchieebene, um einen höheren Prozentsatz des freigegebenen Puffers für den Multicast-Datenverkehr neu zuzuweisen. Weitere Informationen zur Feinabstimmung eines freigegebenen Puffers finden Sie unter Grundlegendes zur CoS-Pufferkonfiguration.

  • Wenden Sie auf dem Juniper Networks Switch, von dem die Multicast-Datenverkehrsspitzen kommen, einen Shaper auf die Ausgangsverbindung an.

• (Nur QFX5-Switchesxxx ) Wenn Sie die Sturmkontrolle auf einer Schnittstelle aktiviert haben, stellen Sie möglicherweise einen erheblichen Unterschied zwischen den konfigurierten und den tatsächlichen Datenverkehrsraten für die Schnittstelle fest. Diese Differenz ist das Ergebnis eines internen Sturmkontrollmeters, das die tatsächliche Datenverkehrsrate für die Schnittstelle in Schritten von 64 Kbit/s quantifiziert, z. B. 64 Kbit/s, 128 Kbit/s, 192 Kbit/s usw.

(QFX5xxx- und EX46xx-Switches) Sie können keine hardwaregestützte Inline-BFD (Bidirectional Forwarding Detection) mit VXLAN-Kapselung von BFD-Paketen verwenden. Wenn Sie EVPN-Overlay-BGP-Peerings konfigurieren, verwenden Sie außerdem verteilte BFD anstelle von hardwaregestütztem Inline-BFD. Weitere Informationen zu den verschiedenen Arten von BFD-Sitzungen, die Sie konfigurieren können, finden Sie unter Grundlegendes zur Erkennung von Netzwerkfehlern durch BFD .

(QFX5130-32CD-, QFX5130E-32CD-, QFX5130-48C-, QFX5700- und QFX5700E-Switches) Ab den Versionen 25.2X100-D10 und 25.4R1 von Junos OS Evolved unterstützen wir hardwaregestütztes Inline-BFD mit 100 x 3 Millisekunden-Timern über VXLAN-Tunnel nur auf den aufgeführten Plattformen. Diese Unterstützung gilt für:

• Typ-2-IPv4- oder IPv6-L2- und L3-Multihop-BFD mit ECMP oder mehrfach vernetzten VTEPs mit folgenden Anforderungen:

  • 100 x 3 ms Timer

  • Overlay-BGP-Peering zwischen Loopbacks

  • BFD konfiguriert für die Overlay-BGP-Sitzungen

• Typ 5 IPv4 oder IPv6 Multihop BFD mit ECMP

• Reine Typ-5-Routing-Instanzen

(QFX5xxx- und EX46xx-Switches) Die Konfiguration und Verwendung von MPLS und EVPN-VXLAN auf demselben Gerät wird nicht unterstützt. Diese Einschränkung besteht darin, dass Broadcom-basierte Plattformen dieselben Hardwaretabellen zum Speichern von Tunnel- und virtuellen Portinformationen verwenden, die sowohl von den MPLS- als auch von den VXLAN-Funktionen verwendet werden.

Außerdem können Sie kein MPLS-Underlay mit EVPN und einem VXLAN-Overlay verwenden. Dies ist eine Hardwareeinschränkung von Broadcom.

(QFX5xxx- und EX46xx-Switches) Wir unterstützen keine getaggten L3-Schnittstellen und L2-Bridge-Domänen als Untereinheiten derselben Schnittstelle mit einem IRB in Konfigurationen im Service-Provider-Stil.

MC-LAGs werden von VXLAN nicht unterstützt.

IP-Fragmentierung wird auf der Layer-3-Seite nicht unterstützt.

Die folgenden Features werden auf der Layer-2-Seite nicht unterstützt:

• IGMP-Snooping mit EVPN-VXLAN in Junos OS-Versionen vor Junos OS Version 17.2R1.

• STP (jede Variante).

Sicherheitsfunktionen für Zugriffsports werden von VXLAN nicht unterstützt. Beispielsweise werden die folgenden Funktionen nicht unterstützt:

• DHCP-Snooping.

• Dynamische ARP-Inspektion.

• MAC-Begrenzung und MAC-Bewegungsbegrenzung.

Die Replikation eingehender Knoten wird nicht unterstützt, wenn ein das SDN-Controller für die Steuerungsebene (OVSDB-VXLAN) verwendet wird. Die Replikation eingehender Knoten wird für EVPN-VXLAN unterstützt.

QFX10000-Switches, die in einer EVPN-VXLAN-Umgebung bereitgestellt werden, unterstützen kein physisches IPv6-Underlay-Netzwerk.

Wenn die Next-Hop-Datenbank auf einem QFX10000-Switch Next-Hops sowohl für das Underlay-Netzwerk als auch für die EVPN-VXLAN-Overlay-Netzwerk enthält, darf der nächste Hop zu einem VXLAN-Peer kein Ethernet Segment Identifier (ESI) oder eine Virtual Tunnel Endgerät (VTEP)-Schnittstelle sein.

IRB-Schnittstellen, die in EVPN-VXLAN-Overlay-Netzwerken verwendet werden, unterstützen das IS-IS-Routing-Protokoll nicht.

VLAN-Firewall-Filter für IRB-Schnittstellen, auf denen EVPN-VXLAN aktiviert ist.

Filterbasierte Weiterleitung (FBF) wird auf IRB-Schnittstellen, die in einer EVPN-VXLAN-Umgebung verwendet werden, nicht unterstützt.

Die Switches QFX10002, QFX10008 und QFX10016 unterstützen keine Portspiegelung und -analyse, wenn auch EVPN-VXLAN konfiguriert ist.

Wenn Sie die IRB-Schnittstellen auf einem Gerät konfigurieren, das gleichzeitig konfigurierte VLANs sowohl auf einem zentral gerouteten Bridging-Overlay als auch auf einem Edge-gerouteten Bridging-Overlay unterstützt, müssen sich die IRB-MAC-Adresse und die MAC-Adresse des virtuellen Gateways auf der IRB-Schnittstelle für das zentral geroutete Bridging-Overlay von der IRB-MAC-Adresse und der virtuellen Gateway-MAC-Adresse auf der IRB-Schnittstelle für das Edge-Routed Bridging-Overlay unterscheiden.

In einer EVPN-VXLAN-Umgebung wird die Konfiguration von Anycast-Gateways mit der default-gateway Anweisung und der advertise Anweisung für Verbindungen, die am selben Ethernet-Segment (ES) beteiligt sind, nicht unterstützt.

Sie müssen Class-of-Service-Regeln (CoS) konfigurieren, damit die DSCP-Bits (Differentiated Services Code Point) aus dem inneren VXLAN-Header in den äußeren VXLAN-Header kopiert werden.

Sie müssen die Tunnel-Terminierung auf Geräten der PTX10K-Serie in EVPN-VXLAN-Bereitstellungen wie folgt global aktivieren:

set forwarding-options tunnel-termination

Sie können keinen Firewall-Filter auf diesen Geräten verwenden, um die VXLAN-Tunnel-Terminierung auf bestimmten Ports zu blockieren, aber Sie können den folgenden Befehl verwenden, um die VXLAN-Tunnel-Terminierung für einen Port zu blockieren:

set interfaces logical-interface-name unit n family inet/inet6 no-tunnel-termination

Multihoming-Peers innerhalb eines Datencenters sollten aus einer ähnlichen Produktfamilie stammen. Wir raten davon ab, die ACX-Serie mit der QFX-Serie, der PTX-Serie oder der MX-Serie für Multihoming zu kombinieren.

(ACX 7xxx Router) Netzwerke mit MAC- und IP-Skalierung sollten . set system packet-forwarding-options hw-db-profile cloud-metro Der Standardwert ist lean-edge, der für die IP-Skalierung vorgesehen ist.

(ACX 7xxx Router) Load Balancing ist standardmäßig nicht aktiviert. Hier sehen Sie eine Beispielkonfiguration. Konfigurieren Sie nur die Optionen, die für Ihre Bereitstellung erforderlich sind.

(ACX 7xxx Router) Konfigurieren Sie set system packet-forwarding-options system-profile vxlan-extended die Unterstützung eines EVPN-VXLAN-IPv6-Underlays.

(ACX 7xxx Router) Konfigurieren Sie die Unterstützung set system packet-forwarding-options system-profile vxlan-stitching von EVPN-VLXAN zu EVPN-VXLAN-Stitching und EVPN-VXLAN zu EVPN-MPLS-Stitching mit no-control-word Unterstützung.

(ACX 7xxx Router) Konfigurieren Sie set system packet-forwarding-options system-profile vxlan-stitching control-word die Unterstützung von Steuerwortfunktionen in einem verknüpften EVPN-VXLAN-zu-EVPN-MPLS-Netzwerk. Weitere Informationen zur Unterstützung von Steuerwörtern finden Sie unter vxlan-stitching .

(ACX 7xxx Router) Eine benutzerdefinierte Virtual Gateway Address (VGA) IPv4 MAC (virtual-gateway-v4-mac) und eine benutzerdefinierte VGA IPv6 MAC (virtual-gateway-v6-mac) werden systemweit unterstützt.

(ACX 7xxx Router) Konfigurieren Sie set system packet-forwarding-options no-ip-tos-rewrite die Weitergabe von DSCP-Informationen von der Nutzlast an den VXLAN-Router-Header während der VXLAN-Kapselung.

(ACX 7xxx Router) Die ESI-Konfiguration im EVPN-Multihoming-Modus wird pro physischem Schnittstellengerät oder nur pro LAG-Schnittstelle unterstützt.

(ACX 7xxx Router) IRB-Schnittstellen werden als EVPN-VXLAN-Underlay-Netzwerke nicht unterstützt.

(ACX 7xxx Router) Beim EVPN-VXLAN-zu-EVPN-MPLS-Stitching sind Geräte, die keine Weiterleitung basierend auf Bridge-Domain-Labels unterstützen, nicht mit Geräten der ACX-Serie als DC-Peer-GWs kompatibel.

Wenn Sie mehrere Untereinheiten auf einem Port mit einer ESI konfigurieren, wird der Deaktivierungsvorgang (set interfaces logical-interface-name unit n disable) auf diesen logischen Schnittstellen nicht unterstützt.

In einem EVPN-VXLAN-Overlay wird die Ausführung eines Routing-Protokolls auf einer IRB-Schnittstelle in einer Standardrouting-Instanz (default.inet.0) nicht unterstützt. Stattdessen wird empfohlen, die IRB-Schnittstelle in eine Routing-Instanz vom Typ .vrf