2.5. Praktikum

Die ersten drei Versuche können Sie wieder im Laboraufbau FAST durchführen.
  1. Beobachten Sie mittels tcpdump, wie sich Linux hinsichtlich Datagramm-Verlust und ARP-Flooding verhält, wenn Sie bei leerem ARP-Cache ein 8192 Byte großes UDP-Datagramm unter Verwendung des Test-Programms sock an den Echo-Server eines anderen Systems senden.

    Hinweis: Eine unter Linux lauffähige Version von sock finden Sie auf allen Labor-Rechnern (einschließlich hydra) in der Datei /usr/local/bin/sock. Die C-Quelltexte stehen im Verzeichnis /usr/local/src/sock des Steuerrechners hydra. Damit haben Sie prinzipiell die Möglichkeit, sock auch für andere UNIX-Plattformen zu generieren.

  2. Bauen Sie eine TCP-Verbindung für interaktiven Datenaustausch (Telnet o.ä.) zwischen zwei Rechnern auf und beobachten Sie die ausgetauschten Segmente mittels tcpdump. Dokumentieren Sie Ihr konkretes Vorgehen beim Experiment. Welche Details können Sie den Ausgaben des Monitor-Programms entnehmen?

  3. Bauen Sie eine TCP-Verbindung für den Transport großer Datenmengen zwischen zwei Rechnern auf und beobachten Sie die ausgetauschten Segmente mittels tcpdump. Ermitteln Sie die Unterschiede im Verhalten bei 10-Mbit/s-Ethernet und 100-Mbit/s-Ethernet.

  4. Die in TCP realisierte Flußsteuerung begrenzt den Durchsatz auf einer beliebigen Verbindung im Internet auf den der "engsten Stelle". Wen man nun für eine bestimmte Verkehrsbeziehung einen "unbefriedigenden" Durchsatz feststellt, möchte man natürlich gern wissen, wo denn der "Flaschenhals" ist. Die Ihnen schon bekannten Werkzeuge ping und traceroute liefern nur Verzögerungszeiten, was zwar auch interessant ist, aber kaum Rückschlüsse auf den erzielbaren Durchsatz zuläßt.

    Ein Schritt in Richtung dieses Analyseproblems ist ein relativ neues, allerdings offenbar seit Mitte 1997 nicht weiter gepflegtes Werkzeug TReno, das nicht nur wie traceroute den Weg eines Pakets ermittelt, sondern auch die Bandbreiten der einzelnen Übertragungsabschnitte ermittelt (oder dies zumindest versucht :-).
    Der Name TReno ist aus Traceroute RENO abgeleitet, wobei RENO eine BSD-Unix-Version ist, die als repräsentativ für moderne TCP-Implementierungen gelten kann.

    TReno sendet wie traceroute UDP-Pakete oder ICMP-ECHO-Requests mit kleinen TTL-Werten aus. Die daraufhin von den Routern "am Weg" zurückgeschickten ICMP-TTL-Exceeded-Pakete kommen etwa nach derselben Zeit an, nach der auch TCP-ACK-Pakete kommen würden. Auf dieser Basis kann man experimentell ermitteln, auf welche Datenrate sich eine TCP-basierte Flußsteuerung zu dem betreffenden Partner (oder Router) einstellen würde.

    Ermitteln Sie mit treno (installiert auf hydra.informatik.tu-chemnitz.de in /usr/local/bin) das Netzverhalten zu von Ihnen ausgewählten Partnern. Geben Sie möglichst auch eine Interpretation der Resultate an.

    Sehen Sie sich vorher die Handbuchseite zu treno [treno.txt] an.

    Die WWW-Seite http://www.psc.edu/~pscnoc/treno.html soll die TReno-Funktion formulargesteuert anbieten, so daß man von dort aus das Netzverhalten zu einem ausgewählten Partner ermitteln kann. Zum Zeitpunkt der letzten Aktualisierung des vorliegenden Textes stand dieser Dienst allerdings nicht zur Verfügung, worauf mit der Bemerkung "The Treno Server has been temporarily disabled" hingewiesen wurde.


Vertiefung:

Nähere Informationen zu TReno (einschließlich des Quelltexts) finden Sie unter http://www.psc.edu/~mathis/ippm/. Dort ist auch der zugehörige Grundlagenartikel erhältlich:

Diese Arbeiten sind in eine IETF-Arbeitsgruppe Internet Performance and IP Provider Metrics (IPPM) eingebettet. Informationen dazu finden Sie u.a. unter http://www.advanced.org/IPPM/index.html.
© Holger Trapp, Uwe Hübner, 8.2.1999