Det mest almindelige værktøj til netværksovervågning og fejlfinding i dag er Switch Port Analyzer (SPAN), også kendt som portspejling. Det giver os mulighed for at overvåge netværkstrafik i bypass out of band-tilstand uden at forstyrre tjenester på det aktive netværk og sender en kopi af den overvågede trafik til lokale eller eksterne enheder, herunder Sniffer, IDS eller andre typer netværksanalyseværktøjer.
Nogle typiske anvendelser er:
• Fejlfinding af netværksproblemer ved at spore kontrol-/datarammer;
• Analyser latenstid og jitter ved at overvåge VoIP-pakker;
• Analyser latenstid ved at overvåge netværksinteraktioner;
• Opdag uregelmæssigheder ved at overvåge netværkstrafik.
SPAN-trafik kan spejles lokalt til andre porte på den samme kildeenhed eller spejles eksternt til andre netværksenheder, der støder op til lag 2 på kildeenheden (RSPAN).
I dag skal vi tale om teknologi til fjernovervågning af internettrafik kaldet ERSPAN (Encapsulated Remote Switch Port Analyzer), der kan transmitteres på tværs af tre IP-lag. Dette er en udvidelse af SPAN til Encapsulated Remote.
Grundlæggende driftsprincipper for ERSPAN
Lad os først se på ERSPANs funktioner:
• En kopi af pakken fra kildeporten sendes til destinationsserveren til parsing via Generic Routing Encapsulation (GRE). Serverens fysiske placering er ikke begrænset.
• Ved hjælp af chippens brugerdefinerede felt (UDF) funktion udføres enhver offset på 1 til 126 bytes baseret på basedomænet via den udvidede liste på ekspertniveau, og sessionsnøgleordene matches for at realisere visualiseringen af sessionen, såsom TCP trevejs handshake og RDMA session;
• Understøttelse af indstilling af samplingsfrekvens;
• Understøtter pakkeopfangningslængde (Packet Slicing), hvilket reducerer presset på målserveren.
Med disse funktioner kan du se, hvorfor ERSPAN er et vigtigt værktøj til overvågning af netværk i datacentre i dag.
ERSPANs hovedfunktioner kan opsummeres i to aspekter:
• Sessionssynlighed: Brug ERSPAN til at indsamle alle oprettede nye TCP- og Remote Direct Memory Access (RDMA)-sessioner til backend-serveren til visning;
• Netværksfejlfinding: Registrerer netværkstrafik til fejlanalyse, når der opstår et netværksproblem.
For at gøre dette skal kildenetværksenheden filtrere den trafik, der er af interesse for brugeren, fra den massive datastrøm, lave en kopi og indkapsle hver kopiramme i en særlig "superframe-container", der indeholder nok yderligere information, så den kan dirigeres korrekt til den modtagende enhed. Desuden skal den modtagende enhed være i stand til at udtrække og fuldt ud gendanne den oprindelige overvågede trafik.
Modtagerenheden kan være en anden server, der understøtter dekapsulering af ERSPAN-pakker.
ERSPAN-type- og pakkeformatanalyse
ERSPAN-pakker indkapsles ved hjælp af GRE og videresendes til enhver IP-adresserbar destination via Ethernet. ERSPAN bruges i øjeblikket primært på IPv4-netværk, og IPv6-understøttelse vil være et krav i fremtiden.
For den generelle indkapslingsstruktur af ERSAPN er følgende en spejlpakkeoptagelse af ICMP-pakker:
ERSPAN-protokollen har udviklet sig over en lang periode, og med forbedringen af dens funktioner er der blevet dannet flere versioner, kaldet "ERSPAN-typer". Forskellige typer har forskellige frame header-formater.
Det er defineret i det første Version-felt i ERSPAN-headeren:
Derudover angiver feltet Protokoltype i GRE-headeren også den interne ERSPAN-type. Feltet Protokoltype 0x88BE angiver ERSPAN-type II, og 0x22EB angiver ERSPAN-type III.
1. Type I
ERSPAN-rammen af Type I indkapsler IP og GRE direkte over headeren i den originale spejlramme. Denne indkapsling tilføjer 38 bytes over den originale ramme: 14(MAC) + 20 (IP) + 4(GRE). Fordelen ved dette format er, at det har en kompakt headerstørrelse og reducerer transmissionsomkostningerne. Men fordi det sætter GRE Flag og Version-felterne til 0, bærer det ingen udvidede felter, og Type I er ikke udbredt, så der er ingen grund til at udvide yderligere.
GRE-headerformatet for Type I er som følger:
2. Type II
I Type II er felterne C, R, K, S, S, Recur, Flags og Version i GRE-headeren alle 0 undtagen S-feltet. Derfor vises feltet Sekvensnummer i GRE-headeren for Type II. Det vil sige, at Type II kan sikre rækkefølgen af modtagne GRE-pakker, så et stort antal GRE-pakker, der ikke er i rækkefølge, ikke kan sorteres på grund af en netværksfejl.
GRE-headerformatet for Type II er som følger:
Derudover tilføjer ERSPAN Type II-rammeformatet en 8-byte ERSPAN-header mellem GRE-headeren og den originale spejlede ramme.
ERSPAN-headerformatet for Type II er som følger:
Endelig, umiddelbart efter den originale billedramme, er standard 4-byte Ethernet cyklisk redundanskontrol (CRC) kode.
Det er værd at bemærke, at spejlrammen i implementeringen ikke indeholder FCS-feltet fra den oprindelige ramme. I stedet genberegnes en ny CRC-værdi baseret på hele ERSPAN. Det betyder, at den modtagende enhed ikke kan verificere CRC-korrektheden af den oprindelige ramme, og vi kan kun antage, at kun ukorrupte rammer spejles.
3. Type III
Type III introducerer en større og mere fleksibel sammensat header til at håndtere stadig mere komplekse og forskelligartede netværksovervågningsscenarier, herunder, men ikke begrænset til, netværksadministration, indtrængningsdetektion, ydeevne- og forsinkelsesanalyse og mere. Disse scener skal kende alle de oprindelige parametre for spejlrammen og inkludere dem, der ikke er til stede i selve den oprindelige ramme.
ERSPAN Type III-sammensatte header indeholder en obligatorisk 12-byte header og en valgfri 8-byte platformspecifik underheader.
ERSPAN-headerformatet for Type III er som følger:
Igen, efter den originale spejlramme er der en 4-byte CRC.
Som det kan ses af headerformatet for Type III, tilføjes der, udover at bevare felterne Ver, VLAN, COS, T og Session ID på basis af Type II, mange specialfelter, såsom:
• BSO: bruges til at angive indlæsningsintegriteten af datarammer, der transporteres gennem ERSPAN. 00 er en god ramme, 11 er en dårlig ramme, 01 er en kort ramme, 11 er en stor ramme;
• Tidsstempel: eksporteret fra hardwareuret synkroniseret med systemtiden. Dette 32-bit felt understøtter mindst 100 mikrosekunders tidsstempelgranularitet;
• Frame Type (P) og Frame Type (FT): førstnævnte bruges til at angive, om ERSPAN bærer Ethernet-protokolrammer (PDU-rammer), og sidstnævnte bruges til at angive, om ERSPAN bærer Ethernet-rammer eller IP-pakker.
• HW-ID: unik identifikator for ERSPAN-motoren i systemet;
• Gra (Tidsstempelgranularitet): Angiver granulariteten for tidsstemplet. For eksempel repræsenterer 00B en granularitet på 100 mikrosekunder, 01B en granularitet på 100 nanosekunder, 10B en IEEE 1588-granularitet, og 11B kræver platformspecifikke underoverskrifter for at opnå højere granularitet.
• Platform-ID vs. platformspecifikke oplysninger: Platformspecifikke oplysninger har forskellige formater og indhold afhængigt af platform-ID-værdien.
Det skal bemærkes, at de forskellige headerfelter, der understøttes ovenfor, kan bruges i almindelige ERSPAN-applikationer, selv spejling af fejlrammer eller BPDU-rammer, samtidig med at den originale Trunk-pakke og VLAN-ID bevares. Derudover kan vigtige tidsstempeloplysninger og andre informationsfelter tilføjes til hver ERSPAN-ramme under spejling.
Med ERSPANs egne funktionsoverskrifter kan vi opnå en mere raffineret analyse af netværkstrafikken og derefter blot montere den tilsvarende ACL i ERSPAN-processen, så den matcher den netværkstrafik, vi er interesserede i.
ERSPAN implementerer RDMA-sessionssynlighed
Lad os tage et eksempel på brugen af ERSPAN-teknologi til at opnå visualisering af RDMA-sessioner i et RDMA-scenarie:
RDMAFjernadgang til direkte hukommelse gør det muligt for netværksadapteren på server A at læse og skrive til hukommelsen på server B ved hjælp af intelligente netværkskort (INIC'er) og switche, hvilket opnår høj båndbredde, lav latenstid og lav ressourceudnyttelse. Det bruges i vid udstrækning i big data- og højtydende distribueret lagringsscenarier.
RoCEv2RDMA over Converged Ethernet version 2. RDMA-dataene er indkapslet i UDP-headeren. Destinationsportnummeret er 4791.
Daglig drift og vedligeholdelse af RDMA kræver indsamling af en masse data, som bruges til at indsamle daglige vandstandsreferencelinjer og unormale alarmer, samt som grundlag for at lokalisere unormale problemer. Kombineret med ERSPAN kan massive data hurtigt indsamles for at opnå mikrosekunds videresendelseskvalitetsdata og protokolinteraktionsstatus for switching-chippen. Gennem datastatistik og -analyse kan RDMA end-to-end videresendelseskvalitetsvurdering og -forudsigelse opnås.
For at opnå visualisering af RDAM-sessioner skal ERSPAN matche nøgleord for RDMA-interaktionssessioner, når vi spejler trafik, og vi skal bruge den udvidede ekspertliste.
Definition af matchende felt på udvidet liste på ekspertniveau:
UDF'en består af fem felter: UDF-nøgleord, basisfelt, offsetfelt, værdifelt og maskefelt. Begrænset af kapaciteten af hardwareposter kan der i alt bruges otte UDF'er. Én UDF kan matche maksimalt to bytes.
• UDF-nøgleord: UDF1... UDF8 Indeholder otte nøgleord fra UDF-matchningsdomænet
• Basisfelt: Angiver startpositionen for UDF-matchningsfeltet. Følgende
L4_header (gælder for RG-S6520-64CQ)
L5_header (til RG-S6510-48VS8Cq)
• Offset: angiver offset baseret på basisfeltet. Værdien ligger fra 0 til 126
• Værdifelt: matchende værdi. Det kan bruges sammen med maskefeltet til at konfigurere den specifikke værdi, der skal matches. Den gyldige bit er to bytes
• Maskefelt: maske, gyldig bit er to bytes
(Tilføj: Hvis der bruges flere poster i det samme UDF-matchningsfelt, skal basis- og offsetfelterne være de samme.)
De to nøglepakker, der er knyttet til RDMA-sessionsstatus, er Congestion Notification Packet (CNP) og Negative Acknowledgment (NAK):
Førstnævnte genereres af RDMA-modtageren efter at have modtaget ECN-beskeden sendt af switchen (når eout-bufferen når tærsklen), som indeholder information om flowet eller QP'en, der forårsager overbelastning. Sidstnævnte bruges til at indikere, at RDMA-transmissionen har en pakketabsresponsbesked.
Lad os se på, hvordan man matcher disse to beskeder ved hjælp af den udvidede liste på ekspertniveau:
Ekspert adgangsliste udvidet rdma
tillad udp enhver enhver enhver enhver ligning 4791udf 1 l4_header 8 0x8100 0xFF00(Matchende RG-S6520-64CQ)
tillad udp enhver enhver enhver enhver ligning 4791udf 1 l5_header 0 0x8100 0xFF00(Matchende RG-S6510-48VS8CQ)
Ekspert adgangsliste udvidet rdma
tillad udp enhver enhver enhver enhver ligning 4791udf 1 l4_header 8 0x1100 0xFF00 udf 2 l4_header 20 0x6000 0xFF00(Matchende RG-S6520-64CQ)
tillad udp enhver enhver enhver enhver ligning 4791udf 1 l5_header 0 0x1100 0xFF00 udf 2 l5_header 12 0x6000 0xFF00(Matchende RG-S6510-48VS8CQ)
Som et sidste trin kan du visualisere RDMA-sessionen ved at montere ekspertudvidelseslisten i den relevante ERSPAN-proces.
Skriv i det sidste
ERSPAN er et af de uundværlige værktøjer i nutidens stadigt større datacenternetværk, stadig mere kompleks netværkstrafik og stadig mere sofistikerede krav til netværksdrift og vedligeholdelse.
Med den stigende grad af O&M-automatisering er teknologier som Netconf, RESTconf og gRPC populære blandt O&M-studerende inden for automatisk netværksdrift og -vedligeholdelse. Brugen af gRPC som den underliggende protokol til at sende mirror-trafik tilbage har også mange fordele. For eksempel kan det, baseret på HTTP/2-protokollen, understøtte streaming-push-mekanismen under den samme forbindelse. Med ProtoBuf-kodning reduceres informationsstørrelsen med halvdelen sammenlignet med JSON-formatet, hvilket gør dataoverførslen hurtigere og mere effektiv. Forestil dig bare, hvis du bruger ERSPAN til at spejle interesserede streams og derefter sender dem til analyseserveren på gRPC, vil det så forbedre evnen og effektiviteten af automatisk netværksdrift og -vedligeholdelse betydeligt?
Udsendelsestidspunkt: 10. maj 2022
