Beiträge von CruxTheFirst

    Moin zusammen,


    ich hatte eigentlich vor, von DG zu Vodafon Glasfaser Business zu wechseln. Vor ein paar Monaten, als hier im Ort (Bereich Südhessen, PLZ 648**) noch groß die Verfügbarkeit von Vodafon Glasfaser (via DG) beworben wurde, konnte ich in der Vodafon Verfügbarkeitsprüfung auch meine Adresse und die entsprechenden Glasfaser Tarife finden.

    Jetzt wird für meine Adresse (und testweise auch andere im Ort) jedoch nur noch DSL als verfügbar angezeigt.


    Weiß jemand vielleicht mehr? Wurde diese Kooperation wieder beendet?


    Gruß

    CruxTheFirst

    Mmmmh, beim MTR gegen dns.google ist es eigenartig, dass der Worst Wert mit 15 ms nur knapp ueber dem Durchschnitt liegt und weit unter den mehreren 100 der meisten andererr Hops. Das passt nicht ganz zu einer simplen CG-NAT Gateway Erklaerung, andererseits zeigt es auch, dass Dein Computer und Dein Router wohl auch nicht an den Verzoegerungen schuld sein sollten.

    Ich sehe da auch kein Problem im Transit, der quad-8 trace beweist dieses. Die Averages sind für ein grundliegendes Problem auch viel zu niedrig. Hop by Hop spikes können echt viele Ursachen haben und auch mal verwirren.

    Sind Buzzer und Meeshaw auf dem selben Gateway? Selber 2nd Hop. Alles komisch.

    Ich würde mal die "Gamer" Kisten aus dem Bild nehmen - > Live Linux booten und gescheites MTR laufen lassen wo man auch die Standard Deviation sieht, mtr bitte auch ohne DNS reverse (mtr -n) wenn dann. Falls irgendwo auf dem Unifi Gateway an den Smartqueues gefummelt wurde, alles resetten; selbiges für sämtliche non-standard Settings an der Fritzbox (ja, ich hab gelesen das wohl schon direkt am ONT getestet wurde - ist jetzt erstmal egal wenn vorher mit falschen optionen (10ms interval) getestet wurde)

    Droppen ja aber kein hohen Ping.

    Diese Dinge hängen unter Umständen zusammen. Mit 1 Sekunde timeout sieht dein MTR bezüglich Hop 1 jetzt deutlich! besser aus und mit Verlaub Du hast von fast 2000 Paketen einen Average von 11ms! Du hattest also nur ein paar mal so derbe Ausreisser, die auch andere Ursachen haben können.

    Lass den MTR doch auch mal gegen andere Ziele laufen z.b 1.1.1.1 oder 8.8.8.8

    Der Zielserver verwirft mittlerweile ICMP Pakete - was ja ansich (als Gameserver) keine schlechte Sache ist.

    Völliger Unfug.


    Das ist das ICMP Rate Limit von der Fitzbox - die 17% Paketloss haben somit keine Aussagekraft. Hier erklärt:

    Der Aruba Artikel hat damit nun echt nix zu tun, es kann ICMP Rate Limit sein muss aber nicht.

    17% Packetloss, in DEINEM Netz, zu DEINEM Router. Prüf mal deine Verkabelung und/oder WIFI Settings.

    Gute Analyse. Vielleicht hilft es einem anderen Betroffenen.

    Wenn dieses denn auch wirklich der Grund ist, ist ja auch alles nur Theorie auf Basis des beobachteten Verhaltens. Was mich ärgert ist, dass man bei der Deutsche Glasfaser niemanden aus dem 3rd Level mal zu greifen bekommt und einfach mal ein paar Fakten schafft. Die Anleitung für Kundeneigene Router ist der total Witz, bezieht sich natürlich auch nur auf Fritzboxen und enthält 0 hilfreiche Angaben.

    Witzigerweise, in https://datatracker.ietf.org/doc/html/rfc6355 ": IANA has assigned the value 4 for use by the DHCPv6 DUID-UUID type.
    Sollte also als Standard auch Unterstützt werden; welchen Grund sollte es geben diese Requests abzublocken?


    Pest vs. Cholera - aber ich ziehe wirklich in betracht zu Vodafon Glasfaser im Business Tarif zu wechseln, da ist immerhin noch feste public IPv4 und statischer IPv6 Prefix gegen 5 Euro Aufpreis möglich - und ehrlich, ich war früher da als Kabelkunde (auch Business); so schlecht wie der DG Support ist der Vodafon Support dann auch nicht.

    Hallo zusammen,

    gestern habe ich testweise auf derselben Hardware (MAC-Adressen blieben also unverändert) ein OPNsense Live ISO gebootet. Prompt waren IPv6-Adresse und Standardroute da. Da kommt natürlich sofort die Frage auf, warum VyOS von heute auf morgen nicht mehr funktionierte und die OPNsense sofort...

    Nach längerer Debugging-Session fand ich heraus, dass Deutsche Glasfaser offenbar keine DUID-UUID (Type 4) mehr akzeptiert. FreeBSD bzw. OPNsense verwendet dagegen offenbar DUID-LLT (Type 1)

    Der Vollständigkeithalber:
    DUID-LLT (Type 1): using Link-Layer address plus Time
    DUID-EN (Type 2): using vendor assigned Enterprise Number
    DUID-LL (Type 3): using Link-Layer address
    DUID-UUID (Type 4): using a Universally Unique Identifier (UUID)

    Nachdem ich die DUID in VyOS ebenfalls auf Type 1 umgestellt habe, kam dann auch sofort eine DHCPv6-Antwort - samt Präfix; aber immer noch keine Default-Route. Zehn Minuten später traf dann zwar ein Router-Advertisement ein, doch dessen Router Lifetime war auf 0 Sekunden gesetzt und wird damit natürlich nicht in die Routing Table installiert, vermutlich vom standby Router in dem Segment...

    Irgendwann dann endlich das richtige RA

    tcpdump -s0 -vvv -n -i eth2 -c 1 'icmp6 && ip6[40]==134'
    tcpdump: listening on eth2, link-type EN10MB (Ethernet), snapshot length 262144 bytes
    10:04:48.177385 IP6 (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::ff:fe01:101 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 32
    hop limit 64, Flags [managed], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
    source link-address option (1), length 8 (1): 02:00:00:01:01:01
    0x0000: 0200 0001 0101
    mtu option (5), length 8 (1): 1500
    0x0000: 0000 0000 05dc
    1 packet captured
    1 packet received by filter

    Fazit: Deutsche Glasfaser bastelt und macht Changes ohne das irgendwie zu Dokumentieren und Leute mit Kundeneigenem Router dürfen im Nebel rumgeistern. Support weiss von garnichts. Von Heute auf Morgen: Type 4 DUID = wir reagieren garnicht mehr. Das ganze Setup war 1 Jahr lang stabil vorher, bis auf eine Outage in Januar die sich von Heute auf Morgen in Luft aufgelöst hatte. Erschwertes Troubleshooting: Solange der DHCPv6 Handshake in die Hose geht (und es kommt ja überhaupt gar kein Reply auf die DHCPv6 SOLICITS mit falscher DUID) + eine v4 auf dem Interface aktiv ist, schickt Deutsche Glasfaser dann auch keine UNSOLICITED RAs mehr und man sucht sich einen Wolf was überhaupt los ist - es sieht dann aus als wird sämtlicher IPv6 Traffic verschluckt.


    *seufz* - normalerweise muss der Support sowas sofort in den Logs sehen und nicht 2 Wochen den Kunden vertrösten mit ERLOGENEN Status Mails.

    Update: Heute habe ich ein sehr seltsames Verhalten festgestellt, welches ich gerade auch dem Support als Info schon gesendet habe.

    Nach testweisem Umhängen des ONT von eth3 zu eth2, also damit eine andere MAC-Adresse auf dem WAN sichtbar wurde, waren plötzlich auch eingehende ICMPv6 Route Advertisements im Trace zu sehen, aber nur solange meine IPv4 DHCP-Requests noch abgelehnt wurden (NACK im Trace). Ab dem Zeitpunkt, an dem die IPv4-Adresse zugewiesen wurde, war sofort absolute Stille bezüglich IPv6! Nur noch outbound traffic von mir sichtbar.

    Reproduzierbares Verhalten, nur haut es mich dann immer eine ganze weile offline bis DG die geändert MAC wieder akzeptiert.

    Da sind doch irgendwelche Profile verkonfiguriert?

    Habe alle möglichen Einstellungen durchprobiert in meiner Fritzbox 753

    Das kann natürlich auch schon wieder ein ganz anderes Problem sein. Mein Problem zB ist sehr spezifisch und konkret, da auf meinem WAN Interface seitens DG keine unsolicited Route Advertisments mehr ankommen und meine DHCPv6 SOLICITS auch nicht beantwortet werden bzw. seitens DG da auch kein Traffic mehr zu sehen ist.

    "Durchprobieren" impliziert ich weiss nicht was konfiguriert sein muss.

    Ich vermute mal, diese Mail der DG ist die typische "Ist in Arbeit" Mail bevor das Ticket geschlossen wird mit "kein Problem gefunden / liegt am Router des Kunden" :) ?

    Zitat

    Liebe Glasfaserkundin, Lieber Glasfaserkunde,

    unsere Techniker vor Ort arbeiten weiterhin intensiv und mit höchster Priorität an der Lösung. Die Arbeiten zur Wiederherstellung des Netzes gestalten sich sehr komplex.

    Wir können Ihnen aktuell noch kein Enddatum nennen. Sobald wir über ausreichende Informationen verfügen, nennen wir Ihnen gern umgehend ein Enddatum. Wir melden uns schnellstmöglich wieder bei Ihnen.
    Um die Störung zu beheben, haben wir folgende Maßnahmen eingeleitet:

    Wir befinden uns noch in der technischen Analyse. Weitere Maßnahmen werden wir umgehend benennen

    Frage:

    Lag die IPv6-Adresse deines Router-WAN-Ports bisher im IPv6-Range 2a00:6020:1000::/48 (in der Regel liegt die IPv6-Adresse dann genauer in einem /112-Block der Form: 2a00:6020:1000:PQ::/112, d.h. die WAN-Port-Adresse lautet 2a00:6020:1000:PQ::WXYZ)?

    Falls nicht, dann liegt dein Anschluss vermutlich in einem der Bereiche, in dem DG offenbar eine neue/modifizierte IPv6-Adressierungssystematik einführt, und in denen es vermehrt zu IPv6-Problemen kommt, wie diverse Fälle hier im Forum zeigen.

    Auffällig sind diesbezüglich laut meinen Beobachtungen bisher folgende IPv6-Ranges:

    #PD-Block (/56) Kunden-Anschluss aus:WAN-Port-Adresse aus:
    1.2a00:6020:7380::/41 (2a00:6020:7380:100::/56 - 2a00:6020:73ff:ff00::/56)2a00:6020:7380::/112 (2a00:6020:7380::WXYZ)
    2.2a00:6020:7680::/41 (2a00:6020:7680:100::/56 - 2a00:6020:76ff:ff00::/56)2a00:6020:7680::/112 (2a00:6020:7680::WXYZ)
    3.2a00:6020:7800::/41 (2a00:6020:7800:100::/56 - 2a00:6020:787f:ff00::/56)2a00:6020:7800::/112 (2a00:6020:7800::WXYZ)
    4.2a00:6020:7880::/41 (2a00:6020:7880:100::/56 - 2a00:6020:78ff:ff00::/56)2a00:6020:7880::/112 (2a00:6020:7880::WXYZ)
    5.2a00:6020:8f00::/41 (2a00:6020:8f00:100::/56 - 2a00:6020:8f7f:ff00::/56)2a00:6020:8f00::/112 (2a00:6020:8f00::WXYZ)

    Liegt dein Anschluss in einem dieser Bereiche?

    Moin ::1,

    meine WAN Adresse war bisher in 2a00:6020:1000:PQ::/112 (Mit PD-Block aus 2a00:6020:5000::/41)

    Was mich halt total irritiert, ist, dass überhaupt kein ICMP6-Traffic in irgendeiner Art und Weise mehr sichtbar ist. Dass Solicits nicht beantwortet werden, ist ja nix Neues, aber totale Funkstille, das muss der "Fachabteilung" eigentlich auffallen.

    Seufz.

    Da häng ich mich jetzt mal dazu hier.

    Seit Sonntag (08.06 - kann auch früher gewesen sein aber mein lokales Monitoring hatte zeitgleich Probleme und ich hab es nicht vorher gemerkt) keine IPv6 Adresse mehr (Eppertshausen/ Kreis Darmstadt-Dieburg) mehr. tcpdump (filter auf UDP 546/547 & any ICMP6) komplett stumm auf dem WAN Interface, meine Requests gehen raus; seitens DG stille - keine RAs, keine IA-NA, kein IA-PD.

    Reset vom ONT (Nokia G-010G-Q) ist durch. IPv4 ist alles grün. Hotline ratlos und es liegt jetzt in der Fachabteilung. Ende Januar war es schonmal so, woran es damals lag konnte man natürlich jetzt in den Tickets nicht mehr nachvollziehen :/

    Anschlusstyp: Kundeneigener Router -> (CWWK Barebone mit VyOS)