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-, QFX- und PTX-Serie

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

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

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

    • EVPN-VXLAN auf einem virtuellen EX4300-48MP-Chassis wird nur in Campus-Netzwerken unterstützt.

    • 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 multihomediert werden, aber wir unterstützen kein Multihoming eines Hosts mit ESI-LAG-Schnittstellen auf 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 mehrfach vernetzt werden, aber wir unterstützen kein Multihoming eines Hosts mit ESI-LAG-Schnittstellen auf EX4100 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 mehrfach vernetzt werden, aber wir unterstützen kein Multihoming eines Hosts mit ESI-LAG-Schnittstellen auf 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 anderen gemischten oder nicht gemischten Virtual Chassis oder VCF. Wir unterstützen VCF in EVPN-VXLAN-Datencenter-Umgebungen, in denen Junos OS-Versionen ab 14.1X53-D40 und älter als 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 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 lernt, 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 lernt und dieses Paket dann über die VCP-Links (Virtual Chassis-Port) an einen anderen Mitglieds-Switch im Virtual Chassis auf dem Weg zu seinem Ziel weiterleiten muss. Das Virtual Chassis markiert die MAC-Adresse, wie sie beim zweiten Mitglieds-Switch wieder zu sehen ist, sodass die MAC-Adresse möglicherweise nicht für ein oder zwei zusätzliche Alterungsintervalle nach dem ersten veraltet ist. Das MAC-Lernen kann auf VXLAN-Schnittstellen nicht nur am zweiten Virtual Chassis-Komponenten-Switch deaktiviert werden, sodass Sie die zusätzliche Verzögerung in diesem Fall nicht vermeiden können.

  • (Nur QFX5120 Switches) Datenverkehr, der über eine dem Core zugewandte Layer-3-Tagged-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 Kapselung von Ethernet-Services 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 Unternehmensstil und im 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.

  • (QFX5110 und QFX5120 Switches) In EVPN-VXLAN-Fabrics unterstützen wir keine Konfigurationen im Unternehmensstil, im Service Provider-Stil und native VLAN 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 Unternehmensstil sein. Weitere Informationen zu Konfigurationen im Unternehmensstil und im Service Provider-Stil finden Sie unter Flexible Ethernet Services Encapsulation.

  • (QFX5xxx-Switches) In einem EVPN-VXLAN-Fabric können Sie die native-vlan-id-Anweisung nicht auf derselben Schnittstelle konfigurieren, auf der Sie die VLAN-Übersetzung mit der vlan-rewrite-Anweisung 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) Die VXLAN-Konfiguration wird nur in der Routing-Instanz des Standard-Switches unterstützt.

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

    Hinweis:

    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.

  • (QFX5100-, QFX5110-, QFX5120-, EX4600- und EX4650-Switches) 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 eine der folgenden Aktionen 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, um VTEP-Erreichbarkeit aus der Ferne zu erreichen.

  • (QFX5110 Switches) Standardmäßig ist das Routing des Datenverkehrs 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 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.

    Hinweis:

    Ab den Junos OS-Versionen 18.1R3 und 18.4R1 für QFX5100-, QFX5110-, QFX5200- und QFX5210-Switches und Junos OS Version 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-Bundle-Schnittstellen (AE).)

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

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

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

    Wenn in Versionen vor Junos OS Version 22.2R3-S3 einem Port ein dynamisches VLAN zugewiesen wird, 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 Authentifizierung .

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

    Hinweis:

    In einer EVPN-VXLAN-Umgebung wird der EVPN-Multihoming-Aktiv-Aktiv-Modus anstelle von MC-LAG für redundante Konnektivität zwischen Hosts und Leaf-Geräten 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.

    • Redundante Trunk Groups (RTGs).

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

    • Wir unterstützen mit VXLAN keine vollständigen STP-, MSTP-, RSTP- oder VSTP (xSTP)-Funktionen. Sie können jedoch xSTP 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 z. B. 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 Funktionen, die von OVSDB-verwalteten Schnittstellen unterstützt werden.

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

      • EX4300-Multigigabit-Switches 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

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

      Wir unterstützen die folgenden Zugriffssicherheitsfunktionen auf zugriffsseitigen Layer-2-Schnittstellen, die VXLAN-zugeordneten VLANs zugeordnet sind:

      • DHCPv4- und DHCPv6-Snooping

      • Dynamische ARP-Inspektion (DAI)

      • Neighbor Discovery Inspection (NDI)

      • IPv4- und IPv6-Quellschutz

      • Router Advertisement (RA)-Schutz

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

  • Die Replikation von Eingangsknoten wird in den folgenden Fällen nicht unterstützt:

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

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

    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-Mirroring-Instance so konfigurieren, dass sie den Datenverkehr spiegelt, der von einer Schnittstelle ausgeht, die die 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.

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

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

    • (QFX5100 Schalter) Bei IRB-Schnittstellen in einer EVPN-VXLAN-IP-Fabric auf einer Ebene wird die Firewallfilterung und -überwachung nur am Eingangspunkt von nicht gekapselten 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 Ingress Route Access Control Lists [IRACLs].

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

    • (QFX5110 und QFX5120 Switches) Die Unterstützung für Filterung und Überwachung auf nicht gerouteten 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 einem bestimmten Kunden-VLAN zugeordnet ist. Der extended-vlan-bridge Kapselungstyp wird auf der physischen Schnittstelle konfiguriert.

    • Flexible Ethernet-Services, bei denen es sich um einen Kapselungstyp handelt, der es einer physischen Schnittstelle ermöglicht, sowohl die Schnittstellenkonfiguration von Service Providern als auch von Unternehmen 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 in einem oder mehreren angegebenen VLANs deaktivieren. Ab Junos OS Version 18.4R3 müssen Sie diese Funktion jedoch in 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 Mit 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

    Hinweis:

    Die no-arp-suppression Anweisung wird auf Switches der EX- 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 hierarchisches 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 gekapselt und dann von einem QFX5-Switchxxx entkapselt wird, der kein hierarchisches ECMP unterstützt, kann der Switch die beiden Routenebenen, die im inneren Paket enthalten waren, nicht auflösen. 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-geroutete 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-Routinginstanz (default.inet.0) befindet, nicht unterstützt. Stattdessen wird empfohlen, die IRB-Schnittstelle in eine Routinginstanz vom Typ vrf.

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

    • (Nur QFX5-Switchesxxx ) Wenn Sie Route Leaking zwischen virtuellen Routing- und Weiterleitungsinstanzen (VRF) konfigurieren, 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 länger als /64 für IPv6-Präfixe ist. Wenn eine von Ihnen angegebene Subnetzmaske diese Parameter nicht erfüllt, werden die angegebenen Routen nicht verloren.

    • (Nur QFX5120 Switches) Standardmäßig weisen QFX5120-Switches 5 MB eines gemeinsam genutzten Puffers zu, um Multicast-Datenverkehrsspitzen zu absorbieren. Wenn ein Multicast-Datenverkehrsschub 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 diesem Fall Multicast-Pakete verwirft, können Sie einen der folgenden Schritte ausführen:

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

      • Wenden Sie auf dem Juniper Networks-Switch, von dem die Multicast-Datenverkehrsspitzen ausgehen, einen Shaper auf den Ausgangslink an.

    • (Nur QFX5-Switchesxxx ) Wenn Sie die Sturmsteuerung 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. Dieser Unterschied ist das Ergebnis eines internen Sturmkontrollmessgeräts, 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) Die hardwaregestützte Inline-Erkennung bidirektionale Weiterleitung (BFD) mit VXLAN-Kapselung von BFD-Paketen ist nicht möglich. Wenn Sie EVPN-Overlay-BGP-Peerings konfigurieren, verwenden Sie außerdem verteiltes BFD anstelle von hardwareunterstütztem Inline-BFD. Weitere Informationen zu den verschiedenen Arten von BFD-Sitzungen, die Sie konfigurieren können, finden Sie unter Grundlegendes dazu, wie BFD Netzwerkfehler erkennt.

  • (QFX5xxx- und EX46xx-Switches) Die gleichzeitige 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 Hardwarebeschränkung von Broadcom.

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

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

    Hinweis:

    In einer EVPN-VXLAN-Umgebung wird der EVPN-Multihoming-Aktiv-Aktiv-Modus anstelle von MC-LAG für redundante Konnektivität zwischen Hosts und Leaf-Geräten 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 (alle Varianten).

  • Sicherheitsfunktionen für Zugriffsports werden von VXLAN nicht unterstützt. Die folgenden Funktionen werden beispielsweise 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 Replikation von Eingangsknoten 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 das EVPN-VXLAN-Overlay-Netzwerk enthält, darf der nächste Hop zu einem VXLAN-Peer keine Ethernet Segment Identifier (ESI)- oder eine Virtual Tunnel Endpoint (VTEP)-Schnittstelle sein.

  • IRB-Schnittstellen, die in EVPN-VXLAN-Overlay-Netzwerken verwendet werden, unterstützen das IS-IS-Routingprotokoll 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 die Portspiegelung und -analyse nicht, wenn EVPN-VXLAN ebenfalls 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-geroutete Bridging-Overlay unterscheiden.

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

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

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

VXLAN-Einschränkungen bei Routern der PTX10000 Serie

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

    set forwarding-options tunnel-termination

    Diese Option ist standardmäßig deaktiviert.

  • Sie können auf diesen Geräten keinen Firewallfilter verwenden, um die VXLAN-Tunnelterminierung an 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-termination wird die Tunnelterminierung für den gesamten Datenverkehr an dem Port deaktiviert, an dem sie konfiguriert ist.

VXLAN-Einschränkungen auf allen Geräten

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