• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

[SOLVED] T-Com VDSL IPv6 -> Log wird geflutet

Scheduled Pinned Locked Moved Deutsch
25 Posts 7 Posters 5.3k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • ?
    A Former User
    last edited by Dec 3, 2016, 8:23 AM

    Selbes Problem hier. Habe auch bereits eine Neuinstallation gemacht und das Problem bleibt. In Verbindung mit dem LAN Interface welches die IPV6 Adresse des WAN Interfaces trackt und DHCPv6 wird das System auch instabil und in regelmäßigen Abständen reagiert es nicht mehr. Anfangs habe ich die Freezer und Kernel Panics auf einen Hardwarefehler geschoben, inzwischen habe ich aber das Gerät ausgetauscht und habe die gleichen Symptome wieder sobald ich IPv6 wie oben beschrieben aktiviere.

    Hab jetzt vorübergehend IPv6 ausgeschaltet.

    1 Reply Last reply Reply Quote 0
    • S
      stickybit
      last edited by Dec 4, 2016, 6:51 PM

      I opened a ticket: https://redmine.pfsense.org/issues/6981

      1 Reply Last reply Reply Quote 0
      • S
        stickybit
        last edited by Dec 11, 2016, 2:08 PM

        Version: 2.3.2-p1

        Ich wollte gerade die Beta Versionen testen und schalte IPv6 nochmal probehalber unter der aktuell laufenden Version ein und siehr da … ES GEHT!^^
        Keine sekündlichen Logeinträge mehr.

        How-to:
        https://moerbst.wordpress.com/2016/07/31/ipv6mit-pfsense-an-dsl-der-telekom/

        1 Reply Last reply Reply Quote 0
        • A
          arnog
          last edited by Dec 19, 2016, 9:23 AM

          Bei mir gab es leider keine Besserung. Auch nach einem Neustart habe ich weiterhin die Probleme. Ich warte mal auf die 2.3.3, in dem Ticket, das dazu aufgemacht wurde, steht ja, dass es viele Änderungen an dhcp6c gegeben hat für diese Version.

          1 Reply Last reply Reply Quote 0
          • J
            JeGr LAYER 8 Moderator
            last edited by Dec 21, 2016, 8:24 PM

            Dazu gab es auch ein Ticket @arnog: https://redmine.pfsense.org/issues/6981
            Konntest du ggf. was durch den Watchdog erreichen wie die anderen im Ticketkommentar?

            Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

            If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

            1 Reply Last reply Reply Quote 0
            • A
              arnog
              last edited by Dec 22, 2016, 2:49 PM

              Das Ticket hatte ich schon gesehen, ich bin aber nicht sicher, ob der Watchdog wirklich das Problem ist. Ich habe mal ein paar logs an das Ticket angehängt. Was mich in den logs stutzig macht, ist die Zeile "reset timer for pppoe0 to 0.775890".

              1 Reply Last reply Reply Quote 0
              • J
                JeGr LAYER 8 Moderator
                last edited by Dec 22, 2016, 2:56 PM

                OK wollte nur sicher gehen, dass das nicht vielleicht schon gelöst wurde :) Ich kann leider nicht mitreden, wir haben hier kein entsprechendes PPPoE Testszenario :/

                Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                1 Reply Last reply Reply Quote 0
                • L
                  lodur
                  last edited by Dec 23, 2016, 2:26 PM

                  Habe gestern auch nochmal einen Versuch gestartet (v2.3.2p1), ohne Erfolg. Sobald IPv6 dazu geschaltet ist, sind die Probleme wieder da. Werde das Ticket im Auge behalten und abwarten, wie es bei dem nächsten Release aussieht.

                  1 Reply Last reply Reply Quote 0
                  • A
                    arnog
                    last edited by Jan 2, 2017, 9:16 AM

                    Für mich hat sich das Problem jetzt dadurch gelöst, dass ich bei "Request only an IPv6 prefix" einen Haken gesetzt habe. Es funktioniert anscheinend bei der Telekom im BNG so, dass die Adresse für das WAN-Interface per Router Advertisement vergeben wird. Nur das zu delegierende /56er Prefix wird per DHPCv6 verteilt.

                    Ich bin mir nicht sicher, meine mich aber zu erinnern, dass im "alten" Telekom-Netz auch die Adresse für das WAN-Interface per DHCPv6 vergeben wurde und deshalb der Haken da nicht gesetzt werden musste.

                    1 Reply Last reply Reply Quote 0
                    • L
                      lodur
                      last edited by Jan 4, 2017, 9:01 AM

                      Hat bei mir auch geholfen. Danke für den Tipp!

                      1 Reply Last reply Reply Quote 0
                      • A
                        a_wein
                        last edited by Apr 11, 2017, 1:38 PM

                        Ich habe das gleiche Problem an einem neuen VDSL100-Anschluss der Telekom, Vigor130 und APU2.

                        Die Fehler und Verbindungsabbrüche wurden zwar seltener seitdem ich "Only request an IPv6 prefix" an habe, scheint aber das Problem nicht vollständig zu beheben.

                        Ich würde mich freuen wenn jemand von euch noch einen Tipp hat oder zumindest das Problem reproduzieren kann.
                        Einziger Workaround der funktioniert ist IPv6 zu deaktivieren - das ist aber ja keine Lösung…

                        Aktuelle Einstellungen:

                        • IPv6 Configuration Type: DHCP6

                        • Request a IPv6 prefix/information through the IPv4 connectivity link

                        • Only request an IPv6 prefix, do not request an IPv6 address

                        • DHCPv6 Prefix Delegation size: /56

                        • Send IPv6 prefix hint

                        1 Reply Last reply Reply Quote 0
                        • A
                          arnog
                          last edited by Apr 11, 2017, 3:38 PM

                          Bei mir funktioniert es mit diesen Einstellungen weiterhin ohne Probleme. Wie äußert sich das denn bei dir?

                          1 Reply Last reply Reply Quote 0
                          • A
                            a_wein
                            last edited by Apr 12, 2017, 9:45 AM

                            
                            Apr 12 11:40:35	dhcp6c	12324	IA timeout for PD-0, state=ACTIVE
                            Apr 12 11:40:35	dhcp6c	12324	reset a timer on pppoe0, state=RENEW, timeo=0, retrans=10793
                            Apr 12 11:40:35	dhcp6c	12324	Sending Renew
                            
                            

                            Das passiert dann ungefähr alle 15 Minuten…

                            1 Reply Last reply Reply Quote 0
                            • A
                              arnog
                              last edited by Apr 12, 2017, 3:50 PM

                              Das habe ich auch und es erzeugt bei mir keine Probleme.

                              Wenn ich das richtig verstanden habe, ist das auch völlig in Ordnung, dass pfSense das Lease für den delegierten Prefix erneuert. Bei IPv6 gibt es keine Lease-Time im eigentlichen Sinne mehr, sondern bei der Prefix Delegation werden dem Client zwei Zeiten T1 und T2 mitgegeben.

                              T1 ist die Zeit, nach der der Client ein RENEW für die prefix delegation anfragen sollte.
                              Falls auf die RENEW-Anfrage keine Antwort kommt, ist T2 die Zeit, nach der er eine REBIND-Anfrage schicken sollte.

                              T1 wird normalerweise vom DHCP-Server auf 0,5 * preferred lifetime der Prefix Delegation gesetzt. T2 auf 0,8 * preferred lifetime. Sieht also so aus, als ob die preferred lifetime für prefix delegation bei der Telekom auf 30 Minuten gesetzt ist und T1 auf 15 Minuten dann.

                              1 Reply Last reply Reply Quote 0
                              • A
                                a_wein
                                last edited by Apr 16, 2017, 11:45 AM

                                Grundsätzlich stimme ich dir zu - so verstehe ich das auch. Allerdings wird dabei nicht nur die DHCPv6 Lease erneuert sondern auch die IPv4 Verbindung beeinflusst. So weit ich das sehe wird diese zwar nicht getrennt aber die Default-Route verändert, so dass Clients im LAN Verbindungsprobleme haben (warum verstehe ich noch nicht).

                                
                                Apr 16 08:11:42	php-fpm	63044	/rc.newwanipv6: rc.newwanipv6: Info: starting on pppoe0.
                                Apr 16 08:11:42	php-fpm	63044	/rc.newwanipv6: rc.newwanipv6: on (IP address: 2003:d1:a3bf:1975:20d:b9ff:fe40:7fdd) (interface: wan) (real interface: pppoe0).
                                Apr 16 08:11:54	php-fpm	63044	/rc.newwanipv6: ROUTING: setting default route to 62.155.243.156
                                Apr 16 08:11:54	php-fpm	63044	/rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::143:143:3e9b:f39c%pppoe0
                                Apr 16 08:11:54	php-fpm	63044	/rc.newwanipv6: The command '/sbin/route change -inet6 default 'fe80::143:143:3e9b:f39c%pppoe0'' returned exit code '1', the output was 'route: writing to routing socket: Network is unreachable route: writing to routing socket: Network is unreachable change net default: gateway fe80::143:143:3e9b:f39c%pppoe0 fib 0: Network is unreachable'
                                Apr 16 08:11:54	php-fpm	63044	/rc.newwanipv6: Removing static route for monitor 8.8.8.8 and adding a new route through 62.155.243.156
                                Apr 16 08:11:54	php-fpm	63044	/rc.newwanipv6: Removing static route for monitor 2001:4860:4860::8888 and adding a new route through fe80::143:143:3e9b:f39c%pppoe0
                                Apr 16 08:11:54	check_reload_status		Reloading filter
                                
                                
                                1 Reply Last reply Reply Quote 0
                                • A
                                  arnog
                                  last edited by Apr 16, 2017, 5:56 PM

                                  Eigentlich sollte es da keine Unterbrechung geben. Die Zeile im Log ist etwas irreführend, weil die Route gar nicht neu gesetzt wird, falls sie schon existiert. pfSense versucht erst, die Route hinzuzufügen. Falls das scheitert (weil die Route schon existiert), versucht pfSense die bestehende Route zu ändern. Das sollte aber bei gleichen Settings keine Auswirkung haben.

                                  Apr 16 08:11:54	php-fpm	63044	/rc.newwanipv6: ROUTING: setting default route to 62.155.243.156
                                  

                                  Siehe dort:

                                  https://github.com/pfsense/pfsense/blob/79255a305e711634a1d0a0ba4dea115e2332bd61/src/etc/inc/system.inc#L733
                                  https://github.com/pfsense/pfsense/blob/f0875a7e6af8862ddd71b91b52194a96ff385d3b/src/etc/inc/util.inc#L2399

                                  Einzige Unterschied zu meinem Log ist, dass bei mir die Zeile mit "Network unreachable" nicht vorhanden ist. Kann es da evtl. zu Problemen kommen?

                                  1 Reply Last reply Reply Quote 0
                                  • P
                                    pfadmin
                                    last edited by Apr 19, 2017, 7:48 AM

                                    Der Thread wurde vom TO als Solved gekennzeichnet. Kommt selten vor, ist aber so….

                                    1 Reply Last reply Reply Quote 0
                                    • First post
                                      Last post
                                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                                      This community forum collects and processes your personal information.
                                      consent.not_received