Unitymedia Neue Routingerscheinungen

[maffle]

Hab jetzt paar mal die VFS neugestartet ich bekomm immer die selbe IP... gibts überhaupt dynamische IP bei UM? Die wird vermutlich fest eingestellt sein.

Erm... das steht in der VFS:

Wieso ist das "läuft ab" in de Vergangenheit? das war da wo ich den neugestartet hab und der sich die gezogen hat. Das ist aber dieselbe wie vorher auch.

 

[floh667]

ich weiß es nicht. vielleicht ist die vodafone station was das angeht nicht ganz zuverlässig und liest das fehlerhaft aus. Oder jemand anderes hier kann das erklären

 

[Soldierofoc]

Leastime dürfte bei etwa 1-2h liegen. Zumindest hatte ich diese Woche, nachdem das HFC Modem 2h offline war, anschließend eine neue IP.

 

[floh667]

um 00:22 Uhr kann ich es genau sagen, dann läuft unseres ab und erneuert sich

 

[maffle]

Ich lass die VFS jetzt mal 2 stunden ausgeschaltet, bin wieder über Telekom VDSL drinn. Ich bezweifle mal, dass ich selbst wenn ich ne andere IP bekomme dann anders geroutet werde. Dass ich über fra1/2 gehe liegt vermutlich an meiner lokalen Gegebenheit.

Das kann doch nich sein, dass die Aorta fra1/2 router irgend n Problem haben oder ne Drossel eingestellt ist. Wie soll ich das beweisen, UM anschreiben wird da wohl kaum was bringen.

Leider geht bei mir scheinbar fast alles über diese Route...

Auffällig ist, dass bei mir der tele2, der bei mir auch geht, von fra3 weg geht, aber von fra1 zu fra3 und dann das Aorta Netz verlässt.

 

[Cyrus]

Der Trick mit dem offline nehmen für zwei Stunden wirkt sich aber nur auf die IPv4 aus, oder?
Man bekommt auch nach einem Tag noch die gleiche IPv6.

 

[millen]

@Cyrus Soweit ich weiß hat die IPv6 ne Leastime von 7 Tagen.

 

[maffle]

Ich hatte die VFS jetzt für 2 Stunden 40 Minuten vom Strom, und er hat sich wieder die selbe IPv4 gezogen...

 

[floh667]

ok das ist sehr seltsam. normal hätte er da echt ne neue kriegen sollen

 

[maffle]

Habe mittlerweile die letzte Stunde iperf tests gemacht zu meinem VPS server bei Netcup, und es wird noch konfuser:

iperf udp test von mir zum VPS server:

[ ID] Interval Transfer Bandwidth Total Datagrams
[ 5] 0.00-1.00 sec 5.38 MBytes 45.1 Mbits/sec 689
[ 5] 1.00-2.00 sec 5.98 MBytes 50.2 Mbits/sec 766
[ 5] 2.00-3.00 sec 5.94 MBytes 49.8 Mbits/sec 760
[ 5] 3.00-4.00 sec 5.95 MBytes 49.9 Mbits/sec 762
[ 5] 4.00-5.00 sec 5.98 MBytes 50.1 Mbits/sec 765
[ 5] 5.00-6.00 sec 5.95 MBytes 49.9 Mbits/sec 762
[ 5] 6.00-7.00 sec 5.96 MBytes 50.0 Mbits/sec 763
[ 5] 7.00-8.00 sec 5.96 MBytes 50.0 Mbits/sec 763
[ 5] 8.00-9.00 sec 5.96 MBytes 50.0 Mbits/sec 763
[ 5] 9.00-10.00 sec 5.96 MBytes 50.0 Mbits/sec 763
[ 5] 10.00-10.08 sec 616 KBytes 65.8 Mbits/sec 77
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datag rams
[ 5] 0.00-10.08 sec 59.6 MBytes 49.6 Mbits/sec 0.000 ms 0/7633 (0%)

iperf udp test von meinem VPS server zu mir, erst mit 10mbit, dann 100, dann 200, dann 500:

Server listening on UDP port 580**
Receiving 1470 byte datagrams
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
[ 3] local 10.0.0.9 port 580** connected with 94.16.123.* port 42866
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0- 2.0 sec 2.50 MBytes 10.5 Mbits/sec 0.080 ms 0/ 1786 (0%)
[ 3] 2.0- 4.0 sec 2.50 MBytes 10.5 Mbits/sec 0.100 ms 0/ 1784 (0%)
[ 3] 4.0- 6.0 sec 2.50 MBytes 10.5 Mbits/sec 0.087 ms 0/ 1783 (0%)
[ 3] 6.0- 8.0 sec 2.50 MBytes 10.5 Mbits/sec 0.097 ms 0/ 1784 (0%)
[ 3] 0.0-10.0 sec 12.5 MBytes 10.5 Mbits/sec 0.129 ms 2147465812/2147474730 (1e+02%)
[ 4] local 10.0.0.9 port 580** connected with 94.16.123.* port 60515
[ 4] 0.0- 2.0 sec 25.0 MBytes 105 Mbits/sec 0.146 ms 0/17843 (0%)
[ 4] 2.0- 4.0 sec 24.9 MBytes 105 Mbits/sec 0.313 ms 0/17791 (0%)
[ 4] 4.0- 6.0 sec 25.0 MBytes 105 Mbits/sec 0.135 ms 6/17827 (0.034%)
[ 4] 6.0- 8.0 sec 25.0 MBytes 105 Mbits/sec 0.133 ms 0/17831 (0%)
[ 4] 0.0-10.0 sec 125 MBytes 105 Mbits/sec 0.097 ms 2147305326/2147394482 (1e+02%)
[ 3] local 10.0.0.9 port 580** connected with 94.16.123.* port 60246
[ 3] 0.0- 2.0 sec 49.9 MBytes 209 Mbits/sec 0.181 ms 36/35629 (0.1%)
[ 3] 2.0- 4.0 sec 49.8 MBytes 209 Mbits/sec 0.024 ms 354/35519 (1%)
[ 3] 2.00-4.00 sec 354 datagrams received out-of-order
[ 3] 4.0- 6.0 sec 50.1 MBytes 210 Mbits/sec 0.069 ms 7/35759 (0.02%)
[ 3] 6.0- 8.0 sec 49.9 MBytes 209 Mbits/sec 0.188 ms 2/35583 (0.0056%)
[ 3] 6.00-8.00 sec 79 datagrams received out-of-order
[ 3] 0.0-10.0 sec 250 MBytes 210 Mbits/sec 0.055 ms 2147127033/2147305318 (1e+02%)
[ 3] 0.00-10.00 sec 433 datagrams received out-of-order
[ 4] local 10.0.0.9 port 580** connected with 94.16.123.* port 49247
[ 4] 0.0- 2.0 sec 104 MBytes 437 Mbits/sec 0.032 ms 13116/87461 (15%)
[ 4] 2.0- 4.0 sec 104 MBytes 435 Mbits/sec 1.523 ms 15136/89170 (17%)
[ 4] 4.0- 6.0 sec 103 MBytes 433 Mbits/sec 0.683 ms 15601/89168 (17%)
[ 4] 6.0- 8.0 sec 102 MBytes 427 Mbits/sec 0.024 ms 16009/88677 (18%)
[ 4] 8.0-10.0 sec 103 MBytes 432 Mbits/sec 1.652 ms 16212/89606 (18%)
[ 4] 0.0-10.0 sec 516 MBytes 432 Mbits/sec 1.552 ms 2146671556/2147039565 (1e+02%)

Ich weiß nicht was die ca 17% packet loss bei dem 500mbit test aussagen, aber die kamen hier an, sah ich auch am task manager dass ich von mir mit 500mibt gezogen hab.

Über http download von meinem VPS server selbes problem, es fängt schnell an, sackt dann auf ca 10mb/s ab ....

 

[rv112]

Vermutlich ist bei Dir einfach nur der Downstream gestört, das würde so ziemlich alles erklären.

 

[maffle]

Ich hatte die VFS jetzt 13 Stunden aus, bis grad eben. Wieder neue IPv4 gezogen... so viel dazu. Super. Jemand ne Idee, wieso? Ist die vielleicht an die IPv6 gekoppelt, und beide sind 7 Tage?

Vermutlich ist bei Dir einfach nur der Downstream gestört, das würde so ziemlich alles erklären.

Ne eben nicht, wieso kann ich dann zB von dem Tele2 server permanent max speed laden? Ich hab dazu auch 0 Paketverluste egal wohin.

Hier nochn Beispiel der max speed ankommt ohne Probleme:

wget -O /dev/null http://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-10.5.0-amd64-kde.iso

Routenverfolgung zu ftp.acc.umu.se [194.71.11.165]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms wrtarm.lan [10.0.0.199]
2 1 ms 1 ms 1 ms 192.168.0.1
3 * * * Zeitüberschreitung der Anforderung.
4 9 ms 11 ms 8 ms de-lue05a-cr03-te-1-2-0-1430.lue.unity-media.net [81.210.139.10]
5 20 ms 19 ms 19 ms de-gek01a-rd01-ae-0-0.aorta.net [84.116.197.37]
6 20 ms 22 ms 19 ms de-dus23e-rc1-ae-8-0.aorta.net [84.116.196.25]
7 * 23 ms 23 ms nl-ams02a-rc2-lag-15-0.aorta.net [84.116.138.206]
8 19 ms 18 ms 19 ms nl-ams04a-ri3-ae-8-0.aorta.net [84.116.130.97]
9 20 ms 18 ms 18 ms nl-sar.nordu.net [109.105.98.186]
10 34 ms 25 ms 25 ms de-hmb.nordu.net [109.105.97.50]
11 53 ms 40 ms 38 ms dk-ore.nordu.net [109.105.102.122]
12 38 ms 40 ms 40 ms mcen1-r1.sunet.se [109.105.102.123]
13 41 ms 43 ms 39 ms lund-lnd88-r1.sunet.se [130.242.4.70]
14 41 ms 41 ms 41 ms vaxjo-vxj-r1.sunet.se [130.242.4.63]
15 44 ms 43 ms 42 ms jonkoping-jkg-r1.sunet.se [130.242.4.54]
16 46 ms 46 ms 45 ms skovde-ske109-r1.sunet.se [130.242.4.43]
17 47 ms 48 ms 49 ms orebro-lba-r1.sunet.se [130.242.4.32]
18 51 ms 51 ms 52 ms falun-fln4-r1.sunet.se [130.242.4.22]
19 56 ms 55 ms 55 ms sundsvall-sva-r1.sunet.se [130.242.4.21]
20 59 ms 58 ms 58 ms umea-ume8-r1.sunet.se [130.242.4.15]
21 59 ms 56 ms 56 ms umu-r1.sunet.se [130.242.4.115]
22 59 ms 60 ms 56 ms hammurabi.ftp.acc.umu.se [194.71.11.165]

tele2:

wget -O /dev/null http://speedtest.tele2.net/1GB.zip

Routenverfolgung zu speedtest.tele2.net [90.130.70.73]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms wrtarm.lan [10.0.0.199]
2 2 ms 1 ms 2 ms 192.168.0.1
3 * * * Zeitüberschreitung der Anforderung.
4 10 ms 8 ms 7 ms de-lue05a-cr03-te-1-2-0-1430.lue.unity-media.net [81.210.139.10]
5 21 ms 15 ms 15 ms de-fra01b-rc1-ae-7-0.aorta.net [84.116.197.50]
6 15 ms 14 ms 16 ms de-fra03b-ri1-ae-10-0.aorta.net [84.116.132.178]
7 15 ms 15 ms 15 ms fra36-peer-1.xe-0-3-0-unit0.tele2.net [130.244.200.73]
8 17 ms 15 ms 15 ms fra36-core-1.bundle-ether2.tele2.net [130.244.64.186]
9 14 ms 15 ms 13 ms d90-130-70-73.cust.tele2.se [90.130.70.73]

----

wget -O /dev/null http://us.download.nvidia.com/Windows/452.06/452.06-desktop-win10-64bit-international-dch-whql.exe

Routenverfolgung zu cs5341561.wpc.phicdn.net [192.229.221.58]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms wrtarm.lan [10.0.0.199]
2 2 ms 2 ms 2 ms 192.168.0.1
3 * * * Zeitüberschreitung der Anforderung.
4 36 ms 12 ms 7 ms de-lue05a-cr03-te-1-2-0-1430.lue.unity-media.net [81.210.139.10]
5 18 ms 17 ms 18 ms de-fra01b-rc1-ae-7-0.aorta.net [84.116.197.50]
6 14 ms 15 ms 23 ms de-fra02a-ri1-ae-0-0.aorta.net [84.116.137.34]
7 14 ms 14 ms 15 ms 213.46.177.162
8 16 ms 15 ms 15 ms ae-65.core1.frc.edgecastcdn.net [152.195.100.129]
9 14 ms 15 ms 13 ms 192.229.221.58

 

[why_]

Ne eben nicht, wieso kann ich dann zB von dem Tele2 server permanent max speed laden? Ich hab dazu auch 0 Paketverluste egal wohin.

verschiedene tcp congestion control Algorithmen bei verschiedenen quellen. BBR kommt damit recht gut klar wenn die Leitung Müll ist, andere Algorithmen eher nicht so.

 

[maffle]

verschiedene tcp congestion control Algorithmen bei verschiedenen quellen. BBR kommt damit recht gut klar wenn die Leitung Müll ist, andere Algorithmen eher nicht so.

Das hab ich mir auch gedacht, also dass es doch irgend ein Problem mit meiner Leitung ist, dies sich aber nicht typisch äußert, und einige Router das vielleicht "weg regeln" andere nicht, durch Fehlerkorrektur.

Scheinbar funktioniert diese Korrektur überhaupt nicht, wenn bei mir alles über

de-fra01 und de-fra02 läuft. Und das ist sehr viel.

Was mach ich da jetzt...

 

[Edding]

generelles Problem ist das schon mal nicht.

--2020-09-05 17:46:08-- http://us.download.nvidia.com/Windows/452.06/452.06-desktop-win10-64bit-international-dch-whql.exe
Resolving us.download.nvidia.com (us.download.nvidia.com)... 2606:2800:233:ef6:15dd:1ece:1d50:1e1, 192.229.221.58
Connecting to us.download.nvidia.com (us.download.nvidia.com)|2606:2800:233:ef6:15dd:1ece:1d50:1e1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 589364424 (562M) [application/octet-stream]
Saving to: 'NUL'
NUL 100%[=================================================>] 562,06M 106MB/s in 6,2s
2020-09-05 17:46:15 (91,2 MB/s) - 'NUL' saved [589364424/589364424]
--2020-09-05 17:46:23-- http://us.download.nvidia.com/Windows/452.06/452.06-desktop-win10-64bit-international-dch-whql.exe
Resolving us.download.nvidia.com (us.download.nvidia.com)... 192.229.221.58
Connecting to us.download.nvidia.com (us.download.nvidia.com)|192.229.221.58|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 589364424 (562M) [application/octet-stream]
Saving to: 'NUL'
NUL 100%[=================================================>] 562,06M 108MB/s in 6,1s
2020-09-05 17:46:29 (92,3 MB/s) - 'NUL' saved [589364424/589364424]

 

[floh667]

https://www.heise.de/hintergrund/Mi...it-im-Markt-der-Peering-Anbieter-4886694.html heise hat nen netten artikel zu der ganzen private peering geschichte veröffentlicht.
Dazu hab ich noch die seite entdeckt, welche peerings direkt anzeigt https://radar.qrator.net/as6830/peerings

 

[sch4kal]

https://www.heise.de/hintergrund/Mi...it-im-Markt-der-Peering-Anbieter-4886694.html heise hat nen netten artikel zu der ganzen private peering geschichte veröffentlicht.
Dazu hab ich noch die seite entdeckt, welche peerings direkt anzeigt https://radar.qrator.net/as6830/peerings

Das heißt gar nix, die stehen auch schon bei bgp.he.net
Du kannst genauso gut über den Routeserver am DE-CIX peeren, das heißt noch nicht das da ein PNI zwischen beiden Unternehmen besteht.

 

[floh667]

Das hab ich ja nid gemeint. ich fand die nur übersichtlicher :3

Was ist dort der Unterschied zwischen IPv4 customer und peerings?

 

[maffle]

Jemand noch ne Idee was ich jetzt machen sollte mit meinem Problem?

 

[floh667]

Routing nimmt heute nacht wieder den bananenweg schlechthin

Routenverfolgung zu one.one.one.one [1.1.1.1] über maximal 30 Abschnitte:

1 <1 ms <1 ms <1 ms 192.168.xx.xx
2 * * * Zeitüberschreitung der Anforderung.
3 17 ms 6 ms 8 ms ip-81-210-144-156.hsi17.unitymediagroup.de [81.210.144.156]
4 21 ms 16 ms 16 ms 84.116.191.170
5 16 ms 16 ms 17 ms de-str01c-rc1-ae-23-0.aorta.net [84.116.191.165]
6 16 ms 16 ms 21 ms de-fra01b-rc1-ae-4-0.aorta.net [84.116.140.201]
7 16 ms 16 ms 17 ms ch-otf01b-ra1-ae8-0.aorta.net [84.116.134.57]
8 16 ms 15 ms 25 ms ffm-b1-link.telia.net [62.115.42.170]
9 17 ms 17 ms 18 ms cloudflare-ic-328337-ffm-b1.c.telia.net [62.115.144.199]
10 15 ms 15 ms 15 ms one.one.one.one [1.1.1.1]

die können das echt on the fly wechseln. hab zu dem zeitpunkt grad quake live gespielt. Das einzige was man merkt ist ein kurzer Ruck im Spiel und dann is halt die latenz höher.

 

[rv112]

Hier wurde heute Nacht auch für 2 Stunden über Stuttgart geroutet. Nun wieder direkt nach FFM.

 

[floh667]

Hier auch wieder. Waren wohl wieder ein paar Wartungsarbeiten

 

[maffle]

Hatte vor 2 Tagen Vodafone Twitter angeschrieben und mein Problem beschrieben. Kam nur kurz zurück dass sich die Fachabteilung sich das ansehn würde und melden würde, aber dass das länger dauern wird.

So nun wach ich heute auf und schau auf mein test script was ich zum testen kurz starte auf meinem OpenWRT router zu dem Nvidia server

#!/bin/sh

while true
do
wget -O /dev/null http://us.download.nvidia.com/Windows/452.06/452.06-desktop-win10-64bit-international-dch-whql.exe
echo "done."
sleep 2
done

und starre etwas verblüfft auf den Wert... 64MB/s. Gestern war noch alles wie immer im Eimer, und das Problem mit dem Absinken nach 2 Sekunden war dauerhaft vorhanden. 64... 63.... 64.... 63.... wieder und immer wieder. Jedesmal max speed.

Dann schaue ich rüber zur VFS und siehe da... die LED Lampen sind an! Ich mach die immer aus, die VFS hat n bug, dass sich die LED Lampen immer einschalten nach einem reboot und er die Einstellung für LED off nicht speichert. Und siehe da.... es gab einen Reboot der Box vor gut 11 Stunden, also heute Nacht um 1:00 ca.

Firmware version angesehen... und ich hab ein Update bekommen... auf

AR01.02.037.03.14_081320_711.SIP.10

vorher war ich die letzten Monate auf:

AR01.02.037.03.12_112819_711.SIP.10

wget -O /dev/null http://us.download.nvidia.com/Windows/452.06/452.06-desktop-win10-64bit-international-dch-whql.exe läuft jetzt immer ohne Probleme mit max speed durch.

Am routing hat sich scheinbar nichts geändert:

Routenverfolgung zu cs5341561.wpc.phicdn.net [192.229.221.58]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms wrtarm.lan [10.0.0.199]
2 2 ms 2 ms 2 ms 192.168.0.1
3 * * * Zeitüberschreitung der Anforderung.
4 11 ms 11 ms 9 ms de-lue05a-cr03-te-1-2-0-1430.lue.unity-media.net [81.210.139.10]
5 14 ms 14 ms 17 ms de-fra01b-rc1-ae-7-0.aorta.net [84.116.197.50]
6 18 ms 16 ms 14 ms de-fra02a-ri1-ae-0-0.aorta.net [84.116.137.34]
7 16 ms 17 ms 15 ms 213.46.177.162
8 16 ms 29 ms 19 ms ae-65.core1.frc.edgecastcdn.net [152.195.100.129]
9 15 ms 14 ms 12 ms 192.229.221.58

Ablaufverfolgung beendet.

Dachte ich mir... oh mann. Lag es an der Firmware? Habe den nvidia download dann noch so 10 mal am Desktop getestet. Jedesmal max speed. Kein einziger Einbruch. Immer und immer wieder. Max speed. Gefixt!!!

Dann hab ich wget -O /dev/null http://v4.speedtest.belwue.net/1G getestet..... Einbruch. 7MB/s .... .....

dann wieder Nvidia getestet. Und jetzt ist der Nvidia Download auch wieder kaputt und verhält sich fehlerhaft.

WAS ZUM TEUFEL? Ich bin ratlos. Wie kann das bitte sein? Das einmalige ändern des downloads nach dem reboot/firmware update hat dazu geführt dass der andere Download jetzt auch wieder defekt ist. Dabei lief er immer und immer wieder max speed durch, bis ich kurz den wget -O /dev/null http://v4.speedtest.belwue.net/1G genommen hab dann zurück.

Wie ist sowas zu erklären? ........ ich bin ratlos.

Ich kann es mir nur so erklären, dass der andere Download irgendwie, wieso auch immer, die VFS dazu bewogen hat vielleicht einen anderen Docsis Kanal zu nehmen und dieser irgendwie fehlerhaft läuft, und ich dadurch "geflagt" bin am nächsten Hub, dass die Leitung gestört ist. Gibt es sowas? Und dass es nach dem Reboot der VFS "zufällig" auf Kanälen lief, wo es klappte... aber das ist doch total hanebüchen, ich kann mir nicht denken, dass es sowas gibt.

 

[floh667]

hab ein bisschen den aschluss verloren... hast du eigentlich mal die VFS als router genutzt und geschaut obs damit auch passiert?

 

[maffle]

hab ein bisschen den aschluss v erloren... hast du eigentlich mal die VFS als router genutzt und geschaut obs damit auch passiert?

Ja natürlich, steht auch oben alles. Also direkt an der VFS, ipv4 und/oder ipv6, selbes Problem bzw Phänomen.

Das seltsame ist, dass der Nvidia download jetzt nach einiger Zeit warten wieder normal durch läuft. Bzw es scheint stabiler zu laufen, als vor dem Firmware update.... hab ihn grad wieder laufen in endlosschleife und die letzten 20 mal max speed durchgelaufen. Dann aber plötzlich wieder ein Einbruch auf 12MB/s. Danach wieder max durch. Dann kurz wget -O /dev/null http://v4.speedtest.belwue.net/1G getestet danach wieder Einbruch auf 12MB/s und jetzt ist der Nvidia download auch wieder gestört....