Om even uit te sluiten dat er problemen zijn bij Hurricane Electric heb ik een tunnel naar een machine in AWS opgezet. Als ik hier een 6in4 tunnel maak (proto 41) haal ik hier dezelfde 13Mbit/s downstream. Zet ik deze om naar GRE (proto 47) haal ik de volledige 250mbit/s. Ook IPSEC werkt gewoon naar behoren.
Is het een bekend issue dat protocol 41 verkeer geratelimit wordt op de Arris modems?
Onderstaand testje zoals uitgevoerd hierbij wordt een 6in4 en GRE tunnel opgezet tussen dezelfde machines.
#Opzetten 6in4 en GRE tunnel (ander kant heeft adres :2)
ip tunnel add 6in4 mode sit remote n.n.n.n ttl 255
ip addr add fd00:1::1/64 dev 6in4
ip link set 6in4 mtu 1480 up
ip tunnel add gre mode gre remote n.n.n.n ttl 255
ip addr add fd00:2::1/64 dev gre
ip link set gre mtu 1476 up
# test over sit tunnel ( 6in4 )
root@aws:/# iperf -V -c fd00:1::2
------------------------------------------------------------
Client connecting to fd00:1::2, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[ 3] local fd00:1::1 port 35622 connected with fd00:1::2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 16.5 MBytes 13.7 Mbits/sec
# test over gre tunnel
root@aws:/# iperf -V -c fd00:2::2
------------------------------------------------------------
Client connecting to fd00:2::2, TCP port 5001
TCP window size: 45.0 KByte (default)
------------------------------------------------------------
[ 3] local fd00:2::1 port 33472 connected with fd00:2::2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 291 MBytes 243 Mbits/sec
Best beantwoord door CitizenE
Om mijn theorie (dat proto's 41 en 47 door het modem niet in hardware worden afgehandeld) verder te onderbouwen, heb ik een setup gemaakt waarbij er geen gebruik wordt gemaakt van GRE of 6in4 maar de sessie wordt ge-encapsuleerd in UDP. Ik heb dat gedaan door een foo-over-udp (fou) SIT tunnel te bouwen naar een VPS, gehost in een data center in Amsterdam. Van daar loopt er weer een 6in4 tunnel naar een HE PoP om zo hetzelfde pad af te leggen als de eerdere testen. Er zit in deze setup dus een extra hop met een extra stuk encapsulatie.
Om niet mijn draaiende 6in4 tunnel te verstoren, heb ik gebruik gemaakt van een andere HE 6in4 tunnel die ik nog had met het endpoint in Londen. Dit klinkt op papier niet optimaal. De resultaten zijn daardoor des te opvallend.
Bij een herhaling van de eerder uitgevoerde tests haal ik in deze setup een snelheid die heel dicht bij het maximaal haalbare zit. In mijn geval tegen de 300Mbit/s. Da's wel even andere koek.
/home/citizenE > curl --interface 2001:470:dead:beef::1 -6 http://download.xs4all.nl/test/1GiB.bin -o /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1024M 100 1024M 0 0 33.4M 0 0:00:30 0:00:30 --:--:-- 34.0M
Schematisch:
nuc <-- fou SIT tunnel --> VPS <-- 6in4 HE tunnel --> Londen HE PoP <-- IPv6 Internet --> download.xs4all.nl
Conclusie: er is niks mis met het 6in4 tunnel mechanisme an sich of de HE infrastructuur. Het gaat wel echt mis zodra het stukje tunnel dat over het modem loopt in GRE of 6in4 verpakt zit. Je mag wat mij betreft wel stellen dat die Connectbox modems in de huidige config totaal ruk zijn...
Deze test setup zou voor mij een workaround kunnen zijn maar je bent wel afhankelijk van een VPS en daar komen dan ook de kosten nog bij. Verder ondersteunt mijn gateway wel GRE en 6in4 maar geen fou. Je moet de tunnel dus termineren op een linux box in je netwerk. Niet ideaal.
