Det vanligste verktøyet for nettverksovervåking og feilsøking i dag er Switch Port Analyzer (SPAN), også kjent som portspeiling. Det lar oss overvåke nettverkstrafikk i bypass out-of-band-modus uten å forstyrre tjenester på det aktive 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 latens 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 speiles eksternt til andre nettverksenheter ved siden av lag 2 på kildeenheten (RSPAN).
I dag skal vi snakke om teknologi for fjernovervåking av internettrafikk kalt ERSPAN (Encapsulated Remote Switch Port Analyzer), som kan overføres over tre IP-lag. Dette er en utvidelse av SPAN til Encapsulated Remote.
Grunnleggende driftsprinsipper for ERSPAN
La oss først se på ERSPANs funksjoner:
• En kopi av pakken fra kildeporten sendes til målserveren for parsing gjennom Generic Routing Encapsulation (GRE). Serverens fysiske plassering er ikke begrenset.
• Ved hjelp av brikkens brukerdefinerte felt (UDF)-funksjon utføres enhver forskyvning på 1 til 126 byte basert på basedomenet gjennom den utvidede listen på ekspertnivå, og sesjonsnøkkelordene matches for å realisere visualiseringen av sesjonen, for eksempel TCP treveis håndtrykk og RDMA-sesjon;
• Støtte for innstilling av samplingsfrekvens;
• Støtter pakkeavskjæringslengde (Packet Slicing), noe som reduserer presset 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:
• Øktsynlighet: Bruk ERSPAN til å samle alle opprettede nye TCP- og RDMA-økter (Remote Direct Memory Access) til backend-serveren for visning;
• Nettverksfeilsøking: Registrerer nettverkstrafikk for feilanalyse når et nettverksproblem oppstår.
For å gjøre dette må kildenettverksenheten filtrere ut trafikken som er av interesse for brukeren fra den massive datastrømmen, lage en kopi og innkapsle hver kopiramme i en spesiell "superrammebeholder" som inneholder nok tilleggsinformasjon slik at den kan rutes riktig til mottakerenheten. Dessuten må den gjøre det mulig for mottakerenheten å trekke ut og gjenopprette den opprinnelige overvåkede trafikken fullstendig.
Mottakerenheten kan være en annen server som støtter dekapsling av ERSPAN-pakker.
ERSPAN-type- og pakkeformatanalyse
ERSPAN-pakker innkapsles ved hjelp av GRE og videresendes til en hvilken som helst 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 speilpakkeopptak av ICMP-pakker:
ERSPAN-protokollen har utviklet seg over lang tid, og med forbedringen av dens funksjoner har det blitt dannet flere versjoner, kalt «ERSPAN-typer». Ulike typer har forskjellige rammehodeformater.
Den er definert i det første Versjon-feltet i ERSPAN-headeren:
I tillegg indikerer feltet Protokolltype i GRE-headeren også den interne ERSPAN-typen. Protokolltypefeltet 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 headeren 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 headerstørrelse og reduserer overføringskostnadene. Men fordi det setter GRE-flagg- og versjonsfeltene til 0, har det ingen utvidede felt, og type I er ikke mye brukt, så det er ikke behov for å 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 Version i GRE-headeren alle 0 unntatt S-feltet. Derfor vises Sekvensnummer-feltet i GRE-headeren for Type II. Det vil si at Type II kan sikre rekkefølgen for mottak av GRE-pakker, slik at et stort antall GRE-pakker i feil rekkefølge 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-header mellom GRE-headeren og den originale speilede rammen.
ERSPAN-headerformatet for Type II er som følger:
Til slutt, rett etter den originale bilderammen, kommer standard 4-byte Ethernet-koden for syklisk redundanskontroll (CRC).
Det er verdt å merke seg at i implementeringen inneholder ikke speilrammen FCS-feltet til den opprinnelige rammen. I stedet beregnes en ny CRC-verdi på nytt basert på hele ERSPAN. Dette betyr at mottakerenheten ikke kan bekrefte CRC-korrektheten til den opprinnelige 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, inntrengingsdeteksjon, ytelses- og forsinkelsesanalyse og mer. Disse scenene må kjenne til alle de opprinnelige parameterne til speilrammen og inkludere de som ikke er tilstede i selve den opprinnelige rammen.
ERSPAN Type III-sammensatt header 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 det en 4-byte CRC.
Som det fremgår av overskriftsformatet til Type III, legges det til mange spesialfelt i tillegg til å beholde feltene Ver, VLAN, COS, T og Session ID basert på Type II, for eksempel:
• BSO: brukes til å indikere lasteintegriteten 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 lang ramme;
• Tidsstempel: eksportert fra maskinvareklokken synkronisert med systemtiden. Dette 32-bits feltet støtter minst 100 mikrosekunder med tidsstempelgranularitet;
• Rammetype (P) og rammetype (FT): førstnevnte brukes til å spesifisere om ERSPAN bærer Ethernet-protokollrammer (PDU-rammer), og sistnevnte brukes til å spesifisere om ERSPAN bærer Ethernet-rammer eller IP-pakker.
• HW-ID: unik identifikator for ERSPAN-motoren i systemet;
• Gra (Tidsstempelgranularitet): Angir granulariteten til tidsstempelet. For eksempel representerer 00B en granularitet på 100 mikrosekunder, 01B en granularitet på 100 nanosekunder, 10B en 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 bør bemerkes at de ulike headerfeltene som støttes ovenfor kan brukes i vanlige ERSPAN-applikasjoner, til og med speiling av feilrammer eller BPDU-rammer, samtidig som den opprinnelige Trunk-pakken og VLAN-ID-en opprettholdes. I tillegg kan viktig tidsstempelinformasjon og andre informasjonsfelt legges til hver ERSPAN-ramme under speiling.
Med ERSPANs egne funksjonsoverskrifter kan vi oppnå en mer raffinert analyse av nettverkstrafikk, og deretter ganske enkelt montere den tilsvarende ACL-en i ERSPAN-prosessen for å matche nettverkstrafikken vi er interessert i.
ERSPAN implementerer RDMA-øktsynlighet
La oss ta et eksempel på bruk av ERSPAN-teknologi for å oppnå visualisering av RDMA-økter i et RDMA-scenario:
RDMAFjernstyrt direkte minnetilgang lar nettverkskortet til server A lese og skrive til minnet til server B ved hjelp av intelligente nettverkskort (INIC-er) og svitsjer, noe som oppnår høy båndbredde, lav latens og lav ressursutnyttelse. Det er mye brukt i stordata- og høytytende distribuert lagringsscenarier.
RoCEv2RDMA over konvergert Ethernet versjon 2. RDMA-dataene er innkapslet i UDP-headeren. Destinasjonsportnummeret er 4791.
Daglig drift og vedlikehold av RDMA krever innsamling av mye data, som brukes til å samle inn daglige referanselinjer for vannstand og unormale alarmer, samt grunnlaget for å finne unormale problemer. Kombinert med ERSPAN kan massive data raskt samles inn for å få mikrosekunddata for videresendingskvalitet og protokollinteraksjonsstatus for svitsjebrikken. Gjennom datastatistikk og -analyse kan RDMA ende-til-ende-videresendingskvalitetsvurdering og -prediksjon oppnås.
For å oppnå visualisering av RDAM-økter trenger vi at ERSPAN matcher nøkkelord for RDMA-interaksjonsøkter når vi speiler trafikk, og vi må bruke den utvidede ekspertlisten.
Definisjon av samsvarende felt på utvidet liste på ekspertnivå:
UDF-en 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. Én UDF kan samsvare med maksimalt to byte.
• UDF-nøkkelord: UDF1... UDF8 Inneholder åtte nøkkelord fra UDF-samsvarende domene
• Basisfelt: identifiserer startposisjonen til UDF-samsvarsfeltet. Følgende
L4_header (gjelder for RG-S6520-64CQ)
L5_header (for RG-S6510-48VS8Cq)
• Offset: indikerer offset basert på basisfeltet. Verdien varierer fra 0 til 126
• Verdifelt: samsvarende verdi. Det kan brukes sammen med maskefeltet for å konfigurere den spesifikke verdien som skal samsvares. Den gyldige biten er to byte
• Maskefelt: maske, gyldig bit er to byte
(Legg til: Hvis flere oppføringer brukes i samme UDF-samsvarende felt, må basis- og offsetfeltene være de samme.)
De to nøkkelpakkene som er 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 responsmelding om pakketap.
La oss se på hvordan vi kan matche disse to meldingene ved hjelp av den utvidede listen på ekspertnivå:
utvidet rdma for eksperttilgangsliste
tillat udp hvilken som helst hvilken som helst hvilken som helst ligning 4791udf 1 l4_header 8 0x8100 0xFF00(Matchende RG-S6520-64CQ)
tillat udp hvilken som helst hvilken som helst hvilken som helst ligning 4791udf 1 l5_header 0 0x8100 0xFF00(Matchende RG-S6510-48VS8CQ)
utvidet rdma for eksperttilgangsliste
tillat udp hvilken som helst hvilken som helst hvilken som helst ligning 4791udf 1 l4_header 8 0x1100 0xFF00 udf 2 l4_header 20 0x6000 0xFF00(Matchende RG-S6520-64CQ)
tillat udp hvilken som helst hvilken som helst hvilken som helst ligning 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 i 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 krav til nettverksdrift og vedlikehold.
Med den økende graden av automatisering av drift og vedlikehold, er teknologier som Netconf, RESTconf og gRPC populære blant drift- og vedlikeholdsstudenter innen automatisk nettverksdrift og vedlikehold. Å bruke gRPC som underliggende protokoll for å sende tilbake speiltrafikk har også mange fordeler. For eksempel, basert på HTTP/2-protokollen, kan den støtte strømmemekanismen under samme tilkobling. Med ProtoBuf-koding reduseres størrelsen på informasjonen med halvparten 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 sender dem til analyseserveren på gRPC, vil det forbedre evnen og effektiviteten til automatisk nettverksdrift og vedlikehold betraktelig?
Publiseringstid: 10. mai 2022
