Tja, an sich fand ich 1&1′ Backbone-Wechsel an meinem VDSL-Anschluß ja eher vorteilhaft. Bis jetzt.
Wie schon unter dem entsprechenden Beitrag kommentiert, hat die »Anpassung der Netz-Infrastruktur an Ihrem 1&1 DSL-Anschluss« – also der Wechsel vom Telekom- auf den 1&1-Versatel-Backbone hinter der Telekom-VDSL-Infrastruktur – für mich eigentlich nur Vorteile: es ist a) ein Non-Double-Paid-Backbone (siehe auch Golem.de) und b) auch ein alternativer Backbone zu dem der Telekom.
Halt, nein, ich mache mir nichts vor: beide CuDA enden in ca. 200m im Telekom-Outdoor-DSLAM, die Redundanz ist zwischen Netzzusammenschaltung Ex-Versatel/Telekom und meinem Keller nicht gegeben. Deshalb ist UnityMedia seit Dezember ja auch beauftragt, die Hütte hier per Koaxial-Kabel an deren »Glasfaser-Netz« anzubinden (ja, ich habe eine Kundennummer mit einer Auftragsbestätigung bekommen, am 05.12.2017 — wie lange dauert es eigentlich für gewöhnlich, bis UM endlich losbaggert?).
Aber ich schweife ab; das Thema heute aben ist, daß der Versatel-Backbone gerade mächtig kacke ist:
wusel@ysabell:~$ sudo tcptraceroute github.com traceroute to github.com (192.30.253.113), 30 hops max, 60 byte packets 1 192.168.5.33 (192.168.5.33) 3.093 ms 3.095 ms 3.105 ms 2 192.168.177.11 (192.168.177.11) 3.105 ms 5.177 ms 5.212 ms 3 rec1001aihr001.versatel.de (62.214.63.85) 16.824 ms 16.843 ms 16.841 ms 4 62.214.37.237 (62.214.37.237) 25.403 ms 25.483 ms 25.488 ms 5 62.214.37.110 (62.214.37.110) 27.760 ms * 30.757 ms 6 dialup-212.162.17.5.frankfurt1.mik.net (212.162.17.5) 30.769 ms 24.012 ms 23.960 ms 7 * * * 8 GITHUB-INC.bear1.Washington111.Level3.net (4.53.116.102) 180.372 ms GITHUB-INC.bear1.Washington111.Level3.net (4.15.136.22) 175.002 ms GITHUB-INC.bear1.Washington111.Level3.net (4.53.116.102) 174.970 ms 9 * * * 10 * * * 11 192.30.253.113 (192.30.253.113)177.341 ms 177.424 ms 177.426 ms
Hmm, »dialup«? Ja, das paßt:
wusel@ysabell:/path$ git clone git@github.com:ffgtso/gluon-ffgt-v2016.2.git Klone nach 'gluon-ffgt-v2016.2' ... X11 forwarding request failed on channel 0 remote: Counting objects: 19562, done. remote: Compressing objects: 100% (43/43), done. ^Cpfange Objekte: 21% (4216/19562), 1.41 MiB | 8.00 KiB/s
8 verfickte kByte/sec, also 64 kBit/sec über meinen 1&1-VDSL100-Anschluß? You must be kidding?!
Gegenprobe:
root@gw-gt:~# ip route add 192.30.253.0/24 via 192.168.177.1 table NAT
wusel@ysabell:~$ sudo tcptraceroute github.com traceroute to github.com (192.30.253.113), 30 hops max, 60 byte packets 1 192.168.5.33 (192.168.5.33) 3.838 ms 3.800 ms 3.781 ms 2 192.168.177.1 (192.168.177.1) 3.768 ms 3.757 ms 7.351 ms 3 62.155.243.28 (62.155.243.28) 30.158 ms 30.162 ms 30.155 ms 4 d-ed5-i.D.DE.NET.DTAG.DE (62.156.131.225) 24.699 ms d-ed5-i.D.DE.NET.DTAG.DE (62.154.5.213) 27.625 ms d-ed5-i.D.DE.NET.DTAG.DE (62.154.5.205) 27.551 ms 5 80.157.129.202 (80.157.129.202) 30.026 ms 30.006 ms 29.986 ms 6 * * * 7 GITHUB-INC.bear1.Washington111.Level3.net (4.15.136.22) 127.365 ms 127.860 ms GITHUB-INC.bear1.Washington111.Level3.net (4.53.116.102) 127.739 ms 8 * * * 9 * * * 10 192.30.253.113 (192.30.253.113)119.728 ms 127.769 ms 118.848 ms
Much better:
wusel@ysabell:/path$ git clone git@github.com:ffgtso/gluon-ffgt-v2016.2.git Klone nach 'gluon-ffgt-v2016.2' ... X11 forwarding request failed on channel 0 remote: Counting objects: 19562, done. remote: Compressing objects: 100% (43/43), done. remote: Total 19562 (delta 8), reused 0 (delta 0), pack-reused 19513 Empfange Objekte: 100% (19562/19562), 6.60 MiB | 1.91 MiB/s, Fertig. Löse Unterschiede auf: 100% (7618/7618), Fertig. Prüfe Konnektivität ... Fertig.
Das war jetzt nicht entertaining, liebe 1&1. Noch so’n Bock und wir müssen reden.
Naja, mik.net gibt es schon soooo lange nicht mehr ;) insofern ist das mit dem “dialup” eher ein Artefakt…