Lösung von Problemen mit IPv4-
Fragmentierung, MTU, MSS und PMTUD mit GRE und IPsec
Inhalt
Einführung
IPv4-Fragmentierung und -Reassemblierung Probleme mit der IPv4-Fragmentierung
IPv4-Fragmentierung vermeiden: Funktionsweise und Funktionsweise von TCP MSS Szenario 1
Szenario 2
Was ist die PMTUD?
Szenario 3 Szenario 4
Probleme mit der PMTUD
Häufige Netzwerktopologien, die PMTUD benötigen Tunnel
Überlegungen zu Tunnelschnittstellen
Router als PMTUD-Teilnehmer am Endpunkt des Tunnels Szenario 5
Szenario 6
Reiner IPsec-Tunnelmodus Szenario 7
Szenario 8
GRE und IPv4sec zusammen Szenario 9
Szenario 10
Weitere Empfehlungen Zugehörige Informationen
Einführung
In diesem Dokument wird beschrieben, wie IPv4-Fragmentierung und Path Maximum Transmission Unit Discovery (PMTUD) funktionieren. Außerdem werden einige Szenarien erläutert, die das Verhalten der PMTUD in Kombination mit verschiedenen Kombinationen von IPv4-Tunneln betreffen. Die derzeit weit verbreitete Nutzung von IPv4-Tunneln im Internet hat die Probleme, die mit der IPv4-Fragmentierung und der PMTUD einhergehen, in den Vordergrund gerückt.
IPv4-Fragmentierung und -Reassemblierung
Das IPv4-Protokoll wurde für die Verwendung auf einer Vielzahl von Übertragungsverbindungen
entwickelt. Obwohl die maximale Länge eines IPv4-Datagramms 65535 beträgt, erzwingen die meisten Übertragungsverbindungen eine kleinere maximale Paketlänge, die MTU genannt wird.
Der Wert der MTU hängt von der Art der Übertragungsverbindung ab. Das Design von IPv4 berücksichtigt MTU-Unterschiede, da Router IPv4-Datagramme nach Bedarf fragmentieren können. Die Empfangsstation ist für die Reassemblierung der Fragmente zurück zum ursprünglichen IPv4-Datagramm voller Größe verantwortlich.
Bei der IPv4-Fragmentierung wird ein Datagramm in mehrere Teile zerlegt, die später wieder zusammengesetzt werden können. Die Felder IPv4-Quelle, Ziel, Identifikation, Gesamtlänge und Fragment-Offset sowie die Flags "more fragments" und "don't fragment" 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 Identifizierung beträgt 16 Bit und ist ein Wert, der vom Absender eines IPv4-Datagramms zugewiesen wird, um die Reassemblierung der Fragmente eines Datagramms zu erleichtern.
Der Fragment-Offset beträgt 13 Bit und gibt an, wo ein Fragment zum ursprünglichen IPv4- Datagramm gehört. Dieser Wert ist ein Vielfaches von acht Byte.
Im Flags-Feld des IPv4-Headers befinden sich drei Bits für Steuerelementflags. Es ist wichtig zu beachten, dass das DF-Bit (don't fragment) eine zentrale Rolle in der PMTUD spielt, da es bestimmt, ob ein Paket fragmentiert werden darf oder nicht.
Bit 0 ist reserviert und immer auf 0 eingestellt. Bit 1 ist das DF-Bit (0 = "may fragment", 1 = "do not fragment"). 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 Nicht anwenden Mehr
Die nächste Grafik zeigt ein Beispiel für Fragmentierung. Wenn Sie alle Längen der IPv4-
Fragmente addieren, überschreitet der Wert die ursprüngliche IPv4-Datagrammlänge um 60. Die Gesamtlänge wird um 60 erhöht, weil drei zusätzliche IPv4-Header erstellt wurden, einer für jedes Fragment nach dem ersten Fragment.
Das erste Fragment hat einen Offset von 0, die Länge dieses Fragments beträgt 1500; Dies umfasst 20 Byte für den geringfügig geänderten ursprünglichen IPv4-Header.
Das zweite Fragment hat einen Offset von 185 (185 x 8 = 1480), was bedeutet, dass der Datenanteil dieses Fragments 1480 Byte in das ursprüngliche IPv4-Datagramm einsetzt. Die Länge dieses Fragments beträgt 1500; Dazu gehört auch der zusätzliche IPv4-Header, der für dieses Fragment erstellt wurde.
Das dritte Fragment hat einen Offset von 370 (370 x 8 = 2960), was bedeutet, dass der Datenteil dieses Fragments 2960 Byte in das ursprüngliche IPv4-Datagramm beginnt. Die Länge dieses Fragments beträgt 1500; Dazu gehört auch der zusätzliche 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 440 Byte in das ursprüngliche IPv4-Datagramm einspeist. Die Länge dieses Fragments beträgt 700 Byte. Dazu gehört auch der zusätzliche 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) gibt einen Datenversatz von 440 Byte in das ursprüngliche IPv4-Datagramm zurück. Wenn Sie dann die Datenbytes aus dem letzten Fragment (680 = 700 - 20) hinzufügen, erhalten Sie 5120 Byte, das ist der Datenanteil des ursprünglichen IPv4-Datagramms. Dann entspricht das Hinzufügen von 20 Byte für einen IPv4-Header der Größe des ursprünglichen IPv4-Datagramms (4440 + 680 + 20 = 5140), wie in den Bildern gezeigt.
Probleme mit der IPv4-Fragmentierung
Es gibt mehrere Probleme, die eine IPv4-Fragmentierung unerwünscht machen. Der CPU- und Speicher-Overhead erhöht sich geringfügig, um ein IPv4-Datagramm fragmentieren zu können.
Dies gilt sowohl für den Sender als auch für einen Router im Pfad zwischen einem Sender und einem Empfänger. Beim Erstellen von Fragmenten werden Fragment-Header erstellt und das ursprüngliche Datagramm in die Fragmente kopiert. Dies kann relativ effizient erfolgen, da alle Informationen, die zur Erstellung der Fragmente benötigt werden, sofort verfügbar sind.
Die Fragmentierung verursacht beim erneuten Zusammensetzen der Fragmente einen höheren Overhead für den Empfänger, da der Empfänger den Speicher für die ankommenden Fragmente zuweisen und sie nach dem Empfang aller Fragmente wieder in einem Datagramm
zusammenfassen 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.
Die Reassemblierung auf einem Router ist jedoch sehr ineffizient, dessen Hauptaufgabe darin besteht, Pakete so schnell wie möglich weiterzuleiten. Ein Router ist nicht dafür konzipiert, Pakete über einen bestimmten Zeitraum zu speichern. Außerdem wählt ein Router, der eine
Reassemblierung durchführt, den größten verfügbaren Puffer (18 K) aus, mit dem er arbeiten kann, da er die Größe des ursprünglichen IPv4-Pakets nicht kennt, bis das letzte Fragment empfangen wird.
Ein weiteres Fragmentierungsproblem betrifft die Behandlung verworfener Fragmente. Wenn ein Fragment eines IPv4-Datagramms verworfen wird, muss das gesamte ursprüngliche IPv4- Datagramm erneut gesendet und auch fragmentiert werden. Ein Beispiel hierfür ist das Network File System (NFS). NFS hat standardmäßig eine Lese- und Schreibblockgröße von 8.192, sodass ein NFS-IPv4-/UDP-Datagramm ungefähr 8.500 Byte beträgt (einschließlich NFS-, UDP- und IPv4-Header). Eine an ein Ethernet angeschlossene Sendestation (MTU 1500) muss das 8500- Byte-Datagramm in sechs Teile zerlegen. fünf 1500-Byte-Fragmente und ein 1100-Byte-Fragment.
Wenn eines der sechs Fragmente aufgrund einer überlasteten Verbindung verworfen wird, muss das gesamte ursprüngliche Datagramm erneut übertragen werden, d. h. es müssen sechs weitere Fragmente erstellt werden. Wenn bei dieser Verbindung eines von sechs Paketen verworfen wird, ist die Wahrscheinlichkeit gering, dass NFS-Daten über diese Verbindung übertragen werden können, da mindestens ein IPv4-Fragment aus jedem ursprünglichen IPv4-Datagramm mit NFS 8500 Byte gelöscht würde.
Firewalls, die Pakete auf Basis von Layer-4- (L4) bis Layer-7- (L7)-Informationen im Paket filtern oder bearbeiten, können Probleme bei der korrekten Verarbeitung von IPv4-Fragmenten haben.
Wenn die IPv4-Fragmente außer Betrieb sind, kann eine Firewall die nicht-initialen Fragmente blockieren, da sie nicht die Informationen enthalten, die mit dem Paketfilter übereinstimmen. Das würde bedeuten, dass das ursprüngliche IPv4-Datagramm nicht vom empfangenden Host
reassembliert werden konnte. Wenn die Firewall so konfiguriert ist, dass nicht-initiale Fragmente mit unzureichenden Informationen den Filtern korrekt entsprechen, kann es zu einem nicht initialen Fragmentangriff durch die Firewall kommen. Außerdem leiten einige Netzwerkgeräte (z.
B. Content Switch Engines) Pakete basierend auf L4- bis L7-Informationen weiter. Wenn ein Paket mehrere Fragmente umfasst, kann das Gerät Probleme bei der Durchsetzung seiner Richtlinien haben.
IPv4-Fragmentierung vermeiden: Funktionsweise und Funktionsweise von TCP MSS
Die maximale TCP-Segmentgröße (MSS) definiert die maximale Datenmenge, die ein Host in
einem einzelnen TCP/IPv4-Datagramm akzeptieren möchte. Dieses TCP/IPv4-Datagramm kann auf der IPv4-Schicht fragmentiert sein. Der MSS-Wert wird als TCP-Header-Option nur in TCP- SYN-Segmenten gesendet. Jede Seite einer TCP-Verbindung meldet der anderen Seite ihren MSS-Wert. Im Gegensatz zur allgemeinen Annahme wird der MSS-Wert nicht zwischen Hosts ausgehandelt. Der sendende Host muss die Datengröße in einem einzelnen TCP-Segment auf einen Wert begrenzen, der kleiner oder gleich der vom empfangenden Host gemeldeten MSS ist.
Ursprünglich bedeutete MSS, wie groß ein Puffer (größer oder gleich 65496 Byte) auf einer Empfangsstation war, um die in einem einzelnen IPv4-Datagramm enthaltenen TCP-Daten speichern zu können. MSS war das maximale Segment (Textbaustein) von Daten, das der TCP- Empfänger akzeptieren wollte. Dieses TCP-Segment kann bis zu 64 KB groß sein (die maximale IPv4-Datagrammgröße) und auf der IPv4-Ebene fragmentiert werden, um über das Netzwerk an den empfangenden Host übertragen zu werden. Der empfangende Host baute das IPv4-
Datagramm neu zusammen, bevor er das gesamte TCP-Segment an die TCP-Schicht übergab.
Im Folgenden sind einige Szenarien aufgeführt, die zeigen, wie MSS-Werte festgelegt und verwendet werden, um TCP-Segmentgrößen und damit IPv4-Datagrammgrößen zu begrenzen.
Szenario 1 zeigt, wie MSS erstmals implementiert wurde. Host A hat einen Puffer von 16 K und Host B einen Puffer von 8 K. Sie senden und empfangen ihre MSS-Werte und passen ihre Sende- MSS an, um Daten untereinander zu senden. Beachten Sie, dass Host A und Host B die IPv4- Datagramme fragmentieren müssen, die größer als die Schnittstellen-MTU, aber immer noch kleiner als die Sende-MSS sind, da der TCP-Stack 16.000 oder 8.000 Byte Daten im Stack an IPv4 weitergeben könnte. Im Fall von Host B könnten Pakete zweimal fragmentiert werden, einmal, um in das Token Ring LAN zu gelangen und wieder in das Ethernet LAN zu gelangen.
Szenario 1
Host A sendet seinen MSS-Wert von 16 K an Host B.
1.
Host B erhält den 16.000-MSS-Wert von Host A.
2.
Host B legt seinen Sende-MSS-Wert auf 16 K fest.
3.
Host B sendet seinen MSS-Wert von 8 K an Host A.
4.
Host A empfängt den 8.000-MSS-Wert von Host B.
5.
Host A legt seinen Sende-MSS-Wert auf 8 K fest.
6.
Um eine IPv4-Fragmentierung an den Endpunkten der TCP-Verbindung zu vermeiden, wurde der MSS-Wert in die minimale Puffergröße und die MTU der ausgehenden Schnittstelle geändert (- 40). MSS-Nummern sind 40 Byte kleiner als MTU-Nummern, da MSS nur die TCP-Datengröße ist, die den 20-Byte-IPv4-Header und den 20-Byte-TCP-Header nicht enthält. Die MSS basiert auf den standardmäßigen Headergrößen. Der Sender-Stack muss die entsprechenden Werte für den IPv4-Header und den TCP-Header abziehen, je nachdem, welche TCP- oder IPv4-Optionen verwendet werden.
Die MSS funktioniert jetzt so, dass jeder Host zunächst seine MTU der ausgehenden Schnittstelle mit seinem eigenen Puffer vergleicht und den niedrigsten Wert als zu sendende MSS auswählt.
Die Hosts vergleichen dann die erhaltene MSS-Größe mit der MTU ihrer eigenen Schnittstelle und wählen erneut die niedrigere der beiden Werte aus.
Szenario 2 veranschaulicht diesen zusätzlichen Schritt des Absenders, um eine Fragmentierung der lokalen und Remote-Kabel zu vermeiden. Beachten Sie, wie die MTU der ausgehenden Schnittstelle von jedem Host berücksichtigt wird (bevor die Hosts einander ihre MSS-Werte senden) und wie dies zur Vermeidung von Fragmentierung beiträgt.
Szenario 2
Host A vergleicht seinen MSS-Puffer (16 KB) und seine MTU (1500 - 40 = 1460) und verwendet den niedrigeren Wert als MSS (1460), um ihn an Host B zu senden.
1.
Host B empfängt die Sende-MSS von Host A (1460) und vergleicht sie mit dem Wert seiner Ausgangsschnittstelle MTU - 40 (4422).
2.
Host B legt den unteren Wert (1460) als MSS fest, um IPv4-Datagramme an Host A zu senden.
3.
Host B vergleicht seinen MSS-Puffer (8 K) und seine MTU (4462-40 = 4422) und verwendet 4422 als MSS, um an Host A zu senden.
4.
Host A empfängt die Sende-MSS von Host B (4422) und vergleicht sie mit dem Wert seiner Ausgangsschnittstelle MTU -40 (1460).
5.
Host A legt den unteren Wert (1460) als MSS für das Senden von IPv4-Datagrammen an 6.
Host B fest.
1460 ist der von beiden Hosts als Sende-MSS für einander ausgewählte Wert. Oft ist der Sende- MSS-Wert an jedem Ende einer TCP-Verbindung gleich.
In Szenario 2 tritt keine Fragmentierung an den Endpunkten einer TCP-Verbindung auf, da beide MTUs der ausgehenden Schnittstelle von den Hosts berücksichtigt werden. Pakete können im Netzwerk zwischen Router A und Router B immer noch fragmentiert werden, wenn sie auf eine Verbindung mit einer niedrigeren MTU stoßen als die der ausgehenden Schnittstellen beider Hosts.
Was ist die PMTUD?
Die TCP-MSS, wie zuvor beschrieben, übernimmt die Fragmentierung an den beiden Endpunkten einer TCP-Verbindung, behandelt jedoch nicht den Fall, dass sich in der Mitte eine kleinere MTU- Verbindung zwischen diesen beiden Endpunkten befindet. Die PMTUD wurde entwickelt, um eine Fragmentierung des Pfads zwischen den Endpunkten zu vermeiden. Sie wird verwendet, um die niedrigste MTU auf dem Pfad von der Quelle eines Pakets zum Ziel dynamisch zu bestimmen.
Hinweis: Die PMTUD wird nur von TCP und UDP unterstützt. Andere Protokolle unterstützen es nicht. Wenn die PMTUD auf einem Host aktiviert ist und dies fast immer der Fall ist, ist das DF-Bit für alle TCP- und UDP-Pakete vom Host festgelegt.
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 er Informationen erhält, dass das Paket fragmentiert werden muss. Ein Host "merkt" sich normalerweise den MTU-Wert für ein Ziel, da er in seiner Routing-Tabelle einen "Host" (/32)-Eintrag mit diesem MTU-Wert erstellt.
Wenn ein Router versucht, ein IPv4-Datagramm mit festgelegtem DF-Bit an eine Verbindung weiterzuleiten, die eine niedrigere MTU als die Paketgröße aufweist, verwirft der Router das Paket und gibt eine ICMP-Meldung (Internet Control Message Protocol) "Destination Unreachable" (Ziel nicht erreichbar) an die Quelle dieses IPv4-Datagramms zurück, wobei der Code "fragmentation needed and DF set" (Typ 3, Code 4) angibt. Wenn die Quellstation die ICMP-Nachricht empfängt, verringert sie die Sende-MSS, und wenn TCP das Segment erneut sendet, wird die kleinere Segmentgröße verwendet.
Hier sehen Sie ein Beispiel für eine ICMP-Meldung "fragmentation needed and DF set", die Sie möglicherweise auf einem Router sehen, nachdem der Befehl debug ip icmp aktiviert wurde:
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 der Angabe "fragmentation needed and DF set" zurückgibt, die MTU dieses Next-Hop-Netzwerks in die unteren 16 Bit des ICMP-zusätzlichen Headerfelds aufnehmen, das in der ICMP-Spezifikation RFC 792 als "unused"
gekennzeichnet ist.
Frühe Implementierungen von RFC 1191 lieferten keine Informationen zur MTU für den nächsten Hop. Selbst wenn diese Informationen bereitgestellt wurden, ignorieren einige Hosts sie. In diesem Fall enthält RFC 1191 auch eine Tabelle mit den vorgeschlagenen Werten, um die die MTU während der PMTUD gesenkt werden soll. Sie wird von Hosts verwendet, um schneller zu einem vernünftigen Wert für die Sende-MSS zu gelangen, wie im Bild gezeigt.
Die PMTUD wird kontinuierlich für alle Pakete durchgeführt, da sich der Pfad zwischen Sender und Empfänger dynamisch ändern kann. Jedes Mal, wenn ein Absender eine ICMP-Meldung
"Can't Fragment" erhält, aktualisiert er die Routing-Informationen (wo die PMTUD gespeichert wird).
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, wird die Anzahl der nicht erreichbaren ICMP-Nachrichten, die er sendet, auf zwei pro Sekunde reduziert. Wenn Sie in diesem Kontext ein Netzwerkszenario haben, in dem Sie erwarten, dass der Router mit mehr als zwei ICMP-Meldungen (Typ = 3, Code = 4) pro Sekunde antworten muss (kann verschiedene Hosts sein), sollten Sie die Drosselung von ICMP-Nachrichten mit dem Befehl no ip icmp rate-limit unreachable [df] interface deaktivieren.
2. Der Absender kann ICMP-Meldungen "Can't Fragment" von jedem (oder jedem) Hop auf dem Pfad zum Empfänger erhalten.
Die PMTUD wird unabhängig für beide Richtungen eines TCP-Datenflusses durchgeführt. Es kann vorkommen, dass die PMTUD in einer Richtung eines Datenflusses eine der Endstationen
veranlasst, die Sende-MSS zu senken, und die andere Endstation die ursprüngliche Sende-MSS behält, da sie nie ein IPv4-Datagramm gesendet hat, das groß genug ist, um die PMTUD
auszulösen.
Ein gutes Beispiel hierfür ist die HTTP-Verbindung, die in Szenario 3 unten dargestellt ist. Der TCP-Client sendet kleine Pakete, und der Server sendet große Pakete. In diesem Fall wird die PMTUD nur von den großen Paketen des Servers (über 576 Byte) ausgelöst. Die Pakete des Clients sind klein (weniger als 576 Byte) und lösen die PMTUD nicht aus, da sie keine
Fragmentierung erfordern, um über die 576-MTU-Verbindung zu gelangen.
Szenario 3
Szenario 4 zeigt ein Beispiel für asymmetrisches Routing, bei dem einer der Pfade eine niedrigere MTU als der andere aufweist. Asymmetrisches Routing tritt auf, wenn verschiedene Pfade zum Senden und Empfangen von Daten zwischen zwei Endpunkten verwendet werden. In diesem Szenario löst die PMTUD die Senkung der Sende-MSS nur in eine Richtung eines TCP-
Datenflusses aus. Der Datenverkehr vom TCP-Client zum Server fließt über Router A und Router B, während der vom Server zum Client zurückgegebene Datenverkehr ü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 4092-Byte-Pakete fragmentieren muss, bevor sie an Router C gesendet werden können.
Der Client hingegen erhält niemals eine ICMP-Meldung "Destination Unreachable" mit dem Code
"fragmentation needed and DF set", da Router A Pakete nicht fragmentieren muss, wenn er sie über Router B an den Server sendet.
Szenario 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
Es gibt drei Dinge, die die PMTUD unterbrechen können. Zwei davon sind ungewöhnlich und eine häufig.
Ein Router kann ein Paket verwerfen und keine ICMP-Meldung senden. (Gelegentlich)
●
Ein Router kann eine ICMP-Nachricht generieren und senden, aber die ICMP-Nachricht wird von einem Router oder einer Firewall zwischen diesem Router und dem Sender blockiert.
(Häufig)
●
Ein Router kann eine ICMP-Nachricht generieren und senden, aber der Absender ignoriert die Nachricht. (Gelegentlich)
●
Der erste und der letzte der drei Aufzählungspunkte hier sind ungewöhnlich und in der Regel das Ergebnis eines Fehlers, aber der mittlere Aufzählungspunkt beschreibt ein gemeinsames Problem.
Personen, die ICMP-Paketfilter implementieren, neigen dazu, alle ICMP-Meldungstypen zu blockieren, anstatt nur bestimmte ICMP-Meldungstypen zu blockieren. Ein Paketfilter kann alle ICMP-Meldungstypen blockieren, mit Ausnahme derjenigen, die "nicht erreichbar" oder
"zeitüberschreitend" sind. Der Erfolg oder Misserfolg der PMTUD hängt davon ab, ob ICMP nicht erreichbare Nachrichten an den Absender eines TCP/IPv4-Pakets gesendet werden. ICMP- Nachrichten mit Zeitüberschreitung sind für andere IPv4-Probleme wichtig. 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 eingesetzt werden können, um das Problem der vollständigen Blockierung von ICMP zu lindern.
Löschen Sie das DF-Bit auf dem Router, und lassen Sie dennoch Fragmentierung zu (dies ist jedoch möglicherweise keine gute Idee. Weitere Informationen finden Sie unter Probleme mit der IP-Fragmentierung).
●
Bearbeiten Sie den Wert für die TCP-MSS-Option mit dem Schnittstellenbefehl ip tcp adjust- mss <500-1460>.
●
Im nächsten Szenario befinden sich Router A und Router B in derselben administrativen Domäne.
Router C ist nicht erreichbar und blockiert ICMP, sodass die PMTUD kaputt ist. Eine Lösung für diese Situation besteht darin, das DF-Bit in beide Richtungen auf Router B zu löschen, um eine Fragmentierung zu ermöglichen. Dies kann über Richtlinien-Routing erfolgen. Die Syntax zum Löschen des DF-Bits ist in der 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 Option besteht darin, den Wert der TCP-MSS-Option für SYN-Pakete zu ändern, die den Router durchlaufen (verfügbar ab Cisco IOS® 12.2(4)T). Dadurch wird der Wert der MSS- Option im TCP-SYN-Paket reduziert, sodass er kleiner ist als der Wert (1460) im Befehl ip tcp adjust-mss. Das Ergebnis ist, dass der TCP-Absender Segmente sendet, die nicht größer als dieser Wert sind. Die IPv4-Paketgröße ist 40 Byte größer (1500) als der MSS-Wert (1460 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 Befehl ip tcp adjust-mss anpassen. Diese Syntax reduziert den MSS-Wert für TCP-Segmente auf 1460. Dieser Befehl wirkt sich sowohl auf den ein- als auch den ausgehenden Datenverkehr der Schnittstelle serial0 aus.
int s0
ip tcp adjust-mss 1460
IPv4-Fragmentierungsprobleme haben sich seit der Verbreitung von IPv4-Tunneln immer weiter verbreitet. Der Grund dafür, dass Tunnel eine größere Fragmentierung verursachen, liegt darin, dass die Tunnelkapselung der Größe eines Pakets "Overhead" hinzufügt. Durch Hinzufügen von Generic Router Encapsulation (GRE) werden einem Paket beispielsweise 24 Byte hinzugefügt.
Nach dieser Erhöhung muss das Paket möglicherweise fragmentiert werden, da es größer als die MTU für ausgehende Verbindungen ist. In einem späteren Abschnitt dieses Dokuments werden Beispiele für Probleme angezeigt, die durch Tunnel und IPv4-Fragmentierung auftreten können.
Häufige Netzwerktopologien, die PMTUD benötigen
Die PMTUD wird in Netzwerksituationen benötigt, in denen Zwischenverbindungen kleinere MTUs als die MTU der Endverbindungen aufweisen. Häufige Gründe für das Vorhandensein dieser kleineren MTU-Verbindungen sind:
Endhosts mit einer Ethernet-Verbindung zwischen den über den Token Ring (oder FDDI) verbundenen Hosts. 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. Dadurch wird die effektive MTU des Ethernet auf 1492 (1500-8) reduziert.
●
Tunneling-Protokolle wie GRE, IPv4sec und L2TP benötigen ebenfalls Platz für ihre jeweiligen Header und Trailer. Dadurch wird auch die effektive MTU der ausgehenden Schnittstelle reduziert.
In den nächsten Abschnitten werden die Auswirkungen der PMTUD untersucht, bei der irgendwo zwischen den beiden End-Hosts ein Tunneling-Protokoll verwendet wird. Von den drei vorherigen Fällen ist dieser Fall der komplexeste und deckt alle Probleme ab, die Sie möglicherweise in den anderen Fällen sehen.
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 zur Bereitstellung von Diensten, um ein Punkt-zu-Punkt-Kapselungsschema zu implementieren. Tunneling besteht aus den folgenden drei Hauptkomponenten:
Passenger-Protokoll (AppleTalk, Banyan VINES, CLNS, DECnet, IPv4 oder IPX)
●
Trägerprotokoll - Eines dieser Kapselungsprotokolle:GRE - Das Multiprotocol Carrier Protocol 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 zum Übertragen des gekapselten Protokolls verwendet wird.
●
Die in diesem Abschnitt gezeigten Pakete veranschaulichen die IPv4-Tunneling-Konzepte, bei denen GRE das Kapselungsprotokoll und IPv4 das Transportprotokoll ist. Das Passagierprotokoll ist auch 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 Kapselungsprotokoll.
●
IPv4 ist das Passagierprotokoll.
●
Das nächste Beispiel zeigt die Kapselung von IPv4 und DECnet als Passagierprotokolle mit GRE als Carrier. Dies zeigt, dass das Carrier-Protokoll mehrere Passagierprotokolle kapseln kann, wie im Bild gezeigt.
Ein Netzwerkadministrator könnte das Tunneling in einer Situation in Betracht ziehen, 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, möchte der
Administrator diese möglicherweise nicht miteinander verbinden, indem er DECnet im Backbone konfiguriert. Der Administrator möchte möglicherweise nicht zulassen, dass DECnet-Routing Backbone-Bandbreite beansprucht, da dies die Leistung des IPv4-Netzwerks beeinträchtigen könnte.
Eine praktikable Alternative ist die Tunnelung von DECnet über den IPv4-Backbone. Tunneling kapselt die DECnet-Pakete in IPv4 und sendet sie über den Backbone an den Tunnel-Endpunkt, an dem die Kapselung entfernt wird und die DECnet-Pakete über DECnet an ihr Ziel weitergeleitet werden können.
Die Kapselung von Datenverkehr innerhalb eines anderen Protokolls bietet folgende Vorteile:
Die Endpunkte verwenden private Adressen (RFC 1918), und der Backbone unterstützt das Routing dieser Adressen nicht.
●
VPNs (Virtual Private Networks) über WANs oder das Internet zulassen.
●
Verbinden Sie nicht zusammenhängende Multiprotokoll-Netzwerke über einen einzigen Protokoll-Backbone.
●
Verschlüsselung des Datenverkehrs über das Backbone oder das Internet
●
Für den Rest des Dokuments wird IPv4 als Passagierprotokoll und IPv4 als Transportprotokoll verwendet.
Überlegungen zu Tunnelschnittstellen
Dies sind Überlegungen beim Tunneling.
Schnelles Switching von GRE-Tunneln wurde in Cisco IOS® Version 11.1 eingeführt, und CEF-Switching in Version 12.0. CEF-Switching für Multipoint-GRE-Tunnel wurde in Version 12.2(8)T eingeführt. Kapselung und Entkapselung an Tunnelendpunkten waren in früheren Versionen von Cisco IOS® bei langsamem Betrieb, als nur Prozess-Switching unterstützt wurde.
●
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 im Grunde die Firewall für jedes Passagierprotokoll, das Sie tunneln. Daher wird empfohlen, Firewall-Funktionen an den Tunnelendpunkten zu integrieren, um Richtlinien für die Passagierprotokolle durchzusetzen.
●
Tunneling kann aufgrund einer erhöhten Latenz Probleme mit Transportprotokollen mit eingeschränkten Timern (z. B. DECnet) verursachen.
●
Tunneling über Umgebungen mit unterschiedlichen Geschwindigkeits-Links, z. B. schnelle FDDI-Ringe und über langsame 9600-Bit-Telefonleitungen, kann zu Problemen bei der Paketumordnung führen. Einige Passagierprotokolle funktionieren in gemischten Mediennetzwerken schlecht.
●
Point-to-Point-Tunnel können die Bandbreite einer physischen Verbindung nutzen. Wenn Sie Routing-Protokolle über mehrere Point-to-Point-Tunnel ausführen, sollten Sie bedenken, dass jede Tunnelschnittstelle über eine Bandbreite verfügt und dass die physische Schnittstelle, über die der Tunnel ausgeführt wird, über eine Bandbreite verfügt. Beispielsweise sollten Sie die Tunnelbandbreite auf 100 KB einstellen, wenn 100 Tunnel über eine 10-MB-Verbindung laufen. Die Standardbandbreite für einen Tunnel beträgt 9 KB.
●
Routingprotokolle bevorzugen einen Tunnel gegenüber einer echten Verbindung, da der Tunnel trügerisch als eine 1-Hop-Verbindung mit dem niedrigsten Pfad erscheinen könnte,
●
obwohl er tatsächlich mehr Hops umfasst und in Wirklichkeit teurer ist als ein anderer Pfad.
Dies kann durch eine ordnungsgemäße Konfiguration des Routing-Protokolls verhindert werden. Möglicherweise sollten Sie ein anderes Routing-Protokoll über die Tunnelschnittstelle verwenden als das Routing-Protokoll, das auf der physischen Schnittstelle ausgeführt wird.
Probleme beim rekursiven Routing können vermieden werden, indem geeignete statische Routen zum Tunnelziel konfiguriert werden. Eine rekursive Route ist, wenn der beste Pfad zum Tunnelziel durch den Tunnel selbst verläuft. Diese Situation führt dazu, dass die
Tunnelschnittstelle hoch- und heruntergefahren wird. Dieser Fehler wird angezeigt, wenn ein rekursives Routing-Problem auftritt.
%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 der 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 bei Bedarf entsprechende Maßnahmen ergreifen.
●
Die zweite Rolle kommt zum Tragen, nachdem der Router das ursprüngliche IPv4-Paket in das Tunnelpaket gekapselt hat. In dieser Phase agiert der Router in Bezug auf die PMTUD und das Tunnel-IPv4-Paket eher wie ein Host.
●
Sehen wir uns nun an, was passiert, wenn der Router in der ersten Rolle agiert - ein Router, der Host-IPv4-Pakete weiterleitet - in Bezug auf die PMTUD. Diese Rolle kommt zum Tragen, bevor der Router das Host-IPv4-Paket in das Tunnelpaket kapselt.
Wenn der Router als Forwarder eines Host-Pakets beteiligt ist, führt er die folgenden Aktionen aus:
Überprüfen, ob das DF-Bit festgelegt ist
●
Überprüfen Sie, welche Paketgröße der Tunnel aufnehmen kann.
●
Fragmentierung (wenn das Paket zu groß und das DF-Bit nicht festgelegt ist), kapselt Fragmente und sendet sie; oder
●
Paket verwerfen (wenn Paket zu groß und DF-Bit festgelegt ist) und ICMP-Nachricht an den Absender senden
●
Kapseln (wenn das Paket nicht zu groß ist) und senden
●
Im Allgemeinen besteht die Wahl zwischen Kapselung und dann Fragmentierung (Senden zweier Kapselungsfragmente) oder Fragmentierung und dann Kapselung (Senden zweier gekapselter Fragmente).
Einige Beispiele, die die Mechanik der IPv4-Paketkapselung und -fragmentierung beschreiben, sowie zwei Szenarien, die die Interaktion von PMTUD und Paketen veranschaulichen, die Beispielnetzwerke durchlaufen, werden in diesem Abschnitt erläutert.
Das erste Beispiel zeigt, was mit einem Paket geschieht, wenn der Router (an der Tunnelquelle) die Rolle des Weiterleitungsrouters übernimmt. Beachten Sie, dass der Router zur Verarbeitung der PMTUD das DF-Bit und die Paketgröße des ursprünglichen Datenpakets überprüfen und die entsprechenden Maßnahmen ergreifen muss. In diesem Beispiel wird die GRE-Kapselung für den Tunnel verwendet. Wie man sehen kann, fragmentiert GRE vor der Kapselung. Spätere Beispiele zeigen Szenarien, in denen die Fragmentierung nach der Kapselung 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 Forwarding-Router (an der Tunnelquelle) empfängt ein 1500-Byte-Datagramm mit dem DF- Bit-Clear (DF = 0) vom sendenden Host. Dieses Datagramm besteht aus einem 20-Byte-IP-
Header plus 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 Forwarding-Router das Datagramm in zwei Fragmente von 1476 (20 Byte IPv4-Header + 1456 Byte IPv4-Nutzlast) und 44 Byte (20 Byte IPv4-Header + 24 Byte IP v4-Nutzlast), sodass das Paket nach Hinzufügen der GRE-Kapselung nicht größer ist als die MTU der ausgehenden physischen Schnittstelle.
IP01456 Byte TCP + Daten IP124 Byte Daten
3. Der Forwarding-Router fügt jedem Fragment des ursprünglichen IPv4-Datagramms GRE- Kapselung hinzu, die einen 4-Byte-GRE-Header sowie einen 20-Byte-IPv4-Header enthält. Diese beiden IPv4-Datagramme haben nun eine Länge von 1500 und 68 Byte, und diese Datagramme werden als einzelne IPv4-Datagramme und nicht als Fragmente betrachtet.
IPv4 GRE IP01456 Byte TCP + Daten IPv4 GRE IP124 Byte Daten
4. Der Tunnel-Ziel-Router entfernt die GRE-Kapselung aus jedem Fragment des ursprünglichen Datagramms, wodurch zwei IPv4-Fragmente mit den Längen 1476 und 24 Byte übrig bleiben.
Diese IPv4-Datagrammfragmente werden von diesem Router separat an den empfangenden Host weitergeleitet.
IP01456 Byte TCP + Daten IP124 Byte Daten
5. Der empfangende Host reassembliert diese beiden Fragmente wieder in das ursprüngliche Datagramm.
IPv4 1480 Byte TCP + Daten
Szenario 5 zeigt die Rolle des Weiterleitungsrouters im Kontext einer Netzwerktopologie.
In diesem Beispiel agiert der Router in der gleichen Rolle wie der Forwarding-Router, aber dieses Mal ist das DF-Bit festgelegt (DF = 1).
Beispiel 2
1. Der Weiterleitungsrouter an der Tunnelquelle empfängt vom sendenden Host ein 1500-Byte- Datagramm mit DF = 1.
IPv4 1480 Byte TCP + Daten
2. Da das DF-Bit festgelegt ist und die Datagrammgröße (1500 Byte) größer als die IPv4-MTU des GRE-Tunnels (1476) ist, verwirft der Router das Datagramm und sendet eine Meldung "ICMP fragmentation needed but DF bit set" an die Quelle des Datagramms. Die ICMP-Meldung benachrichtigt den Absender, dass die MTU 1476 beträgt.
IPv4 ICMP MTU 1476
3. Der sendende Host empfängt die ICMP-Nachricht, und wenn er die ursprünglichen Daten erneut sendet, verwendet er ein 1476-Byte-IPv4-Datagramm.
IPv4 1456 Byte TCP + Daten
4. Diese IPv4-Datagrammlänge (1476 Byte) ist jetzt 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
Jetzt können Sie sehen, was passiert, wenn der Router in der zweiten Rolle als sendender Host in Bezug auf die PMTUD und das Tunnel-IPv4-Paket agiert. Denken Sie daran, dass diese Rolle ins Spiel kommt, nachdem der Router das ursprüngliche IPv4-Paket in das Tunnelpaket gekapselt hat.
Hinweis: Standardmäßig führt ein Router keine PMTUD für die von ihm generierten GRE- Tunnelpakete aus. Mit dem Befehl tunnel path-mtu-discovery kann die PMTUD für GRE- IPv4-Tunnelpakete aktiviert werden.
Beispiel 3 zeigt, was geschieht, wenn der Host IPv4-Datagramme sendet, die klein genug sind, um in die IPv4-MTU der GRE-Tunnel-Schnittstelle zu passen. Das DF-Bit kann in diesem Fall entweder festgelegt oder gelöscht werden (1 oder 0). Für die GRE-Tunnelschnittstelle ist der Befehl tunnel path-mtu-discovery nicht konfiguriert, sodass der Router keine PMTUD auf dem GRE-IPv4-Paket ausführt.
Beispiel 3
1. Der Weiterleitungsrouter an der Tunnelquelle empfängt ein 1476-Byte-Datagramm vom sendenden Host.
IPv4 1456 Byte TCP + Daten
2. Dieser Router kapselt das 1476-Byte-IPv4-Datagramm in GRE, um ein 1500-Byte-GRE-IPv4- Datagramm zu erhalten. Das DF-Bit im GRE-IPv4-Header ist eindeutig (DF = 0). Dieser Router leitet dieses Paket dann an das Tunnelziel weiter.
IPv4 GRE IPv4 1456 Byte TCP + Daten
3. Es wird angenommen, dass zwischen Tunnelquelle und -ziel ein Router mit einer Verbindungs- MTU von 1400 vorhanden ist. Dieser Router fragmentiert das Tunnelpaket, da das DF-Bit klar ist (DF = 0). Denken Sie daran, dass dieses Beispiel die äußerste IPv4 fragmentiert, sodass die GRE-, inneren IPv4- und TCP-Header nur im ersten Fragment angezeigt werden.
IP0GRE IP 1352 Byte TCP + Daten IP1104 Byte Daten
4. Der Tunnel-Zielrouter muss das GRE-Tunnelpaket neu zusammenbauen.
IP GRE IP 1456 Byte TCP + Daten
5. Nach der Reassemblierung des GRE-Tunnelpakets entfernt der Router den GRE-IPv4-Header und sendet das ursprüngliche IPv4-Datagramm auf seinem Weg.
IPv4 1456 Byte TCP + Daten
Das nächste Beispiel zeigt, was geschieht, wenn der Router in Bezug auf die PMTUD und das Tunnel-IPv4-Paket als sendender Host agiert. Dieses Mal wird das DF-Bit im ursprünglichen IPv4- Header festgelegt (DF = 1), und der Befehl tunnel path-mtu-discovery wurde so konfiguriert, dass das DF-Bit vom inneren IPv4-Header in den äußeren (GRE + IPv4)-Header kopiert wird.
Beispiel 4
1. Der Weiterleitungsrouter an der Tunnelquelle empfängt vom sendenden Host ein 1476-Byte- Datagramm mit DF = 1.
IPv4 1456 Byte TCP + Daten
2. Dieser Router kapselt das 1476-Byte-IPv4-Datagramm in GRE, um ein 1500-Byte-GRE-IPv4- Datagramm zu erhalten. Dieser GRE-IPv4-Header hat das DF-Bit-Set (DF = 1), da das DF-Bit für das ursprüngliche IPv4-Datagramm festgelegt wurde. Dieser Router leitet dieses Paket dann an das Tunnelziel weiter.
IPv4 GRE IPv4 1456 Byte TCP
3. Gehen Sie erneut davon aus, dass zwischen Tunnelquelle und -ziel ein Router mit einer
Verbindungs-MTU von 1400 vorhanden ist. 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 1376 (1400 - 24). Wenn der sendende Host die Daten das nächste Mal in einem 1476-Byte-IPv4-Paket erneut sendet, kann dieses Paket zu groß sein, und dieser Router sendet eine "ICMP"-Fehlermeldung mit einem MTU-Wert von 1376 an den Sender.
Wenn der sendende Host die Daten erneut sendet, sendet er sie in einem 1376-Byte-IPv4-Paket, und dieses Paket wird es durch den GRE-Tunnel zum empfangenden Host geleitet.
Szenario 5
In diesem Szenario wird die GRE-Fragmentierung veranschaulicht. Denken Sie daran, dass Sie vor der Kapselung für GRE fragmentieren, dann PMTUD für das Datenpaket durchführen und das DF-Bit nicht kopiert wird, wenn das IPv4-Paket durch GRE gekapselt wird. In diesem Szenario ist das DF-Bit nicht festgelegt. Die IPv4-MTU der GRE-Tunnelschnittstelle ist standardmäßig um 24 Byte kleiner als die IPv4-MTU der physischen Schnittstelle. Daher beträgt die IPv4-MTU der GRE- Schnittstelle, wie im Bild gezeigt, 1476.
Der Absender sendet ein 1500-Byte-Paket (20 Byte IPv4-Header + 1480 Byte TCP-Nutzlast).
1.
Da die MTU des GRE-Tunnels 1476 beträgt, wird das 1500-Byte-Paket in zwei IPv4- Fragmente von 1476 und 44 Byte aufgeteilt, jeweils in Erwartung der zusätzlichen 24 Byte des GRE-Headers.
2.
Die 24 Byte GRE-Header werden jedem IPv4-Fragment hinzugefügt. Jetzt sind die Fragmente 1500 (1476 + 24) und 68 (44 + 24) Byte.
3.
Die GRE + IPv4-Pakete, die die beiden IPv4-Fragmente enthalten, werden an den GRE- Tunnel-Peer-Router weitergeleitet.
4.
Der GRE-Tunnel-Peer-Router entfernt die GRE-Header aus den beiden Paketen.
5.
Dieser Router leitet die beiden Pakete an den Ziel-Host weiter.
6.
Der Zielhost reassembliert die IPv4-Fragmente wieder zurück zum ursprünglichen IPv4- Datagramm.
7.
Szenario 6
Dieses Szenario ähnelt Szenario 5, aber dieses Mal ist das DF-Bit festgelegt. In Szenario 6 ist der Router so konfiguriert, dass er die PMTUD auf GRE + IPv4-Tunnelpaketen mithilfe des Befehls tunnel path-mtu-discovery 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
empfängt, reduziert er die IPv4-MTU auf der GRE-Tunnelschnittstelle. Denken Sie auch hier daran, dass die IPv4-MTU des GRE-Tunnels standardmäßig auf 24 Byte kleiner als die MTU der physischen Schnittstelle festgelegt ist, sodass die IPv4-MTU der GRE hier 1476 beträgt. Beachten
Sie auch, dass sich eine 1400-MTU-Verbindung im GRE-Tunnelpfad befindet, wie im Bild gezeigt.
Der Router empfängt ein 1500-Byte-Paket (20 Byte IPv4-Header + 1480 TCP-Nutzlast) und verwirft das Paket. Der Router verwirft das Paket, da es größer ist als die IPv4-MTU (1476) auf der GRE-Tunnelschnittstelle.
1.
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 Routing-Tabelle.
2.
Der sendende Host verwendet eine Paketgröße von 1476 Byte, wenn er die Daten erneut sendet. Der GRE-Router fügt 24 Byte GRE-Kapselung hinzu und sendet ein 1500-Byte- Paket.
3.
Das 1500-Byte-Paket kann die 1400-Byte-Verbindung nicht passieren, daher wird es vom Zwischenrouter verworfen.
4.
Der Zwischenrouter sendet einen ICMP (Typ = 3, Code = 4) mit einer Next-Hop-MTU von 1400 an den GRE-Router. Der GRE-Router reduziert diesen Wert auf 1376 (1400 - 24) und legt einen internen IPv4-MTU-Wert für die GRE-Schnittstelle fest. Diese Änderung ist nur bei Verwendung des Befehls debug tunnel sichtbar. in der Ausgabe des Befehls show ip
interface tunnel<#> nicht sichtbar.
5.
Wenn der Host das 1476-Byte-Paket das nächste Mal erneut sendet, verwirft der GRE- Router das Paket, da es größer ist als die aktuelle IPv4-MTU (1376) auf der GRE- Tunnelschnittstelle.
6.
Der GRE-Router sendet einen weiteren ICMP (Typ = 3, Code = 4) mit einer Next-Hop-MTU von 1376 an den Sender, und der Host aktualisiert seine aktuellen Informationen mit einem neuen Wert.
7.
Der Host sendet die Daten erneut, aber jetzt in einem kleineren 1376-Byte-Paket fügt die GRE 24 Byte Kapselung hinzu und leitet sie weiter. Dieses Mal wird das Paket an den GRE- 8.
Tunnel-Peer gesendet, wo das Paket entkapselt und an den Ziel-Host gesendet wird.
Hinweis: Wenn der Befehl tunnel path-mtu-discovery in diesem Szenario nicht auf dem Weiterleitungsrouter konfiguriert und das DF-Bit in den Paketen festgelegt wurde, die über den GRE-Tunnel weitergeleitet werden, würde Host 1 weiterhin TCP/IPv4-Pakete an Host 2 senden, aber sie würden in der Mitte an der 1400-MTU-Verbindung fragmentiert werden.
Auch der GRE-Tunnel-Peer müsste sie neu zusammenbauen, bevor er sie entkapseln und weiterleiten kann.
Reiner IPsec-Tunnelmodus
Das IPv4 Security Protocol (IPv4sec) ist eine standardbasierte Methode, die Datenschutz, Integrität und Authentizität für Informationen bereitstellt, die über IPv4-Netzwerke übertragen werden. IPv4sec bietet IPv4-Verschlüsselung auf Netzwerkebene. IPv4sec verlängert das IPv4- Paket, indem mindestens ein IPv4-Header (Tunnelmodus) hinzugefügt wird. Die hinzugefügten Header variieren in Abhängigkeit vom IPv4sec-Konfigurationsmodus, überschreiten jedoch nicht
~58 Byte (Encapsulating Security Payload (ESP) and ESP Authentication (ESPauth)) pro Paket.
IPv4sec verfügt über zwei Modi: Tunnelmodus und Transportmodus.
Der Tunnelmodus ist der Standardmodus. Im Tunnelmodus ist das gesamte ursprüngliche IPv4-Paket geschützt (verschlüsselt, authentifiziert oder beides) und von den IPv4sec- Headern und -Trailern gekapselt. Anschließend wird dem Paket ein neuer IPv4-Header vorangestellt, der die IPv4sec-Endpunkte (Peers) als Quelle und Ziel angibt. Der
Tunnelmodus kann für jeden 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 VPNs (Virtual Private Networks)
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 diesen Datenverkehr zwischen den IPv4sec-Peer-Routern verschlüsselt.
1.
Im Transportmodus (konfiguriert mit dem Unterbefehl Modus Transport in der
Transformationsdefinition) ist nur die Nutzlast des ursprünglichen IPv4-Pakets geschützt (verschlüsselt, authentifiziert oder beides). Die Nutzlast wird durch die IPv4sec-Header und - Trailer gekapselt. Die ursprünglichen IPv4-Header bleiben intakt, mit der Ausnahme, dass das IPv4-Protokollfeld als ESP (50) geändert wird und der ursprüngliche Protokollwert im IPv4sec-Trailer gespeichert wird, um wiederhergestellt zu werden, wenn das Paket
entschlüsselt wird. Der Transportmodus wird nur verwendet, wenn sich der zu schützende IPv4-Datenverkehr zwischen den IPv4sec-Peers selbst befindet, die Quell- und Ziel-IPv4- Adressen im Paket mit den IPv4sec-Peer-Adressen identisch sind. Normalerweise wird der IPv4sec-Transportmodus nur verwendet, wenn ein anderes Tunneling-Protokoll (wie GRE) verwendet wird, um zuerst das IPv4-Datenpaket zu kapseln. Anschließend wird IPv4sec zum Schutz der GRE-Tunnelpakete verwendet.
2.
IPv4sec führt die PMTUD immer für Datenpakete und für eigene Pakete durch. Es gibt IPv4sec- Konfigurationsbefehle, um die PMTUD-Verarbeitung für das IPv4sec-IPv4-Paket zu ändern.
IPv4sec kann das DF-Bit vom IPv4-Header des Datenpakets löschen, festlegen oder in den IPv4sec-IPv4-Header kopieren. Dies wird als "DF Bit Override Function" bezeichnet.
Hinweis: Sie möchten die Fragmentierung nach der Kapselung wirklich vermeiden, wenn Sie eine Hardwareverschlüsselung mit IPv4sec durchführen. Die Hardwareverschlüsselung ermöglicht einen Durchsatz von etwa 50 Mbit/s, je nach Hardware. Wenn das IPv4sec-Paket fragmentiert ist, verlieren Sie jedoch 50 bis 90 % des Durchsatzes. Dieser Verlust liegt daran, dass die fragmentierten IPv4sec-Pakete zur Reassemblierung weitergeleitet und dann zur Entschlüsselung an das Hardware-Verschlüsselungs-Engine übergeben werden.
Dieser Verlust des Durchsatzes kann dazu führen, dass der Durchsatz bei der
Hardwareverschlüsselung auf das Leistungsniveau der Softwareverschlüsselung (2-10 Mbit/s) absinkt.
Szenario 7
Dieses Szenario zeigt die IPv4sec-Fragmentierung in Aktion. In diesem Szenario beträgt die MTU auf dem gesamten Pfad 1500. In diesem Szenario ist das DF-Bit nicht festgelegt.
Der Router empfängt ein 1500-Byte-Paket (20-Byte-IPv4-Header + 1480 Byte TCP-Nutzlast), das für Host 2 bestimmt ist.
1.
Das 1500-Byte-Paket wird 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 Anrufe 1.500 beträgt, muss dieses Paket fragmentiert werden.
2.
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 1500-Byte-Fragment und einem 72-Byte-IPv4-Fragment führt.
3.
Der IPv4sec-Tunnel-Peer-Router empfängt die Fragmente, entfernt den zusätzlichen IPv4- Header und leitet die IPv4-Fragmente wieder in das ursprüngliche IPv4sec-Paket ein.
4.
Anschließend entschlüsselt IPv4sec dieses Paket.
Der Router leitet dann das ursprüngliche 1500-Byte-Datenpaket an Host 2 weiter.
5.
Szenario 8
Dieses Szenario ähnelt Szenario 6, mit der Ausnahme, dass in diesem Fall das DF-Bit im
ursprünglichen Datenpaket festgelegt ist und es eine Verbindung im Pfad zwischen den IPv4sec- TunnelPeers gibt, die eine niedrigere MTU als die anderen Verbindungen hat. Dieses Szenario zeigt, wie der IPv4sec-Peer-Router beide PMTUD-Rollen ausführt, wie im Abschnitt Der Router als PMTUD-Teilnehmer am Endpunkt eines Tunnels beschrieben.
In diesem Szenario sehen Sie, wie sich die IPv4sec-PMTU aufgrund der erforderlichen Fragmentierung auf einen niedrigeren Wert ändert. Denken Sie daran, dass das DF-Bit vom inneren IPv4-Header in den äußeren IPv4-Header kopiert wird, wenn IPv4sec ein Paket
verschlüsselt. Die MTU- und PMTU-Medienwerte werden in der IPv4sec Security Association (SA) gespeichert. Die Medien-MTU basiert auf der MTU der ausgehenden Router-Schnittstelle, und die PMTU basiert auf der minimalen MTU, die im Pfad zwischen den IPv4sec-Peers zu beobachten ist. Denken Sie daran, dass IPv4sec das Paket kapselt/verschlüsselt, bevor es versucht, es wie im Bild gezeigt zu fragmentieren.
Der Router empfängt ein 1500-Byte-Paket und verwirft es, da der hinzugefügte IPv4sec- Overhead das Paket größer macht als die PMTU (1500).
1.
Der Router sendet eine ICMP-Meldung an Host 1 und teilt ihm mit, dass die Next-Hop-MTU 1442 beträgt (1500 - 58 = 1442). Diese 58 Byte stellen den maximalen IPv4sec-Overhead bei Verwendung von IPv4sec ESP und ESPauth dar. Der tatsächliche IPv4sec-Overhead kann bis zu 7 Byte unter diesem Wert liegen. Host 1 zeichnet diese Informationen in seiner Routing-Tabelle auf, in der Regel als Host-Route für das Ziel (Host 2).
2.
3. Host 1 senkt seine PMTU für Host 2 auf 1442, sodass Host 1 kleinere Pakete (1442 Byte) sendet, wenn er die Daten erneut an Host 2 überträgt. Der Router empfängt das 1442-Byte- 3.
Paket, und IPv4sec fügt 52 Byte Verschlüsselungs-Overhead hinzu, sodass das
resultierende IPv4sec-Paket 1496 Byte beträgt. Da für dieses Paket das DF-Bit im Header festgelegt ist, wird es vom mittleren Router mit der 1400-Byte-MTU-Verbindung verworfen.
Der mittlere Router, der das Paket verworfen hat, sendet eine ICMP-Meldung an den
Absender des IPv4sec-Pakets (den ersten Router), die ihm mitteilt, dass die Next-Hop-MTU 1400 Byte beträgt. Dieser Wert wird in der IPv4sec SA-PMTU aufgezeichnet.
4.
Wenn Host 1 das 1442-Byte-Paket das nächste Mal sendet (es hat keine Bestätigung dafür erhalten), verwirft IPv4sec das Paket. Auch hier verwirft der Router das Paket, da der dem Paket hinzugefügte IPv4sec-Overhead das Paket größer als die PMTU (1400) macht.
5.
Der Router sendet eine ICMP-Meldung an Host 1 und teilt ihm mit, dass die Next-Hop-MTU jetzt 1342 beträgt. (1400 - 58 = 1342). Host 1 zeichnet diese Informationen erneut auf.
6.
Wenn Host 1 die Daten erneut sendet, verwendet er das kleinere Paket (1342). Dieses Paket erfordert keine Fragmentierung und wird über den IPv4sec-Tunnel zu Host 2 geleitet.
7.
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 IPv4-Multicast-Pakete nicht unterstützt. Das 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 zuerst das Multicast- Paket des dynamischen Routing-Protokolls in ein GRE-IPv4-Unicast-Paket zu kapseln, das dann von IPv4sec verschlüsselt werden kann. Dabei wird IPv4sec häufig im Transportmodus zusätzlich zur GRE bereitgestellt, da die IPv4sec-Peers und die GRE-Tunnelendpunkte (die Router)
identisch sind und der Transportmodus 20 Byte IPv4sec-Overhead einspart.
Ein interessanter Fall ist, wenn ein IPv4-Paket in zwei Fragmente aufgeteilt und durch GRE gekapselt wurde. In diesem Fall werden für IPv4sec zwei unabhängige GRE + IPv4-Pakete
angezeigt. Häufig ist eines dieser Pakete in einer Standardkonfiguration groß genug, um nach der Verschlüsselung fragmentiert werden zu müssen. Der IPv4sec-Peer muss dieses Paket vor der Entschlüsselung neu zusammenbauen. Diese "doppelte Fragmentierung" (einmal vor GRE und einmal nach IPv4sec) auf dem sendenden Router erhöht die Latenz und senkt den Durchsatz.
Außerdem erfolgt die Reassemblierung prozessgesteuert, d. h., es wird immer ein CPU-Treffer auf dem empfangenden Router auftreten.
Diese Situation kann vermieden werden, indem die "ip mtu" auf der GRE-Tunnelschnittstelle niedrig genug eingestellt wird, um den Overhead von GRE und IPv4sec zu berücksichtigen (standardmäßig ist die GRE-Tunnelschnittstelle "ip mtu" auf die MTU - GRE-Overhead-Byte der Ausgangsschnittstelle festgelegt).
In dieser Tabelle sind die vorgeschlagenen MTU-Werte für jede Tunnel-/Modus-Kombination aufgeführt, vorausgesetzt, die physische Ausgangsschnittstelle hat eine MTU von 1500.
Tunnelkombination Spezifische MTU erforderlich 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. Außerdem gibt es keinen erkennbaren Nachteil, wenn ein zusätzlicher Overhead von 20 oder 40 Byte zugelassen wird. Es ist einfacher, sich einen
Wert zu merken und festzulegen. Dieser Wert deckt fast alle Szenarien ab.
Szenario 9
IPv4sec wird zusätzlich zu GRE bereitgestellt. Die ausgehende physische MTU beträgt 1500, die IPv4sec-PMTU 1500 und die GRE-IPv4-MTU 1476 (1500 - 24 = 1476). Aus diesem Grund werden TCP/IPv4-Pakete zweimal fragmentiert, einmal vor 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.
Durch die Konfiguration von "ip mtu 1440" (IPv4sec-Transportmodus) oder "ip mtu 1420"
(IPv4sec-Tunnelmodus) im GRE-Tunnel würde in diesem Szenario eine doppelte Fragmentierung ausgeschlossen.
Der Router empfängt ein 1500-Byte-Datagramm.
1.
Vor der Kapselung fragmentiert GRE das 1500-Byte-Paket in zwei Teile: 1476 (1500 - 24 = 1476) und 44 (24 Daten + 20 IPv4-Header) Byte.
2.
GRE kapselt die IPv4-Fragmente, wodurch jedem Paket 24 Byte hinzugefügt werden.
Daraus ergeben sich zwei GRE + IPv4sec-Pakete von 1500 (1476 + 24 = 1500) und jeweils 68 (44 + 24) Byte.
3.
IPv4sec verschlüsselt die beiden Pakete und fügt jedem 52 Byte (IPv4sec-Tunnelmodus) Kapselungs-Overhead hinzu, um ein 1552-Byte- und ein 120-Byte-Paket zu erhalten.
4.
Das 1552-Byte-IPv4sec-Paket wird vom Router fragmentiert, da es größer ist als die MTU für ausgehende Anrufe (1500). Das 1552-Byte-Paket ist in Pakete unterteilt, 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 5.
den IPv4sec + GRE-Peer weitergeleitet.
Der empfangende Router reassembliert die beiden IPv4sec-Fragmente (1500 Byte und 72 Byte), um das ursprüngliche 1552-Byte-IPv4sec + GRE-Paket zu erhalten. Das 120-Byte- IPv4sec + GRE-Paket muss nicht verändert werden.
6.
IPv4sec entschlüsselt sowohl 1552-Byte- als auch 120-Byte-IPv4sec + GRE-Pakete, um 1500-Byte- und 68-Byte-GRE-Pakete zu erhalten.
7.
Die GRE kapselt die GRE-Pakete mit 1500 Byte und 68 Byte, um IPv4-Paketfragmente mit 1476 Byte und 44 Byte zu erhalten. Diese IPv4-Paketfragmente werden an den Ziel-Host weitergeleitet.
8.
Host 2 reassembliert diese IPv4-Fragmente, um das ursprüngliche 1500-Byte-IPv4- Datagramm abzurufen.
9.
Szenario 10 ähnelt Szenario 8, außer dass eine untere MTU-Verbindung im Tunnelpfad
vorhanden ist. Dies ist ein Worst-Case-Szenario für das erste von Host 1 an Host 2 gesendete Paket. Nach dem letzten Schritt in diesem Szenario legt Host 1 die richtige PMTU für Host 2 fest, und alles ist gut für die TCP-Verbindungen zwischen Host 1 und Host 2. TCP-Datenflüsse
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 Befehl tunnel path-mtu-discovery auf dem GRE-Tunnel konfiguriert, und das DF-Bit wird auf TCP/IPv4-Paketen festgelegt, die von Host 1 stammen.
Szenario 10
Der Router empfängt ein 1500-Byte-Paket. Dieses Paket wird von der GRE verworfen, weil die GRE das Paket nicht fragmentieren oder weiterleiten kann, weil das DF-Bit festgelegt ist, und die Paketgröße die ausgehende Schnittstelle "ip mtu" ü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 beträgt (1500 - 24 = 1476).
●
Host 1 ändert seine PMTU für Host 2 auf 1476 und sendet die kleinere Größe, wenn das Paket erneut übertragen wird. GRE kapselt sie und übergibt das 1500-Byte-Paket an IPv4sec.
IPv4sec verwirft das Paket, weil GRE das DF-Bit (festgelegt) aus dem inneren IPv4-Header kopiert hat. Mit dem IPv4sec-Overhead (maximal 38 Byte) ist das Paket zu groß, um die physische Schnittstelle weiterzuleiten.
●
IPv4sec sendet eine ICMP-Meldung an die GRE, die anzeigt, dass die Next-Hop-MTU 1462 Byte beträgt (da maximal 38 Byte für Verschlüsselung und IPv4-Overhead hinzugefügt
werden). GRE zeichnet den Wert 1438 (1462 - 24) als "ip mtu" auf der Tunnelschnittstelle auf.
●
Hinweis: Diese Änderung des Werts wird intern gespeichert und ist in der Ausgabe des Befehls show ip interface tunnel<#> nicht sichtbar. Diese Änderung wird nur angezeigt, wenn Sie den Befehl debug tunnel verwenden.
●
Wenn Host 1 das 1476-Byte-Paket das nächste Mal überträgt, verwirft die GRE es.
●
Der Router sendet eine ICMP-Meldung an Host 1, die anzeigt, dass 1438 die Next-Hop-MTU ist.
●
Host 1 senkt die PMTU für Host 2 und überträgt ein 1438-Byte-Paket erneut. Diesmal akzeptiert die GRE das Paket, kapselt es und übergibt es zur Verschlüsselung an IPv4sec.
Das IPv4sec-Paket wird an den Intermediär-Router weitergeleitet und verworfen, weil es eine MTU für die Ausgangsschnittstelle von 1.400 hat.
●
Der Zwischenrouter sendet eine ICMP-Meldung an IPv4sec, die besagt, 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 und die GRE den Wert 1338 intern aufzeichnet.
●
Wenn Host 1 das ursprüngliche Paket erneut sendet (weil es keine Bestätigung erhalten hat), verwirft die GRE es.
●
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 1.338.
●
Host 1 überträgt ein 1338-Byte-Paket erneut und kann dieses Mal endlich den gesamten Weg bis zu Host 2 zurücklegen.
●
Weitere Empfehlungen
Die Konfiguration des Befehls tunnel path-mtu-discovery auf einer Tunnelschnittstelle kann GRE- und IPv4sec-Interaktionen unterstützen, wenn sie auf demselben Router konfiguriert sind. Denken Sie daran, dass ohne den konfigurierten Befehl tunnel path-mtu-discovery das DF-Bit immer im GRE-IPv4-Header gelöscht würde. Auf diese Weise kann das GRE-IPv4-Paket fragmentiert werden, obwohl der gekapselte Daten-IPv4-Header das DF-Bit festgelegt hat, wodurch das Paket normalerweise nicht fragmentiert werden kann.
Wenn der Befehl tunnel path-mtu-discovery auf der GRE-Tunnelschnittstelle konfiguriert ist, geschieht dies.
GRE kopiert das DF-Bit aus dem Daten-IPv4-Header in den GRE-IPv4-Header.
1.
Wenn das DF-Bit im GRE-IPv4-Header festgelegt ist und das Paket nach der IPv4sec- Verschlüsselung für die IPv4-MTU an der physischen ausgehenden Schnittstelle "zu groß"
ist, verwirft IPv4sec das Paket und benachrichtigt den GRE-Tunnel, um die IPv4-MTU-Größe zu verringern.
2.
IPv4sec führt die PMTUD für seine eigenen Pakete durch. Wenn sich die IPv4sec-PMTU ändert (wenn sie reduziert wird), benachrichtigt IPv4sec nicht sofort die GRE, aber wenn ein anderes "zu großes" Paket eingeht, wird der Prozess in Schritt 2 durchgeführt.
3.
Die IPv4-MTU der GRE ist jetzt kleiner, sodass sie alle Daten-IPv4-Pakete mit dem DF-Bit- Satz, die jetzt zu groß sind, verwirft und eine ICMP-Nachricht an den sendenden Host sendet.
4.
Mit dem Befehl tunnel path-mtu-discovery kann die GRE-Schnittstelle ihre IPv4-MTU dynamisch statt statisch mit dem Befehl ip mtu festlegen. Es wird empfohlen, beide Befehle zu verwenden.
Der Befehl ip mtu wird verwendet, um Platz für den GRE- und IPv4sec-Overhead im Verhältnis zur IPv4-MTU der lokalen physischen Ausgangsschnittstelle zu schaffen. Der Befehl tunnel path-mtu-
discovery ermöglicht eine weitere Verringerung der IPv4-MTU des GRE-Tunnels, wenn eine niedrigere IPv4-MTU-Verbindung im Pfad zwischen den IPv4sec-Peers besteht.
Im Folgenden finden Sie einige Beispiele für Probleme mit der PMTUD in einem Netzwerk, in dem GRE + IPv4sec-Tunnel konfiguriert sind.
Diese Liste beginnt mit der wünschenswertesten Lösung.
Beheben Sie das Problem, dass die PMTUD nicht funktioniert. Dies wird normalerweise durch einen Router oder eine Firewall verursacht, der bzw. die ICMP blockiert.
1.
Verwenden Sie den Befehl ip tcp adjust-mss an den Tunnelschnittstellen, damit der Router den TCP-MSS-Wert im TCP-SYN-Paket reduziert. Dies hilft den beiden End-Hosts (dem TCP-Sender und -Empfänger), ausreichend kleine Pakete zu verwenden, sodass die PMTUD nicht benötigt wird.
2.
Verwenden Sie Policy Routing auf der Eingangs-Schnittstelle des Routers, und konfigurieren Sie eine Routenzuordnung, um das DF-Bit im Daten-IPv4-Header zu löschen, bevor es zur GRE-Tunnelschnittstelle gelangt. Dadurch kann das Daten-IPv4-Paket vor der GRE- Kapselung fragmentiert werden.
3.
Erhöhen Sie die "ip mtu" an der GRE-Tunnelschnittstelle auf die MTU der ausgehenden Schnittstelle. Dadurch kann das Daten-IPv4-Paket GRE-gekapselt werden, ohne es zuerst zu fragmentieren. Das GRE-Paket wird dann IPv4sec-verschlüsselt und anschließend fragmentiert, um die physische ausgehende Schnittstelle zu verlassen. In diesem Fall würden Sie den Befehl tunnel path-mtu-discovery auf der GRE-Tunnelschnittstelle nicht konfigurieren. Dies kann den Durchsatz erheblich reduzieren, da die IPv4-
Paketreassemblierung auf dem IPv4sec-Peer im Prozess-Switching-Modus erfolgt.
4.
Zugehörige Informationen
Support-Seite für IP-Routing
●
Support-Seite für IPSec (IP Security Protocol)
●
IPSec-Overhead-Rechner (Berechnung der Paketgröße mit IPSec-Kapselprotokollen)
●
RFC 1191 MTU-Pfaderkennung
●
RFC 1063: Optionen zur IP-MTU-Erkennung
●
RFC 791 Internetprotokoll
●
RFC 793 Transmission Control Protocol
●
RFC 879 Maximale TCP-Segmentgröße und zugehörige Themen
●
RFC 1701 Generic Routing Encapsulation (GRE)
●
RFC 1241 Ein Schema für ein Internet Encapsulation Protocol
●
RFC 2003 IP-Kapselung innerhalb IP
●
Technischer Support und Dokumentation - Cisco Systems
●
