Det vanligaste verktyget för nätverksövervakning och felsökning idag är Switch Port Analyzer (SPAN), även känt som portspegling. Det låter oss övervaka nätverkstrafik i bypass out-of-band-läge utan att störa tjänster i det aktiva nätverket, och skickar en kopia av den övervakade trafiken till lokala eller fjärranslutna enheter, inklusive Sniffer, IDS eller andra typer av nätverksanalysverktyg.
Några typiska användningsområden är:
• Felsök nätverksproblem genom att spåra kontroll-/dataramar;
• Analysera latens och jitter genom att övervaka VoIP-paket;
• Analysera latens genom att övervaka nätverksinteraktioner;
• Upptäck avvikelser genom att övervaka nätverkstrafik.
SPAN-trafik kan speglas lokalt till andra portar på samma källenhet, eller fjärrspeglas till andra nätverksenheter intill lager 2 på källenheten (RSPAN).
Idag ska vi prata om teknik för fjärrövervakning av internettrafik som kallas ERSPAN (Encapsulated Remote Switch Port Analyzer) och som kan överföras över tre IP-lager. Detta är en utökning av SPAN till Encapsulated Remote.
Grundläggande driftsprinciper för ERSPAN
Låt oss först titta på ERSPANs funktioner:
• En kopia av paketet från källporten skickas till destinationsservern för parsning via Generic Routing Encapsulation (GRE). Serverns fysiska plats är inte begränsad.
• Med hjälp av chipets UDF-funktion (User Defined Field) utförs en förskjutning på 1 till 126 byte baserat på basdomänen via den utökade listan på expertnivå, och sessionsnyckelorden matchas för att visualisera sessionen, såsom TCP trevägshandskakning och RDMA-session;
• Stöd för inställning av samplingsfrekvens;
• Stöder paketavlyssningslängd (Packet Slicing), vilket minskar belastningen på målservern.
Med dessa funktioner kan du förstå varför ERSPAN är ett viktigt verktyg för att övervaka nätverk i datacenter idag.
ERSPANs huvudfunktioner kan sammanfattas i två aspekter:
• Sessionssynlighet: Använd ERSPAN för att samla in alla skapade nya TCP- och RDMA-sessioner (Remote Direct Memory Access) till backend-servern för visning;
• Felsökning av nätverk: Samlar in nätverkstrafik för felanalys när ett nätverksproblem uppstår.
För att göra detta måste källnätverksenheten filtrera bort trafiken som är av intresse för användaren från den massiva dataströmmen, göra en kopia och inkapsla varje kopierad bildruta i en speciell "superframe-behållare" som innehåller tillräckligt med ytterligare information så att den kan dirigeras korrekt till den mottagande enheten. Dessutom måste den mottagande enheten kunna extrahera och helt återställa den ursprungliga övervakade trafiken.
Mottagarenheten kan vara en annan server som stöder dekapsling av ERSPAN-paket.
ERSPAN-typ- och paketformatanalys
ERSPAN-paket inkapslas med GRE och vidarebefordras till valfri IP-adresserbar destination via Ethernet. ERSPAN används för närvarande huvudsakligen i IPv4-nätverk, och IPv6-stöd kommer att vara ett krav i framtiden.
För den allmänna inkapslingsstrukturen för ERSAPN är följande en spegelbild av ICMP-paket:
ERSPAN-protokollet har utvecklats under en lång tid, och i takt med att dess funktioner har förbättrats har flera versioner bildats, kallade "ERSPAN-typer". Olika typer har olika format för ramhuvuden.
Det definieras i det första Version-fältet i ERSPAN-rubriken:
Dessutom anger fältet Protokolltyp i GRE-rubriken även den interna ERSPAN-typen. Fältet Protokolltyp 0x88BE anger ERSPAN-typ II och 0x22EB anger ERSPAN-typ III.
1. Typ I
ERSPAN-ramen av typ I inkapslar IP och GRE direkt över headern i den ursprungliga spegelramen. Denna inkapsling lägger till 38 byte över den ursprungliga ramen: 14(MAC) + 20 (IP) + 4(GRE). Fördelen med detta format är att det har en kompakt headerstorlek och minskar överföringskostnaden. Men eftersom det sätter GRE-flaggan och versionsfälten till 0, innehåller det inga utökade fält och typ I används inte i stor utsträckning, så det finns inget behov av att expandera mer.
GRE-headerformatet för typ I är följande:
2. Typ II
I typ II är fälten C, R, K, S, S, Recur, Flags och Version i GRE-rubriken alla 0 förutom S-fältet. Därför visas fältet Sekvensnummer i GRE-rubriken för typ II. Det vill säga, typ II kan säkerställa ordningen för mottagande av GRE-paket, så att ett stort antal GRE-paket i fel ordning inte kan sorteras på grund av ett nätverksfel.
GRE-headerformatet för typ II är följande:
Dessutom lägger ERSPAN Type II-ramformatet till en 8-byte ERSPAN-rubrik mellan GRE-rubriken och den ursprungliga speglade ramen.
ERSPAN-rubrikformatet för typ II är följande:
Slutligen, omedelbart efter den ursprungliga bildrutan, kommer standard 4-byte Ethernet-kod för cyklisk redundanskontroll (CRC).
Det är värt att notera att i implementeringen innehåller inte den speglade ramen FCS-fältet från den ursprungliga ramen, istället beräknas ett nytt CRC-värde om baserat på hela ERSPAN. Detta innebär att den mottagande enheten inte kan verifiera CRC-korrektheten för den ursprungliga ramen, och vi kan bara anta att endast oskadade ramar speglas.
3. Typ III
Typ III introducerar en större och mer flexibel sammansatt header för att hantera alltmer komplexa och varierande nätverksövervakningsscenarier, inklusive men inte begränsat till nätverkshantering, intrångsdetektering, prestanda- och fördröjningsanalys med mera. Dessa scener behöver känna till alla originalparametrar för spegelbilden och inkludera de som inte finns i själva originalbilden.
ERSPAN Type III-sammansatta rubriken innehåller en obligatorisk 12-byte-rubrik och en valfri 8-byte plattformsspecifik underrubrik.
ERSPAN-rubrikformatet för typ III är följande:
Återigen, efter den ursprungliga spegelramen finns en 4-byte CRC.
Som framgår av rubrikformatet för typ III, läggs många specialfält till, förutom att behålla fälten Ver, VLAN, COS, T och Session ID baserat på typ II, såsom:
• BSO: används för att indikera laddningsintegriteten för dataramar som transporteras genom ERSPAN. 00 är en bra ram, 11 är en dålig ram, 01 är en kort ram, 11 är en stor ram;
• Tidsstämpel: exporteras från hårdvaruklockan synkroniserad med systemtiden. Detta 32-bitarsfält stöder minst 100 mikrosekunders granularitet för tidsstämpeln;
• Ramtyp (P) och ramtyp (FT): den förra används för att ange om ERSPAN bär Ethernet-protokollramar (PDU-ramar), och den senare används för att ange om ERSPAN bär Ethernet-ramar eller IP-paket.
• HW-ID: unik identifierare för ERSPAN-motorn i systemet;
• Gra (Tidsstämpelns granularitet): Anger tidsstämpelns granularitet. Till exempel representerar 00B en granularitet på 100 mikrosekunder, 01B en granularitet på 100 nanosekunder, 10B en IEEE 1588-granularitet och 11B kräver plattformsspecifika underrubriker för att uppnå högre granularitet.
• Plattforms-ID kontra plattformsspecifik information: Fält för plattformsspecifik information har olika format och innehåll beroende på plattforms-ID-värdet.
Det bör noteras att de olika headerfälten som stöds ovan kan användas i vanliga ERSPAN-applikationer, även vid spegling av felramar eller BPDU-ramar, samtidigt som det ursprungliga Trunk-paketet och VLAN-ID:t bibehålls. Dessutom kan viktig tidsstämpelinformation och andra informationsfält läggas till i varje ERSPAN-ram under speglingen.
Med ERSPANs egna funktionsrubriker kan vi uppnå en mer förfinad analys av nätverkstrafik och sedan helt enkelt montera motsvarande ACL i ERSPAN-processen för att matcha den nätverkstrafik vi är intresserade av.
ERSPAN implementerar RDMA-sessionssynlighet
Låt oss ta ett exempel på hur man använder ERSPAN-teknik för att visualisera RDMA-sessioner i ett RDMA-scenario:
RDMAFjärrstyrd direktminnesåtkomst gör det möjligt för nätverkskortet på server A att läsa och skriva till minnet på server B med hjälp av intelligenta nätverkskort (INIC) och switchar, vilket uppnår hög bandbredd, låg latens och låg resursanvändning. Det används ofta i stordata- och högpresterande distribuerad lagring.
RoCEv2RDMA över konvergerad Ethernet version 2. RDMA-data är inkapslad i UDP-headern. Destinationsportnumret är 4791.
Daglig drift och underhåll av RDMA kräver insamling av mycket data, vilket används för att samla in dagliga referenslinjer för vattennivåer och onormala larm, samt som grund för att lokalisera onormala problem. Kombinerat med ERSPAN kan massiva data snabbt samlas in för att erhålla mikrosekunddata för vidarebefordringskvalitet och protokollinteraktionsstatus för switchchipet. Genom datastatistik och analys kan RDMA-end-till-end-vidarebefordringskvalitetsbedömning och förutsägelser erhållas.
För att uppnå visualisering av RDAM-sessioner behöver vi att ERSPAN matchar nyckelord för RDMA-interaktionssessioner vid spegling av trafik, och vi behöver använda den utökade expertlistan.
Definition av matchningsfält för utökad lista på expertnivå:
UDF:n består av fem fält: UDF-nyckelord, basfält, offsetfält, värdefält och maskfält. Begränsat av kapaciteten för hårdvaruposter kan totalt åtta UDF:er användas. En UDF kan matcha maximalt två byte.
• UDF-nyckelord: UDF1... UDF8 Innehåller åtta nyckelord från UDF-matchningsdomänen
• Basfält: identifierar startpositionen för UDF-matchningsfältet. Följande
L4_header (gäller RG-S6520-64CQ)
L5_header (för RG-S6510-48VS8Cq)
• Offset: anger offseten baserat på basfältet. Värdet varierar från 0 till 126
• Värdefält: matchande värde. Det kan användas tillsammans med maskfältet för att konfigurera det specifika värde som ska matchas. Den giltiga biten är två byte
• Maskfält: mask, giltig bit är två byte
(Lägg till: Om flera poster används i samma UDF-matchningsfält måste bas- och offsetfälten vara desamma.)
De två viktigaste paketen som är associerade med RDMA-sessionsstatus är Congestion Notification Packet (CNP) och Negative Acknowledgment (NAK):
Det förra genereras av RDMA-mottagaren efter att ha mottagit ECN-meddelandet som skickats av switchen (när eout-bufferten når tröskelvärdet), vilket innehåller information om flödet eller QP som orsakar överbelastning. Det senare används för att indikera att RDMA-överföringen har ett svarsmeddelande om paketförlust.
Låt oss titta på hur man matchar dessa två meddelanden med hjälp av den utökade listan på expertnivå:
expertåtkomstlista utökad rdma
tillåt udp vilken som helst vilken som helst vilken som helst ekvation 4791udf 1 l4_header 8 0x8100 0xFF00(Matchande RG-S6520-64CQ)
tillåt udp vilken som helst vilken som helst vilken som helst ekvation 4791udf 1 l5_header 0 0x8100 0xFF00(Matchande RG-S6510-48VS8CQ)
expertåtkomstlista utökad rdma
tillåt udp vilken som helst vilken som helst vilken som helst ekvation 4791udf 1 l4_header 8 0x1100 0xFF00 udf 2 l4_header 20 0x6000 0xFF00(Matchande RG-S6520-64CQ)
tillåt udp vilken som helst vilken som helst vilken som helst ekvation 4791udf 1 l5_header 0 0x1100 0xFF00 udf 2 l5_header 12 0x6000 0xFF00(Matchande RG-S6510-48VS8CQ)
Som ett sista steg kan du visualisera RDMA-sessionen genom att montera experttilläggslistan i lämplig ERSPAN-process.
Skriv i det sista
ERSPAN är ett av de oumbärliga verktygen i dagens allt större datacenternätverk, alltmer komplexa nätverkstrafik och alltmer sofistikerade krav på nätverksdrift och underhåll.
Med den ökande graden av O&M-automation är tekniker som Netconf, RESTconf och gRPC populära bland O&M-studenter inom automatisk nätverksdrift och underhåll. Att använda gRPC som underliggande protokoll för att skicka tillbaka speglande trafik har också många fördelar. Till exempel, baserat på HTTP/2-protokollet, kan det stödja strömningsmekanismen under samma anslutning. Med ProtoBuf-kodning minskas informationsstorleken med hälften jämfört med JSON-formatet, vilket gör dataöverföringen snabbare och effektivare. Tänk dig bara, om du använder ERSPAN för att spegla intresserade strömmar och sedan skickar dem till analysservern på gRPC, kommer det att förbättra förmågan och effektiviteten hos automatisk nätverksdrift och underhåll avsevärt?
Publiceringstid: 10 maj 2022
