ERSPAN fortid og nutid af Mylinking™ netværkssynlighed

Det mest almindelige værktøj til netværksovervågning og fejlfinding i dag er Switch Port Analyzer (SPAN), også kendt som Port-spejling. Det giver os mulighed for at overvåge netværkstrafik i bypass ud af bånd-tilstand uden at forstyrre tjenester på live-netværket, og sender en kopi af den overvågede trafik til lokale eller eksterne enheder, inklusive Sniffer, IDS eller andre typer netværksanalyseværktøjer.

Nogle typiske anvendelser er:

• Fejlfind netværksproblemer ved at spore kontrol/datarammer;

• Analyser latens og jitter ved at overvåge VoIP-pakker;

• Analyser latens ved at overvåge netværksinteraktioner;

• Opdag uregelmæssigheder ved at overvåge netværkstrafikken.

SPAN-trafik kan spejles lokalt til andre porte på den samme kildeenhed eller eksternt spejles til andre netværksenheder, der støder op til Layer 2 af kildeenheden (RSPAN).

I dag skal vi tale om Remote Internet-trafikovervågningsteknologi kaldet ERSPAN (Encapsulated Remote Switch Port Analyzer), der kan transmitteres på tværs af tre lag af IP. Dette er en udvidelse af SPAN til Encapsulated Remote.

Grundlæggende driftsprincipper for ERSPAN

Lad os først tage et kig på ERSPANs funktioner:

• En kopi af pakken fra kildeporten sendes til destinationsserveren til parsing gennem Generic Routing Encapsulation (GRE). Den fysiske placering af serveren er ikke begrænset.

• Ved hjælp af funktionen User Defined Field (UDF) på chippen, udføres enhver offset på 1 til 126 bytes baseret på Base-domænet gennem den udvidede liste på ekspertniveau, og sessionsnøgleordene matches for at realisere visualiseringen af sessionen, såsom TCP tre-vejs håndtryk og RDMA session;

• Understøtter indstilling af samplingsfrekvens;

• Understøtter pakkeaflytningslængde (Packet Slicing), hvilket reducerer trykket på målserveren.

Med disse funktioner kan du se, hvorfor ERSPAN er et vigtigt værktøj til overvågning af netværk inde i datacentre i dag.

ERSPANs hovedfunktioner kan opsummeres i to aspekter:

• Sessionssynlighed: Brug ERSPAN til at indsamle alle oprettede nye TCP- og RDMA-sessioner (Remote Direct Memory Access) til back-end-serveren til visning;

• Netværksfejlfinding: Fanger netværkstrafik til fejlanalyse, når der opstår et netværksproblem.

For at gøre dette skal kildenetværksenheden bortfiltrere trafikken af ​​interesse for brugeren fra den massive datastrøm, lave en kopi og indkapsle hver kopiramme i en speciel "superframe-beholder", der bærer nok yderligere information, så den kan være korrekt dirigeret til den modtagende enhed. Gør desuden den modtagende enhed i stand til at udtrække og gendanne den oprindelige overvågede trafik.

Den modtagende enhed kan være en anden server, der understøtter afkapsling af ERSPAN-pakker.

Indkapsling af ERSPAN-pakker

ERSPAN-type- og pakkeformatanalysen

ERSPAN-pakker indkapsles ved hjælp af GRE og videresendes til enhver IP-adresserbar destination over Ethernet. ERSPAN bruges i øjeblikket hovedsageligt 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 spejlpakkefangst af ICMP-pakker:

indkapslingsstruktur af ERSAPN

ERSPAN-protokollen har udviklet sig over en lang periode, og med forbedringen af ​​dens muligheder er der blevet dannet flere versioner, kaldet "ERSPAN-typer". Forskellige typer har forskellige frame header-formater.

Det er defineret i det første versionsfelt i ERSPAN-headeren:

ERSPAN header version

Derudover angiver feltet Protocol Type i GRE-headeren også den interne ERSPAN Type. Feltet Protocol Type 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 hovedet på 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 den sætter GRE Flag og Version felter til 0, bærer den ingen udvidede felter, og Type I er ikke meget brugt, så der er ingen grund til at udvide mere.

GRE-headerformatet for Type I er som følger:

GRE header format I

2. Type II

I Type II er felterne C, R, K, S, S, Recur, Flag og Version i GRE-headeren alle 0 undtagen S-feltet. Derfor vises feltet Sekvensnummer i GRE-headeren på Type II. Det vil sige, at Type II kan sikre rækkefølgen af ​​modtagelse af GRE-pakker, således at et stort antal ude af rækkefølge GRE-pakker ikke kan sorteres på grund af en netværksfejl.

GRE-headerformatet for Type II er som følger:

GRE header format II

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:

ERSPAN header format II

Endelig, umiddelbart efter den originale billedramme, er standard 4-byte Ethernet Cyclic Redundancy Check (CRC) kode.

CRC

Det er værd at bemærke, at i implementeringen indeholder spejlrammen ikke FCS-feltet for den originale 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 originale 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 adressere stadig mere komplekse og forskelligartede netværksovervågningsscenarier, herunder, men ikke begrænset til, netværksstyring, indbrudsdetektion, ydeevne- og forsinkelsesanalyse og mere. Disse scener skal kende alle de originale parametre for spejlrammen og inkludere dem, der ikke er til stede i selve den originale ramme.

ERSPAN Type III sammensatte header inkluderer en obligatorisk 12-byte header og en valgfri 8-byte platformspecifik underheader.

ERSPAN-headerformatet for Type III er som følger:

ERSPAN header format III

Igen, efter den originale spejlramme er en 4-byte CRC.

CRC

Som det kan ses af overskriftsformatet for Type III, tilføjes der, udover at bevare felterne Ver, VLAN, COS, T og Session ID på basis af Type II, mange specielle felter, såsom:

• BSO: bruges til at angive belastningsintegriteten af ​​datarammer, der føres gennem ERSPAN. 00 er en god ramme, 11 er en dårlig ramme, 01 er en kort ramme, 11 er en stor ramme;

• Tidsstempel: eksporteres 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): Specificerer tidsstemplets granularitet. For eksempel repræsenterer 00B 100 mikrosekunders granularitet, 01B 100 nanosekunders granularitet, 10B IEEE 1588 granularitet og 11B kræver platformsspecifikke underoverskrifter for at opnå højere granularitet.

• Platform-ID vs. Platformspecifik info: Platformspecifik info-felter har forskellige formater og indhold afhængigt af Platf-ID-værdien.

Port ID-indeks

Det skal bemærkes, at de forskellige overskriftsfelter, der understøttes ovenfor, kan bruges i almindelige ERSPAN-applikationer, selv spejlende fejlrammer eller BPDU-rammer, mens den originale Trunk-pakke og VLAN-ID bevares. Derudover kan nøgletidsstempeloplysninger og andre informationsfelter tilføjes til hver ERSPAN-ramme under spejling.

Med ERSPANs egne feature-headere kan vi opnå en mere raffineret analyse af netværkstrafikken, og så blot montere den tilsvarende ACL i ERSPAN-processen for at matche den netværkstrafik, vi er interesseret i.

ERSPAN implementerer RDMA-sessionssynlighed

Lad os tage et eksempel på at bruge ERSPAN-teknologi til at opnå RDMA-sessionsvisualisering i et RDMA-scenarie:

RDMA: Remote Direct Memory Access gør det muligt for netværksadapteren på server A at læse og skrive hukommelsen på server B ved at bruge intelligente netværkskort (inics) og switches, hvilket opnår høj båndbredde, lav latenstid og lav ressourceudnyttelse. Det er meget udbredt i big data og højtydende distribueret lagringsscenarier.

RoCEv2: RDMA over konvergeret Ethernet version 2. RDMA-dataene er indkapslet i UDP-headeren. Destinationsportnummeret er 4791.

Daglig drift og vedligeholdelse af RDMA kræver opsamling af en masse data, som bruges til at indsamle daglige vandstandsreferencelinjer og unormale alarmer, samt grundlaget for lokalisering af unormale problemer. Kombineret med ERSPAN kan massive data fanges hurtigt for at opnå mikrosekunders videresendelseskvalitetsdata og protokolinteraktionsstatus for switching-chip. Gennem datastatistik og analyse kan RDMA end-to-end videresendelseskvalitetsvurdering og forudsigelse opnås.

For at opnå RDAM-sessionsvisualisering har vi brug for ERSPAN til at matche søgeord til RDMA-interaktionssessioner, når vi spejler trafik, og vi skal bruge den udvidede ekspertliste.

Ekspert-niveau udvidet liste matchende feltdefinition:

UDF består af fem felter: UDF nøgleord, basisfelt, offsetfelt, værdifelt og maskefelt. Begrænset af kapaciteten af ​​hardwareindgange, kan i alt otte UDF'er bruges. En UDF kan maksimalt matche to bytes.

• UDF-nøgleord: UDF1... UDF8 Indeholder otte nøgleord for det matchende UDF-domæne

• Basisfelt: identificerer 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 går fra 0 til 126

• Værdifelt: matchende værdi. Den 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-matchende felt, skal basis- og offsetfelterne være de samme.)

De to nøglepakker, der er forbundet med RDMA-sessionsstatus, er Congestion Notification Packet (CNP) og Negative Acknowledgement (NAK):

Førstnævnte genereres af RDMA-modtageren efter at have modtaget ECN-meddelelsen sendt af switchen (når eout-bufferen når tærsklen), som indeholder information om flowet eller QP, der forårsager overbelastning. Sidstnævnte bruges til at angive, at RDMA-transmissionen har en pakketabssvarmeddelelse.

Lad os se på, hvordan man matcher disse to beskeder ved hjælp af den udvidede liste på ekspertniveau:

RDMA CNP

ekspert adgangsliste udvidet rdma

tillad udp enhver hvilken som helst hvilken som helst eq 4791udf 1 l4_header 8 0x8100 0xFF00(Matchende RG-S6520-64CQ)

tillad udp enhver hvilken som helst hvilken som helst eq 4791udf 1 l5_header 0 0x8100 0xFF00(Matchende RG-S6510-48VS8CQ)

RDMA CNP 2

ekspert adgangsliste udvidet rdma

tillad udp enhver hvilken som helst hvilken som helst eq 4791udf 1 l4_header 8 0x1100 0xFF00 udf 2 l4_header 20 0x6000 0xFF00(Matchende RG-S6520-64CQ)

tillad udp enhver hvilken som helst hvilken som helst eq 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 stadig større datacenternetværk, stadig mere kompleks netværkstrafik og stadig mere sofistikerede netværksdrift og vedligeholdelseskrav.

Med den stigende grad af O&M-automatisering er teknologier som Netconf, RESTconf og gRPC populære blandt O&M-studerende i netværksautomatisk O&M. Brug af gRPC som den underliggende protokol til at sende tilbage spejltrafik har også mange fordele. For eksempel, baseret på HTTP/2-protokollen, kan den understøtte streaming push-mekanismen under samme forbindelse. Med ProtoBuf-kodning reduceres størrelsen af ​​information til det halve sammenlignet med JSON-format, hvilket gør datatransmission 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 i høj grad forbedre evnen og effektiviteten af ​​netværkets automatiske drift og vedligeholdelse?


Indlægstid: 10. maj 2022