Policing

Eine Besonderheit von Trafficcontrol-inetgw ist das differenzierte Ingress-Policing: Statt lediglich beliebige Pakete zu verwerfen, sobald der Downstream die Rohdatenbandbreite überschreitet, analysiert Trafficcontrol-inetgw den Typ des Pakets und verwirft nur solche, auf die es weniger ankommt. Wegen der reduzierten Möglichkeiten des Linux-Kernels beim Ingress, arbeitet Trafficcontrol-inetgw anders als bei Egress ohne Warteschlangen. Jedes Paket durchläuft eine Reihe von Filtern, danach entscheidet Trafficcontrol-inetgw über Annahme oder Verweigerung.

Zeile 143 von Listing 1 prüft für jedes eingehende Paket, ob insgesamt 98 Prozent der vom Administrator konfigurierten Rohdatenbandbreite überschritten sind. Ist das nicht der Fall, nimmt das System das Paket ohne weitere Prüfung an. Die Anweisung »conform-exceed continue/ok« beschreibt, was zu tun ist, wenn der Filter zutrifft (»continue« : weiter mit dem nächsten Filter) oder nicht zutrifft (»ok« : Paket annehmen).

Sind 98 Prozent der Rohdatenbandbreite überschritten, bekommen bis zu 2 Prozent der Pakete ab Zeile 150 die IPtables-Marke »20« aufgedrückt. Diese Pakete verarbeitet dann das Skript »iptables-ingress« (Listing 3) weiter. Es verwirft einzelne Pakete, wenn sie zu einem HTTP- oder FTP-Download gehören, der bereits mehr als 10 MByte Nutzdaten transportiert hat. Die Strategie: Besser schon bei 98 Prozent große Downloads etwas abbremsen, als später das ACK-Paket einer ausgehenden Verbindung verwerfen müssen.

Bei dem Filter ab Zeile 156 kommen nur die Pakete an, die den Filter in Zeile 143 passiert haben. Hier klärt sich, ob diese Pakete 1 Prozent der Rohdatenbandbreite überschreiten, der Downstream also zu 99 Prozent ausgelastet ist. Wenn ja, gehen ab Zeile 163 einzelne, mindestens 1024 Bytes große Pakete über den Jordan. Das begünstigt ACK-, SSH- und ähnliche Pakete auch dann, wenn die IPtables-Regel in Listing 3 nicht greift, weil keine großen Downloads vorliegen. Erst wenn der Downlink trotzdem zu 100 Prozent ausgelastet ist, verwirft ein Algorithmus ab Zeile 173 auch beliebige Pakete.

Das in Listing 1 abgedruckte »trafficcontrol-inetgw« fußt auf Wondershaper, erweitert ihn aber in einigen Punkten. Das Skript benötigt mindestens Kernel 2.6.24 [8] und IProute 20080725. Zur Installation lädt der Administrator die vier in Tabelle 4 genannten Dateien von [6] herunter und kopiert sie nach »/usr/local/bin/« . Dann erweitert er seine Firewall um die Regeln aus Listing 2. Liegt sie als Bash-Skript vor, genügt die folgende Ergänzung:

DEV="Device"
source /usr/local/bin/iptables-egress

Danach empfiehlt sich ein Testlauf mit »trafficcontrol-inetgw Device geschätzte_Uplink-Rohdatenbandbreite geschätzte_Downlink-Rohdatenbandbreite« . Kommt keine Fehlermeldung, hat alles geklappt. Dann kann man mit »trafficcontrol-inetgw Device« Statistiken abrufen und das System mit »trafficcontrol-inetgw Device clear« wieder dekonfigurieren.

Mit einigen Versionen von IPtables, zum Beispiel 1.4.2 in Debian Lenny, tritt das Problem auf, dass Tc aus dem IProute-Paket die IPtables-Bibliotheken nicht findet, da sie nach »/lib/xtables« verschoben und umbenannt sind. Wer »trafficcontrol-inetgw« aufruft, erhält dann bei Zeile 153 die Meldung »/lib/iptables/libipt_mark.so: cannot open shared object file: No such file or directory failed to find target MARK« . Als Workaround kann der Administrator das »/lib/iptables« -Verzeichnis einer älteren Version nach »/usr/local/lib/oldiptables« kopieren und das »tc« in Zeile 8 mit der Umgebungsvariablen »IPTABLES_LIB_DIR« bekanntgeben.

Die Suche nach einem geeigneten Partner

Zum Testen des Setups benötigt der Administrator einen Host zum Anpingen, der nur wenige Hops entfernt im Internet steht. Die Antwortzeit der Ping-Pakete soll die Latenz des Internetzugangs messen und möglichst wenig vom sonstigem Verkehr im Internet beeinflusst sein. Wenn der Point-to-Point-Partner beim eigenen Provider nicht auf Ping reagiert, lässt der Admin sich mit »mtr -ntrc3 www.google.de« alle Router auf dem Weg zu Google anzeigen. Anschließend probiert er nacheinander, ob sie auf Ping reagieren. Der erste Router, der ohne Paketverluste auf »ping IP-Nummer« antwortet, empfiehlt sich als Gegenstelle.

Das Skript »trafficcontrol-searchbw« (hier nicht abgedruckt, aber bei [6] zu finden) unterstützt den Administrator beim Suchen der Rohdatenbandbreite. Statt vieler Testläufe mit »trafficcontrol-inetgw« und anschließendem Ping reicht ein Aufruf zum Untersuchen eines Bandbreitenintervalls. Zuerst ergänzt er in Zeile 18 des Skripts die gerade ermittelte IP-Nummer in der Variablen »PingHost« . Nun startet er einige große Downloads, um den Downlink konstant auszulasten. Mit dem Aufruf von

trafficcontrol-searchbw Device DOWNUntergrenze-Obergrenze SchrittweitePing-Anzahl Upstream

startet eine erste Übersichtsmessung. Die einzelnen Parameter in korrekter Reihenfolge erklärt Tabelle 5. Ein Beispiel: »trafficcontrol-searchbw ppp0 DOWN 1300-1800 50 5 210« . Das Intervall von 1300 bis 1800 KBit/s Downlink-Rohdatenbandbreite entspricht dabei einer ersten Schätzung das Anwenders. Die 210 KBit/s für den Upstream sind ebenfalls geraten, aber bei dieser Messung nicht wichtig. Abbildung 2 zeigt das Ergebnis.

Abbildung 2: Eine Übersichtsmessreihe von erzielten Nutzbandbreiten und Ping-Zeiten. Deutlich zu sehen ist der Latenzsprung zwischen 1700 und 1750 KBit/s – in diesem Bereich liegt die optimale Bandbreite.

Nach der Übersichtsmessung startet der Administrator eine Detailmessung des interessanten Intervalls. Wie in Abbildung 3 zu sehen, reduziert er dabei die Schrittweite und erhöht die Anzahl der Pings: »trafficcontrol-searchbw ppp0 DOWN 1650-1750 20 100 210« .

Abbildung 3: Detailmessreihe für das in Abbildung 2 ermittelte Rohbandbreiten-Intervall. Die optimale Rohbandbreite liegt bei 1710 KBit/s, da hier die Latenz bei ausgelastetem Downlink noch unter 100 ms liegt. Damit liefert der Router 1471 KBit/s Nutzdaten. Die Ergebnisse sind genauer als in Abbildung 2, da hier wesentlich länger gemessen wurde.

Da diese Messung recht lange läuft, muss der Admin darauf achten, dass die Downloads stabil bleiben. Die jeweils gemessene Nutzdatenbandbreite sieht er in der Ausgabe. Bricht sie ein, muss er die Messung wiederholen. Außerdem darf der Uplink nicht nennenswert anderweitig genutzt sein. Dies erhöht die Latenz und verfälscht damit das Ergebnis. Auch hier sollte er in der Ausgabe die Upstream-Bandbreite prüfen und die Messung gegebenenfalls wiederholen.

Nun kann der Administrator seine optimale Rohdatenbandbreite für den Downlink ablesen. Es ist die letzte Zeile, die noch eine akzeptable Antwortzeit unter 100 Millisekunden erzielt. Anschließend wiederholt er die Messungen für den Uplink. Steht kein FTP-Server zum Hochladen der Daten ins Internet bereit, kann er sich selbst E-Mails mit sehr großen Attachments schicken. Die Messung muss aber abgeschlossen sein, bevor das System die E-Mails wieder herunterlädt. Ein Beispielkommando für eine Uplink-Übersichtsmessung lautet: »trafficcontrol-searchbw ppp0 UP 150-250 10 5 1710« .

Um das System beim Booten zu konfigurieren, fügt der Administrator das Kommando »trafficcontrol-inetgw« zu einem seiner Startskripte hinzu. Bei einem DSL-Zugang zum Beispiel empfiehlt es sich

#!/bin/sh
case "$PPP_IFACE" inDevice) /usr/local/bin/trafficcontrol-inetgw.sh
[UCC:x00-fake-italic]Device Up Down
 ;;
esac

unter »/etc/ppp/ip-up.d/trafficcontrol« abzulegen. Nun kann er auch seine Firewall um die Regeln aus IPtables-ingress ergänzen. Diese müssen vor den üblichen Regeln für das Connection Tracking stehen, damit IPtables-ingress alle Pakete einer Verbindung auswerten kann. Dazu ergänzt der Admin »source /usr/local/bin/iptables-ingress« in seinem Firewallskript. Diese Regeln werden erst nach der Messung aktiv, da sie Downloads ab dem 10. MByte um zirka zwei Prozent ausbremsen. Dies hätte die maximale Bandbreite verfälscht.