Verbindungsabbrüche/Packetloss, ratloser Support, demotivierter Level2 Support

[Kieferer]

• 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?

[Kieferer]

Erst mal vielen Dank für die schnelle Antwort. ohne den sonst üblichen Sarkasmus

Nö, einen Reset hatte ich bewußt nicht durchgeführt. Ich wollte dem Support eine Chance geben.

Den letzten Reset - den nicht erfolgreichen Netz Assi Test - habe ich erst vor wenigen Tagen durchgeführt.

Schaun ma mal, ich  nehme jetzt den Router für 5 Minuten vom Netz und checke noch mal.

[Kieferer]

Keine Änderung. Ein Iperf Test mit einer einer Verbindung ist nicht gut.

Das aufrufen einer Website dauert lange.

Mit 4 parallelen Verbindungen schaut es besser aus. Jedoch nicht so wie es mal war.

Es hat den Anschein das nur ein Upstream Kanal arbeitet.

Alle SC Upstream Kanäle sind auf 64QAM.

[Kieferer]

Sicher das der OFDMA abgedreht ist?

Upstream-Kanäle
Kanal ID	Kanaltyp	Frequenz (MHz)	Modulation	Send. Signalstärke (dBmV/dBµV)	Ranging Status
2	SC-QAM	45	64QAM	45/105	Erfolgreich
4	SC-QAM	31	64QAM	43/103	Erfolgreich
3	SC-QAM	37	64QAM	43/103	Erfolgreich
1	SC-QAM	51	64QAM	45/105	Erfolgreich

Hallo Kieferer,

es gibt ja noch die Meldung ***126/21, die einem zentralen Auftrag angehängt ist, bei dem die Kollegen mögliche Probleme im Zusammenhang mit dem OFDMA-Kanal untersuchen. Eigentlich ist bei Deinem Router der Kanal laut Einstellungen deaktiviert, er wird aber weiterhin genutzt und fast der komplette Traffic läuft darüber. Ich habe daher den Router neu bei uns angemeldet, der Kanal ist aber immer noch da. Ich habe daher eine Meldung (***709/21) an den Folgebereich gegeben, damit die Kollegen sich das mal anschauen.

Viele Grüße,

Claudia

[Kieferer]

Ein Ticket ist eröffnet.

Nun wechselt die Modulation. Max Upload nun 15 MBits

Gegen 15:00 wurde meine VPN Verbindung rausgekickt.

Mehr anzeigen

Upstream-Kanäle
Kanal ID	Kanaltyp	Frequenz (MHz)	Modulation	Send. Signalstärke (dBmV/dBµV)	Ranging Status
2	SC-QAM	45	32QAM	45/105	Erfolgreich
4	SC-QAM	31	64QAM	43/103	Erfolgreich
3	SC-QAM	37	32QAM	45/105	Erfolgreich
1	SC-QAM	51	64QAM	45/105	Erfolgreich

[Wallace]

Hey,

am 16.05 gegen 15 Uhr sehe ich einen Reboot. Hast Du den selbst verursacht?

VG Wallace

[Kieferer]

Nicht sicher.

Um 12.10 habe ich nochmals den Assi - natürlich ohne Erfolg - versucht, es kann durchaus sein das ich vor Wut und Frustration nochmals um 15:00 einen reboot durchgeführt habe. Das kann ich nicht ausschließen, ich glaube aber eher das jemand remote was gemacht hat.

Heute: Der Upload ist zwar ohne drops, jedoch vermindert.

Mehr anzeigen

Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  35.8 MBytes  30.1 Mbits/sec   15             sender
[  5]   0.00-10.09  sec  34.4 MBytes  28.6 Mbits/sec                  receiver
CPU Utilization: local/sender 0.6% (0.2%u/0.4%s), remote/receiver 4.5% (1.2%u/3.

Obwohl der Upload vermindert ist, ist das cwnd hoch - so wie für 54Mbits üblich - und es sind kaum retries ersichtlich. Eigentlichh sollten 50 MBits im Upload drin sein.

Mehr anzeigen

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  3.58 MBytes  30.1 Mbits/sec    0    198 KBytes       
[  5]   1.00-2.00   sec  4.66 MBytes  39.1 Mbits/sec    0    382 KBytes       
[  5]   2.00-3.00   sec  3.23 MBytes  27.1 Mbits/sec   14    324 KBytes       
[  5]   3.00-4.00   sec  3.23 MBytes  27.1 Mbits/sec    0    366 KBytes       
[  5]   4.00-5.00   sec  4.04 MBytes  33.9 Mbits/sec    1    277 KBytes       
[  5]   5.00-6.00   sec  3.23 MBytes  27.1 Mbits/sec    0    303 KBytes       
[  5]   6.00-7.00   sec  3.23 MBytes  27.1 Mbits/sec    0    318 KBytes       
[  5]   7.00-8.00   sec  3.23 MBytes  27.1 Mbits/sec    0    324 KBytes       
[  5]   8.00-9.00   sec  3.23 MBytes  27.1 Mbits/sec    0    325 KBytes       
[  5]   9.00-10.00  sec  4.16 MBytes  34.9 Mbits/sec    0    325 KBytes       

Gestern sah es so aus.

Mehr anzeigen

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  5.82 MBytes  48.9 Mbits/sec    0    313 KBytes       
[  5]   1.00-2.00   sec  4.97 MBytes  41.7 Mbits/sec   15    144 KBytes       
[  5]   2.00-3.00   sec  2.42 MBytes  20.3 Mbits/sec    6   60.8 KBytes       
[  5]   3.00-4.00   sec  1.62 MBytes  13.6 Mbits/sec    2   59.4 KBytes       
[  5]   4.00-5.00   sec  1.62 MBytes  13.6 Mbits/sec    4   45.2 KBytes       
[  5]   5.00-6.00   sec   827 KBytes  6.77 Mbits/sec    4   38.2 KBytes       
[  5]   6.00-7.00   sec  1.62 MBytes  13.6 Mbits/sec    2   43.8 KBytes       
[  5]   7.00-8.00   sec  1.62 MBytes  13.6 Mbits/sec    0   66.5 KBytes       
[  5]   8.00-9.00   sec  2.42 MBytes  20.3 Mbits/sec    0   89.1 KBytes       
[  5]   9.00-10.00  sec  1.62 MBytes  13.6 Mbits/sec    3   52.3 KBytes       
[  5]  10.00-11.00  sec   827 KBytes  6.77 Mbits/sec    3   35.4 KBytes       
[  5]  11.00-12.00  sec   827 KBytes  6.78 Mbits/sec    2   35.4 KBytes       
[  5]  12.00-13.00  sec   827 KBytes  6.78 Mbits/sec    3   31.1 KBytes       

Beachte den Unteschied im cwnd.

Ca. 20MBits Upload entspricht QAM64 (2^6) -> ca. 6 * 5 MHz Bandbreite = 30MBits Brutto

Irgendwie habe ich das Gefühl das nur ein SC arbeitet 

Uups

Mehr anzeigen

Upstream-Kanäle
Kanal ID	Kanaltyp	Frequenz (MHz)	Modulation	Send. Signalstärke (dBmV/dBµV)	Ranging Status
2	SC-QAM	45	32QAM	45/105	Erfolgreich
4	SC-QAM	31	32QAM	43/103	Erfolgreich
3	SC-QAM	37	16QAM	43/103	Erfolgreich
1	SC-QAM	51	64QAM	45/105	Erfolgreich

Ein iperf Test mit udp sieht perfekt aus. Der Speed im Upload ist eigendlich da.

Mehr anzeigen

Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  62.0 MBytes  52.0 Mbits/sec  0.000 ms  0/44887 (0%)  sender
[  5]   0.00-10.03  sec  62.0 MBytes  51.8 Mbits/sec  0.251 ms  0/44887 (0%)  receiver
CPU Utilization: local/sender 10.9% (10.9%u/0.0%s), remote/receiver 5.8% (1.0%u/4.8%s)

[Wallace]

Hey,

laut System wird die Last gleichmäßig auf alle 4 SC verteilt. Also daran sollte es nicht liegen. Bei der Mod sollte aber auch wesentlich mehr ankommen.

VG Wallace

[Kieferer]

---

@Wallace  schrieb:

Bei der Mod sollte aber auch wesentlich mehr ankommen.

---

Das dachte ich mir auch, daher meine Überschlagsrechnung. Ich hoffe das diese stimmt.

Ich habe gestern Nachmittag mit meinen Tamagotschi einige iperf Tests laufen lassen. Mehr als 25MBits kamen nicht zusammen.

Gegen 23:00 habe ich es am Rechner nochmals versuchtt, da kamen wieder die perfekten 50MBits - keine Einbrüche - im Upload.

Auffällig war der Anstieg des Pings an der VF Gateway.

PfSense VF Gateway

Smokeping

Upstream Pegel ok

Mehr anzeigen

Upstream-Kanäle
Kanal ID	Kanaltyp	Frequenz (MHz)	Modulation	Send. Signalstärke (dBmV/dBµV)	Ranging Status
2	SC-QAM	45	64QAM	44/104	Erfolgreich
4	SC-QAM	31	64QAM	45/105	Erfolgreich
3	SC-QAM	37	64QAM	43/103	Erfolgreich
1	SC-QAM	51	64QAM	45/105	Erfolgreich

Upload Speed auch heute morgen noch perfekt.

Mehr anzeigen

iperf3 -c iperf.par2.as49434.net -p9231 -t100 -P1 -V
Control connection MSS 1448
Time: Thu, 19 May 2022 05:38:32 GMT

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-100.00 sec   645 MBytes  54.1 Mbits/sec   20             sender
[  5]   0.00-100.06 sec   643 MBytes  53.9 Mbits/sec                  receiver

[Wallace]

Hey,

wir hatten am 18.05 von 18:40 bis 21:30 eine Last von 90% auf allen 4 SC. Das passt gut zu Deinen Beobachtungen. Nen Ausbau wird´s deswegen aber leider nicht geben, weil der Threshold nicht lang genug überschritten ist.

Ich habe gerade gesehen, dass unser 2nd Level ein Ticket ans 3rd Level gegeben hat. Bin Gespannt was die Kollegen rausfinden werden.

VG Wallace

[Kieferer]

---

@Wallace  schrieb:

Hey,

Ich habe gerade gesehen, dass unser 2nd Level ein Ticket ans 3rd Level gegeben hat. Bin Gespannt was die Kollegen rausfinden werden.

---

Cool, dafür kann es einen Grund geben. Nachdem ich am 16.5.22 ein Ticket eröffnete und eigentlich den versprochenen Rückruf schon abschrieb, erhielt ich am 17.5.22 gegen 21:15 einen Anruf des 2nd. Level.

Eine nette Dame - von der Stimme her Mitte 30, mehr Vorstellungkraft möchte ich jetzt nicht aufwenden - bemerkte das nichts auffälliges an meiner Leitung sei.

Ich machte den Vorschlag einen iferf3 tcp Test laufen zu lassen, parallel zu ihren Aufzeichnungen. Ergebnis um die 25MBits, es war nicht auffälliges an der Leitung zu beobachten.

Spannend wurde es nachdem ich einen UDP Test laufen ließ. Da sah sie 'merkwürdige' Dinge auf der Leitung. Während des laufenden udp Test fragte sie bei einem Kollegen nach.

Leider war zu diesem Zeitpunkt von ihr das Gespräch 'On Hold'. Nach ihrer Aussage sollte das nicht sein. Sie hat wahrscheinlich ein Ticket an den 3rd. Level geöffnet, so hatte ich das verstanden.

Auf die Frage hin, ob das gesamte Segment von meiner UDP Spielerei betroffen sei, wurde sie sehr unsicher.

Ich behaupte Ja, es ist ein shared Medium.

Ich habe den iperf udp Test heute nochmals nachgestellt.

Ich nehme an dass am Mittwoch der 3rd. Level mit udp Speedtests gespielt hatte. Im übrigen habe ich dieses Phänomen schon im letzen Jahr berichtet gehabt.