UDM-Pro und IPV6 an Stiegeler FTTH GF

Es gibt 56 Antworten in diesem Thema, welches 6.271 mal aufgerufen wurde. Der letzte Beitrag () ist von daimonion.

  • Hallo Leute.


    Nachdem ich nun bei meinem Anbieter (Stiegeler) endlich auch mit Glasfaser versorgt werden kann, möchte ich auch schauen dass die Verbindung via IPv6 erreichbar ist.

    Out-of-the-box bekomme ich mit der UDM-Pro (Console OS v3.1.15, Network-App v7.4.162) keine v6 Adresse zugewiesen.


    In den Wan Einstellungen habe ich v6 per DHCPv6 aktiviert:



    Nun möchte ich schauen was hier das Problem ist. Ich habe in einem anderen Thread schon mal einen Blogartikel gefunden, der mir ausreichend fundiert erschien als Vorlage und Netzwerkanalyse zu dienen:


    Teaching my UniFi UDM how to IPv6
    Adventures into IPv6, and getting it all working on a UniFI UDM
    david.coffee


    Ich denke nicht, dass dieser Artikel komplett passt, weil dort z.B. nichts hinsichtlich Rapid-Commit steht.

    Wie komme ich ausgerechnet auf Rapid Commit.

    Mein Schwager hängt mit seiner Fritzbox an genau dem selben Tropf und die Einstellungen dort sehen eben Rapid Commit vor.



    Nichtsdestotrotz habe ich mal ein wenig den Artikel durchgearbeitet und versucht nachzuvollziehen was da geht.


    Ich habe geschaut was so alles läuft:


    Code
    root@UDMProSchmesterle:~# ps aux |grep dhcp
    root     2485256  0.0  0.0   2132   536 ?        S    18:43   0:00 /usr/sbin/odhcp6c -e -v -s /usr/share/ubios-udapi-server/ubios-odhcp6c-script -D -P 62 ppp0
    root     2485440  0.0  0.0   4924   640 pts/0    S+   18:43   0:00 grep --color dhcp
    root@UDMProSchmesterle:~#

    Dann habe ich einfach mal versucht den odhcp6c manuell laufen zu lassen. Mit folgendem Ergebnis:


    Nun ja, zumindest ist die Meldung schon mal nicht so erfolgversprechend. Aber auch eine Spur, wenn ich mal so sagen darf.

    Ich hänge mit meinem GPON (Nokia-G010G-R) am Port9, dem ersten Wan Port 9.

    Was könnte ich denn machen, dass hier erst mal das Network "reachable" ist?

    Wie klappt das mit Rapid-commit bei der UDM-Pro?


    Meinen ISP habe ich schon mal angefragt welche IPv6 Einstellungen ich setzen muss. Mal schauen was die bringen.

    Ich hab auch schon eine tcpdump bei der Fritte meines Schwagers für das WAN Interface gemacht, aber ich glaube da habe ich nur die gesendet Nachrichten erwischt. Kann das sein? Bei Bedarf kann ich gerne einen Screenshot dieses Mitschnitts posten.


    Abschließend, würde ich mich freuen, wenn wir das hier gemeinsam irgendwie hinbekommen, denn das Internet ist hinsichtlich Stiegeler und UDM-Pro noch sehr leer.


    Danke schon mal im Voraus


    Grüße

    Daimonion


    Edit: Also die erste Erkenntnis die ich habe, wenn ich, wie in dem Artikel geschrieben steht dhcpv6 auf dem WAN1 (Port9) deaktiviere, dann ist v6 glaube ich komplett aus und das würde die network is unreachable meldungen erklären.

    Also alternative:


    Die Option -e leitet die logmessages nach stderr. Also hab ich mir gerade mal tail -f /var/log/error angeschaut während ich in der UI DHCPv6 aus- und kurz danach wieder angeschaltet habe..


    Code
    2023-08-30T19:51:30+02:00 UDMProSchmesterle odhcp6c[2605024]: Failed to send RS (Cannot assign requested address)
    2023-08-30T19:51:30+02:00 UDMProSchmesterle odhcp6c[2605024]: Failed to send SOLICIT message to ff02::1:2 (Network is unreachable)
    2023-08-30T19:51:31+02:00 UDMProSchmesterle ubios-udapi-server[1176]: res-interfaces: Failed to process internal request {"AFTR":"","DOMAINS":"","RA_ADDRESSES":"2a05:5800:302:4df:5160:f229:af59:85a1/64,3529,86329","RA_DNS":"2a05:5800:180:13::21 2a05:5800:180:17::21","RA_DOMAINS":"","RA_HOPLIMIT":"64","RA_MTU":"0","RA_REACHABLE":"0","RA_RETRANSMIT":"0","RA_ROUTES":"::/0,fe80::e681:84ff:fea0:6734,4429,512","RDNSS":"2a05:5800:180:13::21 2a05:5800:180:17::21","SIP_DOMAIN":"","SIP_IP":"","SNTP_IP":"","interface":"ppp0","script":"ubios-
    2023-08-30T19:51:31+02:00 UDMProSchmesterle ubios-udapi-server[1176]: res-interfaces: odhcp6c-script","state":"stopped"}: Unknown interface: ppp0
    2023-08-30T19:51:53+02:00 UDMProSchmesterle mca-ctrl[2616712]: mca-ctrl[2616712]: mca-monitor.mca_control_main(): service_json event fail, retry (30 sec left)
    2023-08-30T19:52:08+02:00 UDMProSchmesterle ubios-udapi-server[1176]: domain-resolver: Ares Socket (ppp0 5.83.185.94 0x001a0000) setsockopt SO_BINDTODEVICE failed with 'No such device' (19)
    2023-08-30T19:52:08+02:00 UDMProSchmesterle ubios-udapi-server[1176]: domain-resolver: Ares Socket (ppp0 5.83.xxx.94 0x001a0000) setsockopt SO_BINDTODEVICE failed with 'No such device' (19)
    2023-08-30T19:52:08+02:00 UDMProSchmesterle ubios-udapi-server[1176]: domain-resolver: Ares Socket (ppp0 5.83.xxx.94 0x001a0000) setsockopt SO_BINDTODEVICE failed with 'No such device' (19)
    2023-08-30T19:52:08+02:00 UDMProSchmesterle ubios-udapi-server[1176]: domain-resolver: Ares Socket (ppp0 5.83.xxx.94 0x001a0000) setsockopt SO_BINDTODEVICE failed with 'No such device' (19)

    2 Mal editiert, zuletzt von daimonion ()

  • Basics zuerst:

    DU must wissen was für ein Prefix dein Provider gedenkt dir zuzuweisen.


    Out-of-the-box bekomme ich mit der UDM-Pro (Console OS v3.1.15, Network-App v7.4.162) keine v6 Adresse zugewiesen.

    Das ppp0 wird auch keine bekommen. Unifi geht da einen seltsamen Weg. Es lässt sich vom Provider das Präfix geben

    und diesen wird dann den einzelnen VLANs verteilt. Jedes VLAN bekommt dabei ein /64

    (wobei ich nicht weis was passiert wenn es von Provider nur ein /64 gibt)

    Wenn du also im Default VLAN IP6 aktiviert hast siehst du auf dem br0 interface das erstmal eine IPV6.

    nichts hinsichtlich Rapid-Commit steht.

    Nun wird es widerlich....6rd is so eine Weiterentwicklung von der 6to4 Technik bei den wird das IPv6 durch ipv4 getunnelt.

    Der Provider Selber braucht dann keine eigne IPv6 Infrastruktur und kann sich das einfach bei einem IPv6 ISP einkaufen.

    Das ist gelinde gesagt dreck da du immer einen Endpoint hast der dich dann richtig ins Netz routet. Quasi so ne Art Proxy.


    Un nun die gute oder für dich schlechte Nachricht.. Unifi hat bisher keine rd6 Unterstützung....

  • Hi. Danke für deine Antwort

    DU must wissen was für ein Prefix dein Provider gedenkt dir zuzuweisen.

    Jup, Anfrage läuft. Ich hoffe die stellen sich nicht all zu blöd an. Bis dahin kann ich vielleicht mit einem Screenshot der Fritte dienen. (IP ist mittlerweile wieder neu vergeben. :winking_face: )



    Zum Thema Basics. Lese ich das richtig, dass der ISP hier einen 56er Präfix zur Verfügung stellt?


    Das ppp0 wird auch keine bekommen. Unifi geht da einen seltsamen Weg. Es lässt sich vom Provider das Präfix geben

    und diesen wird dann den einzelnen VLANs verteilt. Jedes VLAN bekommt dabei ein /64

    (wobei ich nicht weis was passiert wenn es von Provider nur ein /64 gibt)

    Wenn du also im Default VLAN IP6 aktiviert hast siehst du auf dem br0 interface das erstmal eine IPV6.

    Also ich hoffe/glaube ich habe verstanden was du meinst.

    Un nun die gute oder für dich schlechte Nachricht.. Unifi hat bisher keine rd6 Unterstützung....

    D.h. aktuell hab ich mit der UDM keine Chance eine v6 zu bekommen, wenn der ISP v6 mittels 6rd zur Verfügung stellt?

  • Lese ich das richtig, dass der ISP hier einen 56er Präfix zur Verfügung stellt?

    Ja ein /56 Prefix zum Delegieren... Das ist das was du haben willst.


    D.h. aktuell hab ich mit der UDM keine Chance eine v6 zu bekommen, wenn der ISP v6 mittels 6rd zur Verfügung stellt?

    Aktuell JA, IPv6 ist und bleibt scheinbar noch das ungeliebte Stiefkind bei UI.

    Also Wenn dem so ist. Laut Bild gibt es keine Öffentliche IP4 Adresse (IP aus 100.64.0.0/10)

    da würde ich mich fragen wie der Tunnel zum Endpunkt kommt.. aber nun wer weis was der Carrier da gebaut

    hat.


    Aber zum testen:

    Im Wan sollte das hier stehen:

    Also mit /56



    Wichtig ist nun das im LAN IPv6 auch an ist...

    Ob Slic oder DHCO ist fast egal und Geschmacksache.. aber AN mus es sein..

    sonst wirst du keien IP V6 sehen...


  • Okay, gerade nochmal ein wenig gelesen. Und ich glaube bei meinem Schwager ist die Inetverbindung auch noch nicht richtig konfiguriert (werde ich mir die Tage mal anschauen)

    Aber von vorne.


    Ich glaube mit 6rd hast du was verwechselt. Ich bin mir relativ sicher, dass mein ISP eine native v6 Verbindung zur Verfügung stellt. Ich glaube mit dem Haken, den man in der Fritzbox bei Rapid Commit setzen kann, ist eher ein vereinfachtes verfahren zur Adressvergabe gemeint, als ein 6rd Tunnel.


    vgl: https://www.juniper.net/docume…/dhcpv6-rapid-commit.html

    Zitat

    Server und Client verwenden dann einen Austausch mit zwei Nachrichten (Solicit and Reply), um Clients zu konfigurieren, anstatt den Standardaustausch mit vier Nachrichten (Solicit, Advertise, Request, and Reply). Der Austausch von Zwei-Nachrichten ermöglicht eine schnellere Client-Konfiguration und ist in Umgebungen von Vorteil, in denen Netzwerke stark belastet sind.

    Weiters kurz zu der v4 Adresse die in den Fritzbox screenshots zu sehen ist. Ja, das ist eine CGNAT Adresse. Stiegeler setzt diese auf v4 standardmäßig ein. Ein Anruf bei der Hotline und eine höfliche bitte, oder ein kompetenter Techniker beim Schalten der Faser, kann die Option für eine native v4-Adresse setzen. Dies hab ich für mich gemacht. Mein Schwager brauchst das nicht und dem hab ich das CGNAT gelassen. Daher lass dich bitte nicht mit der 100er Adresse verwirren.


    Den Prefix habe ich bei mir nun auch gesetzt, aber meine LAN Einstellungen sehen anders aus. Ich kann zwar ebenso Prefix Delegation machen, aber ich kann kein SLAAC einstellen (Wobei ich die Einstellung bei dir als sinnvoll erachte.)

    Bei mir sieht das so aus:



    Console ist eine UDM-Pro mit v3.1.15 mit Network App v7.4.162

  • ist eher ein vereinfachtes verfahren zur Adressvergabe gemeint, als ein 6rd Tunnel.

    Knallt mit den Kopf auf die Handfläche.. War wohl zu spät... :tired_face:

    "IPv6 Rapid Commit" und „IPv6 Rapid Deployment" klingen fast gleich.

    Du hast natührlich recht. Hab mich ja auch schon gewundert weil das „eigentlich“ mit einer CGNAT

    Adresse so nicht sein sollte.


    Nun aber dennoch :smiling_face:

    Wenn der Carrier auf "Rapid Commit“ besteht, es ohne also nicht geht (bei deinem Schwager könnte man das ja schnell zu testen)

    könnte ich mit vorstellen das UNIFI da auch Probleme mit hat.


    der odhcp6c scheint aus dem openwrt Project zu kommen.


    https://github.com/openwrt/odhcp6c/issues/71

    sagt das rapid commit nicht unterstützt wird...........

    das ungeliebte Stiefkind :pouting_face: halt..



    ber ich kann kein SLAAC einstellen (Wobei ich die Einstellung bei dir als sinnvoll erachte.)

    Kann sein das das erst mit der 7.5.X kommt (bin da auch auf EA Version) Sollte aber eh kein großen unterschied

    machen.

  • Knallt mit den Kopf auf die Handfläche.. War wohl zu spät... :tired_face:

    "IPv6 Rapid Commit" und „IPv6 Rapid Deployment" klingen fast gleich.

    Es geht den Menschen wie den Leuten. Kein Problem. Mir hats geholfen denn ich habe wieder etwas gelernt und verstanden. Von daher scheint es einen nutzen gehabt zu haben. :winking_face::grinning_squinting_face:



    Nun aber dennoch :smiling_face:

    Wenn der Carrier auf "Rapid Commit“ besteht, es ohne also nicht geht (bei deinem Schwager könnte man das ja schnell zu testen)

    könnte ich mit vorstellen das UNIFI da auch Probleme mit hat.

    Jap, das werde ich auch machen und werde auch nochmal versuchen ein paar tcpdumps von der Einwahl/Adressvergabe zu bekommen.

    Hab nur bis Sonntag keine Zeit dafür. Aber gut ich warte ja auch noch auf die Rückmeldung vom ISP.


    Kann sein das das erst mit der 7.5.X kommt (bin da auch auf EA Version) Sollte aber eh kein großen unterschied


    machen.

    Ja, das denke ich dass das so sein wird. Die ist ja schon RC. Von daher sollte das recht bald mal kommen. Ansonsten kann ich ja auch ins EA rein und mir die holen.


    Summasumarum:


    Lass uns mal auf die Infos vom Provider warten und auf meine Tests die ich bei meinem Schwager machen kann. Sobald ich mehr Infos habe, werde ich sie posten und dann kann man weiter schauen.

    Danke dir auf jeden Fall jetzt schon mal.

  • Erste Rückmeldung vom Provider.

    Der Prefix sollte auf /56 stehen, was wir hier mittlerweile auch schon herausgefunden haben.


    Gibt es eine Stelle in der UDM-Pro an der ich sehe was die v6 Einstellung dann macht?


    ifconfig für ?br0? ?eth9?

    /var/log/messages

    /var/log/ppp0

    ....

    ??


    Der Provider erwartet eine Rückmeldung ob es funktioniert hat, aber wenn ich das Ergebnis einer Änderung nicht sehe, stehe ich ein wenig blöd da. :winking_face:


    Grüße

    Daimonion

    Einmal editiert, zuletzt von daimonion ()

    • Hilfreich

    Das Ungeliebte stiefkind darf nicht wirklich mitspielen.


    /data/udapi-config/pd.leases


    Da stehen die IP und Präfixe für alle Konfigurierten interface drinne wenns was gibt.


    Da kann du aber auch mit ip a s br0 auch am interface sehen (ip address show br0 in kurz)

    also wenn du natürlich das default LAN eingeschaltet hast sonst dann halt für die vlan aka „brxx"


    Sonts habe ich auch eher nicht gefunden, wenns geht dann gehts Is ja auch nur einschalten und richten pfeif auswählen und

    halt beim VLAN einschalten.

  • Ich schau nachher gleich. Aktuell bin ich noch in der Firma und dessen Proxy ist ne Mimose. Editiere hier dann.


    Edit:


    das br0 hat aktuell nur die fe80 adresse und pd.leases ist leer.


    Ich vermute hier nun dass ich keinen dhcpv6 lease bekomme, weil die duid noch nicht stimmt.

    Das ist auch hier in dem Artikel besschrieben, den ich oben schon mal verlinkt hatte:

    Zitat

    So to summarize: This ISP is using fully native IPv6, the IPv6 prefix space is assigned through DHCPv6, and authentication happens through a DUID identifier that’s being used in all DHCPv6 requests.

    Teaching my UniFi UDM how to IPv6
    Adventures into IPv6, and getting it all working on a UniFI UDM
    david.coffee


    Ich werde das mal meinen ISP fragen.

    Einmal editiert, zuletzt von daimonion ()

  • Moin


    So, heute konnte ich nochmal die Verbindung der Fritte an einen Stiegeler GF Anschluss intensiver testen.


    Der Anschluss selbst kann natives v6 und Rapid Commit kann auch deaktiviert werden. Die Fritte bekommt auch dann eine v6 zugewiesen.


    Ich hab dann mal versucht den Datenverkehr an der WAN Schnittstelle zu capturen (mit dem Capture Interface der Fritte) aber da habe ich das Gefühl nur die Sendenachrichten erwischt zu haben und nicht den ganzen Verkehr (warum auch immer).

    Falls da jemand weiß warum, nehm ich jeden Tipp.


    Die Einstellungen in der Fritte hier nochmal kurz als Doku:



    Und dann habe ich mal die zweite Option aktiviert "Globale Adresse ausschließlich per DHCPv6 beziehen" aktiviert und da klappt eine Adressvergabe nicht. Es kommt keine v6 Verbindung zu stande.


    Und das ist ja scheinbar genau das was die UDM versucht. Warum klar wäre warum das nicht funktioniert.


    Ergo: Wie bekomme ich die UDM dazu ein Router Advertisement zu machen und dieses dann zu nutzen?

  • Moin.


    bin ich ein wenig weiter? Ich weiß es nicht... Aber vielleicht. Ich bräuchte aber eure Hilfe um das aktuelle Setup einzuordnen.


    Ich habe durch suchen folgenden Beitrag gefunden:


    https://community.ui.com/questions/Getting-IPv6-WAN-to-work-UDM/a049f237-ddf7-434d-8b88-5477c1b0ab80#answer/b9eb6a67-e23b-46b5-9bf5-b3e00559f1c0


    Dort wird, soweit ich das verstehe, der ppp Schnittstelle gesagt, dass ein Router Advertisement durchgeführt werden soll.


    Mit dieser Einstellung bei mir und dem poff bekomme ich folgenden Log in /var/logmessages


    Es scheint nun, dass ich hier das erste mal eine v6 Adresse sehe. Wie ich das interpretiere wird die aber mit einer unkown origin erkannt und wieder entfernt.


    Könnt ihr mit der Info mehr anfangen? Müsste ich evtl. noch was anders konfigurieren, das die Adresse dauerhaft bleibt?

  • Eine Problematik ist das der Forums Beitrag 3 Jahre alt ist. Da war die UDM noch auf Version 1.x und nicht auf 3.x wie heute.

    Auch die Network app selber ist gewachsen.


    Die IP die ich sehe ist "2a05:5800:302:a461:5c1f:1909:5e93:cc1c/64“ das ein /64 und eher das was für das PPPoE interface ist.

    Das ist Unifi aber egal und will es nicht und benutzt es auch nicht. Du brauchst das /56 Präfix das auch über das Script

    von unifi dann ins system verdaut wird.


    Schwierig...das Stiefkind ist nun wirklich bockig.

  • Ich hab einen tcpdump der ppp0 Schnittstelle gemacht:



    Kann damit jemand was anfangen?


    Edit:


    Heute morgen habe ich nochmal die Einstellungen aus meinem letzten Post in /etc/ppp/options und in /etc/sysctl.d/03-ubnt-udapi-server-enable-ipv6-forwarding.conf rückgängig gemacht.

    Der tcpdump hat sich dadurch nicht verändert. Scheint das der dhcp die Messages verursacht, aber mit der Antwort nicht klar kommt.

    Einmal editiert, zuletzt von daimonion ()

  • Moin.


    Nachdem das ConsoleOS und die Network App aktualisiert wurden, wurde ja von mir schon der tcpdump gepostet.

    Nun habe ich heute mal versucht das ganze in der Shell zu bekommen und ja, zumindest kann ich das mal als Meldung von odhcp6c sehen, was im tcpdump steht.


    Würde mich freuen, wenn ihr mir bei der Interpretation helft. Gerade auch was die Information: "Server returned IA_PD status 'No Address Available (No addresses have been assigned)'"

    angeht.


    Die Antwort kommt hier vom ISP. Will der nicht, oder kann der nicht, weil ich ihm was falsches sage?

  • Mhhh..


    also wenn ich"root@Lisa:~# /usr/sbin/odhcp6c -e -v -s /usr/share/ubios-udapi-server/ubios-odhcp6c-script -D -P 0 ppp0"

    einfach so starte also mit IP dann bekomme ich sowas:



    Aber mit dem Prefix den ich schon habe. Das ist also eher ein „habe ich will ich nochmal“. Mein provider sagt dann

    wohl OK. (Siehe das T1 und T2 Timer bei mir viel höher sind).


    Forciere ich ein reconnect (Stecker ziehen) passiert erstmal nix mehr und bekomme trotzdem ne neue IP WEIL:

    Der läuft zweimal.

    Code
    root@Lisa:~# ps -ef | grep [o]dhc
    root 1668580 1667483 0 19:03 pts/0 00:00:00 /usr/sbin/odhcp6c -e -v -s /usr/share/ubios-udapi-server/ubios-odhcp6c-script -D -P 0 ppp0
    root 1676163 1332 0 19:07 ? 00:00:00 /usr/sbin/odhcp6c -e -v -s /usr/share/ubios-udapi-server/ubios-odhcp6c-script -D -P 0 ppp0

    der Unifi-Server gibt da so schnell die Kontrolle nicht ab bei der Bereitstellung und Überwachung de eignen Dienste...

  • Na ja deine UDM wird sich de IP nicht ausdenken die kommt als Vorschlag vom Carrier wird dann bestätigt und

    der Carrier sendet sie nochmal zum eigentlichen konfigurieren.


    ODER deine Büchse sendet weil du den DHCP Zweimals startet als „hier will ich behalten“ und der Carrier sagt NÖ

    weil das Lease schon abgelaufen ist...


    nachtrag: Warum versuchst du eigentlich den odhcp nochmal zu starten ?

    Wehen den Logs ? der Kram Reporter zu aufrufenden..

    udapi-server wird wiederum von system Kontrolliert...


    Sprich:


    journalctl | grep odhcp


    Da logs :smiling_face:

    Einmal editiert, zuletzt von gierig ()

  • Den tcpdump, den ich weiter oben angehangen habe, und der das gleiche Verhalten zeigt wie der zweite Start des odhcp zeigt ja, das der Provider diese Antwort auch sendet wenn die Konfig via der UI so eingestellt wurde.


    Das ich den odhcp ein zweites mal gestartet hab, war nur dem geschuldet, dass ich für den aus der UI gestarteten Prozess halt nicht gesehen habe was der so macht.

    Mit deinem journalctl | grep odhcp werde ich das nachher mal versuchen und schauen was der erste Prozess so sagt.


    Ich melde mich mit dem Ergebnis.