Modernes Bandbreitenmanagement begrenzt und formt den Datenstrom, der das eigene Netz verlässt. Das steigert die Performance der vernetzten Applikationen und spart auch Kosten. Jedes Linux beherrscht heute die passenden Verfahren; zwei Appliances zeigen, wie einfach die Verkehrskontrolle gelingt.

IPv6, QoS (Quality of Service), Multicast, Streaming, Voice over IP: Das Internet transportiert nicht nur E-Mail, FTP oder Webseiten. Der moderne Multimedia-Mix verlangt nach neuen Eigenschaften des Netzes. Manchmal müssen möglichst viele Daten durch das Netz, es ist aber egal, wann und in welcher Reihenfolge die einzelnen Pakete an ihrem Ziel eintreffen. Andere Applikationen brauchen dagegen einen konstanten Datenfluss, ohne große oder gar wechselnde Verzögerungen.

Aufgabe des Traffic-Engineering-Teilgebiets Bandbreitenmanagement ist es, den Netzwerkverkehr zu optimieren. Dazu muss es sich in der Regel an Schicht 7 des OSI-Modells orientieren, passend zu den eingesetzten Applikationen. Beispielsweise wollen Admins, dass fürs LAN entwickelte Programme auch im WAN klaglos laufen und dass kein einzelner User die ganze Bandbreite mit P2P- und Filesharing-Software belegt. Sie möchten die Laufzeit (Latency) und Laufzeitschwankungen (Jitter) für VoIP optimieren und die Antwortzeiten von Webservern verbessern. Die gleichen Techniken funktionieren auch im Heimnetz, etwa um die asymmetrische DSL-Leitung besser zu nutzen.

Einige Hersteller von Bandbreitenmanagement-Programmen und -Appliances errechnen aus dem optimierten Lauf von Applikationen wie SAP oder Citrix Metaframe eine eindrucksvolle Ersparnis für die Anwender. Sie betrachten Bandbreitenmanagement vorwiegend auf Layer 7. Andere verkaufen zusätzlich IP-Telefone, Switches oder Router. Für diese ist Bandbreitenmanagement ein Multimedia-Thema, das mit modernen Technologien und Multicast zu tun hat.

Neue Netze

IPv6, QoS und Multicast werden oft in einem Atemzug genannt. IPv6 hat sich – abgesehen von Lippenbekenntnissen der Hardwarehersteller – bislang aber nicht durchgesetzt und sucht weiter nach einer sinnvollen Verwendung. Zumindest in der Theorie beherrscht IPv6 End-to-End-QoS (durch Flow Labels) für Unicast und Multicast. Genau das bräuchten Multimedia-Anwendungen.

Abbildung 1: Traffic Shaping betrifft nur Pakete, die den Rechner verlassen (Outbound). Ist das Netz ausgelastet, landen sie in einer Queue. Traffic Policing wirkt sich dagegen auf hereinkommende Pakete aus (Inbound). Umfassendes Bandbreitenmanagement kombiniert beide Techniken.

Vergleichbare Ergebnisse sind aber auch mit IPv4 zu erreichen. Wenn alle Endpunkte einer Multicast-Anwendung (zum Beispiel Videokonferenz) unter einer administrativen Hoheit stehen, können sich die Beteiligten hinter ihren Access-Routern die nötige Bandbreite reservieren und gegebenenfalls zentral verwalten. Bei der 1:N-Beziehung des Multicasts ergeben sich allerdings an den N Standorten schon aufgrund der unterschiedlichen Entfernung zur Quelle verschiedene Laufzeiten und Laufzeitschwankungen. Für das (wichtige) Reporting ist das problematisch.

VoIP[4] profitiert besonders vom Bandbreitenmanagement. Für die Echtzeit-Übertragung von Sprache senden die Protokolle viele kleine Pakete, die mit geringer und konstanter Verzögerung ans Ziel gelangen müssen. Die VoIP-Anwendung benutzen so genannte Codes (Encoder und Decoder), um Audio-, Video- und Steuerdaten platzsparend in IP-Pakete zu kapseln. Die für Sprache am häufigsten verwendeten Codes ITU-T G.711 und G.723.1 liefern sehr kleine IP-Pakete (78 Bytes und 218 Bytes).

Die RTP-Übertragung (Realtime Transport Protocol) fällt durch einen enormen Overhead bei Datenmenge und Paketzahl auf (Tabelle 1). Sie verbraucht mehr Rechenzeit in Router und Firewall als große FTP-Datenpakete, die für hohe Datenmengen nur wenige Routing- und Firewalling-Entscheidungen erfordern. Da das Netz große und kleine Pakete hintereinander transportiert, müssen die RTP-Daten häufig warten, was zu starken Laufzeitschwankungen führt.

Seit Kernelversion 2.4 ist zum Einsatz von Bandbreitenmanagement kein Neukompilieren des Kernels mehr erforderlich (siehe Artikel zu QDisc in diesem Heft). Es genügt, die Userspace-Tools IProute2 und TCng zu installieren und zu konfigurieren (siehe Artikel in diesem Heft). Wo und wie man QoS einsetzt, hängt unter anderem von der Bandbreite des Internetzugangs und den Applikationen ab, aber auch davon, ob es nur einen oder mehrere Standorte betrifft (so genanntes End-to-End-QoS).

QoS je nach Bandbreiten

Ist die Bandbreite der WAN- oder Internetverbindung schmalbandig, etwa kleiner als 2 MBit/s, genügen relativ einfache Installationen. Sie nivellieren den Netzwerkverkehr, erkennen zu Bandbreiten-hungrige User, Applikationen oder Sessions und teilen die Ressourcen fairer zu, etwa durch eine andere Queueing Discipline (zum Beispiel SFQ, Stochastical Fairness Queueing). E

Bei WAN-Verbindungen und schnellen Internetzugängen (ab 34 MBit/s) ist mehr nötig. Um den Überblick zu behalten, partitioniert das Management die verfügbare Bandbreite in einzelne kleinere Kanäle und kontrolliert den Zugang zu diesen Ressourcen. Jeder Kanal erhält eigene Eigenschaften bei Delay und Jitter (wichtig für Sprache) sowie Bandbreite und Paketverlust. Das Bandbreitenmanagement definiert und überwacht diese Parameter.

Bei flotten Zugängen darf die Quelle nicht einfach mit maximaler Geschwindigkeit senden, sie sollte auch dafür sorgen, dass die Daten in verträglichen Portionen beim Empfänger ankommen. Diese freiwillige Zurückhaltung ist um so wichtiger, je langsamer das Netz des Empfängers angebunden ist (siehe Kasten “Queueing, Shaping und QoS”).

Schlange stehen

Linux unterscheidet zwischen Traffic Shaping und Traffic Policing (siehe Abbildung 1). Beim Traffic Shaping optimiert das System den ausgehenden Netzverkehr, zum Beispiel per QDiscs (Queueing Disciplines). Traffic Policing ist das gezielte Verwerfen (Drop) ankommender Pakete. Gegenwärtig kann Linux ohne Patches den Inbound-Netzwerkverkehr nicht queuen (also durch Shaping beeinflussen).

Eine Übersicht gängiger QDiscs zeigt Tabelle 3. Sie sind in zwei Kategorien eingeteilt: QDisc mit Klassifizierung der Pakete (Classfull Queues) und ohne Klassifizierung (Classless Queues). Classfull Queues bereiten das Aufteilen der verfügbaren Bandbreite in kleinere Kanäle vor. Das Klassifizieren ist auch sinnvoll, wenn der Provider Diffserv (RFC 2474) unterstützt. Dann ist es wichtig, die Daten für die einzelnen Diffserv-Klassen passend aufzubereiten. Hinter diesen Klassen stecken meist unterschiedliche SLAs (Service Level Agreements), die zum Beispiel andere Werte für Latency und Jitter im ISP-Netz garantieren.

Classless Queues sind hauptsächlich für das Traffic Engineering an einer einzelnen Position im Netzwerk relevant. Hier will der Betreiber durch veränderte QDiscs die Bandbreiten einzelner Hosts oder Applikationen limitieren oder die Wartezeiten fair verteilen.

Das so genannte Token Bucket (TBF, siehe Kasten “Theorie des Token Bucket Filter”) wird von Geräten mit Classfull und Classless Queues genutzt. Die Implementierung einzelner QDiscs unterscheidet sich je nach Hersteller. Der TBF ist in der Praxis wichtig, weil er weitgehend generisch arbeitet und sich gut skalieren lässt. Er eignet sich zum Verlangsamen von Netzwerkverkehr und zur Kontrolle des Durchgangsverkehrs auf Routern. TBF ist auch in Ciscos Router-Betriebssystem IOS für Committed Access Rates (CAR) und Generic Traffic Shaping (GTS) zuständig.

Implementierungen und Produkte

Wer ein kommerzielles Produkt oder eine Appliance zum Bandbreitenmanagement einsetzt, braucht sich nicht mit der Theorie von Token Bucket Filter und QDisc zu belasten. Fast alle Hersteller haben GUIs entwickelt, die zwar Informationen über Bandbreiten, Ports, Protokolle und Applikationen wiedergeben, aber nichts zu den verwendeten Queues aussagen. Für das tiefere Verständnis der Techniken und Abläufe ist dieses Wissen aber von Vorteil.

Bandbreitenmanagement betreibt man sinnvollerweise direkt auf dem Zugangsrouter zum WAN oder in Form einer Layer-2-Bridge zwischen Access-Router und LAN (Abbildung 1). Die Bridge-Variante ist sehr komfortabel, sie erspart dem Admin das Aufteilen des internen Netzes in weitere Subnetze.

Allerdings entsteht damit ein zusätzlicher Single Point of Failure. Mit einer herkömmlichen Workstation als Bandwidth-Broker ist das kaum zu verhindern. Manche Appliances vermeiden dieses Risiko durch ein so genanntes Fail-open-Verfahren. Im stromlosen Zustand lassen sie den Netzwerkverkehr ungehindert fließen, ganz wie ein einfaches Netzwerkkabel.

Zwei Einsatzfelder sind zu unterscheiden: erstens das Bandbreitenmanagement auf einem einzelnen Netzwerkelement oder WAN-Link (zum Beispiel mit Net Equalizer) und zweitens QoS von Ende zu Ende, zum Beispiel mit IPanema[1]. Für VoIP-Anwendungen ist Ende-zu-Ende-QoS ideal. Traffic Control an einem einzelnen Knoten ist aber ebenfalls hilfreich.

Es kann zum Beispiel sein, dass vor einem sehr kleinen VoIP-Paket ein großes FTP-Datenpaket kommt. Ein gewöhnlicher Router verarbeitet die Pakete nacheinander. Wie lange das dauert, hängt von der Geschwindigkeit des WAN-Links ab, nicht von der Leistung des Routers. Ohne Bandbreitenmanagement muss das kleine VoIP-Paket warten, bis das FTP-Datenpaket den Router verlassen hat. Das erhöht Latenzzeit und Jitter. Bei gutem Queue-Management landen kleine Pakete in eigenen Warteschlangen (eine Prio-QDisc), die öfter an die Reihe kommen.

End-to-End-QoS braucht für eine durchgängige Implementierung eine stimmige Konfiguration aller Komponenten. Das geht zwar auch manuell oder per Skripting, der komplexe Sachverhalt ist mit einem zentralen Bandwidth-Broker und einem übersichtlichen GUI (wie bei IPanema) jedoch leichter zu überblicken.

Abbildung 2: In der Tocken-Bucket-Theorie leitet ein Förderband die Netzwerkpakete am Filter vorbei. Der Filter muss jedes Paket mit einem Token versehen (Aufkleber). Die Aufkleber kommen in regelmäßigen Abständen aus dem Rohr, als Reserve gibt es den Stapel.

IPanema

Eine typische IPanema-Installation besteht aus mindestens einer Supervising Console (genannt IP-Boss) und mehreren IP-Engines. Die Engines arbeiten als Traffic Shaper direkt hinter dem Zugangsrouter. Der Hersteller vertreibt diese Linux-basierte Appliance in verschiedenen Ausführungen (siehe Abbildung 3). Welche Distribution und welche Kernelversion er in den Appliances einsetzt, verriet der Hersteller auf Anfrage leider nicht. Der IP-Boss läuft unter Solaris oder Windows 2000.

Abbildung 4 zeigt IPanema-IP-Engines im Einsatz als Layer-2-Bridge hinter den Access-Routern aller Standorte eines Unternehmens. Damit partitioniert sie Mietleitungen in kleinere Kanäle, kontrolliert den Zugang einzelner Applikationen zu den Ressourcen und gestaltet den Traffic Flow passend zu den Kapazitäten der fernen Standorte (siehe Kasten “Queueing, Shaping und QoS”).

Interessanterweise berücksichtigt IPanema auch Layer-7-Eigenschaften. Die reine Unterteilung eines WAN-Links in Kanäle hilft wenig, wenn sich in diesem wieder alle Pakete im freien Wettbewerb befinden. Mit IPanema sind Konfigurationen möglich, die jeder Session oder jeder Applikation eine Bandbreite garantieren, solange der Link nicht ausgelastet ist. Danach entscheidet die so genannte Criticality (Terminologie des Herstellers), die Appliance bevorzugt innerhalb eines Kanals die kritischeren Applikationen und verzögert unwichtige.

Abbildung 3: Das Highend-Produkt aus der IPanema-Appliance-Reihe. Diese Box kümmert sich um das Traffic Shaping am Gigabit-Internetzugang. Sie stimmt sich dazu mit den Gegenstellen ab, um Quality of Service von Ende zu Ende festzusetzen. Die Konfiguration stammt von einer Workstation mit IP-Boss.

Viele Standorte

Der Einsatz bei einer Firma mit drei Standorten ist in Abbildung 4 skizziert. End-to-End-QoS gelingt in diesem Szenario am besten, wenn die Firma zusätzlich ein IP-VPN beim Provider kauft und es der Appliance lediglich überlässt, die Bandbreitenverteilung zu optimieren. IP-VPNs vernetzen Standorte über die Infrastruktur des Internetproviders, etwa mit MPLS (Multi Protocol Label Switching). Da IP-VPNs das Backbone des Providers nutzen, lassen sich einfach N:N-Beziehungen herstellen und damit Direktleitungen einsparen oder ATM-Ringe vermeiden. Ähnlich wie bei Mietleitungen sind mit IP-VPNs auch garantierte Bandbreiten verbunden.

Häufig genügt es aber bereits, eine Internetverbindung fester Bandbreite bei einem guten Provider einzukaufen. Viele Zusatzmerkmale kosten mehr, als sie nutzen. Ein guter ISP sollte die gemietete Bandbreite im eigenen Backbone auch dann gewährleisten, wenn der Kunde keine zusätzlichen IP-VPNs oder QoS-Merkmale kauft. Das geht aber nur, wenn der Provider sein Backbone nicht überbucht. Sind zwei Standorte mit 34 MBit/s über den gleichen ISP angebunden, sollten die 34 MBit/s zwischen beiden Standorten auch ohne Zusatzmerkmale bereitstehen.

Net Equalizer

Von AP-Connections[2] ist ein Bandbreitenmanager in zwei Varianten erhältlich. Die GPL-Version muss ohne GUI auskommen (Bandwidth Arbitrator), während die kommerzielle Ausführung ein Web-basiertes GUI enthält (Net Equalizer, Abbildung 5). Das Produkt gibt es als bootbare CD-ROM, basierend auf BBC-Linux[3], oder als Appliance (Abbildung 6).

Nach dem Booten und der Grundkonfiguration (Interface-IP-Adressen, Bandbreiten) befindet sich der Net Equalizer in einem Defaultmodus, der den Netzwerkverkehr nivelliert. Er identifiziert allzu anspruchsvolle Sessions und verlangsamt sie. HTTP, Chat und SMTP-Verkehr tastet er nicht an. Vermutlich ist hierzu eine SFQ im Einsatz.

AP-Connections vertreibt die kleinste Net-Equalizer-Appliance eigenartigerweise erst ab einer Stückzahl von fünf Geräten. Aus Sicht des Autors wäre die Appliance aber auch für Bandbreitenmanagement an einzelnen Standorten oder an einem einzelnen WAN-Link geeignet, etwa um die Warteschlangen zu verwalten und Traffic-Spitzen abzufangen. Dafür spricht auch, dass es keine zentrale Management-Plattform gibt.

Net Equalizer ist gut geeignet für Unternehmen, die ihren Usern P2P-Applikationen erlauben, aber zugleich sicherstellen möchten, dass dadurch nicht zuviel Bandbreite verloren geht. Zusätzlich nivelliert das Produkt Netzverkehr, der durch unerwartete Hintergrundapplikationen entsteht, zum Beispiel Webradio oder Updates von Applikationen.

Abbildung 4: Beim Ende-zu-Ende-QoS kooperieren die Traffic-Shaping-Installationen der einzelnen Standorte einer Firma. Beispielsweise bei den Produkten von IPanema ist der zentrale IP-Boss für das Meta-Management zuständig, er konfiguriert die Appliances namens IP-Engine an jedem Standort.

Abbildung 5: Mit der Weboberfläche von Net Equalizer ist es recht einfach, den Netzverkehr zu beschränken. Hier sorgt der Admin dafür, dass Gnutella maximal 150 KBit/s Bandbreite erhält.

Signalling und Routing

Wie Tabelle 4 zeigt, besteht Traffic Engineering nicht nur aus Bandbreitenmanagement. Zu den beschriebenen Ausschnitten Shaping, Policing und Scheduling kommen Monitoring und Reporting (Evaluierung) sowie Human Shaping: Die Admins und User müssen miteinander sprechen und ihre Chefs überzeugen. Weitere Traffic-Engineering-Techniken sind Signalling und Routing.

Traffic Engineering durch Routing ist besonders interessant in einem weit verteilten Userkreis, der sich nicht unter einer administrativen Hoheit befindet. In der Highend-Liga konnten sich die BSD-basierten Produkte des Herstellers F5 Networks etablieren[7]. F5 unterscheidet zwischen Local und Global Traffic Management. Fürs Local Traffic Management vertreibt der Hersteller eine Appliance, die den Netzwerkverkehr ausgewählter Applikationen sichert und zum Teil mit Mitteln von Layer 7 des OSI-Modells optimiert.

Abbildung 6: Die Net-Equalizer-Appliance Serie 500. Sie arbeitet als transparente Bridge zwischen Internetzugang und lokalem Netz.

Unter Global Traffic Management vertreibt F5 die 3DNS-Appliance, die unter anderem Traffic Management durch Routing beherrscht. Der Kundenkreis dieser Lösungen ist aber eher im Online-Geschäft zu finden, vor allem bei den Betreibern sehr populärer Webseiten und nicht bei Unternehmen, die ihre WAN-Links optimieren möchten.

In Form gebracht

Es kaum möglich, Ordnung in das Chaos aus ungenormten Begriffen, Terminologien und Modewörtern im Traffic Engineering zu bringen. QoS im Sinne eines Best-Effort-Ansatzes, der IPv4-Netzwerke verbessert und Verkehrsspitzen abmildert, ist aber an vielen Stellen sehr sinnvoll. Der Endnutzer bemerkt die Vorteile eines erfolgreichen Bandbreitenmanagements nur indirekt, daher setzt es sich – ähnlich wie IPv6 – nur langsam durch. Wer heute Traffic Engineering betreiben möchte, findet dennoch eine große Auswahl von geeigneten Techniken und Produkten. (fjl)