Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

Beachten Sie bei der Konfiguration von Virtual Extensible LANs (VXLANs) auf Switches der QFX-Serie und der EX-Serie die in den folgenden Abschnitten beschriebenen Einschränkungen. In diesen Abschnitten bezieht sich "Layer-3-Seite" auf eine netzwerkseitige Schnittstelle, die VXLAN-Kapselung und -Entkapselung vornimmt, und "Layer-2-Seite" auf eine serverseitige Schnittstelle, die Mitglied eines VLANs ist, das einem VXLAN zugeordnet ist.

VXLAN-Einschränkungen für die Switches QFX5xxx, EX4100, EX4100-F, EX4300-48MP, EX4400 und EX4600

  • (QFX5130-32CD- und QFX5700-Switches) Wir unterstützen in folgenden Fällen keine CRB-Architektur (Centrally Routed Bridging) mit einem Collapsed-Spine-Modell:

    • Eine Schnittstelle verwendet in der Hierarchie edit interfaces interface-name sowohl Konfigurationen im Unternehmens- als auch im Dienstanbieterstil.

    • Mehrere Zugriffsports auf 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 der Ethernet-Services

    Unterstützte Szenarien:

    • Ein nicht kollabierter 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 Unternehmensstil auf CE-orientierten Schnittstellen konfiguriert werden.

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

    Nicht unterstützte Szenarien:

    • Ein Collapsed Spine und jede lokale Schnittstelle auf dem Gerät umfasst alle konfigurierten VLANs. Die Problemumgehung für dieses Szenario besteht in der Verwendung flexible-ethernet-services der Kapselung auf der physischen Schnittstelle.

    • Ein Collapsed Spine, bei dem einige VLANs auf dem Gerät auf keiner 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 Unternehmensstil konfiguriert sind. 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-Anwendungsszenarien können Hosts zu eigenständigen EX4400-Switches multihomed werden, aber wir unterstützen kein Multihoming eines Hosts mit ESI-LAG-Schnittstellen zu EX4400 Virtual Chassis.
    • Eigenständige EX4100 (EX4100 und EX4100-F) Switches und EX4100 Virtual Chassis (EX4100 und EX4100-F) unterstützen EVPN-VXLAN. Für Multihoming-Anwendungsszenarien können Hosts zu eigenständigen EX4100-Switches multihomed werden, aber wir unterstützen kein Multihoming eines Hosts mit ESI-LAG-Schnittstellen zu EX4100 Virtual Chassis.

    • In Datencenter-Netzwerken unterstützen wir EVPN-VXLAN nur auf einem Virtual Chassis oder VCF, der aus allen QFX5100 Switches besteht, und nicht auf anderen gemischten oder nicht gemischten Virtual Chassis oder VCFs. Wir unterstützen VCF in EVPN-VXLAN-Datencenter-Umgebungen, in denen Junos OS-Versionen ab 14.1X53-D40 und vor 17.1R1 ausgeführt werden. Es wird jedoch nicht empfohlen, EVPN-VXLAN auf einem QFX5100 Virtual Chassis oder VCF zu verwenden, da die Funktionsunterstützung nur der Unterstützung auf eigenständigen QFX5100-Switches entspricht, die Junos OS Version 14.1X53-D40 ausgeführt werden.

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

    • Wenn ein QFX5100 Virtual Chassis eine MAC-Adresse auf einer VXLAN-Schnittstelle lernt, kann es möglicherweise 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 von einem eingehenden Paket auf einem Virtual Chassis-Mitglieds-Switch lernt und dieses Paket dann über die Virtual Chassis Port (VCP)-Verbindungen an einen anderen Mitglieds-Switch im Virtual Chassis auf dem Weg zu seinem Ziel weiterleiten muss. Das Virtual Chassis markiert die MAC-Adresse, die erneut am zweiten Mitglieds-Switch zu sehen ist, sodass die MAC-Adresse möglicherweise für ein oder zwei zusätzliche Alterungsintervalle über das erste hinausgeht. Das MAC-Lernen kann auf VXLAN-Schnittstellen nicht erst beim zweiten Virtual Chassis-Komponenten-Switch ausgeschaltet 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 Enterprise-Stil mit flexibler Ethernet-Services-Kapselung konfigurieren, legt das Gerät Transit-Layer-2-VXLAN-gekapselte Pakete auf dieser Schnittstelle ab. Um dieses Problem zu umgehen, konfigurieren Sie die Schnittstelle im Service Provider-Stil, anstatt den Enterprise-Stil zu verwenden. Weitere Informationen zu Konfigurationen im Enterprise- und Service Provider-Stil finden Sie unter Flexible Ethernet-Services-Kapselung. Einen Überblick über die Konfiguration flexibler Ethernet-Services in einer EVPN-VXLAN-Fabric finden Sie unter Understanding Flexible Ethernet Services Support with EVPN-VXLAN.

  • (QFX5110 und QFX5120 Switches) 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 Konfiguration im Service Provider-Stil identisch ist. Das native VLAN kann eines der VLANs in der Konfiguration im Enterprise-Stil sein. Weitere Informationen zu Konfigurationen im Enterprise- und Service Provider-Stil finden Sie unter Flexible Ethernet-Services-Kapselung.

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

  • (QFX5100-, QFX5110-, QFX5200- und QFX5210-Switches) 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 Routing-Instanz des Standard-Switches.

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

    Anmerkung:

    Die folgenden Switches unterstützen VXLAN-Routing ab den angegebenen Versionen, sodass diese Einschränkung nicht mehr gilt:

    • EX4300-48MP-Switches: Ab Junos OS Version 19.4R1.

    • QFX5210 Switches: Ab Junos OS Version 21.3R1.

  • (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 die 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-Funktion in Ihrem EVPN-VXLAN-Netzwerk erforderlich ist, können Sie einige zusätzliche Konfigurationen vornehmen, damit sie funktioniert. Weitere Informationen finden Sie unter Grundlegendes zur Konfiguration 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 VLANs und eines VXLAN sein. Das heißt, eine Schnittstelle, die VXLAN-Kapselung und -Entkapselung vornimmt, kann nicht gleichzeitig 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.

    Anmerkung:

    Ab Junos OS Releases 18.1R3 und 18.4R1 für QFX5100-, QFX5110-, QFX5200- und QFX5210-Switches und Junos OS Release 19.4R1 für QFX5120- und EX4650-Switches gilt diese Einschränkung nicht mehr, da Sie flexible Ethernet-Services auf der physischen Schnittstelle konfigurieren können. (Dasselbe gilt für aggregierte Ethernet (AE)-Bundle-Schnittstellen.)

    Seit Junos OS Version 20.3R1 unterstützen wir außerdem auf QFX5110- und QFX5120-Switches logische Layer-2-VLAN- und VXLAN-Schnittstellen auf derselben physischen Schnittstelle nur mit Schnittstellenkonfigurationen im Service Provider-Stil.

    Weitere Informationen hierzu finden Sie unter Grundlegendes zur Unterstützung flexibler Ethernet-Services mit EVPN-VXLAN.

  • (QFX5110-, QFX5120-, EX4100- und EX4400-Switches) Wir unterstützen keine VXLAN- und logischen Nicht-VXLAN-Schnittstellen auf derselben physischen Schnittstelle, die Schnittstellenkonfigurationen im Unternehmensstil verwenden.

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

    Wenn in Versionen vor Junos OS-Version 22.2R3-S3 ein dynamisches VLAN einem Port zugewiesen ist, muss dieses VLAN bereits statisch an 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 mit VXLAN nicht unterstützt.

    Anmerkung:

    In einer EVPN-VXLAN-Umgebung wird für redundante Konnektivität zwischen Hosts und Leaf-Geräten der EVPN-Multihoming-Aktiv-Aktiv-Modus anstelle von MC-LAG verwendet.

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

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

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

    • Redundant Trunk Groups (RTGs).

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

    • VXLAN unterstützt nicht die vollständigen STP-, MSTP-, RSTP- oder VSTP (xSTP)-Funktionen. Sie können jedoch xSTP am Edge (Zugriffsport) für 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-Verschiebungsbegrenzung.

    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 Features, die auf OVSDB-verwalteten Schnittstellen unterstützt werden.

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

      • Multigigabit-Switches EX4300 ab Junos OS Version 19.4R1

      • EX4400-Switches ab Junos OS Version 21.1R1

      • EX4400-Multigigabit-Switches ab Junos OS Version 21.2R1

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

      • Multigigabit-Switches EX4100 ab Junos OS Version 22.3R1

      Wir unterstützen die folgenden Zugriffssicherheitsfunktionen auf 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

      • Router-Werbung (RA)-Schutz

      Wir unterstützen diese Funktionen nur für Single-Homed-Zugriffsschnittstellenverbindungen.

  • Die Replikation des Eingangsknotens wird in den folgenden Fällen nicht unterstützt:

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

    • Bei Verwendung eines SDN-Controllers für die Steuerungsebene (OVSDB-VXLAN)

    Die Replikation von Eingangsknoten wird mit EVPN-VXLAN unterstützt.

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

  • Wenn Sie eine Port-Spiegelungsinstanz so konfigurieren, dass sie den Datenverkehr spiegelt, 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 davon nicht betroffen.

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

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

    • (QFX5100 Switches) Firewall-Filter und -Richtlinien werden für Transitdatenverkehr, für den 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 eingekapselten Frames unterstützt, die über die IRB-Schnittstelle geroutet werden.

    • (EX4650-, QFX5110- und QFX5120-Switches) Wir unterstützen Eingangsfilterung und -überwachung für geroutete VXLAN-Schnittstellen (IRB-Schnittstellen) als Eingangsrouten-Zugriffskontrolllisten [IRACLs].

    • (QFX5110-, QFX5120- und QFX5210-Switches) Wir unterstützen Ingress-Filterung und -Überwachung für nicht geroutete VXLAN-Schnittstellen als Ingress-Port-ACLs [IPACLs]).

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

  • (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 Unternehmensstile der Schnittstellenkonfiguration zu unterstützen.

    Weitere Informationen zu diesen Arten der Schnittstellenkonfiguration finden Sie unter Flexible Kapselung von Ethernet-Services.

  • (Nur QFX5100 Switches) Mit der no-arp-suppression Konfigurationsanweisung können Sie die Unterdrückung von ARP-Anforderungen in einem oder mehreren angegebenen 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 in allen VLANs zu deaktivieren.set groups group-name vlans * no-arp-suppression Bei diesem Befehl verwenden wir das Sternchen (*) als Platzhalter, der alle VLANs angibt.

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

    Anmerkung:

    Die no-arp-suppression Anweisung wird auf Switches der EX-Serie und QFX-Serie ab Junos OS Version 19.1R1 nicht mehr unterstützt. Die Anweisung ist veraltet.

  • QFX5120-48Y-, QFX5120-32C- und QFX5200-Switches unterstützen hierarchische 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-Typ-5-Paket mit einem VXLAN-Header eingekapselt und dann von einem QFX5-Switchxxx , der hierarchisches ECMP nicht unterstützt, entkapselt wird, ist der Switch nicht in der Lage, die zweistufigen Routen aufzulösen, die sich im inneren Paket befanden. Der Switch verwirft dann das Paket.

  • (QFX5100-, QFX5110-, QFX5120-, QFX5200- und QFX5210-Switches) 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-Routing-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 MAC-Adresse des virtuellen Gateways auf der IRB-Schnittstelle für das Edge-Routing-Bridging-Overlay unterscheiden.

  • (Nur QFX5110- und QFX5120-Switches) In einem EVPN-VXLAN-Overlay wird die Ausführung eines Routing-Protokolls auf einer IRB-Schnittstelle, die sich in einer Standard-Routing-Instanz (default.inet.0) befindet, nicht unterstützt. Stattdessen wird empfohlen, die IRB-Schnittstelle in eine Routinginstanz des Typs .vrf

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

    • (Nur QFX5-Switchesxxx ) Bei der Konfiguration von Routenlecks zwischen virtuellen Routing- und Weiterleiten-Instanzen (VRF) müssen Sie jedes Präfix mit einer Subnetzmaske angeben, die gleich oder länger als /16 für IPv4-Präfixe oder gleich oder größer als /64 für IPv6-Präfixe ist. Wenn eine von Ihnen angegebene Subnetzmaske diese Parameter nicht erfüllt, werden die angegebenen Routen nicht offengelegt.

    • (Nur QFX5120 Switches) Standardmäßig weisen QFX5120-Switches 5 MB eines gemeinsam genutzten Puffers zu, um Spitzen von Multicast-Datenverkehr zu absorbieren. Wenn ein Burst von Multicast-Datenverkehr 5 MB überschreitet, verwirft der Switch die Pakete, die der Switch erhält, nachdem der Pufferspeicher überschritten wurde. Um zu verhindern, dass der Switch in dieser Situation Multicastpakete 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 Multicastdatenverkehr neu zuzuordnen. Weitere Informationen zur Feinabstimmung eines gemeinsam genutzten Puffers finden Sie unter Grundlegendes zur CoS-Pufferkonfiguration.

      • Wenden Sie auf dem Switch von Juniper Networks, von dem die Multicast-Datenverkehrsausbrüche kommen, einen Shaper auf den Ausgangslink an.

    • (Nur QFX5-Switchesxxx ) Wenn Sie die Sturmsteuerung für eine Schnittstelle aktiviert haben, stellen Sie möglicherweise einen erheblichen Unterschied zwischen den konfigurierten und den tatsächlichen Datenverkehrsraten für die Schnittstelle fest. Dieser Unterschied ist das Ergebnis einer internen Sturmsteuerungsmessung, die 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-Bidirektional-Weiterleitungserkennung (BFD) mit VXLAN-Kapselung von BFD-Paketen verwenden. Wenn Sie EVPN-Overlay-BGP-Peerings konfigurieren, verwenden Sie 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 Verstehen, wie BFD Netzwerkfehler erkennt .

  • (QFX5xxx- und EX46xx-Switches) Die gleichzeitige Konfiguration und Verwendung von MPLS und EVPN-VXLAN auf demselben Gerät ist nicht unterstützt. Diese Einschränkung liegt 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 Stil von Service Providern.

VXLAN-Einschränkungen für Switches der QFX10000-Serie

  • MC-LAGs werden von VXLAN nicht unterstützt.

    Anmerkung:

    In einer EVPN-VXLAN-Umgebung wird für redundante Konnektivität zwischen Hosts und Leaf-Geräten der EVPN-Multihoming-Aktiv-Aktiv-Modus anstelle von MC-LAG verwendet.

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

  • Die folgenden Funktionen 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 (beliebige Variante).

  • Die 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-Verschiebungsbegrenzung.

  • Die Replikation von Eingangsknoten wird nicht unterstützt, wenn ein SDN-Controller für die Steuerungsebene (OVSDB-VXLAN) verwendet wird. Die Ingress-Node-Replikation 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 keine Ethernet Segment Identifier (ESI)- oder VTEP-Schnittstelle (Virtual Tunnel Endpoint) sein.

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

  • VLAN-Firewall-Filter, die auf IRB-Schnittstellen angewendet werden, auf denen EVPN-VXLAN aktiviert ist.

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

  • QFX10002-, QFX10008- und QFX10016-Switches 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-Routing-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 MAC-Adresse des virtuellen Gateways auf der IRB-Schnittstelle für das Edge-Routing-Bridging-Overlay unterscheiden.

  • In einem EVPN-VXLAN-Overlay wird die Ausführung eines Routing-Protokolls auf einer IRB-Schnittstelle, die sich in einer Standard-Routing-Instanz (default.inet.0) befindet, nicht unterstützt. Stattdessen wird empfohlen, die IRB-Schnittstelle in eine Routinginstanz des Typs .vrf

  • In einer EVPN-VXLAN-Umgebung unterstützen wir nicht die Konfiguration von Anycast-Gateways mit der Anweisung und der Anweisung auf Links, die default-gateway advertise am selben Ethernet-Segment (ES) teilnehmen.

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

VXLAN-Einschränkungen für Router der PTX10000-Serie

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

    set forwarding-options tunnel-termination

    Diese Option ist standardmäßig deaktiviert.

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

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

    Durch Hinzufügen der Option "no-tunnel-termining" wird die Tunnelterminierung für den gesamten Datenverkehr auf dem jeweiligen Port deaktiviert, an dem sie konfiguriert ist.

VXLAN-Einschränkungen für Router der ACX-Serie

  • Multihoming-Peers innerhalb eines Datencenters sollten aus einer ähnlichen Produktfamilie stammen. Es wird nicht empfohlen, die ACX-Serie mit der QFX-, PTX- oder MX-Serie für Multihoming zu kombinieren.

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

  • (ACX 7xxx-Router) Der Lastenausgleich 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) Konfiguration set system packet-forwarding-options system-profile vxlan-extended für die Unterstützung eines EVPN-VXLAN IPv6-Underlays.

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

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

  • (ACX 7xxx-Router) Eine benutzerdefinierte virtuelle Gateway-Adresse (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 die Weitergabe von DSCP-Informationen aus der Nutzlast an den VXLAN-Router-Header set system packet-forwarding-options no-ip-tos-rewrite 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) Für das EVPN-VXLAN-zu-EVPN-MPLS-Stitching sind Geräte, die keine Weiterleitung auf der Grundlage von Bridge-Domain-Labels unterstützen, nicht mit Geräten der ACX-Serie als DC-Peer-GWs kompatibel.

VXLAN-Einschränkungen auf allen Geräten

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