Fischertechnik
AVR
Raspberry Pi
Elektronik
Netzwerk
Sonstiges


















Impressum

WAN-Simulator

Eigenschaften eines WAN

WAN steht für Wide Area Network und wird typischerweise für Verbindungen im Bereich von hundert bis mehrere Tausend Kilometer verwendet. Der Bereich zwischen LAN und WAN wird MAN oder Metropolitan Area Network bezeichnet.

Abschätzung der Latenzzeiten

Bei so langen Verbindungen entsteht signifikante Latenz, die einige Anwendungen verhindert und viele behindert. Die Latenz ist immer größer als die Entfernung auf der Luftlinie geteilt durch die Lichtgeschwindigkeit, da die genutzten Kabel nicht auf dem kürzesten Weg liegen und Kupfer- bzw. Glasfaserkabel Signale nicht genau mit Lichtgeschwindigkeit übertragen können. Eine gute Näherung ergibt sich mit einem Faktor von 1,5 für die Entfernung und 2/3 für die Signalgeschwindigkeit.
Latenz=(1,5*Entfernung) / ( 2/3 * Lichtgeschwindigkeit)
Latenz in Millisekunden=(1,5*Entfernung in Kilometern ) / 200
Entfernung Luftlinie in kmLatenz msRTT in ms
1000,751,5
2001,53
40036
6004,59

Realistisch liegen die Latenzzeiten noch höher, da die Carrier heute IP-basierte und damit Paket-vermittelnde Techniken einsetzen. Im Gegensatz zur früheren Multiplextechnik ergeben sich höhere Latenzen, die darüberhinaus auch noch schwanken (Jitter). Bei hohen Auslastungen werden Pakete verworfen bevor sie weitergeschickt werden können. Aus betriebswirschaftlicher Sicht ist es für die Carrier sinnvoll mehr Bandbreite zu verkaufen als sie im Backbone selber installiert haben (Überbuchung); in den Anschlussleitungen passt die Bandbreite noch und da die Kunden selten gleichzeitig die gekaufte und bezahlte Bandbreite gleichzeitig in Anspruch nehmen, passt es sogar meist auch im restlichen Netz. Meist heißt aber nicht immer und dieses führt zu sporadischen Paketverlusten.
Ein weiterer Effekt in den IP-Netzen der Carrier ist ein Reordering von Paketen. Wenn zwischen Quelle und Ziel mehrere Wege verfügbar sind, dann können sich Pakete gegenseitig überholen und somit in einer anderen Reihenfolge ankommen als sie versendet wurden. Dabei reicht es durchaus, dass unterschiedliche logische Wege verfügbar sind. Verfügen die eingesetzten Netzkoppelelemente zum Beispiel über unterschiedliche Wartenschlangen für unterschiedliche Paketgrößen, dann kann es schon passieren, dass auf nur einem physikalischen Weg ein kleines Paket schneller als ein großes am Ziel ankommt.

Einfluss auf Anwendungen

Anwendungsprogrammierer für Client-Server-Anwendungen haben häufig ein hochwertiges Entwicklungsumfeld; leistungstarke Clients die netzwerktechnisch unmittelbar neben potenten Servern stehen. So hält man gute Entwickler bei Laune.
Beim Ausrollen so entwickelter Anwendungen gibt es bei den Kunden dann immer wieder unerklärliche Performanceprobleme.
Mal ist die Bandbreite ein Problem, mal die Latenz und mal die Fehlerrate. Ganz selten auch mal die veränderte Paketreihenfolge.
Inzwischen gehört es bei vielen Entwicklern dazu, die Anwendung vor der Auslieferung bezüglich der Empfindlichkeit gegen die beschriebenen Faktoren zu testen. Schwieriger wird es für Kunden, die nach jahrelangem problemlosen Betrieb einer Anwendung umziehen oder die Server in ein entferntes Rechenzentrum auslagern. Die Anwendungsentwickler sind nicht greifbar und die verlagerten Server lassen sich nicht trivial zurückholen.
Ob jetzt vor einer Verlagerung, oder vor dem ersten Ausliefern einer Anwendung getestet wird, ist eine Testumgebung erforderlich, die idealerweise die oben genannten Faktoren gezielt steuern kann.
Die erforderliche Technik heißt WAN-Simulator oder auch WAN-Emulator. Diese gibt es fertig zu kaufen; sind aber für kleine Entwickler finanziell eine Hürde, die nicht jeder überwinden kann.

Prinzipieller Aufbau eines WAN-Simulators

Ein WAN-Simulator benötigt typischerweise drei Netzwerkkarten und wird über zwei von diesen in den Datenverkehr zwischen Client und Server eingeschleift. Das dritte Interface dient der Steuerung und ggf. auch dazu Messdaten (Traces) abzugreifen ohne die zu messende Kommunikationsbeziehung zu stören.

Selbstbau

Linux bringt schon seit Jahren alles mit, um einen WAN-Simulator zu bauen und vermutlich basieren viele der professionellen Systemen auch auf diesem Betriebssystem. Als ich jetzt einerseits den Bedarf nach einem WAN-Simulator hatte und andererseits inzwischen auch VLAN-taugliche Ethernet-Switches mein Eigen nennen darf, stand dem Selbstbau nicht mehr viel im Weg.
Mein Cubietruck schien mir ein guter Kompromiss unter Berücksichtigung der Leistungsdaten, der Kosten und der Transportfähigkeit. Im Gegensatz zum RaspberryPi bietet der Cubietruck ein im Prozessor sehr gut integriertes LAN-Interface mit Gigabit-Ethernet wo der RasPi nur ein USB-angebundenes 100Mbps-Interface zu bieten hat.

VLAN-tauglicher Switch

Ich verwende den NSW Netgear GS105Ev2 mit der Firmware V1.4.0.2. Dieser Switch ist klein und handlich und mit etwas über 20 € auch nicht zu teuer für fünf Gigabit-Ethernet-Ports. Ein Nachteil ist für mich allerdings, dass dieser Switch ausschließlich mit einem Windows-Rechner konfiguriert werden kann. Das erscheint mir nicht zeitgemäß und ist durchaus eine Einschränkung in Zeiten von Tablets und Smartphones. Von meinen Vorlieben für Linux-Rechnern will ich hier gar nicht reden.
Mit diesem Programm (ProSafe Plus Konfigurationsprogramm) kann jeder dieser Ports entweder als Trunk, also mit Zusatzinformationen gemäß 802.1q zu den virtuellen LAN konfiguriert werden, oder als "normaler" LAN-Anschluss ohne diese Zusatzinformationen in einem der vergebenen Netze.
Für meine Tests hat sich bewährt die Ports 1 und 2 in ein VLAN (1) zu konfigurieren, Port 3 als Trunk, Port 4 in VLAN 5 und Port 5 in VLAN 6. An Port 3 kommt dann der Cubietruck, an Port 4 der Client und an Port 5 der Server. Letztere Anschlüsse dürfen selbstverständlich beliebig getauscht werden.

Nachtrag Oktober 2016 zum NSW Netgear GS105Ev2

Inzwischen ist das fehlende WEB-Interface vorhanden und der oben beschrieben Nachteil somit Geschichte.

VLAN-Konfiguration auf dem Cubietruck

Sinn und Zweck ist es ja, aus dem einen LAN-Interface des Cubietrucks mehrere zu machen. Im konkreten Fall zwei, und das sind auf dem Switch die Ports 4 und 5.
Aus Linux-Sicht heißen die neuen Interfaces eth0.5 und eth0.6. Ohne die unten folgende interne Bridge könnten die Ports unabhängig voneinander genutzt werden. Mit geeigneter Switch- und Linux-Konfiguration wären so vier LAN-Interfaces möglich. Mit einem größeren Switch auch mehr. 

#!/bin/bash
modprobe 8021q

ip link add link eth0 name eth0.5 type vlan id 5
ip link add link eth0 name eth0.6 type vlan id 6
ip link set eth0 up
ip link set eth0.5 up
ip link set eth0.6 up
ifconfig eth0.5 0.0.0.0
ifconfig eth0.6 0.0.0.0

Bridge zwischen den VLAN

Die Daten des Clients sollen ja durch den WAN-Simulator zum Server gelangen und die Antworten des Servers wieder zurück zum Client. Dafür muss eine Verbindung zwischen den LAN-Interfaces eth0.5 und eth0.6 geschaffen werden. Im Ethernet wird dieses durch eine Bridge realisiert; hier muss also eine virtuelle innerhalb des Cubietrucks erstellt werden: 

#!/bin/bash
brctl addbr br0
brctl setfd br0 0
brctl addif br0 eth0.5
brctl addif br0 eth0.6
ifconfig br0 up

# IPv4-Adresse fuer In-band Mangement setzen:
ifconfig br0 10.0.0.3 netmask 255.255.255.0 up

# schalte alle Filter aus:
for f in /proc/sys/net/bridge/bridge-*; do echo 0 > $f; done

Software netem

Voraussetzung für die Nutzung der Netzwerkemulation netem ist ein passend konfigurierter Linux-Kernel. Alle meine bisherigen Systeme hatten die entsprechende Konfiguration enhalten:
Networking / Networking Options / QoS and/or fair queuing (*) / Network emulator (M)
Wenn der Kernel keine passende Unterstützung bietet, gibt es die Fehlermeldung
RTNETLINK answers: Operation not supported
Falls dieses passiert hilft ein neuer Kernel; zum Beispiel vom netten Daniel Andersen unter seiner Download-Seite http://dl.danand.de/cubieboard/ Den Kernel danand_a20_3_4_108_d.tgz hat er extra für mich mit diesen Kernel-Optionen gebaut; auch auf diesem Weg nocheinmal vielen Dank!



Die gute man-page zu netem gibt es auch im Netz unter http://lartc.org/manpages/tc.txt. 

#!/bin/bash

# neu anlegen (add)
tc qdisc add dev eth0.5 root netem delay 25ms loss 0.5%
tc qdisc add dev eth0.6 root netem delay 25ms loss 0.5%

# aendern (replace wirkt wie entfernen und sofort wieder neu anlegen)
# bei einigen Operationen ist der Wechsel mit change statt replace
# direkt moeglich.
#
tc qdisc replace dev eth0.5 root netem delay 0ms loss 0%
tc qdisc replace dev eth0.6 root netem delay 0ms loss 0%

Exkurs Warum ein neuer Kernel,

wenn doch alle meine bisherigen die richtigen Optionen hatte? Ein Entwickler hatte im Code des Ethernet-Treibers wohl Probleme im Umgang mit VLAN und hatte bei jedem Paket nach 802.1q eine Kernel-Ausgabe geschrieben. Dieses hat die Performance im konkreten Anwendungsfall soweit reduziert, dass keine vernünftigen Messungen möglich waren.

In-band versus Out-of-band Management

Im üblichen Einsatz eines WAN-Simulators erfolgt ein Out-of-Band Management, auch um einen Einfluss der Administration auf die simulierte WAN-Strecke sicher auszuschließen. Wenn zum Beispiel durch eine geignete zeitliche Abfolge die Steuerung von der Simulation getrennt werden kann, ist auch ein In-band Mangement möglich.
Im obigen Code-Ausschnitt zur Konfiguration der Bridge ist zu sehen, dass für das In-band Management eine IPv4-Adresse an das Bridge-Interface gebunden wurde.
Der Client hat hier die zentrale Rolle. Erst stellt er auf dem WAN-Simulator die Parameter ein, dann misst und protokolliert er die Antwortzeit eines ICMP-Echo-Pakets ("ping") und führt dann einen Filetransfer einer 100 MByte-Datei durch. Die vom Filetransferprogramm bereitgestellten Performancedaten werden ebenfalls protokolliert.

Performance mit diesem Testaufbau

Tests ohne Latenz und ohne Paketverlust zeigen die erreichbaren Transferraten. Diese liegen in der Größenordnung von 67 Mbps auf Anwendungsebene, also schon abzüglich der Protokoll-Header. Unter deren Berücksichtigung ist von mindestens 70 Mbps auszugehen. Unter optimaler Nutzung der TCP-Funktionalitäten sollte diese Übertragungsrate bei zunehmender Latenz nicht, bzw. nur minimal einbrechen solange es keine Paketverluste gibt (die Bandbreite bleibt ja bestehen und sollte idealerweise die Begrenzung der erreichbaren Übertragungsrate sein). Sollte aber die Fenstergröße zu klein, oder eine Blockung in der Anwendung vorliegen, reduziert sich die erreichbare Datenrate erheblich. Lotus Notes (inzwischen IBM) nutzt zum Beispiel in der Anwendung eine Blockgröße von nur 16 kByte und reagiert damit empfindlich auf hohe Latenzen. Viele SSL-Implementierungen nutzen die maximale Blockgröße der Verschlüsselung auch um auf eine Bestätigung von der Gegenseite zu warten, was ebenfalls als erhebliche Bremse wirken kann.
Ob die gemessene Obergrenze jetzt die Grenze der eingesetzten Hardware ist, muss ein Folgetest aufzeigen.

Messung scp auf Basis der openssh-Implementierung

In den folgenden Diagrammen sind die Ergenisse der ersten Messreihen dargestellt. Der Overhead für die Protokollschichten Ethernet, 802.1q, IP und TCP wurden nicht hineingerechnet; die Werte beziehen sich also auf die Werte, die tatsächlich bei der Anwendung "ankommen".
Es ist zu sehen, dass scp alleine durch Latenz signifikant an Performance verliert. Der Einfluss von Paketverlusten im Promillebereich ist dabei fast zu vernachlässigen. Oberhalb von 1 Prozent spielt die Latenz eine untergeordnete Rolle. Die Übertragungsrate bricht schon bei wenigen Millisekunden Latenz auf Werte unterhalb von 10 Prozent des Maximalwertes und sinkt mit zunehmender Latenz nur wenig weiter.
Übertragungsrate in Anhängigkeit der Paketverlustrate
Übertragungsrate in Anhängigkeit des latenz
Übertragungsrate in Anhängigkeit von Loss und Delay

HPN-Patches

Vom Pittsburgh Supercomputing Center gibt es Patches zur Leistungssteigerung der sonst auf openssh basierenden Produkte. Unter Linux sind die modifizierten Progamme typischerweise als gesonderte Pakete verfügbar.