VoIP/QoS im Wohnheim Netz -
Ein Erfahrungsbericht

Kapitel

Einleitung:

Ich arbeite neben meinem Studium als studentische Hilfskraft im Rechenzentrum der FHTE. Ich wohne in einem Studentenwohnheim, welches mit Optischen Richtfunk an die FHTE angebunden ist. Es kommt des öfteren vor, dass ich von meinem Zimmer aus für das Rechenzentrum tätig bin. Unter anderem muss ich dabei auch Telefongespräche mit meinen Kollegen führen, die ich leider kostenpflichtig über das öffentliche Telefonnetz führen muss. Mich ärgerte dabei, dass ich nicht die bereits vorhande Ethernetanbindung zwischen Wohnheim <-> FHTE verwenden konnte. Im Rahmen meines Praxissemsters bei der Firma
Circular Informationssysteme GmbH bekam ich die Möglichkeit das Thema "Voice-over-IP" hinsichtlich folgender Punkte näher zu untersuchen: Im folgenden möchte ich den Weg aufzeigen, der uns ermöglichte Gespräche zwischen meinem Wohnheimzimmer und dem RZ über VoIP zu realisieren. Da die Art der Realisierung etwas ungewöhnlich ist, hielt ich es für sinnvoll sämtliche Schritte zu dokumentieren und online zustellen.

Wohnheimnetz

Anbindung Wohnheim an die FHTE

Das Wohnheimnetz ist optisch (Produktname: CBL LED-LINK 300) an die FHTE (Hochschulzentrum) mit 10 Mbit/s angebunden. Bei Nebel und Regen führt das teilweise zu beeinträchtigungen der Netzanbindung. Selbst Blitze lassen die Netzverbindung kurz einfrieren.
Bis vor kurzem war die Strecke noch auf Half-Duplex eingestellt, da für die Konvertierung von TP-Kabel (Anschluss des Switch, gelbes Kabel) auf LWL (Anschluss der Optischen Richtfunkantenne) ein HUB mit AUI-LWL Konverter verwendet wurde. (unten im Bild)

Ab 17.06.2005 wurde die Strecke auf full-duplex umgestellt, nachdem full-duplex fähige Medienconverter an beide Endpunkte (Wohnheim/HZE) aufgestellt wurden. (oben im Bild, nicht angeschlossen)

Die Anbindung ist dabei auf Layer2 transparent, dass heist das Wohnheim wird nicht zur FHTE geroutet sondern gebridged. Das Wohnheim steckt an einem 10 Mbit/s Switchport an der FHTE und hat ein eigenes VLAN an der FHTE. Das RZ der FHTE stellt für dieses VLAN einen eigenen Gateway mit DNS&DHCP zur Verfügung. Um Netzdienste ausserhalb dieses VLANs nutzen zu können, müssen sich die Bewohner an einem VPN-Gateway anmelden.

Netzdaten:

Netzadresse 10.42.0.0/16
Uni-Linuxrouter 10.42.0.1
Patrick Linuxrouter 10.42.0.9

Wohnheiminfrastruktur

Im Wohnheim gibt es 4 HP 4108gl Switches mit jeweils 72 x 10/100 Mbit/s Switchports sowie einen HP2524 mit 24 Switchports. Die 5 Switches sind untereinander mit 1 GBit/s Uplinks miteinander verbunden. Alle Zimmer sind dabei im gleichen VLAN. Ausnahme: Ein Bewohner verstöst gegen die Wohnheimnetzregeln , dann wird er in ein "Wurmnetz" gesteckt wo er im Browser eine Sperrseite zu Gesicht bekommt.

Erste Erfahrung mit VoIP in bestehender Infrastruktur

Bei den ersten Tests mit SIP (über sipgate) waren oft Störungen bemerkbar. Das hat mich auch nicht verwundert, da das Wohnheim-MRTG auch ausgelastete Tunnelendpunkte anzeigte. Erstaunlicherweise funktionierte Skype über unsere "verstopften" Leitungen ziemlich gut. Da ich VoIP aber gerne mit dem Standard SIP realisieren wollte, musste ich meine Tests an dieser Stelle abbrechen. Ich musste mich erst in das Thema QoS/TrafficShaping einarbeiten, um VoIP mit SIP im Wohnheimnetz ermöglichen zu können.

VoIP Qualität

Die Qualität von VoiP kann an 3 Punkten festgemacht werden:
Verwendeter Audio Codec, Latenz/Jitterbuffer, Paketverlust

Codec Mit dem Codec wird bestimmt, wie gut die Sprachqualität sein soll. Je besser, desto höher die benötigte Bandbreite. In meinem Test wurde der Codec G711u (ISDN-Qualität) verwendet, da dem Wohnheim genügend Bandbreite zur Verfügung steht

Latenz Die Latenz gibt an, mit welcher Verzögerung die Sprachpakete zum Gesprächspartner gelangen. Als Jitter bezeichnet man die zeitliche Schwankung zwischen dem Empfang von zwei Datenpaketen. Um große zeitliche Schwankungen zu kompensieren werden sogenannte "Pufferspeicher" (Buffer) eingesetzt. Die Größe des Pufferspeicher muss immer mit Beachtung der Laufzeit geschehen. Ein zu groß gewählter Speicher kann zu einer Verschlechterung der Laufzeit führen. Folgende Tabelle gibt eine kleine Übersicht über die Latenzen. Bei DSL kann man mit der Option "Fastpath" die Latenz auf bis zu 40ms verringern.

bis 50ms VoIP perfekt
bis 100ms Voip noch möglich
ab 100ms man fällt sich Gegenseitig ins Wort
ab 150ms deutliche Verzögerungen, i.d.R. Paketverluste, Gespräch nahezu unmöglich

Paketverlust Auf einer schlechten Übertragungsstrecke können auch Pakete verloren gehen. Wenn die Pakete an einem überlasteten Router gelangen, so sollte mittels Priorisierung sichergestellt werden, dass VoIP-Pakete immer den Vorzug bekommen. Paketverluste können nicht ausgeglichen werden, indem sie neu wiederholt werden würden. Ein Wiederholung wäre in der Regel zu spät und würde den Gesprächspartner nur verwirren. Den Verlust eines Sprachpakets nimmt der Gesprächsparter in Form eines Knacksens wahr.

Einführung QoS

QoS (Quality-of-Service) bezeichnet die Priorisierung von IP-Datenpaketen anhand bestimmter Merkmale und Eigenschaften. Mit diesen Mechanismen ist es möglich, z.B. Voice-over-IP, welches einen verzögerungsfreien und kontinuierlichen Datenstrom benötigt, stärker zu bevorzugen als das Herunterladen von einem Dateiserver oder den Aufruf von Webseiten.

TrafficShaping ist dabei eine Unterdisziplin von QoS.

Im Folgenden werden 2 Begriffe öfters verwendet:

Wie in der
Abbildung zu sehen ist, stauen sich in einer Überlastsituation sämtliche Pakete an den Tunnelenden des LED-LINK 300 bzw. am daran angeschlossenen Switchport. Diese Tunnelenden verfügen leider über keine QoS-fähigen Warteschlangen (Queues) - sie arbeiten nach dem FIFO (first-in first-out) Prinzip. Logische Kosequenz: Eine QoS-fähige Warteschlange muss in Form eines Routers oder Bridge vor die Tunnelendpunkte angeschlossen werden.

Zu beachten: Es muss sichergestellt sein, dass der neue Bottleneck nicht mehr an den Tunnelendpunkten (LED-LINK 300) anliegt, sondern an die davorgeschalteten Netzkomponenten vorverlagert wird.
Dazu muss die Geschwindigkeit an den Bottlenecks künstlich auf ca 95% der höchstmöglichen Bandbreite limitiert werden, damit die Queues an den Tunnelendpunkten immer leer sind und somit ankommende Pakete sofort verschickt werden können. Durch das limitieren der Bandbreite auf einer QoS-fähigen Queue werden zwangsläufig Pakete verworfen. Dies ist nicht schlimm, da übergeordnete Protokolle (z.b. TCP) sicherstellen, dass jedes Paket ankommt. Desweiteren wird durch das gezielte "wegwerfen" von Paketen der Durchsatz durch TCP selbst automatisch gesenkt. UDP ist auch kein Problem, da sich die übergeordnete Applikation, die UDP verwendet selber um die Sicherung kümmern muss.

TrafficShaping ist übrigens nur für ausgehenden Verkehr möglich. Man kann nicht limitieren, wieviel ein Partnerknoten einem senden soll. Es kann lediglich limitiert werden, wieviel zu einem Partnerknoten gesendet werden soll.

Netzkomponenten

Bezüglich der Implementierung von den notwendigen Netzkomponenten hatte ich mir Bedingungen aufgestellt, an die ich mich halten wollte:

Bedingungen:

  1. geringe Kosten
    wenn möglich soll ausgemusterte FHTE-Hardware verwendet werden
  2. OpenSource Komponenten
  3. Ursprungszustand soll leicht wiederherstellbar sein (kein QoS)
  4. RZ der FHTE soll möglichst nicht beansprucht werden (zu wenig verfügbares Personal)
  5. Die Bewohner sollen keine Netzveränderung wahrnehmen z.b in Form eines veränderten Adressbereichs

Bottleneck Wohnheim (zu HZE)

Wie in der
Layer2-Abbildung bereits zu sehen war, sind die Bewohner direkt mit dem Uni Linuxrouter verbunden. Um nun den Verkehr kontrollieren zu können, muss eine Netzkomponenten dazwischen eingefügt werden. Um eine Rekonfiguration der Adressbereiche zu verhindern, schied das einfügen eines Routers im Wohnheim aus. Daher wurde eine Bridge in Erwägung gezogen. Eine Bridge verbindet 2 Netze miteinander auf OSI Layer 2.

Da die Bridge nichts anderes machen sollte ausser Netzverkehr zu priorisieren, gab es keine grosse Anforderung an die Hardware. Das RZ der FHTE hat mir dazu einen P200 mit 3x Netzwerkkarten zur Verfügung gestellt. Um mit Linux Bridgen zu können, sind mind. 2 Netzkarten notwendig. Die 3. Netzwerkkarte wurde nur aus Redundanzgründen eingebaut, damit über ein "Backbone-Vlan" die Administration der Linuxbridge durchgeführt werden kann, sollte es mit dem Bridging Schwierigkeiten geben.

Anschluss Bridge an Wohnheim Switch

Die Bridge wollte ich nicht direkt zwischen der optischen Richtfunktantenne und einem Switchport anschliessen, da bei einem Ausfall der Bridge auch das Backbone-VLAN nicht mehr erreichbar wäre. Über das Backbone-VLAN werden z.b. die Switches administriert. Das Backbone-VLAN wird mittels 802.1q auch zwischen Wohnehim <-> HZE mitübertragen. Ich wollte sicherstellen, dass im Notfall die Bewohner wieder direkt am Uplink angeschlossen werden können und die Bridge umgangen werden kann.

Dies war nur wie folgt möglich: Die Bewohner wurden im VLAN1 (default) belassen, aber der HZE-Uplink zum neuen VLAN10 (Uplink, native Vlan) zugeordnet. Somit sind diese beiden Netze getrennt, es sei denn eine Bridge verbindet diese beiden VLANS über 2 Switchports miteinander. VLAN43 (Backbone-VLAN) ist weiterhin direkt aus dem HZE erreichbar, da das Vlan weitherhin mit 802.1q auf den Uplink-Switchport übertragen wird. Sollte die Linuxbridge nun ausfallen, so kann der Netzverkehr für die Bewohner wiederhergestellt werden, indem über VLAN43 der Uplink wieder auf VLAN1 (native Vlan) zugeordnet werden kann.

Eine spezielle Eigenschaft von Switchen kann uns bei unserem Vorhaben ein Problem bereiten: Normalerweise merkt sich ein Switch den Switchport, an dem eine MAC-Adresse gesichtet wurde. Taucht die MAC-Adresse nun an unterschiedlichen Switchports auf, so kann das den Switch verwirren (obwohl es unterschiedliche VLANS wären). Er würde dann ständig den Switchport für diese MAC-Adresse aktualisieren, so dass die Ethernetframes nie zu Ihrem Ziel gelangen würden. Dieses Problem kann auftreten, wenn die Linuxbridge 2 Switchports (VLAN1, VLAN10) miteinander verbindet. Der HP4108GL kann damit umgehen, da er über eine sogenannte "Multiple Forwarding Database" verfügt, die eine MAC-Adresse nicht nur einem Switchport sondern auch einem VLAN zuordnen kann. Ältere bzw. billigere Switches (z.b. HP2524) verfügen nur über eine "Single Forwarding Database" und zeigen o.g. Fehlverhalten. Dieses Fehlverhalten könnte man mit "mac-nat" auf der Linuxbridge beheben, ist jdoch kompliziert anzuwenden.

Da im 8. Obergeschoss keine 3 Switchports mehr frei waren, musste ich VLAN10 bis zu dem Switch in den 2. Untergeschoss weiterleiten. Dort wurde die LinuxBridge dann jeweils mit einer NIC mit VLAN1 (hze), VLAN10(bewohner) und VLAN43(Backbone) verbunden. Dies ist auch im neuen Netzplan zu sehen.

Bottleneck HZE (zu Wohnheim)

Normalerweise läuft der Netzwerkverkehr zwischen Bewohner und "Uni LinuxRouter". Damit ich meine QoS-Versuche hätte durchführen können, hätte ich Zugriff auf eben diesen Router benötigt. Dies ist aus nachvollziehbaren Sicherheitsgründen nicht erwünscht. Ich habe im HZE bereits einen eigenen Server, den ich für diverse Tests benutze. Ein Lösung wäre gewesen, einfach eine 2. Netzwerkkarte einzubauen und ihn als Bridge zu konfigurieren (genauso wie am Bottleneck Wohnheim zu HZE). Schliesslich ist mein Server im HZE nicht ausgelastet. Allerdings wollte ich das Ausfallsicherheitsgründen nicht haben: Wenn mein HZE Server ausgefallen wäre, dann wäre der gesamte Internetverkehr im Wom zusammengebrochen.
Wir entschlossen uns daher dazu, dass der "Uni LinuxRouter" den gesamten Verkehr an mich routen soll. Das bedeutet, dass sämtliche Pakete zu meinem Router verschickt werden, so dass ich sie wiederum in das Wohnheimnetz routen muss. Die Besonderheit hier ist, dass obwohl der Uni LinuxRouter direkt am Wohnheimsubnetz angeschlossen ist, die Pakete nicht direkt zustellt, obwohl er es könnte. Somit entsteht ein Konstrukt, dass ich selber als "Dreieck Routing" bezeichne (bei IPv6/Mobile-IP wird ein ähnliches Verfahren "Triangle Routing" gennant). Auf das "Dreieck Routing" gehe ich im nächsten Abschnitt näher ein.
Auf dem Uni Linuxrouter musste die Routingtabelle angepasst werden:.
ip route del 10.42.0.0/16 dev eth0
ip route add 10.42.0.9 dev eth0 
ip route add 10.42.0.0/17 via 10.42.0.9 dev eth0 
Meinem LinuxRouter muss darüberhinaus mitgeteilt werden, dass er Routing für das Subnetz 10.42.0.0/16 erlauben soll
iptables -A FORWARD -i eth1.45 -d 10.42.0.0/16 -j ACCEPT
Vorteil im Notfall:
- Die RZ-Unixadmins können ohne Hilfe von mir oder einem RZ-Netzmanager den Ursprungszustand wieder herstellen, indem Sie die Routingtabelle wieder zurücksetzen.
- Oder aber ich könnte im Wohnheim selbst die IP meines HZE-Linuxrouters eintragen, so dass alle Pakete vom Uni LinuxRouter einen nexthop haben, zu dem die Pakete weitergeroutet werden können. Beispielsweise könnte meine WOM-LinuxBridge diese Routingfunktionalität übernehmen. Mein Problem ist, dass ich selber keine Zugang zu den Serverräumen des RZ habe und dort meinen LinuxRouter nicht schnell genug instandsetzen könnte.

Neue Netzstruktur (QoS-fähig)

In dem neuen Netzplan ist nun deutlich zu sehen, wie die 2 Bottleneck auf QoS-fähige Endpunkte verschoben worden ist. Es sind auch gleich die 3 Hardphones eingezeichnet, die für meine späteren Tests von Bedeutung sind.

Exkurs: "Dreieck Routing"

Wenn ich von meiner Workstation (10.42.0.8) den Uni Linuxrouter anpinge (10.42.0.1) bekomme ich ganz normal "ICMP echo request" und "ICMP echo reply". Schaut man auf meiner Workstation mit
tcpdump -neq
genauer hin, so sieht man, dass mir nicht das Interface von Uni Linuxrouter sondern eine andere MAC (lila) das ICMP reply zurücksendet. Diese MAC gehört zu meinem Linuxrouter, der die ICMP Pakete von dem Uni Linuxrouter empfängt und an meine Workstation weiterroutet.

Ansicht Workstation

Wenn ich

tcpdump -neq
auf meinem Linuxrouter ausführe, dann sieht man in der 1. Zeile ganz genau, wie die ICMP reply Pakete vom Uni Linuxrouter (grün) zu meinem Linuxrouter (lila) gesendet werden, und anschliessend in Zeile 2 von meinem Linuxrouter (lila) zu meiner Workstation (türkis) zurückgeschickt werden. Die ICMP request Pakete sehe ich wiederum nicht auf meinem Linuxrouter, da diese Pakete weiterhin vom Client direkt an den Uni Linuxrouter gesendet werden. Der Client sendet immer direkt an den Uni Linuxrouter (10.42.0.1, grün), da er ihn mittels DHCP als default gateway eingetragen hat.


Ansicht Linuxrouter

Man sieht also, dass für den Client dieser Vorgang vollkommen transparent ist, da die IP-Adressen stimmen. Ping bzw. das Betriebssystem stellt keinen Fehler fest, da nur die Quell-/Ziel IP-Adressen wichtig sind. Die MAC-Adressen sind hierbei unerheblich.

QoS Strategien

Qos unter Linux ist eine schwere Materie, auf die ich nicht zufriedenstellend in diesem Bericht eingehen kann. Zum Einarbeiten seien folgende Links empfohlen: TrafficShaping bzw. QoS wird mit Linux mit dem eingebauten Tool tc erreicht. Ich habe mich für htb zum Einsatz als (classful) qdisc entschieden, da ich mit htb Prioritäten sowie vererbare Bandbreite managen kann. Die Bandbreite lässt sich dabei mittels Klassen weitervererben. Als Classifier habe ich iptables eingesetzt, da es mir die grösstmöglichste Freiheit beim klassifizieren der Pakete gab. Der in tc eingebaute u32-Filter bietet zu wenig Möglichkeiten und ist auch schwieriger zu bedienen.

Klassifizierungskriterium

Da jeder Bewohner einen eigenen VPN-Tunnel zur FHTE hat, ist es mir auf der Bridge nicht möglich Pakete aufgrund von Ziel-IP/Port zu klassifizieren. Unter Klassifzieren versteht man, das ich ein Paket einer bestimmte Queue zuordnen kann, die beispielsweise eine höhere Priorität als anderer Queues hat. Dies ist bei RTP-Paketen (RealTimeProtocol, Sprachdaten bei VoIP) oder SSH (interaktive Session) wünschenswert. Glücklicherweise setzen einige Applikationen das TOS bzw DSCP Feld im IP-Header. Das TOS-feld (Type-of-Service) -mittlerweile DSCP (Differentiated Services Code Point) genannt- trägt Informationen in sich, ob das Paket z.b. möglichst Schnell oder mit möglichst geringen Kosten ans Ziel soll. Beispielsweise setzt der OpenSSH-Client den TOS Wert auf 0x10 (geringe Verzögerung).
# tcpdump 
...
15:19:43.291403 134.108.60.203.42073 > 134.108.73.225.ssh: tcp 0 (DF) [tos 0x10]
15:19:43.291526 134.108.73.225.ssh > 134.108.60.203.42073: tcp 208 (DF) [tos 0x10]
...
Dieser TOS-Wert ist auch "aussen" auf einem ESP Paket sichtbar:
# tcpdump -n | grep ESP| grep tos
...
19:00:06.557399 802.1Q vlan#45 P1 192.168.42.254 > 10.42.0.117: ESP(spi=0x3aad716e,seq=0x30bf) [tos 0x10]
19:00:07.706505 802.1Q vlan#45 P1 192.168.42.254 > 10.42.0.98: ESP(spi=0x929fa54c,seq=0x4cf1) [tos 0x10]
...
Dieser Wert genutzt werden, um das Paket zu priorisieren. Hier noch ein Beispiel, wie (interaktive) SSH Pakete Priorisiert werden können.
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 10kbit ceil 100kbit prio 1
iptables -t mangle -A POSTROUTING -o eth0 -p tcp --dport 22 -m tos --tos ! 0x08 -j MARK --set-mark 6
tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 6 fw flowid 1:12
In der 1. Zeile lege ich die Queue an, in der 2. Zeile klassifiziere ich das Paket und in der 3. Zeile ordne ich aufgrund der Klassifzierung das Paket seiner Queue zu. In Zeile 2 wird der TOS-Value 0x08 ausgeschlossen, da es sich dabei um scp (Filetransfer over ssh) handelt, der nicht priorisiert werden muss.

Leider war keines der von mir getesteten Softphones in der Lage den TOS-Value zu setzen. Ein Möglichkeit wäre gewesen, auf "Patrick LinuxRouter" einen SipProxy zu installieren, damit SIP-Paktet an VPN vorbei die Bridge passieren können. Dann hätte ich aufgrund Quelle IP/Port eine priorisierung vornehmen können. Davon wurde mir allerdings abgeraten.

Implementierung von QoS auf den Netzkomponenten

Um die optimale QoS Strategie herauszufinden musste ich erst einige Tage herumexperimentieren. Mein jeweils aktuellstes TrafficShaping-Script ist hier verfügbar [qos-script]. Sobald ich an diesem Script irgendetwas ändere, lade ich das auch auf meine beiden Server.

Beim ersten Versuch wurde die gesamte Bandbreite für Up-/Download zu limitiert. Das Ergebnis lässt sich in Form von MRTG-Graphen visualisieren:
Der Verkehr von HZE zu Wohnheim ist grün dargestellt
Der Verkehr von Wohnheim zu HZE ist blau dargestellt

Im ersten Schritt wurde der Verkehr HZE zu Wohnheim limitiert. Die roten Ellipsen markieren den Unterschied.
Im zweiten Schritt wurde auch der Verkehr Wohnheim zu HZE limitiert.
Dieses Ergebnis hatte einen entscheidenden Nachteil, den mich die Wohnheimbewohner auch bald Wissen liesen: Dadurch, dass ich die Gesamtbandbreite für alle begrenze, kann ein einziger Bewohner denoch alle anderen anderen Bewohner empfindlich stören. Die Bewohner liesen mich wissen, das Skype, das vorher anstandslos lief nun nicht mehr lief. Genau genommen hatte sich für die Bewohner nichts verbessert, ausser das ich nun den Nachweis hatte, dass das TrafficShaping grundsätzlich funktioniert.

Versuch 1
Nach einigen Überlegungen war klar, dass ich den Verkehr nicht mehr als ganzes sondern für jeden einzelnen Host begrenzen muss. Das bedeutet, dass ich für jeden Host eine eigene Klasse sowie einen eigenen Filter setzen muss. Jan Horbach schreibt ist seiner Ausarbeitung [JAN], dass das Anlegen von mehreren hundert Filtern (=Classifiern) die Bandbreite auf einem 100 Mbit/s Interface auf ca. 50 Mbit/s verschlechtern kann. Da das Wohnheim sowieso nur mit 10 Mbit/s ausgestattet ist, kann man diese Erkenntnis getrost ignorieren.

Mit einer Schleife habe ich für alle Hosts im 10.42.0.0/24 Netz eine eigene Klasse sowie Filter angelegt. Für jeden Host habe ich dabei eine Obergrenze von 640Kbit/s festgelegt. Das sollte für Surfen & VoIP reichen. Sollte jemand im Wohnheim eine andere IP verwenden, als die vom DHCP-Server vergebenen, dann landet dieser Host in einer "default"-Klasse, die auch wiederum nur einige Kbit/s zur Verfügung hat. Der "Nachteil" an dieser Strategie ist, dass selbst wenn ein Host alleine im Netz aktiv ist, dass er nie mehr als 80 Kbit/s zugewiesen bekommt. Der Vorteil, dass nun das VoIP (SIP & Skype) nun ohne Probleme läuft, wiegt das aber wieder auf. Für SSH,ICMP und VoIP (SIP/RTP) habe ich spezielle Klassen mit erhöhter Priorität und eigens reserverierte Bandbreite erstellt. (Im Abschnitt "Test mit Round-Trip-Time" gibt es eine Kurzdemo zur Priorisierung von ICMP Paketen)

Desweiteren musste ich für ARP und DHCP Pakete eine eigene Klasse definieren, da sonst in einer Überlastsituation dieses Pakete verworfen werden würden. Dies kam bereits vor und hatte kurzeitig zu Verbindungsproblemen an den Clients geführt...

Versuch 2
Das Ergebniss vorneweg: Da ein Host nun nie mehr als 640Kbit/s (ca. 80 Kbyte/s) bekommen kann, sind im MRTG auch weniger Spitzen zu sehen. Das VoIP für jeden einzelen Bewohner läuft jetzt besser, da ein netzaktiver Bewohner nicht mehr alle Bewohner ausbremsen kann. VoIP Pakete werden nicht priorisiert, aber es steht nun insgesamt für jeden eine eigene Bandbreite zur Verfügung. Man spricht hierbei von "Überprovisionierung", da nun praktisch 50% der gesamten Leitungskapazität frei sind, so dass VoIP Pakete nahezu sofort ans Ziel gelangen. Einzig die Pakete von meinem Hardphone werden priorisiert, da es unverschlüsselt senden darf (die Firewall meines Linuxrouter aktzeptiert die IP meines Hardphones sowie ausgewählte UDP Ports)

Aber auch hier gibt es Grenzen: Wenn 15 Bewohner mit Höchstgeschwindigkeit Traffic verursachen würden, dann wäre die Kapazitätsgrenze wieder erreicht: 15 x 640 Kbits = 9600 Kbit/s ca. 10 Mbit/s. VoIP wäre dann nicht möglich. In der Praxis ist das im Wohnheim noch nicht aufgetaucht. Die Bewohner verusachen meist nur kurze Trafficspitzen z.b. wenn Sie sich eine Homepage anschauen, eine Email abrufen oder tatsächlich einmal ein Programm herunterladen

Das AbuseManagement ist auch einfacher geworden: Früher wurden Sperren manuell verhängt die ich dann auch wieder rückgängig machen musste. Neuerdings werden aufällige Hosts für einen bestimmten Zeitraum auf Bandbreiten kleiner 100Kbit/s limitiert. Dies ist ja jetzt problemlos möglich, da jeder Host eine eigene Klasse hat, die kontrolliert werden kann. Jan Horbach hat dafür ein Framework entwickelt (DynShaper), dass in Abhängigkeit des bereits angefallenden Traffics die Bandbreite eines einzelnen Hosts limitiert bzw. kontinuierlich herabsetzt [JAN]. Die RZ-Leitung wünscht langfristig TrafficShaping für Wohnheim <-> Internet. Das Problem in unserem Fall ist, dass ich die VPN-Pakte nicht inspizieren und nach FHTE-/Internet Traffic unterscheiden kann. Somit kann (sollte) DynShaper nicht im Wohnheimnetz eingesetzt werden, da sonst auch der Traffic in das FHTE-Netz (z.b. Zugriff auf ftp-Mirror, Linux-ISOs) bestraft werden würde, was allerdings nicht unsere Absicht ist.

Test mit Round-Trip-Time

Um einen oberflächlichen Nachweis zu erhalten, das meine QoS Konfiguration funktioniert, habe ich diverse Tests durchgeführt. Dieses Tests wurden alle von meinem Wohnheim-Desktop ausgeführt. Auch die folgenden Screenshots wurden darauf erstellt. Die Screenshots zeigen dabei immer folgendes:
1. Fall: QoS deaktiviert

Ich verursache Traffic indem ich mit "voller Kraft" eine Datei zum HZE hochlade. Gleichzeitig pinge ich diesen Server an. Die RTT ist dabei meistens bei ca. 100ms

2. Fall: QoS aktiviert

Traffishaping wird aktiviert.

Anmerkung: Die Messung stammt noch vor dem 17.06.2005. Damals war ich gezwungen wegen der half-duplex verbindung "asymetrisches" Trafficshaping durchzuführen d.h. ich haben den Verker von Wom zu HZE auf 1000 Kbit/s begrenzt und den Verkehr von HZE zu Wom auf 4300 Kbit/s. Dies tut hier allerdings nichts zu Sache, da dies auf den Ping-Test keine Auswirkung hat

Ich versuche weiterhin mit "voller Kraft" eine Datei zum HZE hochzuladen. Die Wohnheimbridge begrenzt allerdings die maximal zulässige Uploadgeschwindigkeit, so dass ich auf nicht mehr als 70 Kbyte/s (ca. 560 Kbit/s) komme. Gleichzeit ist zu sehen, dass die RTT meistens unterhalb von 2ms liegt. Es gibt wenige kleinere "Ausreiser" mit bis zu 20 ms. Die Qualität ist damit immer noch sichergestellt (s. Abschnitt "VoIP Qualität")

VoIP Telefone

Für Windows und Linux existieren diverse Softphones. Um die Softphones verwenden zu können, braucht man in der Regel Headsets, die man sich aufsetzen muss. Das ist teilweise "unbequem", da das Softphone im Hintergrund ständ aktiv sein muss und das Headset griffbereit. Meine RZ-Kollegen waren verständlicherweise nicht gewillt, meine Tests zu unterstützen.
Um die Aktzeptanz zu erhöhen hat mir das RZ 3 Grandstream BT-101 "Hardphones" zur Verfügung gestellt. Diese Telefone sehen aus wie herkömliche Telefone und lassen sich ebenso leicht bedienen. Ein Telefon wurde im Wohnheim, RZ-HZE, sowie bei mir im Praxissemesterbetrieb (Circular Informationssysteme GmbH) aufgestellt. Somit konnte ich die für mich interessanten Tests durchführen: VoIP über optischen Richtfunk mit QoS sowie Voip über WAN

Das gute dabei: Wenn im RZ das Telefon klingelt, dann wissen meine Kollegen immer gleich wer dran ist ;-)

Grandstream BT-101

Das wählen von IP-Adressen ist wie folgt möglich:
  1. Hörer abnehmen
  2. 'Menu' Taste drücken
  3. IP-Adresse eingeben, wobei jedes Byte immer 3 Stellen haben muss. Beispiel IP: 134.108.39.127 --> 134108039127
Nachteile des BT-101:
  • kein Adressbuch
  • Eingabe von Buchstaben muss mit Nummernblock kodiert werden
  • kein Hinweis wer oder wann jemand angerufen hat
  • kein DHCP möglich, wenn VLAN-tag eingestellt wird
Fazit: Das BT-101 ist ein einfaches Telefon, mit dem ohne jeglichen Komfort telefoniert werden kann. Da mein Praxissemester ein Kooperationsprojekt zwischen dem RZ der FHTE sowie Circular war, musste ich des öfteren mit meinen RZ-Kollegen telefonieren. Gegen Ende des Semesters fand dies teilweise nur noch über das BT-101 (und nicht mehr über das Festnetz). Die Qualität war hervorragend. Auch über meinen Wohnheimanschluss konnte ich komfortabel mit dem RZ in Kontakt bleiben. Das im Wohnheim eingeführte QoS stellte dabei die Qualität sicher.

Links

Danksagungen

Ich bedanke mich bei allen Beteiligten, die mich bei meinem Vorhaben unterstützt haben
Ressourcen, welche mir mit freundlicher Unterstützung vom RZ zur Verfügung gestellt wurden:
Letzte Aktualisierung Sun, 01 Apr 2007 13:50:42
Autor: Patrick Cervicek