Beiträge von tkriener

  • Erfahrungen mit e.on / Westconnect bzgl. AON oder PON?

    Kurzes Update:

    Scheinbar wurde im Netz was angepasst. Bei mir haben die Aussetzer am Donnerstag 18.1. nach 10:00 Uhr aufgehört.
    Ein tcpdump, den ich heute gezogen habe, zeigt dass der DHCP-Server direkt auf den ersten Request nach 15 Minuten antwortet.

    Im UDM-Forum hat ein anderer Nutzer ähnliches beobachtet.

    Aktueller Stand meiner UDM Pro ist OS 3.2.9 und Network 8.0.26.

  • Erfahrungen mit e.on / Westconnect bzgl. AON oder PON?

    Was meinst Du mit Renews? Die Inline-Kopie im Beitrag ist Cut-And-Paste aus Wireshark. Laut RFC2131 ist "RENEWING" ein Status in dem dann wieder DHCP Requests geschickt werden, bei denen nur die Parameter anders aussehen, wie beim Request in der initialen Phase.

    Oder übersehe ich was?

    Laut dem Post hier gab es mit dem udhcpc aus BusyBox 1.30 wohl Probleme, wenn Provider bestimmte Flags bei den DHCP-Requests filtern.

    Allerdings hat das Binary die Version "BusyBox v1.34.1" von Oktober 2023 und es funktioniert ja ein paar mal hintereinander, bevor dann gar keine Antworten mehr kommen.

    Für mich sieht das eher so aus, das da beim DHCP Server sowas in der Art wie eine "Spam"-Schwelle erreicht wird mit Paketen, die nicht die erwarteten Parameter setzen. Was das genau ist, weiß aber wahrscheinlich nur der Betrieb des DHCP-Servers.

  • Erfahrungen mit e.on / Westconnect bzgl. AON oder PON?

    Hallo,

    habe den tcpdump heute erstellt und angehängt (dhcp_20240108.zip).

    Kommando war:

    tcpdump -U -i eth8.132 -w - "(udp port 67 and port 68) or (udp port 546 and port 547)"

    Für mich sieht das aus, als ob der DHCP-Server nicht antwortet.

    Die UDM schickt nach ca. 15 Minuten einen ersten DHCP-Request an den DHCP-Server, was der halben Leasetime entspricht. Sollte soweit in Ordnung sein, oder?
    Bekommt darauf mehrfach keine Antwort, bis sie dann einen Request per Broadcast schickt.

    Das scheint oft zu funktionieren, bis dann nach ca. 3 Stunden (in dem Fall ca.14:10) auch auf den Broadcast keine Antwort kommt und die UDM einen DHCP-Discover startet. Der führt dann bei mir zu einem kurzen Ausfall der Verbindung, weil die IP verworfen wird.

    Den PCAP habe ich auch per Mail an den Support geschickt. Keine Ahnung wie die mit unaufgeforderten Informationen umgehen, aber vielleicht liest ja jemand mit. Ticketnummer ist wohl CRM:0269327 oder CRM:0385227, jedenfalls sind die Nummern mal in Mails aufgetaucht.

    Vielleicht hat ja jemand eine Idee, was schief läuft.

  • Erfahrungen mit e.on / Westconnect bzgl. AON oder PON?

    Das dass mit IPv6 zu tun hat, würde mich wundern, da meines Wissens nach mit "öffentlicher IPv4" kein IPv6 bekommt. Deshalb ist IPv6 bei mir auch deaktiviert. Hat der 1. level so auch nochmal abgefragt.

    Vielleicht hilft auch schon der Hinweis, dass in der UDM hier ein udhcpc von busybox benutzt wird. Die haben den nur leider so mit einem internen Binary verknüpft, dass man die Aufrufparameter nicht anpassen kann. Zumindest nicht als Nutzer.

    Ich bin jetzt zwar erstmal bis 8.1. in Urlaub, dann aber zu allen Schandtaten bereit, wenn mir einer beschreibt was er genau braucht. Macht mit Sicherheit keinen Sinn einen PCAP über 3-4 Stunden mitzuschneiden und einzuschicken.

    In den Logs von der UDM sehe ich leider nicht viel. Um hier einen sinnvollen Debug zu erzeugen braucht es wahrscheinlich wirklich den Hersteller.

    Nur wie soll ich das sinnvoll mit einem 1. Level aushandeln?

  • Erfahrungen mit e.on / Westconnect bzgl. AON oder PON?

    Hallo,

    ich bin einer der betroffenen und traue mir durchaus zu IP-Netzwerke und Routing verstanden zu haben. Zumindest hat mich mal eine Hochschule 10 Jahre lang dafür bezahlt Studenten darin zu unterrichten.

    Zitat von kingpin42

    Telefonie ist auch mit öffentlicher IP im "Internet VLAN" erreichbar, da dort auch die Route zu den SIP-Proxys enthalten ist (10.199.27.0/24).

    Das werde ich in jedem Fall mal austesten. Schade nur, dass das zumindest als ich es vor 1,5 Jahren aufgebaut habe, nirgends dokumentiert war.

    Zitat von kingpin42

    Das Infoblox DHCP Cluster bei uns verhält sich jedenfalls strikt RFC Konform, ich hab leider keine USG oder andere Router von Ubiquiti zur Hand und könnte es direkt testen, jedoch habe ich mit "üblichen Verdächtigen" wie openWRT,*sense und Mikrotik keine Probleme mit kurzen Verbindungsabbrüchen durch Reconnects, wie dort beschrieben.

    Ich glaube gerne dass das RFC Konform funktioniert, allerdings hat sich bei meinem Zugang das verhalten netzseitig ab ca. 7.11.23 geändert. Bis dahin hatte ich ca. 1,5 Jahre alle paar Tage mal eine Meldung vom Router, aber ohne die Auswirkungen wirklich zu merken.

    Seit dem 7.11. bekomme ich ungefähr alle 3 Stunden eine Meldung vom Router, teilweise sogar öfter. Gleichzeitig gibt es dann Unterbrechungen von Verbindungen per RDP, SSH etc.

    Was mich massiv ärgert, ist dass man vom Support Null Rückmeldung erhält. Wenn man dann selbst anruft erfährt man, das vor Tagen was von der Technik gemacht wurde und es im Ticket die Rückfrage gibt, ob das Problem noch existiert. Darauf kann man aber keine Antwort erhalten, wenn man den Kunden nicht darüber informiert.

    Ich bin gerne bereit bei der Fehlersuche zu unterstützen, dafür muss man dann aber auch in beide Richtungen kommunizieren.

    Wenn sich herausstellt, dass der Fehler bei Ubiquity liegt, mache ich auch gerne dort ein Ticket auf. Aber wenn etwas 1,5 Jahre ohne Probleme funktioniert, und dann ohne Änderung am Router auf einmal nicht mehr geht, gehe ich erstmal davon aus, dass das Problem auf der anderen Seite liegt.

    Gruß,

    Thomas Kriener