De meest gebruikte tool voor netwerkmonitoring en probleemoplossing is tegenwoordig Switch Port Analyzer (SPAN), ook wel bekend als port mirroring. Hiermee kunnen we netwerkverkeer monitoren in een bypass-out-of-band-modus zonder de services op het actieve netwerk te verstoren, en een kopie van het gemonitorde verkeer verzenden naar lokale of externe apparaten, waaronder sniffers, IDS of andere netwerkanalysetools.
Enkele typische toepassingen zijn:
• Problemen met het netwerk oplossen door controle-/dataframes te traceren;
• Analyseer latentie en jitter door VoIP-pakketten te monitoren;
• Analyseer de latentie door netwerkinteracties te monitoren;
• Anomalieën opsporen door netwerkverkeer te monitoren.
SPAN-verkeer kan lokaal worden gespiegeld naar andere poorten op hetzelfde bronapparaat, of op afstand worden gespiegeld naar andere netwerkapparaten die zich op laag 2 van het bronapparaat bevinden (RSPAN).
Vandaag gaan we het hebben over een technologie voor het monitoren van internetverkeer op afstand, genaamd ERSPAN (Encapsulated Remote Switch Port Analyzer), die gegevens over drie IP-lagen kan verzenden. Dit is een uitbreiding van SPAN naar Encapsulated Remote.
Basiswerkingsprincipes van ERSPAN
Laten we eerst eens kijken naar de functies van ERSPAN:
• Een kopie van het pakket van de bronpoort wordt naar de doelserver gestuurd voor verwerking via Generic Routing Encapsulation (GRE). De fysieke locatie van de server is niet beperkt.
• Met behulp van de User Defined Field (UDF)-functie van de chip wordt elke offset van 1 tot 126 bytes uitgevoerd op basis van het basisdomein via de uitgebreide lijst op expertniveau, en worden de sessietrefwoorden vergeleken om de visualisatie van de sessie te realiseren, zoals de TCP-drieweghandshake en de RDMA-sessie;
• Ondersteuning bij het instellen van de bemonsteringsfrequentie;
• Ondersteunt het onderscheppen van pakketten over een bepaalde lengte (Packet Slicing), waardoor de belasting van de doelserver wordt verminderd.
Met deze functies is het duidelijk waarom ERSPAN tegenwoordig een essentieel hulpmiddel is voor het bewaken van netwerken in datacenters.
De belangrijkste functies van ERSPAN kunnen in twee aspecten worden samengevat:
• Sessiezichtbaarheid: Gebruik ERSPAN om alle nieuwe TCP- en Remote Direct Memory Access (RDMA)-sessies naar de back-endserver te verzamelen en weer te geven;
• Netwerkprobleemoplossing: Legt netwerkverkeer vast voor foutanalyse wanneer er een netwerkprobleem optreedt.
Om dit te doen, moet het bronnetwerkapparaat het voor de gebruiker relevante verkeer uit de enorme datastroom filteren, een kopie maken en elk kopieframe inkapselen in een speciale "superframe-container" die voldoende aanvullende informatie bevat om correct naar het ontvangende apparaat te kunnen worden gerouteerd. Bovendien moet het ontvangende apparaat in staat zijn om het oorspronkelijke, gemonitorde verkeer te extraheren en volledig te herstellen.
Het ontvangende apparaat kan een andere server zijn die het uitpakken van ERSPAN-pakketten ondersteunt.
De ERSPAN-type- en pakketformaatanalyse
ERSPAN-pakketten worden ingekapseld met GRE en via Ethernet doorgestuurd naar elke bestemming met een IP-adres. ERSPAN wordt momenteel voornamelijk gebruikt op IPv4-netwerken, maar ondersteuning voor IPv6 zal in de toekomst een vereiste zijn.
Voor de algemene inkapselingsstructuur van ERSAPN is hieronder een voorbeeld van een gespiegelde pakketvastlegging van ICMP-pakketten weergegeven:
Het ERSPAN-protocol is in de loop der tijd ontwikkeld en met de verbetering van de mogelijkheden zijn er verschillende versies ontstaan, de zogenaamde "ERSPAN-typen". De verschillende typen hebben verschillende frameheaderformaten.
Het is gedefinieerd in het eerste veld 'Version' van de ERSPAN-header:
Daarnaast geeft het veld Protocol Type in de GRE-header ook het interne ERSPAN-type aan. Het veld Protocol Type 0x88BE duidt op ERSPAN Type II, en 0x22EB op ERSPAN Type III.
1. Type I
Het ERSPAN-frame van type I encapsuleert IP en GRE direct over de header van het originele spiegelframe. Deze encapsulatie voegt 38 bytes toe aan het originele frame: 14 (MAC) + 20 (IP) + 4 (GRE). Het voordeel van dit formaat is de compacte headergrootte en de lagere transmissiekosten. Omdat de velden GRE Flag en Version echter op 0 worden gezet, bevat het geen extra velden. Type I wordt niet veel gebruikt, waardoor verdere uitbreiding niet nodig is.
Het GRE-headerformaat van type I is als volgt:
2. Type II
Bij Type II zijn de velden C, R, K, S, S, Recur, Flags en Version in de GRE-header allemaal 0, behalve het veld S. Daarom wordt het veld Sequence Number weergegeven in de GRE-header van Type II. Dat wil zeggen dat Type II de volgorde van ontvangst van GRE-pakketten kan garanderen, zodat een groot aantal GRE-pakketten die niet in de juiste volgorde aankomen, niet gesorteerd kan worden vanwege een netwerkfout.
Het GRE-headerformaat van type II is als volgt:
Daarnaast voegt het ERSPAN Type II frameformaat een 8-byte ERSPAN-header toe tussen de GRE-header en het oorspronkelijke gespiegelde frame.
Het ERSPAN-headerformaat voor Type II is als volgt:
Ten slotte, direct na het oorspronkelijke beeldframe, bevindt zich de standaard 4-byte Ethernet CRC-code (Cyclic Redundancy Check).
Het is belangrijk op te merken dat in de implementatie het spiegelbeeldframe het FCS-veld van het originele frame niet bevat. In plaats daarvan wordt een nieuwe CRC-waarde berekend op basis van de volledige ERSPAN. Dit betekent dat het ontvangende apparaat de correctheid van de CRC van het originele frame niet kan verifiëren en dat we er dus alleen van uit kunnen gaan dat alleen onbeschadigde frames worden gespiegeld.
3. Type III
Type III introduceert een grotere en flexibelere samengestelde header om steeds complexere en diversere netwerkmonitoringsscenario's aan te pakken, waaronder, maar niet beperkt tot, netwerkbeheer, inbraakdetectie, prestatie- en vertragingsanalyse en meer. Deze scenario's moeten alle oorspronkelijke parameters van het spiegelbeeld kennen, inclusief parameters die niet in het originele beeld zelf aanwezig zijn.
De ERSPAN Type III samengestelde header bevat een verplichte header van 12 bytes en een optionele platformspecifieke subheader van 8 bytes.
Het ERSPAN-headerformaat voor Type III is als volgt:
Na het oorspronkelijke spiegelbeeld volgt opnieuw een CRC van 4 bytes.
Zoals blijkt uit de headerindeling van Type III, zijn naast de velden Ver, VLAN, COS, T en Session ID, die op basis van Type II behouden zijn gebleven, veel speciale velden toegevoegd, zoals:
• BSO: wordt gebruikt om de laadintegriteit aan te geven van dataframes die via ERSPAN worden verzonden. 00 is een goed frame, 11 is een slecht frame, 01 is een kort frame, 11 is een lang frame;
• Tijdstempel: geëxporteerd vanuit de hardwareklok, gesynchroniseerd met de systeemtijd. Dit 32-bits veld ondersteunt een tijdstempelgranulariteit van ten minste 100 microseconden;
• Frametype (P) en Frametype (FT): het eerste wordt gebruikt om aan te geven of ERSPAN Ethernet-protocolframes (PDU-frames) transporteert, en het tweede wordt gebruikt om aan te geven of ERSPAN Ethernet-frames of IP-pakketten transporteert.
• HW ID: unieke identificatiecode van de ERSPAN-engine binnen het systeem;
• Gra (Timestamp Granularity): Specificeert de granulariteit van de tijdstempel. Bijvoorbeeld, 00B staat voor een granulariteit van 100 microseconden, 01B voor 100 nanoseconden, 10B voor IEEE 1588-granulariteit en 11B vereist platformspecifieke subheaders om een hogere granulariteit te bereiken.
• Platform-ID versus platformspecifieke informatie: Platformspecifieke informatievelden hebben verschillende formaten en inhoud, afhankelijk van de waarde van de platform-ID.
Het is belangrijk op te merken dat de verschillende header-velden die hierboven worden ondersteund, kunnen worden gebruikt in reguliere ERSPAN-toepassingen, zelfs bij het spiegelen van foutframes of BPDU-frames, met behoud van het oorspronkelijke Trunk-pakket en de VLAN-ID. Bovendien kunnen belangrijke tijdstempelgegevens en andere informatievelden aan elk ERSPAN-frame worden toegevoegd tijdens het spiegelen.
Met de eigen feature headers van ERSPAN kunnen we een meer verfijnde analyse van netwerkverkeer uitvoeren en vervolgens eenvoudig de bijbehorende ACL in het ERSPAN-proces koppelen aan het netwerkverkeer waarin we geïnteresseerd zijn.
ERSPAN implementeert RDMA-sessiezichtbaarheid
Laten we een voorbeeld bekijken van het gebruik van ERSPAN-technologie om RDMA-sessievisualisatie in een RDMA-scenario te realiseren:
RDMARemote Direct Memory Access (RDMA) maakt het mogelijk dat de netwerkadapter van server A het geheugen van server B kan lezen en schrijven met behulp van intelligente netwerkinterfacekaarten (NIC's) en switches. Dit resulteert in een hoge bandbreedte, lage latentie en een laag resourcegebruik. Het wordt veel gebruikt in big data- en high-performance gedistribueerde opslagscenario's.
RoCEv2RDMA over Converged Ethernet versie 2. De RDMA-gegevens zijn ingekapseld in de UDP-header. Het bestemmingspoortnummer is 4791.
De dagelijkse werking en het onderhoud van RDMA vereisen het verzamelen van grote hoeveelheden data. Deze data worden gebruikt voor het vastleggen van dagelijkse referentiewaarden voor het waterpeil en alarmmeldingen bij afwijkingen, en vormen de basis voor het lokaliseren van problemen. In combinatie met ERSPAN kan een enorme hoeveelheid data snel worden vastgelegd om gegevens over de doorstuurkwaliteit en de protocolinteractiestatus van de switchchip met een nauwkeurigheid van microseconden te verkrijgen. Door middel van datastatistiek en -analyse kan de end-to-end doorstuurkwaliteit van RDMA worden beoordeeld en voorspeld.
Om RDAM-sessies te visualiseren, moet ERSPAN trefwoorden matchen voor RDMA-interactiesessies bij het spiegelen van verkeer, en moeten we de uitgebreide expertlijst gebruiken.
Definitie van een veld voor het matchen van uitgebreide lijsten op expertniveau:
Een UDF bestaat uit vijf velden: UDF-trefwoord, basisveld, offsetveld, waardeveld en maskerveld. Beperkt door de capaciteit van de hardware-ingangen kunnen er in totaal acht UDF's worden gebruikt. Eén UDF kan maximaal twee bytes matchen.
• UDF-trefwoord: UDF1... UDF8 Bevat acht trefwoorden van het UDF-matchingdomein
• Basisveld: identificeert de startpositie van het UDF-matchingveld. Het volgende
L4_header (van toepassing op RG-S6520-64CQ)
L5_header (voor RG-S6510-48VS8Cq)
• Offset: geeft de offset aan ten opzichte van het basisveld. De waarde varieert van 0 tot 126.
• Waardeveld: overeenkomende waarde. Het kan samen met het maskerveld worden gebruikt om de specifieke waarde te configureren waarmee moet worden vergeleken. De geldigheidsbit is twee bytes.
• Maskerveld: masker, geldige bits zijn twee bytes
(Toevoeging: Als meerdere waarden in hetzelfde UDF-matchingveld worden gebruikt, moeten de basis- en offsetvelden hetzelfde zijn.)
De twee belangrijkste pakketten die verband houden met de RDMA-sessiestatus zijn het Congestion Notification Packet (CNP) en het Negative Acknowledgment (NAK):
De eerste wordt gegenereerd door de RDMA-ontvanger na ontvangst van het ECN-bericht dat door de switch is verzonden (wanneer de eout-buffer de drempelwaarde bereikt), dat informatie bevat over de stroom of QP die congestie veroorzaakt. De tweede wordt gebruikt om aan te geven dat de RDMA-transmissie een pakketverlies-responsbericht heeft.
Laten we eens kijken hoe we deze twee berichten kunnen matchen met behulp van de uitgebreide lijst op expertniveau:
expert access-list extended rdma
permit udp any any any any eq 4791udf 1 l4_header 8 0x8100 0xFF00(Overeenkomend met RG-S6520-64CQ)
permit udp any any any any eq 4791udf 1 l5_header 0 0x8100 0xFF00(Overeenkomend met RG-S6510-48VS8CQ)
expert access-list extended rdma
permit udp any any any any eq 4791udf 1 l4_header 8 0x1100 0xFF00 udf 2 l4_header 20 0x6000 0xFF00(Overeenkomend met RG-S6520-64CQ)
permit udp any any any any eq 4791udf 1 l5_header 0 0x1100 0xFF00 udf 2 l5_header 12 0x6000 0xFF00(Overeenkomend met RG-S6510-48VS8CQ)
Als laatste stap kunt u de RDMA-sessie visualiseren door de expert-extensielijst in het juiste ERSPAN-proces te koppelen.
Schrijf in het laatste
ERSPAN is een van de onmisbare tools in de steeds groter wordende datacenternetwerken van vandaag, met steeds complexer wordend netwerkverkeer en steeds geavanceerdere eisen op het gebied van netwerkbeheer en -onderhoud.
Met de toenemende automatisering van beheer en onderhoud (O&M) zijn technologieën zoals Netconf, RESTconf en gRPC populair onder O&M-studenten. Het gebruik van gRPC als onderliggend protocol voor het terugsturen van gespiegeld verkeer biedt ook veel voordelen. Zo kan het, gebaseerd op het HTTP/2-protocol, het streaming push-mechanisme ondersteunen via dezelfde verbinding. Dankzij ProtoBuf-codering wordt de informatiegrootte gehalveerd ten opzichte van JSON-formaat, waardoor gegevensoverdracht sneller en efficiënter verloopt. Stel je voor: als je ERSPAN gebruikt om relevante streams te spiegelen en deze vervolgens via gRPC naar de analyseserver te sturen, zou dat de mogelijkheden en efficiëntie van geautomatiseerd beheer en onderhoud niet aanzienlijk verbeteren?
Geplaatst op: 10 mei 2022
