Flow-basierte Telemetrie für VXLANs (QFX5120)

Vorteile von FBT für VXLANs

Mit FBT für VXLANs können Sie Inline-Telemetrie-Daten für EVPN-VXLAN-Architekturen aktivieren, die entweder CRB- oder ERB-Overlays haben, wodurch Sie eine zusätzliche Informationsquelle über Ihr Netzwerk erhalten.

Bei einem VXLAN mit CRB-Overlay sind Core-Switches als Layer-/Layer-3-VXLAN-Gateways konfiguriert, wobei die integrierten Routing- und Bridging-Schnittstellen (IRB) für die virtuellen Netzwerke auf den Core-Switches konfiguriert sind. Im Gegensatz dazu ermöglichen Core-Switches in einem VXLAN mit einem ERB-Overlay den Transport von EVPN-Routen vom Typ 2 und Typ 5, und die IRB-Schnittstellen sind auf den Distribution-Switches konfiguriert. Das ERB-Design ermöglicht auch einen schnelleren Server-zu-Server-Datenverkehr innerhalb des Campus. Das hat zur Folge, dass das Routing bei einem ERB-Overlay viel näher an den Endsystemen erfolgt als bei einem CRB-Overlay. Abbildung 1und Abbildung 2 zeigen Beispieltopologien für diese Overlays. Weitere Informationen zu diesen EVPN-VXLAN-Architekturen finden Sie unter Technology Primer: EVPN-VXLAN Fabrics for the Campus.

Abbildung 1: Topologie von Central-Routed Bridging (CRB)

Abbildung 2: Edge-Routed Bridging (ERB)-Topologie

Übersicht über den Flow-Export

FBT für VXLANs verwendet softwarebasierten IPFIX-Flow-Export. (IPFIX ist in RFC 7011 definiert.) Ein Datenstrom ist eine Abfolge von Paketen, die denselben Kernsatz von Parametern auf einer Schnittstelle haben, von denen einige Quell-IP, Ziel-IP, Quellport, Zielport und Protokoll sind. Dieser Kernparametersatz wird als Flow-Schlüssel bezeichnet, und die Software verwendet diesen Schlüssel, um mehr über die Flows zu erfahren. Für jeden Flow sammelt die Software verschiedene Parameter und exportiert das tatsächliche Paket bis zur konfigurierten Cliplänge an einen Collector, der die offene Standard-IPFIX-Vorlage verwendet, um den Flow zu organisieren. Sobald kein aktiver Datenverkehr für einen Datenstrom vorhanden ist, wird der Datenverkehr nach dem konfigurierten inaktiven Timeout veraltet (konfigurieren Sie die flow-inactive-timeout Anweisung auf Hierarchieebene [edit services inline-monitoring template template-name] ).

Bei FBT für VXLANs unterscheidet sich der Datenstromschlüssel je nachdem, ob Sie IPv4- oder IPv6-Datenverkehr überwachen. Der Datenstromschlüssel für IPv4-Datenverkehr wird in Tabelle 1 und der Datenstromschlüssel für IPv6-Datenverkehr in Tabelle 2 erläutert. Sowohl für IPv4- als auch für IPv6-Datenverkehr enthält der Datenstrom zusätzlich zu den Schlüsselfeldern Felder für die Eingangs- und Ausgangsports, die Start- und Endzeit des Datenstroms sowie das Byte- und Paketanzahldelta. Die Startzeit des Flows ist der Zeitstempel, zu dem die Software den Flow gelernt hat. Die Stop-Zeit des Flusses ist der Zeitstempel der letzten Zählerabfrage. Ein Beispiel für eine IPFIX-Datenvorlage für IPv4-Datenverkehr ist in Abbildung 3 dargestellt.

Abbildung 3: Beispiel für eine IPFIX-Datenvorlage für IPv4-Datenverkehr

Einschränkungen und Vorbehalte

• FBT für VXLANs wird nur unter Junos OS unterstützt.

• Es werden nur IRB-Schnittstellen unterstützt. Bei EVPN-VXLAN-Netzwerken mit CRB-Overlays können Sie die IRB-Schnittstellen nur auf der Spine überwachen. Bei EVPN-VXLAN-Netzwerken mit ERB-Overlays können Sie nur die IRB-Schnittstellen auf den Leaves überwachen.

• Es werden nur eine Inline-Überwachungsinstanz und ein Kollektor unterstützt.

• Der Kollektor muss über eine Netzwerkschnittstelle erreichbar sein, nicht nur über eine Management- oder Loopback-Schnittstelle.

• Sie können keinen Optionsvorlagenbezeichner oder eine Weiterleitungsklasse konfigurieren.

• Der IPFIX-Optionsdatensatz und die IPFIX-Optionsdatenvorlage werden nicht unterstützt.

• Flow-Learning und -Tracking basieren nur auf Client-Verkehrsdaten, nicht auf dem äußeren Tunnel-Header. Flow Learning ist softwarebasiert und dauert bis zu 10 Sekunden pro Flow.

• Zähler sind erst aktiv, wenn die Software den Fluss lernt und den Fluss in der Flusstabelle installiert.

• Die Software verwendet das TCP FIN/RST-Flag nicht für die Flussalterung.

• Die Software erfordert einen Layer-3-Header im Paket und unterstützt nur die Protokolle TCP und UDP.

• Der gemeldete Ausgangsport ist bei LAG-, ECMP-, Broadcast-, Multicast- oder unbekanntem Datenverkehr möglicherweise nicht korrekt, wenn sich der Ausgangsport in einem anderen VRF befindet.