Tunnel und Blockaden

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 …«?

7 thoughts on “Tunnel und Blockaden

  1. 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. :)

  2. 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:

      root@de3:~# iperf -s -p 4711 
      ------------------------------------------------------------
      Server listening on TCP port 4711
      TCP window size: 85.3 KByte (default)
      ------------------------------------------------------------
      [  4] local 198.19.44.2 port 4711 connected with 198.19.44.32 port 60968
      [ ID] Interval       Transfer     Bandwidth
      [  4]  0.0-10.0 sec   207 MBytes   173 Mbits/sec
      [  5] local 198.19.44.2 port 4711 connected with 198.19.44.32 port 60970
      [  5]  0.0-10.0 sec   199 MBytes   166 Mbits/sec
      [  4] local 5.x.x.x port 4711 connected with 108.x.x.x port 42440
      [  4]  0.0-10.1 sec   160 MBytes   133 Mbits/sec
      [  5] local 5.x.x.x port 4711 connected with 108.x.x.x port 42442
      [  5]  0.0-10.2 sec   101 MBytes  83.2 Mbits/sec
      [  4] local 10.1.0.1 port 4711 connected with 10.1.0.0 port 49968
      [  4]  0.0-10.1 sec   212 MBytes   177 Mbits/sec
      [  5] local 10.1.0.1 port 4711 connected with 10.1.0.0 port 49970
      [  5]  0.0-10.1 sec   215 MBytes   179 Mbits/sec
      [  4] local 10.0.0.1 port 4711 connected with 10.0.0.0 port 43972
      [  4]  0.0-10.1 sec  77.6 MBytes  64.7 Mbits/sec
      [  5] local 10.0.0.1 port 4711 connected with 10.0.0.0 port 43974
      [  5]  0.0-10.0 sec  77.5 MBytes  64.9 Mbits/sec
      
      root@us1:~# scp -p 10.0.0.1:/tmp/100MB.zip /tmp/ ; scp -p 10.1.0.1:/tmp/100MB.zip /tmp/
      100MB.zip                                                               100%  100MB   4.6MB/s   00:22    
      100MB.zip                                                               100%  100MB   2.6MB/s   00:38    

      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:

      root@us1:~# scp -p 10.0.0.1:/tmp/100MB.zip /tmp/ ; scp -p 10.1.0.1:/tmp/100MB.zip /tmp/
      100MB.zip                                                               100%  100MB   9.1MB/s   00:11    
      100MB.zip                                                               100%  100MB  12.5MB/s   00:08    
      root@us1:~# scp -p 10.0.0.1:/tmp/100MB.zip /tmp/ ; scp -p 10.1.0.1:/tmp/100MB.zip /tmp/
      100MB.zip                                                               100%  100MB   3.7MB/s   00:27    
      100MB.zip                                                               100%  100MB   5.3MB/s   00:19    
      root@us1:~# scp -p 10.0.0.1:/tmp/100MB.zip /tmp/ ; scp -p 10.1.0.1:/tmp/100MB.zip /tmp/
      100MB.zip                                                               100%  100MB  10.0MB/s   00:10    
      100MB.zip                                                               100%  100MB   1.9MB/s   00:54    

      Evtl. jage ich hier Geister, oder das ist adaptives DPI. Komisch ist nur der Unterschied iperf/ssh finde ich.

  3. Versuch mal das Offloading abzuschalten:
    ethtool -K eth0 gro off
    ethtool -K eth0 gso off

    • Hmm.

      root@carrot:~# ethtool -k eth0 | grep -i offload
      tcp-segmentation-offload: off
      udp-fragmentation-offload: off [fixed]
      generic-segmentation-offload: off [requested on]
      generic-receive-offload: on
      large-receive-offload: off [fixed]
      rx-vlan-offload: on
      tx-vlan-offload: on
      l2-fwd-offload: off [fixed]
      hw-tc-offload: off [fixed]

      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.

        root@us1:~# scp -p /tmp/100MB.zip 198.19.44.2:/tmp/100MB.zip 
        100MB.zip                                                               100%  100MB  16.7MB/s   00:06    
        root@us1:~# scp -p /tmp/100MB.zip 198.18.44.2:/tmp/100MB.zip 
        100MB.zip                                                               100%  100MB   5.6MB/s   00:18    
        root@us1:~# scp -p 198.18.44.2:/tmp/100MB.zip /tmp/
        100MB.zip                                                                 0%  256KB  18.3KB/s 1:33:14 ETA^Croot@us1:~# 
        root@us1:~# scp -p 198.19.44.2:/tmp/100MB.zip /tmp/
        100MB.zip                                                                 0%  128KB  16.0KB/s 1:46:32 ETA^C

        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*.

Comments are closed.