PoempelFox Blog

[..] [RSS Feed]
 

Sat, 20. Jun 2009


traceroute is evil Created: 20.06.2009 18:32
One of the nicest tools to help trace problems on the Intra- or Internet is traceroute. However, it can be horribly misleading. Some of its widely known limitations include:
  • You only can trace the hops in one direction. It gives you no information about the route in the other direction, back to you. These routes can be completely different.
  • Routers usually handle them in software on their rather slow general purpose CPUs, other than the routing they do in hardware. That leads to the strange effect that some hops in a route reply really slow and even drop packets, while the hops further down the road reply fast.
  • If the path to a target is not always the same during the duration of the trace, traceroute will display crap.
I had to learn of another potential problem last week.
What happened was that a contractor noticed some strange effects in traceroute and considered the network to have a problem:

traceroute to 192.168.81.166 (192.168.81.166), 30 hops max, 40 byte packets 1 10.188.3.254 (10.188.3.254) 8.269 ms 8.255 ms 8.248 ms 2 192.168.81.166 (192.168.81.166) 0.177 ms 0.178 ms 0.172 ms

That one was easy to explain - the router is a big one, and though it routes in hardware, the answers to the traceroute have to be generated on its rather slow cpu, leading to delays if the cpu is busy with other things. Packets just passing through it are handled by special hardware, thus they are not delayed even if the cpu is busy with maintenance work, thus the next hop is reachable in roughly 1/50th the time it seems to take to reach the router, even though the packets pass through that exact same router.
However, there was more strangeness. Some traces looked like this:

traceroute to 192.168.81.166 (192.168.81.166), 30 hops max, 40 byte packets 1 10.188.3.254 (10.188.3.254) 1.264 ms 1.256 ms 1.251 ms 2 192.168.81.166 (192.168.81.166) 0.135 ms 0.133 ms *

traceroute to 192.168.81.166 (192.168.81.166), 30 hops max, 40 byte packets 1 10.188.3.254 (10.188.3.254) 1.224 ms 1.217 ms 1.212 ms 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 192.168.81.166 (192.168.81.166) 0.139 ms 0.134 ms 0.125 ms

That seemed very weird at first sight. After all it was not the router that lost replies, it was the target host - and the target host was an idle linux machine with no firewalling configured, so there shouldn't have been any drops there. Was there really a network problem? Did the network lose packets?
As it turns out: No. With the help of tcpdump, the problem became apparent pretty fast. The linux box got the packet, but just did not reply. And once that was clear, the explanation was apparent.
Traceroutes can be done in three different ways: With ICMP, UDP or TCP requests. In any case, the basic trick is to set the Time-to-live (TTL) of the packet sent to the number of the hop you're interested in, and then check from which host the "TTL expired in transit" error message for that packet arrives - voila, that's your hop. However, the last hop (with the target host) in the traceroute is different. Because when the trace reaches the target host, the time-to-live is not expired, so naturally it will not generate a "TTL expired" error message. Instead, it will reply with an "destination port unreachable" error message (for UDP traceroute) or an "icmp echo reply" (for ICMP traceroute). And there lies the problem: The linux traceroute utility by default does an UDP trace. However, even with no firewalling set up, linux limits the number of "destination port unreachable" error messages generated. And that limit by default is set rather low - too low for traceroute to work reliably on fast networks. The traceroute packets can arrive faster than the rate limiting allows the linux host to reply. So there are a few ways to get reliable (w.r.t. the last hop) traceroute results:
  • Use a windows machine for tracerouting. That works because the windows traceroute utility by default uses ICMP, not UDP, and that does not fall into the default rate limiting...
  • Use the traceroute parameter -I to make it use ICMP instead of UDP. Unfortunately, that parameter is only available to root.
  • Turn the rate limiting off at the target host: echo 0 > /proc/sys/net/ipv4/icmp_ratemask - as that limit usually makes sense, this is not recommended.
  • Turn up the rate limit setting a notch in /proc/sys/net/ipv4/icmp_ratelimit. The default is 250, the redhat enterprise default of 1000 seems to make a lot more sense.
Of course, you could just use ping instead if you're interested in the last hop, but that would be boring, wouldn't it?
no comments yet
write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3

Fri, 12. Jun 2009


Quo vadis, M-net Support? Created: 12.06.2009 10:43
Last modified: 20.06.2009 17:00
Seit vielen Jahren bin ich Kunde bei M-net. Und mit vielen Jahren meine ich wirklich VIELE Jahre. Mit einer kurzen Unterbrechung in der ich Netz im Wohnheim hatte, bin ich dem Laden seit er noch "Astat" hiess und nur ISDN Dialups ohne Telefonanschluesse anbot treu geblieben. Aus Astat wurde NEFkom, NEFkom verschmolz mit M-net.
In all diesen Jahren brauchte ich den Support nur selten - es lief einfach alles recht reibungslos. Bis zu den Zeiten von einschliesslich ADSL1 war mein einziger Kontakt mit dem Support, als ein Telekomtechniker bei der Schaltung eines neuen Anschlusses beim Nachbarn meinen kappte - ein Problem das der Support schnell regeln konnte.
Der Kontakt mit dem Support wurde häufiger, als ich nach einem Umzug auf ADSL2 wechselte. Denn dafür war ein neues Modem notwendig, und M-net stellte hierfür ein "Sphairon Turbolink AR871" zur Verfügung. Bei diesem Modemtyp war der Ethernet Port sehr anfaellig, er gab nach 1-2 Jahren den Geist auf, und produzierte dann regelmässig Linkausfälle in immer kürzeren Abständen. Das NEFkom/M-net Forum war voll mit Postings zu diesem Problem. Da das Modem bei mir an einem Linuxrouter hängt und Linux anders als Windows hier sehr tolerant ist, fiel das immer erst nach einigen Wochen auf, wenn die Abstände zwischen den Ausfällen so kurz wurden dass die Verbindung schleichend lahm wurde, und das Kernellog überquoll mit:

Apr 26 18:38:22 mulder kernel: eth1: link down Apr 26 18:38:23 mulder kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x45E1 Apr 26 18:38:31 mulder kernel: eth1: link down Apr 26 18:38:33 mulder kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x45E1 Apr 26 18:38:34 mulder kernel: eth1: link down Apr 26 18:38:35 mulder kernel: eth1: link up, 100Mbps, full-duplex, lpa 0x45E1


Zwei mal hatte ich den Spass mit einem auf diese Weise defekten Modem, doch genügte eine kurze Mail an den Support mit der Beschreibung des Problems, und es wurde unter der Bedingung das alte (kaputte) innerhalb von 4 Wochen einzusenden ein neues Modem zugeschickt. Der letzte Tausch war vor ca. einem Jahr, und damals bekam ich als Ersatz einen anderen Modemtyp - ein "Turbolink 1203". Ich hatte also begründete Hoffnung, dass die toten Ethernet-Ports mit dem neuen Modemtyp der Vergangenheit angehörten.
Leider wurde die Hoffnung bitter enttäuscht. Eines Sonntags beschloss das Modem "10 MBit should be enough for anybody", und Autonegotionation hatte es auch ploetzlich verlernt:

Jun 10 00:48:22 mulder kernel: [800471.150524] 0000:02:00.0: eth1: Link is Up 10 Mbps Half Duplex, Flow Control: None Jun 10 00:48:22 mulder kernel: [800471.150706] 0000:02:00.0: eth1: Autonegotiated half duplex but link partner cannot autoneg. Try forcing full duplex if link gets many collisions.


Das war zwar ein leicht anderes Fehlerbild als bei den vorherigen Modemausfällen, nichts desto trotz lag das Problem eindeutig am Ethernet Port des Modems. Nachdem ich also durch Testen mit mehreren Rechnern, Kabeln und sogar einem anderen Modem ausgeschlossen hatte, dass das Problem irgendwo bei mir lag, habe ich eine Mail an den Support geschrieben. Die Highlights dieser Kommunikation moechte ich hier in Ausschnitten wiedergeben:

From: me To: Support Date: Sun, 07 Jun 2009 22:07:26 +0200 Subject: Defekter Ethernet Port Turbolink 1203? Seit es letzten Sonntag ausnahmsweise mal fuer ein paar Minuten aus war, bekommt mein Turbolink 1203 nur noch mit einiger Verzoegerung (es dauert etliche Sekunden bis ueberhaupt die Link LED angeht) und mit 10 MBit half duplex einen Link auf ethernetseite. Das ist natuerlich zu wenig fuer ADSL2. Die Gegenseite konnte ich als Ursache ausschliessen - das Symptom tritt mit unterschiedlichen netzwerkkabeln und gegenstellen (laptop, switch, PC) auf, und gleichzeitig funktioniert mein eigenes Notfall-Ersatzmodem problemlos mit 100 MBit. Ich kann also nur davon ausgehen, dass der Ethernet-Port des Modems mal wieder die Graetsche gemacht hat - auch wenn die Symptome anders sind als bei den vorherigen zwei Ausfaellen mit den alten Sphairon Modellen. Falls sie Remote keine weiteren Ruecksetz- / Diagnose-Moeglichkeiten haben, bitte ich - wieder mal - um Zusendung eines Ersatzmodems. Debitorennummer laut Kundenportal: ****


Die Antwort liess über einen Tag auf sich warten, und war dafür dann nicht nur nutzlos, sondern kontraproduktiv:

From: Support To: me Date: Tue, 9 Jun 2009 11:32:43 +0200 Subject: AW: Defekter Ethernet Port Turbolink 1203? [...] An Ihrem Anschluss lassen sich aktuell keinerlei Probleme feststellen, auch sehen wir keine Abbrüche. Wir haben an Ihrem Anschluss ein anderes DSL-Profil eingestellt, bitte beobachten Sie die Verbindung in den nächsten Tagen und geben Sie uns erneut Rückmeldung, falls weiterhin Probleme auftreten. [...]


"Anderes Profil" ist dabei ein hübscher Euphemismus für "wir haben die Leitung auf 15 MBit gedrosselt". Was natürlich in keinster Weise zur Reparatur des defekten Ethernet Ports beitrug, nur dazu dass ich jetzt auch mit Ersatzmodem weniger DSL Sync bekomme.
Wie mein Geschichtslehrer früher immer sagte: "Gut gemeint ist das Gegenteil von gut gemacht" - und der M-net support meint es offenbar sehr gut, hat aber meine Mail entweder nicht gelesen oder nicht verstanden.

From: me To: Support Date: Tue, 9 Jun 2009 12:17:21 +0200 Subject: Re: AW: Defekter Ethernet Port Turbolink 1203? [...] UM HIMMELS WILLEN NEIN!!!! RUECKGAENGIG MACHEN! Auf DSL-Seite funktioniert(e) alles einwandfrei! Wenn ich (mein eigenes, auf eBay ersteigertes) Ersatzmodem anschliesse, sehe ich auch dass die Synchronisation auf DSL-Seite problemlos >16000 erreicht. Das Problem ist eindeutig der Ethernet-Port des Modems. Und auch hier gilt - mit meinem eigenen Modem gibt es keine Probleme, nur das von M-net gestellte spinnt. [...]


Diesmal dauerte die Antwort noch länger, und war - man glaubt es kaum - noch weniger hilfreich:

From: Support To: me Date: Fri, 12 Jun 2009 08:06:50 +0200 Subject: AW: AW: Defekter Ethernet Port Turbolink 1203? [...] Bitte geben sie uns ihre Kundennummer oder Telefonnummer an um sie eindeutig zu identifizieren. Da der Fehler am Modem liegt, können wir gerne das Modem austauschen. Entweder kommen sie zum Tausch in einen unserer Shops oder wir senden ihnen ein neues Modem zu. [...]


Offenbar ist es unmöglich für M-net, eine Antwort einer von ihnen selbst vor nicht mal einer Stunde verschickten Mail automatisch oder manuell (ueber Subject und From-Adresse) zuzuordnen. Wahnsinn. Aber gut, ich habe mit den gewuenschten Daten und fast einem Fullquote der bisherigen Kommunikation geantwortet.
Die naechste Antwort kam dann immerhin schnell, aber aus Muenchen - was insofern nicht verwundert, als die From-Adresse aller Antworten bisher "support_muc" war, unterschrieben aber trotzdem von einem Nuernberger Mitarbeiter.

From: Support To: me Date: Fri, 12 Jun 2009 15:59:41 +0200 Subject: AW: AW: AW: Defekter Ethernet Port Turbolink 1203? [...] Es tut mir leid,wäre es vielleicht möglich das Sie Ihr Anliegen in ein zwei Sätzen geordnet formulieren könnten, da ich bei dem Durcheinander mich leider nicht zurecht finden kann, vielen Dank. [...]


From: me To: Support Date: Fri, 12 Jun 2009 17:14:23 +0200 Subject: Re: AW: AW: AW: Defekter Ethernet Port Turbolink 1203? [...] Um es kurz zu machen: 1. Der Netzwerkport des mir von M-net zur Verfuegung gestellten DSL-Modems ist kaputt, ich bitte um Zusendung eines Ersatzmodems. 2. Das Problem hat ein Kollege von ihnen [1] falsch verstanden, darum hat er an der Konfiguration meines DSL Ports herumgefummelt, indem er ein anderes Profil mit niedrigerer Bandbreite eingestellt hat. Das war komplett sinnlos, da ich mich nie ueber Verbindungsabbrueche auf DSL Seite beschwert hatte, und dadurch selbstverstaendlich der kaputte Ethernetport des Modems nicht repariert wurde. Ich moechte das das Rueckgangig gemacht wird. Debitorennummer laut Kundenportal: ***** Telefon: ***** [...]


From: Support To: me Date: Sat, 13 Jun 2009 10:31:53 +0200 [...]Die Geschwindigkeit wird am Montag wieder auf volle Leistung eingestellt. Ein neues Modem wird ihnen in den nächsten Tagen zugesendet. Bitte senden sie uns das alte Modem mit dem beigelegten Rücksendeschein zurück.[...]


Das neue Modem kam tatsaechlich am 17ten, und auch das Profil wurde offensichtlich wieder korrigiert (sync mit >17000 KBit). Da auch das Modem funktioniert sieht es aus als haette die Geschichte doch ein Happy End gefunden...
1 comment
Pömpel pömpel pömpel!
Gut gemacht, Fox!
Karin 12.06.2009 15:24

write a new comment:
name or nickname
eMail adress (optional)
Your comment:
calculate: (2 times 10) plus 3
 
EOPage - generated with blosxom