ip reassembly time exceeded / MTU-Problem?

From: Markus <universe(at)truemetal.org>
Date: Mon, 20 Feb 2006 20:35:20 +0100

Folgendes Szenario:

   .---. .---. .----.
I--| J |-----| F |---| S2 |
   '---' | '---' '----'
          |
        .----.
        | S1 |
        '----'

I = Internet
J = Juniper-Router
F = FreeBSD-Router mit 5.4-RELEASE
S1 = Server #1
S2 = Server #2

Problem: Datenpakete, die von S2 mit einer Groesse > 1500 bytes ueber
den FreeBSD-Router (2 NICs, em(4)) gehen, bereiten Schwierigkeiten (=
keine vollstaendige Kommunikation). MTU steht auf allen beteiligten
Interfaces (FE/GE) auf 1500.

Geht (1500 bytes - ping von S2 auf S1):

[root(at)S2 ~]# ping -s 1472 -c 1 S1
PING 192.168.100.100 (192.168.100.100) 1472(1500) bytes of data.
1480 bytes from 192.168.100.100: icmp_seq=0 ttl=62 time=103 ms

--- 192.168.100.100 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

Geht nicht (1501 bytes - ping von S2 auf S1):

[root(at)S2 ~]# ping -s 1473 -c 1 S1
PING 192.168.100.100 (192.168.100.100) 1473(1501) bytes of data.

--- 192.168.100.100 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Funktioniert nicht:

- Datenpakete > 1500 bytes von S2 zu S1 oder ins Internet

Funktioniert:

- Datenpakete > 1500 bytes von S2 auf das FreeBSD-Router-Interface
(LAN), dass sich in demselben Subnet wie S2 befindet.
- Datenpakete > 1500 bytes von S2 auf andere Rechner in anderen
Subnetzen, die ebenfalls an dem LAN-Interface haengen.

Bedeutet: bei allen Datenpaketen, die das zweite
FreeBSD-Router-Interface (WAN, d.h. zur Juniper / zu S1) verlassen,
tritt dieses Problem auf. Solange sich die Datenpakete nur auf dem
LAN-Interface tummeln, funktioniert alles tadellos.

S1 zu S2 hat dasselbe Problem. Allerdings NUR zu S1 und allen anderen
Rechnern, die sich hinter dem LAN-Interface auf dem FreeBSD-Router
befinden. S1 kann bei > 1500 bytes einwandfrei mit dem Internet und mit
allen anderen Rechnern in allen moeglichen Subnetzen kommunizieren,
solange sich diese nicht hinter dem FreeBSD-Router befinden.

Das Phaenomen scheint "neu" zu sein, existiert also erst seit ein paar
Wochen. An der Systemkonfiguration des FreeBSD-Routers wurde nichts
geaendert. polling und dummynet sind aktiviert, sonst macht der Router
nichts, ausser Datenpakete zu forwarden. Ueber den FreeBSD-Router gehen
konstant ca. 300 Mbit/s outgoing (Router -> Internet) und ca. 60 Mbits
incoming (Internet -> Router):

F# netstat -w 1
            input (Total) output
   packets errs bytes packets errs bytes colls
     48871 0 34789320 49072 0 35139956 0
     50767 0 37244252 50372 0 36832706 0
     50560 0 37011759 50076 0 36426849 0

Und fuer Bernd ( ;-) ):

F# netstat -m
1122 mbufs in use
1120/25600 mbuf clusters in use (current/max)
0/3/6656 sfbufs in use (current/peak/max)
2520 KBytes allocated to network
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines

Jetzt zum spannenderen Teil...

Waehrend eines pings von S1 auf S2 (tcpdump laeuft auf dem
FreeBSD-Router):

[root(at)S1 root]# ping -s 1473 -c 3 S2
PING 192.168.200.200 (192.168.200.200) 1473(1501) bytes of data.

--- 192.168.200.200 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2032ms

F# tcpdump -n host 192.168.100.100 or host 192.168.200.200
listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
192.168.100.100 > 192.168.200.200: icmp
192.168.100.100 > 192.168.200.200: icmp 1480: echo request seq 1
192.168.200.200 > 192.168.100.100: icmp 1480: echo reply seq 1
192.168.200.200 > 192.168.100.100: icmp
192.168.100.100 > 192.168.200.200: icmp
192.168.100.100 > 192.168.200.200: icmp 1480: echo request seq 2
192.168.200.200 > 192.168.100.100: icmp 1480: echo reply seq 2
192.168.200.200 > 192.168.100.100: icmp
192.168.100.100 > 192.168.200.200: icmp
192.168.100.100 > 192.168.200.200: icmp 1480: echo request seq 3
192.168.200.200 > 192.168.100.100: icmp 1480: echo reply seq 3
192.168.200.200 > 192.168.100.100: icmp

...ca. 30 Sekunden Pause...

192.168.100.100 > 192.168.200.200: icmp 556: ip reassembly time exceeded
192.168.100.100 > 192.168.200.200: icmp 556: ip reassembly time exceeded
192.168.100.100 > 192.168.200.200: icmp 556: ip reassembly time exceeded

Und dasselbe von S2 auf S1:

[root(at)S2 ~]# ping -s 1473 -c 3 S1
PING 192.168.100.100 (192.168.100.100) 1473(1501) bytes of data.

--- 192.168.100.100 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

F# tcpdump -n host 192.168.100.100 or host 192.168.200.200
listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes

192.168.200.200 > 192.168.100.100: icmp 1480: echo request seq 0
192.168.200.200 > 192.168.100.100: icmp
192.168.200.200 > 192.168.100.100: icmp 1480: echo request seq 1
192.168.200.200 > 192.168.100.100: icmp
192.168.200.200 > 192.168.100.100: icmp 1480: echo request seq 2
192.168.200.200 > 192.168.100.100: icmp

...ca. 30 Sekunden Pause...

192.168.100.100 > 192.168.200.200: icmp 556: ip reassembly time exceeded
192.168.100.100 > 192.168.200.200: icmp 556: ip reassembly time exceeded
192.168.100.100 > 192.168.200.200: icmp 556: ip reassembly time exceeded

Google und diverse Mailinglisten-Archive haben dazu leider nicht viel
ausgespuckt. Oftmals wurde allerdings erwaehnt "System am Ende /
ueberlastet". (nicht FreeBSD-spezifisch, ging um Linux, Draytek-Kram
usw.)

Meiner Meinung nach performed der Router noch ganz ok. Die Latenzen sind
zwar relativ hoch, aber das liegt primaer an dummynet und dem
implementierten traffic-shaping. Load liegt bei 1-2, und ca. 60-80% CPU
in Interrupts. Vielleicht noch interessant: die ipfw-rules (-> dummynet)
auf dem FreeBSD-Router sind nur fuer das externe Interface (WAN)
konfiguriert. Und noch eine Info, um das gleich auszuschliessen: das
Problem ist nicht Betriebssystem-spezifisch (S1, S2) - egal was laeuft,
Windows, Linux, FreeBSD, ueberall dasselbe Phaenomen.

Wer kann helfen? Welche Daten muss ich noch liefern?

Danke & Gruss,
Markus

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 20 Feb 2006 - 20:36:48 CET

search this site