Det vanligste verktøyet for nettverksovervåking og feilsøking i dag er Switch Port Analyzer (SPAN), også kjent som portspeiling. Den lar oss overvåke nettverkstrafikk i bypass ut av båndmodus uten å forstyrre tjenester på live-nettverket, og sender en kopi av den overvåkede trafikken til lokale eller eksterne enheter, inkludert Sniffer, IDS eller andre typer nettverksanalyseverktøy.
Noen typiske bruksområder er:
• Feilsøk nettverksproblemer ved å spore kontroll/datarammer;
• Analyser ventetid og jitter ved å overvåke VoIP-pakker;
• Analyser latens ved å overvåke nettverksinteraksjoner;
• Oppdag avvik ved å overvåke nettverkstrafikk.
SPAN-trafikk kan speiles lokalt til andre porter på samme kildeenhet, eller eksternspeiles til andre nettverksenheter ved siden av lag 2 på kildeenheten (RSPAN).
I dag skal vi snakke om ekstern Internett-trafikkovervåkingsteknologi kalt ERSPAN (Encapsulated Remote Switch Port Analyzer) som kan overføres over tre lag med IP. Dette er en utvidelse av SPAN til Encapsulated Remote.
Grunnleggende driftsprinsipper for ERSPAN
Først, la oss ta en titt på ERSPANs funksjoner:
• En kopi av pakken fra kildeporten sendes til målserveren for parsing gjennom Generic Routing Encapsulation (GRE). Den fysiske plasseringen av serveren er ikke begrenset.
• Ved hjelp av funksjonen User Defined Field (UDF) til brikken, utføres enhver offset på 1 til 126 byte basert på Base-domenet gjennom den utvidede listen på ekspertnivå, og øktsøkeordene matches for å realisere visualiseringen av økten, slik som TCP treveis håndtrykk og RDMA-økt;
• Støtte innstilling av samplingsfrekvens;
• Støtter pakkeavskjæringslengde (Packet Slicing), noe som reduserer trykket på målserveren.
Med disse funksjonene kan du se hvorfor ERSPAN er et viktig verktøy for å overvåke nettverk i datasentre i dag.
ERSPANs hovedfunksjoner kan oppsummeres i to aspekter:
• Sesjonssynlighet: Bruk ERSPAN til å samle alle opprettede nye TCP- og Remote Direct Memory Access-sesjoner (RDMA) til back-end-serveren for visning;
• Nettverksfeilsøking: Fanger nettverkstrafikk for feilanalyse når et nettverksproblem oppstår.
For å gjøre dette, må kildenettverksenheten filtrere ut trafikken av interesse for brukeren fra den massive datastrømmen, lage en kopi og kapsle inn hver kopiramme i en spesiell "superframe-beholder" som bærer nok tilleggsinformasjon slik at den kan rutes riktig til mottaksenheten. Aktiver dessuten mottakerenheten til å trekke ut og fullstendig gjenopprette den opprinnelige overvåkede trafikken.
Den mottakende enheten kan være en annen server som støtter dekapsulering av ERSPAN-pakker.
ERSPAN-type- og pakkeformatanalysen
ERSPAN-pakker er innkapslet ved hjelp av GRE og videresendes til enhver IP-adresserbar destinasjon over Ethernet. ERSPAN brukes for tiden hovedsakelig på IPv4-nettverk, og IPv6-støtte vil være et krav i fremtiden.
For den generelle innkapslingsstrukturen til ERSAPN er følgende en speilpakkefangst av ICMP-pakker:
ERSPAN-protokollen har utviklet seg over lang tid, og med forbedringen av dens evner har det blitt dannet flere versjoner, kalt "ERSPAN Types". Ulike typer har forskjellige rammeoverskriftsformater.
Det er definert i det første versjonsfeltet i ERSPAN-overskriften:
I tillegg indikerer Protocol Type-feltet i GRE-overskriften også den interne ERSPAN-typen. Protokolltype-feltet 0x88BE indikerer ERSPAN Type II, og 0x22EB indikerer ERSPAN Type III.
1. Type I
ERSPAN-rammen av Type I innkapsler IP og GRE direkte over overskriften til den originale speilrammen. Denne innkapslingen legger til 38 byte over den originale rammen: 14(MAC) + 20 (IP) + 4(GRE). Fordelen med dette formatet er at det har en kompakt topptekststørrelse og reduserer overføringskostnadene. Men fordi den setter GRE-flagg- og versjonsfeltene til 0, har den ingen utvidede felt og Type I er ikke mye brukt, så det er ikke nødvendig å utvide mer.
GRE-headerformatet for Type I er som følger:
2. Type II
I Type II er feltene C, R, K, S, S, Recur, Flags og Versjon i GRE-overskriften alle 0 bortsett fra S-feltet. Derfor vises feltet Sekvensnummer i GRE-overskriften til Type II. Det vil si at Type II kan sikre rekkefølgen på mottak av GRE-pakker, slik at et stort antall uordnede GRE-pakker ikke kan sorteres på grunn av en nettverksfeil.
GRE-headerformatet for Type II er som følger:
I tillegg legger ERSPAN Type II-rammeformatet til en 8-byte ERSPAN-overskrift mellom GRE-overskriften og den originale speilbildet.
ERSPAN-headerformatet for Type II er som følger:
Til slutt, umiddelbart etter den originale bilderammen, er standard 4-byte Ethernet Cyclic Redundancy Check (CRC)-kode.
Det er verdt å merke seg at i implementeringen inneholder ikke speilrammen FCS-feltet til den opprinnelige rammen, i stedet blir en ny CRC-verdi beregnet på nytt basert på hele ERSPAN. Dette betyr at mottaksenheten ikke kan verifisere CRC-korrektheten til den originale rammen, og vi kan bare anta at bare ukorrupte rammer speiles.
3. Type III
Type III introduserer en større og mer fleksibel sammensatt header for å håndtere stadig mer komplekse og mangfoldige nettverksovervåkingsscenarier, inkludert men ikke begrenset til nettverksadministrasjon, inntrengningsdeteksjon, ytelses- og forsinkelsesanalyse og mer. Disse scenene må kjenne til alle de originale parametrene til speilrammen og inkludere de som ikke er til stede i selve originalrammen.
ERSPAN Type III-kompositthodet inkluderer en obligatorisk 12-byte-header og en valgfri 8-byte-plattformspesifikk underheader.
ERSPAN-headerformatet for Type III er som følger:
Igjen, etter den originale speilrammen er en 4-byte CRC.
Som man kan se fra overskriftsformatet til Type III, i tillegg til å beholde Ver, VLAN, COS, T og Session ID-feltene på grunnlag av Type II, er mange spesialfelt lagt til, for eksempel:
• BSO: brukes til å indikere lastintegriteten til datarammer som bæres gjennom ERSPAN. 00 er en god ramme, 11 er en dårlig ramme, 01 er en kort ramme, 11 er en stor ramme;
• Tidsstempel: eksportert fra maskinvareklokken synkronisert med systemtiden. Dette 32-bits feltet støtter minst 100 mikrosekunder med tidsstempelgranularitet;
• Frame Type (P) og Frame Type (FT): førstnevnte brukes til å spesifisere om ERSPAN bærer Ethernet-protokollrammer (PDU-rammer), og sistnevnte brukes til å spesifisere om ERSPAN har Ethernet-rammer eller IP-pakker.
• HW ID: unik identifikator for ERSPAN-motoren i systemet;
• Gra (tidsstempelgranularitet): Spesifiserer granulariteten til tidsstemplet. For eksempel representerer 00B 100 mikrosekunders granularitet, 01B 100 nanosekunders granularitet, 10B IEEE 1588 granularitet, og 11B krever plattformspesifikke underoverskrifter for å oppnå høyere granularitet.
• Plattform-ID vs. plattformspesifikk informasjon: Felt for plattformspesifikk informasjon har forskjellige formater og innhold avhengig av plattform-ID-verdien.
Det skal bemerkes at de forskjellige overskriftsfeltene som støttes ovenfor kan brukes i vanlige ERSPAN-applikasjoner, til og med speilvende feilrammer eller BPDU-rammer, samtidig som den originale Trunk-pakken og VLAN-IDen opprettholdes. I tillegg kan nøkkeltidsstempelinformasjon og andre informasjonsfelt legges til hver ERSPAN-ramme under speiling.
Med ERSPANs egne funksjonshoder kan vi oppnå en mer raffinert analyse av nettverkstrafikk, og så enkelt montere den tilsvarende ACL i ERSPAN-prosessen for å matche nettverkstrafikken vi er interessert i.
ERSPAN implementerer RDMA-sesjonssynlighet
La oss ta et eksempel på bruk av ERSPAN-teknologi for å oppnå RDMA-sesjonsvisualisering i et RDMA-scenario:
RDMA: Ekstern direkte minnetilgang gjør det mulig for nettverksadapteren til server A å lese og skrive minnet til server B ved å bruke intelligente nettverkskort (inics) og svitsjer, og oppnå høy båndbredde, lav ventetid og lav ressursutnyttelse. Det er mye brukt i big data og høyytelses distribuert lagringsscenarier.
RoCEv2: RDMA over konvergert Ethernet versjon 2. RDMA-dataene er innkapslet i UDP-hodet. Destinasjonsportnummeret er 4791.
Daglig drift og vedlikehold av RDMA krever innsamling av mye data, som brukes til å samle inn daglige vannstandsreferanselinjer og unormale alarmer, samt grunnlag for å lokalisere unormale problemer. Kombinert med ERSPAN kan massive data fanges opp raskt for å oppnå mikrosekunders videresendingskvalitetsdata og protokollinteraksjonsstatus for byttebrikken. Gjennom datastatistikk og analyse kan RDMA ende-til-ende videresending kvalitetsvurdering og prediksjon oppnås.
For å oppnå RDAM-sesjonsvisualisering trenger vi ERSPAN for å matche søkeord for RDMA-interaksjonsøkter ved speiling av trafikk, og vi må bruke den utvidede ekspertlisten.
Definisjon av felt for utvidet listesamsvar på ekspertnivå:
UDF består av fem felt: UDF nøkkelord, basisfelt, offsetfelt, verdifelt og maskefelt. Begrenset av kapasiteten til maskinvareoppføringer, kan totalt åtte UDF-er brukes. En UDF kan matche maksimalt to byte.
• UDF nøkkelord: UDF1... UDF8 Inneholder åtte nøkkelord for UDF-samsvarende domene
• Grunnfelt: identifiserer startposisjonen til UDF-samsvarsfeltet. Følgende
L4_header (gjelder for RG-S6520-64CQ)
L5_header (for RG-S6510-48VS8Cq)
• Offset: indikerer forskyvningen basert på basisfeltet. Verdien varierer fra 0 til 126
• Verdifelt: samsvarende verdi. Den kan brukes sammen med maskefeltet for å konfigurere den spesifikke verdien som skal matches. Den gyldige biten er to byte
• Maskefelt: maske, gyldig bit er to byte
(Legg til: Hvis flere oppføringer brukes i samme UDF-samsvarsfelt, må base- og offsetfeltene være de samme.)
De to nøkkelpakkene knyttet til RDMA-øktstatus er Congestion Notification Packet (CNP) og Negative Acknowledgment (NAK):
Førstnevnte genereres av RDMA-mottakeren etter å ha mottatt ECN-meldingen sendt av svitsjen (når eout-bufferen når terskelen), som inneholder informasjon om flyten eller QP som forårsaker overbelastning. Sistnevnte brukes til å indikere at RDMA-overføringen har en pakketapsvarmelding.
La oss se på hvordan du matcher disse to meldingene ved å bruke den utvidede listen på ekspertnivå:
eksperttilgangsliste utvidet rdma
tillat utp hvilken som helst hvilken som helst hvilken som helst eq 4791udf 1 l4_header 8 0x8100 0xFF00(Matchende RG-S6520-64CQ)
tillat utp hvilken som helst hvilken som helst hvilken som helst eq 4791udf 1 l5_header 0 0x8100 0xFF00(Matchende RG-S6510-48VS8CQ)
eksperttilgangsliste utvidet rdma
tillat utp hvilken som helst 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)
tillat utp hvilken som helst 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 siste trinn kan du visualisere RDMA-økten ved å montere ekspertutvidelseslisten i den aktuelle ERSPAN-prosessen.
Skriv inn det siste
ERSPAN er et av de uunnværlige verktøyene i dagens stadig større datasenternettverk, stadig mer kompleks nettverkstrafikk og stadig mer sofistikerte nettverksdrift og vedlikeholdskrav.
Med den økende graden av O&M-automatisering er teknologier som Netconf, RESTconf og gRPC populære blant O&M-studenter i nettverksautomatisk O&M. Å bruke gRPC som den underliggende protokollen for å sende tilbake speiltrafikk har også mange fordeler. For eksempel, basert på HTTP/2-protokollen, kan den støtte streaming-push-mekanismen under samme tilkobling. Med ProtoBuf-koding reduseres størrelsen på informasjon til det halve sammenlignet med JSON-format, noe som gjør dataoverføring raskere og mer effektiv. Tenk deg, hvis du bruker ERSPAN til å speile interesserte strømmer og deretter sende dem til analyseserveren på gRPC, vil det i stor grad forbedre muligheten og effektiviteten til nettverkets automatiske drift og vedlikehold?
Innleggstid: 10. mai 2022
