Beiträge von ctr

merkwürdigerweise habe ich seit der Wartung erheblich höhere roundtrips. von (im Tagesmittel zu Cloudflare, Google und Azure, entsprechend der Unifi default checks) 4.3 ms zu 12.7 ms.

Es geht wieder (ohne Änderungen meinerseits), default route kommt über RA rein.

Meine Interface IP hat sich vom Block `2a00:6020:1000:41::` in `2a00:6020:1000:40::`und das announcte Präfix von `2a00:6020:5080::/41` in `2a00:6020:5000::/41` (41bit maske laut info von user ::1) geändert

Zitat von ::1

Ist denn in den NA der Gegenstelle das R-Flag gesetzt? Ich vermute mal, nein. Denn andernfalls hätte die Unify-Selbst-Konstruktion der Gateway-Adresse evtl. funktioniert.

doch ist gesetzt

No.     Time                          Source                Destination           Protocol Length Info
      5 2026-05-19 12:25:19,653599    fe80::xxxx:xxxx:xxxx:xxxx fe80::ff:fe01:101     ICMPv6   86     Neighbor Advertisement fe80::xxxx:xxxx:xxxx:xxxx (rtr, sol, ovr) is at 16:3c:60:xx:xx:xx

Frame 5: Packet, 86 bytes on wire (688 bits), 86 bytes captured (688 bits)
Ethernet II, Src: 16:3c:60:xx:xx:xx (16:3c:60:xx:xx:xx), Dst: 02:00:00:01:01:01 (02:00:00:01:01:01)
Internet Protocol Version 6, Src: fe80::xxxx:xxxx:xxxx:xxxx, Dst: fe80::ff:fe01:101
Internet Control Message Protocol v6
    Type: Neighbor Advertisement (136)
    Code: 0
    Checksum: 0xfe32 [correct]
    [Checksum Status: Good]
    Flags: 0xe0000000, Router, Solicited, Override
        1... .... .... .... .... .... .... .... = Router: Set
        .1.. .... .... .... .... .... .... .... = Solicited: Set
        ..1. .... .... .... .... .... .... .... = Override: Set
        ...0 0000 0000 0000 0000 0000 0000 0000 = Reserved: 0
    Target Address: fe80::xxxx:xxxx:xxxx:xxxx
    ICMPv6 Option (Target link-layer address : 16:3c:60:xx:xx:xx)
        Type: Target link-layer address (2)
        Length: 1 (8 bytes)
        Link-layer address: 16:3c:60:xx:xx:xx (16:3c:60:xx:xx:xx)

und die "Unify-Selbst-Konstruktion der Gateway-Adresse" funktioniert ja auch (das war der routing Eintrag mit "dhcp" nebst dem dazugehörigen Log, das genau das gesagt hat. d.h. ich habe eine default route - aber sie funktioniert nicht.

Zitat von ::1

Da müsstest du so im PLZ-Gebiet 66xxx/67xxx (SL/RP) liegen (IPv6-Range 2a00:6020:5080::/41) - ich habe noch nicht gesehen, dass dort auf das "neue" Adresskonzept umgestellt wird.

Nein in 61xxx (HE) genau gesagt diesem Wartungsgebiet:

{
  "category": "Wartung",
  "area": [
    "Hessen"
  ],
  "subject": "Wartung TV, Internet, Festnetz: Hessen - Bad Homburg vor der Höhe, Butzbach, Glashütten (Taunus), Grävenwiesbach, Neu-Anspach, Ober-Mörlen, Oberursel (Taunus), Schmitten (Hochtaunus), Usingen, Wehrheim, Wöllstadt, Weilrod",
  "description": "<p>Betroffenes Gebiet: Hessen - Bad Homburg vor der H&ouml;he, Butzbach, Glash&uuml;tten (Taunus), Gr&auml;venwiesbach, Neu-Anspach, Ober-M&ouml;rlen, Oberursel (Taunus), Schmitten (Hochtaunus), Usingen, Wehrheim, W&ouml;llstadt, Weilrod</p>\r\n\r\n<p>Wartungsbeginn:&nbsp;20.05.2026, 12:30 Uhr<br />\r\nWartungsende:&nbsp;21.05.2026, 06:00 Uhr<br />\r\nAusfallzeit:&nbsp;360 Minuten<br />\r\n&nbsp;</p>\r\n\r\n<p>Auf Grund einer geplanten Wartung stehen alle Dienste in dem angegebenen Zeitraum nicht zur Verf&uuml;gung.</p>\r\n\r\n<p>Sollten Sie nach Ende der Wartung weiterhin Probleme&nbsp;mit Ihrer Verbindung haben, f&uuml;hren Sie bitte einen Neustart&nbsp;durch. Dazu trennen Sie Ihre&nbsp;Ger&auml;te kurz vom Strom.</p>\r\n\r\n<p>Wir danken&nbsp;f&uuml;r Ihr Verst&auml;ndnis.</p>\r\n\r\n<p>Ihr Deutsche Glasfaser Team</p>\r\n\r\n<p>&nbsp;</p>",
  "affectedProducts": [
    "TV",
    "Internet",
    "Festnetz"
  ],
  "start": "2026-05-20T12:30:00+02:00",
  "end": "2026-05-21T06:00:00+02:00",
  "updatedAt": "2026-05-06T14:47:16.276423+02:00"
}

"trotzdem" im Sinne von eben nicht per DHCPv6 (weil es ja per DHCPv6 auch gar nicht geht). Ich wollte hier nur den IPv6-unkundingen Leser nicht verwirren (insbesondere in Hinblick auf den Routingeintrag der dhcp suggeriert aber eben anderweitig aus dem Userspace kommt).

Die Gegenstelle sendet NS und und NA, aber keine RA. manuelle default route auf Gegenstelle liefert die Pakete an die Gegenstelle, aber es kommt nichts zurück.

Habe gerade mal ein traceoute von "draußen" auf mein Präfix gesendet und sehe so etwas lustiges wie:

 1:  gateway                                               0.905ms 
 2:  2a00:d0c0:200::1                                      0.719ms 
 3:  2a00:d0c0:c:100::2                                   85.737ms 
 4:  fd00:bb:bb:7141:1142::1                               0.956ms 
 5:  no reply
 6:  no reply

Ich befürchte im Rahmen der Wartung (morgen geht es weiter: 6h vom 20.05.2026 um 12.30 Uhr bis zum 21.05.2026 06.00 Uhr!) wird auf die neue Struktur umgestellt von der hier ja verschiedentlich auch die Rede war. Derzeit habe ich noch eine Interface IP aus dem 2a00:6020:1000:41:: Block und quasi-statische IPv6.

genau so hatte ich es auch immer (nur mit 56 statt 64, weil ich mehrere Netze brauche) - aber seit der Wartung gehts halt nicht mehr, vorher schon (ohne Änderungen meinerseits)

Nach dem ich jetzt fast 2 Monate ohne Probleme (mal von den gelegentlichen Wartungsarbeiten abgesehen) IPv4/IPv6 Glasfaser-Internet bei der DG hatte, habe ich jetzt auf einmal (nach den angekündigten Wartungsarbeiten heute/19.05.26 00:00-01:00) kein IPv6 mehr. Ich nutze ein UniFi Gateway Lite (UXG) und hatte vorher DHCPv6 auf dem WAN Interface angeschaltet (komischerweise entgegen der Beschreibung hier Cloud Gatway Ultra, Deutsche Glasfaser, Einstellungen WAN). Damit hat die Firewall auf eth1 ein ipv6/128 bekommen und ein /56er Präfix, dass ich per PD nach innen verteilt habe. Die default route kam trotzdem per RA, Stand gestern:

default via fe80::ff:fe01:102 dev eth1 table 201.eth1 proto ra metric 512 mtu 1500 pref medium

Seit heute (also seitdem es nach der Wartung wieder geht) bekomme ich zwar weiterhin per DHCPv6 Interface-Adresse und ein /56 Präfix (sogar jeweils die gleichen wir früher), aber mein gegenüber spricht kein RA mehr - ich bekomme keine default route.

manuell angetriggert über rdisc6 kommen nur timeouts.

Die UniFi konstruiert sich dann selbst eine Default route:

May 19 17:28:55 firewall01 ubios-udapi-server[2069]: dhcp-client: [RA-absent] Using SERVER address as gateway: fe80::ff:fe01:101 on eth1
May 19 17:28:55 firewall01 ubios-udapi-server[2069]: dhcp-client: Adding PD address: {
May 19 17:28:55 firewall01 ubios-udapi-server[2069]: dhcp-client:  "cidr": "2a00:6020:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/128",
May 19 17:28:55 firewall01 ubios-udapi-server[2069]: dhcp-client:  "origin": "dhcp",
May 19 17:28:55 firewall01 ubios-udapi-server[2069]: dhcp-client:  "type": "dynamic",
May 19 17:28:55 firewall01 ubios-udapi-server[2069]: dhcp-client:  "version": "v6"
May 19 17:28:55 firewall01 ubios-udapi-server[2069]: dhcp-client: } to dhcp address list on eth1
May 19 17:28:55 firewall01 ubios-udapi-server[2069]: WAN-Diag(eth1): res-interfaces: Adding new dynamic route ::/0 via fe80::ff:fe01:101/eth1 in table 201 (DHCP)

resultierend in

default via fe80::ff:fe01:101 dev eth1 table 201.eth1 proto dhcp metric 200 pref medium

Aber auch mit der so konstruierten Default Route funktioniert kein IPv6. Ausgehend sehe ich nur link-local Traffic (neighbor advertisement/neighbor solicitation, aber eben kein router advertisment) und natürlich meine ausgehenden IPv6 Verbindungsversuche auf die aber keine Antwort kommt. Auch ankommend (auf die benannten Adresse) kommt nichts.

Habe schon eine Störung aufgemacht, woraufhin mein ONT rebootet wurde (was überraschenderweise nichts geändert hat). Jetzt warte ich ja nur darauf, dass sie mir entweder was vom Kabel erzählen oder das es natürlich an meinem Router liegt...

Zitat von belegdol

Gelogen ist es vielleicht nicht, aber impliziert wird eine exklusive Leitung. Ich finde es einfach armselig mit welchen Methoden für Glasfaser geworben wird. Da muss man sich nicht wundern, wenn die Leute sich mit Bestellungen zurückhalten.

Ja so sehe ich das auch - es gibt genug gute Gründe für Glasfaser ohne solchen Quatsch zu erzählen.

Wow - das waren viele Antworten. Mir ging es nicht um ein konkretes Bandbreitenproblem (bin noch nicht mal angeschlossen) und schon gar nicht um Ende-zu-Ende Nutzbarkeit der Bandbreite im Internet (bis zu oder jenseits des Peerings) sondern einerseits um die Wahrscheinlichkeit des Auftretens ggü. Cable/DOCSIS (hier konnte ich bis jetzt nur herauslesen, dass es wegen dynamischer Zuteilung der TDM Slots flexibler ist, als die statische Kanalzuteilung im Cable) aber VOR ALLEM um die Vermarktung bzw. die getroffenen Aussagen. Denn dafür ist die Eintrittswahrscheinlichkeit sogar irrelevant. Ich kann doch nicht behaupten, der Vorteil von Glasfaser (in der konkrete Ausbauvariante GPON mit Split) gegenüber Cable/DOCSIS besteht darin, dass es KEIN Shared Medium ist, wenn es eben doch eins ist. Das ist nach meinem technischen Verständnis (und dem wurde hier glaube ich auch nicht widersprochen) einfach eine falsche Tatsachenbehauptung. Auf dieser Basis kann ich doch keine Verträge abschließen. (Was im Vertrag steht, sei mal dahin gestellt, der Verkäufer kann nicht etwas anderes Bewerben als tatsächlich angeboten wird bzw. konkrete [wissentliche?] Falschbehauptungen aufstellen.)

Und btw. bei uns wird mit GPON, nicht XGS-PON ausgebaut. Bei XGS-PON halte ich das Verhältnis selbst bei 1:64 (160Mbit) für vertretbarer als 1:32 bei GPON (80Mbit), denn damit bestünde wenigstens die theoretische Möglichkeit, dass bei größtenteils 100Mbit-Tarif-Nutzern jeder "seine" gebuchte Bandbreite bekommt (blödes Beispiel 54 x 100 Mbit, 5 x 300Mbit, 3 x 500Mbit und 2 x 1000 Mbit an einem Split ~ 10Gbit).

Die Glafaser-Anbieter (insbesondere die GF-only) bewerben ja die Glasfaser-Technik sehr aggressiv als technologisch überlegen und nicht den gleichen Beschränkungen wie xDSL oder Cable/DOCSIS unterworfen. Während ich da in der reinen Lehre (Glasfaser vs. Kupfer) durchaus mitgehe, stört mich, dass insbesondere die DG (auch andere?) aktiv damit wirbt, dass es sich bei den DG Anschlüssen eben im Gegensatz zu Cable/DOCSIS nicht um ein Shared Medium handelt, sondern jeder die volle Bandbreite hat. Nach meinem Verständnis wird doch aber beim Einsatz von Splittern massiv überbucht. Bei einem 1:32 Split bleiben von 2,5 Gbit Downstream gerade mal 80 MBit pro Teilnehmer. Das ist natürlich Worst-Case gerechnet und nicht alle Kunden nutzen die "großen" Tarife. Aber im Prinzip reichen doch schon 3-4 Nutzer mit 1Gbit-Tarif damit nicht jeder seine Anschlussleistung erhält oder habe ich da einen Denkfehler?

Irgendwo habe ich gelesenen, dass das bei TDM nicht so ins Gewicht fällt wie bei Cable/DOCSIS - aber warum nicht? Die Art des Multiplexing ändert doch nichts an der (massiven) Überbuchung der eigentlichen Leitungskapazität. Vielleicht tritt das Problem seltener auf, da die Slots besser/dynamischer verteilt sind, aber wenn besagte 3-4 Nutzer gleichzeitig einen GBit-Downstream wollen, werden sie ihn nicht bekommen können.

In der Praxis spielt das (noch - die Anwendungen die solche Bandbreiten brauchen werden kommen) eine untergeordnete Rolle, aber mich stört massiv, dass die DG es unterschlägt, dass es sich um ein Shared Medium handelt und selbst auf Nachfrage penetrant behauptet "es handele sich um eine eigene Faser und deswegen würde auch jedem Kunden die volle Bandbreite zur Verfügung stehen".