adminstoriesblackholesidentifizieren

no way to compare when less than two revisions

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.


—adminstoriesblackholesidentifizieren [20120830 08:45] (aktuell) – angelegt Dirk Deimeke
Zeile 1: Zeile 1:
 +====== Blackholes identifizieren ======
  
 +  * Urspruenglicher Autor: Ramon Kukla
 +  * Urspruengliches Datum: 05.08.2011
 +
 +Nein, wir bleiben im weiten Feld der EDV und wechseln nicht in die Astronomie. Obwohl [[http://de.wikipedia.org/wiki/Schwarzes_Loch|Schwarze Loecher]] durchaus interessant sind. Aktuell geht es aber um sogenannte Blackholes in Netzen.
 +
 +Wer sich ein wenig mit Netzwerken beschaeftigt wird wissen, dass Daten nicht am Stueck, sondern in Pakete verteilt, uebertragen werden. Bei TCP/IP sind das in einem Ethernet 1500 Byte. Die 1500 Byte sind natuerlich nicht der Bereich, der fuer Nutzdaten verwendet werden kann. Hier gehen dann noch die sogenannten Headerinformationen fuer [[http://de.wikipedia.org/wiki/IP-Paket#Aufbau_des_Kopfdatenbereiches_.28IP-Header.29|IP]] (Source Address, Destination Address, Protocol, etc.) und [[http://de.wikipedia.org/wiki/Transmission_Control_Protocol#Aufbau_des_TCP-Headers|TCP]] (Source Port, Destination Port, Flags, etc.) ab, so dass spaeter entsprechend weniger Platz fuer die Daten bleibt. Im Normalfall haben wir 20 Byte fuer IP und noch mal 20 Byte fuer TCP, womit dann 1460 Byte fuer weiter oben liegende Protokolle ueber bleiben.
 +
 +Wenn nun einer der beteiligten Router nicht in der Lage ist ein Paket mit gesetztem DF-Bit (Don't Fragment) ohne Fragmentierung zu uebertragen und keine entsprechende Meldung abgibt, dann haben wir ein Problem. Denn die beteiligten Hosts gehen davon aus, dass sie Pakete in der Groesse X versenden koennen, die gehen aber nicht ueber die Leitung, da der Router diese verwirft. Die Effekte koennen nun von Abbruechen der Verbindungen bis hin zu einfachen Aussetzern und Performanceproblemen fuehren. Was also tun, wenn man ein Blackhole vermutet?
 +
 +Am einfachsten ist hier der Einstieg mit Ping. Unter Linux waere beispielsweise ein ''ping -c 1 -M do -s 1472 $ZIEL'' ein guter Ansatz. Mit ''-c 1'' definieren wir, dass nur ein Paket geschickt wird. Das ''-M do'' bedeutet soviel wie Don't fragment. Mit ''-s 1472'' wird die Anzahl der Daten-Bytes festgelegt und mit ''$ZIEL'', kaum ueberraschend, das Ziel. Das mit dem ''-c 1'' (oder einem anderen sinnvollen kleineren Wert) sollte man machen. Andernfalls kann es passieren, dass einem nachher ewig viele ''Frag needed and DF set ''-Meldungen durch die Shell rauschen.
 +
 +Die maximale Groesse der MTU ([[https://secure.wikimedia.org/wikipedia/de/wiki/Maximum_Transmission_Unit|Maximum Transmission Unit]]) in unserem Beispiel (mal so ein "normales" Ethernet angenommen) ist 1500 Bytes. Da ziehen wir dann noch 20 Bytes fuer IP und 8 Bytes fuer ICMP ab. Hier mal ein Beispiel.
 +
 +<code>ramon@superfrog ~ $ ping -c 1 -M do -s 1473 192.168.0.1
 +PING 192.168.0.1 (192.168.0.1) 1473(1501) bytes of data.
 +From 192.168.150.10 icmp_seq=1 Frag needed and DF set (mtu = 1500)
 +
 +--- 192.168.0.1 ping statistics ---
 +0 packets transmitted, 0 received, +1 errors</code
 +
 +Hier sehen wir, dass es Probleme gibt, da die MTU 1500 Bytes gross ist. Wir wollten aber, zusaetzlich zu den 20 Bytes fuer IP und den 8 Bytes fuer ICMP, noch 1473 Bytes an Daten uebertragen. Und das ohne zu fragmentieren. Da wir in Summe mehr als 1500 Bytes haben, gibt es eine entsprechende Meldung. Als Vergleich noch ein Beispiel, in der das Paket ueber das Netz geht.
 +
 +<code>ramon@superfrog ~ $ ping -c 1 -M do -s 1472 192.168.0.1
 +PING 192.168.0.1 (192.168.0.1) 1472(1500) bytes of data.
 +1480 bytes from 192.168.0.1: icmp_req=1 ttl=62 time=5.51 ms
 +
 +--- 192.168.0.1 ping statistics ---
 +1 packets transmitted, 1 received, 0% packet loss, time 0ms
 +rtt min/avg/max/mdev = 5.515/5.515/5.515/0.000 ms</code>
 +
 +Soweit so gut. Moechte man nun allerdings den Hop identifizieren, der Probleme macht, ist man nur mit der Ping-Methode nicht auf der sicheren Seite. Denn, wir erinnern uns, der "boese" Router meldet ja nichts zurueck. Also nehmen wir uns traceroute als Werkzeug zur Hilfe. Fuer den Anfang machen wir erst einmal ein einfachen traceroute auf das Ziel via ''traceroute $ZIEL''. Anschliessend kann man sich dann durch die Tabelle durcharbeiten. Der traceroute-Befehl von Windows und Linux unterscheiden sich allerdings, nicht nur in den Parametern, ein Stueck weit. Verwendet ''tracert'' unter Windows ICMP, so haben wir mit ''traceroute'' unter Linux im Standard UDP-Pakete.
 +
 +<code>ramon@superfrog ~ $ traceroute -n 192.168.0.1</br>traceroute to 192.168.121.254 (192.168.121.254), 30 hops max, 60 byte packets
 +1  192.168.150.1  0.341 ms  0.368 ms  0.411 ms
 +2  192.168.100.1  0.343 ms  0.362 ms  0.409 ms
 +3  192.168.0.1  18.310 ms * *</code>
 +
 +Nun haben wir eine Liste der beteiligten Stationen und koennen diese nun einzeln mit einem ''ping -f -l $PAKETGROESSE $ZIEL'' (um auch dem Windows-Ping mal eine Chance zu geben) testen.
 +
 +Kleine Ergaenzung. Ich konnte nicht durchgaengig originale Ausgaben der Befehle verwenden, da der WLAN-Router in meinem Netzwerk beim Testen, vor allem mit zu grossen Paketen und dem gesetzten DF, aus dem Tritt kam und neu gestartet werden musste. *huestel*
 +
 +Sollte es Fragen oder Unklarheiten geben, koennt ihr mich gerne ansprechen!
 +
 +[[adminstoriesartikel|Zurück zur Uebersicht]]
  • adminstoriesblackholesidentifizieren.txt
  • Zuletzt geändert: 20120830 08:45
  • von Dirk Deimeke