Glasfaser für Brieselang - FUXX!NET oder DNS:NET

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von chrislu

    Dem schließe ich mich an! ( sPnzz).

    Sonst zum Thema, seit es gestern Nacht schlagartig funktionierte habe ich heute noch keine Probleme gehabt.

    Sehr schön aber richtig merkwürdig, dass dieses Problem dich und fujitsu Abends komplett lahmgelegt hatte während es bei uns kaum spurbar war (außer bei den Speedtests).

    Zitat von murphaph

    Sehr schön, aber richtig merkwürdig, dass dieses Problem dich und fujitsu Abends komplett lahmgelegt hatte, während es bei uns kaum spürbar war (außer bei den Speedtests).

    Ich hatte auch Einschränkungen. z.B. nicht nutzbarer Video-Call bei Whatsapp, oder Download von Ubuntu mit 3:30, Intel CPU-GFX-Treiber Abbruch nach 15 Min. (dauert sonst 15-20 sec.). Aber auch sehr träger Webseitenaufbau.
    Heute war alles chick. 19:00 bis eben immer über 900 MBit. Dafür hat ein paarmal der Upload geschwächelt, 300 - 400 MBit. ;) Alles mit dem Messprotokoll (Breitband-Tool).

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Komplett lahmgelegt waren wir nicht.

    Es ist wie Phino schreibt.

    Teams bricht ab,

    Smart Home Geräte erreichen ihren Server nicht, Ladekreis bei Netflix…

    und dann misst man halt mal nach.

    komplette Ausfälle waren kurz und nicht jeden Abend.

    Aber viel schlechter als bei DSL.

    Im Moment ist es viel besser und konstanter.

    Heute schraube ich an Failover & Failback in meinem Edgreouter X. Alles läuft super bei mir, nachdem ich die Fehlende Load-Balancing-regeln zur Firewall hinzugefügt habe. Aber mir ist was ausgeffalen als ich das ganze mit MTR getestet habe. DNS:Net scheint immer noch Packet-Loss zu haben.

    Hier ein MTR zu 8.8.8.8 über DNS:Net-Glasfaser:

    Das gleiche aber über meine Failover-VDSL der Telekom:

    Laut whois gehört der Server der DNS:Net:

    Ich bin ja kein Expert. Was meint ihr? Müsste DNS:Net sich darum kümmern? Oder ist sowas zu vernachlässigen?

    Zitat von murphaph

    DNS:Net scheint immer noch Packet-Loss zu haben.

    Welche Paketverluste meinst du? Die 6% von dem einen Hop in der Mitte? Die sind unkritisch, das ist ICMP limiting. Entscheidend ist in dem Fall nur die Statistik zum letzten Hop, und die ist unauffällig, sowohl in Bezug auf die Verluste als auch in Bezug auf die Delay Times.

    Wenn mitten im Trace Verluste auftreten und anschließend nicht mehr, ist das unkritisch. Wenn ab einem bestimmten Hop immer Verluste auftreten, dann kann das ein Hinweis sein, muss aber nicht. Aber dann empfiehlt es sich, mit gezielten Werkzeugen auf Applikationsebene genauer hinzuschauen.

    Netzwerk-Monitoring: Ping und Traceroute richtig interpretieren
    Klemmt es im Netzwerk, so helfen Ping und Traceroute, Fehler und Engpässe einzukreisen. Wir erklären die Funktionsweise und helfen Angriffe aufzudecken.
    www.heise.de

    Die Traces sind beide perfekt.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von upD8R

    Urgs, heute bei mir (15370, nicht Brieslang und DSL, kein FTTH) geht seit 20 Uhr kaum noch was, gerade mal 2 MBit/s, das mag mein Waipu gar nicht ...

    HIer in Brieselang genau dasselbe. Teilweise gar kein Internet. Wobei die Verbindung und IP-Adress-Zuweisung funktioniert. Jetzt seit ca. 5 Min sieht es wieder gut aus. Meine Leitung hat daher nicht umgeschaltet auf Fallback, weil sie dachte alles ist gut.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Nach den gestrigen Aussetzer (ab Vormittags, abends extrem) scheint es heute wieder rundzulaufen.
    Wäre schön, wenn so etwas auf der Webseite von DNS:NET dokumentiert werden würde.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Ich messe eigentlich immer nur stündlich, 7 min nach der vollen Stunde. 19:07 ging es runter, tot ab 20 Uhr bis nach 22 Uhr, dann ging es wieder aufwärts, was die DL-Raten anging.

    Meine neu aufgesetzte Smokeping-Instanz zeigt das hier:

    Schwer zu sagen, so bis 22:00 Uhr. Aber ein ganz anderes Verhalten als bisher. Die Leitung stand, IP-Adresse vorhanden. Aber die Windows-Clients waren mal offline und dann wieder online. Zu sehen am Icon unten rechts. Bei SmokePing ist nichts zusehen. Meine Router (Unifi UDM SE) hat auch nicht auf Fallback umgeschaltet, weil er ja eine IP hatte und Ping funktionierte.
    Meine Frau war genervt, weil sie immer wieder bei Citrix herausflog. Und auch beim Telefonieren hatte ich 2 Unterbrechungen. AM späten Nachmittag meldete die FB: telefonieren länger als eine Stunde nicht möglich. Und ich habe bei 3 SIP-Anbieter Rufnummern.

    Zitat von Phino

    Meine Router (Unifi UDM SE) hat auch nicht auf Fallback umgeschaltet, weil er ja eine IP hatte und Ping funktionierte.

    Habe gerade im Log meines Edgerouters geschaut. Ist bei mir auch so gewesen. Das gute ist, dieses mal hat es anscheinend sehr viele getroffen, vielleicht sogar alle DNS:Net Kunden und war nicht zu ignorieren.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von upD8R

    Ich messe eigentlich immer nur stündlich, 7 min nach der vollen Stunde. 19:07 ging es runter, tot ab 20 Uhr bis nach 22 Uhr, dann ging es wieder aufwärts, was die DL-Raten anging.

    Meine neu aufgesetzte Smokeping-Instanz zeigt das hier:

    Welchen Endpunkt testest du?

    Zitat von Wellenreiter

    Welchen Endpunkt testest du?

    Wahrscheinlich nicht den richtigen, ich teste einfach auf http://www.dns-net.de in der Hoffnung, dass sie die Seite in ihrem eigenen Realm hosten. Habe ich aber ehrlicherweise gar nicht nachgeschaut.

    Haste eine bessere Idee?

    Habe aber auch deren Peering-Port in FRA mit drin (80.81.194.30), das sah aber auch nicht besser aus.

    Oder meintest Du die Speedtest.net Server ID? Das ist die 20507, also DNS:NET selbst.

    Einmal editiert, zuletzt von upD8R (4. Juli 2023 um 15:10) aus folgendem Grund: Frage eventuell falsch verstanden