Teile und herrsche ... das Breitband-Kabel von Vodafone als Internet-Verbindung

PeterPawn · 1 Sep 2018

Ich bin ja eigentlich kein absoluter Gegner des Breitbandkabels als Träger für Internet-Anbindungen ... aber irgendwo ist's dann auch mal gut.

Wenn der Anbieter es dann nicht auf die Reihe bekommt, seine Technik auch vernünftig zu dimensionieren und zu konfigurieren, kommt am Ende wohl so etwas dabei heraus:

Code:

# traceroute www.heise.de
traceroute to www.heise.de (193.99.144.85), 30 hops max, 38 byte packets
 1  *  *  *
 2  ip53a9b46e.static.kabel-deutschland.de (83.169.180.110)  27.593 ms  20.158 ms  *
 3  ip5886c00b.static.kabel-deutschland.de (88.134.192.11)  27.131 ms  10.621 ms  12.972 ms
 4  ip5886edb0.static.kabel-deutschland.de (88.134.237.176)  10.345 ms  11.169 ms  13.040 ms
 5  ip5886edf0.static.kabel-deutschland.de (88.134.237.240)  19.232 ms  18.179 ms  20.119 ms
 6^C
# ping 83.169.180.110
PING 83.169.180.110 (83.169.180.110): 56 data bytes
64 bytes from 83.169.180.110: seq=0 ttl=254 time=20.278 ms
64 bytes from 83.169.180.110: seq=1 ttl=254 time=19.961 ms
64 bytes from 83.169.180.110: seq=5 ttl=254 time=19.803 ms
64 bytes from 83.169.180.110: seq=6 ttl=254 time=9.412 ms
64 bytes from 83.169.180.110: seq=14 ttl=254 time=20.682 ms
64 bytes from 83.169.180.110: seq=17 ttl=254 time=19.221 ms
64 bytes from 83.169.180.110: seq=18 ttl=254 time=10.250 ms
64 bytes from 83.169.180.110: seq=20 ttl=254 time=18.866 ms
64 bytes from 83.169.180.110: seq=21 ttl=254 time=19.124 ms
64 bytes from 83.169.180.110: seq=22 ttl=254 time=17.576 ms
64 bytes from 83.169.180.110: seq=25 ttl=254 time=27.869 ms
64 bytes from 83.169.180.110: seq=30 ttl=254 time=26.950 ms
64 bytes from 83.169.180.110: seq=31 ttl=254 time=9.109 ms
64 bytes from 83.169.180.110: seq=33 ttl=254 time=10.801 ms
64 bytes from 83.169.180.110: seq=34 ttl=254 time=8.994 ms
64 bytes from 83.169.180.110: seq=39 ttl=254 time=11.255 ms
64 bytes from 83.169.180.110: seq=41 ttl=254 time=18.685 ms
64 bytes from 83.169.180.110: seq=42 ttl=254 time=8.494 ms
64 bytes from 83.169.180.110: seq=43 ttl=254 time=9.864 ms
64 bytes from 83.169.180.110: seq=44 ttl=254 time=20.624 ms
64 bytes from 83.169.180.110: seq=45 ttl=254 time=18.481 ms
64 bytes from 83.169.180.110: seq=46 ttl=254 time=8.194 ms
64 bytes from 83.169.180.110: seq=47 ttl=254 time=18.803 ms
64 bytes from 83.169.180.110: seq=48 ttl=254 time=8.516 ms
64 bytes from 83.169.180.110: seq=50 ttl=254 time=18.912 ms
64 bytes from 83.169.180.110: seq=51 ttl=254 time=19.324 ms
64 bytes from 83.169.180.110: seq=53 ttl=254 time=9.903 ms
64 bytes from 83.169.180.110: seq=54 ttl=254 time=9.173 ms
64 bytes from 83.169.180.110: seq=55 ttl=254 time=19.191 ms
64 bytes from 83.169.180.110: seq=56 ttl=254 time=27.738 ms
64 bytes from 83.169.180.110: seq=58 ttl=254 time=9.902 ms
64 bytes from 83.169.180.110: seq=60 ttl=254 time=19.182 ms
64 bytes from 83.169.180.110: seq=61 ttl=254 time=18.869 ms
64 bytes from 83.169.180.110: seq=62 ttl=254 time=19.982 ms
64 bytes from 83.169.180.110: seq=66 ttl=254 time=19.056 ms
64 bytes from 83.169.180.110: seq=70 ttl=254 time=10.377 ms
64 bytes from 83.169.180.110: seq=74 ttl=254 time=19.589 ms
64 bytes from 83.169.180.110: seq=77 ttl=254 time=18.313 ms
64 bytes from 83.169.180.110: seq=78 ttl=254 time=17.305 ms
64 bytes from 83.169.180.110: seq=80 ttl=254 time=7.698 ms
64 bytes from 83.169.180.110: seq=83 ttl=254 time=17.408 ms
64 bytes from 83.169.180.110: seq=86 ttl=254 time=20.766 ms
64 bytes from 83.169.180.110: seq=89 ttl=254 time=9.669 ms
64 bytes from 83.169.180.110: seq=92 ttl=254 time=19.012 ms
64 bytes from 83.169.180.110: seq=93 ttl=254 time=17.923 ms
64 bytes from 83.169.180.110: seq=94 ttl=254 time=8.311 ms
64 bytes from 83.169.180.110: seq=98 ttl=254 time=20.620 ms
64 bytes from 83.169.180.110: seq=101 ttl=254 time=9.874 ms
64 bytes from 83.169.180.110: seq=104 ttl=254 time=19.633 ms
64 bytes from 83.169.180.110: seq=105 ttl=254 time=19.090 ms
64 bytes from 83.169.180.110: seq=106 ttl=254 time=8.526 ms
64 bytes from 83.169.180.110: seq=112 ttl=254 time=26.463 ms
64 bytes from 83.169.180.110: seq=113 ttl=254 time=9.603 ms
64 bytes from 83.169.180.110: seq=114 ttl=254 time=12.819 ms
64 bytes from 83.169.180.110: seq=115 ttl=254 time=18.899 ms
64 bytes from 83.169.180.110: seq=116 ttl=254 time=18.614 ms
64 bytes from 83.169.180.110: seq=117 ttl=254 time=19.169 ms
64 bytes from 83.169.180.110: seq=118 ttl=254 time=9.545 ms
64 bytes from 83.169.180.110: seq=125 ttl=254 time=21.263 ms
64 bytes from 83.169.180.110: seq=128 ttl=254 time=18.969 ms
64 bytes from 83.169.180.110: seq=129 ttl=254 time=16.145 ms
64 bytes from 83.169.180.110: seq=130 ttl=254 time=17.811 ms
64 bytes from 83.169.180.110: seq=131 ttl=254 time=18.119 ms
64 bytes from 83.169.180.110: seq=132 ttl=254 time=18.512 ms
64 bytes from 83.169.180.110: seq=135 ttl=254 time=19.543 ms
64 bytes from 83.169.180.110: seq=137 ttl=254 time=19.198 ms
64 bytes from 83.169.180.110: seq=138 ttl=254 time=19.613 ms
64 bytes from 83.169.180.110: seq=139 ttl=254 time=19.500 ms
64 bytes from 83.169.180.110: seq=141 ttl=254 time=18.457 ms
64 bytes from 83.169.180.110: seq=142 ttl=254 time=18.454 ms
64 bytes from 83.169.180.110: seq=143 ttl=254 time=18.730 ms
64 bytes from 83.169.180.110: seq=144 ttl=254 time=18.190 ms
64 bytes from 83.169.180.110: seq=145 ttl=254 time=18.795 ms
64 bytes from 83.169.180.110: seq=147 ttl=254 time=18.563 ms
64 bytes from 83.169.180.110: seq=149 ttl=254 time=18.735 ms
64 bytes from 83.169.180.110: seq=151 ttl=254 time=9.477 ms
64 bytes from 83.169.180.110: seq=152 ttl=254 time=18.992 ms
64 bytes from 83.169.180.110: seq=153 ttl=254 time=18.705 ms
64 bytes from 83.169.180.110: seq=154 ttl=254 time=8.785 ms
64 bytes from 83.169.180.110: seq=155 ttl=254 time=18.661 ms
64 bytes from 83.169.180.110: seq=157 ttl=254 time=18.485 ms
64 bytes from 83.169.180.110: seq=161 ttl=254 time=9.140 ms
64 bytes from 83.169.180.110: seq=162 ttl=254 time=20.430 ms
64 bytes from 83.169.180.110: seq=163 ttl=254 time=10.088 ms
64 bytes from 83.169.180.110: seq=164 ttl=254 time=25.760 ms
64 bytes from 83.169.180.110: seq=166 ttl=254 time=19.920 ms
64 bytes from 83.169.180.110: seq=167 ttl=254 time=16.125 ms
64 bytes from 83.169.180.110: seq=168 ttl=254 time=9.075 ms
64 bytes from 83.169.180.110: seq=169 ttl=254 time=9.558 ms
64 bytes from 83.169.180.110: seq=172 ttl=254 time=34.522 ms
64 bytes from 83.169.180.110: seq=173 ttl=254 time=10.517 ms
64 bytes from 83.169.180.110: seq=174 ttl=254 time=19.205 ms
64 bytes from 83.169.180.110: seq=177 ttl=254 time=20.439 ms
64 bytes from 83.169.180.110: seq=178 ttl=254 time=19.419 ms
64 bytes from 83.169.180.110: seq=180 ttl=254 time=9.391 ms
64 bytes from 83.169.180.110: seq=182 ttl=254 time=18.902 ms
64 bytes from 83.169.180.110: seq=185 ttl=254 time=9.751 ms
64 bytes from 83.169.180.110: seq=186 ttl=254 time=9.046 ms
64 bytes from 83.169.180.110: seq=190 ttl=254 time=20.759 ms
64 bytes from 83.169.180.110: seq=194 ttl=254 time=20.714 ms
64 bytes from 83.169.180.110: seq=195 ttl=254 time=16.376 ms
64 bytes from 83.169.180.110: seq=201 ttl=254 time=18.425 ms

Das ist ein simples "ping" von meiner FRITZ!Box 6490 zum ersten Hop innerhalb des VF/KD-Netzes, dessen IP-Adresse mir das "traceroute" davor anzeigte - beides auf der Box selbst ausgeführt, allerdings auf dem ATOM-Core und nicht auf dem CM (also dem ARM-Core). Später gehen die Latenzen dann noch bis knapp 50 ms hoch ... und wir reden hier immer noch vom ersten Hop im VF/KD-Netz.

Zählt man das mal nach (vollkommen abgesehen von den "erratischen" Roundtrip-Zeiten), ergibt das knapp 50% Paketverluste schon innerhalb der ersten 200 ICMP-Requests ... und das nur für die - im Abstand von 1 Sekunde - versandten kurzen ICMP-Pakete.

Was das für die ganzen anderen Pakete am Ende heißt, die da rundherum noch zu versenden sind, wenn man auch nur irgendeine x-beliebige Seite in einem Browser öffnen will (das geht von der DNS-Abfrage über den TLS-Connect bis zur "richtigen" Übertragung von Datenpaketen und entsprechenden Bestätigungen), kann sich jeder selbst ausrechnen - das ist dann eine absolut unbenutzbare Verbindung, weil irgendein Request am Ende immer mit einem Timeout sterben wird ... bis hin zum Laden irgendwelcher JS-Files für das Login in das Kundenportal des KNB.

---------------------------------------------------------------------------------------------

Das ist jedenfalls absoluter Müll - und die VF/KD-Hotline schießt den Vogel dann erst so richtig ab. Da man ja nicht über die Kabel-Telefonie anrufen kann (selbst wenn die SIP-Pakete zufällig mal durchkommen, sind 50% Verlust beim RTP auch keine verständlicheTelefonverbindung mehr), greift man also zum Mobiltelefon.

"Hallo und herzlich Willkommen bei Vodafone (alles nur sinngemäß, kein Anspruch auf wörtliche Wiedergabe). Wenn Sie Probleme mit Ihrer Internetverbindung oder Ihrem Telefon haben, drücken Sie die "1". Wenn Sie Probleme mit dem Fernsehempfang haben (der parallel vollkommen ungestört läuft), drücken Sie die "2". Wenn Sie ..." - man muß sich nicht alles anhören und drückt einfach mal die "1".

"Wir haben Ihnen einen Link auf Ihr Mobiltelefon geschickt, mit dem Sie auf das Kundenportal zugreifen können." Tut-Tut-Tut ... aufgelegt.

Dann kommt die SMS:

Bitteschön, hier geht es direkt zu den Lösungen im Kundenportal.
http://vod.af/bpnet

Freundliche Grüße, Ihr Vodafone-Team

Also jetzt mal ehrlich, "liebes Vodafone-Team" (ich kann auch freundlich sein) ... ich bin in aller Regel ein gemütlicher Zeitgenosse und falle eher selten aus der Rolle bzw. vergesse mich soweit, daß die verwendeten Formulierungen nicht mehr zitierfähig sind - aber Ihr habt doch wohl absolut "den Arsch offen".

---------------------------------------------------------------------------------------------

Nicht genug, daß Ihr es nicht rafft, wenn Euch ein Kunde mit einem Mobilfunkvertrag eines anderen Anbieters anruft und Ihr ihm das Gespräch dann einfach "ins Gesicht hinein" auflegt, ohne daß er eine Chance für eine andere Auswahl erhält ... das dann auch noch mit freundlichen Grüßen zu tun, ist mindestens genauso pervers wie die fortgesetzte Folter, der sich ein Kunde dann ausgesetzt sieht, wenn er es dennoch wagt, noch einmal anzurufen und - nachdem er sich dann erneut durch das Sprachmenü gekämpft hat - in der beileibe nicht kurzen Wartezeit mit einer Dauerschleife dieses unsäglichen "Good Morning" von Max Frost beschallt wird, nur weil Ihr das irgendwie (lange nachdem es tatsächlich aktuell war) mal dafür lizensiert habt.

Selbst wenn das beim ersten Hören vielleicht noch zu ertragen ist, wird es in der Dauerschleife praktisch zur Körperverletzung (oder gar zum Sonderkündigungsgrund) und Ihr müßt Euch keineswegs wundern, wenn die Kunden beim irgendwann (viel später i.d.R.) folgenden Telefonat mit einem Agent dann keineswegs mehr so "entspannt" sind, wie Ihr das vielleicht bei so einem "Gute-Laune-Song" erwarten möchtet.

Zum Samstag abend paßt das jedenfalls mal gar nicht, jedoch ist ein zeitabhängiges Handling der telefonischen Kundenkontakte vermutlich ohnehin zuviel für Euch (das ist eher was für Spezialisten, die sich mit IVR, Spracherkennung und Portalgestaltung/-Usability auch auskennen) und man sollte vermutlich schon froh sein, daß telefonische Kontakte überhaupt möglich sind bei einem Telco - schließlich verdient man an diesen Kontakten ja selbst gar nichts.

Vielleicht stellt Ihr Euch einfach mal vor, Ihr würdet nur noch Anrufe erhalten, bei denen die Kunden in den Hörer rülpsen oder furzen ... dann gewinnt Ihr eine ungefähre Ahnung von ca. 50% der Zumutungen, die Ihr den Kunden von Vodafone - und die haben i.d.R. keine Alternative zu einem solchen Anruf - angedeihen laßt, wenn diese doch nur gerne eine Störung des Internet-Anschlusses melden möchten.

Kundendienst geht jedenfalls deutlich anders - bis hin zur Frage, ob man dem Kunden etwas Musik in der Wartezeit vorspielen darf oder ob es ihm gar lieber wäre, wenn ihn der nächste freie Agent dann zurückruft, wenn sein "Ticket" an der Reihe wäre.

Hier kann Vodafone in meinen Augen jedenfalls seine "Abstammung" einfach nicht abstreifen ... man kommt hemdsärmlig daher bei den Briten und macht erst mal alles platt, was sich einem so in den Weg stellen könnte. Die Zeiten, in denen für das Geschäftsgebahren von britischen Firmen noch "Gentlemen" zuständig waren, die sich auch noch zu benehmen wußten und das in eine Auswirkung auf die Unternehmenskultur ummünzten, scheinen endgültig vorbei.

Ihr seid nur noch ein Haufen ungehobelter Rüpel und da ist die Aufforderung an den Kunden, bei dem o.g. Fehlerbild doch einfach mal die von Euch bereitgestellte ConnectBox anzuschließen und zu gucken, ob sich dabei irgendetwas ändert (auf welcher Grundlage diese Annahme basieren sollte, würde mich ja mal brennend interessieren), dann nur noch das Sahnehäubchen.

Ich kann mir jedenfalls noch bis zum 21.09.2018 überlegen, ob ich den Vertrag mit Euch verlängern will - die Zeichen dafür stehen (sicherlich wenig überraschend) eher schlecht und wenn das so weitergeht mit den Paketverlusten (das erste Ticket dazu ist vom 11.08.), wird es auch nichts mit der Bezahlung von mir für die verbleibenden drei Monate nach dem ultimativen Kündigungstermin ... dann kündige ich nämlich wegen nichterbrachter Leistung fristlos.

f666 · 4 Sep 2018

Hatte so einen Katastrophenanschluss als es noch KD war, mit TechniColor Zwangsrouter.

Gespräch mit der Dame der Hotline:
- ...wenn ich mich auf meinem Router einlogge und den Ping Test starte bekomme ich >50% Paketverluste
- Wie loggen sie sich da ein?
- Benutzername admin und mein Kennwort.
- Bei KD gibt es kein Kennwort, der Anschluss lässt sich immer ohne Kennwort nutzen.
- D'oh.
...
- Dann kann es nur an ihrem Rechner liegen. Bitte stellen sie die Netzwerkeinstellungen auf DHCP.
- Nein es liegt nicht an meinem Rechner, die Verbindung zum Router ist ohne Probleme.
- Herr XXXX, wenn sie nicht tun was ich ihnen sage kann ich ihnen nicht helfen. Aufgelegt.

Bin dann zurück auf DSL gewechselt.

PeterPawn · 4 Sep 2018

Ja, ich bin auch eher nicht der Typ fürs Telefon, wenn der DAS (dümmster anzunehmender Supporter) am anderen Ende der Leitung ist und einem genau denselben Schwachsinn verkaufen will, wie der 80-jährigen Bäuerin, die schon froh ist, wenn sie das moderne, schnurlose Telefon unfallfrei bedient.

Aber einen Tod muß man sterben und während die E-Mail (oder die Störungsmeldung im Kundenportal) am Samstag abend wohl eher in der Rundablage landet bzw. bis nach dem WE vertagt werden kann, ist das bei einem Telefonat (Hartnäckigkeit des Kunden vorausgesetzt, denn es brauchte 5 Versuche insgesamt (1x SMS, 3x Stille nach Warteschleife, 1x fast direkt durchgekommen), bis ich einen Supporter an der Leitung hatte) dann schon nicht mehr ganz so einfach.

Der Support-MA hat dann glücklicherweise nicht erst so getan, als wüßte er ohnehin alles besser (bis auf den - durch nichts zu begründenden - Vorschlag, das doch mal mit der ConnectBox zu vergleichen) ... aber merkwürdigerweise funktionierte während dieses Gespräches (davor und danach aber eben nicht) sogar die Verbindung wieder so weit, daß ein Speedtest (Ookla iirc, jedenfalls der, welcher von VF selbst angeboten wird) auf > 80% im DS kam, > 100% im US und eine Latenz von 23 ms - LOLWUT.

Wie man das bei Paketverlusten in der Größenordnung von 50% messen will (ich habe nicht geschaut, ob das TCP- oder UDP-Pakete sind und die möglichst noch auf einem bestimmten Port laufen ... weil ja ohnehin kein Provider auf die Idee kommen würde, ~~beim Abgas-~~ bei einer Durchsatzmessung irgendwie "zu schummeln") und vor allem, wie das bei TCP-Verbindungen (wo erst mal das Timeout eintreten muß, bevor die Wiederholung erfolgt) dann auf einen Durchsatz von > 80 MBit/s kommen soll, erschließt sich mir zwar nicht ... aber basierend auf der Feststellung des Hotline-Mitarbeiters, daß diese Werte "im Rahmen des Vertrags" sind, kann ich mir ausrechnen, welche Stoßrichtung sich hinter diesen Argumenten verbirgt.

Aber ich habe eben auch in der Gegenrichtung Messungen laufen (regelmäßiger Verbindungstest über Icinga-Server)´und da werden ebenfalls in diesen "Stoßzeiten" Paketverluste von 50 bis hin zu 90% (bei 10 ICMP-Requests alle fünf Minuten, was für eine "normale" Leitung - egal ob DSL oder BK - ausreicht von der Genauigkeit her) detektiert.

Ja, das Kabel ist ein "shared medium" ... und auch "Überbuchen" ist - in gewissen Grenzen - normal. Aber wenn es dann regelmäßig zu Störungen kommt (wie gesagt, das Ticket vom 11.08. hat man sich noch gar nicht getraut zu schließen bei VF, weil es immer wieder auftritt zu den "Stoßzeiten"), denn muß ich eben ausbauen oder darf schon vorher keine weiteren Verträge in diesem Segment schließen.

VF versucht ja bekanntlich mit fast allen Mitteln, die Kunden vom DSL weg zum BK-Angebot zu drängen ... solange die Kapazitäten passen, ist das für den Kunden auch nicht unbedingt ein Nachteil (weil viele ja ohnehin dann das DVB-C-Angebot parallel nutzen). Aber da, wo es Alternativen gibt (auch preislich attraktive), kann man sich die Kunden mit solch einer "langen Leitung" dann auch problemlos wieder vergraulen.

GokuSS4 · 4 Sep 2018

kein FTTC über den guten Klingeldraht verfügbar?

NDiIPP · 5 Sep 2018

Imo Nahbereich mit wohl max. VDSL25, zumindest bis 2016. Als er noch seine alte Signatur hatte, hatte er laut dieser neben einem (zeitweisen) KDG/Vodafone-Anschluss auch einen VDSL25-Anschluss (T-DSL-Business, feste IP, mit ISDN, zumindest bis 2016, dann war die Signatur mit Details zur WAN-Anbindung weg). Wegen 2016, Berlin und ISDN vermute ich mal Nahbereich. Spätestens wenn Tranche 3 abgeschlossen ist gibt es dann vielleicht VVDSL50-SVVDSL250...

PeterPawn · 5 Sep 2018

Alles schon mal dagewesen ... in den letzten 16 Jahren.

Ist aber - selbst als "Leidensgeschichte" - irgendwo OT (also selbst entscheiden, ob man wirklich weiterlesen will und bitte hinterher nicht maulen), obwohl auch hier wieder Erfahrungen mit VF/KD (damals noch "reinrassig" als KDG) vorkommen.

2002 - ADSL
2004 - Telekom Business 16.000 auf ADSL2+
2006 - VDSL 25 zusätzlich (ich habe 2 CuDA hier liegen bis in die Wohnung) mit Outdoor-DSLAM, das Haus hat einen eigenen KVz. für ~30 WE, da es ein nachträglich entstandener Lückenbau ist

Beim ersten VDSL-Vertrag war ich über mehrere Jahre tatsächlich der Einzige, der auf dem Outdoor-DSLAM hing (ich stand beim Einbau daneben) - da war ich "early adopter", denn ich hatte gleich zugeschlagen, als VDSL von der Telekom angeboten wurde (noch die Zeit, wo das VDSL-Modem neben dem Router stand). Die Nachbarn hier im Haus waren mit ADSL2 zufrieden, was schon immer direkt aus der VSt. kam. Meine Leitungslänge bis zum Outdoor-DSLAM waren damals rund 55m.

Irgendwann wurde dann 2011 bei einem Vertragswechsel der Outdoor-DSLAM entsorgt und auch mein VDSL-Anschluß direkt von der VSt. (Nahbereich) geschaltet - die ist nicht weit entfernt. Ich kann die direkt sehen (das hier ist der Bau: https://www.google.com/maps/@52.553...4!1sTsKQjZ4mYR2Dsp-I0deSJQ!2e0!7i13312!8i6656), Luftlinie 200m, Trasse wohl um die 300, würde jedenfalls zu den Leitungswerten passen.

Dank des Lückenbaus mit eigenem KVz. und durch das fehlende "Austragen" des Outdoor-DSLAM bei der Telekom, war dann über Jahre (seit 2011 bis heute) trotzdem nur VDSL25 zu buchen, obwohl die angezeigte Leitungskapazität mit der 7490 satt über den max. Werten für VDSL50 liegt - ich habe mind. alle drei Monate und mit jedem denkbaren Trick versucht, auf VDSL50 zu kommen; es führte kein Weg dorthin.

Zwischendurch hatte ich auf der zweiten TAL auch mal VDSL25 von 1&1 - bis dann BK 2012 rückkanalfähig ausgebaut wurde ... dann kam (endlich) 100 MBit/s übers Kabel und ich habe den 1&1-Anschluß zum Laufzeit-Ende aufgegeben (der T-DSL-Business hatte halt feste IPv4-Adresse bei VDSL25), weil drei dann doch etwas zuviel des Guten waren.

Irgendwann hatte ich dann den Kanal voll von der Telekom und den vergeblichen Versuchen (über Jahre, buchstäblich), da doch noch irgendwie zu höheren Geschwindigkeiten zu kommen - Frühjahr 2017 ging der VDSL-Anschluß bei der Telekom außer Betrieb (auch weil ich inzwischen auf die feste IP verzichten konnte) und ich zu einem anderen Anbieter zurück, weil ich den (alten und überdurchschnittlich teuren) T-DSL-Business-Vertrag loswerden wollte, der 2011 vom AGB-Produkt (6 Tage KF) auf C&S Comfort (und damit Laufzeit) umgestellt wurde von mir ... damals noch in der irrigen Hoffnung, das würde bei VDSL50 helfen, weil mit dieser Umstellung auch der Outdoor-DSLAM von der Telekom abgebaut wurde, der eben nur max. VDSL25 konnte, weil er zu früh in Betrieb ging.

Zwischenzeitlich hatte ich auch den Kabelanschluß mal für ein paar Monate aufgegeben ... 2012 war ich nach dem Ausbau noch gestartet mit EPC3212 und 7270 (aber keine HomeBox) und ohne (genutzte) Telefonie, weil ich die immer über den Telekom-Anschluß laufen ließ. 2013 gab's die erste 6360 von KDG, über die ich erst so richtig in das Thema "FRITZ!Box-Hacken" eingestiegen bin. Vorher hatte ich zwar auch (bzw. "nur") modifiziert, aber die 6360 ging mir dann so richtig auf den Zeiger.

Auch weil KDG die im Zuge der Fehlerbehebung (nach einem Tausch einer defekten 6360, die bei jedem DECT-Gespräch einfach mal neu startete) immer auf Werkseinstellungen setzte und sich einen Dreck darum scherte, ob das sinnvoll war und ob mein Netz damit für jeden offen stand ... weil die Box in Werkseinstellungen immer DHCP-Server spielen wollte und VPN-Verbindungen plötzlich nicht mehr genutzt wurden, sondern Daten direkt über den Router als Gateway flossen.

Da habe ich dann begonnen, die FRITZ!Boxen bei mir zu isolieren und nicht mehr direkt im "inneren" LAN zu betreiben - am Ende war auch das die Initialzündung für mein besonderes Interesse daran, wie der Provider durch TR-069 und die falschen "Werkseinstellungen" die Geräte bei den Kunden gefährdet und was AVM eigentlich dagegen tut, daß die Geräte in den Werkseinstellungen extrem leicht anzugreifen sind.

Ende 2014 gab's noch die erste 6490 für mich und zum Ende der einmalig um 12 Monate verlängerten Laufzeit bin ich 2015 aus dem Kabel-Vertrag raus, um die Chance für eine "Neuorientierung" zu haben und außerdem waren keine vernünftigen Konditionen "bei Fortsetzung des Vertrags" zu verhandeln. Im Dez. 2016 kam dann der Kabelanschluß wieder, jetzt mit Retail-6490, weil ja die Routerfreiheit Einzug gehalten hatte und auch, weil ich einige Sachen der 6490 ohne BK-Vertrag eben nicht richtig testen konnte.

Den Business bei der Telekom habe ich inzwischen von der Backe, trotzdem gibt es weiterhin "nur" VDSL25, den ich auch als zweiten Anschluß benutze - nur ist halt der DS-Durchsatz etwas bescheiden für heutige Verhältnisse und auch die 5 MBit/s im Upstream sind nicht wirklich der Renner - aber in Kombination mit den 6 MBit/s vom Kabelanschluß (wenn der mal funktioniert) war es noch auszuhalten und der Verzicht auf Entertain (das hatte ich zwischendrin auch noch, irgendwann gab's das auch mal für C&S Comfort-Verträge) tat ein Übriges, weil nicht länger die VDSL-Leitung vom TV-Stream beansprucht wurde, seitdem ich wieder auf DVB-C zurück war (auch der Sagemcom mit seinen vier Tunern war damals noch eine mittlere Sensation im Vergleich zur dbox2 ... auch weil man ja nicht ahnen konnte, daß dessen Firmware dermaßen grottig war und blieb - der wurde dann durch eine Vu abgelöst, auch wenn die nur drei Tuner hat; aber da kommt man auch wenigsten noch an Aufnahmen ran).

Aber was nutzt mir der jetzt vorhandene Kabelanschluß mit seinen 100/6 (bei einer anderen Buchung käme ich vielleicht sogar in eine andere Service-Group, ich habe mir das noch gar nicht so genau angesehen, was VF/KD da provisioniert), wenn der praktisch unbrauchbar ist ... meine Lastverteilung erkennt ja eben gerade nicht, daß beim DS-Verhältnis von 4:1 (100 vs. 25) zwischen zwei Anschlüssen der Weg über die 6490 nicht richtig funktioniert (das bemerken erst die Clients, wenn Pakete fehlen). Wenn ich das ohnehin alles bevorzugt über den DSL-Anschluß abwickeln muß, brauche ich den Kabel-Anschluß auch nicht.

Wie gesagt ... Kündigungstermin ist der 21.09. zum Dez. 2018 und wenn sich da nicht noch absehbar etwas ändert, ist eben nach zwei Jahren mal wieder Schluß. Mal sehen, wann die Telekom ihre Datenbank aktualisiert ... vielleicht gibt es hier aber auch niemals mehr als VDSL25, weil dieser dämliche, inzwischen nicht mehr vorhandene Outdoor-DSLAM wohl ein "Walking Dead" zu sein scheint. Mache ich eine Verfügbarkeitsprüfung für die eigene Adresse hier, kriege ich überall nur VDSL50, was dann wieder auf VDSL25 "gedeckelt" wird. Lasse ich das "A" in der Hausnummer weg (das ist dann jenseits einer breiteren Straße im nächsten Block), ist da (gerade noch einmal bei 1&1 gecheckt) auch SV im Angebot als DSL250 und die Nachbarhäuser hier im Block kriegen wenigstens "echtes" VDSL50 (mit den 10 MBit/s im Upstream, was für mich wichtiger wäre als der DS).

Es ist also nicht so, daß es gar keine Alternativen gäbe bzw. ich hier keine hätte und nutze ... inzwischen denke ich sogar darüber nach, einen MagentaMobil XL dazu zu nehmen, weil dessen (theoretisch und "bis zu") 50 MBit/s im Upstream natürlich schon hilfreich wären, wenn nur die Hälfte dabei rumkäme. Da ist dann auch egal, daß er das Doppelte des Kabelanschlusses kostet ... ein nicht funktionierender Anschluß für die Hälfte nutzt mir eben gar nichts - nicht einmal die Hälfte.

Flole · 6 Sep 2018

Die Verträge haben alle die gleichen QoS Einstellungen, also unabhängig davon ob du nun 100, 500 oder 1000 buchst, sogar Business und Privatkunden werden da gleich behandelt.

Wenn man jetzt aber mal etwas weiter denkt, und einfach mal einen zweiten PeterPawn zusammen mit dir an die CMTS klemmt und ihr beide die Upload Option 50 bucht (scheint dir ja wichtig zu sein), dann ist der Upload fast erschöpft (wenn du, wie ich annehme, das auch häufiger mal nutzt), ziemlich genau 8Mbit/s bleiben dann noch übrig. Die Problematik sollte einem jetzt regelrecht ins Auge springen. Wenn ich dann noch mal an die Feststellung von Robert denke, das sein Segment 30-fach Überbucht ist, da sind 2 "Power-user" natürlich ein Problem. Und wenn das Segment überlastet ist, wird ja nichts zur Entlastung getan, da kommen Rückerstattungen bis ausgebaut ist. Letztes mal als ich da angerufen hab, hat der nen Support Ticket von mir was 2 Jahre alt war rausgekramt und mich im ernst gefragt warum ich denn jetzt noch mal anrufe, das Problem hätte ich doch schon gemeldet und das Ticket wäre noch offen. Sprachlos war ich da ja schon.....

rmh · 6 Sep 2018

@PeterPawn, ich erlebe hier gerade so etwas wie ein Deja-vu, wenn ich deinen Bericht lese.
An einem zweiten Wohnsitz stand ich jüngst vor der Entscheidung mich für Kabel oder VDSL zu entscheiden, jeweils mit allen Vor- und Nachteilen. Vodafone hat nach meiner Vergleichstabelle das interessanteste Gesamtpaket für mich angeboten, allerdings wollte ich keinen Kabelanschluss mehr (nachdem ich viele Jahre Erfahrung gesammelt habe). Die Hintergründe sind vielschichtig. Unter Anderem hoher Paketverlust, eingeschränkte Upload-Bandbreite da "shared medium", DS-Lite bei Vertragsumstellung ohne Garantie vollwertiges DS durch den Support wieder aktiviert zu bekommen, stark eingeschränkter Kundenservice mit unterdurchschnittlich ausgebildetem Callcenter Personal, etc.
Nach ca. 6 Anläufen habe ich es dann tatsächlich geschafft, telefonisch einen VDSL-Vertrag über Vodafone zu erhalten und bin heute zufrieden. Es liegen stabile 33 MBit Upload an und das zu einem vergleichsweise fairen Preis. Die Fritzbox hat man mir günstig zum Kauf angeboten. Latenz und Jitter sind ein Traum im Vergleich zum Kabelanschluss. TV läuft unabhängig über DVB-S, von daher bisher kein Nachteil. Insgesamt habe ich das Gefühl die für mich richtige Entscheidung getroffen zu haben.

PeterPawn · 6 Sep 2018

QoS meinte ich auch nicht beim "anderen Tarif" ... sondern nur beim Speedtest. Es kommt mir halt komisch vor, wenn der Provider den praktischerweise gleich selbst anbietet, sowohl auf der Webseite im Kundencenter als auch telefonisch (da hätte ich auch noch den von breitbandmessung.de (also den von der BNetzA gesponsorten) verwenden dürfen) und der dann auch noch - während parallel weiterhin Verluste beim ICMP auftreten, die ich auf dem Router in der Console beobachten kann - so gar kein Problem feststellen möchte und der Support beim Provider anhand des Ergebnisses dann auch noch das Fehlen jeglichen Handlungsbedarfs konstatieren möchte.

Aber ich kenne bisher das Prinzip bei der Messung des Programms von "breitbandmessung.de" nicht - habe das zwar inzwischen installiert und lasse auch eine Messkampagne durchlaufen, aber ich habe noch keinen Mitschnitt angefertigt, was da wie gemessen wird. Ich weiß also auch nicht, welcher Aufwand da im Programm getrieben wird, um die Tatsache ggü. dem Provider zu verschleiern, daß eine solche Messung stattfindet. Je nachdem,. wie groß der Pool an möglichen Serveradressen und an verwendeten Ports für solche Messungen da wirklich ist, wäre ja eine Priorisierung des Messverkehrs durchaus machbar und - ohne VF da etwas unterstellen zu wollen, für das keine Beweise vorliegen - wenn mich ein Provider allzu beflissen zum Speedtest "drängen" will und der dann auch noch das Ergebnis "alles im grünen Bereich" ausgibt, dann bin ich halt erst mal skeptisch.

Es ist ja nicht so, daß man dabei nicht auch "schummeln" könnte ... und seitdem die Anwendung von "breitbandmessung.de" diese Kampagnen protokollieren kann und die auch als Nachweis ggü. dem Provider verwendet werden können, hat das ja auch einen ähnlich "offiziellen" Charakter wie Abgastests für Motoren in der Automobil-Branche. Da soll es ja auch schon mal die eine oder andere Vorsorge gegen allzu schlechte Ergebnisse in der Software gegeben haben - stand zumindest letztens irgendwo in den Nachrichten.

Wie gesagt - ich lasse mal die Messkampagne durchlaufen, auch wenn die wohl nur die DS-Richtung berücksichtigt nach dem, was ich bisher gesehen habe. Wenn ich dann mal Zeit habe, schneide ich zwei Messungen mit - durch den internen zusätzlichen Router (es sind schon zwei Hops bis zur 6490 selbst und alles im Netz von VF/KD ist durch doppeltes NAT (einmal intern, einmal FRITZ!Box) gegangen) ist das einerseits leicht, andererseits sorgt das eben auch für ein "unzulässiges Messprotokoll", denn das Programm stellt selbst fest:

Nun kann und werde ich dafür nicht die Struktur im Netz ändern ... der einzige "Rechner", der für die Messung nach diesen Kriterien bei mir geeignet wäre, ist der (interne) Router selbst und auch für Linux gibt es ja die Anwendung zum Messen - wenn es mir also jemals irgendwo tatsächlich um ein valides Protokoll gehen sollte, müßte ich die dort ablaufen lassen, mit abgesetztem X-Server (sofern die das überhaupt kann, ich habe es noch nicht angesehen), weil das OS auf dem Router (alter MacMini) halt auch "minimal" ist und sich auf das Wesentliche beschränkt.

Wenn diese Messungen immer nach demselben Schema laufen (ich hoffe es nicht), könnte eben auch ein Provider entsprechende "Gegenmaßnahmen" in seinem Netz ausführen ... ob ich den Traffic meiner Kunden für die Umsetzung irgendwelcher Netzsperren analysiere (jenseits von einfachem DNS-Blacklisting für solche Sperren) oder für die Priorisierung von Datenverkehr bei Durchsatzermittlungen, ist vom Prinzip her so ziemlich dasselbe Verfahren und wenn die Infrastruktur für die eine "deep packet inspection" erst mal vorhanden ist, kann ich damit auch andere Sachen machen - allerdings muß ich das natürlich nicht und schon gar nicht, wenn mein Netz tatsächlich in Ordnung ist und alle meine Kunden mit dem breitesten Grinsen, das man sich nur vorstellen kann, herumlaufen, sowie das Gespräch auf das Thema "Qualität des heimischen Internetanschlusses" kommt.

Jedenfalls werden dann hoffentlich für mich auch ein paar neue Erkenntnisse abfallen, wie das Messprogramm arbeitet ... von den verwendeten Gegenstellen bis hin zur Frage, ob ein Mix aus TCP und UDP verwendet wird (TCP ist ja "reliable" beim Transport jedes einzelnen Paketes, was ggf. auch wiederholt wird, wenn es verloren geht auf dem Weg und UDP verzichtet auf solche Maßnahmen, solange keine darüberliegende Schicht für Wiederholungen sorgt) und der über wechselnde Ports geht, weil sich Server und Client zuvor (und zwar verschlüsselt, damit da auch niemand in die "Verhandlung" hineinsehen und dynamische Priorisierungen vornehmen kann) über die Parameter einer solchen "Testverbindung" abgestimmt haben.

Allerdings ist eben - bei einer zu kleinen Anzahl von Gegenstellen für eine solche Messung, solche Server werden dafür ja extra nahe am Backbone aufgestellt, damit das Peering in alle Netze so gestaltet ist, daß auch eine Messung höherer Geschwindigkeiten möglich ist - eine Messung schon an der Zieladresse zu erkennen, wenn's schlecht läuft. Aber das wissen die Autoren solcher Programme ja alle selbst ... ich bin mal gespannt, welche "fraud counter measures" hier getroffen werden. Eine Beschreibung, die sich auch diesen Aspekten widmet (also über die Erklärung für die Benutzer, was das eigentlich ist so eine Messung, hinausgeht), habe ich noch nicht entdecken können - sollte jemand da eine Quelle kennen, nehme ich die gerne.

--------------------------------------------------------------------------------------

Trotzdem könnte ein Provider - abhängig von der Kundenzahl und der konkreten Belegung seines Netzes mit anderen Diensten - ja bei anderem Tarif auch andere "MAC Domain Downstream and Upstream Service Groups" (MULPI, 5.2.7.3) verwenden bzw. die Kanäle (sogar dynamisch) anders zusammenfassen beim Bonding (MULPI, 5.2.7.4). Das meinte ich, als ich davon schrieb, daß ein Tarifwechsel ggf. sogar eine Änderung herbeiführen könnte, aber dafür müßte man mal die Provisionierung für unterschiedliche Tarife in demselben Segment vergleichen.

Ich weiß ja, daß @Flole da auch ein paar Anstrengungen in dieser Richtung unternommen hat (diese Infos sind u.a. ja auch in den Provider-Konfigurationen enthalten, die er sammeln möchte) ... es kann also durchaus tatsächlich sein, daß ein KNB dort keine Unterschiede in den SG macht. Das sollte aber (nach meinem Verständnis der "Prinzipien", das gerne korrigiert werden darf, wenn es jemand anders/besser kennt) pro CMTS gelten und kann damit nur konkret am eigenen Anschluß ermittelt werden und gilt nicht automatisch für die gesamte Stadt oder auch nur den übernächsten Wohnblock (je nachdem, wieviele WE tatsächlich an dem eigenen CMTS hängen).

Es kann aber am Ende auch schlicht eine Überlastung des Fiber-Nodes hinter dem CMTS sein, der die Daten nicht mehr schnell genug über seine Glasfaser-Anbindung weg kriegt ... wobei das eigentlich nur für den US gelten sollte, denn auf der RF-Seite eines CMTS sollte eigentlich immer mehr Bandbreite zur Verfügung stehen, als auf der Seite der Anbindung ans Netz des Providers. Wobei auch beim DS natürlich die permanente Auslastung aller Bonding-Kanäle, weil da in einer SG mehrere Kunden "volles Ballett" laden wollen, zu diesem Fehlerbild führen kann, während auf der Fiber-Seite noch genug Bandbreite zur Verfügung steht ... nur in die Richtung dieser "Teilmenge" an Kunden besteht dann halt "Stau".

EDIT: Ich habe die Infos zum Messvorgang doch noch gefunden ... manchmal ist man einfach nur betriebsblind.

Flole · 6 Sep 2018

Ich beziehe mich jetzt mal ausschließlich auf die Casa CMTS, darüber habe ich am meisten Informationen (ich habe die komplette Doku hier vorliegen) und Wissen und da diese ja die Zukunft bei Vodafone ist, sollte das immer mehr Leute betreffen:

"MAC Domain Downstream and Upstream Service Groups" gibt es auf der Casa so wie du es dir vorstellst gar nicht mehr. Die Kanäle werden dynamisch zugewiesen und je nach Konfiguration können die Modems auch während des Betriebs durch die Gegend geschoben werden und ein Kanalwechsel durchgeführt werden. Das ist eon Verfahren zum Load balancing um genau das Problem zu verhindern. Die Kanäle sind auch nicht Bestandteil der Konfigurationsdatei.

Es gibt auch pro "Region" nur eine CMTS, diese versorgt dann mal eben eine ganze Stadt wenn die das denn schafft. Schauen wir uns aber mal Berlin an, ein Blick auf helpdesk.kdgforum.de ergibt folgende Kopfstationen: Berlin 85 (Zehlendorf, BK 5), Berlin 131 (Wittenau, BK 6), Berlin 87 (Spandau, BK 14), Berlin 571 (Lichtenberg, BK 16E), Berlin 400 (Tempelhof, BK 40)

Wenn also eine davon überlastet wäre (was ich im Moment nicht wirklich glaube) dann wäre das Problem im Prinzip riesig. Die Mühe rauszufinden welche Cmts nun für dich zuständig ist habe ich mir jetzt nicht gemacht, vielleicht weißt du es ja beim lesen auch schon direkt das eine davon so nah bei dir steht das es nur die sein kann. Die CMTS versorgt dann wiederum mehrere Segmente, die überlastet sein können. Die CMTS selbst ist mit mehreren Gigabit angebunden und diese Anbindung müsste tatsächlich schneller sein als die auf der RF Seite. Ich gehe mal davon aus, das die Casa mal voll ausgenutzt wird und ein 100gigabit/s Modul dort steckt. Gehen wir ebenfalls davon aus, das es nicht nur eine Faser gibt sondern mindestens 2 wegen der Redundanz. Nun hat man also 200gigabit/s zur Verfügung, und könnte damit 50 Segmente mit den 3.8 (aufgerundet 4) gbit/s versorgen. Selbst wenn man da nicht mit nem Gleichzeitigsfaktor arbeitet und nochmal 10 Segmente dazu schmeißt weil die nie alle voll ausgenutzt sind, ist das eigentlich schon ne ganze Masse. 60 Segmente mit jeweils etwa 200 Kunden (hab ich bei mir mal festgestellt und setze das hier einfach mal an, hier läuft nämlich alles super) und schon ergeben 12000 Leute an einer Cmts ohne Probleme auf der Anbindung an das Providernetz. Notfalls würde man da aber einfach eine Faser mehr aufschalten, das erfordert keine Tiefbauarbeiten und dementsprechend geht das ganz schnell, an der CMTS sollten mehr als genug zur Verfügung stehen. Bei einer Segmentierung sieht das etwas anders aus....
Das ganze ist jetzt natürlich mal rein theoretisch, das da durchaus mehr Leute dran aufgeschaltet werden (können) ohne das es Probleme gibt sollte klar sein, ich wollte nur mal verdeutlichen in was für einer Größenordnung wir uns bewegen und wie viele Leute dann betroffen wären.

Ich vermute hier auch eher ein ausgehendes als ein eingehendes Problem (also Verluste im Upstream), um das zu testen könntest du ja mal mit iperf eingehend und ausgehend ein kleines bisschen UDP Traffic verursachen, wenn auf einer Seite Verluste sind weißt du zumindest schon mal in welcher Richtung das nun passiert. Ich würde mich auch als Gegenstelle dafür anbieten falls du da sonst nichts hast.

Der Speedtest kann zumindest auf der Strecke CMTS-Modem nicht bevorzugt behandelt werden bzw. wird es nicht, aber über die genauen Zusammenhänge in dem Bereich werde ich noch nichts öffentlich sagen bis meine "Forschung" komplett abgeschlossen ist und entsprechend präsentiert wurde.

Wenn du Mal die Modemwerte (also die Pegel) postest könnte da bestimmt Mal jemand drüber schauen ob da vielleicht einfach nur was verpegelt ist (das würde sowas auch erklären). Die uncorrected errors hat Vodafone ja sowohl aus web if als auch supportdaten verbannt, das wäre sehr interessant in diesem Zusammenhang gewesen.

PeterPawn · 6 Sep 2018

Falsch angepaßte Pegel würden ja nicht zu einem zeitlich eingrenzbaren Problem passen ... höchstens dann, wenn das Bonding auch noch so weit "dynamisch" ist, daß zu bestimmten Zeitpunkten auch ungünstigere Kanäle mit Fehlern, die Wiederholungen erfordern, soweit ausgeklammert sind, daß sie nicht genutzt werden und erst dann wieder "ins Spiel kommen", wenn es auf den anderen Kanälen eng ist. Meines Wissens ist das nicht das Prinzip ... also sollten entsprechende Fehler auf der RF-Seite des CM sich m.E. auch den ganzen Tag über zeigen und nicht regelmäßig wiederkehrende Probleme verursachen. Das würde ich also schon mal ausschließen - Gegenargumente?

Es ist auch ziemlich offensichtlich, daß die Probleme erst mit Konfigurationsänderungen seitens des KNB Einzug gehalten haben (im November geht hier ja dann das große Stühlerücken im BK-Netz los). Ich habe ja nun glücklicherweise einen "Fundus" an Support-Daten und da braucht man nur mal die DOCSIS-Abschnitte zu vergleichen, um festzustellen, was sich geändert hat - die eine Datei (mit QAM64 im US) ist vom 18.07.2018 und die andere von heute (weitere zwischendrin müßte ich erst suchen):

Code:

DOCSIS DB Info:
----------------------------------------------------
CM Mac Status: Operational    Mode: DOCSIS 3.0
Docsis 1.0 CoS: no           Docsis 2.0 Mode: enabled
eRouter Mode: 3 (IPv4+IPv6)
eRouter Enabled: yes
Multiple Dowstreams: yes    Multiple Upstreams: yes
Last frequency: 562000000   Max CPE: 2
RegReq SID: 14270            override SID: 0
UCD on all Downstreams: yes
Channel Change Status: No active channel change
Transmit Channel Configuration: yes
Upstream Drop Classifiers: no
Multicast DSID Forwarding: GMAC promiscuous support
US 1: SID: 14270    UCID: 10    DCID: 0    usable: yes
US 2: SID: 14270    UCID: 12    DCID: 0    usable: yes
US 3: SID: 14270    UCID: 11    DCID: 0    usable: yes
US 4: SID: 14270    UCID: 9    DCID: 0    usable: yes
US 5: SID: 0    UCID: 0    DCID: 0    usable: no (reason 1 REJECT_OTHER)
US 6: SID: 0    UCID: 0    DCID: 0    usable: no (reason 1 REJECT_OTHER)
US 7: SID: 0    UCID: 0    DCID: 0    usable: no (reason 1 REJECT_OTHER)
US 8: SID: 0    UCID: 0    DCID: 0    usable: no (reason 1 REJECT_OTHER)
Reinit Mac Reason: Power on
Resets: 0     Invalid Reg-Rsp's: 0     T1-Timeouts: 0

DOCSIS Us Status:
----------------------------------------------------
PGA gain code is 57
PGA current is:      3
Current Full Scale:  56.080002
PloadMinSet:         5.000000
Initial PloadMinSet: 5.000000
Power Reporting:    Yes

Digital Att: 14.217728   15.482991   14.880641   13.041710   9.127320   9.127320   9.127320   9.127320
Frquency   : 52.200089   36.200104   45.800095   58.600086   10.000026   10.000026   10.000026   10.000026
Symbol rate:      5.12        5.12        5.12        5.12   Invalid    Invalid    Invalid    Invalid
modulation :    64QAM      64QAM      64QAM      64QAM        ERR        ERR        ERR        ERR
SCDMA mode :        0          0          0          0          0          0          0          0
rep power  :  43.2500    42.2500    42.5000    44.2500    -1.0000    -1.0000    -1.0000    -1.0000
Upstream    :      10         12         11          9        ---        ---        ---        ---

Phigh      :  51.0000    51.0000    51.0000    51.0000     0.0000     0.0000     0.0000     0.0000
PLow       :  24.1800    24.1800    24.1800    24.1800     0.0000     0.0000     0.0000     0.0000
PdrwHigh   :  46.0000    46.0000    46.0000    46.0000     0.0000     0.0000     0.0000     0.0000
PdrwLow    :  34.0000    34.0000    34.0000    34.0000     0.0000     0.0000     0.0000     0.0000
deltaPf    :   1.3880     1.6520     1.3000     1.2120     0.0000     0.0000     0.0000     0.0000

DOCSIS Ds Status:
----------------------------------------------------
Number of tuners   : 1
Tuner Id #         :    1   
Frequency(MHz)     : 0.000   
Tuner Type         : Full CBW

Number of receivers: 24

Receiver #         :    1         2         3         4         5         6         7         8   
Frequency(MHz)     : 562.000   546.000   554.000   570.000   578.000   586.000   594.000   602.000 
QAM Lock           : YES       YES       YES       YES       YES       YES       YES       YES     
FEC Lock           : YES       YES       YES       YES       YES       YES       YES       YES     
MPEG Lock          : YES       YES       YES       YES       YES       YES       YES       YES     
CH Enabled         : YES       YES       YES       YES       YES       YES       YES       YES     
MSE                : -40.366   -40.366   -40.366   -40.366   -40.946   -40.366   -40.946   -40.366 

Receiver #         :    9        10        11        12        13        14        15        16   
Frequency(MHz)     : 0.000     0.000     0.000     0.000     666.000   674.000   682.000   690.000 
QAM Lock           : NO        NO        NO        NO        YES       YES       YES       YES     
FEC Lock           : NO        NO        NO        NO        YES       YES       YES       YES     
MPEG Lock          : NO        NO        NO        NO        YES       YES       YES       YES     
CH Enabled         : NO        NO        NO        NO        YES       YES       YES       YES     
MSE                : -inf      -inf      -inf      -inf      -40.366   -40.366   -40.366   -40.366 

Receiver #         :   17        18        19        20        21        22        23        24   
Frequency(MHz)     : 698.000   706.000   714.000   722.000   762.000   770.000   778.000   786.000 
QAM Lock           : YES       YES       YES       YES       YES       YES       YES       YES     
FEC Lock           : YES       YES       YES       YES       YES       YES       YES       YES     
MPEG Lock          : YES       YES       YES       YES       YES       YES       YES       YES     
CH Enabled         : YES       YES       YES       YES       YES       YES       YES       YES     
MSE                : -35.544   -35.544   -36.335   -36.335   -37.305   -37.305   -37.305   -36.558 

DCID               : 3         1         2         4         5         6         7         8       
                   : -NA-      -NA-      -NA-      -NA-      9         10        11        12     
                   : 13        14        15        16        17        18        19        20     
DCID               : 3         1         2         4         5         6         7         8       
                   : ---       ---       ---       ---       9         10        11        12     
                   : 13        14        15        16        17        18        19        20     
RC index           : 1 [Prm]   2         3         4         5         6         7         8       
                   : -NA-      -NA-      -NA-      -NA-      9         10        11        12     
                   : 13        14        15        16        17        18        19        20

Code:

DOCSIS DB Info:
----------------------------------------------------
CM Mac Status: Operational    Mode: DOCSIS 3.0
Docsis 1.0 CoS: no           Docsis 2.0 Mode: enabled
eRouter Mode: illegal mode (4)
eRouter Enabled: yes
Multiple Dowstreams: yes    Multiple Upstreams: yes
Last frequency: 578000000   Max CPE: 0
RegReq SID: 5641            override SID: 0
UCD on all Downstreams: yes
Channel Change Status: No active channel change
Transmit Channel Configuration: yes
Upstream Drop Classifiers: no
Multicast DSID Forwarding: GMAC promiscuous support
US 1: SID: 5641    UCID: 4    DCID: 0    usable: yes
US 2: SID: 5641    UCID: 1    DCID: 0    usable: yes
US 3: SID: 5641    UCID: 3    DCID: 0    usable: yes
US 4: SID: 5641    UCID: 2    DCID: 0    usable: yes
US 5: SID: 0    UCID: 0    DCID: 0    usable: no
US 6: SID: 0    UCID: 0    DCID: 0    usable: no
US 7: SID: 0    UCID: 0    DCID: 0    usable: no
US 8: SID: 0    UCID: 0    DCID: 0    usable: no
Reinit Mac Reason: No primary SF upstream channel
Resets: 4     Invalid Reg-Rsp's: 0     T1-Timeouts: 0

DOCSIS Us Status:
----------------------------------------------------
PGA gain code is 61
PGA current is:      3
Current Full Scale:  60.080002
PloadMinSet:         1.500000
Initial PloadMinSet: 0.000000
Power Reporting:    Yes

Digital Att: 15.522754   13.081737   15.169152   15.258897   9.127320   9.127320   9.127320   9.127320
Frquency   : 36.200001   58.599998   45.799999   52.200001   10.000025   10.000025   10.000025   10.000025
Symbol rate:      5.12        5.12        5.12        5.12   Invalid    Invalid    Invalid    Invalid
modulation :     8QAM       8QAM       8QAM       8QAM        ERR        ERR        ERR        ERR
SCDMA mode :        0          0          0          0          0          0          0          0
rep power  :  46.2100    48.2100    46.2100    46.2100    -1.0000    -1.0000    -1.0000    -1.0000
Upstream    :       4          1          3          2        ---        ---        ---        ---

Phigh      :  52.2100    52.2100    52.2100    52.2100     0.0000     0.0000     0.0000     0.0000
PLow       :  24.1800    24.1800    24.1800    24.1800     0.0000     0.0000     0.0000     0.0000
PdrwHigh   :  50.7100    50.7100    50.7100    50.7100     0.0000     0.0000     0.0000     0.0000
PdrwLow    :  38.7100    38.7100    38.7100    38.7100     0.0000     0.0000     0.0000     0.0000
deltaPf    :   1.6520     1.2120     1.3000     1.3880     0.0000     0.0000     0.0000     0.0000

DOCSIS Ds Status:
----------------------------------------------------
Number of tuners   : 1
Tuner Id #         :    1   
Frequency(MHz)     : 0.000   
Tuner Type         : Full CBW

Number of receivers: 24

Receiver #         :    1         2         3         4         5         6         7         8   
Frequency(MHz)     : 578.000   586.000   594.000   602.000   666.000   674.000   682.000   690.000 
QAM Lock           : YES       YES       YES       YES       YES       YES       YES       YES     
FEC Lock           : YES       YES       YES       YES       YES       YES       YES       YES     
MPEG Lock          : YES       YES       YES       YES       YES       YES       YES       YES     
CH Enabled         : YES       YES       YES       YES       YES       YES       YES       YES     
MSE                : -38.605   -38.605   -38.983   -40.366   -40.366   -40.366   -40.366   -40.366 

Receiver #         :    9        10        11        12        13        14        15        16   
Frequency(MHz)     : 626.000   0.000     0.000     0.000     698.000   706.000   714.000   722.000 
QAM Lock           : YES       NO        NO        NO        YES       YES       YES       YES     
FEC Lock           : YES       NO        NO        NO        YES       YES       YES       YES     
MPEG Lock          : YES       NO        NO        NO        YES       YES       YES       YES     
CH Enabled         : YES       YES       YES       YES       YES       YES       YES       YES     
MSE                : -38.983   -17.302   -17.307   -17.313   -35.729   -36.335   -36.335   -36.558 

Receiver #         :   17        18        19        20        21        22        23        24   
Frequency(MHz)     : 762.000   770.000   778.000   786.000   794.000   802.000   810.000   818.000 
QAM Lock           : YES       YES       YES       YES       YES       YES       YES       YES     
FEC Lock           : YES       YES       YES       YES       YES       YES       YES       YES     
MPEG Lock          : YES       YES       YES       YES       YES       YES       YES       YES     
CH Enabled         : YES       YES       YES       YES       YES       YES       YES       YES     
MSE                : -37.305   -36.558   -37.305   -36.558   -36.335   -36.335   -36.335   -36.335 

DCID               : 5         6         7         8         9         10        11        12     
                   : -NA-      -NA-      -NA-      -NA-      13        14        15        16     
                   : 17        18        19        20        21        22        23        24     
DCID               : 5         6         7         8         9         10        11        12     
                   : ---       ---       ---       ---       13        14        15        16     
                   : 17        18        19        20        21        22        23        24     
RC index           : 1 [Prm]   2         3         4         5         6         7         8       
                   : -NA-      -NA-      -NA-      -NA-      9         10        11        12     
                   : 13        14        15        16        17        18        19        20

Einer Segmentierung kannst Du in Berlin gar nicht aus dem Weg gehen ... Berlin hat irgendwas zwischen 1,9 und 2 Mio. Wohnungen und selbst wenn nur die Hälfte (oder auch nur 25%) davon mit BK-Anschlüssen versehen ist und es auch noch Versorgung über andere Anbieter (die sich hinter PŸUR versammeln) gibt, sind eben 5 KDG-Kopfstationen nicht automatisch auch nur fünf CMTS - das würde wohl vorne und hinten nicht reichen bzw. das würde kein einzelnes CMTS (schon von der Rechenleistung her vermutlich) stemmen können. Da wird also fleißig segmentiert und die CMTS (bzw. die jeweiligen Segmente, weil für die anderen Dienste auf DVB-C-Kanälen die CMTS ja nicht zuständig sind) nutzen vielleicht noch alle dieselbe Belegung der Kanäle - schon damit es nicht 100 verschiedene Belegungspläne für Berlin gibt.

Wobei vielleicht nicht mal das zwingend ist bei den Datenkanälen, wie man oben sehen kann ... außer es wurden wirklich auch an allen anderen CMTS die US-Kanäle von QAM64 auf QAM8 umgestellt (die Frequenzen sind ja noch dieselben und über das Modulationsverfahren auf einem Kanal entscheidet das CMTS und nicht das CM, afaik).

Ich habe jedenfalls zugegebenermaßen absolut keine Idee, wo mein zuständiges CMTS stehen mag und welchen "Einzugsbereich" es am Ende versorgt ... ich kann nur sehen, daß sich etwas geändert hat und in Grenzen auch noch, was das betrifft.

Was aber (ich verwende halt immer noch 06.83, ggf. ist das in der 06.87 sogar schon korrigiert) auch putzig ist ... trotz der DOCSIS-Daten aus dem zweiten Protokoll oben (dem mit QAM8 im Upstream), ist das FRITZ!OS tapfer der Meinung:

Code:

Kabel-Internet aktiv
Verbindungsdauer: 01:02:15:19
EuroDOCSIS 3.0
19 Kanäle in Empfangsrichtung
4 Kanäle in Senderichtung

... was so irgendwie gar nicht mit meiner manuellen Zählung übereinstimmt. Trotzdem zeigt es natürlich auch nur 19 Kanäle in seiner Detailansicht.

Wobei die "kurze" Verbindungsdauer auch mal wieder der Tatsache geschuldet ist, daß erst gestern die Synchronisation komplett verloren ging:

Code:

05.09.18 10:50:06 IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: 2a02:8109:a4xx:xxxx::/62
05.09.18 10:50:06 Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: 2a02:8109:8000:xxxx:a4e0:xxxx:xxxx:xxxx
05.09.18 10:50:05 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: 91.64.2xx.xxx, DNS-Server: 83.169.184.33 und 83.169.184.97, Gateway: 91.64.2xx.xxx
05.09.18 10:50:02 Kabel-Internet ist verfügbar.
05.09.18 10:49:26 Kabel-Internet Synchronisierung beginnt (Training).
05.09.18 10:48:09 Verbindung zum Online-Speicher beendet.
05.09.18 10:48:08 Internetverbindung IPv6 wurde getrennt, Präfix nicht mehr gültig.
05.09.18 10:48:08 Internetverbindung wurde getrennt.
05.09.18 10:48:08 VPN-Verbindung zu XXX wurde getrennt. Ursache: 5 IP address change
05.09.18 10:48:08 Kabel-Internet antwortet nicht (Keine Synchronisierung).
05.09.18 10:48:08 Kabel-Internet ist verfügbar (Synchronisierung besteht mit 0/1000000 kbit/s).

Auch die Angabe mit den "Max. CPE: 0" sieht erst mal komisch aus, ist auch nicht wirklich das, was VF/KD hier provisioniert hat:

Code:

Network Access Control:on
Privacy Enable:on
Software Upgrade IPv6 TFTP Server:2a02:8100:c0:249:0:0:32:1101
Subscriber Management Filter Groups:CMupstream 10, CMdownstream 0, SUBupstream 15, SUBdownstream 0, PSupstream 15, PSdownstream 0, MTAupstream 27, MTAdownstream 0, STBupstream 15, STBdownstream 0
SNMP MIB Object(docsDevFilterIpDefault.0):1.3.6.1.2.1.69.1.6.3.0, Integer, 2
SNMP MIB Object(docsDevFilterIpStatus.1):1.3.6.1.2.1.69.1.6.4.1.2.1, Integer, 4
SNMP MIB Object(docsDevFilterIpControl.1):1.3.6.1.2.1.69.1.6.4.1.3.1, Integer, 1
SNMP MIB Object(docsDevFilterIpIfIndex.1):1.3.6.1.2.1.69.1.6.4.1.4.1, Integer, 0
SNMP MIB Object(docsDevFilterIpDirection.1):1.3.6.1.2.1.69.1.6.4.1.5.1, Integer, 3
SNMP MIB Object(docsDevFilterIpBroadcast.1):1.3.6.1.2.1.69.1.6.4.1.6.1, Integer, 2
SNMP MIB Object(docsDevFilterIpSaddr.1):1.3.6.1.2.1.69.1.6.4.1.7.1, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpSmask.1):1.3.6.1.2.1.69.1.6.4.1.8.1, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDaddr.1):1.3.6.1.2.1.69.1.6.4.1.9.1, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDmask.1):1.3.6.1.2.1.69.1.6.4.1.10.1, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpProtocol.1):1.3.6.1.2.1.69.1.6.4.1.11.1, Integer, 6
SNMP MIB Object(docsDevFilterIpDestPortLow.1):1.3.6.1.2.1.69.1.6.4.1.14.1, Integer, 137
SNMP MIB Object(docsDevFilterIpDestPortHigh.1):1.3.6.1.2.1.69.1.6.4.1.15.1, Integer, 139
SNMP MIB Object(docsDevFilterIpStatus.2):1.3.6.1.2.1.69.1.6.4.1.2.2, Integer, 4
SNMP MIB Object(docsDevFilterIpControl.2):1.3.6.1.2.1.69.1.6.4.1.3.2, Integer, 1
SNMP MIB Object(docsDevFilterIpIfIndex.2):1.3.6.1.2.1.69.1.6.4.1.4.2, Integer, 0
SNMP MIB Object(docsDevFilterIpDirection.2):1.3.6.1.2.1.69.1.6.4.1.5.2, Integer, 3
SNMP MIB Object(docsDevFilterIpBroadcast.2):1.3.6.1.2.1.69.1.6.4.1.6.2, Integer, 2
SNMP MIB Object(docsDevFilterIpSaddr.2):1.3.6.1.2.1.69.1.6.4.1.7.2, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpSmask.2):1.3.6.1.2.1.69.1.6.4.1.8.2, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDaddr.2):1.3.6.1.2.1.69.1.6.4.1.9.2, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDmask.2):1.3.6.1.2.1.69.1.6.4.1.10.2, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpProtocol.2):1.3.6.1.2.1.69.1.6.4.1.11.2, Integer, 17
SNMP MIB Object(docsDevFilterIpDestPortLow.2):1.3.6.1.2.1.69.1.6.4.1.14.2, Integer, 137
SNMP MIB Object(docsDevFilterIpDestPortHigh.2):1.3.6.1.2.1.69.1.6.4.1.15.2, Integer, 139
SNMP MIB Object(docsDevFilterIpStatus.3):1.3.6.1.2.1.69.1.6.4.1.2.3, Integer, 4
SNMP MIB Object(docsDevFilterIpControl.3):1.3.6.1.2.1.69.1.6.4.1.3.3, Integer, 1
SNMP MIB Object(docsDevFilterIpIfIndex.3):1.3.6.1.2.1.69.1.6.4.1.4.3, Integer, 0
SNMP MIB Object(docsDevFilterIpDirection.3):1.3.6.1.2.1.69.1.6.4.1.5.3, Integer, 3
SNMP MIB Object(docsDevFilterIpBroadcast.3):1.3.6.1.2.1.69.1.6.4.1.6.3, Integer, 2
SNMP MIB Object(docsDevFilterIpSaddr.3):1.3.6.1.2.1.69.1.6.4.1.7.3, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpSmask.3):1.3.6.1.2.1.69.1.6.4.1.8.3, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDaddr.3):1.3.6.1.2.1.69.1.6.4.1.9.3, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpDmask.3):1.3.6.1.2.1.69.1.6.4.1.10.3, IP Address, 0.0.0.0
SNMP MIB Object(docsDevFilterIpProtocol.3):1.3.6.1.2.1.69.1.6.4.1.11.3, Integer, 6
SNMP MIB Object(docsDevFilterIpDestPortLow.3):1.3.6.1.2.1.69.1.6.4.1.14.3, Integer, 135
SNMP MIB Object(docsDevFilterIpDestPortHigh.3):1.3.6.1.2.1.69.1.6.4.1.15.3, Integer, 135
Baseline Privacy Configuration Settings
  Authorize Wait Timeout:10
  Reauthorize Wait Timeout:10
  Authorization Grace Time:600
  Operational Wait Timeout:1
  Rekey Wait Timeout:1
  TEK Grace Time:600
  Authorize Reject Wait Timeout:60
  SA Map Wait Timeout:1
  SA Map Max Retries:4
Maximum Number of CPEs:2
Upstream Service Flow Encodings
  Service Flow Reference:1
  Quality of Service Parameter Set:provisioned admitted active
  Traffic Priority:0
  Upstream Maximum Sustained Traffic Rate:6360000
  Maximum Traffic Burst:28000
  Maximum Concatenated Burst:28000
  Service Flow Scheduling Type:Best Effort
  IP Type of Service Overwrite:and-mask 0x00 or-mask 0x00
Upstream Service Flow Encodings
  Service Flow Reference:12
  Quality of Service Parameter Set:provisioned admitted active
  Traffic Priority:4
  Service Flow Scheduling Type:Best Effort
  IP Type of Service Overwrite:and-mask 0x68 or-mask 0x68
  Service Flow Forbidden Attribute Mask:80000000
Downstream Service Flow Encodings
  Service Flow Reference:2
  Quality of Service Parameter Set:provisioned admitted active
  Traffic Priority:0
  Downstream Maximum Sustained Traffic Rate:106000000
  IP Type of Service Overwrite:and-mask 0x00 or-mask 0x00
Downstream Service Flow Encodings
  Service Flow Reference:4
  Quality of Service Parameter Set:provisioned admitted active
  Traffic Priority:4
  Service Flow Forbidden Attribute Mask:80000000
Upstream Packet Classification Encoding
  Classifier Reference:201
  Service Flow Reference:12
  Classifier Activation State:on
  Ethernet LLC Packet Classification Encodings
    Ethertype/DSAP/MacType:type 0x03 eprot1 0x0F eprot2 0x16
Upstream Packet Classification Encoding
  Classifier Reference:205
  Service Flow Reference:12
  Classifier Activation State:on
  IP Packet Classification Encodings
    IP Protocol:17
    IP Destination Address:88.134.209.0
    IP Destination Mask:255.255.255.0
    TCP/UDP Destination Port Start:5060
    TCP/UDP Destination Port End:5060
Upstream Packet Classification Encoding
  Classifier Reference:208
  Service Flow Reference:12
  Classifier Activation State:on
  IP Packet Classification Encodings
    IP Type of Service Range and Mask:tos-low 0x50 tos-high 0x50 tos-mask 0xFF
    IP Protocol:17
    IP Destination Address:88.134.209.0
    IP Destination Mask:255.255.255.0
Upstream Packet Classification Encoding
  Classifier Reference:210
  Service Flow Reference:12
  Classifier Activation State:on
  Ethernet LLC Packet Classification Encodings
    Ethertype/DSAP/MacType:type 0x03 eprot1 0x25 eprot2 0x2B
Upstream Packet Classification Encoding
  Classifier Reference:212
  Service Flow Reference:12
  Classifier Activation State:on
  IP Packet Classification Encodings
    IP Protocol:17
    IP Source Address:10.0.0.0
    IP Source Mask:255.0.0.0
    TCP/UDP Destination Port Start:67
    TCP/UDP Destination Port End:67
Upstream Packet Classification Encoding
  Classifier Reference:219
  Service Flow Reference:12
  Classifier Activation State:on
  IP Packet Classification Encodings
    TCP/UDP Destination Port Start:53
    TCP/UDP Destination Port End:53
  IPv6 Packet Classification Encodings
    IPv6 Next Header Type:17
    IPv6 Source Address:2a02:8101:1000:0:0:0:0:0
    IPv6 Source Prefix Length:36
    IPv6 Destination Address:2a02:8100:0:0:0:0:0:0
    IPv6 Destination Prefix Length:32
Upstream Packet Classification Encoding
  Classifier Reference:222
  Service Flow Reference:12
  Classifier Activation State:on
  IP Packet Classification Encodings
    TCP/UDP Destination Port Start:547
    TCP/UDP Destination Port End:547
  IPv6 Packet Classification Encodings
    IPv6 Next Header Type:17
    IPv6 Source Address:2a02:8101:1000:0:0:0:0:0
    IPv6 Source Prefix Length:36
    IPv6 Destination Address:2a02:8100:0:0:0:0:0:0
    IPv6 Destination Prefix Length:32
Downstream Packet Classification Encoding
  Classifier Reference:103
  Service Flow Reference:4
  Classifier Activation State:on
  IP Packet Classification Encodings
    IP Protocol:17
    IP Destination Address:10.0.0.0
    IP Destination Mask:255.0.0.0
    TCP/UDP Destination Port Start:161
    TCP/UDP Destination Port End:161
Downstream Packet Classification Encoding
  Classifier Reference:104
  Service Flow Reference:4
  Classifier Activation State:on
  IP Packet Classification Encodings
    IP Protocol:17
    IP Source Address:88.134.209.0
    IP Source Mask:255.255.255.0
    TCP/UDP Source Port Start:5060
    TCP/UDP Source Port End:5060
Downstream Packet Classification Encoding
  Classifier Reference:107
  Service Flow Reference:4
  Classifier Activation State:on
  IP Packet Classification Encodings
    IP Protocol:17
    IP Destination Address:10.0.0.0
    IP Destination Mask:255.0.0.0
    TCP/UDP Source Port Start:67
    TCP/UDP Source Port End:67
Downstream Packet Classification Encoding
  Classifier Reference:114
  Service Flow Reference:4
  Classifier Activation State:on
  IP Packet Classification Encodings
    TCP/UDP Source Port Start:53
    TCP/UDP Source Port End:53
  IPv6 Packet Classification Encodings
    IPv6 Next Header Type:17
    IPv6 Source Address:2a02:8100:0:0:0:0:0:0
    IPv6 Source Prefix Length:32
    IPv6 Destination Address:2a02:8101:1000:0:0:0:0:0
    IPv6 Destination Prefix Length:36
Downstream Packet Classification Encoding
  Classifier Reference:117
  Service Flow Reference:4
  Classifier Activation State:on
  IP Packet Classification Encodings
    TCP/UDP Source Port Start:547
    TCP/UDP Source Port End:547
  IPv6 Packet Classification Encodings
    IPv6 Next Header Type:17
    IPv6 Source Address:2a02:8100:0:0:0:0:0:0
    IPv6 Source Prefix Length:32
    IPv6 Destination Address:2a02:8101:1000:0:0:0:0:0
    IPv6 Destination Prefix Length:36

, denn da steht schon ziemlich deutlich "Max. CPEs: 2" (anderer Text, gleicher Gedanke).

Nun bin ich mit mir selbst uneins, ob ich tatsächlich mal das Firmware-Update mache (ist halt Aufwand, die Zugänge dort einzubauen und bei der Box am BK-Anschluß habe ich auch keine seriellen Schnittstellen bestückt - abgesehen davon wäre der Weg dafür dann doch wieder zu weit und meine 2m USB-Kabel reichen dafür nicht mal im Ansatz), weil es vielleicht doch an Inkompatibilitäten der alten Version mit der neueren Konfiguration bei VF/KD liegt.

Aber auch der Aufwand, der erst mal wieder mit der Untersuchung verbunden wäre, was VF/KD denn nun von den PACM-Möglichkeiten in den Folgeversionen tatsächlich nutzt bzw. ob AVM da auch wirklich alle "Sperren" bei kundeneigenen Boxen sauber umgesetzt hat (solange es den Teil nicht gab, konnte man da auch nichts seitens des KNB einstellen), ist eigentlich etwas, was ich im Moment so gar nicht gebrauchen kann (deshalb bin ich meinerseits mehr als dankbar, daß von 07.00 für die 6490 noch nichts zu sehen ist und meinetwegen darf das auch bis Weihnachten so bleiben).

-------------------------------------------------------------------------------------------------------

Speedtests und QoS:

Daß eine Bevorzugung von Speedtests sich nicht gleich bis ins CM fortsetzen muß, auch wenn VF natürlich Klassifizierungen bereits auf dem CM konfiguriert:

Code:

Classifiers:
-----------------------
Clfy  0: EtherType MAC proto f16 ==> SF 7eac008
Clfy  1: IPv4 DST 88.134.209.0/255.255.255.0 UDP Ports 0:5060 ==> SF 7eac008
Clfy  2: IPv4 DST 88.134.209.0/255.255.255.0 UDP TosLow 0x50 TosHigh 0x50 Mask 0xff ==> SF 7eac008
Clfy  3: EtherType MAC proto 252b ==> SF 7eac008
Clfy  4: IPv4 SRC 10.0.0.0/255.0.0.0 UDP Ports 0:67 ==> SF 7eac008
Clfy  5: IPv6 SRC 2a02:8101:1000::/36 DST 2a02:8100::/32 UDP Ports 0:53 ==> SF 7eac008
Clfy  6: IPv6 SRC 2a02:8101:1000::/36 DST 2a02:8100::/32 UDP Ports 0:547 ==> SF 7eac008
Clfy  7: IPv4 DST 10.0.0.0/255.0.0.0 UDP Ports 0:161 ==> SF 7eae007
Clfy  8: IPv4 SRC 88.134.209.0/255.255.255.0 UDP Ports 5060:0 ==> SF 7eae007
Clfy  9: IPv4 DST 10.0.0.0/255.0.0.0 UDP Ports 67:0 ==> SF 7eae007
Clfy 10: IPv6 SRC 2a02:8100::/32 DST 2a02:8101:1000::/36 UDP Ports 53:0 ==> SF 7eae007
Clfy 11: IPv6 SRC 2a02:8100::/32 DST 2a02:8101:1000::/36 UDP Ports 547:0 ==> SF 7eae007

, ist schon klar ... schließlich würde es da auch deutlich zu schnell auffallen.

Aber ich habe inzwischen die Testbeschreibung gelesen ... die Durchsatzmessung ist eben tatsächlich nur eine solche und sie erfolgt über 4 parallele HTTP-Verbindungen, für die ein Server (bzw. mehrere hinter einem Load-Balancer) Daten in ausreichender Geschwindigkeit bereitstellen kann. Dann beginnt die Messung aber auch erst "verspätet", um TCP-Einflüsse wie "slow start" (also kleines Window, was mit jedem erfolgreichen Paket verdoppelt wird bis zur max. Größe) nicht zum "Verfälschen" der Ergebnisse beitragen zu lassen. Da ist also nichts irgendwie verschlüsselt und die Adressen der Server sind mit einiger Sicherheit auch bekannt - und die Tests laufen über den normalen HTTP-Port.

Das würde sogar dazu führen, daß einer Leitung, bei der der Provider den Durchsatz einer einzelnen HTTP-Verbindung auf 1/4 der vertraglich vereinbarten Datenrate limitiert (warum und wo er das auch immer tun sollte - man kennt das aber z.B. von P2P-Netzwerken und entsprechenden Filtern bei Providern), weiterhin 100% bescheinigt würden ... irgendwie auch nicht wirklich das, was man als Kunde jetzt erwarten würde, der seinen Download eines Spiele-Updates auf der Game-Console anstößt oder sich ein neues Linux-Image lädt oder etwas in der Richtung und dabei keinen Download-Manager einsetzt, der das über mehrere TCP-Verbindungen bewerkstelligt und die Teil-Downloads dann wieder zusammensetzt.

Eine Regel, die damit aus diesem Traffic während eines Messvorgangs "Echtzeit" macht, ist - bei bekannter Adresse und bekanntem Port - nun wirklich kein Hexenwerk und diese Messung bildet (meines Erachtens) auch kein wirklich realistisches Szenario ab, was abseits eines größeren Downloads liegt. Wo hat man denn bitte einen Datenstrom per HTTP zu erwarten, der eine Größenordnung erreicht, mit der man 100 MBit/s über 10 Sekunden messen kann? Selbst YT verwendet i.d.R. RTSP.

Und dann kommt ja noch das "Überlesen" des Verbindungsaufbaus und des Starts der Verbindung hinzu bei diesem Test ... ein realistisches Browser-Szenarion heutzutage heißt aber, daß

DNS-Abfragen erfolgen (i.d.R. UDP - aber auch das muß halt einigermaßen verläßlich zugestellt werden, sonst braucht schon die Namensauflösung ewig)
HTTPS-Verbindungen aufgebaut werden, ggf. noch mit weiteren OCSP-Abfragen im Hintergrund (alles TCP, wo fehlende Pakete auch wiederholt werden müssen, was dann wiederum zum "Herunterregeln" des Durchsatzes führt, um genau solche Verluste zu vermeiden bzw. unmittelbar beim Auftreten zu bemerken - kleines Window, bis hin zum ACK für jedes einzelne Paket, wenn's schlecht läuft)
kleinere Dateien (JS-Code, Bilder, Texte) über diese Verbindungen transportiert werden und
mit ein wenig Glück diese HTTP-Verbindungen bei weiteren Requests erneut verwendet werden können (ab HTTP/1.1), sofern Server und Client das wollen und unterstützen (irgendwann macht auch ein Server mal so eine Verbindung zu, weil er ja noch andere potentielle Clients bedienen muß und eine offene Verbindung auch dessen Ressourcen blockiert)

Dabei sind viele Verbindungen (u.a. die zu den Analyse-Diensten) dann extrem kurz und transportieren gerade mal einen einzelnen Request - aber es sind eben viele und auch die müssen eben - schon aus Privacy-Gründen - mit TLS betrieben werden, was einen gewaltigen Overhead rund um den Transport eines einzelnen Cookies o.ä. erzeugt.

Schon wer sich einfach nur mal die Newsticker-Seite von heise.de lädt, der wird (z.B. mit uBlock als Zählhilfe) 11 verschiedene Domains finden, zu denen dabei Kontakt aufgenommen werden soll ... das sind auch (mind.) 11 HTTP(S)-Verbindungen, weil das natürlich auch unterschiedliche Server sind. Beim Aufruf der "heise.de"-Homepage sind das 13 Domains und insgesamt 78 Requests, bis die 1,83 MB der Homepage (das sind keine 16 MBit) geladen wurden.

Keine dieser Verbindungen kommt zeitlich auch nur in die Nähe der drei Sekunden Wartezeit (bei laufender Datenübertragung wohlgemerkt, sonst würde es den "slow start" ja nicht ausblenden), die bei der Durchsatzmessung als Zeitpunkt des Beginns der Messung verwendet wird: https://breitbandmessung.de/downloads/Technische Spezifikation - breitbandmessung.pdf - Seite 22.

Trotzdem treten gerade hier dann die Verzögerungen in den "Stoßzeiten" auf ... man sieht es ggf. sogar im Browser, wenn der sekunden- bis minutenlang beim "Performing TLS handshake with ..." hängt - das Problem ist hier gar nicht der gesamte Durchsatz, sondern die Zuverlässigkeit der Übertragung der Pakete und die habe ich ebenfalls gegen meinen Server schon getestet (aber noch nicht zu einem Zeitpunkt, wo es "klemmt"). Allerdings gehen wohl tatsächlich mehr Pakete im US verloren als im DS ... habe ich aber auch nicht wirklich anders erwartet (schon wg. der angenommenen Anbindung des CMTS, siehe weiter oben).

-------------------------------------------------------------------------------------------------------

Wenn das Problem tatsächlich nur auf der RF-Strecke zwischen CMTS und CM bestehen sollte und sich überwiegend auf den US erstreckt (erst seitdem es so richtig schlimm ist, nervt mich das Thema wirklich - vorher habe ich einfach nur die Prioritäten mehr in Richtung DSL verschoben, wenn "das Wetter" im Kabel mal schlechter war, aber inzwischen ist das ein täglich zu beobachtendes Phänomen), dann hilft vielleicht sogar die Umrüstung auf DOCSIS 3.1 (wenn VF/KD die dann auch freigibt und die Technik beim Kunden paßt) ... denn dabei gibt es ja dann neue Modulations- und Multiplexverfahren für den Rückkanal und auch wieder mehr (potentielle) Bandbreite. Aber das werde ich dann (zumindest im Rahmen dieses Vertrages) nicht mehr erleben ... denn ich kann nicht erst auf "den Weihnachtsmann" warten (zeitlich würde das vielleicht hinkommen) und auf ein (ungewisses) Versprechen, daß irgendwann alles wieder besser wird, vertrauen.

Flole · 6 Sep 2018

Gegenagumente in Form von Gegenbeispielen habe ich gleich 2 Stück: Es könnte ein LTE Sendemast sein, denn O2 strahlt auf genau den Kanälen die DOCSIS bei Vodafone nutzt. Das würde sich in dem MSE wiederspiegeln (Signal-Rausch Verhältnis), der Teil der Modemwerte ist. Wenn niemand eingebucht ist reduziert das Teil seine Sendeleistung, wenn jemand sich einbucht legt der so richtig los.
Vermutung Nummer 2 (nach der es mit dem QAM8 ganz aussieht) ist ein Rückwegstörer: Die CMTS muss dann von QAM64 runterschalten (passiert völlig automatisch, da bei QAM64 keine Verbindung mehr da wäre) und somit sinkt die Kapazität von den 108 Mbit/s gewaltig ab. Danach sieht es leider aus.

Die Casa C100G hat ein Backplane von über 1 Terrabit pro Sekunde, es gibt tatsächlich nur diese 5 CMTS bzw. diese 5 Stellen wo diese stehen. Die Line Cards (im Prinzip ein Kabelmodem nur "falsch herum") haben alle eine eigene CPU und FPGAs, somit kannst du da fast beliebig hoch skalieren indem du einfach immer mehr Line Cards reinsetzt (die im Prinzip in sich abgeschlossene Systeme sind). Für Postleitzahl 12679 steht die Zuständige CMTS in der Vulkanstraße, also nen paar Kilometer von dir. Das sind natürlich Strecken die bei ner Segmentierung eventuell geöffnet werden müssen. Wenn man mal ne Verfügbarkeitsabfrage von den 500Mbit/s bei dir macht und irgendwo in der Vulkanstraße dann wird da vermutlich das selbe passieren wie bei mir: Hier maximal 200, direkt neben der CMTS 500.
Achja: Die CMTS haben alle eine Bezeichnung nach dem Schema (das hier ist jetzt die für mich zuständige) hb-neue-cmts-22, also HB ist Bremen, Neue ist die Neuenstraße wo das gute Stück steht, CMTS ist das es eine CMTS ist und 22 ist die Nummer des Racks indem sich das Gerät befindet. Die kann man übrigens auch der FritzBox entlocken, ich weiß nur nicht mehr wie genau ich das gemacht hab

Die 6.87 geht bei mir auch immer mal wieder von 19 Kanälen aus, ich hab mich einfach damit abgefunden, wobei heute mein Austauschgerät angekommen ist, eine 6590 die jetzt endlich mein DVB-C Problem nach über einem Jahr lösen soll. Das mit den MaxCPEs war auch mal ein Problem, wurde dann irgendwann gefixt das es nicht beachtet wurde. Ist aber im Router Betrieb sowieso egal.

Die IPs die da drin stehen sind die SIP Server und das zweite ist die SIP Queue (mit erhöhter Priorität) und unbeschränkter Bandbreite.

Das sollte auch erklären warum die nicht für den Speedtest verwendet werden kann (wobei QoS Einstellungen auch wieder dynamisch von der CMTS eingerichtet werden können).

Docsis 3.1 wird im Upstream noch nicht so wirklich kommen, ich glaube ein Kanal ist da als Test aufgeschaltet. Wenn man 3.1 nutzen will müssen alle 3.0 Geräte von dem Kanal runter, bei vielleicht 2% kompatibler Geräte wäre das wahnsinnig die Kapazität so zu verschenken. Im Downstream sieht das jedoch etwas anders aus.

Die Zuverlässigkeit kann natürlich darunter leiden, wenn das Segment überlastet ist: Das Paket geht zur FritzBox, landet hinten in der Queue, es gibt nicht genug Zeitschlitze zum senden und somit werden die irgendwann einfach verworfen. Das wäre jetzt zumindest meine Vermutung.

Ich bin grad am Überlegen wie du die CMTS mit einem provisionierten Gerät anpingen kannst, da ist mir noch nicht so wirklich was eingefallen. Von nem unprovisionierten Gerät geht es (wenn man ne Shell hat). Dann weißt du ganz sicher obs nun Modem-CMTS oder CMTS-Rest ist.

P.S: Ich hab mir mal deine Idee der "Geheimsprache" geklaut

PeterPawn · 6 Sep 2018

Flole schrieb:
P.S: Ich hab mir mal deine Idee der "Geheimsprache" geklaut

Finde ich auch ohne solche Hinweise ... bei mir gibt's fast immer selbst definierte Styles, weil ich zu hellen Hintergrund hasse (deshalb war auch das "grau in hellblau" vom vergangenen Jahr für mich absolut unlesbar, aber das ist einigermaßen vorbei).

---------------------------------------------------------------------------------------------------------------

Daß die derzeit verwendeten Klassifizierungen nichts mit einem Speedtest zu tun haben, war schon klar ... ich hoffe mal, daß ich das nicht wirklich mißverständlich beschrieben habe und der Inhalt der Config-Datei von VF/KD war ja meinerseits auch schon zuvor "veröffentlicht" in irgendeinem Thread hier, als ich das erste Mal den Excentis-Editor angesprochen hatte zur "Entschlüsselung".

Ansonsten haben wir nur aneinander vorbei geschrieben ... ich sehe natürlich bei der Diskussion eine CMTS als etwas an, was selbst direkt mit den CM kommuniziert und auch selbst die RF-Seite in diese Richtung bereitstellt - also eher das, was ggf. bei der Casa nur noch als Linecard dazugesteckt wird; im Prinzip das, was selbst die RF-Kommunikation in einem Kabelsegment abwickelt.

Das entspricht auch der "Funktionsbeschreibung" aus den DOCSIS-Spezifikationen und wenn es Integrationslösungen gibt, die mehrere dieser Segmente "zusammenfassen", dann ist das zwar nett, hat aber mit der Spezifikation eines CMTS (z.B. in CM-SP-PHYv3.0-C01-171207, Abbildung 1-1 auf Seite 12 - der Link wäre dieser: https://community.cablelabs.com/wik...nload?id=52c04a05-d1c2-4384-a642-a7891aaabf7f, aber ich kopiere einfach mal die Abbildung aus der PDF-Datei):

in der Form, wie ich es meine, nur noch begrenzt zu tun.

Klar, die Integration geht auch dort weiter ... aber bei den PHY-Specs ist nicht von "Linecards" die Rede, sondern vom CMTS und wenn es Geräte gibt, wo die gemeinsamen Funktionen für mehrere dieser Linecards zusammengefaßt werden (und damit redundante Technik entfällt), dann ist das für mich nicht mehr das Gegenstück zum "Cable Modem" (CM), denn der Namen "Cable Modem Termination System" (CMTS) kommt ja daher, daß die (DOCSIS-)Verbindung vom CM in Richtung "Wide-Area Networks" dort endet (bzw. "abgeschlossen" wird) und ab da geht es mit anderen "Technologien" weiter.

---------------------------------------------------------------------------------------------------------------

Wenn es tatsächlich ein Störer ist (egal ob im Segment sitzend oder durch Einstrahlung von außen), dann ist auch der KNB für dessen Lokalisierung verantwortlich und für passende Gegenmaßnahmen ... selbst wenn das dann kein "Überbuchen" wäre, wobei auch das ja als Theorie voraussetzen würde, daß sich in die als Beispiel gewählte o2-LTE-Zelle tatsächlich mal niemand einbucht, damit die überhaupt jemals (für längere Zeit) in einen Modus mit verringerter Sendeleistung geht.

Das mag auf irgendeinem Dorf realistisch sein, vielleicht sogar in irgendeiner Kleinstadt, wenn alle am Stadtrand beim Feuerwerk sind und in der Ortsmitte nur noch die alten Leute ohne Mobilfunk-Geräte verbleiben. In meiner Umgebung besteht da praktisch keine Chance ... meine Ansicht, die ich naturgemäß nicht belegen kann. Auch in Bremen sollte das ja nicht so viel anders sein ... außer ihr habt dort tatsächlich Zellen in "pico"-Größe.

Aber in Anbetracht der sehr übersichtlichen Landschaft bei den Mobilfunk-Anbietern und der "Dichte" der Funkzellen in der Umgebung, ist garantiert immer mind. ein Kunde bei jedem Provider "präsent" (und sei er nur "auf der Durchfahrt" durch die Zelle, denn eine Bundesstraße liegt auch noch vor der Haustür) - mal ganz abgesehen von allen anderen Lösungen bis hin zur M2M-Kommunikation, die "immobil" sind.

Ein Störer im BK-Netz wäre sicherlich denkbar ... seit dem 11.08. (da habe ich das erste Mal so den "channel" (um im DOCSIS-Jargon zu bleiben) vollgehabt, daß ich das Ticket eröffnen ließ) ist der nicht lokalisiert, obwohl ich garantiert nicht der einzige Kunde im Segment bin, der sich darüber empört? Auch wenig wahrscheinlich in meinen Augen.

Aber gerade dann, wenn eine solche Linecard selbständig ein Fallback auf eine robustere Modulation machen sollte, sind eben alle Kunden in dem betroffenen Strang eingeschlossen - die Charakteristik eines US-Kanals gibt das CMTS (ich bleibe bei diesem Begriff, übersetze den meinetwegen für Dich mit "Linecard") über den UCD vor und die (Charakteristik im US-Channel) ist nun mal für alle CM dieselbe.

Ich weiß zwar nicht genau, ob die Modulation auch dynamisch heruntergesetzt werden kann (im DS werden ja regelmäßig die UCD gesendet) oder ob es dazu ein neues "Training" braucht - aber in Anbetracht der Masse an betroffenen Kunden (da hattest Du ja recht mit Deiner Aussage, daß davon sehr viele Kunden betroffen wären - wobei hier "sind" wohl richtiger wäre) sollte ein simpler Störer bereits von einem Meßtrupp aufgespürt worden sein. Auch wenn kurze Unterbrechungen (wie die oben gezeigte) ja tatsächlich darauf hindeuten könnten, daß da jemand die Verzweiger daraufhin abklopft - aber das sollte ja nun nach mehr als drei Wochen auch mal von Erfolg gekrönt sein, selbst wenn sich der Trupp immer weiter in Richtung CM hangeln muß.

---------------------------------------------------------------------------------------------------------------

Ansonsten habe ich tatsächlich mal spaßeshalber eine Verfügbarkeitsabfrage gemacht ... ~~ich könnte direkt auf 400/25 wechseln (kostet am Ende 10 EUR/Monat mehr als die 100/6 jetzt) und für 3 EUR/Monat (den Cent unterschlage ich jetzt mal) auch die 50 MBit/s im Upstream ordern.~~ EDIT: Stimmt nicht, siehe unten.

Der "Red Internet & Phone 500 Cable" war jetzt nicht im Angebot, wenn ich es richtig gesehen habe - kann aber auch durch "NoScript" und JS-Freischaltungsvoodoo untergegangen sein.

EDIT:
Wobei auch das wieder komisch ist ... mache ich bei VF/KD die Abfrage der Verfügbarkeit (identische Adresse) als Neukunde, kriege ich das hier und muß schon sehr, sehr genau hinsehen um zu erkennen, daß die 400er-Option gar nicht wirklich besteht:

und versuche ich einen Tarifwechsel als Bestandskunde, wird mir nur noch das hier angeboten:

... da wird doch nicht jemand Neukunden "ködern" wollen?

Insofern stimmt das also, was Du vermutet hast ... mehr als "Red Internet & Phone 200 Cable" bietet VF/KD hier gar nicht an.

chilango79 · 6 Sep 2018

Ich habe hier (Lateinamerika) genau so etwas erlebt. Verkauft wurden hier 75000 mbit. Die konnte ich auch beim Speedtestnet verifizieren. Downloads kamen nicht über 13000 hinaus. Der Zak-Speedtest von AVM bestätige auch diesen Download.
Die Provider passen auf auf welchen Seiten man sich befindet. Sobald die Seite Speedtest aufgerufen wird schrillen dort die Alarmglocken und meine Nachbarn müssen Leiden damit ich jetzt den vollen Speed testen kann.
Also immer kleine Speedtester verwenden. Breitband.de würde ich auch nicht vertrauen.
Natürlich muss man dann auch die Ergebnisse entsprechend interpretieren. Wenn ich von Lateinamerika aus den AVM Speedtest nutze kann ich den Ping natürlich vergessen

Flole · 6 Sep 2018

Ja dann haben wir tatsächlich etwas aneinander vorbeigeredet. Ich bin etwas Casa geschädigt, wenn man 2000 Seiten Manual gelesen hat und das verstehen will gewöhnt man sich ganz schnell an von Line cards etc. zu reden

Witzigerweise ist das Management der Line Cards wieder zentral, also der ganze Kasten hat nur eine serielle Schnittstelle um alle Karten zu konfigurieren, und ne Zentrale CPU hat der auch noch. Also ohne den Rest würde so eine Line Card nun auch wieder nicht laufen, und andere Hersteller geben ja aus ihrem Gerät (was auch immer es sein mag) auch mehrere Anschlüsse raus wo ein Signal wie es eine CMTS erzeugt draufliegt. Wie man die dann demultiplext oder ob man das Gerät zu 12 CMTSs mit je einem Kanal verarbeitet ist jedem Betreiber selbst überlassen. Ich kann meine auch benutzen um 2 Segmente zu betreiben (mit je 2 Kanälen). Mehr hab ich noch nicht ausprobiert. Also das Konzept ist nicht Irgendwie neu, das gibts schon ewig nur Casa hat das da einfach mal modular gestaltet (so wie die großen Cisco switches die mit den Karten laufen)

Der 500 ist nur unter den Business Tarifen sichtbar.

Und so einen Störer zu finden ist extrem aufwendig, da werden einzelne Straßen abgeklemmt und geschaut ob der weg ist. Wenn man Pech hat ist ne Muffe voll mit Wasser oder ähnliches, und dann muss der Tiefbautrupp anrücken und baggern. Wenn man dann nicht weiß welche, geht das eine Muffe nach der anderen durch.

Ich weiß nur noch das irgendwo jemand das Problem hatte mit einem O2 Mast und das der witzigerweise nicht dauerhaft gesendet (oder zumindest gestört) hat.

Wenn der Rückwegstörer jetzt auch noch einer von den Leuten ist die ihr Modem tagsüber wenn sie auf der Arbeit sind ausmachen, und am besten nachts zum schlafen auch, dann viel Spaß dem Techniker der die Störung suchen soll. Wenn (oder sollte ich eher sagen falls?) es mal wieder eine Zeit lang gut läuft, kannst du ja mal schauen ob wieder auf QAM64 hochgeschaltet wurde.

PeterPawn · 6 Sep 2018

Wenn das einer von den "Selten-Nutzern" ist, sollte man dem aber auch ziemlich leicht auf die Spur kommen, denn dann meldet der sich ja "um den Zeitpunkt der Störung herum" auch beim CMTS an und so viele sind das beim Internet per Kabel eher nicht, die ihre Geräte komplett abstellen, weil hier ja schon länger das Telefon nur dann funktioniert (All-IP-Anschlüsse waren das praktisch schon immer, seit es VoC gab), wenn das Modem auch an ist und es hier niemals eine "Notspeisung" aus der Leitung gab. Auch die Befürchtungen mit dem Blitzschlag findet man eher selten im BK-Netz - den Fernseher stöpseln sicherlich nur sehr wenige ab, wenn ein Gewitter aufzieht.

Ich weiß, daß eine Suche aufwändig ist ... und die kurzen Unterbrechungen sehen ja tatsächlich danach aus, als würde jemand suchen wollen. Afaik erfolgt das heute auch nicht mehr (in erster Linie) durch komplettes Abklemmen eines Strangs über längere Zeit, sondern da wird Meßtechnik eingeschleift, die dann auch die Störung anzeigt und nicht nur nach dem Motto: "Wenn der nicht dran hängt, ist die Störung auch weg." und dem Ausschlußprinzip gearbeitet.

Das "Volllaufen" einer Muffe scheidet bei diesem Sommer auch aus (leider) - ich überlege gerade, ob es hier bei uns Anfang August überhaupt irgendwelche Niederschläge außerhalb von Box-Schulen gab ... von einem größeren Rohrbruch hätte man auch etwas gelesen. Kann zwar alles sein ... aber eine Verbindungsmuffe, die hier nicht gleichzeitig mit einem Revisionsschacht versehen ist und wirklich erst "ausgebuddelt" werden muß, halte ich auch für unwahrscheinlich - nicht unmöglich, aber unwahrscheinlich.

Der Tarif war nur "schlecht geguckt" von mir (bzw. wohl eher "reingefallen", denn warum wird der dann überhaupt angezeigt) ... mehr als 200 sind tatsächlich nicht drin zur Zeit.

-----------------------------------------------------------------------------------------------------------------------------------

Ich kram's noch mal vor, weil's so schön "spannend" ist, nach denkbaren Erklärungen zu suchen.

Da wollte ich also um 19:31 Uhr den nächsten Test innerhalb der oben erwähnten Kampagne starten (weil mein Icinga mir mitteilte, daß die Erreichbarkeit meiner 6490 von außen mal wieder "critical" sei) ... Ergebnis: Bitte prüfen Sie Ihre Internetverbindung, weil die Version nicht gecheckt werden kann. Drei Versuche, dreimal dasselbe Ergebnis - auch im Browser schön zu sehen bei "heise.de": Performing TLS handshake ... blabla.

Also in die Console der 6490:

Code:

# traceroute www.heise.de
traceroute to www.heise.de (193.99.144.85), 30 hops max, 38 byte packets
 1  ip5b40ecfe.dynamic.kabel-deutschland.de (91.64.236.254)  195.796 ms  243.273 ms  220.879 ms
 2  ip5886b92e.dynamic.kabel-deutschland.de (88.134.185.46)  236.826 ms  202.878 ms  209.584 ms
 3  ip5886c00b.static.kabel-deutschland.de (88.134.192.11)  144.628 ms  199.248 ms  208.065 ms
 4  ip5886edb0.static.kabel-deutschland.de (88.134.237.176)  364.921 ms  219.551 ms  198.872 ms
 5  ip5886edf0.static.kabel-deutschland.de (88.134.237.240)  279.006 ms  454.939 ms  272.846 ms
 6  ip5886eda3.static.kabel-deutschland.de (88.134.237.163)  190.079 ms  212.059 ms  338.252 ms
 7  te0-0-2-3.c150.f.de.plusline.net (80.81.192.132)  412.094 ms  398.317 ms  315.751 ms
 8^C
# ping 88.134.185.46
PING 88.134.185.46 (88.134.185.46): 56 data bytes
64 bytes from 88.134.185.46: seq=0 ttl=254 time=271.274 ms
64 bytes from 88.134.185.46: seq=1 ttl=254 time=182.945 ms
64 bytes from 88.134.185.46: seq=2 ttl=254 time=195.206 ms
64 bytes from 88.134.185.46: seq=3 ttl=254 time=163.621 ms
64 bytes from 88.134.185.46: seq=4 ttl=254 time=190.646 ms
64 bytes from 88.134.185.46: seq=5 ttl=254 time=132.551 ms
64 bytes from 88.134.185.46: seq=6 ttl=254 time=156.744 ms
64 bytes from 88.134.185.46: seq=7 ttl=254 time=122.893 ms
64 bytes from 88.134.185.46: seq=8 ttl=254 time=252.222 ms
64 bytes from 88.134.185.46: seq=9 ttl=254 time=186.425 ms
64 bytes from 88.134.185.46: seq=10 ttl=254 time=336.659 ms
64 bytes from 88.134.185.46: seq=11 ttl=254 time=201.083 ms
64 bytes from 88.134.185.46: seq=12 ttl=254 time=253.634 ms
64 bytes from 88.134.185.46: seq=13 ttl=254 time=231.870 ms
64 bytes from 88.134.185.46: seq=14 ttl=254 time=101.647 ms
64 bytes from 88.134.185.46: seq=15 ttl=254 time=168.858 ms
64 bytes from 88.134.185.46: seq=16 ttl=254 time=141.414 ms
64 bytes from 88.134.185.46: seq=17 ttl=254 time=186.994 ms
64 bytes from 88.134.185.46: seq=18 ttl=254 time=174.234 ms
64 bytes from 88.134.185.46: seq=19 ttl=254 time=131.951 ms
64 bytes from 88.134.185.46: seq=20 ttl=254 time=137.542 ms

Keine wirklichen Verluste, aber Latenzen (zum ersten Hop im VF/KD-Netz wieder, die .254 ist das Gateway für die zugewieses IPv4 mit 24er-Maske), die zum Himmel stinken - das ist ja keine Mobilfunk-Verbindung.

Dann die Web-Version des Tests von bandbreitenmessung.de angeworfen:

Die hatte ich zuvor schon mal gemacht, mit diesem Ergebnis:

Also schon eine sichtbare Verschlechterung ggü. der ersten Messung - das spricht ja irgendwie gegen eine Priorisierung vom Traffic des Messprogramms.

Aber wie heißt es so schön: Einmal ist keinmal. - also noch einen Test hinterher (auch die Webversion):

Und siehe da, auch die Desktop-App funktioniert plötzlich wieder und die Latenzen beim "ping" in der Shell sind auch wieder < 100 ms. Es war vermutlich nur ein "kurzer Schluckauf" und so etwas kann ja mal passieren. Blöd ist nur, wenn der gar nicht mehr aufhören will und sich so lange zieht, daß man es im Browser mehr als deutlich bemerkt - denn das bisher Erlebte war eben nicht nur "eine Episode".

Nun bin ich ja mal gespannt, wie lange der letzte Speedtest vorhält und ab wann es wieder in den Keller geht. Im Moment habe ich jedenfalls nicht die Probleme, die sich seit mind. einer Woche um diese Zeit immer einstellen wollten und die dann auch hier im IPPF teilweise zu doppelten Beiträgen geführt haben, weil XHRs nicht richtig ausgeführt wurden und ich mehrfach irgendwelche Buttons drückte. Vielleicht sollte ich einfach alle 15 Minuten einen Speedtest machen lassen - mal sehen, ob das am Ende hilft.

EDIT: Ich habe die Screenshots mal wieder entfernt ... die enthielten die IPv4-Adresse und beim anschließenden Versuch, von VF/KD eine neue zu beziehen (von "Neu verbinden" bis inkl. Neustart der 6490, bei der Gelegenheit habe ich gleich mal auf die 06.87, die in der anderen Partition lag, umgeschaltet), bin ich grandios gescheitert. Wenn die jetzt auch noch "pseudo-statisch" ist, sieht's mit dem Datenschutz noch finsterer aus.
Ich verpixele die jetzt mal, dann kommen sie wieder.
EDIT2: Ok, nun ohne IPv4-Adresse.

Flole · 6 Sep 2018

91.64.236.254 ist deine CMTS wenn deine IP 91.64.236.x ist (da hast du etwas zu viel verpixelt, bzw. da oben dann zu wenig

). Damit sollte dann auch abschließend geklärt sein, wo im Netz das Problem liegt, oder?

Ich hatte vor einigen Wochen mit einem Unitymedia Techniker gesprochen (der im Außendienst ist und das Netz wartet), und der hat mir gesagt das es da keine Messgeräte und das stumpfe abklemmen und ausprobieren immer noch praktiziert wird. Und dann gibts noch die "Neee, bei mir gibts kein Problem, sie kommen nicht in meine Wohnung, wenn meine Nachbarn ein Problem haben, was hat das mit mir zu tun?"-Leute......

Ist zwar Offtopic, aber irgendwie musste ich bei einem E-Bay Angebot grad an deine Worte denken (Ebay-Artikelnummer 183415958210). Da wurde einfach der Aufkleber von unten entfernt

So gehts natürlich auch....

PeterPawn · 7 Sep 2018

Flole schrieb:
Da wurde einfach der Aufkleber von unten entfernt

Wenn das die von ilsa*irgendwas aus Bremen ist ... die hatte ich auch gesehen und mich gewundert, wo da wohl der Aufkleber geblieben sein mag und wie der sich wohl (so sauber auch noch) gelöst hat. Aber die LEDs leuchten ja noch ...

- ich habe aber sogar kurz überlegt, ob ich für die bieten sollte. Ich suche ja explizit eine mit alten Zertifikaten, wo ich mich nicht wirklich ärgere, wenn ich die komplett schrotte. Soweit ich weiß, hat noch niemand hier mit einem JTAG-Adapter den Bootloader wieder eingespielt (es fehlen alle Infos dazu, wobei der Intel-Debugger ja auch irgendwie arbeiten muß) - ggf. könnte man das allerdings tatsächlich wieder "per Klammer" für den SPI-Flash versuchen. Aber alles nicht so meins ... über solche Kopfstände denke ich erst dann nach, wenn ich eine Box wirklich geschrottet habe.

Ansonsten ist es heute bei mir ein anderes Fehlerbild - Verluste praktisch kaum und auch die Icinga-Meldung gab's nur wegen Überschreitung des Latenz-Limits.

-------------------------------------------------------------------------------------------------------------------------------------------

Wobei das "nicht in die Wohnung kommen" ja dann mit dem Abklemmen im Verteiler fürs Haus (NE4, also da, wo auch Sperrfilter eingesetzt würden, usw.) recht leicht zu lösen ist, wenn man sich erst mal so weit vorgekämpft hat, daß man den ÜP von der NE3 identifiziert hat, über den so ein Störer eingespeist wird.

Es hängt sicherlich auch von der Art der Störung ab, wie man diese "umzingeln" will - ich weiß gerade nicht, wie DVB-C und die Daten am Ende wieder auf demselben Kabel landen, aber irgendwo müssen die Kanäle ja wieder zusammengeführt (mixed) werden.

Wenn dann ein kompletter Strang (eine C-Linie) abgeklemmt wird (ich gehe mal davon aus, daß so eine Fehlersuche am CMTS startet und nicht irgendwo auf NE4, mithin erst mal die betroffene A- oder B-Linie ermittelt wird), ist das schon ein erheblicher Eingriff, oder? Aber wie auch immer die Fehlersuche vom KNB laufen mag ... irgendwann muß die halt mal zu einem Ende kommen und eigentlich ist mir das sogar komplett Wumpe, was der KNB hier unternimmt - Hauptsache der Anschluß kommt wieder in die Gänge. Ich glaube ja ohnehin nicht, daß es tatsächlich ein Störer ist - die "zeitabhängige Komponente" der Störung läßt das (egal, welche Erklärung man dafür sucht) für mich unwahrscheinlich erscheinen. Außer man definiert die Kunden, die da für volle Auslastung sorgen, gleich mal als Störer ... dann braucht VF/KD ja nur in die Kundendatenbank zu schauen.

-------------------------------------------------------------------------------------------------------------------------------------------

Ansonsten habe ich oben tatsächlich vergessen, die erste Zeile vom "traceroute" wieder (wie in #1) zu maskieren ... irgendwas ist ja immer. Ich bin ja noch froh, daß ich die IP in den Screenshots noch entfernt habe. Das "Neu verbinden" in der FRITZ!Box hatte ich vor der Veröffentlichung schon angeschoben und erst hinterher kontrolliert. Da war ich einigermaßen verblüfft, als ich immer noch dieselbe IPv4-Adresse hatte, die auf den Screenshots zu sehen war.

Lustigerweise hat meine Rückwärtsrolle von der 06.87 zur 06.83 dann doch wieder eine andere IPv4-Adresse zur Folge gehabt (ich mußte die Box zwischendrin auch stromlos machen, um per FTP an den Bootloader zu kommen - ist mir bei der 6490 bisher auch nicht direkt aufgefallen, nur bei den GRX-Boxen und da muß ich wohl noch mal genauer testen) ... wenn das hier weg ist, schaue ich mal nach, was jetzt beim "Neu verbinden" passiert.

Flole · 7 Sep 2018

Die fritzbox verzählt sich übrigens so wenn ein dynamischer Kanalwechsel passiert, also wenn da nur 19 Kanäle stehen wurde sie mindestens einmal angewiesen den Kanal zu wechseln und hat das auch getan. Wäre das auch geklärt.

Ja die ilsa irgendwas, und trotz der geographischen nähe hab ich damit nichts zu tun, finds aber echt erstaunlich wie viel für sowas noch geboten wird..... Vielleicht sollte man einfach mal nachfragen was mit dem Aufkleber passiert ist

In nem Mehrfamilienhaus mag das vielleicht noch gehen (wenn einen da jemand ins Haus lässt), in nem Einfamilienhaus ist das schon schwieriger. Und genau richtig, die Fehlersuche geht bei der CMTS los und dann werden einzelne Stränge abgeklemmt usw.

Das mit der Zeitabhängigen Komponente hast du glaub ich noch nicht so ganz verstanden wie ich mir das erkläre: Das "runterschalten" von QAM64 auf QAM8 ist im Prinzip das sperren von ziemlich vielen Spuren der Datenautobahn. Wenn nun nur wenige Leute da fahren gibts keine Probleme, aber im Feierabendverkehr ist dann komplett Stau. Du musst bedenken das dir von den 108Mbit/s auf 4 Kanälen bei QAM64, plötzlich etwa 70Mbit/s mal eben so "wegbrechen" wenns auf QAM8 runter geht. Es bleiben also etwa 38Mbit/s Upstream, und das für alle....

PeterPawn · 7 Sep 2018

Flole schrieb:
Es bleiben also etwa 38Mbit/s Upstream, und das für alle....

Nicht mal mehr die, denn inzwischen sind wir bei 2 Kanälen mit QAM8 und zwei Kanälen mit QPSK angekommen im US:

Code:

DOCSIS DB Info:
----------------------------------------------------
CM Mac Status: Operational    Mode: DOCSIS 3.0
Docsis 1.0 CoS: no           Docsis 2.0 Mode: enabled
eRouter Mode: 3 (IPv4+IPv6)
eRouter Enabled: yes
Multiple Dowstreams: yes    Multiple Upstreams: yes
Last frequency: 578000000   Max CPE: 0
RegReq SID: 6486            override SID: 0
UCD on all Downstreams: yes
Channel Change Status: No active channel change
Transmit Channel Configuration: yes
Upstream Drop Classifiers: no
Multicast DSID Forwarding: GMAC promiscuous support
US 1: SID: 6486    UCID: 4    DCID: 0    usable: yes
US 2: SID: 6486    UCID: 2    DCID: 0    usable: yes
US 3: SID: 6486    UCID: 1    DCID: 0    usable: yes
US 4: SID: 6486    UCID: 3    DCID: 0    usable: yes
US 5: SID: 0    UCID: 0    DCID: 0    usable: no (reason 1 REJECT_OTHER)
US 6: SID: 0    UCID: 0    DCID: 0    usable: no (reason 1 REJECT_OTHER)
US 7: SID: 0    UCID: 0    DCID: 0    usable: no (reason 1 REJECT_OTHER)
US 8: SID: 0    UCID: 0    DCID: 0    usable: no (reason 1 REJECT_OTHER)
Reinit Mac Reason: Power on
Resets: 0     Invalid Reg-Rsp's: 0     T1-Timeouts: 0

DOCSIS Us Status:
----------------------------------------------------
PGA gain code is 60
PGA current is:      3
Current Full Scale:  59.080002
PloadMinSet:         2.500000
Initial PloadMinSet: 5.000000
Power Reporting:    Yes

Digital Att: 15.731144   13.467992   11.291902   15.349578   9.127320   9.127320   9.127320   9.127320
Frquency   : 36.200001   52.200001   58.599998   45.799999   10.000019   10.000019   10.000019   10.000019
Symbol rate:      5.12        5.12        5.12        5.12   Invalid    Invalid    Invalid    Invalid
modulation :     QPSK       QPSK       8QAM       8QAM        ERR        ERR        ERR        ERR
SCDMA mode :        0          0          0          0          0          0          0          0
rep power  :  45.0000    47.0000    49.0000    45.0300    -1.0000    -1.0000    -1.0000    -1.0000
Upstream    :       4          2          1          3        ---        ---        ---        ---

Phigh      :  56.1800    56.1800    52.2100    52.2100     0.0000     0.0000     0.0000     0.0000
PLow       :  24.1800    24.1800    24.1800    24.1800     0.0000     0.0000     0.0000     0.0000
PdrwHigh   :  53.6800    53.6800    49.7100    49.7100     0.0000     0.0000     0.0000     0.0000
PdrwLow    :  41.6800    41.6800    37.7100    37.7100     0.0000     0.0000     0.0000     0.0000
deltaPf    :   1.6520     1.3880     1.2120     1.3000     0.0000     0.0000     0.0000     0.0000

DOCSIS Ds Status:
----------------------------------------------------
Number of tuners   : 1
Tuner Id #         :    1     
Frequency(MHz)     : 0.000     
Tuner Type         : Full CBW  

Number of receivers: 24

Receiver #         :    1         2         3         4         5         6         7         8     
Frequency(MHz)     : 674.000   554.000   562.000   570.000   578.000   586.000   594.000   602.000   
QAM Lock           : YES       YES       YES       YES       YES       YES       YES       YES       
FEC Lock           : YES       YES       YES       YES       YES       YES       YES       YES       
MPEG Lock          : YES       YES       YES       YES       YES       YES       YES       YES       
CH Enabled         : YES       YES       YES       YES       YES       YES       YES       YES       
MSE                : -40.366   -38.983   -38.605   -38.605   -38.605   -38.605   -38.983   -40.366   

Receiver #         :    9        10        11        12        13        14        15        16     
Frequency(MHz)     : 0.000     0.000     0.000     0.000     666.000   546.000   682.000   690.000   
QAM Lock           : NO        NO        NO        NO        YES       YES       YES       YES       
FEC Lock           : NO        NO        NO        NO        YES       YES       YES       YES       
MPEG Lock          : NO        NO        NO        NO        YES       YES       YES       YES       
CH Enabled         : NO        NO        NO        NO        YES       YES       YES       YES       
MSE                : -inf      -inf      -inf      -inf      -40.366   -40.366   -40.366   -40.366   

Receiver #         :   17        18        19        20        21        22        23        24     
Frequency(MHz)     : 698.000   706.000   714.000   722.000   762.000   770.000   778.000   786.000   
QAM Lock           : YES       YES       YES       YES       YES       YES       YES       YES       
FEC Lock           : YES       YES       YES       YES       YES       YES       YES       YES       
MPEG Lock          : YES       YES       YES       YES       YES       YES       YES       YES       
CH Enabled         : YES       YES       YES       YES       YES       YES       YES       YES       
MSE                : -35.729   -36.558   -36.335   -36.558   -36.558   -36.558   -37.305   -36.558   

DCID               : 10        2         3         4         5         6         7         8         
                   : -NA-      -NA-      -NA-      -NA-      9         1         11        12       
                   : 13        14        15        16        17        18        19        20       
DCID               : 10        2         3         4         5         6         7         8         
                   : ---       ---       ---       ---       9         1         11        12       
                   : 13        14        15        16        17        18        19        20       
RC index           : 1 [Prm]   2         3         4         5         6         7         8         
                   : -NA-      -NA-      -NA-      -NA-      9         10        11        12       
                   : 13        14        15        16        17        18        19        20

und wenn man sich das ansieht, dann ist es in aufsteigender Frequenzfolge QPSK, QAM8, QPSK, QAM8 ... das ist dann auch kein breitbandiger Störer mehr, der über einen Kanal einfach nur hinausgeht. Das sind zwei "Gassen" ...

Wobei es mir am Ende eben vollkommen egal ist, ob das nun wirklich ein Störer ist oder ob da peu à peu das Ganze umkonfiguriert wird und erst mal alles (bis hin zu den ältesten DOCSIS1-Gurken, die nur QAM16 und QPSK können) auf denselben US-Kanälen zusammengedrängelt werden soll (neuere Geräte müssen ja Fallback beherrschen).

Wenn der KNB einen Störer tatsächlich nicht innerhalb von vier Wochen lokalisieren kann (wie schon mal beschrieben, ist mein altes Ticket vom 11.08.), dann finde ich das auch nicht wirklich normal, aber meinetwegen soll es dann auch ein solcher Störer sein - solange VF/KD für Abhilfe sorgt.

Ich versuche mich jetzt erst mal wieder zu beruhigen (im Moment ist ja nichts los im Segment) und schaue mir das noch die nächsten 14 Tage an ... dann ist der Termin, an dem ich über Kündigen oder Bleiben entscheiden muß.

Teile und herrsche ... das Breitband-Kabel von Vodafone als Internet-Verbindung

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Promi

IPPF-Urgestein

Mitglied

Aktives Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Aktives Mitglied

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Statistik des Forums