Problemen met IPv4-fragmentatie, MTU, MSS en PMTUD oplossen met GRE en IPsec

Inleiding

Dit document beschrijft hoe IPv4-fragmentatie en Path Maximum Transmission Unit Discovery (PMTUD) werken. 

Achtergrondinformatie

Ook worden scenario’s besproken die het gedrag van PMTUD betrekken in combinatie met verschillende combinaties van IPv4-tunnels.

IPv4-fragmentatie en opnieuw samenstellen van datagrammen

Hoewel de maximale lengte van een IPv4-datagram 65535 is, dwingen de meeste transmissielinks een lagere limiet voor maximale pakketlengte af: de MTU. De MTU-waarde is afhankelijk van de transmissiekoppeling.

Het ontwerp van IPv4 biedt ruimte voor MTU-verschillen omdat het routers in staat stelt IPv4-datagrammen te fragmenteren als dat nodig is.

Het ontvangststation (in dit verband) is verantwoordelijk voor de hermontage van de fragmenten in het originele, volledige IPv4-datagram.

IPv4-fragmentatie breekt een datagram in stukken die later opnieuw worden samengesteld.

De IPv4 bron, bestemming, identificatie, totale lengte en fragment offset velden, samen met "meer fragmenten" (MF) en "niet fragmenteren" (DF) vlaggen in de IPv4 header, worden gebruikt voor IPv4 fragmentatie en hermontage.

Zie RFC 791 voor meer informatie over de technische achtergrond van IPv4-fragmentatie en het opnieuw samenstellen van het datagram.

Deze afbeelding toont de indeling van een IPv4-header.

De identificatie is 16 bits en is een waarde die wordt toegewezen door de afzender van een IPv4-datagram. Dit helpt bij het opnieuw samenstellen van de fragmenten van een datagram.

De fragment-offset is 13 bits en geeft aan waar een fragment hoort in het oorspronkelijke IPv4-datagram. Deze waarde is een veelvoud van 8 bytes.

Er zijn 3 bits voor besturingsvlaggen in het vlagveld van de IPv4-header. De "do not fragment" (DF) bit bepaalt of een pakket al dan niet gefragmenteerd mag worden.

Bit 0 is gereserveerd en is altijd ingesteld op 0.

Bit 1 is het DF-bit (0 = "kan fragmenteren", 1 = "niet fragmenteren").

Bit 2 is de MF-bit (0 = ‘laatste fragment’, 1 = ‘meer fragmenten’).

Als de lengte van de IPv4-fragmenten wordt toegevoegd, overschrijdt de waarde de oorspronkelijke IPv4-datagramlengte met 60.

Dat komt doordat de totale lengte met 60 bytes is toegenomen omdat drie aanvullende IPv4-headers zijn gemaakt: één voor elk fragment na het eerste fragment.

Het eerste fragment heeft een offset van 0, de lengte van dit fragment is 1500; dit omvat 20 bytes voor de enigszins gewijzigde originele IPv4-header.

Het tweede fragment heeft een offset van 185 (185 x 8 = 1480); het gegevensgedeelte van dit fragment begint 1480 bytes in het oorspronkelijke IPv4-datagram.

De lengte van dit fragment is 1500; dit omvat de extra IPv4-header die voor dit fragment is gemaakt.

Het derde fragment heeft een offset van 370 (370 x 8 = 2960); het gegevensgedeelte van dit fragment begint 2960 bytes in het oorspronkelijke IPv4-datagram.

De lengte van dit fragment is 1500; dit omvat de extra IPv4-header die voor dit fragment is gemaakt.

Het vierde fragment heeft een offset van 555 (555 x 8 = 4440). Het datagedeelte van dit fragment begint dus na 4440 bytes in het oorspronkelijke IPv4-datagram.

De lengte van dit fragment is 700 bytes; dit omvat de extra IPv4-header die voor dit fragment is gemaakt.

De grootte van het oorspronkelijke IPv4-datagram kan pas worden bepaald wanneer het laatste fragment is ontvangen.

De fragment-offset in het laatste fragment (555) levert een data-offset op van 4440 bytes in het oorspronkelijke IPv4-datagram.

De som van de data bytes van het laatste fragment (680 = 700 - 20) levert 5120 bytes op, wat het datagedeelte is van het oorspronkelijke IPv4-datagram.

De toevoeging van 20 bytes voor een IPv4-header is gelijk aan de grootte van het oorspronkelijke IPv4-datagram (4440 + 680 + 20 = 5140) zoals weergegeven in de afbeeldingen.

Problemen met IPv4-fragmentatie

IPv4-fragmentatie resulteert in een kleine toename van CPU- en geheugenoverhead om een IPv4-datagram te fragmenteren. Dit geldt voor de zender en voor een router in het pad tussen een zender en een ontvanger.

Het maken van fragmenten omvat het maken van fragmentkoppen en kopieert het originele datagram in de fragmenten.

Dit gebeurt efficiënt omdat de informatie die nodig is om de fragmenten te maken onmiddellijk beschikbaar is.

Fragmentatie leidt tot meer overhead voor de ontvanger bij het opnieuw samenstellen van het datagram aan de hand van de fragmenten, omdat de ontvanger geheugen moet toewijzen voor de gestuurde fragmenten en deze weer tot één datagram moet samenstellen nadat alle fragmenten zijn ontvangen.

De hermontage op een host wordt niet als een probleem beschouwd omdat de host de tijd en geheugenbronnen heeft om aan deze taak te besteden.

De hermontage is echter inefficiënt op een router waarvan de primaire taak is om pakketten zo snel mogelijk door te sturen.

Een router is niet ontworpen om pakketten gedurende enige tijd vast te houden.

Een router die de hermontage doet, kiest de grootste buffer die beschikbaar is (18K), omdat deze geen manier heeft om de grootte van het oorspronkelijke IPv4-pakket te bepalen totdat het laatste fragment is ontvangen.

Een ander fragmentatieprobleem heeft te maken met hoe er met afgewezen fragmenten wordt omgegaan.

Als een fragment van een IPv4-datagram wordt weggelaten, moet het volledige originele IPv4-datagram aanwezig zijn en is het ook gefragmenteerd.

Dit wordt ook wel Network File System (NFS) genoemd. NFS heeft een blokgrootte van 8192. 

Daarom is een NFS IPv4/UDP-datagram ongeveer 8500 bytes (inclusief NFS-, UDP- en IPv4-headers).

Een verzendstation dat is aangesloten op een Ethernet-verbinding (MTU 1500) moet het 8500-byte-datagram fragmenteren in zes (6) delen; vijf (5) 1500 byte-fragmenten en één (1) 1100 byte-fragment.

Als een van de zes fragmenten wordt weggelaten vanwege een overbelaste link, moet het volledige originele datagram opnieuw worden verzonden. Dit resulteert in nog zes fragmenten die moeten worden gemaakt.

Als deze link één op de zes pakketten laat vallen, is de kans klein dat NFS-gegevens over deze link worden overgedragen, omdat ten minste één IPv4-fragment zou worden weggelaten uit elk NFS 8500-byte origineel IPv4-datagram.

Firewalls die pakketten filteren of manipuleren op basis van Layer 4 (L4) tot en met Layer 7 (L7) informatie hebben problemen met het correct verwerken van IPv4-fragmenten.

Als de IPv4-fragmenten niet in orde zijn, blokkeert een firewall de niet-initiële fragmenten omdat ze niet de informatie bevatten die overeenkomt met het pakketfilter.

Dit betekent dat het oorspronkelijke IPv4-datagram niet opnieuw kon worden samengesteld door de ontvangende host.

Als de firewall is geconfigureerd om niet-initiële fragmenten met onvoldoende informatie toe te staan om goed overeen te komen met het filter, is een niet-initiële fragmentaanval via de firewall mogelijk.

Netwerkapparaten zoals Content Switch Engines sturen pakketjes op basis van L4 tot en met L7-informatie, en als een pakketje meerdere fragmenten omvat, heeft het toestel moeite om zijn beleid af te dwingen.

IPv4-fragmentatie vermijden: hoe TCP MSS werkt

Het Transmission Control Protocol (TCP) Maximum Segment Size (MSS) definieert de maximale hoeveelheid gegevens die een host accepteert in één TCP/IPv4-datagram.

Dit TCP/IPv4-datagram is mogelijk gefragmenteerd op de IPv4-laag. De MSS-waarde wordt alleen als optie in de TCP-header verzonden in TCP SYN-segmenten.

Elke kant van een TCP-verbinding meldt zijn MSS-waarde aan de andere kant. Over de MSS-waarde wordt niet onderhandeld tussen hosts.

De verzendende host moet de hoeveelheid data in één TCP-segment beperken tot een waarde die lager is dan of gelijk is aan de MSS-waarde die door de ontvangende host is gemeld.

Oorspronkelijk gaf de MSS-waarde aan hoe groot de buffer was (groter dan of gelijk aan 65496 bytes) die aan een ontvangend station werd toegekend om de TCP-data in één IPv4-datagram te kunnen opslaan.

MSS was het maximale gegevenssegment dat de TCP-ontvanger wilde accepteren. Dit TCP-segment kan zo groot zijn als 64K en gefragmenteerd op de IPv4-laag om te worden verzonden naar de ontvangende host.

De ontvangende host stelde het IPv4-datagram opnieuw samen voordat het volledige TCP-segment werd overgedragen aan de TCP-laag.

Hoe MSS-waarden worden ingesteld en gebruikt om de grootte van het TCP-segment en IPv4-datagram te beperken.

Voorbeeld 1 illustreert de manier waarop MSS voor het eerst werd geïmplementeerd.

Host A heeft een buffer van 16K bytes en host B van 8K bytes. De hosts verzenden en ontvangen hun MSS-waarden en passen hun MSS-waarde voor verzenden van data op elkaar af.

Host A en Host B moeten de IPv4-datagrammen fragmenteren die groter zijn dan de interface MTU, maar minder dan de MSS verzenden omdat de TCP-stack 16K of 8K-bytes aan gegevens door de stack naar IPv4 stuurt.

In het geval van host B zijn pakketten gefragmenteerd om op het token-ring-LAN te komen en opnieuw om op het ethernet-LAN te komen.

Voorbeeld 1

1. Host A stuurt zijn MSS-waarde van 16K bytes naar host B.
2. Host B ontvangt de MSS-waarde van 16K bytes afkomstig van host A.
3. Host B stelt zijn MSS-waarde voor verzenden in op 16K bytes.
4. Host B stuurt zijn MSS-waarde van 8K bytes naar host A.
5. Host A ontvangt de MSS-waarde van 8K bytes afkomstig van host B.
6. Host A stelt zijn MSS-waarde voor verzenden in op 8K bytes.

Om IPv4-fragmentatie op de eindpunten van de TCP-verbinding te voorkomen, werd de keuze van de MSS-waarde gewijzigd in de minimale buffergrootte en de MTU van de uitgaande interface (- 40).

MSS-nummers zijn 40 bytes kleiner dan MTU-nummers omdat MSS (de TCP-gegevensgrootte) niet de 20-byte IPv4-header en de 20-byte TCP-header bevat.

MSS is gebaseerd op standaardheader-groottes; de afzenderstapel moet de juiste waarden voor de IPv4-header aftrekken en de TCP-header is afhankelijk van welke TCP- of IPv4-opties worden gebruikt.

MSS werkt momenteel op een manier waarbij elke host eerst zijn uitgaande interface MTU vergelijkt met zijn eigen buffer en de laagste waarde kiest als de MSS die moet worden verzonden.

De hosts vergelijken vervolgens de ontvangen MSS-grootte met hun eigen MTU-interface en kiezen opnieuw de laagste van de twee waarden.

Voorbeeld 2 illustreert deze extra stap die de afzender heeft genomen om fragmentatie op de lokale en externe draden te voorkomen.

De MTU van de uitgaande interface wordt door elke host in aanmerking genomen voordat de hosts elkaar hun MSS-waarden sturen. Dit helpt fragmentatie te voorkomen.

Voorbeeld 2

1. Host A vergelijkt zijn MSS-buffer (16K bytes) en MTU (1500 – 40 = 1460) en gebruikt de lagere waarde (1460) als de MSS-waarde voor verzending naar host B.
2. Host B ontvangt de verzend-MSS (1460) van host A en vergelijkt deze met de waarde van de uitgaande interface MTU - 40 (4422).
3. Host B stelt de lagere waarde (1460) in als de MSS-waarde voor het verzenden van IPv4-datagrammen naar host A.
4. Host B vergelijkt zijn MSS-buffer (8K bytes) en MTU (4462 – 40 = 4422) en gebruikt 4422 als de MSS-waarde voor verzending naar host A.
5. Host A ontvangt de send MSS (4422) van host B en vergelijkt deze met de waarde van de uitgaande interface MTU -40 (1460).
6. Host A stelt de lagere waarde (1460) in als de MSS-waarde voor het verzenden van IPv4-datagrammen naar host B.

1460 is de waarde die door beide hosts wordt gekozen als de MSS-waarde voor verzenden naar elkaar. Vaak zijn de verzend-MSS-waarden hetzelfde aan elk uiteinde van een TCP-verbinding.

In voorbeeld 2 treedt fragmentatie niet op aan de eindpunten van een TCP-verbinding omdat de hosts rekening houden met beide uitgaande interface-MTU's.

Pakketten worden nog steeds gefragmenteerd in het netwerk tussen Router A en Router B als ze een link tegenkomen met een lagere MTU dan die van de uitgaande interface van beide hosts.

Wat is PMTUD

TCP MSS pakt fragmentatie aan op de twee eindpunten van een TCP-verbinding, maar behandelt geen gevallen waarin er een kleinere MTU-link in het midden tussen deze twee eindpunten is.

PMTUD werd ontwikkeld om fragmentatie op het pad tussen de endpoints te vermijden. Het wordt gebruikt om dynamisch de laagste MTU te bepalen langs het pad van een pakketbron naar de bestemming.

Opmerking: PMTUD wordt alleen ondersteund door TCP en UDP. Andere protocollen ondersteunen PMTUD niet. Als PMTUD is ingeschakeld op een host, hebben alle TCP- en UDP-pakketten van de host de DF-bit ingesteld. 

Wanneer een host een volledig MSS-datapakket verzendt met de DF-bit, verlaagt de PMTUD de MSS-waarde voor verzenden voor de verbinding als informatie wordt ontvangen dat het pakket moet worden gefragmenteerd.

Een host registreert de MTU-waarde voor een bestemming omdat deze een host (/32)-item in de routeringstabel maakt met deze MTU-waarde.

Als een router probeert een IPv4-datagram (met de DF-bit ingesteld) door te sturen naar een link met een lagere MTU dan de grootte van het pakket, laat de router het pakket vallen en retourneert een "Destination Unreach" -bericht van het Internet Control Message Protocol (ICMP) naar de IPv4-datagrambron met de code die aangeeft "Fragmentatie nodig en DF-set" (type 3, code 4).

Wanneer het bronstation het ICMP-bericht ontvangt, verlaagt het de MSS-verzending en wanneer TCP het segment opnieuw verzendt, gebruikt het de kleinere segmentgrootte.

Hier is een voorbeeld van een ICMP "fragmentation needed and DF set"-bericht dat op een router wordt weergegeven nadat de debug ip icmp opdracht is ingeschakeld:

ICMP: dst (10.10.10.10) frag. needed and DF set 
unreachable sent to 10.1.1.1

Dit diagram toont de indeling van de ICMP-header van het bericht ‘Bestemming onbereikbaar’ met de code voor ‘Fragmentatie nodig maar DF-bit ingesteld’.

Vanaf RFC 1191 moet een router die een ICMP-bericht stuurt met ‘Fragmentatie nodig maar DF-bit ingesteld’ de MTU van het netwerk van de volgende hop bevatten in de lage 16 bits van het aanvullende ICMP-headerveld dat in ICMP-specificatie RFC 792 het label ‘ongebruikt’ heeft.

Vroegere implementaties van RFC 1191 boden geen MTU-informatie voor de volgende hop. Zelfs wanneer de informatie wel werd geboden, werd deze door sommige hosts genegeerd.

In dit geval bevat RFC 1191 ook een tabel met de voorgestelde waarden waarmee de MTU tijdens PMTUD wordt verlaagd.

Het wordt gebruikt door hosts om sneller te komen tot een redelijke waarde voor het verzenden van MSS en zoals weergegeven in dit voorbeeld.

PMTUD wordt continu uitgevoerd op alle pakketten omdat het pad tussen zender en ontvanger dynamisch kan veranderen.

Telkens wanneer een afzender een ICMP-bericht "Kan niet fragmenteren" ontvangt, wordt de routeringsinformatie bijgewerkt (waar de PMTUD wordt opgeslagen).

Tijdens PMTUD kunnen twee dingen gebeuren:

1. Het pakket kan helemaal naar de ontvanger gaan zonder gefragmenteerd te zijn.

Opmerking: Om de CPU te beschermen tegen DoS-aanvallen, vernauwt een router het aantal ICMP-onbereikbare berichten dat hij zou verzenden, tot twee per seconde. Daarom, in deze context, als u een netwerkscenario hebt waarin u verwacht dat de router zou moeten reageren met meer dan twee ICMP-berichten (type = 3, code = 4) per seconde (kunnen verschillende hosts zijn), schakelt u het afknijpen van ICMP-berichten met de no ip icmp rate-limit unreachable [df] interface opdracht uit.

2. De afzender krijgt ICMP "Cannot Fragment"-berichten van hop langs het pad naar de ontvanger.

PMTUD vindt onafhankelijk plaats voor beide richtingen van een TCP-stroom.

Er zijn gevallen waarin PMTUD in één richting van een stroom een van de eindstations triggert om de verzend-MSS te verlagen en het andere eindstation de oorspronkelijke verzend-MSS behoudt omdat het nooit een IPv4-datagram heeft verzonden dat groot genoeg is om PMTUD te activeren.

Een voorbeeld hiervan is de HTTP-verbinding die wordt weergegeven in voorbeeld 3. De TCP-client verzendt kleine pakketten en de server verzendt grote pakketten.

In dit geval activeren alleen de grote pakketten van de server (meer dan 576 bytes) PMTUD.

De pakketten van de client zijn klein (minder dan 576 bytes) en activeren geen PMTUD omdat ze geen fragmentatie vereisen om de 576 MTU-link over te steken.

Voorbeeld 3

Voorbeeld 4 toont een voorbeeld van asymmetrische routering waarbij een van de paden een kleinere minimale MTU heeft dan de andere.

Asymmetrische routing vindt plaats wanneer verschillende paden worden gebruikt om data te verzenden en ontvangen tussen twee endpoints.

In dit voorbeeld triggert PMTUD de verlaging van de send MSS slechts in één richting van een TCP-stroom.

Het verkeer van de TCP-client naar de server gaat via router A en router B. Het retourverkeer van de server naar de client gaat via router D en router C.

Wanneer de TCP-server pakketten naar de client verzendt, triggert PMTUD de server om de MSS-verzending te verlagen, omdat Router D de 4092 byte-pakketten moet fragmenteren voordat deze naar Router C kan worden verzonden.

Omgekeerd ontvangt de client nooit een ICMP-bericht "Destination Unreach" met de code die aangeeft "fragmentatie vereist en DF-set" omdat Router A geen pakketten hoeft te fragmenteren wanneer deze naar de server wordt verzonden via Router B.

Voorbeeld 4

Opmerking: De opdracht ip tcp path-mtu-discovery wordt gebruikt om TCP MTU path discovery in te schakelen voor TCP-verbindingen die door routers worden geïnitieerd (bijvoorbeeld BGP en Telnet).

Problemen met PMTUD

Dit zijn dingen die PMTUD kunnen breken.

• Een router laat een pakket vallen en verzendt geen ICMP-bericht. (Ongebruikelijk)

• Een router genereert en verzendt een ICMP-bericht, maar het ICMP-bericht wordt geblokkeerd door een router of firewall tussen deze router en de afzender. (Gebruikelijk)

• Een router genereert en stuurt een ICMP-bericht, maar de afzender negeert het bericht. (Ongebruikelijk)

De eerste en laatste van de drie kogels hier zijn meestal het gevolg van een fout, maar de middelste kogel beschrijft een veel voorkomend probleem.

Degenen die ICMP-pakketfilters implementeren, hebben de neiging om alle ICMP-berichttypen te blokkeren in plaats van alleen bepaalde ICMP-berichttypen te blokkeren.

Het is mogelijk voor pakketfilter om alle ICMP-berichttypen te blokkeren, behalve die welke "onbereikbaar" of "tijdsoverschrijdend" zijn.

Het succes of falen van PMTUD hangt af van onbereikbare ICMP-berichten die doordringen tot de afzender van een TCP / IPv4-pakket.

ICMP-berichten ‘tijd verstreken’ zijn van belang voor andere IPv4-problemen.

Hier wordt een voorbeeld getoond van een dergelijk pakketfilter, geïmplementeerd op een router.

access-list 101 permit icmp any any unreachable
access-list 101 permit icmp any any time-exceeded
access-list 101 deny icmp any any
access-list 101 permit ip any any

Er zijn andere technieken die kunnen worden gebruikt om het probleem van een volledig geblokkeerde ICMP te verlichten.

• Wis het DF-bit op de router en laat fragmentatie toe. (Dit is echter geen goed idee. zie Problemen met IPv4-fragmentatie voor meer informatie).

• De waarde van de TCP MSS-optie manipuleren met de ip tcp adjust-mss <500-1460>opdracht interface.

In het volgende voorbeeld bevinden Router A en Router B zich in hetzelfde beheerdomein. Router C is ontoegankelijk en blokkeert ICMP, waardoor PMTUD niet werkt.

Een tijdelijke oplossing is om de DF-bit in beide richtingen op router B te wissen om fragmentatie toe te staan. Dit kan worden bewerkstelligd via beleidsroutering.

De syntaxis voor het wissen van de DF-bit is beschikbaar in Cisco IOS®-softwarerelease 12.1(6) en hoger.

interface serial0 
... 
ip policy route-map clear-df-bit 
route-map clear-df-bit permit 10 
	match ip address 111 
	set ip df 0 
 
access-list 111 permit tcp any any

Een andere optie is om de TCP MSS-waarde te wijzigen bij SYN-pakketten die de router passeren (beschikbaar in Cisco IOS®-versie 12.2(4)T en hoger).

Hierdoor wordt de MSS-optiewaarde in het TCP SYN-pakket verlaagd, zodat deze kleiner is dan de waarde (1460) in de ip tcp adjust-mssopdracht.

Het resultaat is dat de TCP-afzender segmenten verzendt die niet groter zijn dan deze waarde.

De IPv4-pakketgrootte is 40 bytes groter (1500) dan de MSS-waarde (1460 bytes) om de TCP-header (20 bytes) en de IPv4-header (20 bytes) te verwerken.

U kunt de MSS van TCP SYN-pakketten aanpassen met de ip tcp adjust-mss opdracht. Deze syntaxis verlaagt de MSS-waarde op TCP-segmenten tot 1460.

Deze opdracht heeft betrekking op zowel inkomend als uitgaand verkeer op interface serial0.

int s0 
ip tcp adjust-mss 1460

Problemen met IPv4-fragmentatie komen vaker voor als gevolg van bredere implementatie van IPv4-tunnels.

Tunnels veroorzaken meer fragmentatie omdat de tunnelinkapseling "overhead" toevoegt aan de grootte van een pakket.

De toevoeging van Generic Router Encapsulation (GRE) voegt bijvoorbeeld 24 bytes toe aan een pakket en na deze toename moet het pakket worden gefragmenteerd omdat het groter is dan de uitgaande MTU.

Gangbare netwerktopologieën die PMTUD vereisen

PMTUD is vereist in netwerksituaties waarbij tussenliggende links lagere MTU-waarden hebben dan de MTU van de eindlinks. Enkele gangbare redenen voor het bestaan van deze links met een lagere MTU zijn:

• Via Token Ring (of FDDI) verbonden eindhosts met een Ethernet-verbinding tussen de hosts. De MTU’s voor Token Ring (of FDDI) aan de uiteinden zijn groter dan de Ethernet-MTU in het midden.

• PPPoE (vaak gebruikt met ADSL) heeft 8 bytes nodig voor de header. Hierdoor wordt de effectieve Ethernet-MTU verlaagd tot 1492 (1500 – 8).

Tunnelprotocollen zoals GRE, IPv4sec en L2TP hebben ook ruimte nodig voor hun respectieve headers en trailers. Dit vermindert ook de effectieve MTU van de uitgaande interface.

Tunnel

Een tunnel is een logische interface op een Cisco-router die een manier biedt om passenger-pakketten in te kapselen in een transportprotocol.

Deze architectuur is ontwikkeld om services te bieden voor de implementatie van een point-to-point inkapselingsschema. Tunnel interfaces hebben deze drie primaire componenten:

• Passenger-protocol (AppleTalk, Banyan VINES, CLNS, DECnet, IPv4 of IPX)

• Carrier-protocol – één van de volgende inkapselingsprotocollen:

  • GRE - Cisco multiprotocol carrier protocol. Zie RFC 2784 en RFC 1701 voor meer informatie.

  • IPv4 in IPv4-tunnels – zie RFC 2003 voor meer informatie.

• Transportprotocol – het protocol dat wordt gebruikt voor het overdragen van het ingekapselde protocol.

De pakketten in deze sectie illustreren de concepten van IPv4-tunneling waarbij GRE het inkapselingsprotocol is en IPv4 het transportprotocol.

IPv4 is ook het passenger-protocol. In dit geval is IPv4 zowel het transport- als het passenger-protocol.

Normaal pakket

Tunnelpakket

• IPv4 is het transportprotocol.

• GRE is het inkapselingsprotocol.

• IPv4 is het passenger-protocol.

In het volgende voorbeeld wordt de inkapseling getoond met IPv4 en DECnet als passenger-protocollen en GRE als carrier.

Dit illustreert de mogelijkheid dat vervoerdersprotocollen meerdere reizigersprotocollen omvatten, zoals weergegeven in de afbeelding.

Een netwerkbeheerder overweegt tunneling in een situatie waarin er twee niet-aaneengesloten niet-IPv4-netwerken zijn gescheiden door een IPv4-backbone.

Als de niet-aaneengesloten netwerken DECnet uitvoeren, kan de beheerder ervoor kiezen om ze met elkaar te verbinden (of niet te verbinden) door DECnet in de backbone te configureren.

De beheerder wil niet toestaan dat DECnet-routering backbonebandbreedte verbruikt, omdat dit de prestaties van het IPv4-netwerk kan verstoren.

Een haalbaar alternatief is tunneling van DECnet via de IPv4-backbone. De tunneloplossing omvat de DECnet-pakketten in IPv4 en stuurt ze over de backbone naar het tunneleindpunt waar de inkapseling wordt verwijderd en de DECnet-pakketten via DECnet naar hun bestemming worden gerouteerd.

Er zijn voordelen aan het inkapselen van verkeer binnen een ander protocol:

• De endpoints gebruiken privé-adressen (RFC 1918) en de backbone ondersteunt geen routing van deze adressen.

• Virtual Private Networks (VPN’s) zijn toegestaan op WAN’s of het internet.

• Opgedeelde multiprotocol netwerken worden samengevoegd via een backbone met één protocol.

• Verkeer wordt versleuteld via de backbone of het internet.

Hierna wordt IPv4 gebruikt als het passagiersprotocol en IPv4 als het transportprotocol.

Overwegingen voor tunnelinterfaces

De volgende overwegingen zijn van toepassing bij tunneling.

• Fast switching van GRE-tunnels werd geïntroduceerd in Cisco IOS® versie 11.1 en CEF-switching in versie 12.0.

• CEF-switching voor multipoint GRE-tunnels werd geïntroduceerd in versie 12.2(8)T.

• Inkapseling en ontkapseling bij tunnel-endpoints waren langzame processen in eerdere versies van Cisco IOS® wanneer alleen proces-switching werd ondersteund.

• Er zijn beveiligings- en topologieproblemen bij de tunneling van pakketten. Tunnels kunnen toegangscontrolelijsten (ACL’s) en firewalls omzeilen.

• Als je door een firewall tunnelt, omzeilt je het passagiersprotocol dat wordt getunneld. Het is daarom raadzaam firewallfunctionaliteit op te nemen aan de tunnel-endpoints om beleid af te dwingen op de passenger-protocollen.

• Tunneling veroorzaakt problemen met transportprotocollen die beperkte timers hebben (bijvoorbeeld DECnet) vanwege de verhoogde latentie.

• Tunneling over omgevingen met verschillende snelheidsverbindingen, zoals snelle FDDI-ringen en langzame 9600-bps telefoonlijnen, introduceert problemen met het opnieuw ordenen van pakketten. Sommige passenger-protocollen werken slecht op netwerken met verschillende media.

• Point-to-point tunnels verbruiken bandbreedte op een fysieke verbinding. Over meerdere point-to-point tunnels heeft elke tunnelinterface een bandbreedte en dat de fysieke interface waarover de tunnel loopt een bandbreedte heeft. Stel bijvoorbeeld de tunnelbandbreedte in op 100 Kb als er 100 tunnels over een 10 Mb-verbinding lopen. De standaardbandbreedte voor een tunnel is 9 Kb.

• Routeringsprotocollen geven de voorkeur aan een tunnel boven een echte verbinding omdat de tunnel bedrieglijk een one-hop-link lijkt te zijn met het laagste kostenpad, hoewel het meer hop betreft en daarom duurder is dan een ander pad. Dit wordt beperkt door de juiste configuratie van het routeringsprotocol. Overweeg een ander routeringsprotocol over de tunnelinterface te gebruiken dan het routeringsprotocol dat op de fysieke interface wordt uitgevoerd.

• Problemen met recursieve routering worden vermeden door geschikte statische routes naar de tunnelbestemming te configureren. Er is sprake van een recursieve route wanneer het beste pad naar de tunnelbestemming via de tunnel zelf loopt. In deze situatie is de tunnelinterface niet stabiel. Deze fout wordt gezien wanneer er een recursief routeringsprobleem is.

  %TUN-RECURDOWN Interface Tunnel 0
  temporarily disabled due to recursive routing

Router als PMTUD-deelnemer bij endpoint van tunnel

De router heeft twee verschillende PMTUD-rollen wanneer de route het endpoint van een tunnel is.

• In de eerste rol is de router het doorsturende apparaat van een hostpakket. Bij PMTUD-verwerking moet de router de DF-bit en pakketgrootte van het oorspronkelijke datapakket controleren en waar nodig gepaste actie ondernemen.

• De tweede rol wordt vervuld nadat de router het oorspronkelijke IPv4-pakket heeft ingekapseld in het tunnelpakket. In deze fase fungeert de router meer als host voor PMTUD en het IPv4-tunnelpakket.

Wanneer de router in de eerste rol optreedt (een router die host IPv4-pakketten doorstuurt), komt deze rol in het spel voordat de router het host IPv4-pakket in het tunnelpakket inkapselt.

Als de router deelneemt als de forwarder van een hostpakket, voltooit deze de volgende acties:

• Controleren of de DF-bit is ingesteld.

• Controleren welke pakketgrootte de tunnel kan verwerken.

• Fragment (als het pakket te groot is en de DF-bit niet is ingesteld), fragmenten inkapselen en verzenden; of

• Het pakket afwijzen (als pakket te groot is en de DF-bit is ingesteld) en een ICMP-bericht naar de verzender sturen.

• Inkapselen (als pakket niet te groot is) en verzenden.

Er kan dus worden gekozen tussen inkapseling en vervolgens fragmentatie (verzending van twee inkapselfragmenten) of fragmentatie en vervolgens inkapseling (verzending van twee ingekapselde fragmenten).

Twee voorbeelden die de interactie weergeven van PMTUD en pakketten die voorbeeldnetwerken doorkruisen, worden in deze sectie beschreven.

In het eerste voorbeeld wordt getoond wat er gebeurt met een pakket wanneer de router (bij de tunnelbron) de rol van doorsturende router vervult.

Om PMTUD te verwerken, moet de router de DF-bit en pakketgrootte van het oorspronkelijke gegevenspakket controleren en passende actie ondernemen.

In dit voorbeeld is er sprake van GRE-inkapseling voor de tunnel. GRE doet fragmentatie vóór inkapseling.

In latere voorbeelden vindt fragmentatie plaats na inkapseling.

In voorbeeld 1 is de DF-bit niet ingesteld (DF = 0) en is de IPv4-MTU van de GRE-tunnel 1476 (1500 – 24).

Voorbeeld 1

1. De forwarding router (bij de tunnelbron) ontvangt een 1500-byte datagram met de DF bit clear (DF = 0) van de verzendende host.

Dit datagram bestaat uit een IP-header van 20 bytes en een TCP-payload van 1480 bytes.

 2. Omdat het pakket te groot is voor de IPv4 MTU nadat de GRE-overhead (24 bytes) is toegevoegd, breekt de forwarding router het datagram in twee fragmenten van 1476 (20 bytes IPv4-header + 1456 bytes IPv4-payload) en 44 bytes (20 bytes IPv4-header + 24 bytes IPv4-payload)

Nadat de GRE-inkapseling is toegevoegd, is het pakket niet groter dan de uitgaande fysieke interface MTU.

 3. De forwarding router voegt GRE-inkapseling, die een 4-byte GRE-header plus een 20-byte IPv4-header bevat, toe aan elk fragment van het oorspronkelijke IPv4-datagram.

Deze twee IPv4-datagrammen hebben nu lengtes van 1500 en 68 bytes en worden beschouwd als afzonderlijke IPv4-datagrammen, niet als fragmenten.

4. De tunneldoelrouter verwijdert de GRE-inkapseling uit elk fragment van het oorspronkelijke datagram, waardoor twee IPv4-fragmenten met een lengte van 1476 en 24 bytes overblijven.

Deze IPv4-datagramfragmenten worden afzonderlijk door deze router doorgestuurd naar de ontvangende host.

5. De ontvangende gastheer herschikt deze twee fragmenten in het oorspronkelijke datagram.

Voorbeeld 2 toont de rol van de forwarding router in de context van een netwerktopologie.

De router speelt dezelfde rol als de forwarding router, maar deze keer wordt de DF bit ingesteld (DF = 1).

Voorbeeld 2

1. De doorstuurrouter bij de tunnelbron ontvangt een 1500-byte datagram met DF = 1 van de zendende host.

2. Aangezien de DF-bit is ingesteld en de grootte van het datagram (1500 bytes) groter is dan de GRE-tunnel IPv4 MTU (1476), laat de router het datagram vallen en stuurt een "ICMP-fragmentatie nodig, maar DF-bitset" -bericht naar de bron van het datagram.

Het ICMP-bericht waarschuwt de afzender dat de MTU 1476 is.

3. De verzendende host ontvangt het ICMP-bericht en wanneer deze de oorspronkelijke gegevens opnieuw verzendt, gebruikt deze een 1476-byte IPv4-datagram.

4. Deze IPv4-datagramlengte (1476 bytes) is nu gelijk in waarde aan de GRE-tunnel IPv4 MTU, zodat de router de GRE-inkapseling toevoegt aan het IPv4-datagram.

5. De ontvangende router (op de tunnelbestemming) verwijdert de GRE-inkapseling van het IPv4-datagram en verzendt deze naar de ontvangende host.

Dit is wat er gebeurt wanneer de router in de tweede rol optreedt als een verzendende host met betrekking tot PMTUD en met betrekking tot het IPv4-tunnelpakket.

Deze rol komt in het spel nadat de router het originele IPv4-pakket in het tunnelpakket heeft ingekapseld.

Opmerking: Een router voert standaard geen PMTUD uit op de GRE-tunnelpakketten die hij genereert. De opdracht tunnel path-mtu-discovery kan worden gebruikt om PMTUD in te schakelen voor GRE-IPv4-tunnelpakketten.

In voorbeeld 3 wordt beschreven wat er gebeurt wanneer de host IPv4-datagrammen verzendt die klein genoeg zijn om in de IPv4-MTU van de GRE-tunnelinterface te passen.

In dit geval kan de DF-bit wel of niet zijn ingesteld (1 of 0).

De GRE-tunnelinterface heeft de tunnel path-mtu-discovery opdracht niet geconfigureerd, zodat de router geen PMTUD op het GRE-IPv4-pakket uitvoert.

Voorbeeld 3

1. De forwarding router bij de tunnelbron ontvangt een 1476-byte datagram van de verzendende host.

2. Deze router bevat het 1476-byte IPv4-datagram in GRE om een 1500-byte GRE IPv4-datagram te krijgen.

De DF bit in de GRE IPv4 header is gewist (DF = 0). Deze router stuurt dit pakket vervolgens door naar de tunnelbestemming.

3. Stel dat er een router is tussen de tunnelbron en de bestemming met een koppeling MTU van 1400.

Deze router fragmenteert het tunnelpakket omdat het DF-bit helder is (DF = 0).

Vergeet niet dat dit voorbeeld de buitenste IPv4 fragmenteert, zodat de GRE-, binnenste IPv4- en TCP-headers alleen in het eerste fragment verschijnen.

4. De tunnelbestemmingsrouter moet het GRE-tunnelpakket opnieuw samenstellen.

5. Nadat het GRE-tunnelpakket opnieuw is samengesteld, verwijdert de router de GRE IPv4-header en verzendt het originele IPv4-datagram op weg.

Voorbeeld 4 laat zien wat er gebeurt als de router optreedt in de rol van een verzendende host met betrekking tot PMTUD en met betrekking tot het IPv4-tunnelpakket.

Deze keer wordt de DF-bit ingesteld (DF = 1) in de oorspronkelijke IPv4-header en is de tunnel path-mtu-discovery opdracht zo geconfigureerd dat de DF-bit wordt gekopieerd van de binnenste IPv4-header naar de buitenste (GRE + IPv4)-header.

Voorbeeld 4

1. De doorstuurrouter bij de tunnelbron ontvangt een 1476-byte datagram met DF = 1 van de zendende host.

2. Deze router bevat het 1476-byte IPv4-datagram in GRE om een 1500-byte GRE IPv4-datagram te krijgen.

Deze GRE IPv4-header heeft de DF-bitset (DF = 1) omdat het oorspronkelijke IPv4-datagram de DF-bitset had.

Deze router stuurt dit pakket vervolgens door naar de tunnelbestemming.

3. Nogmaals, stel dat er een router is tussen de tunnelbron en de bestemming met een koppeling MTU van 1400.

Deze router fragmenteert het tunnelpakket niet omdat de DF-bit is ingesteld (DF=1).

Deze router moet het pakket laten vallen en een ICMP-foutbericht verzenden naar de tunnelbronrouter, omdat dat het IPv4-adres van de bron op het pakket is.

4. De doorstuurrouter bij de tunnelbron ontvangt deze "ICMP" -foutmelding en verlaagt de GRE-tunnel IPv4 MTU tot 1376 (1400 - 24).

De volgende keer dat de verzendende host de gegevens opnieuw verzendt in een 1476-byte IPv4-pakket, kan dit pakket te groot zijn en deze router stuurt vervolgens een "ICMP" -foutbericht naar de afzender met een MTU-waarde van 1376.

Wanneer de verzendende host de gegevens opnieuw verzendt, verzendt deze deze in een 1376-byte IPv4-pakket en dit pakket maakt het door de GRE-tunnel naar de ontvangende host.

Voorbeeld 5

Dit voorbeeld illustreert GRE fragmentatie. Fragment voor inkapseling voor GRE, doe dan PMTUD voor het gegevenspakket en de DF-bit wordt niet gekopieerd wanneer het IPv4-pakket wordt ingekapseld door GRE.

De DF-bit is niet ingesteld. De IPv4-MTU van de GRE-tunnelinterface is standaard 24 bytes minder dan de IPv4-MTU van de fysieke interface. De IPv4-MTU van de GRE-interface is dus 1476, zoals aangegeven in de afbeelding.

1. De verzender verzendt een pakket van 1500 bytes (IPv4-header van 20 bytes + TCP-payload van 1480 bytes).
2. Omdat de MTU van de GRE-tunnel 1476 is, wordt het 1500-byte pakket opgedeeld in twee IPv4-fragmenten van 1476 en 44 bytes, elk in afwachting van de extra 24 bytes van GRE-header.
3. De 24 bytes van de GRE-header worden toegevoegd aan elk IPv4-fragment. De fragmenten zijn nu 1500 (1476 + 24) en 68 (44 + 24) bytes.
4. De GRE + IPv4-pakketten met de twee IPv4-fragmenten worden doorgestuurd naar de router van de GRE-tunnelpeer.
5. De router van de GRE-tunnelpeer verwijdert de GRE-headers uit de twee pakketten.
6. Deze router stuurt de twee pakketten door naar de bestemmingshost.
7. De bestemmingshost stelt de IPv4-fragmenten opnieuw samen tot het oorspronkelijke IPv4-datagram.

Voorbeeld 6

Dit voorbeeld is vergelijkbaar met voorbeeld 5, maar deze keer is de DF-bit ingesteld. De router is geconfigureerd om PMTUD uit te voeren op GRE + IPv4-tunnelpakketten met de tunnel path-mtu-discoveryopdracht en de DF-bit wordt gekopieerd van de oorspronkelijke IPv4-header naar de GRE IPv4-header.

Als de router een ICMP-foutbericht ontvangt voor het GRE + IPv4-pakket, verlaagt deze de IPv4-MTU voor de GRE-tunnelinterface.

De GRE Tunnel IPv4 MTU is standaard ingesteld op 24 bytes minder dan de fysieke interface MTU, dus de GRE IPv4 MTU hier is 1476. Er is een 1400 MTU-verbinding in het GRE-tunnelpad zoals weergegeven in de afbeelding.

1. De router ontvangt een pakket van 1500 bytes (IPv4-header van 20 bytes + TCP-payload van 1480 bytes) en wijst het pakket af. Het pakket wordt door de router afgewezen omdat het groter is dan de IPv4-MTU (1476) van de GRE-tunnelinterface.
2. De router stuurt een ICMP-foutbericht naar de verzender met de melding dat de MTU van de volgende hop 1476 is. De host registreert deze informatie, meestal als een hostroute voor de bestemming in zijn routeringstabel.
3. De verzendende host gebruikt een pakketgrootte van 1476 bytes bij het opnieuw verzenden van de data. De GRE-router voegt 24 bytes aan GRE-inkapseling toe en verzendt een pakket van 1500 bytes.
4. Het pakket van 1500 bytes kan niet worden verzonden via de link van 1400 bytes en wordt dus door de tussenliggende router afgewezen.
5. De tussenliggende router stuurt een ICMP-bericht (type 3, code 4) naar de GRE-router met een MTU van de volgende hop van 1400. De GRE-router verlaagt deze tot 1376 (1400 – 24) en stelt een interne IPv4-MTU-waarde in voor de GRE-interface. Deze wijziging kan alleen worden gezien wanneer u de debug tunnel opdracht gebruikt; deze kan niet worden gezien in de uitvoer van de show ip interface tunnel<#> opdracht.
6. De volgende keer dat de host het 1476-byte pakket opnieuw verzendt, laat de GRE-router het pakket vallen, omdat het groter is dan de huidige IPv4 MTU (1376) op de GRE-tunnelinterface.
7. De GRE-router stuurt een andere ICMP (type = 3, code = 4) naar de afzender met een next-hop MTU van 1376 en de host werkt de huidige informatie bij met nieuwe waarde.
8. De host verzendt de gegevens opnieuw, maar nu in een kleiner pakket van 1376 bytes, voegt GRE 24 bytes aan inkapseling toe en stuurt het door. Deze keer gaat het pakket naar de GRE-tunnelpeer, waar het pakket wordt gedecapsuleerd en naar de bestemmingshost wordt verzonden.

Opmerking: Als de opdracht tunnel path-mtu-discovery in dit scenario niet is geconfigureerd op de doorstuurrouter en de DF-bit is ingesteld in de pakketten die door de GRE-tunnel zijn doorgestuurd, slaagt Host 1 er nog steeds in om TCP / IPv4-pakketten naar Host 2 te verzenden, maar ze worden in het midden gefragmenteerd bij de 1400 MTU-link. Ook de GRE-tunnelpeer moet ze opnieuw monteren voordat hij ze kan ontkapselen en doorsturen.

Pure IPsec-tunnelmodus

Het IPv4sec-protocol (IPv4 Security) is een op standaarden gebaseerde methode die de privacy, integriteit en authenticiteit garandeert van informatie die via IPv4-netwerken wordt overgedragen.

IPv4sec biedt IPv4-encryptie op de netwerklaag. IPv4sec verlengt het IPv4-pakket door ten minste één IPv4-header toe te voegen (tunnelmodus).

De toegevoegde header(s) variëren in lengte afhankelijk van de IPv4sec-configuratiemodus, maar ze zijn niet groter dan ~58 bytes (Encapsulating Security Payload (ESP) en ESP-verificatie (ESPauth)) per pakket.

IPv4sec heeft twee modi: tunnelmodus en transportmodus.

1. De tunnelmodus is de standaardmodus. In de tunnelmodus wordt het volledige oorspronkelijke IPv4-pakket beschermd (versleuteld, geverifieerd of beide) en ingekapseld door de IPv4sec-headers en ‑trailers. Vervolgens wordt een nieuwe IPv4-header toegevoegd aan het pakket die de IPv4sec-endpoints (peers) aangeeft als bron en bestemming. De tunnelmodus kan worden gebruikt met al het unicast IPv4-verkeer en moet worden gebruikt als IPv4sec verkeer van hosts achter de IPv4sec-peers beschermt. De tunnelmodus wordt bijvoorbeeld gebruikt met Virtual Private Networks (VPN’s) waar hosts op een beschermd netwerk pakketten verzenden naar hosts op een ander beschermd netwerk via enkele IPv4sec-peers. Bij VPN’s beschermt de IPv4sec-‘tunnel’ het IPv4-verkeer tussen hosts door het verkeer tussen de IPv4sec-peerrouters te versleutelen.
2. Met de transportmodus (geconfigureerd met de subopdracht, mode transportop de transformatiedefinitie) is alleen de payload van het oorspronkelijke IPv4-pakket beveiligd (gecodeerd, geverifieerd of beide). De payload wordt ingekapseld door de IPv4sec-headers en ‑trailers. De oorspronkelijke IPv4-headers blijven intact, maar het IPv4-protocolveld wordt gewijzigd naar ESP (50). De oorspronkelijke protocolwaarde wordt opgeslagen in de IPv4sec-trailer en wordt hersteld wanneer het pakket wordt ontsleuteld. De transportmodus wordt alleen gebruikt wanneer het te beschermen IPv4-verkeer tussen de IPv4sec-peers zelf plaatsvindt en de IPv4-adressen voor bron en bestemming in het pakket gelijk zijn aan de adressen van de IPv4sec-peers. Normaliter wordt de IPv4sec-transportmodus alleen gebruikt wanneer een ander tunnelingprotocol (zoals GRE) wordt gebruikt om eerst het IPv4-datapakket in te kapselen, waarna IPv4sec wordt gebruikt om de GRE-tunnelpakketten te beschermen.

IPv4sec voert altijd PMTUD uit voor datapakketten en voor de eigen pakketten. Er zijn IPv4sec-configuratieopdrachten om PMTUD-verwerking voor het IPv4sec IPv4-pakket aan te passen. IPv4 kan de DF-bit wissen, instellen of kopiëren van de IPv4-header in het datapakket naar de IPv4sec IPv4-header. Dit wordt de ‘Functionaliteit voor negeren van DF-bit’ genoemd.

Opmerking: Vermijd fragmentatie na inkapseling wanneer hardwarecodering met IPv4sec is voltooid. Hardwarecodering geeft u een doorvoersnelheid van ongeveer 50 Mbs, afhankelijk van de hardware, maar als het IPv4sec-pakket gefragmenteerd is, verliest u 50 tot 90 procent van de doorvoer. Dit verlies wordt veroorzaakt doordat proces-switching wordt toegepast op de gefragmenteerde IPv4sec-pakketten voor het opnieuw samenstellen ervan, waarna ze voor decryptie worden overgedragen aan de engine voor hardware-encryptie. Dit verlies aan doorvoersnelheid kan ertoe leiden dat de snelheid van hardware-encryptie wordt verlaagd tot het prestatieniveau van software-encryptie (2–10 MB).

Voorbeeld 7

In dit scenario wordt IPv4sec-fragmentatie in actie getoond. De MTU langs het gehele pad is 1500. In dit scenario is de DF-bit niet ingesteld.

1. De router ontvangt een pakket van 1500 bytes (IPv4-header van 20 bytes + TCP-payload van 1480 bytes) met host 2 als bestemming.
2. Het pakket van 1500 bytes is versleuteld door IPv4sec en er zijn 52 bytes aan overhead toegevoegd (IPv4sec-header, ‑trailer en aanvullende IPv4-header). IPv4sec moet dus een pakket van 1552 bytes verzenden. Omdat de uitgaande MTU 1500 is, moet dit pakket worden gefragmenteerd.
3. Het IPv4sec-pakket wordt opgedeeld in twee fragmenten. Tijdens fragmentatie wordt een extra 20-byte IPv4-header toegevoegd voor het tweede fragment, wat resulteert in een 1500-byte fragment en een 72-byte IPv4-fragment.
4. De router van de IPv4sec-tunnelpeer ontvangt de fragmenten, verwijdert de aanvullende IPv4-header en stelt het oorspronkelijke IPv4sec-pakket weer samen uit de IPv4-fragmenten. Vervolgens ontsleutelt IPv4sec dit pakket.
5. De router stuurt het oorspronkelijke datapakket van 1500 bytes naar host 2.

Voorbeeld 8

Dit voorbeeld is vergelijkbaar met voorbeeld 6, behalve dat in dit geval de DF-bit is ingesteld in het oorspronkelijke gegevenspakket en er een koppeling in het pad is tussen de IPv4sec-tunnelpeers die een lagere MTU heeft dan de andere koppelingen.

Dit voorbeeld laat zien hoe de IPv4sec peer router beide PMTUD-rollen uitvoert, zoals beschreven in The Router als een PMTUD-deelnemer aan het eindpunt van een tunnelsectie.

De IPv4sec PMTU verandert in een lagere waarde als gevolg van de noodzaak tot fragmentatie.

De DF-bit wordt gekopieerd van de binnenste IPv4-header naar de buitenste IPv4-header wanneer IPv4sec een pakket codeert.

De MTU- en PMTU-waarde van de media worden opgeslagen in de IPv4sec Security Association (SA).

De MTU van de media is gebaseerd op de MTU van de uitgaande routerinterface; de PMTU is gebaseerd op de minimale MTU in het pad tussen de IPv4sec-peers.

IPv4sec inkapselt/versleutelt het pakket voordat het probeert het te fragmenteren zoals weergegeven in de afbeelding.

1. De router ontvangt een pakket van 1500 bytes en laat het vallen omdat de IPv4sec-overhead, wanneer toegevoegd, het pakket groter maakt dan de PMTU (1500).
2. De router stuurt een ICMP-bericht naar host 1 met de melding dat de MTU van de volgende hop 1442 is (1500 – 58 = 1442). Deze 58 bytes is de maximale IPv4sec-overhead wanneer u IPv4sec ESP en ESPauth gebruikt. De echte IPv4sec-overhead is mogelijk 7 bytes minder dan deze waarde. Host 1 legt deze informatie vast in de routingtabel, doorgaans als een hostroute voor de bestemming (host 2).
3. Host 1 verlaagt de PMTU voor Host 2 tot 1442, zodat Host 1 kleinere (1442 byte) pakketten verzendt wanneer het de gegevens opnieuw verzendt naar Host 2. De router ontvangt het pakket van 1442 bytes en IPv4sec voegt 52 bytes aan encryptie-overhead toe, zodat het uiteindelijke IPv4sec-pakket 1496 bytes groot is. Aangezien de DF-bit is ingesteld in de header van dit pakket, wordt het afgewezen door de middelste router met de link met een MTU van 1400.
4. De middelste router die het pakket afwijst, stuurt een ICMP-bericht naar de verzender van het IPv4sec-pakket (de eerste router) met de melding dat de MTU van de volgende hop 1400 is. Deze waarde wordt vastgelegd in de IPv4sec SA-PMTU.
5. De volgende keer dat host 1 het 1442-byte pakket opnieuw verzendt (het heeft er geen bevestiging voor ontvangen), laat de IPv4sec het pakket vallen. De router laat het pakket vallen omdat de IPv4sec-overhead, wanneer toegevoegd aan het pakket, het groter maakt dan de PMTU (1400).
6. De router stuurt een ICMP-bericht naar Host 1 en vertelt dat de next-hop MTU nu 1342 is. (1400 - 58 = 1342). Host 1 registreert deze informatie opnieuw.
7. Wanneer host 1 de gegevens opnieuw verzendt, gebruikt het het kleinere pakket (1342). Dit pakket vereist geen fragmentatie en maakt het door de IPv4sec-tunnel naar Host 2.

Combinatie van GRE en IPv4sec

Complexere interacties voor fragmentatie en PMTUD treden op wanneer IPv4sec wordt gebruikt om GRE-tunnels te versleutelen.

IPv4sec en GRE worden op deze manier gecombineerd omdat IPv4sec geen ondersteuning biedt voor multicast IPv4-pakketten, waardoor geen protocol voor dynamische routing kan worden uitgevoerd via het IPv4sec-VPN.

GRE-tunnels ondersteunen multicast wel, zodat een GRE-tunnel kan worden gebruikt om het multicast pakket eerst via het protocol voor dynamische routing in te kapselen in een unicast GRE IPv4-pakket dat vervolgens door IPv4sec kan worden versleuteld.

Wanneer u dit doet, wordt IPv4sec vaak geïmplementeerd in de transportmodus bovenop GRE omdat de IPv4sec-peers en de GRE-tunneleindpunten (de routers) hetzelfde zijn en de transportmodus 20 bytes IPv4sec-overhead bespaart.

Het wordt interessant wanneer een IPv4-pakket is opgedeeld in twee fragmenten en ingekapseld door GRE.

In dit geval ziet IPv4sec twee onafhankelijke GRE + IPv4-pakketten. Vaak is in een standaardconfiguratie een van deze pakketten groot genoeg dat het gefragmenteerd moet worden nadat het is gecodeerd.

De IPv4sec-peer moet dit pakket opnieuw samenstellen voordat het wordt gedecodeerd. Deze ‘dubbele fragmentatie’ (een keer vóór GRE en opnieuw na IPv4sec) op de verzendende router vergroot de latentie en verlaagt de doorvoersnelheid.

De hermontage is proces-geschakeld, dus er is een CPU-hit op de ontvangende router wanneer dit gebeurt.

Deze situatie kan worden vermeden door de ‘ip mtu’ van de GRE-tunnelinterface laag genoeg in te stellen om rekening te houden met de overhead van zowel GRE als IPv4sec (standaard is de ‘ip mtu’ van de GRE-tunnelinterface ingesteld op de MTU van de werkelijke uitgaande interface – GRE-overheadbytes).

Deze tabel bevat de voorgestelde MTU-waarden voor elke tunnel/modus-combinatie die ervan uitgaan dat de uitgaande fysieke interface een MTU van 1500 heeft.

Opmerking: De MTU-waarde van 1400 wordt aanbevolen omdat deze de meest voorkomende GRE + IPv4sec-moduscombinaties dekt. Ook is er geen merkbaar nadeel aan het toestaan van een extra 20 of 40 bytes overhead. Het is eenvoudiger om slechts één waarde te onthouden en in te stellen die van toepassing is op bijna alle scenario’s.

Voorbeeld 9

IPv4sec wordt geïmplementeerd bovenop GRE. De MTU van de uitgaande fysieke interface is 1500, de IPv4sec-PMTU is 1500 en de GRE IPv4-MTU is 1476 (1500 – 24 = 1476).

TCP/IPv4-pakketten zijn daarom twee keer gefragmenteerd, één keer voor GRE en één keer na IPv4sec.

Het pakket is gefragmenteerd vóór GRE-inkapseling en een van deze GRE-pakketten is opnieuw gefragmenteerd na IPv4sec-codering.

Door ‘ip mtu 1440’ (IPv4sec-transportmodus) of ‘ip mtu 1420’ (IPv4sec-tunnelmodus) te configureren op de GRE-tunnel wordt in dit scenario de kans op dubbele fragmentatie weggenomen.

1. De router ontvangt een datagram van 1500 bytes.
2. Voorafgaand aan inkapseling fragmenteert GRE het pakket van 1500 bytes in twee delen: 1476 bytes (1500 – 24 = 1476) en 44 bytes (24 voor data + 20 voor IPv4-header).
3. GRE kapselt de IPv4-fragmenten in, waardoor nog eens 24 bytes aan elk pakket worden toegevoegd. Dit levert twee GRE + IPv4sec-pakketten van respectievelijk 1500 bytes (1476 + 24) en 68 bytes (44 + 24) op.
4. IPv4sec versleutelt de twee pakketten, die 52 bytes (IPv4sec tunnel-mode) van inkapseling overhead toe te voegen aan elk, om een 1552-byte en een 120-byte pakket te geven.
5. Het IPv4sec-pakket van 1552 bytes wordt door de router gefragmenteerd omdat het groter is dan de MTU van de uitgaande interface (1500). Het pakket van 1552 bytes wordt opgedeeld in een pakket van 1500 bytes en één van 72 bytes (payload van 52 bytes + 20 bytes extra van IPv4-header voor het tweede fragment). De drie pakketten van 1500, 72 en 120 bytes worden doorgestuurd naar de IPv4sec + GRE-peer.
6. De ontvangende router stelt de twee IPv4sec-fragmenten (1500 bytes en 72 bytes) opnieuw samen tot het oorspronkelijke IPv4sec + GRE-pakket van 1552 bytes. Er hoeft niets te worden gedaan met het IPv4sec + GRE-pakket van 120 bytes.
7. IPv4sec ontsleutelt beide IPv4sec + GRE-pakketten van 1552 en 120 bytes tot GRE-pakketten van 1500 en 68 bytes.
8. GRE ontkapselt de GRE-pakketten van 1500 en 68 bytes tot IPv4-pakketfragmenten van 1476 en 44 bytes. Deze IPv4-pakketfragmenten worden doorgestuurd naar de bestemmingshost.
9. Host 2 stelt deze IPv4-fragmenten opnieuw samen tot het oorspronkelijke IPv4-datagram van 1500 bytes.

Scenario 10 is vergelijkbaar met scenario 8 met dit verschil dat zich nu een link met een lagere MTU in het tunnelpad bevindt. In dit scenario is sprake van het slechtste geval voor het eerste pakket dat van host 1 naar host 2 wordt verzonden. Na de laatste stap in dit scenario stelt host 1 de juiste PMTU in voor host 2 en is alles goed voor de TCP-verbindingen tussen host 1 en host 2. TCP-stromen tussen host 1 en andere hosts (bereikbaar via de IPv4sec + GRE-tunnel) hoeven alleen de laatste drie stappen van scenario 10 te doorlopen.

In dit scenario wordt de tunnel path-mtu-discovery opdracht geconfigureerd in de GRE-tunnel en wordt de DF-bit ingesteld op TCP/IPv4-pakketten die afkomstig zijn van host 1.

Voorbeeld 10

1. De router ontvangt een pakket van 1500 bytes. Dit pakket wordt door GRE afgewezen omdat het pakket niet kan worden gefragmenteerd of doorgestuurd aangezien de DF-bit is ingesteld en het pakket groter is dan de ‘ip mtu’ van de uitgaande interface na toevoeging van de GRE-overhead (24 bytes).
2. De router stuurt een ICMP-bericht naar host 1 met de melding dat de MTU van de volgende hop 1476 is (1500 – 24 = 1476).
3. Host 1 wijzigt zijn PMTU voor host 2 naar 1476 en verzendt vervolgens een kleiner pakket. GRE kapselt het in en draagt het pakket van 1500 bytes over aan IPv4sec. IPv4sec wijst het pakket af omdat GRE de DF-bit (ingesteld) heeft gekopieerd van de binnenste IPv4-header. Met de IPv4sec-overhead (maximaal 38 bytes) is het pakket te groot om te worden doorgestuurd naar de fysieke interface.
4. IPv4sec stuurt een ICMP-bericht naar GRE, wat aangeeft dat de next-hop MTU 1462 bytes is (aangezien er maximaal 38 bytes zijn toegevoegd voor codering en IPv4-overhead). GRE legt de waarde 1438 (1462 – 24) vast als de ‘ip mtu’ voor de tunnelinterface.

   Opmerking: deze waardewijziging wordt intern opgeslagen en kan niet worden gezien in de uitvoer van de show ip interface tunnel<#>opdracht. U ziet deze wijziging alleen als u de opdracht debug tunnel inschakelt.

5. De volgende keer dat host 1 het pakket van 1476 bytes opnieuw verzendt, zal GRE het pakket afwijzen.
6. De router stuurt een ICMP-bericht naar host 1 met de melding dat de MTU van de volgende hop 1438 is.
7. Host 1 verlaagt de PMTU voor host 2 en verzendt opnieuw een pakket van 1438 bytes. Deze keer accepteert GRE het pakket, kapselt het in en draagt het over aan IPv4sec voor encryptie.
8. Het IPv4sec-pakket wordt doorgestuurd naar de tussenliggende router en afgewezen omdat die een MTU van de uitgaande interface van 1400 heeft.
9. De tussenliggende router stuurt een ICMP-bericht naar IPv4sec met de melding dat de MTU van de volgende hop 1400 is. Deze waarde wordt door IPv4sec vastgelegd in de PMTU-waarde van de bijbehorende IPv4sec SA.
10. Wanneer host 1 het pakket van 1438 bytes opnieuw verzendt, kapselt GRE het pakket in. Vervolgens draagt GRE het pakket over aan IPv4sec. IPv4sec wijst het pakket af omdat het de eigen PMTU heeft gewijzigd in 1400.
11. IPv4sec stuurt een ICMP-foutbericht naar GRE met de melding dat de MTU van de volgende hop 1362 is en GRE legt de waarde 1338 intern vast.
12. Wanneer host 1 het oorspronkelijke pakket opnieuw verzendt (omdat geen bevestiging is ontvangen), wijst GRE het pakket af.
13. De router stuurt een ICMP-bericht naar host 1 met de melding dat de MTU van de volgende hop 1338 is (1362 – 24). Host 1 verlaagt zijn PMTU voor host 2 tot 1338.
14. Host 1 verzendt opnieuw een pakket van 1338 bytes en deze keer bereikt het host 2 wel.

Meer aanbevelingen

Het configureren van de tunnel path-mtu-discovery opdracht op een tunnelinterface kan GRE- en IPv4sec-interactie helpen wanneer ze op dezelfde router zijn geconfigureerd.

Zonder de tunnel path-mtu-discovery opdracht geconfigureerd, zou de DF-bit altijd worden gewist in de GRE IPv4-header.

Hierdoor kan het GRE IPv4-pakket worden gefragmenteerd ook al is de DF-bit ingesteld in de ingekapselde data-IPv4-header (waardoor normaliter het pakket niet kan worden gefragmenteerd).

Als de opdracht tunnel path-mtu-discovery is geconfigureerd op de GRE-tunnelinterface:

1. GRE kopieert de DF-bit van de IPv4-header voor gegevens naar de IPv4-header voor GRE.
2. Als de DF-bit is ingesteld in de GRE IPv4-header en het pakket "te groot" is na IPv4sec-codering voor de IPv4 MTU op de fysieke uitgaande interface, laat IPv4sec het pakket vallen en meldt de GRE-tunnel om de IPv4 MTU-grootte te verminderen.
3. IPv4sec doet PMTUD voor zijn eigen pakketten en als de IPv4sec PMTU verandert (als deze wordt gereduceerd), meldt IPv4sec GRE niet onmiddellijk, maar wanneer een ander groter pakket doorkomt, vindt het proces in stap 2 plaats.
4. De GRE IPv4 MTU is nu kleiner, dus het laat alle data IPv4-pakketten met de DF-bitset vallen die nu te groot zijn en stuurt een ICMP-bericht naar de verzendende host.

De opdracht tunnel path-mtu-discovery helpt de GRE-interface om zijn IPv4 MTU dynamisch in te stellen in plaats van statisch met de ip mtu opdracht. Het wordt aanbevolen beide opdrachten te gebruiken.

De ip mtu opdracht wordt gebruikt om ruimte te bieden voor de GRE- en IPv4sec-overhead ten opzichte van de lokale fysieke uitgaande interface IPv4 MTU.

Met de tunnel path-mtu-discovery opdracht kan de GRE-tunnel IPv4 MTU verder worden verlaagd als er een lagere IPv4 MTU-link in het pad tussen de IPv4sec-peers is.

Hierna volgen enkele oplossingen voor als u problemen ondervindt met PMTUD in een netwerk met geconfigureerde GRE + IPv4sec-tunnels.

De lijst begint met de oplossing die de voorkeur heeft.

1. Los het probleem van niet-werkende PMTUD op. Dit wordt meestal veroorzaakt door een router of firewall die ICMP blokkeert.
2. Gebruik de ip tcp adjust-mss opdracht op de tunnelinterfaces zodat de router de TCP MSS-waarde in het TCP SYN-pakket verlaagt. Dit helpt de twee eindhosts (de TCP-zender en -ontvanger) om pakketten te gebruiken die klein genoeg zijn zodat PMTUD niet nodig is.
3. Gebruik beleidsroutering op de inkomende interface van de router en configureer een routekaart om de DF-bit in de data-IPv4-header van de data te wissen voordat deze de GRE-tunnelinterface bereiken. Hierdoor kan het IPv4-gegevenspakket worden gefragmenteerd voordat GRE wordt ingekapseld.
4. Verhoog de ‘ip mtu’ voor de GRE-tunnelinterface zodat deze overeenkomt met de MTU van de uitgaande interface. Hierdoor kan het IPv4-gegevenspakket GRE worden ingekapseld zonder het eerst te fragmenteren. Het GRE-pakket wordt vervolgens IPv4sec gecodeerd en vervolgens gefragmenteerd om de fysieke uitgaande interface te verlaten. In dit geval zou u de opdracht niet configureren tunnel path-mtu-discovery op de GRE-tunnelinterface. Hierdoor kan de doorvoersnelheid aanzienlijk afnemen omdat opnieuw samenstellen van het IPv4-pakket op de IPv4sec-peer wordt uitgevoerd in de modus proces-switching.

Gerelateerde informatie

• Ondersteuningspagina voor IP-routing
• Ondersteuningspagina voor IPsec (IP security protocol)
• RFC 1191 PMTUD – Path MTU Discovery
• RFC 1063 IP MTU Discovery Options
• RFC 791 Internet Protocol
• RFC 793 Transmission Control Protocol
• RFC 879 The TCP Maximum Segment Size and Related Topics
• RFC 1701 Generic Routing Encapsulation (GRE)
• RFC 1241 A Scheme for an Internet Encapsulation Protocol
• RFC 2003 IP Encapsulation within IP
• Technische ondersteuning en documentatie – Cisco Systems