Behebung von IPv4-Fragmentierung, MTU-, MSS- und PMTUD-Problemen mit GRE und IPSec

Einleitung

In diesem Dokument werden die Funktionsweisen von IPv4-Fragmentierung und Path Maximum Transmission Unit Discovery (PMTUD) beschrieben. 

Hintergrundinformationen

Außerdem werden Szenarien besprochen, die das Verhalten der PMTUD in Verbindung mit verschiedenen Kombinationen von IPv4-Tunneln beinhalten.

IPv4-Fragmentierung und -Reassemblierung

Obwohl die maximale Länge eines IPv4-Datagramms 65535 beträgt, erzwingen die meisten Übertragungswege eine kleinere maximale Paketlänge, die als MTU bezeichnet wird. Der Wert der MTU hängt vom Übertragungsweg ab.

Das Design von IPv4 trägt den unterschiedlichen MTUs Rechnung, da es Routern ermöglicht, IPv4-Datagramme nach Bedarf zu fragmentieren.

Die Empfangsstation ist verantwortlich für die Reassemblierung der Fragmente in das IPv4-Datagramm in seiner ursprünglichen Größe.

Bei der IPv4-Fragmentierung wird ein Datagramm in mehrere Teile zerlegt, die später wieder zusammengesetzt werden können.

Die Felder „IPv4 source“, „destination“, „identification“, „total length“ und „fragment offset“ sowie die Flags „more fragments“ (MF) und „do not fragment“ (DF) im IPv4-Header werden für die IPv4-Fragmentierung und -Reassemblierung verwendet.

Weitere Informationen über die Mechanik der IPv4-Fragmentierung und -Reassemblierung finden Sie unter RFC 791.

Dieses Bild zeigt das Layout eines IPv4-Headers.

Die Identifikation beträgt 16 Bit und ist ein vom Sender eines IPv4-Datagramms zugewiesener Wert. Dies erleichtert die Reassemblierung der Fragmente eines Datagramms.

Der Fragment-Offset beträgt 13 Bit und gibt an, wo ein Fragment im ursprünglichen IPv4-Datagramm hingehört. Dieser Wert ist ein Vielfaches von acht Byte.

Im Flags-Feld des IPv4-Headers befinden sich drei Bits für Steuerung-Flags. Das DF-Bit „Nicht fragmentieren“ bestimmt, ob ein Paket fragmentiert werden darf oder nicht.

Bit 0 ist reserviert und wird immer auf 0 gesetzt.

Bit 1 ist das DF-Bit (0 = „Fragmentierung erlaubt“, 1 = „nicht fragmentieren“).

Bit 2 ist das MF-Bit (0 = „letztes Fragment“, 1 = „weitere Fragmente“).

Wert	Bit 0 Reserviert	Bit 1 DF	Bit 2 MF
0	0	Mai	Letzte
1	0	Das sollten Sie unterlassen:	Mehr

Wenn Sie alle Längen der IPv4-Fragmente addieren, übersteigt der Wert die ursprüngliche IPv4-Datagrammlänge um 60.

Der Grund dafür, dass die Gesamtlänge um 60 erhöht wird, ist, dass drei zusätzliche IPv4-Header erstellt wurden, einer für jedes Fragment nach dem ersten.

Das erste Fragment hat einen Offset von 0 und die Länge dieses Fragments beträgt 1.500. Dazu gehören 20 Byte für den leicht geänderten ursprünglichen IPv4-Header.

Das zweite Fragment hat einen Offset von 185 (185 x 8 = 1480); der Datenteil dieses Fragments beginnt nach 1.480 Byte des ursprünglichen IPv4-Datagramms.

Die Länge dieses Fragments beträgt 1.500; dies umfasst den zusätzlichen IPv4-Header, der für dieses Fragment erstellt wurde.

Das dritte Fragment hat einen Offset von 370 (370 x 8 = 2960); der Datenteil dieses Fragments beginnt nach 2.960 Byte des ursprünglichen IPv4-Datagramms.

Die Länge dieses Fragments beträgt 1.500; dies umfasst den zusätzlichen IPv4-Header, der für dieses Fragment erstellt wurde.

Das vierte Fragment hat einen Offset von 555 (555 x 8 = 4440), was bedeutet, dass der Datenteil dieses Fragments nach 4440 Byte des ursprünglichen IPv4-Datagramms beginnt.

Die Länge dieses Fragments beträgt 700 Byte; dies umfasst den zusätzlichen IPv4-Header, der für dieses Fragment erstellt wurde.

Erst wenn das letzte Fragment empfangen wird, kann die Größe des ursprünglichen IPv4-Datagramms bestimmt werden.

Der Fragment-Offset im letzten Fragment (555) ergibt einen Daten-Offset von 4440 Byte nach Beginn des ursprünglichen IPv4-Datagramms.

Die Summe der Datenbyte aus dem letzten Fragment (680 = 700 - 20) ergibt 5.120 Byte – das ist der Datenanteil des ursprünglichen IPv4-Datagramms.

Durch Addieren von 20 Byte für einen IPv4-Header erhalten Sie die Größe des ursprünglichen IPv4-Datagramms (4440 + 680 + 20 = 5140), wie in den Bildern gezeigt.

Probleme mit der IPv4-Fragmentierung

Während der Fragmentierung eines IPv4-Datagramms kommt es zu einem geringfügigen Anstieg der CPU- und Speicherauslastung. Dies gilt sowohl für den Sender als auch für einen Router im Pfad zwischen einem Sender und einem Empfänger.

Bei der Erstellung von Fragmenten werden Fragment-Header erzeugt und das ursprüngliche Datagramm in die Fragmente kopiert.

Dies erfolgt effizient, da die Informationen, die für die Erstellung der Fragmente benötigt werden, sofort verfügbar sind.

Auf Empfängerseite verursacht die Reassemblierung der Fragmente eine höhere Auslastung, da der Empfänger Speicher für die ankommenden Fragmente zuweisen und diese nach dem Empfang aller Fragmente wieder zu einem Datagramm zusammenfügen muss.

Die Reassemblierung auf einem Host wird nicht als Problem angesehen, da der Host über die Zeit- und Speicherressourcen verfügt, um sich dieser Aufgabe zu widmen.

Auf einem Router, dessen Hauptaufgabe es ist, Pakete so schnell wie möglich weiterzuleiten, ist die Reassemblierung allerdings sehr ineffizient.

Ein Router ist nicht dafür ausgelegt, Pakete für längere Zeit zu speichern.

Ein Router, der eine Reassemblierung durchführt, wählt den größten verfügbaren Puffer (18 kB), da er keine Möglichkeit hat, die Größe des ursprünglichen IPv4-Pakets zu ermitteln, bis das letzte Fragment empfangen wird.

Ein weiteres Fragmentierungsproblem betrifft den Umgang mit verloren gegangenen Fragmenten.

Wenn ein Fragment eines IPv4-Datagramms verloren geht, muss das gesamte ursprüngliche IPv4-Datagramm erneut gesendet werden – und wird dazu ebenfalls fragmentiert.

Dies ist beim Network File System (NFS) der Fall. NFS hat eine Lese- und Schreibblockgröße von 8192. 

Daher umfasst ein NFS-IPv4-/UDP-Datagramm etwa 8.500 Byte (einschließlich NFS-, UDP- und IPv4-Headern).

Eine an ein Ethernet angeschlossene Sendestation (MTU 1500) muss das 8.500 Byte große Datagramm in sechs Teile zerlegen: fünf 1.500-Byte-Fragmente und ein 1.000-Byte-Fragment.

Wenn eines der sechs Fragmente aufgrund einer überlasteten Verbindung verloren geht, muss das gesamte ursprüngliche Datagramm erneut übertragen werden. Dies bedeutet, dass sechs weitere Fragmente erstellt werden müssen.

Wenn auf dieser Verbindung jedes sechste Paket verloren geht, ist die Wahrscheinlichkeit gering, dass NFS-Daten darüber übertragen werden, da mindestens ein IPv4-Fragment von jedem ursprünglichen NFS-IPv4-Datagramm mit 8.500 Byte verloren geht.

Firewalls, die Pakete auf Basis von Layer-4- (L4) bis Layer-7- (L7)-Informationen filtern oder bearbeiten, haben Probleme bei der korrekten Verarbeitung von IPv4-Fragmenten.

Wenn die IPv4-Fragmente nicht in der richtigen Reihenfolge ankommen, blockiert eine Firewall die nicht-initialen Fragmente, da sie nicht die Informationen enthalten, die dem Paketfilter entsprechen.

Dies bedeutet, dass das ursprüngliche IPv4-Datagramm vom empfangenden Host nicht reassembliert werden konnte.

Wenn die Firewall so konfiguriert ist, dass nicht-initiale Fragmente mit unzureichenden Informationen dem Filter entsprechen, kann ein Angriff durch die Firewall mithilfe nicht-initialer Fragmente erfolgen.

Netzwerkgeräte (wie Content Switch Engines) leiten Pakete weiter, die auf L4- bis L7-Informationen basieren, und wenn ein Paket mehrere Fragmente umfasst, hat das Gerät Probleme bei der Durchsetzung seiner Richtlinien.

IPv4-Fragmentierung vermeiden: So funktioniert TCP MSS

Über die maximale Segmentgröße (Maximum Segment Size, MSS) des Transmission Control Protocol (TCP) wird die maximale Datenmenge definiert, die pro TCP/IPv4-Datagramm vom Host akzeptiert wird.

Dieses TCP/IPv4-Datagramm kann auf der IPv4-Layer fragmentiert sein. Der MSS-Wert wird als TCP-Kopfzeilenoption übertragen, allerdings nur in TCP SYN-Segmenten.

Die beiden Seiten der TCP-Verbindung geben sich gegenseitig ihren MSS-Wert bekannt. Der MSS-Wert wird nicht zwischen den Hosts ausgehandelt.

Der Ausgangshost muss die Größe der Daten pro TCP-Segment auf einen Wert begrenzen, der dem vom Eingangshost gemeldeten MSS-Wert entspricht oder diesen unterschreitet.

Ursprünglich bezeichnete MSS die Größe des zugewiesenen Puffers (größer oder gleich 65496 Byte) auf einer Empfangsstation, damit die in einem einzigen IPv4-Datagramm enthaltenen TCP-Daten gespeichert werden können.

MSS war die maximale Segmentgröße von Daten, die der TCP-Empfänger akzeptieren konnte. Dieses TCP-Segment konnte bis zu 64 kB groß sein und auf dem IPv4-Layer fragmentiert werden, um an den empfangenden Host übertragen zu werden.

Der empfangende Host setzte dann das IPv4-Datagramm neu zusammen, bevor er das komplette TCP-Segment an den TCP-Layer weiterleitete.

Im Folgenden wird erläutert, wie MSS-Werte festgelegt und verwendet werden, um die Größe von TCP-Segmenten und IPv4-Datagrammen zu begrenzen.

Beispiel 1 veranschaulicht die Art und Weise, wie MSS anfangs implementiert wurde.

Host A hat einen Puffer von 16 kB und Host B einen Puffer von 8 kB. Die Hosts senden und empfangen ihre MSS-Werte und passen ihre Sende-MSS an, um Daten untereinander zu senden.

Host A und Host B müssen die IPv4-Datagramme fragmentieren, die größer als die MTU der Schnittstelle, aber weiterhin kleiner als die Sende-MSS sind, da der TCP-Stack 16 kB oder 8 kB Daten den Stack entlang an IPv4 weiterleitet.

Im Fall von Host B können Pakete fragmentiert werden, einmal, um auf das Token Ring LAN zu gelangen, und dann erneut, um auf das Ethernet-LAN zu gelangen.

Beispiel 1

1. Host A sendet seinen MSS-Wert von 16 kB an Host B.
2. Host B empfängt den 16 kB umfassenden MSS-Wert von Host A.
3. Host B setzt seinen Sende-MSS-Wert auf 16 kB.
4. Host B sendet seinen MSS-Wert von 8 kB an Host A.
5. Host A empfängt den 8 kB umfassenden MSS-Wert von Host B.
6. Host A setzt seinen Sende-MSS-Wert auf 8 kB.

Um eine IPv4-Fragmentierung an den Endpunkten der TCP-Verbindung zu vermeiden, wurde die Auswahl des MSS-Wertes auf die minimale Puffergröße und die MTU der ausgehenden Schnittstelle (-40) geändert.

MSS-Nummern sind 40 Byte kleiner als MTU-Nummern, da MSS (die TCP-Datengröße) den 20 Byte großen IPv4-Header und den 20 Byte großen TCP-Header nicht beinhaltet.

MSS basiert auf Standard-Header-Größen; der Sender-Stack muss die entsprechenden Werte für den IPv4- und den TCP-Header subtrahieren, je nachdem, welche TCP- oder IPv4-Optionen verwendet werden.

Derzeit ist die Funktionsweise von MSS so, dass jeder Host zunächst seine ausgehende Schnittstellen-MTU mit seinem eigenen Puffer vergleicht und den niedrigsten Wert als zu sendende MSS wählt.

Die Hosts vergleichen dann die empfangene MSS-Größe mit ihrer eigenen Schnittstellen-MTU und wählen wiederum den niedrigeren der beiden Werte.

Beispiel 2 veranschaulicht diesen zusätzlichen Schritt des Senders, um eine Fragmentierung auf den kabelgebundenen lokalen und Remote-Netzwerken zu vermeiden.

Die MTU der Ausgangsschnittstelle wird von jedem Host berücksichtigt, bevor sich die Hosts gegenseitig ihre MSS-Werte senden. Dies trägt dazu bei, Fragmentierungen zu vermeiden.

Beispiel 2

1. Host A vergleicht seinen MSS-Puffer (16 kB) und seine MTU (1500 - 40 = 1460) und verwendet den niedrigeren Wert (1460) als MSS zum Senden an Host B.
2. Host B empfängt die Sende-MSS (1460) von Host A und vergleicht sie mit dem Wert seiner Ausgangsschnittstellen-MTU - 40 (4422).
3. Host B legt den kleineren Wert (1460) als MSS fest, um IPv4-Datagramme an Host A zu senden.
4. Host B vergleicht seinen MSS-Puffer (8 kB) und seine MTU (4462 - 40 = 4422) und verwendet 4422 als MSS, um an Host A zu senden.
5. Host A empfängt die Sende-MSS (4422) von Host B und vergleicht sie mit dem Wert seiner Ausgangsschnittstellen-MTU -40 (1460).
6. Host A legt den unteren Wert (1460) als MSS für das Senden von IPv4-Datagrammen an Host B fest.

1460 ist der von beiden Hosts gewählte Wert als Sende-MSS füreinander. Häufig ist der Sende-MSS-Wert an beiden Enden einer TCP-Verbindung gleich.

In Beispiel 2 erfolgt die Fragmentierung nicht an den Endpunkten einer TCP-Verbindung, da beide Ausgangsschnittstellen-MTUs von den Hosts berücksichtigt werden.

Pakete werden im Netzwerk zwischen Router A und Router B dennoch weiterhin fragmentiert, wenn sie auf eine Verbindung mit einer niedrigeren MTU stoßen als die der Ausgangsschnittstelle beider Hosts.

Was ist die PMTUD

Die TCP-MSS ist zuständig für die Fragmentierung an den beiden Endpunkten einer TCP-Verbindung, aber nicht für den Fall, dass sich in der Mitte zwischen diesen beiden Endpunkten eine Verbindung mit einer niedrigeren MTU befindet.

Die PMTUD wurde entwickelt, um eine Fragmentierung im Pfad zwischen den Endpunkten zu vermeiden. Sie wird verwendet, um die niedrigste MTU auf dem Weg von der Quelle eines Pakets bis zum Ziel dynamisch zu bestimmen.

Hinweis: Die PMTUD wird ausschließlich von TCP und UDP unterstützt. aber nicht von anderen Protokollen unterstützt. Wenn die PMTUD auf einem Host aktiviert ist, haben alle TCP- und UDP-Pakete vom Host ein festgelegtes DF-Bit. 

Wenn ein Host ein vollständiges MSS-Datenpaket mit festgelegtem DF-Bit sendet, reduziert die PMTUD den Sende-MSS-Wert für die Verbindung, wenn sie die Information erhält, dass das Paket fragmentiert werden muss.

Ein Host zeichnet den MTU-Wert für ein Ziel auf, da er mit diesem MTU-Wert einen Host-Eintrag (/32) in seiner Routingtabelle erstellt.

Wenn ein Router versucht, ein IPv4-Datagramm (mit festgelegtem DF-Bit) auf eine Verbindung weiterzuleiten, deren MTU kleiner ist als das Paket, verwirft der Router das Paket und sendet eine ICMP-Meldung (Internet Control Message Protocol) „Destination Unreachable“ mit dem Code „fragmentation needed and DF set“ (Typ 3, Code 4) an die Quelle dieses IPv4-Datagramms zurück.

Wenn die Quellstation die ICMP-Meldung empfängt, verringert sie die Sende-MSS, und wenn TCP das Segment erneut sendet, wird die kleinere Segmentgröße verwendet.

Das folgende Beispiel zeigt die ICMP-Meldung "fragmentation needed and DF set", die auf einem Router nach dem Aktivieren des debug ip icmp Befehls angezeigt wird:

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

Dieses Diagramm zeigt das Format des ICMP-Headers einer Meldung „fragmentation needed and DF set“ „Destination Unreachable".

Gemäß RFC 1191 muss ein Router, der eine ICMP-Meldung mit dem Hinweis „fragmentation needed and DF set“ angibt, die MTU dieses Next-Hop-Netzwerks in die unteren 16 Bit des ICMP-Zusatz-Headerfeldes aufnehmen, das in der ICMP-Spezifikation RFC 792 als „unused“ gekennzeichnet ist.

Frühe Implementierungen von RFC 1191 haben die Informationen zur MTU am nächsten Hop nicht geliefert. Selbst wenn diese Informationen geliefert wurden, ignorieren einige Hosts sie.

Für diesen Fall enthält RFC 1191 auch eine Tabelle, die die vorgeschlagenen Werte auflistet, um die die MTU während der PMTUD abgesenkt wird.

Diese Tabelle wird von Hosts verwendet, um schneller zu einem vernünftigen Wert für die Sende-MSS zu gelangen, wie in diesem Beispiel gezeigt.

Die PMTUD wird kontinuierlich auf allen Paketen durchgeführt, da sich der Pfad zwischen Sender und Empfänger dynamisch ändern kann.

Jedes Mal, wenn ein Sender eine ICMP-Meldung „Cannot Fragment“ erhält, aktualisiert er die Routinginformationen (den Ort, an dem er die PMTUD speichert).

Während der PMTUD können zwei Dinge passieren:

1. Das Paket kann bis zum Empfänger gelangen, ohne fragmentiert zu werden.

Hinweis: Damit ein Router die CPU vor DoS-Angriffen schützen kann, reduziert er die Anzahl der „ICMP unerreichbar“-Meldungen, die er senden würde, auf zwei pro Sekunde. Wenn Sie in diesem Kontext ein Netzwerkszenario haben, in dem Sie erwarten, dass der Router mit mehr als zwei ICMP-Nachrichten (Typ = 3, Code = 4) pro Sekunde antworten muss (kann verschiedene Hosts sein), deaktivieren Sie die Drosselung von ICMP-Nachrichten mit dem no ip icmp rate-limit unreachable [df] interface Befehl.

2. Der Sender erhält ICMP-Meldungen mit dem Text „Cannot Fragment“ von jedem beliebigen Hop auf dem Weg zum Empfänger.

Die PMTUD wird unabhängig für beide Richtungen eines TCP-Flows durchgeführt.

Es gibt Fälle, in denen die PMTUD in einer Richtung eines Flows eine der Endstationen veranlasst, die Sende-MSS zu senken, und die andere Endstation die ursprüngliche Sende-MSS beibehält, weil sie nie ein IPv4-Datagramm gesendet hat, das groß genug ist, um die PMTUD auszulösen.

Ein Beispiel ist die HTTP-Verbindung in Beispiel 3. Der TCP-Client sendet kleine und der Server große Pakete.

In diesem Fall lösen nur die großen Pakete des Servers (größer als 576 Byte) die PMTUD aus.

Die Pakete des Clients sind klein (kleiner als 576 Byte) und lösen die PMTUD nicht aus, da sie keine Fragmentierung erfordern, um über die Verbindung mit einer MTU von 576 gesendet zu werden.

Beispiel 3

Beispiel 4 zeigt ein asymmetrisches Routing-Beispiel, bei dem einer der Pfade eine kleinere MTU aufweist als der andere.

Asymmetrisches Routing tritt auf, wenn zum Senden und Empfangen von Daten zwischen zwei Endpunkten verschiedene Pfade verwendet werden.

In diesem Beispiel löst die PMTUD das Absenken der Sende-MSS nur in eine Richtung eines TCP-Flows aus.

Der Datenverkehr vom TCP-Client zum Server fließt über Router A und Router B, während der Datenverkehr vom Server zum Client über Router D und Router C fließt.

Wenn der TCP-Server Pakete an den Client sendet, veranlasst die PMTUD den Server, die Sende-MSS zu senken, da Router D die 4.092-Byte-Pakete fragmentieren muss, bevor er sie an Router C senden kann.

Der Client hingegen wird niemals die ICMP-Meldung „Destination Unreachable“ mit dem Code „fragmentation needed and DF set“ empfangen, da Router A Pakete nicht fragmentieren muss, wenn er sie über Router B an den Server sendet.

Beispiel 4

Hinweis: Der Befehl ip tcp path-mtu-discovery wird verwendet, um die TCP-MTU-Pfaderkennung für TCP-Verbindungen zu aktivieren, die von Routern (z. B. BGP und Telnet) initiiert werden.

Probleme mit der PMTUD

Dies sind Dinge, die die PMTUD beschädigen können.

• Ein Router verwirft ein Paket und sendet keine ICMP-Meldung. (Ungewöhnlich)

• Ein Router erzeugt und sendet eine ICMP-Meldung, die jedoch von einem Router oder einer Firewall zwischen diesem Router und dem Sender blockiert wird. (Häufig)

• Ein Router erzeugt und sendet eine ICMP-Meldung, aber der Sender ignoriert diese. (Ungewöhnlich)

Der erste und der letzte Fall sind in der Regel das Ergebnis eines Fehlers, aber der mittlere Fall beschreibt ein häufiges Problem.

Personen, die ICMP-Paketfilter implementieren, neigen dazu, nicht nur bestimmte, sondern alle ICMP-Meldungstypen zu blockieren.

Ein Paketfilter kann alle ICMP-Meldungstypen blockieren, mit Ausnahme derjenigen, die „unreachable“ (nicht erreichbar) oder „time-exceeded“ (Zeit überschritten) lauten.

Der Erfolg oder Misserfolg der PMTUD hängt davon ab, ob „ICMP unerreichbar“-Meldungen zum Sender eines TCP/IPv4-Pakets gelangen.

„ICMP time-exceeded“-Meldungen sind wichtig für andere IPv4-Probleme.

Ein Beispiel für einen solchen Paketfilter, der auf einem Router implementiert ist, ist hier dargestellt.

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

Es gibt andere Techniken, die verwendet werden können, um das Problem der vollständigen Blockierung von ICMP zu beheben.

• Löschen Sie das DF-Bit auf dem Router und lassen Sie die Fragmentierung zu. (Dies ist jedoch nicht empfehlenswert.) weitere Informationen finden Sie unter Probleme mit der IP-Fragmentierung).

• Bearbeiten Sie den Wert der TCP-MSS-Option mit dem Schnittstellenbefehl ip tcp adjust-mss <500-1460>.

Im nächsten Beispiel befinden sich Router A und Router B in derselben administrativen Domäne. Router C ist nicht erreichbar und blockiert ICMP, sodass die PMTUD unterbrochen wird.

Eine Problemumgehungen für diese Situation ist das Löschen des DF-Bits in beide Richtungen auf Router B, um eine Fragmentierung zu ermöglichen. Dies kann mithilfe von richtlinienbasiertem Routing erfolgen.

Die Syntax zum Löschen des DF-Bits ist in Cisco IOS® Softwareversion 12.1(6) und höher verfügbar.

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

Eine weitere Möglichkeit besteht darin, den Wert der TCP-MSS-Option auf SYN-Paketen zu ändern, die den Router durchlaufen (verfügbar in Cisco IOS® 12.2(4)T und höher).

Dadurch wird der Wert der MSS-Option im TCP-SYN-Paket reduziert, sodass er kleiner ist als der Wert (1460) im ip tcp adjust-mssBefehl.

Das Ergebnis ist, dass der TCP-Sender Segmente sendet, die nicht größer als dieser Wert sind.

Die IPv4-Paketgröße ist 40 Byte größer (1.500) als der MSS-Wert (1.460 Byte), um den TCP-Header (20 Byte) und den IPv4-Header (20 Byte) zu berücksichtigen.

Sie können die MSS von TCP-SYN-Paketen mit dem ip tcp adjust-mss Befehl anpassen. Diese Syntax reduziert den MSS-Wert auf TCP-Segmenten auf 1.460.

Dieser Befehl hat Auswirkungen auf den Eingangs- und Ausgangs-Datenverkehr auf Schnittstelle serial0.

int s0 
ip tcp adjust-mss 1460

IPv4-Fragmentierungsprobleme haben sich seit der zunehmenden Verbreitung von IPv4-Tunneln immer weiter ausgebreitet.

Tunnel verursachen mehr Fragmentierung, weil die Tunnelkapselung die Größe eines Pakets um den sogenannten „Overhead“ erhöht.

Beispielsweise wird durch Hinzufügung von Generic Router Encapsulation (GRE) ein Paket um 24 Byte größer, und nach dieser Vergrößerung muss das Paket fragmentiert werden, da es größer als die MTU für ausgehende Pakete ist.

Häufig vorkommende Netzwerktopologien, die PMTUD benötigen

Die PMTUD wird in Netzwerksituationen benötigt, in denen Zwischenverbindungen kleinere MTUs haben als die MTU der Endverbindungen. Einige häufige Gründe für die Existenz dieser kleineren MTU in Verbindungen sind:

• Via Token Ring (oder FDDI) verbundene Endhosts mit einer Ethernet-Verbindung dazwischen. Die Token Ring (oder FDDI)-MTUs an den Enden sind größer als die Ethernet-MTU in der Mitte.

• PPPoE (oft mit ADSL verwendet) benötigt 8 Byte für seinen Header. Dies reduziert die effektive MTU des Ethernet auf 1492 (1500 - 8).

Tunnelprotokolle wie GRE, IPv4sec und L2TP benötigen ebenfalls Platz für ihre jeweiligen Header und Trailer. Dies reduziert auch die effektive MTU der Ausgangsschnittstelle.

Tunnel

Ein Tunnel ist eine logische Schnittstelle auf einem Cisco Router, die eine Möglichkeit bietet, Passagierpakete innerhalb eines Transportprotokolls zu kapseln.

Es handelt sich um eine Architektur, die darauf ausgelegt ist, Services bereitzustellen, um ein Punkt-zu-Punkt-Kapselungsschema zu implementieren. Tunnelschnittstellen umfassen die folgenden drei Hauptkomponenten:

• Passagierprotokoll (AppleTalk, Banyan VINES, CLNS, DECnet, IPv4 oder IPX)

• Trägerprotokoll – eines der folgenden Kapselprotokolle:

  • GRE – das Multiprotocol-Trägerprotokoll von Cisco. Weitere Informationen finden Sie unter RFC 2784 und RFC 1701.

  • IPv4 in IPv4-Tunneln – weitere Informationen finden Sie unter RFC 2003.

• Transportprotokoll – das Protokoll, das für die Übertragung des Kapselprotokolls verwendet wird.

Die in diesem Abschnitt dargestellten Pakete veranschaulichen die IPv4-Tunneling-Konzepte, wobei GRE das Kapselprotokoll und IPv4 das Transportprotokoll ist.

Das Passagierprotokoll ist ebenfalls IPv4. In diesem Fall ist IPv4 sowohl das Transport- als auch das Passagierprotokoll.

Normales Paket

IPv4

TCP

Telnet

Tunnel-Paket

IPv4

GRE

IPv4

TCP

Telnet

• IPv4 ist das Transportprotokoll.

• GRE ist das Kapselprotokoll.

• IPv4 ist das Passagierprotokoll.

Das nächste Beispiel zeigt die Kapselung von IPv4 und DECnet als Passagierprotokolle mit GRE als Trägerprotokoll.

Dies veranschaulicht die Möglichkeit, dass Trägerprotokolle mehrere Passagierprotokolle kapseln, wie im Bild dargestellt.

Ein Netzwerkadministrator zieht ein Tunneling in einer Situation in Betracht, in der es zwei nicht zusammenhängende Nicht-IPv4-Netzwerke gibt, die durch einen IPv4-Backbone getrennt sind.

Wenn die nicht zusammenhängenden Netzwerke DECnet ausführen, kann sich der Administrator dafür entscheiden, sie miteinander zu verbinden (oder auch nicht), indem er DECnet im Backbone konfiguriert.

Er möchte nicht zulassen, dass das DECnet-Routing Backbone-Bandbreite verbraucht, da dies die Leistung des IPv4-Netzwerks beeinträchtigen könnte.

Eine sinnvolle Alternative ist ein Tunneling von DECnet über den IPv4-Backbone. Die Tunneling-Lösung kapselt die DECnet-Pakete in IPv4 und sendet sie über den Backbone an den Tunnel-Endpunkt, wo die Kapselung entfernt wird und die DECnet-Pakete über DECnet an ihr Ziel weitergeleitet werden.

Die Kapselung des Datenverkehrs innerhalb eines anderen Protokolls bietet folgende Vorteile:

• Die Endpunkte verwenden private Adressen (RFC 1918) und der Backbone unterstützt kein Routing dieser Adressen.

• Ermöglichung virtueller privater Netzwerke (VPNs) über WANs oder das gesamte Internet hinweg.

• Verbindung nicht zusammenhängender Multiprotocol-Netzwerke über einen einzigen Protokoll-Backbone.

• Verschlüsselung des Datenverkehrs über den Backbone oder das Internet.

Für den Rest des Dokuments wird IPv4 als Passagierprotokoll und IPv4 als Transportprotokoll verwendet.

Überlegungen zu Tunnelschnittstellen

Folgende Überlegungen sollten Sie beim Tunneling anstellen.

• Fast Switching von GRE-Tunneln wurde in Cisco IOS® Version 11.1 und CEF Switching in Version 12.0 eingeführt.

• CEF-Switching für Multi-Point-GRE-Tunnel wurde in Version 12.2(8)T eingeführt.

• Kapselung und Entkapselung an Tunnel-Endpunkten waren in früheren Versionen von Cisco IOS®, als nur Prozess-Switching unterstützt wurde, langsame Vorgänge.

• Beim Tunneling von Paketen treten Sicherheits- und Topologieprobleme auf. Tunnel können Zugriffskontrolllisten (ACLs) und Firewalls umgehen.

• Wenn Sie durch eine Firewall tunneln, umgehen Sie das Passagierprotokoll, das Sie tunneln. Daher wird empfohlen, an den Tunnelendpunkten Firewall-Funktionalität zu integrieren, um die Einhaltung der Richtlinien für die Passagierprotokolle durchzusetzen.

• Tunneling führt aufgrund erhöhter Latenzzeiten zu Problemen mit Transportprotokollen mit begrenzten Timern (z. B. DECnet).

• Tunneling über Umgebungen mit unterschiedlichen Geschwindigkeiten, z. B. schnelle FDDI-Ringe und über langsame Telefonleitungen mit 9.600 Bit/s, führt zu Problemen bei der Paketneuordnung. Einige Passagierprotokolle funktionieren in gemischten Netzwerken schlecht.

• Punkt-zu-Punkt-Tunnel belegen Bandbreite in einer physischen Verbindung. Über mehrere Punkt-zu-Punkt-Tunnel hat jede Tunnelschnittstelle eine bestimmte Bandbreite, genau wie die physische Schnittstelle, über die der Tunnel läuft. Stellen Sie beispielsweise die Tunnelbandbreite auf 100 Kb, wenn 100 Tunnel über eine 10-Mbit-Verbindung laufen. Die Standardbandbreite für einen Tunnel beträgt 9 kbit.

• Routing-Protokolle ziehen einen Tunnel einer echten Verbindung vor, weil der Tunnel trügerisch als eine One-Hop-Verbindung mit dem ressourcenschonendsten Pfad erscheinen könnte, obwohl er tatsächlich mehr Hops beinhaltet und somit ressourcenintensiver ist als ein anderer Pfad. Dieses Problem wird durch die richtige Konfiguration des Routing-Protokolls entschärft. Erwägen Sie, ein anderes Routing-Protokoll über die Tunnelschnittstelle auszuführen als das Routing-Protokoll auf der physischen Schnittstelle.

• Probleme mit rekursivem Routing werden vermieden, indem geeignete statische Routen zum Tunnelziel konfiguriert werden. Eine rekursive Route bedeutet, dass der beste Weg zum Tunnelziel durch den Tunnel selbst führt. Diese Situation führt zu einem Auf-und-ab-Bouncing der Tunnelschnittstelle. Dieser Fehler tritt auf, wenn es ein Problem mit dem rekursiven Routing gibt.

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

Router als PMTUD-Teilnehmer am Endpunkt des Tunnels

Der Router hat zwei verschiedene PMTUD-Rollen, wenn er Endpunkt eines Tunnels ist.

• In der ersten Rolle ist der Router der Forwarder eines Host-Pakets. Für die PMTUD-Verarbeitung muss der Router das DF-Bit und die Paketgröße des ursprünglichen Datenpakets überprüfen und gegebenenfalls entsprechende Maßnahmen ergreifen.

• Die zweite Rolle kommt ins Spiel, nachdem der Router das ursprüngliche IPv4-Paket in das Tunnelpaket gekapselt hat. In dieser Phase verhält sich der Router eher wie ein Host in Bezug auf die PMTUD und das Tunnel-IPv4-Paket.

Wenn der Router in der ersten Rolle handelt (als Router, der Host-IPv4-Pakete weiterleitet), kommt diese Rolle zum Tragen, bevor der Router das Host-IPv4-Paket innerhalb des Tunnelpakets kapselt.

Wenn der Router als Forwarder eines Host-Pakets teilnimmt, führt er folgende Aktionen aus:

• Überprüft, ob das DF-Bit festgelegt ist.

• Überprüft, welche Paketgröße der Tunnel aufnehmen kann.

• Fragmentiert (wenn das Paket zu groß ist und das DF-Bit nicht festgelegt ist), kapselt die Fragmente und sendet sie; oder

• Verwirft das Paket (wenn das Paket zu groß und das DF-Bit festgelegt ist) und sendet eine ICMP-Meldung an den Sender.

• Kapselt (wenn das Paket nicht zu groß ist) und sendet.

Im Allgemeinen besteht die Wahl zwischen Kapselung und dann Fragmentierung (Senden zweier Kapselungsfragmente) oder Fragmentierung und dann Kapselung (Senden zweier gekapselter Fragmente).

In diesem Abschnitt wird anhand von zwei Beispielen die Interaktion von PMTUD und Paketen veranschaulicht, die Beispielnetzwerke durchqueren.

Das erste Beispiel zeigt, was mit einem Paket passiert, wenn der Router (an der Tunnelquelle) als aktiver Router fungiert.

Der Router muss zur Verarbeitung der PMTUD das DF-Bit und die Paketgröße des ursprünglichen Datenpakets überprüfen und entsprechende Maßnahmen ergreifen.

In diesem Beispiel wird die GRE-Kapselung für den Tunnel verwendet. GRE nimmt vor der Verkapselung eine Fragmentierung vor.

Spätere Beispiele zeigen Szenarien, in denen die Fragmentierung nach der Verkapselung erfolgt.

In Beispiel 1 ist das DF-Bit nicht festgelegt (DF = 0) und die IPv4-MTU des GRE-Tunnels ist 1476 (1500 - 24).

Beispiel 1

1. Der aktive Router (an der Tunnelquelle) empfängt vom sendenden Host ein 1500-Byte-Datagramm ohne festgelegtes DF-Bit (DF = 0).

Dieses Datagramm besteht aus einem 20-Byte-IP-Header und einer 1480-Byte-TCP-Nutzlast.

IPv4	1480 Byte TCP + Daten

 2. Da das Paket nach dem Hinzufügen des GRE-Overheads (24 Byte) zu groß für die IPv4-MTU ist, teilt der aktive Route das Datagramm in zwei Fragmente von 1.476 (20 Byte IPv4-Header + 1.456 Byte IPv4-Nutzlast) und 44 Byte (20 Byte IPv4-Header + 24 Byte IPv4-Nutzlast) auf.

Das Paket ist nach dem Hinzufügen der GRE-Kapselung nicht größer als die MTU der physischen Ausgangsschnittstelle.

IP0	1456 Byte TCP + Daten

IP1	24 Byte Daten

 3. Der aktive Route fügt jedem Fragment des ursprünglichen IPv4-Datagramms eine GRE-Kapselung hinzu, die einen 4-Byte-GRE-Header und einen 20-Byte-IPv4-Header enthält.

Diese beiden IPv4-Datagramme haben nun eine Länge von 1500 bzw. 68 Byte und werden als individuelle IPv4-Datagramme und nicht als Fragmente betrachtet.

IPv4

GRE

IP0

1456 Byte TCP + Daten

IPv4

GRE

IP1

24 Byte Daten

4. Der Tunnel-Zielrouter entfernt die GRE-Kapselung von jedem Fragment des ursprünglichen Datagramms, sodass zwei IPv4-Fragmente der Längen 1476 und 24 Byte übrig bleiben.

Diese IPv4-Datagrammfragmente werden von diesem Router separat an den empfangenden Host weitergeleitet.

IP0	1456 Byte TCP + Daten

IP1	24 Byte Daten

5. Der empfangende Host fügt diese beiden Fragmente wieder zum ursprünglichen Datagramm zusammen.

IPv4	1480 Byte TCP + Daten

Beispiel 2 stellt die Rolle des aktiven Routers im Kontext einer Netzwerktopologie dar.

Der Router nimmt wiederum die Rolle des aktiven Routers ein, aber diesmal ist das DF-Bit festgelegt (DF = 1).

Beispiel 2

1. Der aktive Router an der Tunnelquelle empfängt vom sendenden Host ein 1500 Byte großes Datagramm mit DF = 1.

IPv4	1480 Byte TCP + Daten

2. Da das DF-Bit festgelegt ist und die Datagrammgröße (1.500 Byte) größer ist als die IPv4-MTU des GRE-Tunnels (1.476), verwirft der Router das Datagramm und sendet die Meldung „ICMP fragmentation needed but DF bit set“ an die Quelle des Datagramms.

Die ICMP-Meldung warnt den Sender, dass die MTU eine Größe von 1.476 Byte hat.

IPv4	ICMP MTU 1476

3. Der sendende Host empfängt die ICMP-Meldung, und wenn er die Originaldaten erneut sendet, verwendet er ein 1476-Byte-IPv4-Datagramm.

IPv4	1456 Byte TCP + Daten

4. Diese IPv4-Datagrammlänge (1476 Byte) ist nun gleich dem Wert der IPv4-MTU des GRE-Tunnels, sodass der Router die GRE-Kapselung zum IPv4-Datagramm hinzufügt.

IPv4

GRE

IPv4

1456 Byte TCP + Daten

5. Der empfangende Router (am Tunnelziel) entfernt die GRE-Kapselung des IPv4-Datagramms und sendet es an den empfangenden Host.

IPv4	1456 Byte TCP + Daten

Dies geschieht, wenn der Router in der zweiten Rolle als sendender Host in Bezug auf die PMTUD und das Tunnel-IPv4-Paket fungiert.

Diese Rolle kommt ins Spiel, nachdem der Router das ursprüngliche IPv4-Paket in das Tunnelpaket gekapselt hat.

Hinweis: Standardmäßig führt ein Router keine PMTUD auf den von ihm erzeugten GRE-Tunnelpaketen aus. Der tunnel path-mtu-discovery Befehl kann verwendet werden, um die PMTUD für GRE-IPv4-Tunnelpakete zu aktivieren.

Beispiel 3 zeigt, was passiert, wenn der Host IPv4-Datagramme sendet, deren Größe unterhalb der IPv4-MTU auf der GRE-Tunnelschnittstelle liegt.

Das DF-Bit kann in diesem Fall entweder festgelegt oder nicht festgelegt (1 oder 0) sein.

Auf der GRE-Tunnelschnittstelle ist der tunnel path-mtu-discovery Befehl nicht konfiguriert, sodass der Router keine PMTUD auf dem GRE-IPv4-Paket abbricht.

Beispiel 3

1. Der aktive Router an der Tunnelquelle empfängt ein 1476 Byte großes Datagramm vom sendenden Host.

IPv4	1456 Byte TCP + Daten

2. Dieser Router kapselt das 1476-Byte-IPv4-Datagramm innerhalb von GRE, sodass ein 1500-Byte-GRE-IPv4-Datagramm entsteht.

Das DF-Bit im GRE-IPv4-Header ist nicht festgelegt (DF = 0). Dieser Router leitet dieses Paket dann an das Tunnelziel weiter.

IPv4

GRE

IPv4

1456 Byte TCP + Daten

3. Angenommen, es gibt einen Router zwischen Tunnelquelle und -ziel mit einer Verbindungs-MTU von 1400.

Dieser Router fragmentiert das Tunnelpaket, da das DF-Bit nicht festgelegt ist (DF = 0).

Denken Sie daran, dass dieses Beispiel das äußerste IPv4 fragmentiert, sodass die GRE-, inneren IPv4- und TCP-Header nur im ersten Fragment erscheinen.

IP0

GRE

IP

1352 Byte TCP + Daten

IP1	104 Byte Daten

4. Der Tunnel-Zielrouter muss das GRE-Tunnelpaket reassemblieren.

IP

GRE

IP

1456 Byte TCP + Daten

5. Nachdem das GRE-Tunnelpaket reassembliert wurde, entfernt der Router den GRE-IPv4-Header und sendet das ursprüngliche IPv4-Datagramm auf den Weg.

IPv4	1456 Byte TCP + Daten

Beispiel 4 zeigt, was passiert, wenn der Router in Bezug auf die PMTUD und das Tunnel-IPv4-Paket in der Rolle eines sendenden Hosts agiert.

Diesmal ist das DF-Bit im ursprünglichen IPv4-Header festgelegt (DF = 1), und der tunnel path-mtu-discovery Befehl wurde so konfiguriert, dass das DF-Bit vom inneren IPv4-Header in den äußeren (GRE + IPv4)-Header kopiert wird.

Beispiel 4

1. Der aktive Router an der Tunnelquelle empfängt vom sendenden Host ein 1476 Byte großes Datagramm mit DF = 1.

IPv4	1456 Byte TCP + Daten

2. Dieser Router kapselt das 1476-Byte-IPv4-Datagramm innerhalb von GRE, sodass ein 1500-Byte-GRE-IPv4-Datagramm entsteht.

Bei diesem GRE-IPv4-Header ist das DF-Bit festgelegt (DF = 1), da das DF Bit beim ursprünglichen IPv4-Datagramm ebenfalls festgelegt war.

Dieser Router leitet dieses Paket dann an das Tunnelziel weiter.

IPv4

GRE

IPv4

1456 Byte TCP

3. Nehmen wir erneut an, es gibt einen Router zwischen Tunnelquelle und -ziel mit einer Verbindungs-MTU von 1400.

Dieser Router fragmentiert das Tunnelpaket nicht, da das DF-Bit festgelegt ist (DF = 1).

Dieser Router muss das Paket verwerfen und eine ICMP-Fehlermeldung an den Tunnel-Quellrouter senden, da dies die Quell-IPv4-Adresse auf dem Paket ist.

IPv4	ICMP MTU 1400

4. Der Forwarding-Router an der Tunnelquelle erhält diese „ICMP“-Fehlermeldung und senkt die IPv4-MTU des GRE-Tunnels auf 1.376 (1.400 - 24).

Wenn der sendende Host die Daten in einem 1.476-Byte-IPv4-Paket erneut sendet, kann dieses Paket zu groß sein und dieser Router sendet dann eine „ICMP“-Fehlermeldung mit einem MTU-Wert von 1.376 an den Sender.

Wenn der sendende Host die Daten erneut sendet, sendet er sie in einem 1.376-Byte-IPv4-Paket, das somit ohne Probleme durch den GRE-Tunnel zum empfangenden Host gelangt.

Beispiel 5

Dieses Beispiel veranschaulicht die GRE-Fragmentierung. Führen Sie die Fragmentierung vor der Kapselung für GRE durch; anschließend erfolgt die PMTUD für das Datenpaket, und das DF-Bit wird nicht kopiert, wenn das IPv4-Paket durch die GRE gekapselt wird.

Das DF-Bit ist nicht festgelegt. Die IPv4-MTU der GRE-Tunnelschnittstelle ist standardmäßig 24 Byte kleiner als die IPv4-MTU der physischen Schnittstelle. Somit beträgt die IPv4-MTU der GRE-Schnittstelle 1476, wie im Bild gezeigt.

1. Der Sender sendet ein 1500-Byte-Paket (20 Byte IPv4-Header + 1480 Byte TCP-Nutzlast).
2. Da die MTU des GRE-Tunnels 1.476 ist, wird das 1.500-Byte-Paket in zwei IPv4-Fragmente von 1.476 und 44 Byte zerlegt, jeweils im Vorgriff auf die zusätzlichen 24 Byte des GRE-Headers.
3. Die 24 Byte des GRE-Headers werden zu jedem IPv4-Fragment hinzugefügt. Nun beträgt die Fragmentgröße 1500 (1476 + 24) und 68 (44 + 24) Byte.
4. Die GRE + IPv4-Pakete, die die beiden IPv4-Fragmente enthalten, werden an den GRE-Tunnel-Peer-Router weitergeleitet.
5. Der GRE-Tunnel-Peer-Router entfernt die GRE-Header aus den beiden Paketen.
6. Dieser Router leitet die beiden Pakete an den Zielhost weiter.
7. Der Zielhost reassembliert die IPv4-Fragmente wieder zum ursprünglichen IPv4-Datagramm.

Beispiel 6

Dieses Beispiel ähnelt Beispiel 5, aber diesmal ist das DF-Bit festgelegt. Der Router ist so konfiguriert, dass er mit dem tunnel path-mtu-discoveryBefehl PMTUD auf GRE + IPv4-Tunnelpaketen durchführt, und das DF-Bit wird vom ursprünglichen IPv4-Header in den GRE-IPv4-Header kopiert.

Wenn der Router einen ICMP-Fehler für das GRE + IPv4-Paket erhält, reduziert er die IPv4-MTU auf der GRE-Tunnelschnittstelle.

Die IPv4-MTU des GRE-Tunnels ist standardmäßig auf 24 Byte weniger eingestellt ist als die MTU der physischen Schnittstelle, sodass die IPv4-MTU für die GRE hier 1.476 beträgt. Im GRE-Tunnelpfad gibt es eine Verbindung mit einer MTU von 1.400, wie im Bild dargestellt.

1. Der Router empfängt ein 1500-Byte-Paket (20 Byte IPv4-Header + 1480 Byte TCP-Nutzlast) und verwirft dieses Paket. Dies liegt daran, dass es größer ist als die IPv4-MTU auf der GRE-Tunnelschnittstelle (1476).
2. Der Router sendet einen ICMP-Fehler an den Sender und teilt ihm mit, dass die Next-Hop-MTU 1476 beträgt. Der Host zeichnet diese Informationen auf, in der Regel als Hostroute für das Ziel in seiner Routingtabelle.
3. Der sendende Host verwendet beim erneuten Senden der Daten eine Paketgröße von 1476 Byte. Der GRE-Router fügt 24 Byte GRE-Kapselung hinzu und sendet ein 1500-Byte-Paket.
4. Das 1500-Byte-Paket kann die 1400-Byte-Verbindung nicht durchlaufen, sodass es vom Zwischenrouter verworfen wird.
5. Der Zwischenrouter sendet ein ICMP (Typ = 3, Code = 4) mit einer Next-Hop-MTU von 1400 an den GRE-Router. Der GRE-Router reduziert dies auf 1376 (1400 - 24) und legt einen internen IPv4-MTU-Wert auf der GRE-Schnittstelle fest. Diese Änderung ist nur sichtbar, wenn Sie den debug tunnel Befehl verwenden. Sie wird nicht in der Ausgabe des show ip interface tunnel<#> Befehls angezeigt.
6. Wenn der Host das 1.476-Byte-Paket das nächste Mal sendet, verwirft der GRE-Router das Paket, da es größer ist als die aktuelle IPv4-MTU (1.376) auf der GRE-Tunnelschnittstelle.
7. Der GRE-Router sendet ein weiteres ICMP (Typ = 3, Code = 4) mit einer Next-Hop-MTU von 1.376 an den Sender und der Host aktualisiert seine aktuellen Informationen mit einem neuen Wert.
8. Der Host sendet die Daten erneut, aber jetzt in einem kleineren 1.376-Byte-Paket. Die GRE fügt 24 Byte Kapselung hinzu und leitet das Paket weiter. Diesmal schafft es das Paket zum GRE-Tunnel-Peer, wo das Paket entkapselt und an den Zielhost gesendet wird.

Hinweis: Wenn in diesem Szenario der tunnel path-mtu-discovery Befehl nicht auf dem weiterleitenden Router konfiguriert wurde und das DF-Bit in den über den GRE-Tunnel weitergeleiteten Paketen festgelegt wurde, ist es Host 1 weiterhin möglich, TCP/IPv4-Pakete an Host 2 zu senden, sie werden jedoch in der Mitte an der Verbindung mit einer MTU von 1400 fragmentiert. Auch der GRE-Tunnel-Peer muss sie wieder reassemblieren, bevor er sie entkapseln und weiterleiten kann.

Reiner IPsec-Tunnel-Modus

Das IPv4 Security (IPv4sec)-Protokoll ist eine standardbasierte Methode, die Datenschutz, Integrität und Authentizität für Informationen bietet, die über IPv4-Netzwerke übertragen werden.

IPv4sec bietet IPv4-Verschlüsselung auf Netzwerkebene. IPv4sec verlängert das IPv4-Paket durch Hinzufügen von mindestens einem IPv4-Header (Tunnelmodus).

Die hinzugefügten Header variieren in Abhängigkeit vom IPv4sec-Konfigurationsmodus in der Länge, überschreiten aber nicht ~58 Byte (Encapsulating Security Payload (ESP) und ESP authentication (ESPauth)) pro Paket.

IPv4sec kennt zwei Betriebsmodi: Tunnelmodus und Transportmodus.

1. Der Standardmodus ist der Tunnelmodus. Im Tunnelmodus ist das gesamte ursprüngliche IPv4-Paket geschützt (verschlüsselt, authentifiziert oder beides) und durch die IPv4sec-Header und -Trailer gekapselt. Dann wird dem Paket ein neuer IPv4-Header vorangestellt, der die IPv4sec-Endpunkte (Peers) als Quelle und Ziel angibt. Der Tunnelmodus kann mit jedem Unicast-IPv4-Datenverkehr verwendet werden und muss verwendet werden, wenn IPv4sec den Datenverkehr von Hosts hinter den IPv4sec-Peers schützt. Der Tunnelmodus wird beispielsweise bei virtuellen privaten Netzwerken (VPNs) verwendet, bei denen Hosts in einem geschützten Netzwerk Pakete über ein Paar von IPv4sec-Peers an Hosts in einem anderen geschützten Netzwerk senden. Bei VPNs schützt der IPv4sec-„Tunnel“ den IPv4-Datenverkehr zwischen Hosts, indem er ihn zwischen den IPv4sec-Peer-Routern verschlüsselt.
2. Im Transportmodus (konfiguriert mit dem Unterbefehl, mode transport, in der Transformationsdefinition) wird nur die Nutzlast des ursprünglichen IPv4-Pakets geschützt (verschlüsselt, authentifiziert oder beides). Die Nutzlast wird durch IPv4sec-Header und -Trailer gekapselt. Die ursprünglichen IPv4-Header bleiben intakt, mit der Ausnahme, dass das IPv4-Protokollfeld auf ESP (50) geändert wird und der ursprüngliche Protokollwert im IPv4sec-Trailer gespeichert und bei der Entschlüsselung des Pakets wiederhergestellt wird. Der Transportmodus wird nur verwendet, wenn der zu schützende IPv4-Verkehr zwischen den IPv4sec-Peers selbst stattfindet. Die Quell- und Ziel-IPv4-Adressen auf dem Paket sind identisch mit den IPv4sec-Peer-Adressen. Normalerweise wird der IPv4sec-Transportmodus nur verwendet, wenn ein anderes Tunneling-Protokoll (wie GRE) verwendet wird, um zuerst das IPv4-Datenpaket zu kapseln, und anschließend IPv4sec zum Schutz der GRE-Tunnelpakete verwendet wird.

IPv4sec führt für Datenpakete und seine eigenen Pakete immer eine PMTUD durch. Es gibt IPv4sec-Konfigurationsbefehle, um die PMTUD-Verarbeitung für das IPv4sec-IPv4-Paket zu modifizieren. IPv4sec kann das DF-Bit im IPv4-Header des Datenpakets löschen, festlegen oder in den IPv4sec-IPv4-Header kopieren. Dies wird als „DF Bit Override Functionality“ bezeichnet.

Hinweis: Wenn Sie eine Hardwareverschlüsselung mit IPv4sec durchführen, sollten Sie die Fragmentierung nach der Kapselung vermeiden. Mit Hardwareverschlüsselung erzielen Sie einen Durchsatz von ca. 50 Mbit/s. Der genaue Wert hängt von der Hardware ab, aber wenn das IPv4sec-Paket fragmentiert ist, verlieren Sie 50 bis 90 Prozent des Durchsatzes. Dieser Verlust entsteht, weil die fragmentierten IPv4sec-Pakete zur Reassemblierung per Prozess-Switching weitergeleitet und dann zur Entschlüsselung an das Hardware-Verschlüsselungsmodul übergeben werden. Durch diesen Verlust kann der Durchsatz der Hardwareverschlüsselung auf das Leistungsniveau der Softwareverschlüsselung (2–10 Mbit pro Sekunde) sinken.

Beispiel 7

Dieses Szenario stellt die IPv4sec-Fragmentierung in Aktion dar. In diesem Szenario beträgt die MTU auf dem gesamten Pfad 1500. In diesem Szenario ist das DF-Bit nicht festgelegt.

1. Der Router empfängt ein 1500-Byte-Paket (20 Byte IPv4-Header + 1480 Byte TCP-Nutzlast), das für Host 2 bestimmt ist.
2. Das 1500-Byte-Paket ist mit IPv4sec verschlüsselt und es werden 52 Byte Overhead hinzugefügt (IPv4sec-Header, -Trailer und zusätzlicher IPv4-Header). Jetzt muss IPv4sec ein 1552-Byte-Paket senden. Da die MTU für ausgehende Pakete 1.500 ist, muss dieses Paket fragmentiert werden.
3. Aus dem IPv4sec-Paket werden zwei Fragmente erstellt. Während der Fragmentierung wird ein zusätzlicher 20-Byte-IPv4-Header für das zweite Fragment hinzugefügt, was zu einem 1.500-Byte-Fragment und einem 72-Byte-IPv4-Fragment führt.
4. Der IPv4sec-Tunnel-Peer-Router empfängt die Fragmente, entfernt den zusätzlichen IPv4-Header und reassembliert die IPv4-Fragmente wieder zu dem ursprünglichen IPv4sec-Paket. Dann entschlüsselt IPv4sec dieses Paket.
5. Der Router leitet dann das ursprüngliche 1500-Byte-Datenpaket an Host 2 weiter.

Beispiel 8

Dieses Beispiel ähnelt Beispiel 6, nur dass in diesem Fall das DF-Bit im ursprünglichen Datenpaket festgelegt ist und es eine Verbindung im Pfad zwischen den IPv4sec-Tunnel-Peers gibt, die eine niedrigere MTU als die anderen Verbindungen hat.

Dieses Beispiel zeigt, wie der IPv4sec-Peer-Router beide PMTUD-Rollen ausführt, wie im Abschnitt Der Router als PMTUD-Teilnehmer am Endpunkt eines Tunnels beschrieben.

Die IPv4sec-PMTU ändert sich aufgrund der notwendigen Fragmentierung in einen niedrigeren Wert.

Das DF-Bit wird vom inneren IPv4-Header in den äußeren IPv4-Header kopiert, wenn IPv4sec ein Paket verschlüsselt.

Die MTU- und PMTU-Werte der Medien werden in der IPv4sec Security Association (SA) gespeichert.

Die MTU des Mediums basiert auf der MTU der Router-Ausgangsschnittstelle und die PMTU auf der kleinsten MTU im Pfad zwischen den IPv4sec-Peers.

IPv4sec kapselt und verschlüsselt das Paket, bevor es versucht, es zu fragmentieren, wie im Bild dargestellt.

1. Der Router empfängt ein 1.500-Byte-Paket und verwirft es, da das Paket durch Hinzufügen des IPv4sec-Overheads größer wird als die PMTU (1.500).
2. Der Router sendet eine ICMP-Meldung an Host 1 und teilt ihm mit, dass die Next-Hop-MTU 1442 (1500 - 58 = 1442) beträgt. Diese 58 Byte sind der maximale IPv4sec-Overhead bei Verwendung von IPv4sec ESP und ESPauth. Der tatsächliche IPv4sec-Overhead kann bis zu 7 Byte kleiner als dieser Wert sein. Host 1 zeichnet diese Informationen, in der Regel als Hostroute für das Ziel (Host 2), in seiner Routingtabelle auf.
3. Host 1 senkt seine PMTU für Host 2 auf 1.442, sodass Host 1 kleinere Pakete (1.442 Byte) sendet, wenn er die Daten erneut an Host 2 übermittelt. Der Router empfängt das 1442-Byte-Paket und IPv4sec fügt 52 Byte Verschlüsselungs-Overhead hinzu, sodass das resultierende IPv4sec-Paket 1496 Byte groß ist. Da im Header dieses Pakets das DF-Bit festgelegt ist, wird es vom mittleren Router, dessen Verbindungs-MTU 1400 Byte beträgt, verworfen.
4. Der mittlere Router, der das Paket verworfen hat, sendet eine ICMP-Meldung an den Sender des IPv4sec-Pakets (den ersten Router) und teilt ihm mit, dass die Next-Hop-MTU 1400 Byte beträgt. Dieser Wert wird in der IPv4sec-SA-PMTU aufgezeichnet.
5. Wenn Host 1 das 1.442-Byte-Paket das nächste Mal sendet (er hat keine Bestätigung dafür erhalten), verwirft IPv4sec das Paket. Der Router verwirft das Paket, da es durch Hinzufügen des IPv4sec-Overheads größer wird als die PMTU (1.400).
6. Der Router sendet eine ICMP-Meldung an Host 1 und teilt ihm mit, dass die Next-Hop-MTU nun 1342 beträgt. (1400 - 58 = 1342). Host 1 zeichnet diese Informationen erneut auf.
7. Wenn Host 1 die Daten erneut sendet, verwendet er das kleinere Paket (1.342). Dieses Paket erfordert keine Fragmentierung und kann durch den IPv4sec-Tunnel an Host 2 übertragen werden.

GRE und IPv4sec zusammen

Komplexere Interaktionen für Fragmentierung und PMTUD treten auf, wenn IPv4sec zur Verschlüsselung von GRE-Tunneln verwendet wird.

IPv4sec und GRE werden auf diese Weise kombiniert, da IPv4sec keine IPv4-Multicast-Pakete unterstützt, was bedeutet, dass Sie kein dynamisches Routing-Protokoll über das IPv4sec-VPN-Netzwerk ausführen können.

GRE-Tunnel unterstützen Multicast, sodass ein GRE-Tunnel verwendet werden kann, um zunächst das Multicast-Paket des dynamische Routing-Protokolls in einem GRE-IPv4-Unicast-Paket zu kapseln, das dann durch IPv4sec verschlüsselt werden kann.

Dabei wird IPv4sec oft im Transportmodus aufsetzen und auf GRE bereitgestellt, da die IPv4sec-Peers und die GRE-Tunnelendpunkte (die Router) identisch sind und der Transportmodus 20 Byte an IPv4sec-Overhead einspart.

Ein interessanter Fall tritt auf, wenn ein IPv4-Paket in zwei Fragmente aufgeteilt und durch GRE gekapselt wurde.

In diesem Fall sieht IPv4sec zwei unabhängige GRE + IPv4-Pakete. Häufig ist eines dieser Pakete in einer Standardkonfiguration so groß, dass es nach der Verschlüsselung fragmentiert werden muss.

Der IPv4sec-Peer muss dieses Paket vor der Entschlüsselung reassemblieren. Diese „doppelte Fragmentierung“ (einmal vor GRE und einmal nach IPv4sec) auf dem sendenden Router erhöht die Latenz und senkt den Durchsatz.

Die Reassemblierung erfolgt durch Prozess-Switching, sodass es auf dem empfangenden Router immer, wenn dies geschieht, zu einer hohen CPU-Auslastung kommt.

Diese Situation kann vermieden werden, indem „ip mtu“ auf der GRE-Tunnelschnittstelle so niedrig eingestellt wird, dass es den Overhead von GRE und IPv4sec berücksichtigt (standardmäßig ist „ip mtu“ auf der GRE-Tunnelschnittstelle auf die tatsächliche Overhead-Byte-Zahl der Ausgangsschnittstelle MTU – GRE eingestellt).

Die folgende Tabelle listet die vorgeschlagenen MTU-Werte für jede Tunnel-/Modus-Kombination auf, vorausgesetzt, die physische Ausgangsschnittstelle hat eine MTU von 1.500.

Tunnel-Kombination	Erforderliche spezifische MTU	Empfohlene MTU
GRE + IPv4sec (Transportmodus)	1440 Byte	1400 Byte
GRE + IPv4sec (Tunnelmodus)	1420 Byte	1400 Byte

Hinweis: Der MTU-Wert von 1.400 wird empfohlen, da er die gängigsten GRE + IPv4sec-Moduskombinationen abdeckt. Auch gibt es keinen erkennbaren Nachteil, wenn ein zusätzlicher Overhead von 20 oder 40 Byte zugelassen wird. Es ist einfacher, einen Wert einzustellen, der fast alle Szenarien abdeckt, und sich diesen zu merken.

Beispiel 9

IPv4sec wird aufsetzend auf GRE bereitgestellt. Die MTU der physischen Ausgangsschnittstelle beträgt 1500, die IPv4sec-PMTU beträgt 1500 und die GRE-IPv4-MTU beträgt 1476 (1500 - 24 = 1476).

Aus diesem Grund werden TCP/IPv4-Pakete zweimal fragmentiert, einmal vor der GRE und einmal nach IPv4sec.

Das Paket wird vor der GRE-Kapselung fragmentiert, und eines dieser GRE-Pakete wird nach der IPv4sec-Verschlüsselung erneut fragmentiert.

Die Konfiguration von „ip mtu 1440“ (IPv4sec-Transportmodus) oder „ip mtu 1420“ (IPv4sec-Tunnelmodus) im GRE-Tunnel würde in diesem Szenario die Möglichkeit einer doppelten Fragmentierung ausschließen.

1. Der Router empfängt ein 1500 Byte großes Datagramm.
2. Vor der Kapselung fragmentiert GRE das 1500-Byte-Paket in zwei Teile, eines mit 1476 Byte (1500 - 24 = 1476) und eines mit 44 Byte (24 Byte Daten + 20 Byte IPv4-Header).
3. GRE kapselt die IPv4-Fragmente, wodurch 24 Byte zu jedem Paket hinzugefügt werden. Daraus ergeben sich zwei GRE + IPv4sec-Pakete mit 1500 (1476 + 24 = 1500) und 68 (44 + 24) Byte.
4. IPv4sec verschlüsselt die beiden Pakete und fügt 52 Byte (IPv4sec-Tunnelmodus) Kapselungs-Overhead zu jedem hinzu, sodass Pakete mit 1.552 Byte und 120 Byte entstehen.
5. Das 1552 Byte große IPv4sec-Paket wird vom Router fragmentiert, da es größer ist als die MTU der Ausgangsschnittstelle (1500). Das 1552-Byte-Paket wird aufgeteilt in ein 1500-Byte-Paket und ein 72-Byte-Paket (52 Byte Nutzlast plus ein zusätzlicher 20-Byte-IPv4-Header für das zweite Fragment). Die drei Pakete mit 1500 Byte, 72 Byte und 120 Byte werden an den IPv4sec + GRE-Peer weitergeleitet.
6. Der empfangende Router reassembliert die beiden IPv4sec-Fragmente (1500 Byte und 72 Byte), um das ursprüngliche 1552-Byte-IPv4sec + GRE-Paket zu erzeugen. Das 120-Byte IPv4sec + GRE-Paket muss nicht verändert werden.
7. IPv4sec entschlüsselt sowohl das 1552-Byte- als auch das 120-Byte-IPv4sec + GRE-Paket, sodass zwei GRE-Pakete mit 1500 Byte und 68 Byte entstehen.
8. GRE entkapselt das 1500-Byte- und das 68-Byte-GRE-Paket, sodass zwei IPv4-Paketfragmente mit 1476 Byte und 44 Byte entstehen. Diese IPv4-Paketfragmente werden an den Ziel-Host weitergeleitet.
9. Host 2 reassembliert diese IPv4-Fragmente, sodass wieder das ursprüngliche 1500 Byte große IPv4-Datagramm erzeugt wird.

Szenario 10 ist ähnlich wie Szenario 8, außer dass es eine untere MTU-Verbindung im Tunnelpfad gibt. Dies ist ein Worst-Case-Szenario für das erste Paket, das von Host 1 an Host 2 gesendet wird. Nach dem letzten Schritt in diesem Szenario stellt Host 1 die richtige PMTU für Host 2 ein, sodass für die TCP-Verbindungen zwischen Host 1 und Host 2 alles korrekt ist. TCP-Flows zwischen Host 1 und anderen Hosts (erreichbar über den IPv4sec + GRE-Tunnel) müssen nur die letzten drei Schritte von Szenario 10 durchlaufen.

In diesem Szenario wird der tunnel path-mtu-discovery Befehl im GRE-Tunnel konfiguriert, und das DF-Bit wird auf TCP/IPv4-Paketen festgelegt, die von Host 1 stammen.

Beispiel 10

• Der Router empfängt ein 1500-Byte-Paket. Dieses Paket wird von der GRE verworfen, weil die GRE das Paket aufgrund des festgelegten DF-Bits nicht fragmentieren oder weiterleiten kann und die Paketgröße die „ip mtu“ der Ausgangsschnittstelle überschreitet, nachdem der GRE-Overhead (24 Byte) hinzugefügt wurde.
• Der Router sendet eine ICMP-Meldung an Host 1, um ihm mitzuteilen, dass die Next-Hop-MTU 1476 (1500 - 24 = 1476) beträgt.
• Host 1 ändert seine PMTU für Host 2 auf 1476 und sendet die kleinere Größe, wenn er das Paket erneut sendet. Die GRE kapselt es und übergibt das 1500-Byte-Paket an IPv4sec. IPv4sec verwirft das Paket, weil die GRE das (festgelegte) DF-Bit aus dem inneren IPv4-Header kopiert hat, und mit dem IPv4sec-Overhead (maximal 38 Byte) ist das Paket zu groß, um über die physische Schnittstelle weitergeleitet zu werden.
• IPv4sec sendet eine ICMP-Meldung an die GRE, die anzeigt, dass die Next-Hop-MTU 1.462 Byte beträgt (da maximal 38 Byte für Verschlüsselung und IPv4-Overhead hinzugefügt werden). Die GRE zeichnet den Wert 1438 (1462 - 24) als „ip mtu“ an der Tunnelschnittstelle auf.
• Hinweis: Diese Wertänderung wird intern gespeichert und ist in der Ausgabe des show ip interface tunnel<#>Befehls nicht sichtbar. Sie sehen diese Änderung nur, wenn Sie den debug tunnel Befehl verwenden.
• Wenn Host 1 das 1476-Byte-Paket das nächste Mal sendet, wird es von der GRE verworfen.
• Der Router sendet eine ICMP-Meldung an Host 1, die anzeigt, dass die Next-Hop-MTU 1438 beträgt.
• Host 1 senkt die PMTU für Host 2 und sendet ein 1438 Byte großes Paket erneut. Diesmal akzeptiert die GRE das Paket, kapselt es und leitet es zur Verschlüsselung an IPv4sec weiter.
• Das IPv4sec-Paket wird an den Zwischenrouter weitergeleitet und verworfen, da die MTU der Ausgangsschnittstelle 1400 beträgt.
• Der Zwischenrouter sendet eine ICMP-Meldung an IPv4sec, dass die Next-Hop-MTU 1400 beträgt. Dieser Wert wird von IPv4sec im PMTU-Wert der zugehörigen IPv4sec-SA aufgezeichnet.
• Wenn Host 1 das 1438-Byte-Paket erneut sendet, kapselt die GRE es und übergibt es an IPv4sec. IPv4sec verwirft das Paket, weil es seine eigene PMTU auf 1400 geändert hat.
• IPv4sec sendet einen ICMP-Fehler an die GRE, der anzeigt, dass die Next-Hop-MTU 1362 beträgt, und die GRE zeichnet intern den Wert 1338 auf.
• Wenn Host 1 das ursprüngliche Paket erneut sendet (weil eher keine Bestätigung erhalten hat), wird es von der GRE verworfen.
• Der Router sendet eine ICMP-Meldung an Host 1, die anzeigt, dass die Next-Hop-MTU 1338 (1362 - 24 Byte) beträgt. Host 1 senkt seine PMTU für Host 2 auf 1338.
• Host 1 sendet ein 1338-Byte-Paket erneut und kann diesmal endlich bis zum Host 2 durchdringen.

Weitere Empfehlungen

Die Konfiguration des tunnel path-mtu-discovery Befehls auf einer Tunnelschnittstelle kann die GRE- und IPv4sec-Interaktion erleichtern, wenn sie auf demselben Router konfiguriert sind.

Ohne den tunnel path-mtu-discovery konfigurierten Befehl würde das DF-Bit im GRE-IPv4-Header immer gelöscht.

Dies ermöglicht die Fragmentierung des GRE-IPv4-Pakets, obwohl im gekapselten Daten-IPv4-Header das DF-Bit festgelegt war, was normalerweise eine Fragmentierung des Pakets nicht zulassen würde.

Wenn der tunnel path-mtu-discovery Befehl auf der GRE-Tunnelschnittstelle konfiguriert ist:

1. Die GRE kopiert das DF-Bit aus dem Daten-IPv4-Header in den GRE-IPv4-Header.
2. Wenn das DF-Bit im GRE-IPv4-Header festgelegt und das Paket nach der IPv4sec-Verschlüsselung „zu groß“ für die IPv4-MTU auf der physischen Ausgangsschnittstelle ist, verwirft IPv4sec das Paket und benachrichtigt den GRE-Tunnel, damit seine IPv4-MTU-Größe reduziert wird.
3. IPv4sec führt die PMTUD für seine eigenen Pakete aus. Wenn sich die IPv4sec-PMTU ändert (wenn sie reduziert wird), benachrichtigt IPv4sec allerdings nicht sofort die GRE, aber wenn ein anderes größeres Paket ankommt, läuft der Prozess in Schritt 2 ab.
4. Die IPv4-MTU der GRE ist jetzt kleiner, sodass sie alle Daten-IPv4-Pakete mit festgelegtem DF-Bit, die jetzt zu groß sind, verwirft und eine ICMP-Meldung an den sendenden Host sendet.

Mit diesem tunnel path-mtu-discovery Befehl kann die GRE-Schnittstelle ihre IPv4-MTU nicht statisch, sondern dynamisch mit dem ip mtu Befehl festlegen. Es wird empfohlen, dass beide Befehle verwendet werden.

Der ip mtu Befehl dient dazu, Platz für den GRE- und IPv4sec-Overhead in Bezug auf die IPv4-MTU der lokalen physischen Ausgangsschnittstelle zu schaffen.

Mit dem tunnel path-mtu-discovery Befehl kann die IPv4-MTU des GRE-Tunnels weiter reduziert werden, wenn im Pfad zwischen den IPv4sec-Peers eine Verbindung mit einer niedrigeren IPv4-MTU vorhanden ist.

Folgendes können Sie tun, wenn Sie Probleme mit der PMTUD in einem Netzwerk haben, in dem GRE + IPv4sec-Tunnel konfiguriert sind.

Diese Liste beginnt mit der wünschenswertesten Lösung.

1. Beheben Sie das Problem, dass PMTUD nicht funktioniert, was normalerweise durch einen Router oder eine Firewall verursacht wird, der bzw. die ICMP blockiert.
2. Verwenden Sie den ip tcp adjust-mss Befehl an den Tunnelschnittstellen, damit der Router den TCP-MSS-Wert im TCP-SYN-Paket reduziert. Dadurch können die beiden Endhosts (der TCP-Sender und -Empfänger) ausreichend kleine Pakete verwenden, dass keine PMTUD benötigt wird.
3. Verwenden Sie richtlinienbasiertes Routing auf der Eingangsschnittstelle des Routers und konfigurieren Sie eine Routenübersicht, um das DF-Bit im IPv4-Header der Daten zu löschen, bevor das Paket zur GRE-Tunnelschnittstelle gelangt. Dadurch kann das Daten-IPv4-Paket vor der GRE-Kapselung fragmentiert werden.
4. Erhöhen Sie die „ip mtu“ auf der GRE-Tunnelschnittstelle auf den MTU-Wert der Ausgangsschnittstelle. Dadurch kann das Daten-IPv4-Paket GRE-gekapselt werden, ohne dass es zuvor fragmentiert werden muss. Das GRE-Paket wird dann IPv4sec-verschlüsselt und anschließend fragmentiert, sodass es über die physische Ausgangsschnittstelle übertragen werden kann. In diesem Fall würden Sie auf der GRE-Tunnelschnittstelle keinen tunnel path-mtu-discovery Befehl konfigurieren. Dies kann den Durchsatz drastisch reduzieren, da die Reassemblierung von IPv4-Paketen auf dem IPv4sec-Peer im Prozess-Switching-Modus erfolgt.

Zugehörige Informationen

• IP Routing-Support-Seite
• IPSec (IP Security Protocol)-Support-Seite
• RFC 1191: MTU-Pfaderkennung
• RFC 1063 Optionen für die IP-MTU-Erkennung
• RFC 791 Internetprotokoll
• RFC 793 Transmission Control Protocol
• RFC 879 Maximale TCP-Segmentgröße und verwandte Themen
• RFC 1701 Generic Routing Encapsulation (GRE)
• RFC 1241 Ein Schema für ein Internet-Kapselungsprotokoll
• RFC 2003 IP-Kapselung innerhalb von IP
• Technischer Support und Dokumentation für Cisco Systeme