die MTU, dein Freund und Kopfzerbrecher

Liebe Leute lasst euch sagen: ppp encapsultaion kann schon glücklich machen im österreichischen ADSL-Land, dann wenn man vergisst, dass die Einkapselung die MTU/MSS-Sizes automatisch repariert, wenn man via pptp-client über ein (gutes) altes Thomson Modem einwählt.

Ersetzt man nun, wie in meinem Fall, dieses “Linux-Host macht Einwahl über Modem”-Konstrukt durch einen Cisco als Zugang ins weite Internetz, dann muss man den Tanz der Segments, Frames & Packets tanzen:

MTU 1500 ist im LAN noch ok, aber über WAN meist ungünstig, daher prüft man am besten mittels swipe-ping, welche maximale Größe denn überhaupt unterstützt wird:

dsl-knecht#ping
Protocol [ip]:
Target IP address: 195.96.0.4
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep min size [36]: 1400
Sweep max size [18024]: 1520
Sweep interval [1]:
Type escape sequence to abort.
Sending 121, [1400..1520]-byte ICMP Echos to 195.96.0.4, timeout is 2 seconds:
!!!!!!!!!!!!!!!......!!!!!!!!!!!!!!!!!!......!!......!!......!!......!
!......!!......!!......!!..........................
Success rate is 38 percent (47/121), round-trip min/avg/max = 124/132/136 ms
dsl-knecht#

Hier sieht man also schön, daß bei 1415 byte die ersten Packets gedropped werden, was also die max. MTU darstellt…

daher hab ich auf die Schnelle in meinem Dialer-Interface am Cisco 887 VA folgende Zeilen konfiguriert, um den Bits wieder uneingeschränkten, aber fragmentierten Lauf zu lassen:

interface Dialer0
mtu 1415
ip tcp adjust-mss 1349
end

Der Wert der max. Segmentation Size (MSS sollte 40 byte unter der MTU liegen, da auf Layer 4 noch weitere Bytes für Falgging und Tagging verwendet werden – wenn man IPSec/GRE einsetzten will, dann sollte man – wie ich auch – nochmal 4 Bytes, also insgesamt 44 Bytes geringer  segmentieren. Dann funktionieren wieder alle Webseiten- und Datenaufrufe, welche die Payload des ETH-Frames mit den standardmässigen 1500 Bytes befüllen wollen wieder!

Ein Beispiel aus der Wikipedia, welches die Fragmentierung, Segemtierung und Tagging anschaulich darstellt:

# ping -s 1472 10.0.0.1
          1472 bytes Nutzlast des ICMP-Protokolles (Transportschicht)
        +    8 bytes ICMP-Header (Transportschicht)
        +   20 bytes IPv4-Header (der Vermittlungsschicht)
       -------------
        = 1500 bytes (Nutzlast von Ethernet)
        +   14 bytes (Header der Sicherungsschicht)
        +    4 bytes (Frame Check Sequence)
       -------------
        = 1518 bytes (kompletter Ethernetrahmen)