Dat heefegst Tool fir Netzwierkiwwerwaachung a Problemléisung hautdesdaags ass de Switch Port Analyzer (SPAN), och bekannt als Port Mirroring. Et erlaabt eis den Netzwierkverkéier am Bypass Out-of-Band-Modus ze iwwerwaachen, ouni Servicer am Live-Netzwierk ze stéieren, an et schéckt eng Kopie vum iwwerwaachte Verkéier un lokal oder Ferngeräter, dorënner Sniffer, IDS oder aner Aarte vun Netzwierkanalyse-Tools.
E puer typesch Uwendungen sinn:
• Netzwierkproblemer léisen andeems Kontroll-/Datenrahmen verfollegt ginn;
• Latenz a Jitter analyséieren andeems VoIP-Pakete iwwerwaacht ginn;
• Latenz analyséieren andeems d'Interaktiounen am Netzwierk iwwerwaacht ginn;
• Anomalien duerch Iwwerwaachung vum Netzwierkverkéier erkennen.
SPAN-Verkéier kann lokal op aner Ports um selwechte Quellgerät gespigelt ginn, oder aus der Distanz op aner Netzwierkgeräter, déi nieft der Layer 2 vum Quellgerät (RSPAN) leien, gespigelt ginn.
Haut schwätze mir iwwer d'Technologie fir d'Iwwerwaachung vum Internetverkéier op Distanz, genannt ERSPAN (Encapsulated Remote Switch Port Analyzer), déi iwwer dräi Schichten IP iwwerdroe ka ginn. Dëst ass eng Erweiderung vu SPAN op Encapsulated Remote.
Grondprinzipie vun der Operatioun vum ERSPAN
Als éischt, kucke mer eis d'Features vun ERSPAN un:
• Eng Kopie vum Pak vum Quellport gëtt un den Destinatiounsserver geschéckt fir iwwer Generic Routing Encapsulation (GRE) ze parsen. Déi physesch Lag vum Server ass net limitéiert.
• Mat Hëllef vun der User Defined Field (UDF) Funktioun vum Chip gëtt all Offset vun 1 bis 126 Bytes baséiert op der Base Domain iwwer déi erweidert Lëscht op Expertenniveau duerchgefouert, an d'Sessiouns Schlësselwierder ginn ofgestëmmt fir d'Visualiséierung vun der Sessioun ze realiséieren, wéi den TCP Dräi-Wee Handshake an d'RDMA Sessioun;
• Ënnerstëtzung fir d'Astellung vun der Samplingrate;
• Ënnerstëtzt d'Längt vun der Pakettoffangung (Packet Slicing), wat den Drock um Zilserver reduzéiert.
Mat dëse Funktiounen kënnt Dir gesinn, firwat ERSPAN hautdesdaags e wesentlecht Instrument fir d'Iwwerwaachung vu Netzwierker an Datenzentren ass.
D'Haaptfunktioune vum ERSPAN kënnen an zwou Aspekter zesummegefaasst ginn:
• Sessiounsvisibilitéit: Benotzt ERSPAN fir all erstallt nei TCP- an Remote Direct Memory Access (RDMA)-Sessiounen op de Backend-Server fir d'Uweisung ze sammelen;
• Netzwierkfehlerbehebung: Erfaasst Netzwierkverkéier fir Feeleranalysen, wann e Netzwierkproblem optrieden.
Fir dëst ze maachen, muss den Quellnetzwierkgerät den Traffic, deen dem Benotzer interessant ass, aus dem massiven Datenstroum erausfilteren, eng Kopie maachen an all Kopieframe an e spezielle "Superframe-Container" akapselen, deen genuch zousätzlech Informatiounen enthält, fir datt se korrekt un den Empfangsgerät geroutet kënne ginn. Ausserdeem muss den Empfangsgerät den ursprénglechen iwwerwaachten Traffic extrahéieren a komplett recuperéieren.
Den Empfangsgerät kann en anere Server sinn, deen d'Dekapsuléierung vun ERSPAN-Päcketen ënnerstëtzt.
D'ERSPAN Typ- a Pakformatanalyse
ERSPAN-Päckete ginn mat GRE agekapselt a per Ethernet un all IP-adresséierbar Destinatioun weidergeleet. ERSPAN gëtt de Moment haaptsächlech op IPv4-Netzwierker benotzt, an IPv6-Ënnerstëtzung wäert an Zukunft eng Viraussetzung sinn.
Fir déi allgemeng Kapselstruktur vun ERSAPN ass déi folgend eng Spigelpaket-Erfassung vun ICMP-Päcketen:
Den ERSPAN-Protokoll huet sech iwwer eng laang Zäit entwéckelt, a mat der Verbesserung vu senge Méiglechkeeten goufen e puer Versioune geformt, déi "ERSPAN-Typen" genannt ginn. Verschidden Typen hunn ënnerschiddlech Frame-Header-Formater.
Et ass am éischte Versiounsfeld vum ERSPAN-Header definéiert:
Zousätzlech weist d'Feld "Protokolltyp" am GRE-Header och den internen ERSPAN-Typ un. D'Feld "Protokolltyp" 0x88BE weist ERSPAN-Typ II un, an 0x22EB weist ERSPAN-Typ III un.
1. Typ I
Den ERSPAN Frame vum Typ I encapsuléiert IP a GRE direkt iwwer den Header vum urspréngleche Spigelframe. Dës Encapsulatioun füügt 38 Bytes zum urspréngleche Frame bäi: 14(MAC) + 20 (IP) + 4(GRE). De Virdeel vun dësem Format ass, datt et eng kompakt Headergréisst huet an d'Käschte vun der Iwwerdroung reduzéiert. Well et awer d'Felder GRE Flag a Version op 0 setzt, enthält et keng erweidert Felder an Typ I gëtt net wäit verbreet, sou datt et net néideg ass, weider auszebauen.
De GRE-Headerformat vum Typ I ass wéi follegt:
2. Typ II
Am Typ II sinn d'Felder C, R, K, S, S, Recur, Flags a Version am GRE-Header all 0 ausser dem S-Feld. Dofir gëtt d'Sequence Number-Feld am GRE-Header vum Typ II ugewisen. Dat heescht, den Typ II kann d'Reiefolleg vum Empfang vu GRE-Päcketen garantéieren, sou datt eng grouss Zuel vun net-reegelméissegen GRE-Päcketen wéinst engem Netzwierkfehler net sortéiert ka ginn.
De GRE-Headerformat vum Typ II ass wéi follegt:
Zousätzlech füügt den ERSPAN Type II Frame-Format en 8-Byte ERSPAN Header tëscht dem GRE Header an dem urspréngleche gespigelte Frame bäi.
Den ERSPAN-Headerformat fir Typ II ass wéi follegt:
Schlussendlech, direkt nom urspréngleche Bildframe, kënnt de Standard 4-Byte Ethernet zyklische Redundanzcheck (CRC) Code.
Et ass derwäert ze bemierken, datt an der Implementatioun de Spigelframe net den FCS-Feld vum urspréngleche Frame enthält, mä amplaz gëtt en neie CRC-Wäert nei berechent op Basis vum gesamten ERSPAN. Dëst bedeit, datt den empfangenden Apparat d'CRC-Korrektheet vum urspréngleche Frame net verifizéiere kann, a mir kënnen nëmmen dovun ausgoen, datt nëmmen onverännert Frames gespigelt ginn.
3. Typ III
Typ III stellt e méi groussen a méi flexible Composite-Header an, fir ëmmer méi komplex an divers Netzwierk-Iwwerwaachungsszenarien unzegoen, dorënner, awer net limitéiert op, Netzwierkmanagement, Intrusiounsdetektioun, Performance- an Verzögerungsanalyse a méi. Dës Szenen mussen all déi ursprénglech Parameter vum Spigelframe kennen an och déi enthalen, déi net am urspréngleche Frame selwer präsent sinn.
Den ERSPAN Type III Composite-Header enthält en obligatoreschen 12-Byte-Header an en optionalen 8-Byte-plattformspezifeschen Ënnerheader.
Den ERSPAN-Headerformat fir Typ III ass wéi follegt:
Nach eng Kéier, nom urspréngleche Spigelframe ass e 4-Byte CRC.
Wéi um Headerformat vum Typ III ze gesinn ass, ginn nieft der Erhaalung vun de Felder Ver, VLAN, COS, T a Session ID op Basis vum Typ II och vill speziell Felder bäigefüügt, wéi zum Beispill:
• BSO: gëtt benotzt fir d'Luedintegritéit vun Datenrahmen unzeweisen, déi iwwer ERSPAN transportéiert ginn. 00 ass e gudde Frame, 11 ass e schlechte Frame, 01 ass e kuerze Frame, 11 ass e laange Frame;
• Zäitstempel: exportéiert vun der Hardware-Auer, synchroniséiert mat der Systemzäit. Dëst 32-Bit-Feld ënnerstëtzt op d'mannst 100 Mikrosekonnen Zäitstempelgranularitéit;
• Frame-Typ (P) a Frame-Typ (FT): déi éischt gëtt benotzt fir ze spezifizéieren, ob ERSPAN Ethernet-Protokollframes (PDU-Frames) dréit, an déi zweet gëtt benotzt fir ze spezifizéieren, ob ERSPAN Ethernet-Frames oder IP-Päcketen dréit.
• HW ID: eenzegaartegen Identifikateur vum ERSPAN-Motor am System;
• Gra (Timestamp Granularity): Spezifizéiert d'Granularitéit vum Zäitstempel. Zum Beispill representéiert 00B eng Granularitéit vun 100 Mikrosekonnen, 01B eng Granularitéit vun 100 Nanosekonnen, 10B eng IEEE 1588 Granularitéit, an 11B erfuerdert plattformspezifesch Ënnerheaderen fir eng méi héich Granularitéit z'erreechen.
• Plattform-ID vs. Plattformspezifesch Informatiounen: Plattformspezifesch Informatiounen hunn ënnerschiddlech Formater an Inhalter ofhängeg vum Wäert vun der Plattform-ID.
Et sollt een drop hiweisen, datt déi verschidden Headerfelder, déi uewe genannten ënnerstëtzt ginn, a regulären ERSPAN-Applikatioune benotzt kënne ginn, och wann et ëm Spigelung vu Feelerframes oder BPDU-Frames geet, wärend den ursprénglechen Trunk-Package an d'VLAN-ID erhale bleiwen. Zousätzlech kënnen zu all ERSPAN-Frame wärend dem Spigelung wichteg Zäitstempelinformatiounen an aner Informatiounsfelder bäigefüügt ginn.
Mat den eegenen Feature-Header vun ERSPAN kënne mir eng méi raffinéiert Analyse vum Netzwierkverkéier erreechen an dann einfach déi entspriechend ACL am ERSPAN-Prozess mounten, fir dem Netzwierkverkéier iwwereneestëmmen, un deem mir interesséiert sinn.
ERSPAN implementéiert RDMA Sessiounsvisibilitéit
Loosse mer e Beispill huelen, wéi d'ERSPAN-Technologie benotzt gëtt, fir eng RDMA-Sessiounsvisualiséierung an engem RDMA-Szenario z'erreechen:
RDMARemote Direct Memory Access erméiglecht et dem Netzwierkadapter vum Server A, de Späicher vum Server B ze liesen an ze schreiwen, andeems intelligent Netzwierk-Interfacekaarten (INICs) a Switche benotzt ginn, wouduerch eng héich Bandbreet, eng niddreg Latenz an eng niddreg Ressourcenausnotzung erreecht ginn. Et gëtt wäit verbreet a Big Data- a performante verdeelte Späicherszenarien benotzt.
RoCEv2RDMA iwwer konvergéiert Ethernet Versioun 2. D'RDMA-Donnéeë sinn am UDP-Header agekapselt. D'Destinatiounsportnummer ass 4791.
Den deegleche Betrib an d'Maintenance vun RDMA erfuerderen d'Sammlung vu ville Daten, déi benotzt gi fir deeglech Waasserstandsreferenzlinnen an anormal Alarmer ze sammelen, souwéi d'Basis fir d'Lokaliséierung vun anormalen Problemer. Kombinéiert mat ERSPAN kënnen massiv Daten séier erfaasst ginn, fir Mikrosekonnen-Weiderleedungsqualitéitsdaten an de Protokollinteraktiounsstatus vum Switching-Chip ze kréien. Duerch Datenstatistik an -analyse kann eng End-to-End-Weiderleedungsqualitéitsbeurteilung an -prognose vun RDMA gemaach ginn.
Fir d'Visualiséierung vun RDAM-Sessioune z'erreechen, brauche mir ERSPAN fir Schlësselwierder fir RDMA-Interaktiounssessiounen ze fannen, wann mir den Traffic spigelen, an dofir brauche mir déi erweidert Lëscht vun Experten.
Definitioun vu Matching-Feld op Expertenniveau mat enger erweiderter Lëscht:
Den UDF besteet aus fënnef Felder: UDF-Schlësselwuert, Basisfeld, Offsetfeld, Wäertfeld a Maskfeld. Limitéiert duerch d'Kapazitéit vun den Hardware-Entréen, kënnen am Ganzen aacht UDFs benotzt ginn. Eng UDF kann maximal zwee Bytes enthalen.
• UDF-Schlësselwuert: UDF1... UDF8 Enthält aacht Schlësselwierder vum UDF-Zesummenhangsdomän
• Basisfeld: identifizéiert d'Startpositioun vum UDF-Matchingfeld. Folgend
L4_Header (gëllt fir RG-S6520-64CQ)
L5_Header (fir RG-S6510-48VS8Cq)
• Offset: Weist den Offset baséiert op dem Basisfeld un. De Wäert läit tëscht 0 an 126.
• Wäertfeld: passende Wäert. Et kann zesumme mam Maskfeld benotzt ginn, fir de spezifesche Wäert ze konfiguréieren, deen ugepasst soll ginn. De gültege Bit ass zwee Bytes.
• Maskfeld: Mask, gültege Bit ass zwee Bytes
(Derbäisetzen: Wann méi Entréen am selwechte UDF-Matchingfeld benotzt ginn, mussen d'Basis- an d'Offsetfelder d'selwecht sinn.)
Déi zwee Schlësselpakete, déi mam RDMA-Sessiounsstatus verbonne sinn, sinn de Congestion Notification Packet (CNP) an den Negative Acknowledgment (NAK):
Déi éischt gëtt vum RDMA-Empfänger generéiert nodeems hien d'ECN-Noriicht kritt huet, déi vum Switch geschéckt gëtt (wann den eout-Buffer den Schwellwäert erreecht), déi Informatiounen iwwer de Flow oder de QP enthält, deen d'Stauung verursaacht. Déi zweet gëtt benotzt fir unzeweisen, datt d'RDMA-Iwwerdroung eng Packet-Loss-Äntwert-Noriicht huet.
Kucke mer emol, wéi een dës zwou Messagen mat der erweiderter Lëscht op Expertenniveau zesummebrénge kann:
Expert Zougangslëscht erweidert rdma
erlaabt udp all all all all Equatioun 4791udf 1 l4_header 8 0x8100 0xFF00(Passend zum RG-S6520-64CQ)
erlaabt udp all all all all Equatioun 4791udf 1 l5_header 0 0x8100 0xFF00(Passend zum RG-S6510-48VS8CQ)
Expert Zougangslëscht erweidert rdma
erlaabt udp all all all all Equatioun 4791udf 1 l4_header 8 0x1100 0xFF00 udf 2 l4_header 20 0x6000 0xFF00(Passend zum RG-S6520-64CQ)
erlaabt udp all all all all Equatioun 4791udf 1 l5_header 0 0x1100 0xFF00 udf 2 l5_header 12 0x6000 0xFF00(Passend zum RG-S6510-48VS8CQ)
Als leschte Schrëtt kënnt Dir d'RDMA-Sessioun visualiséieren andeems Dir d'Experten-Erweiderungslëscht an de passenden ERSPAN-Prozess mountéiert.
Schreift an der leschter
ERSPAN ass ee vun den onentbierlechen Tools an den haut ëmmer méi groussen Datenzenter-Netzwierker, dem ëmmer méi komplexen Netzwierkverkéier an den ëmmer méi sophistikéierten Ufuerderunge fir Netzwierkbetrib an Ënnerhalt.
Mat dem zouhuelende Grad vun O&M-Automatiséierung si Technologien wéi Netconf, RESTconf a gRPC bei O&M-Studenten am automateschen Netzwierk-O&M populär. D'Benotzung vu gRPC als Basisprotokoll fir de Récksende vu Spigelverkéier huet och vill Virdeeler. Zum Beispill kann et baséiert op dem HTTP/2-Protokoll de Streaming-Push-Mechanismus ënner der selwechter Verbindung ënnerstëtzen. Mat der ProtoBuf-Kodéierung gëtt d'Gréisst vun der Informatioun am Verglach zum JSON-Format ëm d'Halschent reduzéiert, wat d'Dateniwwerdroung méi séier a méi effizient mécht. Stellt Iech just vir, wann Dir ERSPAN benotzt fir interesséiert Streams ze spigelen an se dann un den Analyseserver op gRPC schéckt, wäert dat d'Fäegkeet an d'Effizienz vum automatesche Betrib an der Ënnerhaltung vum Netzwierk däitlech verbesseren?
Zäitpunkt vun der Verëffentlechung: 10. Mee 2022
