Wenn es eine DNS Störung ist, dann stelle andere DNS Server ein, und das Problem ist gelöst.
Allerdings bin ich skeptisch, dass das alles ist.
Beiträge von frank_m
-
-
Bandbreiten-Tests sind 100%. Ich bekomme genau das, was vertraglich zugesichert ist.
Das ist aber ein Zeichen dafür, dass es auf TCP Ebene keine Paketverluste gibt. Auf sowas reagieren Speedtests recht empfindlich.
Die folgenden beiden public Atlas-Probes hängen ebenfalls am BNG-Cluster deines DG-Anschlusses: #10214 und #53040. Die IPv4-Traceroute-Messungen dieser Probes stimmen für die Hops 2-4 mit deiner Messung überein (Klicke auf einen Messdatenpunkt und dann auf "SHOW TRACEROUTES" in 10214-Built-ins-v4 bzw. 53014-Built-ins-v4, um die Traceroutes anzuzeigen).
Deren Packet Losses sind unauffällig, jedenfalls deutlich besser, als die hier im Thread.
-
Wie sieht die Statistik aus, wenn ihr kein ICMP, sondern UDP Pakete verwendet? ICMP ist immer heikel, und bei 0.5% braucht man da schon sehr viele Pakete, um auf belastbare Aussagen zu kommen (jedenfalls mehr als 400). Versuche mal mtr mit UDP oder auch mal mit TCP.
ICMPs dürfen deine Firewall ungehindert passieren, ohne burst Regel und so? Bei so Tracing Programmen kann genau sowas problematisch sein, wie ich schon mal schmerzhaft spüren musste.
-
Was für einen Tarif bei welchem Anbieter hast du denn überhaupt bestellt?
-
Aus der Erfahrung der anderen Threads:
- Setze deine Fritzbox auf jeden Fall noch mal auf Werkseinstellungen zurück. Nutze auf keinen Fall das Profil der Deutschen Glasfaser, oder ein eigenes Profil mit dem Namen "Deutsche Glasfaer" oder "deugl". Hast du das einmal getan, ist wieder ein Werksreset nötig. Wieder mit 60 Minuten Wartezeit
- Da du direkt mit dem Notebook ein IPv6 Prefix gesehen hast, könnte es ein Problem mit der fehlenden Wartezeit (60 Minuten) gewesen sein
- Es kann aber auch eine fehlerhafte Umstellung des Anschlusses sein, und es ist noch der DG Router Modus aktiv. In dem Fall solltest du mal probieren, VLAN ID 360 für den Internet-Zugang einzurichten.
- Wann hast du den ONT das letzte mal zurückgesetzt?
-
Ja. Glaubs mir. Es dürfte nicht mehr viel an 100 Anschlüssen fehlen, in denen ich die Einrichtung so vorgenommen habe.
-
Mir ist nach etlichen Werksreset's (insgesamt mindestens 20) aufgefallen, dass nicht alle Daten gelöscht werden.
Die Ereignisse werden sogar bei einem Reboot gelöscht, weil sie nur im RAM liegen, dafür braucht es keinen Werksreset. Was auch immer du da veranstaltest...
Und beim Eingeben diverser Namen und Einstellungen wurden diese schon vorangezeigt.
Das liegt an deinem Browser.
Wenn du an einem AON Anschluss nach einem Werksreset mit dem gleichen Router keine Verbindung bekommst, hast du ihn falsch eingerichtet. Da braucht es keine Wartezeit.
-
Wird die VLAN ID 362 in der Telefonie nicht vielleicht durch die Deaktivierung von "Für Internettelefonie eine separate Verbindung nutzen" ignoriert?
Das schon, aber beim Internetzugang war ja auch die falsche VLAN ID drin. Und das heißt, du hast eine DG Router Konfiguration importiert. Warum das schlecht ist, steht in Beitrag #79.
-
Warten wir es ab. Deiner Beschreibung oben zufolge musstest du auch die VLAN ID von 360 auf 362 ändern und hattest ein eigenes VLAN für die Telefonie aktiv. Das heißt, du hast eine Config aus einem DG Router in deinem Kundeneigenen Router. Das wird auf Dauer nicht gutgehen. Glaubs mir, ich beschäftige mich seit 2007 intensiv mit Fritzboxen.
-
Ich bin im Moment so froh, dass alles perfekt funktioniert, dass ich mich nicht traue, noch irgendeine Einstellung zu verändern. Sorry!
Geistern da noch importierte Einstellungen in deinem Router rum? Dann würde ich dringend davon abraten, es so zu lassen.
-
Da fehlt die richtige VLAN ID.
-
Es geht mir um den Sinn/Unsinn bei Miet-Routern und bei Kundentroutern unterschiedliche VLANs zu verwenden...
Das hab ich ja erläutert, warum das so ist. Die Gründe ja ja recht einfach nachvollziehbar.
-
... und in der 5590 die richtige VLAN ID einstellen!
-
Du gehst wohl davon aus, dass die DG da massiv schlauer sein muss als quasi die gesamten Mitbewerber.
Massiv schlauer hab ich nicht gesagt. Aber der Ansatz ist nach meinen eigenen Erfahrungen technisch überlegen und noch dazu kostengünstig und relativ einfach umzusetzen. Das Gegenteil zu beweisen, dürfte schwer werden.
Die Frage sei erlaubt wie das zur aktuellen wirtschaftlichen Situation der DG passt?
Das ist kein Argument. Stehen andere Netzbetreiber besser da? Wie viele hat es davon in den letzten Monaten dahingerafft? Und wo stände die Telekom ohne ihr Kupfernetz im Rücken?
-
Du missverstehst, ich argumentiere nicht gegen einen Reset im Allgemeinen, sondern dagegen, dass die DG dem Nutzer das SIP-Problem haette ersparen koennen, wenn auf die wenig nachvollziehbare differentielle Provisionierung verzichtet wuerde.
Ja, das hätte in diesem konkreten Fall dann vielleicht die Telefonie erlaubt. Aber das würde ja den Verzicht auf die technischen Vorteile des Ansatzes bedeuten - das lässt sich durch so einen Sonderfall wohl kaum rechtfertigen. Und was hilft es, wenn der Kunde durch die anderen Randbedingungen am Ende eh den Reset durchführen muss, durch den er dann auf jeden Fall in den Genuss eines funktionierenden Setups kommt?
Die Frage, die ich schon so oft gestellt habe: will man auf Prinzipien herumreiten, oder einfach lösungsorientiert vorgehen?
-
Ja, nur hat der Internetzugang und das WLAN funktioniert,
Oh, Vorsicht. Er hat noch nicht von Speedtests und Langzeitstabilität berichtet.
Erm wo das? Er wird von der DG keinen SIP-Zugang ueber DSL beikommen haben... und wenn ich es rochtig verstehe hatte die Telephonie urspruenglich funktioniert.
Die 7690 ist eine DSL Box und hat damit eine Konfigurations-Sektion für diesen DSL Teil, der nun in der 5590 herumliegt. Die hat das normalerweise nicht. Wurde zwar in der 7690 nicht benutzt, kann die 5590 aber trotzdem aus dem Tritt bringen.
Schau dich einfach im Forum um, wenn du mir nicht glaubst. Es haben schon viele versucht, aber wegdiskutiert hat die Probleme nach Konfigurationsimporten noch niemand.
-
Wie schon einmal berichtet sehe ich bei meiner provisionieren, kundeneigenen (DG Portal) 5530 direkt an der Faser (klar, sonst wäre sie ja nicht provisioniert) in der Diagnosedatei die Verwendung des VLANs 362.
In deinen Internetzugangsdaten ist sie aber nicht drin, oder?
-
Wenn die DG, wie z.B. die Telekom immer mit ein und dem selben VLAN arbeiten wuerde, haette es das Problem IMHO gar nicht gegeben.
VLAN ist ja nur eines der offensichtlichen Probleme. Wie ich oben schon schrieb: Auch wenn er nun die VLAN ID rausnimmt, kann er trotzdem nicht telefonieren. Er muss die VoIP Accounts mit den zugesandten Zugangsdaten neu einrichten.
Er hat die Konfiguration seiner 7690 der DG in die freie 5590 importiert. Schon allein die Unterschiede in der Hardware sorgen dafür, dass solche Importe immer schiefgehen. Die 7690 ist ein monolithisches System aus einem SoC, der sich um alles kümmert. Die 5590 besteht aus dem Hauptprozessor und einem Tochterboard für die Glasfaser- und WLAN Anbindung. Die Ansätze in der Konfiguration und im Firmware-Aufbau sind komplett unterschiedlich, entsprechend hoch das Risiko, dass die Konvertierung nicht funktioniert. Von der unterschiedliche WLAN Hardware mit den daraus folgenden Unterschieden will ich gar nicht reden.
Die 7690 lief am WAN Port, die 5590 am Glasfaseranschluss. Wie hier zigfach nachzulesen ist (und auch von anderen Nutzern immer wieder bestätigt wird): Bei der Umstellung der Anschlussart mache in einer Fritzbox IMMER einen Werksreset. Da ändert sich unterm Blech so viel, dass die Konvertierung schiefgeht.
Dazu kommt der Umstand, dass er eine DSL Konfiguration in einen Glasfaser-Router importiert hat: da liegen jetzt unpassende Konfigurationsleichen herum, obwohl der DSL Anschluss in der 7690 nicht benutzt wurde. Der Providerfirmware der 7690 hat spezifische Anpassungen (nicht nur für den Autokonfigurations-Server), auch davon sind Konfigurationen nun in der 5590, die damit nichts anfangen kann. Nicht zuletzt sind die VoIP Konfigurationen, QoS Einstellungen und Traffic-Shaper unterschiedlich einzurichten.
Das Vorhaben, die alte 7690 Konfiguration in der neuen 5590 zu nutzen, war aus diversen Gründen zum Scheitern verurteilt. Der Hinweis auf den Werksreset ist eine zwingende Notwendigkeit: So wird er mit seinem neuen Router keine Freude haben.
-
QoS hat IMHO erst mal nichts mit VLANs und schon gar nicht mit unterschiedlichen VLANs zu tun, und ob L2-QoS optimal ist ist auch diskutabel.
Oh, diesbezüglich kann ich dich beruhigen. Wir haben umfangreiche Analysen in einem Automotive Ethernet gemacht, mit der Anforderung, zeitkritische Kontrolldaten über Video-Daten zu priorisieren. L2 QoS hat sich dabei als überlegen gezeigt und war auch günstiger zu realisieren. Die Trennung in VLANs hat sich dabei aus mehreren Gründen als vorteilhaft erwiesen (u.a. Trennung der Broadcast Domains, Lenkung von Datenströmen), auch wenn es kein Muss ist, wie du schon richtig festgestellt hast.
Wie gesagt, ich kann da nichts Schlechtes erkennen. Die technische Lösung halte ich allen anderen für deutlich überlegen und preiswert in der Hardware-Umsetzung.
Und seien wir ehrlich, wenn der Kunde derartig grundlegende Anleitungen ignoriert, rettet ihn auch ein anderer technischer Ansatz des Providers nicht. In diesem konkreten Fall wäre es auch zu Problemen gekommen, würde die DG das gleiche VLAN Konzept für beide Anschluss-Typen benutzen.
-
Es gibt durchaus gute Gründe für die unterschiedliche VLAN Konfiguration.
Beim DG Router werden die Router automatisiert konfiguriert, und folglich können relativ leicht unterschiedliche VLANs für Internet und Telefonie eingerichtet werden. Damit ist immer die optimale QoS möglich, der Kunde profitiert, ohne das es komplex wird.
Beim kundeneigenen Router muss die DG halt davon ausgehen, dass der Router des Kunden ggf. gar nicht 2 VLANs für Internet und Telefonie-Verbindung einrichten kann. Und wenn, dann wird es so komplex, dass mindestens 90% der Kunden damit überfordert wären. Also beißt man in den sauren Apfel und nutzt nur noch ein VLAN für Internet und Telefonie, mit dem man hinter dem ONT der DG überhaupt nicht konfrontiert wird. Man richtet die Endgeräte mit den Zugangsdaten von der DG ein und gut ist es. Erst wenn man am AON Anschluss ohne Wissen der DG den ONT tauscht, muss man sich um eine VLAN ID kümmern, und auch für den Fall ist es dokumentiert. Am GPON Anschluss wird sogar dann die VLAN ID rausgenommen, weil die DG über das Onboarding mitbekommt, dass der Kunde nun einen eigenen ONT nutzt.
Ich kann in dem Vorgehen nichts Schlechtes erkennen. Man sollte sich halt nur an die Anleitungen halten und nicht aus seinen alten DG Routern Konfigurationen in kundeneigene Router importieren. Das ist aus mehreren Gründen ein No-Go, und man wird in dem konkreten Fall direkt mit nicht funktionierendem Internet und Telefon bestraft.
Bezeichnend für dieses Forum ist wieder, dass daraus ein Vorwurf für den Provider gestrickt wird. Das hier war ein Konfigurationsfehler des Endkunden, weil er die Anleitung nicht beachtet hat. Punkt. Daran werdet ihr nichts schönreden.
