- PLZ 8308x
- Red Internet Business 1000
- VF Station (Arris) im Bridgemode -> pfSense
- Anbindung LAN
- Verbindungsabrüche / Packetloss
- Bei Verbindungsabruch leuchted am Modem das rotes LED
Meine Erfahrungen mit dem technischen Support (Level 2?) will ich nicht kommentieren. Wenn die "Leitung" steht, sind die Modemwerte i.O. Es waren mind. 3 verschiedene Experten vor Ort die seit 2019 einpegelten. Im Down/Up habe ich im die 94x/54Mbit mit breitbandmessung.de
Anbei einige Screenshots von heute:
Das Problem zieht sich seit Ende April so dahin. Das gleiche Problem war schon mal Juli/Aug. 2020
Techniker war im Mai vor Ort, Dämpungsglied eingebaut, neu gepegelt. Lief bis Juni. Seither zwei neue VF Arris Router seit dem 11.6.21.
Der 2nd Level ist ratlos, sieht teilweise "Ausfälle", verortet aber das Problem bei mir (hüstl) da ich im Bridgemode bin. Der Leihrouter fällt definitiv aus, die LED Internetanzeige blinkt weiß oder rot. Das hat nichts mit der pfSense zu tun
Anschließent kommen die obligatorischen mails von der pfSense:
Notifications in this message: 4 ================================ 12:30:25 MONITOR: WAN_DHCP has high latency, omitting from routing group GW 188.192.160.254|188.192.160.xx|WAN_DHCP|503.348ms|1426.759ms|12%|down|highdelay 12:30:25 MONITOR: MULLVAD_VPNV4 has high latency, omitting from routing group GW 10.10.0.1|10.10.0.14|MULLVAD_VPNV4|533.388ms|1437.565ms|13%|down|highdelay 12:31:23 MONITOR: WAN_DHCP is available now, adding to routing group GW 188.192.160.254|188.192.160.xx|WAN_DHCP|46.003ms|178.074ms|7%|online|none 12:31:23 MONITOR: MULLVAD_VPNV4 is available now, adding to routing group GW 10.10.0.1|10.10.0.14|MULLVAD_VPNV4|63.349ms|177.439ms|7%|online|none
10 Minuten später bin ich vom Bridge im Router Modus, hää???
Notifications in this message: 3 ================================ 12:40:22 MONITOR: WAN_DHCP is available now, adding to routing group GW 192.168.100.254|192.168.100.197|WAN_DHCP|0ms|0ms|100%|online|none 12:40:23 MONITOR: WAN_DHCP has packet loss, omitting from routing group GW 192.168.100.254|192.168.100.197|WAN_DHCP|0ms|0ms|100%|down|highloss 12:40:25 MONITOR: WAN_DHCP is available now, adding to routing group GW 188.192.160.254|188.192.160.73|WAN_DHCP|21.286ms|14.189ms|0.0%|online|none
Liebe @Moni_GK kannst du da einen Mitarbeiter aus dem Kompetenzzentrum mit diesem Fall beauftragen?
Zwei hintereinander abgesetzte für udp: iperf3 -c iperf.par2.as49434.net -p 9228 -u -b 1000M
bewirken ein PL in der VF GW 188.192.40.254 und in Vodafone.de. Natürlich folgte die obligatorische email ´Packetloss´
Die retries im tcp - in Anbetracht der Packetgröße - ist hoch.
0.00-20.00 sec 15.7 MBytes 6.59 Mbits/sec 112 sender
Ist VF wirklich der Meinung das die Leitung OK ist?
Na dann haben wir ja die gleiche Wellenlänge erreicht und sind im sync.
Das Modem habe ich gegen 20:30 resetet. Schaun ja mal, morgen mache ich die obligatorischen Tests (Speed und iperf)
So nach dem 3ten Test ist es so wie es sein soll. Wird ein anderer Dienst gewählt muß wiederum 3 mal der Test durchlaufen um stetig 50MBits im up zu bekommen. Mhhm, so ne richtige Verbesserung kann ich nicht erkennen.
Beispiel magenta.at & ookla.
Mir geht vorrangig um den Verlauf - schnell ansteigend und beständig 50Mbit/s. Im Down gelingt es ja.
Im Trend des upload speed für den 1. ookla test mit ca. 20MBits ist ersichtlich das ca. 6sek der speed ca. 5MBit/s xxx und in den letzten sekunden sich auf 20MBit/s hoch rappelte. Leider kommt es aufgrund der Skalierung nicht so rüber. Auch der magenta Test zeigte 15Mbit/s. Verhalten wie bei ookla.
Der VF Speedtest, nunja. Abgesehen von den abstrusen Downloadwerten >1000MBit/s bei einer 1GB NIC im PC geht der up meist nicht höher als 10Mbit/s
Iperf3, wie gehabt viele retries mit TCP
thomas@ThinkPad-P50:~$ iperf3 -c iperf.par2.as49434.net -p 9226 -b 50M Connecting to host iperf.par2.as49434.net, port 9226 [ 5] local 10.16.252.100 port 47768 connected to 193.177.162.41 port 9226 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 732 KBytes 6.00 Mbits/sec 5 24.0 KBytes [ 5] 1.00-2.00 sec 509 KBytes 4.17 Mbits/sec 5 22.6 KBytes [ 5] 2.00-3.00 sec 636 KBytes 5.21 Mbits/sec 7 18.4 KBytes [ 5] 3.00-4.00 sec 700 KBytes 5.73 Mbits/sec 9 12.7 KBytes [ 5] 4.00-5.00 sec 509 KBytes 4.17 Mbits/sec 4 21.2 KBytes [ 5] 5.00-6.00 sec 636 KBytes 5.21 Mbits/sec 3 28.3 KBytes [ 5] 6.00-7.00 sec 764 KBytes 6.25 Mbits/sec 8 21.2 KBytes [ 5] 7.00-8.00 sec 636 KBytes 5.21 Mbits/sec 4 24.0 KBytes [ 5] 8.00-9.00 sec 636 KBytes 5.21 Mbits/sec 9 19.8 KBytes [ 5] 9.00-10.00 sec 509 KBytes 4.17 Mbits/sec 6 15.6 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 6.12 MBytes 5.14 Mbits/sec 60 sender [ 5] 0.00-10.02 sec 6.00 MBytes 5.02 Mbits/sec receiver
Im UPD hoher loss, der beim nächsten Durchlauf kleiner wird. Durchsatz von 41MBitd von 50MBits möglichen. Verlust eben 18%
thomas@ThinkPad-P50:~$ iperf3 -c iperf.par2.as49434.net -p 9226 -u -b 50M Connecting to host iperf.par2.as49434.net, port 9226 [ 5] local 10.16.252.100 port 50145 connected to 193.177.162.41 port 9226 [ ID] Interval Transfer Bitrate Total Datagrams [ 5] 0.00-1.00 sec 5.96 MBytes 50.0 Mbits/sec 4313 [ 5] 1.00-2.00 sec 5.96 MBytes 50.0 Mbits/sec 4317 [ 5] 2.00-3.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 [ 5] 3.00-4.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 [ 5] 4.00-5.00 sec 5.96 MBytes 50.0 Mbits/sec 4317 [ 5] 5.00-6.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 [ 5] 6.00-7.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 [ 5] 7.00-8.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 [ 5] 8.00-9.00 sec 5.96 MBytes 50.0 Mbits/sec 4317 [ 5] 9.00-10.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 59.6 MBytes 50.0 Mbits/sec 0.000 ms 0/43160 (0%) sender [ 5] 0.00-10.03 sec 49.0 MBytes 41.0 Mbits/sec 0.311 ms 7665/43159 (18%) receiver
Hohe peaks während des speedtests 00:40 - 1:20
Die anderen peaks sind mir unerklärlich, es war keiner daheim, keine up- oder downloads.
Hier ein 10h Trend. Das sind mir zuviele mikro PL
Ich denke das iperf das geeignetere Tool ist.
Die Speedtests brauchen alle einen Handshake (TCP), egal von wem. So sagt das jedenfalls mein WIreshark
mal gschwind 5 Speedtest von magenta.at durchgezogen. Die ersten 3 Tests haben im Download um die 100MBits. Das kann am Magenta liegen, oder auch nicht. Der Trend im up ist inkonsistent.
Sehr hohe Varianz in der VF Gateway IPv4 188.192.40.254 (pfSense) ab 7:30. Leichter PL all over the time. Gegen 04:00 - 07:30 ein verdächtig ruhiger ping Verlauf.
iperf tcp test, ja das wurde besser.
thomas@ThinkPad-P50:~$ iperf3 -c iperf.par2.as49434.net -p 9226 -b 50M Connecting to host iperf.par2.as49434.net, port 9226 [ 5] local 10.16.252.100 port 51656 connected to 193.177.162.41 port 9226 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 4.22 MBytes 35.4 Mbits/sec 0 218 KBytes [ 5] 1.00-2.00 sec 7.38 MBytes 61.9 Mbits/sec 0 532 KBytes [ 5] 2.00-3.00 sec 6.38 MBytes 53.5 Mbits/sec 7 247 KBytes [ 5] 3.00-4.00 sec 5.88 MBytes 49.3 Mbits/sec 12 97.6 KBytes [ 5] 4.00-5.00 sec 4.62 MBytes 38.8 Mbits/sec 0 163 KBytes [ 5] 5.00-6.00 sec 5.38 MBytes 45.1 Mbits/sec 0 187 KBytes [ 5] 6.00-7.00 sec 6.25 MBytes 52.4 Mbits/sec 0 211 KBytes [ 5] 7.00-8.00 sec 6.50 MBytes 54.5 Mbits/sec 0 232 KBytes [ 5] 8.00-9.00 sec 6.38 MBytes 53.5 Mbits/sec 0 252 KBytes [ 5] 9.00-10.00 sec 6.12 MBytes 51.4 Mbits/sec 0 270 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 59.1 MBytes 49.6 Mbits/sec 19 sender [ 5] 0.00-10.02 sec 57.0 MBytes 47.7 Mbits/sec receiver
Edith: 2ter iperf Test ist schlecht. Die Bitrate dropt
thomas@ThinkPad-P50:~$ iperf3 -c iperf.par2.as49434.net -p 9226 -b 50M Connecting to host iperf.par2.as49434.net, port 9226 [ 5] local 10.16.252.100 port 51726 connected to 193.177.162.41 port 9226 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 469 KBytes 3.85 Mbits/sec 14 12.7 KBytes [ 5] 1.00-2.00 sec 645 KBytes 5.28 Mbits/sec 5 26.9 KBytes [ 5] 2.00-3.00 sec 445 KBytes 3.65 Mbits/sec 11 22.6 KBytes [ 5] 3.00-4.00 sec 382 KBytes 3.13 Mbits/sec 15 8.48 KBytes [ 5] 4.00-5.00 sec 573 KBytes 4.69 Mbits/sec 4 15.6 KBytes [ 5] 5.00-6.00 sec 382 KBytes 3.13 Mbits/sec 9 7.07 KBytes [ 5] 6.00-7.00 sec 382 KBytes 3.13 Mbits/sec 6 14.1 KBytes [ 5] 7.00-8.00 sec 382 KBytes 3.13 Mbits/sec 7 11.3 KBytes [ 5] 8.00-9.00 sec 318 KBytes 2.61 Mbits/sec 8 11.3 KBytes [ 5] 9.00-10.00 sec 382 KBytes 3.13 Mbits/sec 6 15.6 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 4.26 MBytes 3.57 Mbits/sec 85 sender [ 5] 0.00-10.03 sec 4.13 MBytes 3.46 Mbits/sec receiver
iperf udp, gleich schlecht. 17% loss ist recht herb
thomas@ThinkPad-P50:~$ iperf3 -c iperf.par2.as49434.net -p 9226 -u -b 50M Connecting to host iperf.par2.as49434.net, port 9226 [ 5] local 10.16.252.100 port 37406 connected to 193.177.162.41 port 9226 [ ID] Interval Transfer Bitrate Total Datagrams [ 5] 0.00-1.00 sec 5.96 MBytes 50.0 Mbits/sec 4313 [ 5] 1.00-2.00 sec 5.96 MBytes 50.0 Mbits/sec 4317 [ 5] 2.00-3.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 [ 5] 3.00-4.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 [ 5] 4.00-5.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 [ 5] 5.00-6.00 sec 5.96 MBytes 50.0 Mbits/sec 4317 [ 5] 6.00-7.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 [ 5] 7.00-8.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 [ 5] 8.00-9.00 sec 5.96 MBytes 50.0 Mbits/sec 4317 [ 5] 9.00-10.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 59.6 MBytes 50.0 Mbits/sec 0.000 ms 0/43160 (0%) sender [ 5] 0.00-10.03 sec 49.6 MBytes 41.5 Mbits/sec 0.326 ms 7186/43125 (17%) receiver
Es scheint eine kleine Verbesserung zu geben. Von 10 Speedtest gehen 6 so aus wie sie sein sollen, 4 sind jedoch auffällig. Bei guten Speedtests erhalte ich via iperf3 kaum losses.
Beispiele wie es nicht sein sollte.
Scheinbar hat das auch auf die Latenz während eines Speedtests ausgewirkt. Wesendlich geringere peaks. Speedtests ab 14:30. Peaks vor 14:30 sind nicht erklärbar.
Heute wieder mal getestet. Da alle Speedtest mit TCP arbeiten ist es bei der Anzahl der Retries nicht verwunderlich das der Speed nicht kommt.
Iperf3 Parameter bedeutet: -R, --reverse Run in reverse mode (server sends, client receives).
Die Anzahl der Retries ist zu hoch, ein Indiz das was im OFDMA was nicht stimmt. Voraussetzung ist das der Pegel im up ok ist und der SNR/MER innerhalb der spec ist.
Laut Aussage von einem NE3 Techniker - Achtung hörensagen - beträgt der SNR/MER im up nur 22dB. Ob das i.O. ist und wie Abhilfe zu schaffen ist, muß VF wissen.
Hier ein Test mit udp. Leider wird der up SNR/MER im Modem nicht dargestellt. Ein loss von 0.2% ist gut. Ich hatte schon bei anderen udp tests bis zu 26% loss im up.
thomas@ThinkPad-P50:~$ iperf3 -c iperf.par2.as49434.net -p 9238 -u -b50M Connecting to host iperf.par2.as49434.net, port 9238 [ 5] local 10.16.252.142 port 39927 connected to 193.177.162.41 port 9238 [ ID] Interval Transfer Bitrate Total Datagrams [ 5] 0.00-1.00 sec 5.96 MBytes 50.0 Mbits/sec 4313 [ 5] 1.00-2.00 sec 5.96 MBytes 50.0 Mbits/sec 4317 [ 5] 2.00-3.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 [ 5] 3.00-4.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 [ 5] 4.00-5.00 sec 5.96 MBytes 50.0 Mbits/sec 4317 [ 5] 5.00-6.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 [ 5] 6.00-7.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 [ 5] 7.00-8.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 [ 5] 8.00-9.00 sec 5.96 MBytes 50.0 Mbits/sec 4317 [ 5] 9.00-10.00 sec 5.96 MBytes 50.0 Mbits/sec 4316 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-10.00 sec 59.6 MBytes 50.0 Mbits/sec 0.000 ms 0/43160 (0%) sender [ 5] 0.00-10.03 sec 59.4 MBytes 49.7 Mbits/sec 0.337 ms 105/43153 (0.24%) receiver
Mit tcp sieht die Welt bescheidener aus und da liegt imho der Knackpunkt. Der upload speed bricht auf ca. 5.5MBits zusammen, da permanent Retries -insgesamt 44 - gesendet werden müssen. Vergleiche das Eregebnis mit dem udp Test.
thomas@ThinkPad-P50:~$ iperf3 -c iperf.par2.as49434.net -p 9229 -b50M Connecting to host iperf.par2.as49434.net, port 9229 [ 5] local 10.16.252.142 port 53746 connected to 193.177.162.41 port 9229 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 766 KBytes 6.28 Mbits/sec 5 28.3 KBytes [ 5] 1.00-2.00 sec 1.12 MBytes 9.38 Mbits/sec 2 41.0 KBytes [ 5] 2.00-3.00 sec 636 KBytes 5.21 Mbits/sec 7 26.9 KBytes [ 5] 3.00-4.00 sec 764 KBytes 6.26 Mbits/sec 6 17.0 KBytes [ 5] 4.00-5.00 sec 636 KBytes 5.21 Mbits/sec 2 24.0 KBytes [ 5] 5.00-6.00 sec 636 KBytes 5.21 Mbits/sec 5 17.0 KBytes [ 5] 6.00-7.00 sec 509 KBytes 4.17 Mbits/sec 4 17.0 KBytes [ 5] 7.00-8.00 sec 636 KBytes 5.21 Mbits/sec 3 24.0 KBytes [ 5] 8.00-9.00 sec 636 KBytes 5.21 Mbits/sec 6 22.6 KBytes [ 5] 9.00-10.00 sec 636 KBytes 5.21 Mbits/sec 4 18.4 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 6.84 MBytes 5.74 Mbits/sec 44 sender [ 5] 0.00-10.03 sec 6.66 MBytes 5.57 Mbits/sec receiver
Interessant ist auch das Verhalten im ´dig google.de´ - also DNS Adressen Auflösung, nicht ping -
und ´ping Vodafone.de´.
Die hohen peakes bestehen für 5 Minuten nicht wie irrtümlich angenommen für 2 Minuten, also anders wie im Bild dargestellt.
Über die kleinen Packetlosses ganz zu schweigen. Für tcp Verbindungen ist das nicht ok.
Das verursacht ein erneutes senden eines Packetes. Für VPN Verbindungen, welche ich betreibe ist das nicht gut.
Kann jemand die peaks erklären, die Leitung war im idle Mode. Ganz vermessen wäre es eine Erklärung zu finden warum ich kleine PL habe.
Nachdem es keinen Rückwegstörer gibt, frage ich mich - abgesehen vom OFDMA - warum der up nicht so läuft.
Wie erwähnt, vor der Einführung des OFDMA hatte ich keine Probleme in up. Speedtest über VPN zu meinen Netz über Ipsec betrugen vor der Einführung des OFDMA Kanals um die 45Mbits, z.Z dümple ich was mit 15MBits umher. Speedtest ohne VPN auf der Gegenstelle um die 70MBits.
Die Leitung ist aus meiner Sicht nicht i.O, aber besser als im Juni.
Wie geht es weiter
Gruß
Thomas
