Shaping

Genausowenig, wie der Chemnitzer Linux-Tag 2004 größer Filesharing-Knoten Europas werden sollte, wollten wir auch vermeiden, übermäßig Inbound-Traffic zu erzeugen.

Bereits im Vorfeld des Chemnitzer Linux-Tags 2004 erreicheten uns Emails wie diese:

Hallo,
ich möchte den Sonntag auf den Linuxtag kommen und die Gelegenheit nutzen, um
privaten Download zu machen, speziell KDE 3.2 : Sourcen & Debian-Pakete.
Das kostet m.E. >4GB. Ich bin mit diesem Anliegen vermutlich nicht der
einzige.
Deshalb meine Frage:
Habt ihr für solche Anliegen einen lokalen Mirror, bzw. welche Adresse hat er?
(u.U. eine kleine Website mit "most wanted downloads (mirrored)")
tia und mit viel Vorfreude
<Name anonymisiert>

Das Konzept für Traffic-Vermeidung und Shaping war mehrstufig:

Transparente Proxies für http und ftp
Shaping innerhalb von http und ftp durch den squid
ICMP hart in der Firewall limitieren
globales Shaping mit Advanced Routing unter Linux 2.4

1. Transparente Proxies für http und ftp

Unser Router hatte mit einem Athlon XP 2200+ genug Leistung, um mehr als nur unseren Internetuplink zu bedienen und das interne Netzwerk zu versorgen. Auf der 60 GB Systemplatte waren 55 GB für einen großen Squidcache vorgesehen.

Mit ein paar einfachen Konfigurationsdirektiven und iptables-Regeln läßt sich der Squid so konfigurieren, daß er transparent cachen kann, also nicht als Proxy im Browser angegeben werden muß sondern per Redirect von der Firewall automatisch für alle http-Verbindungen verwendet werden kann.

Eine Anleitung dazu findet sich u.a. hier:
Transparent Proxy with Linux und Squid Mini-HOWTO

Squid kann ftp-Verbindung cachen, dies aber nicht transparent. Dafür kam frox zum Einsatz, der genau das leistet. frox wiederum läßt sich so konfigurieren, daß er einen beliebigen Squid als Backend-Proxy verwenden kann. In dieser Konfiguration kam er auf dem Chemnitzer Linux-Tag zum Einsatz.

2. Shaping innerhalb von http und ftp durch den squid

Squid bietet als Feature sog. delay pools. Diese fassen jeweils Requests an den Proxy zu Klassen zusammen. Für den Chemnitzer Linux-Tag gab es folgende Klassen:
Nummer Direktive Beschreibung
1 acl magic_words1 url_regex -i 10. tu-chemnitz.de clug.de alle URLs aus dem lokalen Netz
2 acl magic_words2 url_regex -i .deb .rpm .tar.gz .tar.bz2 Packete von Linuxdistributionen, Source-Packete (naja, etwas unscharf)
3 acl magic_words3 url_regex -i .exe .mp3 .mp3 .mpg .iso .wav .mov .zip .avi .qt .ram .rm .raw Warez

Nummer	Direktive	Beschreibung
1	acl magic_words1 url_regex -i 10. tu-chemnitz.de clug.de	alle URLs aus dem lokalen Netz
2	acl magic_words2 url_regex -i .deb .rpm .tar.gz .tar.bz2	Packete von Linuxdistributionen, Source-Packete (naja, etwas unscharf)
3	acl magic_words3 url_regex -i .exe .mp3 .mp3 .mpg .iso .wav .mov .zip .avi .qt .ram .rm .raw	Warez

Diesen Klassen wurden separat Bandbreiten zugewiesen. Für Klasse 1 gab es keine Bandbreitenbeschränkung, d.h. Daten aus dem lokalen Netz der Uni konnten mit Wire-Speed des 100 MBit/s-Uplinks ins Rechenzentrum bzw. 1 GBit/s heruntergeladen werden, sofern sie bereits im Proxy waren.

Klasse 2 erhielt global 5 MByte/s sobald die Dateigröße >250 KB beträgt, sowie pro Nutzer 0.5 MByte/s sobald die Dateigröße >250 KB beträgt.

Klasse 3 erhielt global 2 MByte/s sobald die Dateigröße >250 KB beträgt, sowie pro Nutzer 0.2 MByte/s sobald die Dateigröße >250 KB beträgt.

Dokumentation zu diesem Thema: Bandwidth-Limiting-HOWTO

3. ICMP hart in der Firewall limitieren

Im Prinzip wäre von einem öffentlichen Kabel-Port auf dem Chemnitzer Linux-Tag ein 100 MBit/s-Floodping auf beliebige Rechner in Uni und dem Internet möglich gewesen. Um das zu verhindern, wurde ICMP mit iptables im Router per limit-Match beschränkt.

# iptables -A FORWARD -p icmp -m limit --limit 300/minute --limit-burst 1000 -j ACCEPT
# iptables -A FORWARD -p icmp -j REJECT --reject-with icmp-proto-unreachable

Erlaubt die ersten 1000 Pakete ungehindert, danach nur noch 300 pro Minute. Die 1000 werden, falls es keinen Match gibt, mit 300 pro Minute wieder 'aufgefüllt'. Ein normaler ping schickt einen request pro Sekunde hinaus. Ausgehend von 6 Nutzern, die gleichzeitig pingen, erschienen uns 300 pro Minute sinnvoll, soviel sollte auch der schwächste server vertragen können. Ein Burst von 1000 sollte 'Ballungen' abfangen.

Weitere Doku zu diesem Thema: iptables-Doku auf frozentux.net

4. Globales Shaping mit Advanced Routing unter Linux 2.4

Hier haben wir uns nach folgenden Dokumenten gerichtet:

Sämtlicher IP-Traffic wurde danach in 4 Klassen eingeteilt:
Klasse Protokolle Beschreibung
1 ssh, irc, ircs, ircd synchrone Verbindungsprotokolle
2 pop3s, imaps, nntp, nntps asynchrone Verbindungsprotokolle
3 http, https, ftp, dport>1024 Surfen und unprivilegierte Ports
4 * der Rest

Klasse	Protokolle	Beschreibung
1	ssh, irc, ircs, ircd	synchrone Verbindungsprotokolle
2	pop3s, imaps, nntp, nntps	asynchrone Verbindungsprotokolle
3	http, https, ftp, dport>1024	Surfen und unprivilegierte Ports
4	*	der Rest

Diese Klassen wurden in der mangle-table mit dem MARK-Target markiert und gemäß ihrer Klassenzugehörigkeit in unterschiedliche Traffic-Klassen einsortiert.

Jede Klasse erhielt als Mindestbandbreite 1/8 der maximal zur Verfügung stehenden Bandbreite. Wenn die anderen Klassen gerade die restliche Bandbreite nicht verwendenten, durfte jede der Klassen bis zur maximalen Bandbreite Traffic machen. Maximal waren insgesamt 80 MBit/s, weil für eine Video-Direktverbindung nach Wilhelmshafen noch 20 MBit/s garantiert zur Verfügung stehen sollten.

Die Shapingklassen sind aufsteigend nach Priorität sortiert, d.h. die erste Klasse hat die höchste Priorität, was so auch sinnvoll ist.

Mit dieser Konfiguration gab es für die Video-Konferenz mit Wilhelmshaven keine Bandbreitenengpässe, das Shaping hat also seinen Zweck voll erfüllt. Am Samstag Abend wurden die Delay-Pools im Squid deaktiviert, weil kein weiterer Bedarf dafür bestand.