Ich habe mein eigenes AS, einen ›eigenen‹ /48er (PA) v6-Netzbereich — und interessante Einsichten gewonnen.
Mein Netz und AS sind aktuell einzig via Hurricane Electric angebunden, über einen IPv4-Tunnel, über den dan IPv6 gesprochen wird:
root@hex:~# traceroute -6 2a07:a907:50c:ff12::2 traceroute to 2a07:a907:50c:ff12::2 (2a07:a907:50c:ff12::2), 30 hops max, 80 byte packets 1 * * * 2 2a03:f82:abcd:43:5716::9 (2a03:f82:abcd:43:5716::9) 4.239 ms 4.276 ms 4.065 ms 3 2a02:d28:3:1004::21 (2a02:d28:3:1004::21) 12.798 ms 12.561 ms 12.521 ms 4 ae02.edge01.pra01.cz.as5580.net (2a02:d28:5580:1::1a5) 9.794 ms 9.780 ms 9.751 ms 5 20ge1-3.core1.prg1.he.net (2001:7f8:14::6e:1) 9.838 ms 12.276 ms 12.023 ms 6 100ge8-1.core1.fra1.he.net (2001:470:0:213::1) 17.329 ms 17.362 ms 17.276 ms 7 ge0-1.tserv18.fra1.ipv6.he.net (2001:470:0:a5::2) 51.891 ms 45.403 ms 45.108 ms 8 uusix-4-pt.tunnel.tserv18.fra1.ipv6.he.net (2001:470:12:f1::2) 22.461 ms 33.693 ms 33.552 ms 9 us1-de3.as206946.net (2a07:a907:50c:ff02::1) 146.958 ms 135.900 ms 145.817 ms 10 uk2-us1.as206946.net (2a07:a907:50c:ff12::2) 136.701 ms 138.594 ms 148.940 ms
Und, wie es sich gehört, bin ich damit in der DFZ (default free zone) ;)
root@de3:~# birdc6 show route | wc -l 32336
Auch habe ich ein »private peering« mit unseren Freiunk-Gateways aktiviert; das erspart dann den Umweg über die öffentlichen Netze — also 15 Hops und ca. 10 ms ;)
root@uk2:~# traceroute -6 stats.4830.org traceroute to stats.4830.org (2001:bf7:1310::5747), 30 hops max, 80 byte packets 1 de3-uk2.as206946.net (2a07:a907:50c:ff01::2) 22.443 ms 22.450 ms 22.424 ms 2 bgp2-de3.as206946.net (2a07:a907:50c:f320::2) 33.641 ms 33.647 ms 33.619 ms 3 2001:bf7:1310:31d::2 (2001:bf7:1310:31d::2) 33.567 ms 33.696 ms 34.051 ms 4 stats.guetersloh.freifunk.net (2001:bf7:1310::5747) 35.331 ms 35.442 ms 35.457 ms
root@uk2:~# traceroute -6 stats.4830.org -s 2a07:4580:xxxx:xxxx:xxxx::xxxx traceroute to stats.4830.org (2001:bf7:1310::5747), 30 hops max, 80 byte packets 1 2a07:4580:b0d::1 (2a07:4580:b0d::1) 0.510 ms 0.528 ms 1.016 ms 2 2001:1b40:6000:1265::97 (2001:1b40:6000:1265::97) 1.045 ms 1.038 ms * 3 3940.core1.dc7.as20860.net (2001:1b40:f000:3940::2) 1.591 ms 1.632 ms 1.649 ms 4 2990.core2.ld5.as20860.net (2001:1b40:f000:29::1) 6.392 ms 6.420 ms 6.404 ms 5 * be97.asr01.ld5.as20860.net (2001:1b40:f000:2d::2) 7.867 ms * 6 40ge1-3.core1.lon2.he.net (2001:7f8:4::1b1b:1) 14.053 ms 23.830 ms 23.847 ms 7 100ge6-2.core1.ams1.he.net (2001:470:0:2d0::2) 53.302 ms 53.277 ms 53.277 ms 8 xe-0-0-1.core-ams14.as6724.net (2001:7f8:1::a500:6724:1) 14.376 ms 14.380 ms 14.551 ms 9 xe-1-2-0.0.core-b30.as6724.net (2a01:238:0:ae30::2) 26.810 ms 26.813 ms 27.001 ms 10 ae3.0.core-b30.as6724.net (2a01:238:0:b130::2) 26.847 ms 26.857 ms 26.551 ms 11 freie-netzwerke.ber.ecix.net (2001:7f8:8:5:0:aca2:0:1) 26.454 ms 26.197 ms 26.219 ms 12 voyager-ak.ber.ecix.net (2001:7f8:8:5:0:31bc:0:2) 28.908 ms 29.233 ms 29.177 ms 13 octalus.in-berlin.ak.community-ix.de (2001:7f8:a5::2:9670:1) 26.546 ms 26.705 ms 26.706 ms 14 lo.nautilus.in-berlin.de (2001:67c:1401::8) 27.028 ms 27.005 ms 26.990 ms 15 freifunk-bgp.in-berlin.de (2001:bf0:c003:40::139) 26.118 ms 25.842 ms 26.081 ms 16 2001:bf7:b101:1::3 (2001:bf7:b101:1::3) 27.067 ms 26.987 ms 27.287 ms 17 2a03:2260:0:62::2 (2a03:2260:0:62::2) 32.375 ms 32.030 ms 38.287 ms 18 2001:bf7:1310:31d::2 (2001:bf7:1310:31d::2) 44.655 ms 44.195 ms 44.201 ms 19 stats.guetersloh.freifunk.net (2001:bf7:1310::5747) 45.350 ms 44.921 ms 45.327 ms
Soweit, so gut. Mein zentraler Hub in D ist eine VM auf einem Host von mir bei Hetzner. Die Tunnel werden, in Freifunk-Manier, per GRE aufgebaut. Und da fiel mir sehr schnell auf, daß irgendwas im Argen liegt:
root@us1:~# scp -p bgp-fks.uu.org:/tmp/100MB.zip /tmp/ 100MB.zip 100% 100MB 12.5MB/s 00:08 root@us1:~# scp -p 198.19.44.2:/tmp/100MB.zip /tmp/ 100MB.zip 0% 160KB 31.2KB/s 54:39 ETA^C root@us1:~#scp -p 10.0.0.1:/tmp/100MB.zip /tmp/ 100MB.zip 100% 100MB 7.1MB/s 00:14
Kurzum: über den GRE-Tunnel (198.19.44.2 ist das Interface der Kiste bei Hetzer für die VM bei Vultr) kommen die Daten nur tröpfelnd (31 KByte/sec), während es über das öffentliche Internet mit 12 MByte/sec schon recht flott fliegt. Parallel habe ich auch einen L2TP-Tunnel geworfen, und darüber sind dann immerhin rd. 7 MByte/sec möglich. Ein klares Indiz, daß entweder Vultr und/oder Hetzner GRE-Tunnel (derzeit?) massiv throttlen. Da ich auch aus UK schon rottige Werte über »mein Netz« gesehen habe, dürfte es ultimativ an Hetzner liegen, die irgendeinen Schweinkram mt GRE veranstalten :-( Und was auch irritiert: nur ca. 50% des direkten Durchsatzes sind per L2TP zu erreichen — da hatte ich mir wirklich mehr versprochen :(
Einfach, weil ich es wissen wollte, habe ich dann auch noch einen OpenVPN-Tunnel (UDP) gegraben. Hier die Ergebnisse in der Reihenfolge IPv4-Internet, L2TP-UDP-Tunnel, OpenVPN-UDP-Tunnel, GRE-Tunnel:
root@us1:/etc/openvpn# scp -p bgp-fks.uu.org:/tmp/100MB.zip /tmp/ ; scp -p 10.0.0.1:/tmp/100MB.zip /tmp/ ; scp -p 192.0.2.1:/tmp/100MB.zip /tmp/ ; scp -p 198.19.44.2:/tmp/100MB.zip /tmp/ 100MB.zip 100% 100MB 11.1MB/s 00:09 100MB.zip 100% 100MB 4.6MB/s 00:22 100MB.zip 100% 100MB 3.0MB/s 00:33 100MB.zip 0% 768KB 23.0KB/s 1:13:48 ETA^C
Irgendwie … doof :-(
Auch doof:
Welcome to Ubuntu 15.04 (GNU/Linux 3.19.0-69-generic x86_64) […] New release '16.04.1 LTS' available. Run 'do-release-upgrade' to upgrade to it. […] root@us1:~# do-release-upgrade […] An upgrade from 'vivid' to 'xenial' is not supported with this tool.
Gnampf.
Nachtrag: »do-release-upgrade« hat mit »-d« dann doch nocht geklappt, siehe Komentar, und ich habe noch einen IPv6-in-IPv4-Tunnel gelegt:
ssh v4: 100MB.zip 100% 100MB 12.5MB/s 00:08 l2tp v4: 100MB.zip 100% 100MB 6.3MB/s 00:16 OVPN UDP4: 100MB.zip 100% 100MB 2.9MB/s 00:35 OVPN TCP4: 100MB.zip 13% 14MB 357.9KB/s 04:07 ETA^C sit: 100MB.zip 100% 100MB 2.2MB/s 00:45 gre: 100MB.zip 0% 480KB 16.4KB/s 1:43:40 ETA^C
Pings sind auch eher unauffällig:
ssh v4: 10 packets transmitted, 10 received, 0% packet loss, time 13131ms rtt min/avg/max/mdev = 114.260/114.380/114.802/0.147 ms l2tp v4: 10 packets transmitted, 10 received, 0% packet loss, time 9012ms rtt min/avg/max/mdev = 111.872/112.328/112.606/0.440 ms OpenVPN UDV4: 10 packets transmitted, 10 received, 0% packet loss, time 9011ms rtt min/avg/max/mdev = 114.900/115.278/115.603/0.223 ms OpenVPN TCP4: 10 packets transmitted, 10 received, 0% packet loss, time 9014ms rtt min/avg/max/mdev = 116.207/117.017/118.643/0.650 ms IP6-in-IP4: 10 packets transmitted, 10 received, 0% packet loss, time 9011ms rtt min/avg/max/mdev = 113.459/114.085/115.074/0.768 ms GRE: 10 packets transmitted, 10 received, 0% packet loss, time 9016ms rtt min/avg/max/mdev = 111.677/111.751/111.849/0.264 ms
Anti-DDOS-Maßnahmen oder »das muß so, weil …«?
Soweit ich weiß, unterstützen Debian und Ubuntu nur Upgrades von einem Release (hier: v) auf das nächste (hier: w, nicht x), Ubuntu ggf. noch von einem LTS auf das nächste. Das ist jetzt aber eher nicht neu. :)
Dann sollte das entweder nicht angezeigt werden oder aber ein schrittweises ›hochhieven‹ stattfinden. … was im übrigen auch funktioniert, »do-release-upgrade -d« brachte V auf W, und danach ein »do-release-upgrade« W auf X.
https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/1457957 ist dann aber nervig.
Hmm, kann es sein dass Du in MTU IP-Fragmentierung mit Deinem GRE Tunnel laeufst?
Hmm, sollte eigentlich nicht, verstehen tue ich es im Moment nicht:
10.0.0.0/25 ist L2TPv4, 10.1.0.0/25 ist IPIPv4, 198.19/16 ist GRE.
Mal MTU jeweils auf 1280 gesetzt:
Evtl. jage ich hier Geister, oder das ist adaptives DPI. Komisch ist nur der Unterschied iperf/ssh finde ich.
Versuch mal das Offloading abzuschalten:
ethtool -K eth0 gro off
ethtool -K eth0 gso off
Hmm.
GRO ist in der Tat an auf dem Hetzner-Host (in ATL steht ja eine VM, Vultr wird das schoch richtig machen ;)). Aber das erklärt für mich nicht, warum ein normaler GRE-Tunnel schnullerlahm ist (scp durch Tunnel: 16 kByte/sec), ein paralleler L2TP-UDP-Tunnel deutlich flotter, und normales TCP (scp) aus ATL auf die VM relativ flott (5-7 MByte/sec)? Bevor ich wild an Stellschrauben drehe, brauche ich noch mehr Daten …
So bekomme ich z. B. durch den GREv4-Tunnel (von meinem VDSL100 zur VM bei Hetzner) über v4 10,7 MByte/sec für einen HTTP-Download; gleicher Tunnel, aber v6-Verbindung dadurch, schafft zumindest 7 MByte/sec — ich stelle aber auch hier deutliche Schwankungen fest, evtl. liegt das hier am Peering Telekom-Hetzner.
Aus dem lokalen RZ (Host) zur Hetzner-VM sind per public v4 30 MByte/sec bei 100 MByte drin — ich denke, GRO ist nicht das Problem. Zwischen der VM in ATL und der VM auf dem Hetzner-Host sind es per public v4 mit wget ~5 MByte/sec, durch den GREv4-Tunnel, egal ob mit v4 oder v6, 12 kByte/sec …
Nachtrag: es ist richtungsabhängig und an der Stelle unabhängig, ob Hetzner oder anderer Hoster in D.
Sprich: zur VM bei Hetzer schieben geht flott, ebenso zur VM an anderem Standort. Von jenen Locations Daten nach ATL ziehen … funktioniert theoretisch, ohne Durchsatz. WTF?! Das erklärt dann auch, warum iperf mit Server in D super Werte lieferte *sigh*.