 Geschrieben von Beat Rubischon (Link) am
Freitag, 5. April 2013, 08:28
aus dem *dinge-die-ich-nie-wissen-wollte* dept.
Vor anderthalb Monaten ersetzte die Swisscom den DSLAM unserer Zentrale in Obstalden. Mein Cisco 836 verstand sich nicht mehr länger mit dem Alcatel Device am anderen Ende und ich implementierte einen schnellen Workaround mit einer DSL Bridge aus einem ehemaligen Bluewin Starter Kit. Ich liebe IOS (nicht iOS), aber auch meine Liebe hat Grenzen.
Wie jede neue Technologie ist auch im DSL Umfeld das Memory billig geworden. Pakete zwischenzuspeichern, bevor sie weitergeleitet werden, ist keine grosse Sache mehr - bei einer ausgelasteten Leitung sind runde 50 Pakete "in Transit" zwischen mir und meinem ISP. Dieser puffert weitere 100 Pakete in seinem Router auf dem Weg zu mir, leider nur dumm und ohne Berücksichtigung irgendwelcher TOS oder QOS Flags. CPU Power ist leider noch immer teuer im Cisco Umfeld. Zugegeben, ich habe nicht die schnellste Leitung zuhause - entsprechend sah ich im Downlink bei einer vollen Leitung mehr als 300ms, im Uplink mehr als 1000ms Latency bei einem vollen Link. Kein Problem für die modernen Social Media Benutzer, tödlich für die interaktive Arbeit in einem Terminal.
Shapen ist das Schlüsselwort. Nur so wenig Pakete senden, dass die Buffers unterwegs nicht gefüllt werden. Und etwas weniger dringend auch dafür sorgen, dass die eingehenden Pakete so ausgebremst werden, dass auch die sendenden Buffers nie aufgefüllt werden. Cisco's IOS kann das, aber nur für IPv4 - eine Ablösung durch Linux war damit gegeben.
Ich fühlte mich einigermassen sicher. Schliesslich habe ich tagtäglich mit Netzwerken zu tun, die 40-56GBit pro Link transportieren. Die paar Kilobit im xDSL Umfeld sollten keinen Challenge sein. Der Teufel (oder Murphy) stecken natürlich auch da.
Die drei Tage Home Office mit Meerschweinchenbabysitting waren Motivation genug, das Problem anzupacken. Wer einmal einen ssh benutzt hat, dessen Link mehr als eine Sekunde Verzögerung hat, kann meinen Schmerz nachfühlen. Ich hatte einen passenden Mac Mini Clone bereit, entschied mich zu CentOS um auch für meinen Job Erkenntnisse zu gewinnen. Ein Fehler, bei meiner nächsten Network Appliance nehme ich wieder Debian.
Erst einmal die VLANs aufräumen. Nummer 1 soll das default sein und bleiben - wie es sich gehört aber keinen produktiven Traffic tragen. Teure Switches verwenden dieses für ihren eigenen Traffic. So machte ich VLAN 100 zu meinem LAN, 101 zur DMZ und 109 zum DSL Link zwischen Bridge und Router. Weiter darf auf dem Router nur ein Trunk angeliefert werden - Linux reagiert interessant, wenn eines der VLANs untagged daherkommt. Das entsprechende ethX ist zwar lauffähig, aber es "sieht" auch die getaggten Frames im Falle von Applikationen, die Broadcasts empfangen. DHCP auf einem solchen Interface "sieht" auch falsche Anfragen, tcpdump ist faktisch unbrauchbar.
PPPoE war erstaunlich simpel. Ich hatte noch einen elektronischen Fresszettel mit Login und Passwort. Dokumentation ist alles :-)
IPv6 war eine Herausforderung. Ich muss bei meinem ISP mit DHCPv6 eine Prefix Delegation abholen - nicht weil ich die wissen muss, ich bekomme immer dieselbe, sondern um das Routing in seinem Access Konzentrator zu aktivieren. Der erste Ansatz mit dem bordeigenen ISC dhclient war vernichtend, der fabriziert einen Segfault. dhclient aus den Sourcen kann keine IPv6 Prefix Delegation und muss gepatcht werden. Der Patch, ein Attachment in einem Mailinglistenarchiv, kommt nicht mit ppp Interfaces zurecht. Er braucht dringend eine MAC Adresse... Nächster Versuch mit dem Wide DHCP Client. Gar nicht so trivial, dieses Projekt wurde zugunsten vom ISC aufgegeben. Er baut, mit seiner Konfiguration bin ich heillos überfordert - alle Howtos zeigen Beispiele, die nicht auf mein Binary passen. Nächster Versuch mit Dibbler. Auch ein Fehlschlag, ich begreife die Konfiguration nicht, er weigert sich schlicht etwas zu tun. How hard can it be? Cisco kann das doch auch und es reicht eine einzige Zeile im Konfigfile.
Ich google weiter, stosse auf eine brauchbare Anleitung zu Ubuntu. In meiner Verzweiflung hole ich die Sourcen von Wide DHCP aus dem Debian Archiv, compiliere ihn und *tadaa* habe IPv6. Es ist tatsächlich der einzige DHCPv6 Client, der sauber eine Prefix Delegation abholen kann, selbst die pfsense Leute verwenden ihn. Das dazugehörende Konfigfile ist simpel:
interface ppp0 {
send ia-pd 0;
};
id-assoc pd 0 {
prefix-interface eth0.101 {
sla-id 0;
};
prefix-interface eth0.100 {
sla-id 1;
};
};
radvd and stateless DHCPv6 waren geradezu trivial und in fünf Minuten oben.
Stabil war der Link noch nicht. Der pppoe Client kennt eine Synchronous Option und ich habe mit meiner langjährigen Erfahrung diese natürlich aktiviert. Hey, ich habe schon syncppp über HDLC gemacht, als ich noch ISDN bzw. V.35 hatte... Fehlschlag, die sorgt für korrupte Frames. Seit sie wieder aus ist, läuft der Link rocksolid.
Letzter Punkt, das Shapen. tc heisst das Command, seine Bedienung gleicht der russischen Atombombe aus dem Film Goldfinger. Ich google, finde dutzende von Anleitungen zu den ausgefallensten Quality of Service Setups - nur nichts, was ich begreife und einfach mal den Traffic limitiert und die Queue dahinter nach Type of Service sortiert. Es gibt einen Wonderhaper, der mir interessanterweise mein IPSEC Tunnel ins Büro killt, ihm Latencies von 3-5 Sekunden beschert. Oder ein cbq.init, das aber nicht mit IPv6 zurechtkommt. Dual Stack ist eine Herausforderung, das ich im Prinzip ja die Summe zweier Protokolle shapen will, diese aber unabhängig voneinander verarbeiten muss.
Viel googeln und lesen später habe ich eine eigene Konfiguration zusammen, die genau das Gewünschte tut:
#!/bin/sh
#
# Simpe traffic shaper for PPPoE using an external xDSL bridge
# 4.4.13 Beat Rubischon
#
# Ideas from
# http://edseek.com/~jasonb/articles/traffic_shaping/scenarios.html
# http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
# http://www.faqs.org/docs/Linux-HOWTO/ADSL-Bandwidth-Management-HOWTO.html
#
# chkconfig: 23456 11 89
# description: Shaper for PPPoE over xDSL
#
### BEGIN INIT INFO
# Provides: $shaper
# Should-Start: $network
# Short-Description: Shaper for PPPoE over xDSL
# Description: Shaper for PPPoE over xDSL
### END INIT INFO
case "$1" in
start)
echo -n "Starting shaper..."
modprobe ifb
ip link set dev ifb0 up
tc qdisc add dev ppp0 root handle 1: htb default 10
tc class add dev ppp0 parent 1: classid 1:1 htb rate 512kbit ceil 512kbit
tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 512kbit ceil 512kbit
tc qdisc add dev ppp0 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev ppp0 ingress
tc filter add dev ppp0 parent ffff: protocol ip \
u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0
tc filter add dev ppp0 parent ffff: protocol ipv6 \
u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0
tc qdisc add dev ifb0 root handle 1: htb default 10
tc class add dev ifb0 parent 1: classid 1:1 htb rate 4700kbit ceil 4700kbit
tc class add dev ifb0 parent 1:1 classid 1:10 htb rate 4700kbit ceil 4700kbit
tc qdisc add dev ifb0 parent 1:10 handle 10: sfq perturb 10
echo "done."
;;
stop)
echo -n "Stopping shaper..."
tc qdisc del dev ppp0 root
tc qdisc del dev ppp0 ingress
tc qdisc del dev ifb0 root
rmmod ifb
echo "done."
;;
restart)
$0 stop
$0 start
;;
status)
echo "--- ppp0 ---"
tc -s qdisc show dev ppp0
echo
tc -s class show dev ppp0
echo
tc -s filter show dev ppp0
echo "--- ifb0 ---"
tc -s qdisc show dev ifb0
echo
tc -s class show dev ifb0
echo
tc -s filter show dev ifb0
;;
esac
Aus den 6000/600 ist nur noch 4700/512 geworden. Weniger Bandbreite, dafür auch massivst weniger Latency - bei all meinen Versuchen blieb ich unter 100ms. Ziel erreicht, ich kann wieder zuhause arbeiten.
Permalink
|