Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

VXLANs verstehen

Die VXLAN-Technologie (Virtual Extensible LAN Protocol) ermöglicht es Netzwerken, mehr VLANs zu unterstützen. Gemäß dem Standard IEEE 802.1Q sind herkömmliche VLAN-Identifikatoren 12 Bit lang – diese Benennung beschränkt Netzwerke auf 4094 VLANs. Das VXLAN-Protokoll überwindet diese Einschränkung durch die Verwendung einer längeren logischen Netzwerkkennung, die mehr VLANs und damit eine logischere Netzwerkisolierung für große Netzwerke wie Clouds mit typischerweise vielen virtuellen Maschinen ermöglicht.

VXLAN-Vorteile

Mit der VXLAN-Technologie können Sie Ihre Netzwerke segmentieren (wie dies bei VLANs der Fall ist), bietet jedoch Vorteile, die VLANs nicht bieten können. Hier sind die wichtigsten Vorteile der Verwendung von VXLANs:

  • Sie können theoretisch bis zu 16 Millionen VXLANs in einer administrativen Domäne erstellen (im Gegensatz zu 4094 VLANs auf einem Gerät von Juniper Networks).

    • Router der MX-Serie und EX9200-Switches unterstützen bis zu 32.000 VXLANs, 32.000 Multicast-Gruppen und 8000 virtuelle Tunnelendgeräte (VTEPs). Das bedeutet, dass VXLANs, die auf Routern der MX-Serie basieren, eine Netzwerksegmentierung in dem Umfang bieten, den Cloud Builder benötigen, um eine sehr große Anzahl von Mandanten zu unterstützen.

    • Switches der QFX10000-Serie unterstützen 4000 VXLANs und 2000 Remote-VTEPs.

    • QFX5100-, QFX5110-, QFX5200-, QFX5210- und EX4600-Switches unterstützen 4000 VXLANs, 4000 Multicast-Gruppen und 2000 Remote-VTEPs.

    • EX4300-48MP-Switches unterstützen 4000 VXLANs.

  • Sie können die Migration virtueller Maschinen zwischen Servern ermöglichen, die in separaten Layer 2-Domänen vorhanden sind, indem Sie den Datenverkehr über Layer 3-Netzwerke tunneln. Mit dieser Funktionalität können Sie Ressourcen innerhalb oder zwischen Datencentern dynamisch zuweisen, ohne durch Layer-2-Grenzen eingeschränkt zu sein oder gezwungen zu sein, große oder geografisch gestreckte Layer-2-Domänen zu erstellen.

Die Verwendung von VXLANs zur Erstellung kleinerer Layer-2-Domänen, die über ein Layer-3-Netzwerk verbunden sind, bedeutet, dass Sie nicht das Spanning Tree Protocol (STP) verwenden müssen, um die Topologie zu konvergieren, sondern stattdessen robustere Routing-Protokolle im Layer-3-Netzwerk verwenden können. Ohne STP wird keiner Ihrer Links blockiert, was bedeutet, dass Sie den vollen Nutzen aus allen von Ihnen erworbenen Ports ziehen können. Durch die Verwendung von Routing-Protokollen zur Verbindung Ihrer Layer 2-Domänen können Sie auch einen Lastenausgleich für den Datenverkehr vornehmen, um sicherzustellen, dass Sie Ihre verfügbare Bandbreite optimal nutzen. Angesichts des großen Ost-West-Datenverkehrs, der häufig innerhalb oder zwischen Datencentern fließt, ist die Optimierung der Netzwerkleistung für diesen Datenverkehr sehr wichtig.

Das Video Warum sollte man ein Overlay-Netzwerk in einem Datencenter verwenden? gibt einen kurzen Überblick über die Vorteile der Verwendung von VXLANs.

Wie funktioniert VXLAN?

VXLAN wird oft als Overlay-Technologie bezeichnet, da Sie damit Layer-2-Verbindungen über ein dazwischenliegendes Layer-3-Netzwerk strecken können, indem Sie Ethernet-Frames in ein VXLAN-Paket mit IP-Adressen einkapseln (tunneln). Geräte, die VXLANs unterstützen, werden als Virtual Tunnel Endpoints (VTEPs) bezeichnet – sie können Endhosts, Netzwerk-Switches oder Router sein. VTEPs kapseln VXLAN-Datenverkehr ein und entkapseln diesen Datenverkehr, wenn er den VXLAN-Tunnel verlässt. Um einen Ethernet-Frame zu kapseln, fügen VTEPs eine Reihe von Feldern hinzu, darunter die folgenden Felder:

  • MAC-Zieladresse (MAC-Adresse des Tunnelendpunkts, VTEP)

  • Äußere MAC-Quelladresse (MAC-Adresse des Tunnel-Quell-VTEP)

  • Äußere IP-Zieladresse (IP-Adresse des Tunnelendpunkts VTEP)

  • Äußere IP-Quelladresse (IP-Adresse des Tunnel-Quell-VTEP)

  • Äußerer UDP-Header

  • Ein VXLAN-Header, der ein 24-Bit-Feld enthält, das als VXLAN Network Identifier (VNI) bezeichnet wird und zur eindeutigen Identifizierung des VXLAN verwendet wird. Der VNI ähnelt einer VLAN-ID, aber mit 24 Bit können Sie viel mehr VXLANs als VLANs erstellen.

Anmerkung:

Da VXLAN dem ursprünglichen Ethernet-Frame 50 bis 54 Byte an zusätzlichen Header-Informationen hinzufügt, empfiehlt es sich, die MTU des zugrunde liegenden Netzwerks zu erhöhen. Konfigurieren Sie in diesem Fall die MTU der physischen Schnittstellen, die am VXLAN-Netzwerk teilnehmen, nicht die MTU der logischen VTEP-Quellschnittstelle, die ignoriert wird.

Abbildung 1 zeigt das VXLAN-Paketformat.

Abbildung 1: VXLAN-Paketformat VXLAN Packet Format

VXLAN-Implementierungsmethoden

Junos OS unterstützt die Implementierung von VXLANs in den folgenden Umgebungen:

  • Manuelles VXLAN: In dieser Umgebung fungiert ein Gerät von Juniper Networks als Transitgerät für nachgeschaltete Geräte, die als VTEPs fungieren, oder als Gateway, das die Konnektivität für nachgeschaltete Server bereitstellt, die virtuelle Maschinen (VMs) hosten, die über ein Layer-3-Netzwerk kommunizieren. In dieser Umgebung werden keine Controller für softwaredefinierte Netzwerke (SDN) bereitgestellt.

    Anmerkung:

    QFX10000-Switches unterstützen keine manuellen VXLANs.

  • OVSDB-VXLAN: In dieser Umgebung verwenden SDN-Controller das OVSDB-Verwaltungsprotokoll (Open vSwitch Database), um die Kommunikation zwischen Controllern (z. B. einem VMware NSX- oder Juniper Networks Contrail-Controller) und Geräten von Juniper Networks, die OVSDB unterstützen, zu ermöglichen.

  • EVPN-VXLAN: In dieser Umgebung ist Ethernet-VPN (EVPN) eine Steuerungsebenentechnologie, die es ermöglicht, Hosts (physische Server und VMs) überall in einem Netzwerk zu platzieren und mit demselben logischen Layer-2-Overlay-Netzwerk verbunden zu bleiben, während VXLAN die Datenebene für das Layer-2-Overlay-Netzwerk erstellt.

Verwenden von QFX5100-, QFX5110-, QFX5120-, QFX5200-, QFX5210-, EX4300-48MP- und EX4600-Switches mit VXLANs

Sie können die Switches so konfigurieren, dass sie alle der folgenden Rollen ausführen:

  • (Alle Switches außer EX4300-48MP) In einer Umgebung ohne SDN-Controller können Sie als Transit-Layer-3-Switch für nachgeschaltete Hosts fungieren und als VTEPs fungieren. Bei dieser Konfiguration müssen Sie keine VXLAN-Funktionen auf dem Switch konfigurieren. Sie müssen IGMP und PIM so konfigurieren, dass der Switch die Multicast-Strukturen für die VXLAN-Multicast-Gruppen bilden kann. (Weitere Informationen finden Sie unter Handbuch "VXLANs erfordern PIM ".)

  • (Alle Switches außer EX4300-48MP) In einer Umgebung mit oder ohne SDN-Controller fungieren Sie als Layer-2-Gateway zwischen virtualisierten und nicht virtualisierten Netzwerken im selben Datencenter oder zwischen Datencentern. Sie können den Switch beispielsweise verwenden, um ein Netzwerk, das VXLANs verwendet, mit einem Netzwerk zu verbinden, das VLANs verwendet.

  • (EX4300-48MP-Switches) Fungiert als Layer-2-Gateway zwischen virtualisierten und nicht virtualisierten Netzwerken in einem Campus-Netzwerk. Sie können den Switch beispielsweise verwenden, um ein Netzwerk, das VXLANs verwendet, mit einem Netzwerk zu verbinden, das VLANs verwendet.

  • (Alle Switches außer EX4300-48MP) Sie fungiert als Layer-2-Gateway zwischen virtualisierten Netzwerken im selben oder in verschiedenen Datencentern und ermöglicht das Verschieben virtueller Maschinen zwischen diesen Netzwerken und Datencentern (VMotion). Wenn Sie z. B. VMotion zwischen Geräten in zwei verschiedenen Netzwerken zulassen möchten, können Sie dasselbe VLAN in beiden Netzwerken erstellen und beide Geräte in dieses VLAN aufnehmen. Die mit diesen Geräten verbundenen Switches, die als VTEPs fungieren, können dieses VLAN demselben VXLAN zuordnen, und der VXLAN-Datenverkehr kann dann zwischen den beiden Netzwerken geroutet werden.

  • (QFX5110 und QFX5120 Switches mit EVPN-VXLAN) Fungiert als Layer-3-Gateway zum Weiterleiten des Datenverkehrs zwischen verschiedenen VXLANs im selben Datencenter.

  • (QFX5110 und QFX5120 Switches mit EVPN-VXLAN) Fungiert als Layer-3-Gateway zum Routing des Datenverkehrs zwischen verschiedenen VXLANs in verschiedenen Datencentern über ein WAN oder das Internet unter Verwendung von Standard-Routing-Protokollen oder VPLS-Tunneln (Virtual Private LAN Service).

Anmerkung:

Wenn Sie möchten, dass ein QFX5110- oder QFX5120-Switch ein Layer-3-VXLAN-Gateway in einer EVPN-VXLAN-Umgebung ist, müssen Sie IRB-Schnittstellen (Integrated Routing and Bridging) konfigurieren, um die VXLANs zu verbinden, genau wie beim Routing von Datenverkehr zwischen VLANs.

Da die zusätzlichen Header 50 bis 54 Byte hinzufügen, müssen Sie möglicherweise die MTU auf einem VTEP erhöhen, um größere Pakete unterzubringen. Wenn der Switch beispielsweise den Standard-MTU-Wert von 1514 Byte verwendet und Sie 1500-Byte-Pakete über das VXLAN weiterleiten möchten, müssen Sie die MTU erhöhen, um die durch die zusätzlichen Header verursachte erhöhte Paketgröße zu berücksichtigen.

Ändern des UDP-Ports auf QFX5100-, QFX5110-, QFX5200-, QFX5210- und EX4600-Switches

Beginnend mit Junos OS Version 14.1X53-D25 auf QFX5100-Switches, Junos OS Version 15.1X53-D210 auf QFX5110- und QFX5200-Switches, Junos OS Version 18.1R1 auf QFX5210-Switches und Junos OS Version 18.2R1 auf EX4600-Switches können Sie den UDP-Port konfigurieren, der als Zielport für VXLAN-Datenverkehr verwendet wird. Geben Sie die folgende Anweisung ein, um den VXLAN-Zielport so zu konfigurieren, dass er nicht der Standard-UDP-Port 4789 ist:

set protocols l2-learning destination-udp-port port-number

Der von Ihnen konfigurierte Port wird für alle auf dem Switch konfigurierten VXLANs verwendet.

Anmerkung:

Wenn Sie diese Änderung an einem Switch in einem VXLAN vornehmen, müssen Sie dieselbe Änderung auch an allen Geräten vornehmen, die die auf Ihrem Switch konfigurierten VXLANs beenden. Wenn Sie dies nicht tun, wird der Datenverkehr für alle auf Ihrem Switch konfigurierten VXLANs unterbrochen. Wenn Sie den UDP-Port ändern, gehen die zuvor erlernten Remote-VTEPs und Remote-MACs verloren und der VXLAN-Datenverkehr wird unterbrochen, bis der Switch die Remote-VTEPs und Remote-MACs erneut lernt.

Hosteintragsüberlaufverhinderung

Wenn die Hosttabelle ihre Kapazität erreicht, laufen standardmäßig zusätzliche Hosteinträge in die LPM-Tabelle (Longest Prefix Match) über. Dies kann zu einer Verschlechterung der Routing-Performance führen, die sich daraus ergibt, dass kleinere Hosteinträge wertvollen Speicherplatz in der LPM-Tabelle beanspruchen.

Ab Junos OS Version 25.2R1 können Sie verhindern, dass Hosteinträge in die LPM-Tabelle übergehen, indem Sie die set forwarding-options no-host-as-lpm Anweisung konfigurieren. Wenn Sie diese Option aktivieren, werden Hosteinträge daran gehindert, in die LPM-Tabelle einzutreten, und es wird eine Fehlermeldung protokolliert, um Sie über den vollständigen Zustand der Hosttabelle zu informieren. Durch diese Einschränkung bleibt die Integrität der LPM-Tabelle für größere Subnetzrouten erhalten, die in der Regel für einen effizienten Netzwerkbetrieb kritischer sind. Diese Konfiguration erfordert einen PFE-Neustart, um alle vorhandenen Hosteinträge aus der LPM-Tabelle zu löschen und sicherzustellen, dass die Tabelle ausschließlich für Subnetzrouten reserviert ist. Der Neustart ist für die Aufrechterhaltung eines sauberen Zustands von entscheidender Bedeutung, da er verhindert, dass sich verbleibende Hosteinträge auf die Tabellenbereichsauslastung auswirken.

Anmerkung:

Durch die Konfiguration der set forwarding-options no-host-as-lpm Anweisung wird die PFE in eigenständigen Geräten neu gestartet. Virtual Chassis (VC)-Geräte erfordern einen manuellen Neustart. Durch einen Neustart der PFE werden alle zuvor gelernten Hosteinträge aus der LPM-Tabelle entfernt.

Die Spillover-Verhinderung von Host-Einträgen ist besonders vorteilhaft für Umgebungen mit hohen Anforderungen an den Host-Zutritt. Die Funktion unterstützt sowohl IPv4- als auch IPv6-Routen und gilt für VXLAN- und Nicht-VXLAN-Umgebungen, wodurch sie sich vielseitig für verschiedene Bereitstellungsszenarien eignet. Durch die Trennung von Host- und Subnetzrouten wird eine Verschlechterung der Routing-Leistung vermieden, die durch Hosteinträge entsteht, die auf die LPM-Tabelle übergreifen. Darüber hinaus generiert das System jedes Mal, wenn Sie die CLI-Option umschalten, eine Systemprotokollmeldung, die einen Prüfpfad für das Änderungsmanagement und die Fehlerbehebung bereitstellt. Durch die Nutzung dieser Funktion können Sie die Verwaltung von Routing-Tabellen und die Routing-Effizienz verbessern und eine systematische Kontrolle über Routing-Tabellen-Einträge sicherstellen.

Im Funktions-Explorer finden Sie eine vollständige Liste der Produkte, die die Funktion "Host Entry Overflow Prevention" unterstützen.

CLI-Befehle

Verwenden Sie den folgenden CLI-Befehl, um die Funktion "Hosteintragsüberlaufverhinderung" zu konfigurieren:

set forwarding-options no-host-as-lpm

Mit diesem Befehl wird die Funktion aktiviert, die das Hinzufügen von Hosteinträgen zur LPM-Tabelle blockiert, wenn die Hosttabelle voll ist, wodurch LPM-Speicherplatz für größere Subnetzrouten erhalten bleibt.

Verwenden Sie den folgenden Befehl, um den Status der Funktion "Hosteintragsüberlaufverhinderung" zu überprüfen:

show forwarding-options no-host-as-lpm

Dieser Befehl zeigt den aktuellen Konfigurationsstatus an und gibt an, ob die Funktion aktiviert oder deaktiviert ist.

Verwenden Sie den folgenden Befehl, um eine Zusammenfassung der Routen in den Packet Forwarding Engine-Host- und LPM-Weiterleitungstabellen anzuzeigen:

show pfe route summary hw

Mit diesen Befehlen können Sie die Einträge der Routing-Tabelle effektiv verwalten und überwachen und so eine optimale Leistung und Skalierbarkeit in Ihrer Netzwerkumgebung gewährleisten.

Steuerung des Transit-Multicast-Datenverkehrs auf QFX5100-, QFX5110-, QFX5200-, QFX5210- und EX4600-Switches

Wenn der Switch, der als VTEP fungiert, ein Broadcast-, unbekanntes Unicast- oder Multicast-Paket empfängt, führt er die folgenden Aktionen für das Paket aus:

  1. Das Paket wird entkapselt und an die lokal angeschlossenen Hosts gesendet.

  2. Anschließend wird die VXLAN-Kapselung erneut hinzugefügt und das Paket an die anderen VTEPs im VXLAN gesendet.

Diese Aktionen werden von der Loopback-Schnittstelle ausgeführt, die als VXLAN-Tunneladresse verwendet wird, und können sich daher negativ auf die für den VTEP verfügbare Bandbreite auswirken. Beginnend mit Junos OS Version 14.1X53-D30 für QFX5100-Switches, Junos OS Version 15.1X53-D210 für QFX5110- und QFX5200-Switches, Junos OS Version 18.1R1 für QFX5210-Switches und Junos OS Version 18.2R1 für EX4600-Switches, wenn Sie wissen, dass keine Multicast-Empfänger an andere VTEPs im VXLAN angeschlossen sind, die Datenverkehr für eine bestimmte Multicast-Gruppe wünschen, Sie können die Verarbeitungslast auf der Loopback-Schnittstelle reduzieren, indem Sie die folgende Anweisung eingeben:

In diesem Fall wird kein Datenverkehr für die angegebene Gruppe weitergeleitet, aber der gesamte andere Multicastdatenverkehr wird weitergeleitet. Wenn Sie keinen Multicast-Datenverkehr an andere VTEPs im VXLAN weiterleiten möchten, geben Sie die folgende Anweisung ein:

Verwenden eines MX-Serie-Routers, EX9200-Switches oder QFX10000-Switches als VTEP

Sie können einen MX-Serie-Router, EX9200-Switch oder QFX10000-Switch so konfigurieren, dass er als VTEP fungiert und alle folgenden Rollen ausführt:

  • Fungiert als Layer-2-Gateway zwischen virtualisierten und nicht virtualisierten Netzwerken im selben Datencenter oder zwischen Datencentern. Beispielsweise können Sie einen Router der MX-Serie verwenden, um ein Netzwerk, das VXLANs verwendet, mit einem Netzwerk zu verbinden, das VLANs verwendet.

  • Sie fungiert als Layer-2-Gateway zwischen virtualisierten Netzwerken im selben oder in verschiedenen Datencentern und ermöglicht das Verschieben virtueller Maschinen zwischen diesen Netzwerken und Datencentern (VMotion).

  • Fungiert als Layer-3-Gateway zum Weiterleiten des Datenverkehrs zwischen verschiedenen VXLANs im selben Datencenter.

  • Fungiert als Layer-3-Gateway zum Routing des Datenverkehrs zwischen verschiedenen VXLANs in verschiedenen Datencentern über ein WAN oder das Internet unter Verwendung von Standard-Routing-Protokollen oder VPLS-Tunneln (Virtual Private LAN Service).

Anmerkung:

Wenn Sie möchten, dass eines der in diesem Abschnitt beschriebenen Geräte ein VXLAN-Layer-3-Gateway ist, müssen Sie IRB-Schnittstellen (Integrated Routing and Bridging) konfigurieren, um die VXLANs zu verbinden, genau wie beim Routing von Datenverkehr zwischen VLANs.

Manuelle VXLANs erfordern PIM

In einer Umgebung mit einem Controller (z. B. einem VMware NSX- oder Juniper Networks Contrail-Controller) können Sie VXLANs auf einem Gerät von Juniper Networks bereitstellen. Ein Controller stellt auch eine Steuerungsebene bereit, die VTEPs verwenden, um ihre Erreichbarkeit anzukündigen und sich über die Erreichbarkeit anderer VTEPs zu informieren. Sie können VXLANs auf Geräten von Juniper Networks auch manuell erstellen, anstatt einen Controller zu verwenden. Wenn Sie diesen Ansatz verwenden, müssen Sie auch Protocol Independent Multicast (PIM) auf den VTEPs konfigurieren, damit sie VXLAN-Tunnel untereinander erstellen können.

Außerdem müssen Sie jeden VTEP in einem bestimmten VXLAN so konfigurieren, dass er Mitglied derselben Multicast-Gruppe ist. (Wenn möglich, sollten Sie jedem VXLAN eine andere Multicast-Gruppenadresse zuweisen, obwohl dies nicht erforderlich ist. Mehrere VXLANs können sich dieselbe Multicast-Gruppe teilen.) Die VTEPs können dann ARP-Anfragen, die sie von ihren verbundenen Hosts erhalten, an die Multicast-Gruppe weiterleiten. Die anderen VTEPs in der Gruppe entkapseln die VXLAN-Informationen und leiten die ARP-Anfrage (vorausgesetzt, sie sind Mitglieder desselben VXLAN) an ihre verbundenen Hosts weiter. Wenn der Zielhost die ARP-Anforderung empfängt, antwortet er mit seiner MAC-Adresse, und sein VTEP leitet diese ARP-Antwort zurück an den Quell-VTEP. Durch diesen Prozess lernen die VTEPs die IP-Adressen der anderen VTEPs im VXLAN und die MAC-Adressen der Hosts, die mit den anderen VTEPs verbunden sind.

Die Multicastgruppen und -strukturen werden auch zum Weiterleiten von Broadcast-, unbekanntem Unicast- und Multicast-Datenverkehr (BUM) zwischen VTEPs verwendet. Dadurch wird verhindert, dass BUM-Datenverkehr unnötig außerhalb des VXLANs geflutet wird.

Anmerkung:

Multicast-Datenverkehr, der über einen VXLAN-Tunnel weitergeleitet wird, wird nur an die Remote-VTEPs im VXLAN gesendet. Das heißt, der einkapselnde VTEP kopiert und sendet keine Kopien der Pakete gemäß der Multicaststruktur, sondern leitet nur die empfangenen Multicastpakete an die Remote-VTEPs weiter. Die Remote-VTEPs entkapseln die eingekapselten Multicast-Pakete und leiten sie an die entsprechenden Layer-2-Schnittstellen weiter.

Load Balancing VXLAN-Datenverkehr

Die Layer-3-Routen, die VXLAN-Tunnel bilden, verwenden standardmäßig Load Balancing pro Paket, was bedeutet, dass Load Balancing implementiert wird, wenn ECMP-Pfade zum Remote-VTEP vorhanden sind. Dies unterscheidet sich vom normalen Routingverhalten, bei dem standardmäßig kein paketspezifisches Load Balancing verwendet wird. (Normales Routing verwendet standardmäßig Load Balancing pro Präfix.)

Das Feld "Quellport" im UDP-Header wird verwendet, um das ECMP-Load Balancing des VXLAN-Datenverkehrs im Layer-3-Netzwerk zu ermöglichen. Dieses Feld wird auf einen Hash der inneren Paketfelder gesetzt, wodurch eine Variable entsteht, mit der ECMP zwischen Tunneln (Flows) unterscheiden kann.

Keines der anderen Felder, die Flow-basiertes ECMP normalerweise verwendet, ist für die Verwendung mit VXLANs geeignet. Alle Tunnel zwischen denselben beiden VTEPs haben dieselbe äußere Quell- und Ziel-IP-Adresse, und der UDP-Zielport ist per Definition auf Port 4789 festgelegt. Daher bietet keines dieser Felder eine ausreichende Möglichkeit für den ECMP, um Datenströme zu unterscheiden.

Aktivieren von QFX5120-Switches zum Tunneln des Datenverkehrs auf Core-orientierten Layer-3-Tag- und IRB-Schnittstellen

Anmerkung:

Dieser Abschnitt gilt nur für QFX5120 Switches, die Junos OS Versionen 18.4R1, 18.4R2, 18.4R2-S1 bis 18.4R2-S3, 19.1R1, 19.1R2, 19.2Rx und 19.3Rx ausgeführt werden.

Wenn ein QFX5120-Switch versucht, Datenverkehr auf Core-orientierten Layer-3-Tagging-Schnittstellen oder IRB-Schnittstellen zu tunneln, verwirft der Switch die Pakete. Um dieses Problem zu vermeiden, können Sie eine einfache, filterbasierte Firewall mit zwei Begriffen auf der Layer-3-Tag- oder IRB-Schnittstelle konfigurieren.

Anmerkung:

QFX5120-Switches unterstützen maximal 256 filterbasierte Firewalls mit zwei Laufzeiten.

Zum Beispiel:

Begriff 1 stimmt mit Datenverkehr überein, der für den QFX5210-Switch bestimmt ist, der durch die Quell-VTEP-IP-Adresse (192.168.0.1/24) identifiziert wird, die der Loopback-Schnittstelle des Switches zugewiesen ist. Beachten Sie für Term 1, dass Sie beim Angeben einer Aktion alternativ den Datenverkehr zählen können, anstatt ihn zu akzeptieren.

Term 2 gleicht den gesamten anderen Datenverkehr ab und leitet ihn an eine Routing-Instanz (Route 1) weiter, die als Schnittstelle ET-0/0/3 konfiguriert ist.

Beachten Sie in diesem Beispiel, dass die Schnittstelle et-0/0/3 von der Routinginstanz route1 referenziert wird. Daher müssen Sie den set firewall family inet filter vxlan100 term 2 then routing-instance route1 Befehl einschließen. Ohne diesen Befehl funktioniert der Firewall-Filter nicht ordnungsgemäß.

Verwenden von Ping und Traceroute mit einem VXLAN

Auf QFX5100- und QFX5110-Switches können Sie die und-Befehle verwenden, um Fehler ping traceroute beim Datenverkehrsfluss durch einen VXLAN-Tunnel zu beheben, indem Sie den overlay Parameter und verschiedene Optionen einschließen. Sie verwenden diese Optionen, um zu erzwingen, dass die ping OR-Pakete traceroute denselben Pfad wie Datenpakete durch den VXLAN-Tunnel nehmen. Mit anderen Worten, Sie sorgen dafür, dass die Underlay-Pakete (ping und traceroute) den gleichen Weg wie die Overlay-Pakete (Datenverkehr) nehmen. Weitere Informationen finden Sie unter Ping-Overlay und Traceroute-Overlay .

Unterstützte VXLAN-Standards

RFCs und Internet-Entwürfe, die Standards für VXLAN definieren:

  • RFC 7348, Virtual eXtensible Local Area Network (VXLAN): Ein Framework für die Überlagerung virtualisierter Layer-2-Netzwerke über Layer-3-Netzwerke

  • Internet draft draft-ietf-nvo3-vxlan-gpe, generische Protokollerweiterung für VXLAN

Tabellarischer Änderungsverlauf

Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Funktionen entdecken , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.

Loslassen
Beschreibung
25.2R1
Ab Junos OS Release können Sie verhindern, dass Host-Routen in die LPM-Tabelle übergreifen.
14,1 X 53-D30
Beginnend mit Junos OS Version 14.1X53-D30 für QFX5100-Switches, Junos OS Version 15.1X53-D210 für QFX5110- und QFX5200-Switches, Junos OS Version 18.1R1 für QFX5210-Switches und Junos OS Version 18.2R1 für EX4600-Switches, wenn Sie wissen, dass keine Multicast-Empfänger an andere VTEPs im VXLAN angeschlossen sind, die Datenverkehr für eine bestimmte Multicast-Gruppe wünschen, Sie können die Verarbeitungslast auf der Loopback-Schnittstelle reduzieren
14,1 X 53-D25
Beginnend mit Junos OS Version 14.1X53-D25 auf QFX5100-Switches, Junos OS Version 15.1X53-D210 auf QFX5110- und QFX5200-Switches, Junos OS Version 18.1R1 auf QFX5210-Switches und Junos OS Version 18.2R1 auf EX4600-Switches können Sie den UDP-Port konfigurieren, der als Zielport für VXLAN-Datenverkehr verwendet wird.