Konfigurieren der Remote-Portspiegelung für EVPN-VXLAN-Fabrics

In diesem Beispiel ermöglichen wir die Remote-Portspiegelung auf einem Lean Spine-Switch. Der gespiegelte Datenverkehr wird über einen GRE-Tunnel an die Remote-Überwachungsstation gesendet. Dieser Anwendungsfall basiert auf der Methode der Portspiegelungsinstanz.

In diesem Beispiel wird eine EVPN-VXLAN ERB-Architektur verwendet, bei der das Unicast Inter-Virtual Network Identifier (VNI)-Routing auf den Leaf-Geräten stattfindet. Die Lean-Spine-Geräte beenden keine VXLAN-Tunnel. Sie bieten IP-Weiterleitung und im Falle eines IBGP-basierten Overlays Routenreflektionsfunktionen. Unser Overlay ist EBGP-basiert, sodass wir keine Routenreflektion verwenden.

Diese Konfiguration spiegelt den gesamten Datenverkehr, der zwischen den Leaf-Geräten gesendet wird, wieder. Die Überwachungsstation erfasst sowohl intra-VLAN (überbrückt) als auch inter-VLAN (geroutet) Datenverkehr für alle VLANs auf den Leaves. Die spezifischen Informationen des Mandanten werden nicht auf den Lean-Spine-Geräten bereitgestellt, aber Sie können die Spiegelungssitzungen im Lean Spine aktivieren.

Achten Sie auf die Kapazität des Analyseports. Ein großer Teil des Datenverkehrs passiert den Analyse-Port, da Sie den gesamten Overlay-Datenverkehr, der zwischen den Leaf-Paarungen gesendet wird, spiegelt. Die Leaf-Geräte sind mit zwei 40-GE-Schnittstellen an den Spine angeschlossen, sodass sie die Kapazität haben, ein hohes Datenverkehrsvolumen zu übertragen. Switches verfügen über begrenzte Pufferungsfunktionen. Frameverluste treten auf, wenn mehr Datenverkehr gespiegelt wird als von der Überwachungsstation unterstützt.

Um die Kapazität zu erweitern, verwenden Sie eine aggregierte Ethernet-Schnittstelle mit mehreren Verbindungsmitgliedern. Reduzieren Sie die Datenverkehrslast durch Spiegelung der Leaf-Geräte und selektive Spiegelung des Datenverkehrs nur für bestimmte Mandanten.

In diesem Konfigurationsbeispiel werden die in Den Anforderungen dargestellten Hardware- und Softwarekomponenten verwendet. Die Geräte in der Topologie beginnen mit ihren Basiskonfigurationen, wie im Anhang angegeben: Vollständige Gerätekonfigurationen.

Wie in Abbildung 2 dargestellt, spiegelt Spine 1 den eingehenden und ausgehenden Overlay-Datenverkehr, der zwischen Leaf 1 und Leaf 4 durch einen Firewall-Filter fließt, der auf seine et-0/0/7-Schnittstelle angewendet wird. Diese Schnittstelle ist an Denkserver Leaf 1 angebunden. Overlay-Datenverkehr wird generiert, indem Ping-Datenverkehr zwischen Server 1 und Server 2 gesendet wird. Der gespiegelte Datenverkehr wird von Spine 1 an die Remote-Überwachungsstation gesendet, die mit der xe-0/0/33:1-Schnittstelle am Rand von Leaf 3 verbunden ist.

Abbildung 2: Topologie der Remote-Portspiegelung durch Spine-Gerät

Der Spine verwendet einen GRE-Tunnel, um den gespiegelten Datenverkehr an die Überwachungsstation zu senden. GRE ist erforderlich, da der gespiegelte Datenverkehr Layer 2 oder Overlay Layer 3 sein kann und daher nicht über das Fabric-Underlay geleitet werden kann. Der GRE-Tunnel wird automatisch gebildet, sobald die IP-Erreichbarkeit zum Überwachungs-Subnetz 172.16.1.0/24 über das Underlay eingerichtet wurde.

Server 1 ist in diesem Szenario single-homed zu Leaf 1.

Verwenden Sie dieses Beispiel, um den Datenverkehr, der Spine 1 passiert, zu spiegeln. Um den gesamten Datenverkehr zu spiegeln, wiederholen Sie die Konfiguration auf Spine 2. Wenn die Portspiegelung auf spines 1 und 2 konfiguriert ist, wird der Datenverkehr gespiegelt, unabhängig davon, welche ECMP-Fabric next Hop vom Leaf ausgewählt wird.

1. (Optional) BGP auf Spine 2 deaktivieren. Zu unseren Testzwecken deaktivieren wir die BGP stanza auf Spine 2. So können wir uns nur auf Spine 1 konzentrieren und sicherstellen, dass der gesamte Datenverkehr zwischen Leaf 1 und Leaf 4 gespiegelt wird.

   Nach der Deaktivierung von BGP auf Spine 2 hat Leaf 1 einen einzigen nächsten Hop, um das Loopback von Leaf 4 zu erreichen. Dies geschieht über Spine 1 über seine et-0/0/48-Schnittstelle.

2. Erstellen Sie eine Spiegelungsinstanz in Spine 1, um den gespiegelten Datenverkehr an die Remote-Überwachungsstation zu senden.

3. Lean Spines sind in einer ERB-Fabric nicht Overlay-fähig. Der gesamte VXLAN-eingekapselte Datenverkehr, der zwischen Leaf-Geräten gesendet wird, verwendet die lokale VTEP-Adresse. Die VTEP-Adresse entspricht normalerweise der Loopback-Adresse des Geräts. Das bedeutet, dass wir einen Filter auf den Spine-Geräten verwenden können, um die Loopback-Adressen der zugehörigen Leaf-Geräte abgleichen zu können, um den Datenverkehr in die Portspiegelinstanz zu leiten.

   Erstellen Sie bei Spine 1 Firewall-Filter, die mit den Quell- und Ziel-IP-Adressen von Leaf 1 und Leaf 4 übereinstimmen. Durch das Abgleichen sowohl der Quell- als auch der Ziel-IP wird der gesamte Overlay-Datenverkehr, der zwischen diesen Leafs gesendet wird, in den GRE-Tunnel gespiegelt.

   Hinweis:

   Da die Lean Spines nicht VXLAN-fähig sind, spiegelt diese Methode den gesamten Overlay-Datenverkehr, der vom Leaf-Gerät gesendet wird, wieder. Wenn beispielsweise auf dem Leaf 100 VLAN- oder VXLAN-VNIs definiert sind, wird der Datenverkehr für alle 100 VNIs gespiegelt. Wenn Sie einen Spiegel auf einer feineren Granularität spiegeln möchten, finden Sie unter Beispiel: Eingangslösung für ein EVPN-VXLAN ERB Fabric Leaf-Gerät. In diesem Beispiel tritt die Spiegelungsfunktion auf dem VXLAN-fähigen Leaf-Gerät auf.

   Legen Sie einen Firewall-Filter für den Datenverkehr fest, der von Leaf 1 gesendet wird. In unserem Beispiel hat der gesamte VXLAN-Datenverkehr, der von Leaf 1 (über die Spines) gesendet wird, eine Quelladresse von 10.1.255.11. Der gesamte von Leaf 4 gesendete VXLAN-Datenverkehr hat die Quelladresse 10.1.255.14.

   Richten Sie einen Firewall-Filter für den Datenverkehr ein, der von Leaf 4 gesendet wird.

4. Wenden Sie die Firewall-Filter auf die Leaf 1- und Leaf 4-Fabric-Schnittstellen an Spine 1 an.

   Notieren Sie sich die Ausrichtung der Filteranwendung. Unsere Filter unterstützen eine QFX5110-Plattform, die gemäß Tabelle 2 nur Eingangsfilter für die Portspiegelung unterstützt. Durch die Verwendung von Eingabefiltern, die mit dem VTEP des lokalen Leafs als Quelladresse und dem VTEP des Remote-Leafs als Zieladresse übereinstimmen, stellen wir sicher, dass nur der Overlay-Datenverkehr zwischen diesen beiden Leaves gespiegelt wird. Wenn Sie den gesamten VXLAN-Datenverkehr, der von einem Leaf gesendet wird, spiegeln möchten, unabhängig vom Zielblatt, passen Sie einfach die Quelladresse des lokalen Leafs in Ihrem Filter an.

5. (Optional) Fügen Sie zusätzliche Filter hinzu.

   In diesem Beispiel haben wir bisher davon ausgegangen, dass Server 1 nur für Leaf 1 als Single-Homed-Server verwendet wird. Wenn der Server zu Leaf 1 und Leaf 2 multihomed ist, müssen Sie die angezeigten Filter anpassen, um auch Datenverkehr abzufangen, der von Leaf 2 nach Leaf 4 gesendet wird, und umgekehrt.

   Diese Anweisungen erstellen beispielsweise einen Eingabefilter für die Leaf 2-orientierte Schnittstelle von Spine 1:

   Eine schnelle Änderung des vorhandenen port-mirror-from-leaf4 Filters ist erforderlich, um auch auf die Zieladresse von Leaf 2 VTEP zu passen.

6. Übernehmen Sie die Änderungen in Spine 1.

   Die Änderungen von der EVPN-VXLAN-Ausgangsbasis werden angezeigt:

7. Ändern Sie die Konfiguration bei Leaf 3, um die xe-0/0/33:1-Schnittstelle zu konfigurieren, die mit der Monitorstation verbunden ist.

   Das mit der Überwachungsstation verbundene Leaf-Gerät benötigt keine explizite GRE-Konfiguration. Dies liegt daran, dass der GRE-Tunnel an der Überwachungsstation endet. Sie müssen sicherstellen, dass die IP-Adresse der Überwachungsstation im Fabric-Underlay erreichbar ist. Anders angegeben kann der Spine den GRE-eingekapselten Datenverkehr nicht an die Überwachungsstation senden, wenn er nicht über eine Erreichbarkeit des Underlays an die Überwachungsstation verfügen.

8. Ändern Sie die Underlay-Exportrichtlinie am Rand von Leaf 3, um das Präfix der Überwachungsstation anzuzeigen. Unsere Topologie verwendet ein EBGP-Underlay. Wir fügen der bestehenden Underlay-Exportrichtlinie einfach einen neuen Begriff hinzu.

9. Übernehmen Sie die Änderungen auf Leaf 3-Rand.

   Die Änderungen an der Ausgangsbasis werden angezeigt:

1. Überprüfen Sie die Underlay-Konnektivität von Spine 1 zur Überwachungsstation.

   Zeigen Sie auf Spine 1 die Route zu 172.16.1.0/24 an.

   Hinweis:

   Streng genommen ist nur eine einfache Konnektivität zwischen Spine und Überwachungsstation erforderlich. Wir haben eine statische Route auf der Überwachungsstation so konfiguriert, dass sie das Fabric-Underlay erreicht. Dies ermöglicht Ping-Tests zur Fehlerisolierung.

   Pingen Sie die Überwachungsstation an, um die Konnektivität zu bestätigen.

   Der Ausgang bestätigt die erwartete Erreichbarkeit des Underlays vom Spine zur Überwachungsstation.

2. Bestätigen Sie die Portspiegelungsinstanzen auf Spine 1. Überprüfen Sie auf Spine 1, ob der Remote-Port-Spiegelungsstatus ist up.

   Die Ausgabe bestätigt die korrekte Definition der Port-Spiegelungsinstanz. Der Status von up zeigt an, dass die Spine einen Underlay-Weg zur Überwachungsstation hat. Erinnern Sie sich daran, dass GRE ein zustandsloses Protokoll ist. Deshalb ist es eine gute Idee, die Konnektivität zwischen Spine und Überwachungsstation zu überprüfen, wie im vorherigen Schritt.

3. Überprüfen Sie, ob die auf Spine 1 angewendeten Filter den Testdatenverkehr korrekt widerspiegeln.

   Löschen Sie die Zähler kurz vor dem Generieren von Pings.

   Starten Sie Pings zwischen Server 1 und Server 2 über die Fabric.

   Zeigen Sie jetzt die Firewall-Zähler auf Spine 1 an. Überprüfen Sie, ob die auf Spine 1 angewendeten Filter den Testdatenverkehr korrekt widerspiegeln. Unsere Beispieltopologie hat nur ein VLAN und ein Serverpaar. Dies macht es einfach, Testdatenverkehr zu Filter-Übereinstimmungen zu korrelieren. Jede Zahl, die nicht null ist, ist ein gutes Zeichen, dass der Filter funktioniert.

   Der Firewall-Zähler gibt den Testdatenverkehr zwischen den beiden Servern korrekt an.

4. Bestätigen Sie, dass der Datenverkehr, der zwischen Server 1 und Server 2 gesendet wird, auf Spine 1 gespiegelt und an die Überwachungsstation gesendet wird.

   Generieren Sie erneut Datenverkehr zwischen Server 1 und 2 (aus Gründen der Kürze nicht dargestellt). Verwenden Sie die rapid Option in Ihrem Ping-Befehl, um ein größeres Volumen an Testdatenverkehr zu generieren, wodurch die Korrelation einfacher wird.

   Überwachung des Schnittstellendatenverkehrs auf der Schnittstelle an Leaf 3-Rand, die mit der Überwachungsstation verbunden ist. Bestätigen Sie, dass die Ausgangspaketanzahl den generierten Testdatenverkehr widerspiegelt.

   Die Ausgabe bestätigt, dass der Datenverkehr zur Überwachungsstation gespiegelt wird. Das Fehlen von Eingangspaketen wird erwartet, da die Überwachungsstation keine Antworten auf den empfangenen GRE-Datenverkehr generiert.

5. Verwenden Sie Wireshark oder eine entsprechende Analyseanwendung, um den gespiegelten Datenverkehr zu erfassen und zu entschlüsseln.

   Abbildung 3: Spiegelung der Datenverkehrsanalyse

   Die Erfassung zeigt an, dass Server 1 Ping-Datenverkehr an Server 2 sendet und Server 2 antwortet. Dadurch wird bestätigt, dass der Overlay-Datenverkehr, der zwischen Leaf 1- und Leaf 4-Paarung gesendet wird, in Spine 1 korrekt gespiegelt wird. Beachten Sie, dass der VXLAN-eingekapselte Datenverkehr (UDP-Port 4789) wiederum in GRE eingekapselt ist (IP-Protokoll 47). Der Protokolltyp des GRE-Headers ist "ERSPAN" (vergleichbar mit der Remote-Portspiegelung), und alle anderen Flags sind auf Null gesetzt.

   Der Decode ermöglicht es Ihnen, die im Underlay verwendeten Leaf-VTEP- oder Loopback-Adressen zu sehen (10.1.255.x). Es ist auch der ursprüngliche Layer-2-Frame vorhanden, der von den Servern gesendet wird und nun als in VXLAN mit VNI 101 verkapselt dargestellt wird. Das ip-Paket, das von den Servern gesendet wird, wird ebenfalls decodiert. Die von den Servern im Overlay verwendeten IP-Adressen sind sichtbar (10.1.100.x/24), ebenso wie die Details der von ihnen generierten IP/ICMP-Pakete.

   Sie haben die Portspiegelung in Ihrer Topologie erfolgreich konfiguriert.

Verwenden Sie das folgende Beispiel, um den Datenverkehr zu spiegeln, der durch ein Leaf-Gerät in einer EVPN-VXLAN ERB Fabric fließt. Im Gegensatz zu dem im ersten Beispiel behandelten Lean Spine-basierten Port-Spiegelungsszenario ist das Leaf mandanten- und VLAN-fähig in einem ERB-Design. Das bedeutet, dass wir spezifischen Datenverkehr, der zwischen unseren Leaf-Geräten gesendet wird, spiegeln können, anstatt den gesamten Overlay-Datenverkehr. Die Tenant-Flows, die den Filterkriterien auf dem ERB Leaf-Gerät entsprechen, werden in einen GRE-Tunnel gespiegelt, der an der Überwachungsstation endet, die an Leaf 3-Rand angeschlossen ist.

In diesem Konfigurationsbeispiel werden die in Den Anforderungen dargestellten Hardware- und Softwarekomponenten verwendet. Die Geräte in der Topologie beginnen mit ihren Basiskonfigurationen, wie im Anhang angegeben: Vollständige Gerätekonfigurationen.

Abbildung 4 zeigt die Topologie für Remote-Port-Spiegelung mit Mandanten-Flow-Filterungsfunktionen.

Abbildung 4: Topologie der Remote-Portspiegelung durch Leaf-Gerät

Beachten Sie, dass Server 1 weiterhin nur für Leaf 1 als Single-Homed dient. Der Unterschied besteht darin, dass die Filter und die Portspiegelungsinstanz jetzt auf dem Leaf-Gerät definiert sind. Ziel ist es, den gesamten Datenverkehr, der von Server 1 an das VLAN 101.1.101.0/24-Subnetz gesendet wird, zuzuordnen. Der Datenverkehr, der von Server 1 an VLAN-101-Ziele gesendet wird, wird abgesendet und an die Portspiegelstation am Rand von Leaf 3 gesendet.

1. Konfigurieren Sie eine Portspiegelungsinstanz bei Leaf 1. Verwenden Sie die IP-Adresse 172.16.1.2 für die Überwachungsstation.

2. Als nächstes erstellen Sie einen Firewall-Filter, der auf das dem VLAN 101 zugewiesene Subnetz übereinstimmt. Das Ziel ist die Spiegelung des gesamten VLAN-101-Datenverkehrs, der von Server 1 über Leaf 1 gesendet wird. Geben Sie für die Zieladresse das Ziel-VLAN-Subnetz an, um den Datenverkehr zwischen VLANs abzufangen.

   Hinweis:

   Wenn Sie nur gerouteten Datenverkehr (inter-VLAN) spiegeln möchten, verwenden Sie einen family inet Filter, der auf die IRB-Schnittstelle des VLANs angewendet wird. Für jedes VLAN wird nur eine IRB-Schnittstelle definiert. Ein auf die IRB-Schnittstelle des VLAN angewendeter Filter fängt den gesamten Inter-VLAN-Datenverkehr für das zugehörige VLAN ab, unabhängig davon, auf welchem Port an der Vorderseite der Datenverkehr eintrifft.

   Die hier dargestellte Methode funktioniert für inter-VLAN- und intra-VLAN-Datenverkehr, erfordert jedoch die Anwendung von Filtern auf Serverschnittstellen basierend auf ihrer VLAN-Mitgliedschaft. Ein inet Filter, der auf eine IRB-Schnittstelle angewendet wird, sieht keinen überbrückten (intra-VLAN)-Datenverkehr.

3. Wenden Sie den Firewall-Filter für die Remote-Portspiegelung an den an Server 1 angeschlossenen Zugriffsport in Eingangsrichtung an.

   Hinweis:

   Auf QFX5110- und QFX5120-Switches kann der Firewall-Filter nicht in Ausgaberichtung angewendet oder an den mit den Spine-Geräten verbundenen Fabric-Schnittstellen verwendet werden.

4. Border Leaf 3 muss nicht für die GRE-Entkapselung konfiguriert werden, da der GRE-Tunnel an der Überwachungsstation endet. Leaf 3 muss jedoch die Erreichbarkeit für das Subnetz der Überwachungsstation im Underlay der Fabric anzeigen. Konfigurieren Sie Folgendes auf Leaf 3, um die Erreichbarkeit zur Überwachungsstation zu gewährleisten.

   Beginnen Sie mit der Konfiguration der an die Überwachungsstation angeschlossenen xe-0/0/33:1-Schnittstelle.

5. Ändern Sie die Underlay-Exportrichtlinie am Rand von Leaf 3, um das Präfix der Überwachungsstation anzuzeigen. Unsere Topologie verwendet ein EBGP-Underlay. Wir fügen der bestehenden Underlay-Exportrichtlinie einfach einen neuen Begriff hinzu.

6. Konfiguration bestätigen.

   Die Änderungen von der Ausgangsbasis werden bei Leaf 1 dargestellt.

   Sie haben die Remote-Portspiegelung über ein Leaf-Gerät in einer EVPN-VXLAN ERB-Fabric erfolgreich konfiguriert.

Ein Ethernet Segment Identifier (ESI) ist die eindeutige 10-Byte-Nummer, die ein Ethernet-Segment in einer mit dem Server verbundenen EVPN-VXLAN-Fabric identifiziert. Der ESI wird über die Schnittstelle konfiguriert, die eine Verbindung zum Server herstellt. Wenn mehrere Verbindungen eine Link Aggregation Group (LAG) bilden und mit dem Server verbunden sind, bildet dies eine ESI-LAG-Schnittstelle, auch EVPN LAG genannt. In einigen Fällen müssen Sie die Port-Spiegelung für den gesamten oder einen Teil des Datenverkehrs aktivieren, der an die ESI-LAG-Schnittstelle gelangt oder verlässt.

Verwenden Sie diesen Abschnitt, um die Remote-Portspiegelung auf ESI-LAG-Ebene einer EVPN-VXLAN ERB-Fabric zu ermöglichen.

In diesem Konfigurationsbeispiel werden die in Den Anforderungen dargestellten Hardware- und Softwarekomponenten verwendet. Die Geräte in der Topologie beginnen mit ihren Basiskonfigurationen, wie im Anhang angegeben: Vollständige Gerätekonfigurationen.

In diesem Fall ändern wir die EVPN-Fabric zur Unterstützung von Multihoming von Server 1 in Leaves 1 und 2. Wir tun dies mit ESI-LAG, auch bekannt als EVPN LAG, Schnittstellen. Best Practices zur EVPN LAG-Konfiguration finden Sie unter Best Practices.

Abbildung 6 zeigt die Topologie für dieses Beispiel. Beide Spines sind in dieser Topologie einsatzbereit. ECMP bedeutet, dass Leaf 1 und Leaf 2 Datenverkehr über jedes Spine-Gerät senden können. Um die Illustration zu vereinfachen, zeigen wir den Datenverkehr und Spiegelpfade mit Spine 1 als Schwerpunkt.

Abbildung 6: Topologie der Remote-Portspiegelung an der ESI-LAG-Schnittstelle

Schnittstelle ae0.0 ist die ESI-LAG-Schnittstelle, die an Server 1 angeschlossen ist. Server 1 erhält die IP-Adresse 10.1.101.10/24 und ist mit VLAN 101 verknüpft. Das Ziel ist es, den Datenverkehr, der von Server 1 gesendet wird, zu filtern und dann zu spiegeln, während er ae0.0 auf beiden Leafs passiert. Der gespiegelte Datenverkehr wird in einen GRE-Tunnel gelegt und an die Überwachungsstation gesendet. Wie zuvor müssen Sie sicherstellen, dass das Monitoring-Stations-Subnetz im EBGP-Underlay erreichbar ist.

Wenn Sie mit der im Anhang: Vollständigen Gerätekonfigurationen dargestellten Basiskonfiguration beginnen, führen Sie diese Schritte aus, um Ihre Topologie zu ändern, bevor Sie beginnen.

1. Ändern Sie die Konfiguration von Leaf 1 und Leaf 2, um eine Multihomed-Anlage von Server 1 zu unterstützen. Beginnen Sie mit der Umbenennung der vorhandenen xe-0/0-Schnittstelle, um die neue ae0.0-Schnittstelle zu werden. Diese Karies über jede Konfiguration von der xe-0/0/0-Schnittstelle, um einige Zeit zu sparen.

2. Die Konfigurationsspezifitäten für die aggregierte Ethernet-Schnittstelle des Servers, die oft als Bonded Interface in Linux bezeichnet wird, sprengen den Rahmen dieses NCE. Beachten Sie, dass es für den Server nur eine aggregierte Standard-Ethernet-Konfiguration gibt. Die Aussagen in Bezug auf ESI-LAG werden nur auf die Leaf-Geräte angewendet.

   Hinweis:

   Die Ausgangsbasiskonfiguration ermöglicht eine aggregierte Ethernet-Schnittstelle über die set chassis aggregated-devices ethernet device-count 1 Konfigurationsanweisung. Sie müssen die Gehäuseunterstützung für aggregierte Geräte aktivieren, oder die aggregierte Schnittstelle wird nicht erstellt.

3. Nachdem Sie diese Änderungen sowohl auf Leaf-Geräte als auch auf den Server angewendet und vorgenommen haben, bestätigen Sie, dass die ae0-Schnittstelle auf beiden Leaves aktiv ist. Die nachstehende Beispielausgabe wurde zur Verdeutlichung verkürzt.

   Vergewissern Sie sich auch, dass Server 1 Server 2 pingen kann (aus Gründen der Kürze nicht angezeigt).

In diesem Beispiel wird gezeigt, wie die Remote-Portspiegelung auf ESI-LAG-Ebene mithilfe einer Remote-Portspiegelungsinstanz ermöglicht wird. Diese Methode unterstützt mandantenspezifische Übereinstimmungskriterien (innerhalb eines Overlay-VLANs), um den Datenverkehr selektiv zu spiegeln.

1. Konfigurieren Sie eine Port-Spiegelungsinstanz sowohl für Leaf 1 als auch für Leaf 2. Server 1 kann Datenverkehr für VLAN 101 über eine der LAG-Member-Schnittstellen senden. ECMP bedeutet, dass der Datenverkehr an beiden Leafs eintreffen kann. DIE IP-Adresse 172.16.1.2 ist die Überwachungsstation.

2. Als nächstes erstellen Sie einen Firewall-Filter, der im Subnet, das VLAN 101 auf beiden Leaves zugewiesen wurde, übereinstimmt. Das Ziel ist die Spiegelung des gesamten VLAN-101-Datenverkehrs, der von Server 1 über Leaf 1 oder Leaf 2 gesendet wird. Geben Sie für die Zieladresse das Ziel-VLAN-Subnetz an, um den Datenverkehr zwischen VLANs abzufangen.

   Wenn Sie nach mehreren Quell- oder Ziel-IP-Adressen filtern müssen, sollten Sie ein source-prefix-list und/oder ein destination-prefix-list in Ihrem Filter verwenden. Auf diese Weise können Sie Änderungen an der Präfixliste vornehmen, ohne die Filterdefinition ändern zu müssen.

   Hinweis:

   Wenn Sie nur gerouteten Datenverkehr (inter-VLAN) spiegeln möchten, verwenden Sie einen family inet Filter, der auf die IRB-Schnittstelle des VLANs angewendet wird. Für jedes VLAN wird nur eine IRB-Schnittstelle definiert. Ein auf die IRB-Schnittstelle des VLAN angewendeter Filter fängt daher den gesamten Inter-VLAN-Datenverkehr für das zugehörige VLAN ab, unabhängig davon, an welchem Port an der Vorderseite der Datenverkehr eingeht.

   Die in diesem Beispiel dargestellte Methode funktioniert für Datenverkehr zwischen VLANs und innerhalb des VLANs, erfordert jedoch die Anwendung von Filtern auf Serverschnittstellen basierend auf der VLAN-Mitgliedschaft. Ein inet Filter, der auf eine IRB-Schnittstelle angewendet wird, sieht keinen überbrückten (intra-VLAN)-Datenverkehr.

3. Wenden Sie den Firewall-Filter für die Remote-Portspiegelung auf die ae0.0-Schnittstelle als Eingabefilter auf beiden Leaves an.

   Hinweis:

   Auf QFX5110- und QFX5120-Switches kann der Firewall-Filter nicht in Ausgangsrichtung aktiviert oder an den mit den Spine-Geräten verbundenen Schnittstellen verwendet werden.

4. Border Leaf 3 muss nicht für die GRE-Entkapselung konfiguriert werden, da der GRE-Tunnel an der Überwachungsstation endet. Leaf 3 muss jedoch die Erreichbarkeit für das Subnetz der Überwachungsstation im Underlay der Fabric anzeigen. Konfigurieren Sie die xe-0/0/33:1-Schnittstelle, die an die Überwachungsstation angeschlossen ist.

   Ändern Sie die Underlay-Exportrichtlinie am Rand von Leaf 3, um das Präfix der Überwachungsstation anzuzeigen. Unsere Topologie verwendet ein EBGP-Underlay. Wir fügen der bestehenden Underlay-Exportrichtlinie einfach einen neuen Begriff hinzu.

5. Die Änderungen an der Ausgangsbasis werden bei Leaf 1 dargestellt.

   Sie haben die Remote-Portspiegelung über ein Leaf-Gerät in einer EVPN-VXLAN ERB-Fabric erfolgreich konfiguriert.

1. Überprüfen Sie die Underlay-Konnektivität von Leaf 1 zur Überwachungsstation.

   Zeigen Sie auf Leaf 1 die Route zu 172.16.1.0/24 an.

   Hinweis:

   Streng genommen ist nur eine einfache Verbindung zwischen Leaf und Überwachungsstation erforderlich. Wir haben eine statische Route auf der Überwachungsstation so konfiguriert, dass sie das Fabric-Underlay erreicht. Dies ermöglicht Ping-Tests als Tool zur Fehlerisolierung.

   Pingen Sie die Überwachungsstation an, um die Konnektivität zu bestätigen.

   Der Ausgang bestätigt die erwartete Erreichbarkeit des Underlays von Leaf 1 zur Überwachungsstation. Wir müssen den Ping von der Loopback-Adresse des Leafs beziehen, da unsere Underlay-Exportrichtlinie nur die Erreichbarkeit der Loopback-Adresse ankündigen. Die Beschaffung von der Loopback-Adresse ist im Lean Spine-Fall nicht erforderlich. Dies liegt daran, dass Spine- und Border Leaf einen direkt verbundenen Fabric-Link teilen.

2. Bestätigen Sie die Port-Spiegelungsinstanz auf Leaf 1.

   Vergewissern Sie sich auf Leaf 1, dass der Remote-Port-Spiegelungsstatus lautet up.

   Die Ausgabe bestätigt die korrekte Definition der Port-Spiegelungsinstanz. Der Status von up zeigt an, dass das Leaf über eine Underlay-Route zur Überwachungsstation verfügt. Erinnern Sie sich daran, dass GRE ein zustandsloses Protokoll ist. Aus diesem Grund ist es eine gute Idee, die Konnektivität zwischen Leaf und Überwachungsstation zu überprüfen, wie im vorherigen Schritt.

3. Überprüfen Sie, ob der auf Leaf 1 und Leaf 2 angewendete Filter den Testdatenverkehr korrekt widerspiegelt. Starten Sie Pings zwischen Server 1 und Server 2 über die Fabric.

   Überprüfen Sie, ob der auf Leaf 1 angewendete Filter und Leaf 2 den Datenverkehr korrekt widerspiegeln. Unsere Beispieltopologie hat nur ein VLAN und ein Serverpaar. Dies macht es einfach, Testdatenverkehr zu Filter-Übereinstimmungen zu korrelieren. Jede Zahl, die nicht null ist, ist ein gutes Zeichen, dass der Filter funktioniert.

   Aufgrund des ECMP-Verhaltens werden einzelne Ping-Flow-Hashes an nur eine der aggregierten Ethernet-Schnittstellenverbindungen gesendet. Das bedeutet, dass erwartet wird, dass der Testdatenverkehr an ein Leaf oder das andere gesendet wird, aber nicht beide. Wenn Server 1 zahlreiche Datenströme generiert, erwarten Sie, dass Pakete über beide Memberschnittstellen an beide Leaves weitergeleitet werden.

   Löschen Sie die Zähler kurz vor dem Generieren von Pings.

   Zeigen Sie jetzt die Firewall-Zähler auf Leaf 1 und Leaf 2 an.

   Die Ausgabe zeigt, dass bei Leaf 1 keine Pakete angezeigt werden. Dies deutet darauf hin, dass der Server für diesen Datenfluss Hashing zu Leaf 2 angibt.

   Überprüfen Sie die Firewall-Zähler bei Leaf 2:

   Der Firewall-Zähler bei Leaf 2 gibt den generierten Testdatenverkehr korrekt an.

4. Bestätigen Sie, dass der Datenverkehr, der zwischen Server 1 und Server 2 gesendet wird, bei Leaf 1 und/oder Leaf 2 zur Übertragung an die Überwachungsstation gespiegelt wird.

   Generieren Sie erneut Datenverkehr zwischen Server 1 und 2 (aus Gründen der Kürze nicht dargestellt). Verwenden Sie die schnelle Option für den Ping-Befehl, um eine größere Menge an Paketen zu generieren, um die Erkennung zu erleichtern.

   Überwachen Sie die Schnittstellendatenzähler an Leaf 3-Rand, um zu überprüfen, ob der Testdatenverkehr an der Überwachungsstation eintrifft.

   Die Ausgabe bestätigt, dass der Datenverkehr an die Überwachungsstation gesendet wird. Das Fehlen von Eingangspaketen wird erwartet, da die Überwachungsstation keine Reaktionen auf den von ihr empfangenen GRE-Datenverkehr generiert.

5. Verwenden Sie Wireshark oder eine entsprechende Analyseanwendung, um den gespiegelten Datenverkehr zu erfassen und zu entschlüsseln.

   Abbildung 7: Spiegelung der Datenverkehrsanalyse

   Die Erfassung zeigt an, dass Server 1 Ping-Datenverkehr an Server 2 sendet. Der Antwortdatenverkehr wird nicht gespiegelt, da wir unseren Filter nur in Leaf 1 und Leaf 2 in Die Eingaberichtung angewendet haben. Wenden Sie eine ähnliche Portspiegelinstanz an und filtern Sie die Konfiguration bei Leaf 4, um den Rücklaufverkehr zu spiegeln. Erinnern Sie sich daran, dass im Lean Spine-Fall der gespiegelte Datenverkehr eine VXLAN-Einkapselung zeigte. In diesem ERB-Leaf-Fall spiegeln wir Layer-2-Datenverkehr, bevor er in VXLAN verkapselt wurde. Der zur Spiegelung des Datenverkehrs verwendete Filter wird als Eingabefilter auf die serverorientierte ae0.0-Schnittstelle angewendet. Es gibt keine VXLAN-Einkapselung am Eingang.

   Dies ist ähnlich wie bei der Anwendung eines Filters auf die IRB-Schnittstelle des VLANs. Im IRB-Filterfall enthält der gespiegelte Datenverkehr auch keine VXLAN-Einkapselung. IRB-Filter verarbeiten nur inter-VLAN-Datenverkehr auf der IP-Ebene. So wird für den IRB-Filterfall nur Layer-3-IP-Datenverkehr gespiegelt.

   Der Code zeigt, dass sich der GRE-Tunnel zwischen Leaf 2 und der Überwachungsstation durch das Underlay befindet. Das von Server 1 gesendete Ethernet-Frame- und IP-Paket wird ebenfalls decodiert. Die den Servern zugewiesenen IP-Adressen sind sichtbar (10.1.100.x/24), ebenso wie die Details des von Server 1 generierten IP/ICMP-Pakets.

   Sie haben die Portspiegelung in Ihrer Topologie erfolgreich konfiguriert.

Ein Ethernet Segment Identifier (ESI) ist die eindeutige 10-Byte-Nummer, die ein Ethernet-Segment identifiziert. Der ESI ist an der mit dem Server verbundenen Schnittstelle aktiviert. Wenn mehrere Verbindungen eine Link Aggregation Group (LAG) bilden, entsteht eine ESI-LAG,auch EVPN LAG genannt, Schnittstelle. In einigen Fällen müssen Sie die Portspiegelung direkt für den gesamten oder einen Teil des Datenverkehrs aktivieren, der an die ESI-LAG-Schnittstelle gelangt oder verlässt.

Sowohl Egress- als auch Ingress-Analyzer-Instanzen werden für ESI-LAG-Schnittstellen auf Leaf-Geräten in einer EVPN-VXLAN-Fabric unterstützt. Dies ist in einem Rechenzentrum nützlich, in dem der Administrator den gesamten Datenverkehr, der einen bestimmten ESI-LAG-Port betritt oder verlässt, an einen remoten Host senden muss. Verwenden Sie diesen Abschnitt, um eine Analyzer-Instanz auf ESI-LAG-Ebene einer EVPN-VXLAN ERB-Fabric zu aktivieren.

Eine Analyseinstanz unterscheidet sich von einer Portspiegelungsinstanz dadurch, dass der Analyzer im Eingang, im Ausgang oder in beide Richtungen arbeitet. Außerdem wird der gesamte Datenverkehr auf der Schnittstelle gespiegelt. Wenn Server 1 beispielsweise über 10 VLANs mit einer Trunkschnittstelle verfügt, wird der Datenverkehr von allen 10 VLANs an die Überwachungsstation gesendet. Im vorherigen Beispiel für die Portspiegelung wird ein Filter verwendet, um eine selektive Spiegelung des Datenverkehrs von einem VLAN oder von bestimmten IP-Adressen in einem VLAN zu ermöglichen.

Analyseinstanzen verwenden keine Firewall-Filter für die granulare Abgleichung. Der gesamte Datenverkehr in der angegebenen Richtung auf der angegebenen Schnittstelle wird gespiegelt.

In diesem Konfigurationsbeispiel werden die in Den Anforderungen dargestellten Hardware- und Softwarekomponenten verwendet. Die Geräte in der Topologie beginnen mit ihren Basiskonfigurationen, wie im Anhang angegeben: Vollständige Gerätekonfigurationen.

In diesem Beispiel wird eine ESI-LAG, auch EVPN LAG genannt, Schnittstelle zwischen Server 1 und Leaf 1 und Leaf 2 verwendet. Best Practices zur EVPN LAG-Konfiguration finden Sie unter Best Practices.

Abbildung 8 zeigt die Topologie für dieses Beispiel.

Abbildung 8: Topologie des Remote-Analyzers an einer ESI-LAG-Schnittstelle

Schnittstelle ae0.0 ist die ESI-LAG-Schnittstelle, die an Server 1 angeschlossen ist. Server 1 erhält die IP-Adresse 10.1.101.10/24 und ist mit VLAN 101 verknüpft. Ziel ist es, eine Analyzer-Instanz so zu konfigurieren, dass der gesamte an der ae0.0-Schnittstelle gesendete und empfangene Datenverkehr sowohl an Leaf 1 als auch an Leaf 2 weitergeleitet wird. Der gespiegelte Datenverkehr wird in einen GRE-Tunnel gelegt und an die Überwachungsstation gesendet. Wie zuvor müssen Sie sicherstellen, dass das Monitoring-Stations-Subnetz im EBGP-Underlay erreichbar ist.

Wenn Sie mit der im Anhang: Vollständigen Gerätekonfigurationen dargestellten Basiskonfiguration beginnen, führen Sie diese Schritte aus, um Ihre Topologie zu ändern, bevor Sie beginnen.

1. Ändern Sie die Konfiguration von Leaf 1 und Leaf 2, um eine Multihomed-Anlage von Server 1 zu unterstützen. Wir beginnen mit der Umbenennung der vorhandenen xe-0/0-Schnittstelle zur neuen ae0.0-Schnittstelle. Diese Karies über jede Konfiguration von der xe-0/0/0-Schnittstelle, um einige Zeit zu sparen.

   Die Konfigurationsspezifitäten für die aggregierte Ethernet-Schnittstelle des Servers, die oft als Bonded Interface in Linux bezeichnet wird, sprengen den Rahmen dieses NCE. Beachten Sie, dass es für den Server nur eine aggregierte Standard-Ethernet-Konfiguration gibt. Die Aussagen in Bezug auf ESI-LAG werden nur auf die Leaf-Geräte angewendet.

   Hinweis:

   Die Ausgangsbasiskonfiguration ermöglicht ein aggregiertes Ethernet-Gerät mithilfe der set chassis aggregated-devices ethernet device-count 1 Konfigurationsanweisung. Sie müssen die Gehäuseunterstützung für aggregierte Geräte aktivieren, oder die aggregierte Schnittstelle wird nicht erstellt.

2. Nachdem Sie diese Änderungen sowohl auf Leaf-Geräte als auch auf den Server angewendet und vorgenommen haben, bestätigen Sie, dass die ae0-Schnittstelle auf beiden Leaves aktiv ist. Die nachstehende Beispielausgabe wurde zur Verdeutlichung verkürzt.

   Vergewissern Sie sich, dass Server 1 Server 2 pingen kann (aus Gründen der Kürze nicht angezeigt).

Dieses Beispiel zeigt, wie Sie die Remote-Portspiegelung auf ESI-LAG-Ebene mithilfe einer Remote-Analyseinstanz aktivieren.

1. Die ae0.0-Schnittstelle ist die ESI-LAG-Schnittstelle, über die der Mandant Server 1 verbunden ist. Diese ESI-LAG endet sowohl bei Leaf 1 als auch bei Leaf 2. Konfigurieren Sie die Analyzer-Instanz auf beiden Leaves für die ae0.0-Schnittstelle. Beachten Sie, dass Sie einen Remote-Analyzer sowohl für die Ein- als auch die Ausgangsrichtung konfigurieren.

2. Border Leaf 3 muss nicht für die GRE-Entkapselung konfiguriert werden, da der GRE-Tunnel an der Überwachungsstation beendet wird. Leaf 3 muss jedoch die Erreichbarkeit für das Subnetz der Überwachungsstation im Underlay der Fabric anzeigen.

   Konfigurieren Sie die xe-0/0/33:1-Schnittstelle, die an die Überwachungsstation angeschlossen ist.

   Ändern Sie die Underlay-Exportrichtlinie am Rand von Leaf 3, um das Präfix der Überwachungsstation anzuzeigen. Unsere Topologie verwendet ein EBGP-Underlay. Wir fügen der bestehenden Underlay-Exportrichtlinie einfach einen neuen Begriff hinzu.

3. Die Änderungen von der Ausgangsbasis werden bei Leaf 1 dargestellt.

   Sie haben die Remote-Portspiegelung über ein Leaf-Gerät in einer EVPN-VXLAN ERB-Fabric erfolgreich konfiguriert.

1. Überprüfen Sie die Underlay-Konnektivität von Leaf 1 und Leaf 2 zur Überwachungsstation.

   Zeigen Sie auf Leaf 1 die Route zu 172.16.1.0/24 an.

   Hinweis:

   Streng genommen ist nur eine einfache Verbindung zwischen Leaf und Überwachungsstation erforderlich. Wir haben eine statische Route auf der Überwachungsstation so konfiguriert, dass sie das Fabric-Underlay erreicht. Dies ermöglicht Ping-Tests als Tool zur Fehlerisolierung.

   Pingen Sie die Überwachungsstation an, um die Konnektivität zu bestätigen.

   Der Ausgang bestätigt die erwartete Erreichbarkeit des Underlays von Leaf 1 zur Überwachungsstation. Wir müssen den Ping von der Loopback-Adresse des Leafs beziehen, da unsere Underlay-Exportrichtlinie nur die Erreichbarkeit der Loopback-Adresse ankündigen. Die Beschaffung der Loopback-Adresse wurde im Lean Spine-Beispiel nicht benötigt, da Spine und Border Leaf direkt über ein gemeinsam genutztes Fabric-Link-Subnetz verbunden sind.

2. Bestätigen Sie die Analyseinstanz auf Leaf 1 und Leaf 2.

   Vergewissern Sie sich auf Leaf 1, dass der Remote-Analysestatus lautet up.

   Die Ausgabe bestätigt die korrekte Definition der Analyzer-Instanz. Der Status von up zeigt an, dass das Leaf über eine Underlay-Route zur Überwachungsstation verfügt. Erinnern Sie sich daran, dass GRE ein zustandsloses Protokoll ist. Aus diesem Grund ist es eine gute Idee, die Konnektivität zwischen Leaf und Überwachungsstation zu überprüfen, wie im vorherigen Schritt.

3. Bestätigen Sie, dass der Datenverkehr, der zwischen Server 1 und Server 2 gesendet wird, von Leaf 1 und/oder Leaf 2 an die Überwachungsstation gespiegelt wird.

   Generieren Sie erneut Datenverkehr zwischen Server 1 und 2 (aus Gründen der Kürze nicht dargestellt). Wir nutzten die schnelle Option für den Ping-Befehl, um eine größere Menge an Paketen zu generieren, um die Erkennung zu erleichtern.

   Überwachen Sie die Schnittstellendatenzähler an Leaf 3-Rand, um zu überprüfen, ob der Testdatenverkehr an der Überwachungsstation eintrifft.

   Die Ausgabe bestätigt, dass der Datenverkehr an der Überwachungsstation eintrifft. Das Fehlen von Eingangspaketen wird erwartet, da die Überwachungsstation keine Reaktionen auf den von ihr empfangenen GRE-Datenverkehr generiert.

4. Verwenden Sie Wireshark oder eine entsprechende Analyseanwendung, um den gespiegelten Datenverkehr zu erfassen und zu entschlüsseln.

   Abbildung 9: Spiegelung der Datenverkehrsanalyse

   Die Erfassung zeigt an, dass Server 1 Ping-Datenverkehr an Server 2 sendet. Da die Analyseinstanzen auf beide Richtungen der ae0.0-Schnittstelle angewendet werden, wird auch der Antwortdatenverkehr gespiegelt. Da der Analyzer auf Schnittstellenebene funktioniert, wird auch LACP, ein Protokoll auf Link-Ebene, das auf der aggregierten Ethernet-Schnittstelle verwendet wird, gespiegelt. Erinnern Sie sich daran, dass im Lean Spine-Fall der gespiegelte Datenverkehr eine VXLAN-Einkapselung anzeigte. In diesem ERB-Leaf-Fall erfassen wir Layer-2-Datenverkehr, bevor er in VXLAN eingekapselt wurde. Beim Eingang erfolgt keine VXLAN-Einkapselung.

   Dies ist ähnlich wie bei der Anwendung eines Filters auf die IRB-Schnittstelle eines VLANs. In diesem Fall enthält der gespiegelte Datenverkehr auch keine VXLAN-Einkapselung. IRB-basierte Filter erfassen den Datenverkehr zwischen VLANs nur auf der IP-Ebene. So wird für den IRB-Filterfall nur nicht-VXLAN-verkapselter Layer 3-IP-Datenverkehr gespiegelt.

   Der Code zeigt, dass sich der GRE-Tunnel zwischen Leaf 2 (10.1.12.2) und der Überwachungsstation durch das Underlay befindet. Der Ethernet-Frame und das zugehörige IP-Paket, das von Server 1 gesendet wird, werden ebenfalls decodiert. Die den Servern zugewiesenen IP-Adressen sind sichtbar (10.1.100.x/24), ebenso wie die Details des von Server 1 generierten IP/ICMP-Pakets. Die Antwort von Server 2 wird ebenfalls gespiegelt, da die Analyzer-Instanz in unserem Beispiel bidirektional angewendet wird.

   Sie haben die Portspiegelung in Ihrer Topologie erfolgreich konfiguriert.