Anton Dollmaier


IPv6 und Probleme mit Path MTU Discovery

12 Jan 2013 »

Bereits seit längerem verwenden wir bei ADITSYSTEMS IPv6 für die Dienste. Anfangs nur intern bzw. für die eigenen Webpräsenzen, seit 2011 aber auch für alle Webhosting-Kunden.

Nachdem nicht nur Server, sondern insbesondere die Clients IPv6 benötigen, läuft im Büro seit 2009 ein IPv6-Tunnel über SixXS. Grundsätzlich stabil, mit einigen kleineren Ausfällen – im großen und ganzen aber sehr brauchbar.

Leider gab es Probleme, manche Server unserer Kunden, die grundsätzlich mit IPv6-Adressen ausgestattet sind, zu erreichen. HTTP funktionierte grundsätzlich, HTTPS-Verbindungen endeten in einem TImeout.

Ein TCP-Dump der Verbindung zeigte wenig aufschlussreiches:

11:34:00.457256 IP6 2a01:138:b003:xx::x.443 > 2a01:198:xxx:xxxx:xxxx:xxxx:7ac5:cd65.51272: Flags [P.], seq 2701:3375, ack 89, win 90, length 674
11:34:00.475585 IP6 2a01:198:200:67b::1 > 2a01:138:b003:xx::x: ICMP6, packet too big, mtu 1280, length 1240

Der Server empfängt also vom SixXS-Gateway mit der IP 2a01:198:200:67b::1 den Hinweis, dass das Paket zu groß ist.

Grund dafür: bei IPv6 werden Pakete nicht mehr bei den Routern, sondern direkt durch den Absender fragmentiert. Ist einem Router auf dem Weg zum Ziel ein Paket zu groß, sendet er ein ICMPv6-Paket mit dem Hinweis “packet too big” zurück. Der Quellserver sieht das ICMPv6-Paket und sendet das ursprüngliche Paket erneut. Dieses Verhalten wird in der “Path MTU Discovery” spezifiziert.

Nicht so bei uns – es geht das gleiche Paket nochmal raus, der Kernel ignoriert offenbar das ICMPv6-Paket.

Nach einiger Suche bei den einschlägigen Suchmaschinen wurde “Reboot” vorgeschlagen – brachte nichts, der Server lief erst kurzzeitig und zeigte bereits beständig das beschriebene Verhalten.

Abhilfe schaffte letztendlich ein anderer Hinweis:

Bei einem Rechner hat es geholfen, das Netzwerkkartenkernelmodul (tg3)rauszuschmeißen und neu zuladen.

Keiner der betroffenen Server verwendet aber Netzwerkkarten mit dem tg3-Kernelmodul. Dafür wurden alle mit Netzwerkkarten von Marvell ausgestattet, die auf den Treiber “sky2” zurückgreifen. Dieses Modul machte bereits zuvor Probleme (die leider zu lange zurück lagen, um sie konkretisieren zu können).

Wir haben deshalb testweise statt dem Standard-Kernel von Debian, 2.6.32, den Kernel 3.2.0 aus den Debian Backports installiert – en voilà, plötzlich hat der Kernel die ICMPv6-Pakete verarbeitet und die HTTPS-Verbindung war über IPv6 erfolgreich!

Was lernen wir daraus? Öfter mal die Kernelmodule prüfen, evntl. gibts mit anderen Kernels weniger Probleme.

© Anton Dollmaier