Och, ich bin mir durchaus bewusst das es bei der Methodik Probleme geben kann.
Dann ist es ja gut.
Ein Gateway muss nicht auf ICMP antworten, besonders wenn was zu tun ist.
Es sollte aber seinen Job erledigen und dies nicht nur auf well known Ports und nicht nur wenn es lustig ist für UDP.
Sehe ich genauso, doch wenn Hop x diesen Job deiner "Ermittlung" nach offenbar nicht tut, habe zumindest ich ein Verständnisproblem dabei, dass Hop x+1 dann davon nicht viel zu wissen scheint.
Entscheidend sind letztlich alleine etwaige Paketverluste am Ziel.
Das Interessante ist, das der von dir zitierte Konsolenbefehl das ganze auf UDP basierend aufzieht.
Du meinst wahrscheinlich "mir" im Sinne von "dir" aus meiner Sicht. Linux-basierte Systeme und auch Cisco verwenden wohl gerne UDP für Routenverfolgungen, während Windows eher auf ICMP steht.
UDP Pakete gehen hier immernoch massiv flöten und werden mit einer MTU die größer als 1024 ist verworfen, respektive fragmentiert… toll.
Das mit der maximalen Paketgröße von 996 Byte netto ist mir auch schon aufgefallen, wobei es hier in einem anderen Thread hieß, das träfe "nur" auf Statusmeldungen zu und nicht für übliche Nutzdaten.
TCP IP ist bei weitem robuster, macht hier auch weniger Probleme… aber UDP kann man knicken.
Auch hier ergibt sich zumindest für mich ein Verständnisproblem, denn auch, wenn einige Router und wohl insbesondere Loadbalancer da tiefgreifende IP-Analysen unterstützen und eventuell je nach Protokoll andere Priorisierungen und Routingentscheidungen treffen, sollte ein klassischer Router ja erstmal gar nicht wissen, ob da nun GRE, TCP, UDP oder sonstwas "drinsteckt". Hier bräuchte man seitens O2 genaue Informationen, welche Router da mit welcher Konfiguration zum Einsatz kommen.
O2 ists egal das ich hier nicht spielen und arbeiten kann, zu Stoßzeiten nichtmals Amazon Prime / Netflix laufen…, an dem Router kann es nicht liegen, immerhin ist der oben zitierte einer von drei getesteten.
Der Speedtest spuckt ja immer super Geschwndigkeiten aus.
Das ist insofern seltsam, als dass sowohl bei Amazon Prime als auch Netflix ziemlich sicher wie auch bei den ganzen Speedtests schnödes HTTP via TCP verwendet werden wird.
Auch stellt sich die Frage, ob bei all diesen Verbindungen dieser eine vermeintlich ausgemachte "böse Router" involviert ist.
Angerufen, hier um Hilfe gebeten, bringt alles nichts. Tickets werden geschlossen, Rückrufe finden nicht statt…, wenn man hier nicht hinterherrennt passiert nichts, mir egal nun.
Dass der Support seitens O2 spätestens bei technischen Spezialthemen nur noch grottig ist, steht außer Frage, wie etliche ins Leere laufende Threads hier klar beweisen.
Ich war bereit Hardware für Tests zur Verfügung zu stellen und gerne auch zu debuggen, tcpdumps und traces jedweder Art zu liefern, nada.
Dafür müsste man eben an die Leute rankommen, die wirklich Ahnung haben und nicht nur an die ##Beleidung entfernt - o2_Kurt##
Solln se mit ihrem Routing und virtuellem mapping von externen IP Adressen im CGNAT ohne mich Spaß haben.
Ja gut, dem CGNAT-Gedöns huldigen hierzulande ja inzwischen alle Mobilfunkanbieter. Als Privatkunde bietet da leider nur die Telekom eine Alternative über den nicht mehr beworbenen, jedoch immer noch Nutzbaren Zugangspunkt internet.t-d1.de.
Ich ärgere mich um das Geld das ich in dieses Projekt versenken muss bis die Kündigung Ende 2021 durch ist.
Bilanz: Ein Kunde weniger für Telefonica -dauerhaft-.
Das ist dann die Konsequenz. Ich hätte ja gerne mal ebenfalls ein wenig Traceroute zu deinem Ziel gemacht, doch das hast du ja in bester "security by obscurity" - Manier unkenntlich gemacht.
Pings via ICMP echo reply als auch TTL exceeded sind zur dann eben alternativ direkt angesprochenen IP-Adresse 62.52.49.38 sowohl von O2 als auch Vodafone aus jedenfalls soweit unauffällig (nix Paketloss).
Edit:
Beleidigung entfernt - wir haben unsere Netiquette nicht ohne Grund.
7 Tage Schreibsperre
o2_Kurt
Gegen die Theorie der 996 Bytes Begrenzung "nur für Statusmeldungen" spricht das UDP Verbindungen (beispielsweise per Wireguard) bei MTU Größen > 1024 massiven Loss zeigen oder gar nicht erst zu Stande kommen.
Und ja, ich habe die MTU von Wireguard auch passend inkl. Header konfiguriert, so dass die Gesamtgröße der verpackten Daten unter 996 +28 bleibt.
Genauer kann ich hier nichts zu sagen, da die Technik O2s mir ausser "die MTU ist viel größer" (siehe anderem Thread von mir) nie geantwortet hat.
Multiplayersessions waren bei Paketverlusten > 10% an dieswm Hop interessant zu beobachten und instabil wie sau.
Fühl dich frei zu testen: 46.114.27.240, diese IP liegt bis morgen früh um 5 an.
Die "offenen Ports" die du via Scan finden wirst, sind erst seit wenigen Wochen (meinem letzten Ticket) aufzufinden (auch für mein Handy), wurden von mir aber nicht konfiguriert, sind auch nicht offen hier...
Poste bitte deine Traceroutes, MTRs etc. dann schau ich auch nochmal was ich beisteuern kann, evtl. sieht man so mehr.
Was das seltsame Verhalten angeht: hier kann ich Amazon / Netflix schauen, sobald ich mit einem meiner Server per Tunnel verbinde und so das o2 Routing umgehe. Da es immer mal wieder nicht ging, hatte ich bald dauerhaft den Tunnel im Mediacenter konfiguriert.
Wenn allerdings die Tunnel instabil werden geht man auf Fehlersuche. Zeigte der im Betreff stehende Server hier Verlustwerte die im 20iger Bereich liegen, so wurden auch die Tunnel instabil. Teste ich sehr früh oder spät ist der PL im MTR nicht vorhanden und tritt auch nicht im Tunnel auf.
Alternativ sind die Probleme wesentlich weniger / waren eigtl. ganz verschwunden, sobald ich auf OpenVPN gewechselt bin, das verpackte dann schön in TCP anstelle von UDP.
Aber dauerhaft noch nen PC laufen lassen um den o2 Tarif brauchbar gestalten zu können, war mir dann auch zu blöd.
Hallo o2_Kurt,
ob scheiternder Login-Möglichkeit und mangels jedweder direkter Benachrichtigung vorab durch dich oder einen Kollegen zunächst von einem Systemfehler ausgehend, habe ich später dann deinen lakonischen Zweizeiler bezüglich einer "Schreibsperre" entdeckt - mit doch einiger Verwunderung.
Hierzu zunächst einmal ein etwas älteres Zitat eines Bekannten, der mir einmal zu entgegnen wusste:
"don't think, you're doing me a favor!"
Dies gebe ich an dieser Stelle gerne mal weiter, denn es hat mir den ganz starken Anschein, dass hier die Vorzeichen nicht so ganz klar sind - nicht mir wird die unermessliche Ehre zuteil, in diesem Forum gnädigerweise nominell etwas beitragen zu dürfen, sondern umgekehrt dürft ihr euch glücklich schätzen, den ein oder anderen Teilnehmer zu haben, der versucht, anderen zu helfen, Ideen beizusteuern und der am Ende gar Teile eures (im Sinne von o2s) Jobs erledigt. Mein Mitteilungsbedürfnis vermag ich alternativ nämlich auch sehr gerne zu zügeln - dann bist du herzlich eingeladen, deine Routenverfolgungen, Messungen und sonstige Testszenarien mit "ausdemdorf" auszutauschen - in einer dir gänzlich liebsamen Wortwahl ganz nach deinem Gusto.
Um der ungerechtfertigten Zensur zu trotzen und dem möglicherweise bei anderen Nutzern hier fälschlicherweise entstehenden Eindruck, es habe sich tatsächlich meinerseits um beleidigende Äußerungen gehandelt, prophylaktisch entgegenzuwirken - ich schrieb von "Weiterschubbsern und Durchlauferhitzern".
Meiner Beobachtung nach seid ihr hier für eine gewisse Kundenbetreuung analog zu einem "first level support" abgestellt, beantwortet einfache Fragen und gebt Ratschläge, was für sich ja wunderbar und ehrenwert ist. Bei weitergehenden technischen Problemen jedoch erschöpft sich eure Tätigkeit allem Anschein nach allenfalls darin, hausintern Tickets zu eröffnen, dort auf Antwort zu warten und diese dann - sofern vorhanden - ohne weitere Prüfung hier wiederzugeben, auf dass der Prozess gegebenenfalls von Neuem beginne.
Nicht selten verlaufen Kundenanfragen dabei im Sande, wodurch uns hier aus Kundensicht eine gewisse Polemik an der ein oder anderen Stelle nicht vollends zu verdenken ist, denn etliches grenzt schlichtweg an Realsatire. Dies spätestens dann, wenn bei einem anhaltenden Problem zwar offenbar Ressourcen vorhanden sind, um einzelne Nutzer ohne Vorabinfo zu sperren, das eigentliche Thema aber nicht weiter verfolgt, geschweige denn gelöst wird.
Auch wenn meine Begriffe vielleicht etwas salopp gewählt waren und ich stattdessen auch von "Proxies" oder "Stellvertretern" hätte schreiben können, muss es meiner Aufmerksamkeit entgangen sein, inwieweit mein durch dich zensierter Beitrag hier faktisch unrichtig und gar beleidigend gewesen sein soll, lasse mich dazu aber gerne mit näheren Einzelheiten erhellen.
Generell stellt sich die Frage, ob man derlei Kritik zu offenbar missverstandenen Beiträgen wie meinem nicht zielführender und effizienter im direkten Dialog klären könnte - etwa, indem man (völlig verrückt) Betroffene einfach mal direkt anschreibt, bevor man zu Maßnahmen greift, bei denen gedanklich auch zu Coronazeiten jeder Kindergarten durchgehend geöffnet hat. Zumindest ich benötigte hierfür auch keine "Netiquette", da reicht die beständig vorhandene Sozialkompetenz und deswegen bitte ich abschließend frei von Ironie auch um Entschuldigung, falls dich der "Durchlauferhitzer" hier tatsächlich derart gekränkt haben sollte - ganz im Sinne mancher Wissenschaftler, denen zufolge letztlich nicht das entscheidet, was man sendet, sondern nur das, was ankommt (wobei ich hier entgegenhalte, dass der Sender weder Einfluss auf etwaige Störungen auf dem Signalweg noch auf die Interpretation auf Empfängerseite hat).
Jedenfalls lag und liegt es mir fern, andere zu beleidigen, sondern möchte möglichst konstruktiv zur Problembehebung oder zumindest Analyse beitragen.
Insofern nun zu "ausdemdorf":
Nun ja, also mit etwas "Verzögerung im Betriebsablauf" die paar Routenverfolgungen, die ich letzte Woche angezettelt hatte -
Zu deinem Host via O2:
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.8.1 - 39 | 1721 | 1059 | 0 | 0 | 3 | 0 |
| No response from host - 100 | 876 | 0 | 0 | 0 | 0 | 0 |
| 10.96.81.146 - 1 | 4224 | 4212 | 12 | 35 | 502 | 17 |
| 82.113.122.198 - 1 | 4198 | 4180 | 12 | 35 | 438 | 15 |
| IARMUN1-Gi0-2-199.net.de.o2.com - 1 | 4210 | 4197 | 12 | 39 | 473 | 44 |
|ae5-510.0001.inrx.04.muc.de.net.telefonica.de - 1 | 4191 | 4173 | 13 | 38 | 639 | 36 |
|ae3-0.0001.inrx.01.off.de.net.telefonica.de - 1 | 4207 | 4195 | 20 | 47 | 425 | 58 |
| 62.52.49.38 - 42 | 1646 | 969 | 21 | 46 | 469 | 43 |
| No response from host - 100 | 876 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 876 | 0 | 0 | 0 | 0 | 0 |
| x2e721bf0.dyn.telefonica.de - 1 | 4185 | 4166 | 41 | 68 | 465 | 68 |
|________________________________________________|______|______|______|______|______|______|
Zum fraglichen O2-Router via O2:
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.8.1 - 71 | 1147 | 344 | 0 | 0 | 6 | 0 |
| No response from host - 100 | 875 | 0 | 0 | 0 | 0 | 0 |
| 10.96.81.146 - 1 | 4211 | 4197 | 12 | 35 | 434 | 54 |
| 82.113.122.198 - 1 | 4203 | 4188 | 12 | 35 | 439 | 54 |
| IARMUN1-Gi0-2-199.net.de.o2.com - 1 | 4198 | 4183 | 12 | 39 | 432 | 50 |
|ae5-510.0001.inrx.04.muc.de.net.telefonica.de - 1 | 4203 | 4189 | 13 | 38 | 553 | 45 |
|ae3-0.0001.inrx.01.off.de.net.telefonica.de - 1 | 4229 | 4223 | 20 | 46 | 485 | 41 |
| 62.52.49.38 - 1 | 4182 | 4164 | 21 | 48 | 464 | 53 |
Zu sipgate.de via O2:
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.8.1 - 59 | 1309 | 546 | 0 | 0 | 10 | 0 |
| No response from host - 100 | 874 | 0 | 0 | 0 | 0 | 0 |
| 10.96.81.146 - 1 | 4210 | 4196 | 12 | 35 | 492 | 28 |
| 82.113.122.198 - 1 | 4223 | 4213 | 12 | 36 | 442 | 21 |
| IARMUN1-Gi0-2-199.net.de.o2.com - 1 | 4208 | 4196 | 13 | 39 | 558 | 44 |
|ae5-510.0001.inrx.04.muc.de.net.telefonica.de - 1 | 4203 | 4189 | 13 | 39 | 506 | 39 |
|bundle-ether1.0005.prrx.02.fra.de.net.telefonica.de - 1 | 4219 | 4210 | 20 | 46 | 484 | 39 |
| te0-0-2-3.c150.f.de.plusline.net - 1 | 4211 | 4200 | 20 | 48 | 575 | 22 |
| 82.98.102.7 - 1 | 4196 | 4182 | 21 | 48 | 389 | 46 |
| 213.83.57.98 - 1 | 4190 | 4173 | 50 | 76 | 495 | 57 |
| sipgate.de - 1 | 4196 | 4181 | 49 | 74 | 493 | 57 |
Zu deinem Host via Vodafone:
Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.42.129 - 32 | 1929 | 1312 | 0 | 0 | 1 | 0 |
| Request timed out. - 100 | 880 | 0 | 0 | 0 | 0 | 0 |
| 10.218.33.60 - 0 | 4390 | 4390 | 16 | 22 | 148 | 21 |
| 10.218.35.137 - 1 | 4382 | 4380 | 17 | 22 | 119 | 19 |
| 10.218.34.26 - 0 | 4390 | 4390 | 17 | 24 | 110 | 21 |
| 145.254.2.179 - 48 | 1515 | 794 | 0 | 33 | 139 | 37 |
| 145.254.2.179 - 47 | 1538 | 823 | 0 | 31 | 149 | 28 |
|80.81.193.89xp.decix.fra.de.net.telefonica.de - 0 | 4390 | 4390 | 21 | 28 | 106 | 23 |
|bundle-ether6.0002.dbrx.01.off.de.net.telefonica.de - 0 | 4390 | 4390 | 21 | 29 | 169 | 25 |
|ae4-0.0002.inrx.01.off.de.net.telefonica.de - 0 | 4390 | 4390 | 20 | 28 | 95 | 27 |
| 62.52.49.38 - 42 | 1642 | 953 | 21 | 30 | 63 | 29 |
| Request timed out. - 100 | 880 | 0 | 0 | 0 | 0 | 0 |
| Request timed out. - 100 | 880 | 0 | 0 | 0 | 0 | 0 |
| x2e721bf0.dyn.telefonica.de - 0 | 4390 | 4390 | 39 | 51 | 409 | 54 |
Zum fraglichen O2-Router via Vodafone:
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.42.129 - 33 | 1927 | 1308 | 0 | 0 | 1 | 0 |
| Request timed out. - 100 | 880 | 0 | 0 | 0 | 0 | 0 |
| 10.218.33.60 - 0 | 4393 | 4393 | 16 | 23 | 170 | 25 |
| 10.218.35.137 - 1 | 4389 | 4388 | 16 | 24 | 76 | 21 |
| 10.218.34.26 - 0 | 4393 | 4393 | 16 | 25 | 138 | 21 |
| 145.254.2.179 - 38 | 1756 | 1094 | 0 | 31 | 107 | 32 |
| 145.254.2.179 - 38 | 1772 | 1115 | 21 | 30 | 143 | 29 |
|80.81.193.89xp.decix.fra.de.net.telefonica.de - 0 | 4393 | 4393 | 20 | 27 | 53 | 34 |
|bundle-ether6.0001.dbrx.01.off.de.net.telefonica.de - 0 | 4393 | 4393 | 21 | 29 | 53 | 31 |
|ae3-0.0001.inrx.01.off.de.net.telefonica.de - 0 | 4393 | 4393 | 20 | 28 | 74 | 37 |
| 62.52.49.38 - 0 | 4393 | 4393 | 21 | 28 | 62 | 28 |
Zu sipgate.de via Vodafone:
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.42.129 - 23 | 2305 | 1781 | 0 | 0 | 1 | 0 |
| Request timed out. - 100 | 881 | 0 | 0 | 0 | 0 | 0 |
| 10.218.33.60 - 0 | 4395 | 4395 | 16 | 23 | 101 | 20 |
| 10.218.35.137 - 1 | 4391 | 4390 | 16 | 24 | 86 | 29 |
| 10.218.34.26 - 0 | 4395 | 4395 | 17 | 24 | 92 | 23 |
| 145.254.2.183 - 3 | 3994 | 3892 | 24 | 34 | 145 | 34 |
| 145.254.2.183 - 3 | 3993 | 3890 | 24 | 34 | 157 | 44 |
| netzquadrat.dus.ecix.net - 0 | 4395 | 4395 | 24 | 32 | 93 | 29 |
| sipgate.de - 0 | 4395 | 4395 | 23 | 31 | 59 | 28 |
Zu o2online.de via PPTP ProtonVPN:
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 10.10.50.1 - 1 | 1216 | 1214 | 27 | 65 | 3581 | 96 |
| po-13.ce34.ams-01.nl.leaseweb.net - 1 | 1200 | 1194 | 28 | 67 | 3578 | 39 |
| xe-11-0-1.br01.ams-01.nl.leaseweb.net - 1 | 1219 | 1218 | 27 | 67 | 3580 | 91 |
| po-101.agg02.ams-01.leaseweb.net - 1 | 1209 | 1205 | 28 | 66 | 3585 | 94 |
| et-53-1.agg01.fra-12.leaseweb.net - 1 | 1211 | 1208 | 35 | 72 | 3577 | 101 |
| ae-1.bb01.fra-12.leaseweb.net - 1 | 1211 | 1208 | 35 | 75 | 3574 | 90 |
| 213.20.250.185 - 1 | 1208 | 1204 | 34 | 71 | 3578 | 91 |
|bundle-ether17.0002.dbrx.02.fra.de.net.telefonica.de - 1 | 1202 | 1197 | 36 | 75 | 3579 | 69 |
|ae101-0.0002.corx.02.fra.de.net.telefonica.de - 1 | 1203 | 1198 | 35 | 73 | 3577 | 59 |
|ae0-0.21.xmws.99.fra.de.net.telefonica.de - 1 | 1207 | 1203 | 35 | 74 | 3613 | 70 |
|ae5-511.4.server.99.kwn.un.net.telefonica.de - 1 | 1201 | 1195 | 35 | 71 | 3574 | 118 |
| sgncore01-svi290.sg.de.o2.com - 1 | 1206 | 1202 | 36 | 76 | 3572 | 121 |
| www.o2online.de - 1 | 1201 | 1195 | 36 | 71 | 1922 | 98 |
Was mir da auffällt, ist:
- die Ergebnisse streuen teilweise so sehr, dass es schwer fällt, daraus irgendeine Auslastung bei den Providern auszumachen
- schon lokal (hier GigaCube mit 192.168.8.1 sowie Handy mit 192.168.42.129) tritt vermeintlicher Paketverlust auf, der sich jedoch nicht über weitere Hops hinwegzieht
- der mutmaßlich überlastete O2-Router mit 62.52.49.38 beantwortet (ICMP-)Pakte offenbar mit unterschiedlicher Priorität, da je nach Zieladresse mehr oder weniger Pakete "verloren gehen".
- der O2-Router zeigt aus dem Netz von Vodafone in dieser "Messung" keine Paketverluste
- Paketverluste ziehen sich nicht generell durch nachfolgende Hops
- bei Vodafone sind Paketverluste am Ziel dennoch geringer als über O2 oder treten in einem Messzeitraum gar nicht auf. Auch sind die Antwortzeiten tendenziell geringer, wobei der GigaCube hier im Vergleich zu einem Samsung Galaxy Note 8 providerunabhängig für etwas 20 ms zusätzliche Latenzzeit sorgt.
Das mit den Paketen > 996 Bytes, die kommentarlos verworfen werden, ist bei Vodafone übrigens genauso, zumindest via ICMP und über den GigaCube.
Davon unabhängig mache aber auch ich die Erfahrung suboptimaler VPN- und VoIP-Verbindungen via O2 LTE - via IPSec zur Firma laggen RDP-Verbindungen teilweise deftig und auch bei VoIP gibt es in Empfangsrichtung manchmal Aussetzer. Allerdings ist es schwierig einzugrenzen, da ich etwa über Downloads via PPTP- und OpenVPN-Tunnel (UDP) nun auch nicht klagen kann, diese stabil laufen und Einschränkungen bei der Telefonie ebensowenig immer auftreten. In letzter Zeit kam das eher bei Hintergrundlast vor, weniger im sonstigen Leerlauf über den Router.
Ich möchte deine Probleme daher wie bereits erwähnt nicht in Abrede stellen, halte es aber für fraglich, ob man das an - wie hier von dir angegeben - diesem einen Router festmachen kann. Jedenfalls sind die Einschränkungen dazu bei mir zu undurchsichtig und nicht zuverlässig genug reproduzierbar.
Erst einmal danke für deine verzögerte aber dann doch gut informativen Antwort :)
Der Host ist auffällig, parallel zu steigendem Loss an dieser Stelle gehen SSH Tunnel und auch RDP/VPN Verbindungen in den Kaugummimodus. Aber du hast recht, es muss nicht an ihm liegen, es kann auch nur sein das er aufgrund der Last unnützen Krams verwirft und die Fehlerursache woanders liegt.
Wie du schon schriebst, die Ergebnisse streuen teils heftig.
Ich denke das hier mehrere Faktoren aufeinander treffen die außerhalb unserer Bearbeitungsreichweite liegen, hier müsste o2 aktiv werden /wird es eventuell irgendwann.
Zu deinem Bann: Schön das du wieder da bist und es nichts permantes war :)
Zu den 996 Bytes: hier hat es auf Seiten der O2 eine Änderung gegeben, nachdem ich gemeckert habe (ein Anruf bei o2 mal wieder), das laut diversen Shiels Up seiten verdammt viele Ports offen sein würden, die nicht stimmen können, habe ich eine SMS einige Tage später gefunden, das die Störung behoben worden wäre.
Naja, die Ports sind weiterhin angeblich offen, auch ist die maximale MTU augenscheinlich immernoch klein, ABER VPN Tunnel auf UDP ebene bauen seitdem fehlerfrei auf und bleiben auch unter Last stabil.
Immerhin etwas^^.
So habe ich aktuell diese Meldung über einen 1412er MTU Wireguard geschrieben.
Ich weiß nicht wer die Einstellungen im Netz vornimmt, aber zumindest passiert etwas nach Monaten des Frusts.
Erst einmal danke für deine verzögerte aber dann doch gut informativen Antwort :)
Gerne, ich war zumindest"bemüht", wie es so schön heißt.
Der Host ist auffällig, parallel zu steigendem Loss an dieser Stelle gehen SSH Tunnel und auch RDP/VPN Verbindungen in den Kaugummimodus. Aber du hast recht, es muss nicht an ihm liegen, es kann auch nur sein das er aufgrund der Last unnützen Krams verwirft und die Fehlerursache woanders liegt.
Ich vermute, da müsste man mal Tools wie iperf via UDP drauf ansetzen, denn eigentlich kann es ja kein Hexenwerk sein, da mit einer bestimmten Rate zu senden und zu sehen, wieviel davon am anderen Ende (fehlerfrei) ankommt. Irgendwie findet sich dazu aber so gut wie nichts; auch diese ganzen Online-Speedtests basieren quasi immer auf TCP.
Ich denke das hier mehrere Faktoren aufeinander treffen die außerhalb unserer Bearbeitungsreichweite liegen, hier müsste o2 aktiv werden /wird es eventuell irgendwann.
Ja, ich finde das stellenweise Gefrickel wie auch die Geschichte mit der verbockten netzinternen Erreichbarkeit der öffentlichen IP-Adressen etwas schade, denn eigentlich hat Telefónica mit ihrem Mediaways-Erbe ja ganz gute Voraussetzungen in Sachen Routing und Netzkopplungen. Zumindest historisch galt das als ganz solide, während die Telekom ja desöfteren durch überlastete Kopplungen u.a. zu YouTube aufgefallen sein soll.
Zu deinem Bann: Schön das du wieder da bist und es nichts permantes war :)
Ich stand auch die ganzen 7 Tage brav in der Ecke und habe über mein Benehmen nachgedacht, jawohl. Kinderhort, was warst du schön.
Zu den 996 Bytes: hier hat es auf Seiten der O2 eine Änderung gegeben, nachdem ich gemeckert habe (ein Anruf bei o2 mal wieder)
Vielleicht verstehe ich da was falsch, aber bei mir gehen Pings weiterhin nur bis 996 Byte pro Paket. Ist das bei dir nun anders?
das laut diversen Shiels Up seiten verdammt viele Ports offen sein würden, die nicht stimmen können, habe ich eine SMS einige Tage später gefunden, das die Störung behoben worden wäre.
Du meinst das kuriose Phänomen, dass Portscanner bestimmte Ports als erreichbar anzeigen, obwohl auf dem Endgerät gar kein entsprechender Dienst läuft? Falls ja, das war mir vor Jahren auch schon mal aufgefallen, könnte aber auch bei einem anderen Anbieter gewesen sein.
ABER VPN Tunnel auf UDP ebene bauen seitdem fehlerfrei auf und bleiben auch unter Last stabil.
Ich habe da nochmal WinMTR auf die interne Gegenstelle hinter dem VPN laufen lassen und da habe ich über Stunden hinweg ca. ~ 0,3% Paketverlust, was wohl im Rahmen ist, denn RDP und VoIP haben heute auch wieder recht gut funktioniert. Vielleicht liegt das auch am GigaCube (Huawei B818), der immerhin stabil läuft und "nur" etwas die Antwortzeiten erhöht.
Ich weiß nicht wer die Einstellungen im Netz vornimmt, aber zumindest passiert etwas nach Monaten des Frusts.
Die Mühlen der Fachabteilungen mahlen da bei O2 wohl generell noch langsamer als die der Justiz (Stichwort: Watschen vom EuGH in Sachen Roaming).
“Vielleicht verstehe ich da was falsch, aber bei mir gehen Pings weiterhin nur bis 996 Byte pro Paket. Ist das bei dir nun anders?”
Das gilt bei mir auch noch, aber während es nach jedem bisherigen Ticket mitsamt “gelöst” keine Änderung an der Sachlage gab, funktionieren nun Tunnel zumindest.
Ich habe allerdings auch nicht mehr getestet, bin nur für große Downloads am LTE Gateway, alles andere mache ich über die Leitung des magentafarbenen T.
Da steckt bestimmt noch an einigen Stellen der Wurm im LTE Netz, aber ich suche da nimmer, sondern warte auf das Durchlaufen der Kündigung / einen Anruf der Technik der mir alles erklärt und die Fehler behebt.
Da steckt bestimmt noch an einigen Stellen der Wurm im LTE Netz, aber ich suche da nimmer, sondern warte auf das Durchlaufen der Kündigung / einen Anruf der Technik der mir alles erklärt und die Fehler behebt.
Das ist gut möglich. Keine Ahnung, ob das mit der von dir beobachteten Problematik zu tun hat, doch die letzten Tage hatte auch ich wieder relativ grottige Performance via O2 & GigaCube (ich erwähne bewusst diese Kombination, da unschlüssig, an wem es denn nun liegt) - interessanterweise im Rahmen der Nutzung jedoch nur bei YouTube und VPN-Tunnel, wo es dann wieder 3% Paketverlust gibt und RDP zäh reagiert.
Dabei zeigt sich, dass eine TCP-Verbindung zu einem der zahlreichen YouTube-Server recht gemächlich läuft (~ 500 kByte/s, was bei üblichen Playern dann zu ständigen Pufferleerläufen führt), mehrere gleichzeitig zumselben Ziel (etwa via JDownloader) aber dann in Summe auf mehrere MB/s kommen. Downloads von Testservern bringen kurioserweise auch mit nur einer Verbindung mehrere MB/s (wget, curl, etc.).
Da liegt dann eigentlich für mich eine Überlastung einzelner Übergabepunkte und so Ziele nahe, doch nach testweiser Umbuchung auf 3G und zurück auf 4G am GigaCube laufen auch einfache Verbindungen zu YouTube wundersamerweise wieder und der Paketloss im IPSec-Tunnel pendelt sich auf die üblichen 0,2 - 0,3% ein. Soweit ermittelbar in denselben Zellen (der GigaCube zeigt da leider auch wieder nur das genutzte Hauptband und dessen Cell-ID an).
Anscheinend tritt das Ganze immer erst mit längerer Verbindungsdauer auf (die übliche Zwangstrennung nach knapp 24 Stunden "frischt" da wohl nichts auf). Entweder hat der GigaCube Cat 19 (B818-263) da ne Macke oder O2 ein sehr dubioses Netzwerkmanagement, dem man nach einiger Laufzeit nur durch Aus- und Wiedereinbuchen entkommt.
Ich teste das gerade im "Kreuztausch" mit einer Telekom-Karte und werde berichten ...
Hi @ausdemdorf ,
die Technik hatte die Meldung erst geschlossen (aber aufgenommen für die Statistik) und nach dem Eröffnen aufgrund des Alters der Beispiele erneut geschlossen (dieses Mal mit einer Meldung für mich). Kannst du heute neue Tests für den Paketverlust anfertigen?
Viele Grüße,
Kurt
Hi @o2_Kurt, danke fürs am Ball bleiben!
Hier ein frischer Trace: https://pastebin.com/MGa0W6hm - 2500 Pings, ca. 60% Loss.
Start: 2020-09-17T14:13:26+0200
HOST: editiert Loss% Snt Last Avg Best Wrst StDev
1. editiert 0.0% 2500 0.5 2.7 0.3 120.3 10.7
2. AS47147 ae3-4019.bbr02.anx84.nue.de.anexia-it.net (144.208.211.10) 0.0% 2500 0.8 0.6 0.4 36.9 3.2
3. AS47147 ae0-0.bbr01.anx84.nue.de.anexia-it.net (144.208.208.139) 0.0% 2500 4.2 4.0 3.8 51.5 2.8
4. AS47147 ae2-0.bbr02.anx25.fra.de.anexia-it.net (144.208.208.141) 0.0% 2500 3.9 4.2 3.8 69.8 3.6
5. AS??? 80.81.192.89xp.decix.fra.de.net.telefonica.de (80.81.192.89) 0.0% 2500 4.4 4.4 4.2 28.3 1.5
6. AS6805 bundle-ether33.0003.dbrx.02.fra.de.net.telefonica.de (62.53.10.50) 0.0% 2500 5.0 4.7 4.5 29.1 1.1
AS6805 bundle-ether33.0004.dbrx.02.fra.de.net.telefonica.de (62.53.9.52)
7. AS6805 ae1-0.0001.corx.01.off.de.net.telefonica.de (62.53.28.150) 0.0% 2500 7.9 6.6 4.1 57.3 7.4
AS6805 ae0-0.0001.corx.01.off.de.net.telefonica.de (62.53.28.148)
AS6805 ae100-0.0002.corx.02.fra.de.net.telefonica.de (62.53.14.162)
AS6805 ae101-0.0002.corx.02.fra.de.net.telefonica.de (62.53.14.182)
8. AS6805 bundle-ether1.0002.dbrx.01.off.de.net.telefonica.de (62.53.28.155) 0.0% 2500 4.5 4.7 4.5 30.3 1.3
AS6805 bundle-ether2.0001.dbrx.01.off.de.net.telefonica.de (62.53.0.199)
AS6805 bundle-ether2.0002.dbrx.01.off.de.net.telefonica.de (62.53.0.209)
9. AS6805 ae3-0.0001.inrx.01.off.de.net.telefonica.de (62.53.0.121) 0.0% 2500 4.3 4.4 4.1 44.3 3.1
AS6805 ae4-0.0001.inrx.01.off.de.net.telefonica.de (62.53.0.205)
AS6805 ae4-0.0002.inrx.01.off.de.net.telefonica.de (62.53.0.207)
AS6805 ae3-0.0002.inrx.01.off.de.net.telefonica.de (62.53.0.135)
10. AS6805 62.52.49.38 59.3% 2500 4.8 4.7 4.2 27.9 1.3
11. AS??? 10.81.85.18 0.0% 2500 5.0 5.1 4.4 46.6 3.2
12. AS??? 10.81.7.2 0.0% 2500 5.3 10.7 4.9 156.8 16.3
13. AS??? ??? 100.0 2500 0.0 0.0 0.0 0.0 0.0
Hallo @ausdemdorf ,
vielen Dank - Ich habe es gerade weitergeleitet!
Viele Grüße,
Kurt
Moin moin @o2_Kurt ,
knapp eine Woche ist rum, ich wollte mal lieb nachfragen, ob die Kollegen der Fachabteilung sich zurückgemeldet haben?
Hallo @ausdemdorf,
ich habe in Deinem Kundenkonto nachgesehen. Die Fehlermeldung ist noch in Bearbeitung. Die letzten Informationen hatte @o2_Kurt der Fehlermeldung zugefügt. Aktuell warten wir noch auf Rückmeldung vom Fachbereich.
Viele Grüße Bianca
Da angekündigt, noch ein kurzes Update von mir.
Meine Vermutung bezüglich des GigaCubes hat sich so nicht bestätigt, denn mit der Telekom-SIM-Karte lief es auch nach Tagen (übrigens hier ohne Zwangstrennung nach 24 Stunden) einwandfrei. Allerdings fehlt mir nun die Gegenprobe, denn aktuell ist auch die Verbindung über O2 hakelfrei bei VoIP und RDP.
Die Telekom-SIM-Karte zeigte denn auch, dass da technisch noch deutlich mehr mit dem B818 geht - > 200 Mbps, höherer Datendurchsatz direkt beim Start von TCP-Verbindungen sowie geringere Latenzzeiten, aber das hat zumindest derzeit natürlich auch noch einen deutlich höheren Preis.
Die Paketverluste via IPSec beliefen sich über mehrere Tage jeweils auf:
251067/251239 Paketen beantwortet > ≈ 0,07% verloren via Telekom LTE
268550/268922 Paketen beantwortet > ≈ 0,14% verloren via O2 LTE
Beides ohne merkliche Einschränkungen, auch wenn die Telekom in dieser Kategorie ebenfalls vorne liegt. Natürlich ist das nur eine Momentaufnahme und nur an meinem Standort über diese eine Zelle so.
@o2_Bianca
Moin moin,
hat sich hierzu schon etwas am Ticket getan? Bearbeitungsstatus bekannt?
Ich würde ja gerne neue Traces liefern, aber aktuell (so die letzten ~4 Tage?) ging erst der Mast nicht, nun wird seit gestern zumindest dran gearbeitet.
Das bedeutet ~1MBit stark schwankend am Homespot, nicht eingehende oder stark verzögerte Nachrichten auf dem Mobiltelefon, Gespräche werden nicht aufgebaut, oder mein Gegenüber berichtet mir davon, dass es locker schon 15 Sekunden geklingelt hätte, bevor mein Handy überhaupt einen Muks von sich gab.
Wäre es möglich für den ganzen Ärger der letzten Monate -siehe meine anderen Beiträge hier- in irgendeiner Art und Weise ein Entgegenkommen von o2 zu erwirken?
Hallo @ausdemdorf,
leider gibt es bisher noch keine Rückmeldung zu der Fehlermeldung. 
Ich habe die Kollegen gebeten sich schnellst möglich bei Dir mit einem Zwischenstand
zu melden. Vielen Dank für Deine Geduld. 
Viele Grüße Bianca
Also bisher hat sich niemand gemeldet.
Hallo @ausdemdorf ,
ich habe gerade nachgeschaut:
Die Fehlermeldung wurde heute um 15:15 Uhr geschlossen, es sei kein Fehler gefunden worden 
Zwischen meiner und Biancas Anfrage, kam leider keine Nachricht in deine oder unsere Richtung.
Gerne eröffne ich die wieder und schicke weitere Daten von dir hin. Tut mir leid, dass auch diese Meldung ohne Ergebnis bleibt!
Viele Grüße,
Kurt
Vielleicht sind die Technik und ich auch nicht kompatibel… ^^.
Ich möchte wissen und beheben lassen warum Verbindungen jedweder Art, aber bevorzugt Tunnel, abreißen.
Hier jetzt eine SSH Verbindung aus der ich heute im Homeoffice geflogen bin.
Die hat nen paar Kilometer auf dem Rücken, aber auch in die Nachbarstadt nen RDP aufbauen? Kann ich knicken.
Besonders lustig ist auch eine VoIP Verbindung auf einen unserer Firmenasterisk, man versteht kaum etwas, auch die Gegenseite berichtet von massivem Lag und Aussetzern. Ganz davon zu schweigen das eingehende Anrufer locker 5-6 mal klingeln lassen müssen bevor der SIP Client hier nen Mucks von sich gibt.
Baue ich durch euren Homespot im LTE Netz aber einen Tunnel zu einem Server auf und von dem eine Verbindung zum Firmenasterisk → alles super, keine Aussetzer, Sprachqualität top, es klingelt direkt.
Das selbe mit der Conferencelösung von Jitsi, Videoübertragung unmöglich, Ton absolut im Sack.
Tunnel ich es → läufts, bis es dann mittendrin abreisst da der Tunnel zerbröselt.
Vielleicht liegt es ja nicht am Paketverlust beim MTR, sondern etwas anderes ist schlecht im Netz.
Hier von extern rein zu mir, mein Tatverdächtiger Hop in eurem Netz hat nur 66% Verlust.
Klar kann er das verwerfen, sollte er aber nicht.
Die SSH Verbindung hatte “Gummibandeffekte”, arbeiten war kaum möglich.
Wieso dann LTE?
Weil über 6MBit Festnetz nicht wirklich viel geht, dann lebe ich damit alle 5-30 Minuten mindestens eine der aktiven Verbindungen neu anzuwerfen; wichtige Dateitransfers schiebe ich dann übers Festnetz.
MTR Trace:
https://pastebin.com/vQ9yeWrm
Hi @ausdemdorf ,
danke für die Daten! Ich habe es gerade weitergeleitet.
Es tut mir leid, dass wir immer in diesem Rythmus arbeiten. Du meldest, ich leite weiter - usw..
Ich hoffe, dass dies auf kurz oder lang auch mal anders betrachtet werden kann, damit wir vorwärts kommen!
Viele Grüße,
Kurt
*Reguläre Nachfrage nach Stand der Dinge*
Standbilder im Stream…
Aussetzer in VoIP Verbindungen...
Abbrüche bei Spielen...
Abbrüche beim Surfen…
Wie immer geht dann auch der Paketverlust im o2 Netz hoch.
Ich habe mal abwechselnd einen der anderen gekauften Router und den Homespot dran gehabt, die Verbindung bleibt madig.
Nachts um 3 fast 140MBit/s Down, fast 40 Up… Mittags um 3 so 0,1-20MBit/s down, 30 Up (Jo, hier auch noch die Frage nach der 20MBit/s Drossel im anderen Thread den ich grade nicht finde).
Wie schauts aus, kann ich noch auf Besserung hoffen, nach mehreren Monaten?
Ich würde das Produkt gerne benutzen.
Achja, der Mast war auch 3 Mal weg. Einmal habe ich es noch gemeldet, die anderen Tage war es mir egal.
Schön wenn dann anstelle von LTE Vollauschlag das Handy und der Homespot Edge ausweisen.
Eine Satire seitens o2!
Satire! Satire!
Hallo @ausdemdorf ,
an deiner Adresse wird die nächste Station als momentan gestört gelistet (LTE).
Belastungswerte sehen wir nicht mehr, aber scheint sich um eine Belastungsstörung zu handeln.
Die geschilderten Werte passen schon dazu, auch der Unterschied schon recht extrem scheint.
Sollte der HomeSpot an dieser gemeldeten Station angebunden sein, könnten wir dafür derzeit keine Störungsmeldung erstellen.
Ansonsten ist noch nichts neues zu vermelden bezüglich Ausbau. Anstehende Erweiterungen würden wir nur durch die geplanten Arbeiten kurz vorher nachvollziehen können.
Ich glaube mich an das Thema ein Limit bezüglich erinnern zu können.
Auch wenn eine belastungsgesteuerte Begrenzung nicht ausgeschlossen ist, konnten wir dazu keine Bestätigung einholen.
Tut mir leid, dass ich dir keine genauen Infos geben kann. Über die aktuelle Einschränkung stehen uns keine weiteren Details zur Verfügung, deswegen die sehr simple Beschreibung. Das die beständige Verbindung für deine Nutzungsansprüche natürlich enorm wichtig ist, verstehe ich natürlich.
Von hier betrachtet würde nur weiterer Ausbau oder eben eine Erweiterung helfen, um die Situation zu stabilisieren. Dies, wie schon erwähnt, taucht bei uns leider bis kurz vor den Arbeiten nicht auf, deshalb kann ich dir keinen Ausblick liefern.
Bezüglich der Software kann ich derzeit nicht viel neues vermelden. Bugfixes sind in Bearbeitung, ich kann momentan aber nicht sagen, wann diese ausgespielt werden und welche Fehlerbilder damit behoben werden.
Viele Grüße,
Kurt
Danke @o2_Kurt , ich weiß deinen Einsatz wirklich zu schätzen.
Wenn es von mir fies rüber kommt, ist es nicht auf dich und deine Kollegen bezogen.
Bin einfach nur sprachlos Seitens meines langjährigen Dienstleisters o2, dem es alles egal ist.
Heute im Postfach:
---im Thema "Überlast im Telefonica Netz: 62.52.49.38" wurde die Antwort von o2_Katja als "Lösung" markiert ---
Und ich ging schon davon aus, das es eine Lösung gegeben hätte.
Ich möchte darum bitten, das o2 zur Kenntnis nimmt, das das Produkt immer noch nicht brauchbar funktioniert und ich sehnlichst darauf warte im Dezember aus dem Vertrag zu kommen.
Bisher gilt DANKE für den Einsatz der Moderatoren, aber SMS, versprochene Rückrufe oder gar eine Fehlerlösung? FEHLANZEIGE.
Bitte die Lösung wieder löschen und weiterhin notieren, das dieser Kunde immer noch unbearbeitet ist. Nicht einfach in “passt schon” sortieren.
DANKE.
@ausdemdorf Ich bedaure, dass du weiterhin mit der Netzleistung an deiner Adresse unzufrieden bist.
Deinem Wunsch als Ersteller dieses Beitrags komme ich natürlich nach und habe die Lösung wieder rausgenommen.
Viele Grüße
Antje
