![]() ![]() ![]() |
|
I'm not even using a custom config, mine is set in the controller software but it failed last night and hadn't come back this morning.
Aredwood: Maybe I need to post my config in this thread. As my IPv6 is still working just fine. Even though it is just based on Michaelmurfy's Edgerouter thread.
Unless I have somehow got a unique profile at 2degrees. Although I doubt that would be the case.
I'm interested in what version of the firmware you're running - I'm happy to downgrade if an older version is more stable.
Aredwood: Maybe I need to post my config in this thread. As my IPv6 is still working just fine. Even though it is just based on Michaelmurfy's Edgerouter thread.
Unless I have somehow got a unique profile at 2degrees. Although I doubt that would be the case.
My thoughts exactly, my config is very generic, and based off of the guides config too, with zero IPv6 issues since the ONT upgrades.
I'm running 1.10.7 FYI.
Referral Links:
Quic - Use code R536299EPGOCN at checkout for free setup
Contact Energy - Use code FRTQDXB for $100 credit
evilonenz:
Aredwood: Maybe I need to post my config in this thread. As my IPv6 is still working just fine. Even though it is just based on Michaelmurfy's Edgerouter thread.
Unless I have somehow got a unique profile at 2degrees. Although I doubt that would be the case.
My thoughts exactly, my config is very generic, and based off of the guides config too, with zero IPv6 issues since the ONT upgrades.
I'm running 1.10.7 FYI.
Hi All,
Sounds like a plan, let's see where you get to. If necessary after this, we can grab some packet captures and escalate to Chorus, however I need some solid proof/evidence there is any issue with the Chorus firmware since the upgrades, if we identify an issue, there wont be a quick fix to this based on recent history.
Nick.
https://nick.mackechnie.co.nz | NZ ISP latency monitoring - https://smokeping.thenet.gen.nz
BTW I'm not on Fibre, but VDSL and getting the IPv6 drops.
Benoire:
BTW I'm not on Fibre, but VDSL and getting the IPv6 drops.
Let's isolate you :-) Can you call please into Customer Care and log a ticket (0800 022 022).
Nick.
https://nick.mackechnie.co.nz | NZ ISP latency monitoring - https://smokeping.thenet.gen.nz
NickMack:
evilonenz:
Aredwood: Maybe I need to post my config in this thread. As my IPv6 is still working just fine. Even though it is just based on Michaelmurfy's Edgerouter thread.
Unless I have somehow got a unique profile at 2degrees. Although I doubt that would be the case.
My thoughts exactly, my config is very generic, and based off of the guides config too, with zero IPv6 issues since the ONT upgrades.
I'm running 1.10.7 FYI.
Hi All,
Sounds like a plan, let's see where you get to. If necessary after this, we can grab some packet captures and escalate to Chorus, however I need some solid proof/evidence there is any issue with the Chorus firmware since the upgrades, if we identify an issue, there wont be a quick fix to this based on recent history.
Nick.
Sounds like a plan, must be frustrating for the people involved! I'll get a copy of my configuration up shortly.
Referral Links:
Quic - Use code R536299EPGOCN at checkout for free setup
Contact Energy - Use code FRTQDXB for $100 credit
Copy of my config here: https://omg.geek.nz/misc/router.txt
Hopefully helps out.
Referral Links:
Quic - Use code R536299EPGOCN at checkout for free setup
Contact Energy - Use code FRTQDXB for $100 credit
evilonenz:
Copy of my config here: https://omg.geek.nz/misc/router.txt
Hopefully helps out.
Thanks for posting that - my config is almost identical (I didn't have "dup-addr-detect-transmits 1" and IPv6 pppoe offload set, and have an IPv6 SSH rule but is otherwise the same), I've tweaked mine to be the same as yours where it differed. I'm also on firmware 1.10.7
It's currently working over IPv6 (after making those two changes) so will see if it stays that way.
Cheers,
Andrew
fe31nz:
vulcannz:
I restarted my box, this did not fix the issue. I changed the WAN IPv6 interface from static to DHCPv6, this then fixed the connection. Then I changed it back to Static and connection stays up.
Note this still happens when the WAN interface is set to DHCPv6. Could it be related to RA timings/expiration's?
Since the latest update to the Junipers you are connecting to, you will not get an IPv6 connection until you have done a DHCPv6 request to the Juniper. I previously had my ERL set up with my static IPv6 addresses, and when the new firmware was installed, I lost the IPv6 connection. To restore it, I kept the static addresses I am using, but also added some config to get the ERL to request a DHCPv6 delegation. The new config does nothing with the delegated prefix - it just throws it away. But until it is requested, the Juniper now refuses to route IPv6 packets, even if you have a static IPv6 assignment. My guess is that every time the PPPoE connection needs to be reestablished, you will need to request a DHCPv6 delegation.
This makes sense. But I don't think it is to do with establishing the PPPoE connection, I believe it is the IP address valid lifetime expiring. I can do DHCPv6 but as the DHCPv6 service doesn't assign a global IP and gateway the box (sonicwall) doesn't assign a global IP automagically itself (which the Fritz does). It still works as traffic is routed over the LL address anyway, but I lose some capability (like logical probe monitoring).
Next step is to figure out if the DHCPv6 (ignoring the global IP issue) is stable. I'm capturing DHCPv6 packets, is there any point in grabbing RAs as well?
@evilonenz @llama233 That is the same configuration I have also. I hardly have any problems (can count 2 since this thread started). No biggie really.
Michael Murphy | https://murfy.nz
Referral Links: Quic Broadband (use R122101E7CV7Q for free setup)
Are you happy with what you get from Geekzone? Please consider supporting us by subscribing.
Opinions are my own and not the views of my employer.
vulcannz:
fe31nz:
vulcannz:
I restarted my box, this did not fix the issue. I changed the WAN IPv6 interface from static to DHCPv6, this then fixed the connection. Then I changed it back to Static and connection stays up.
Note this still happens when the WAN interface is set to DHCPv6. Could it be related to RA timings/expiration's?
Since the latest update to the Junipers you are connecting to, you will not get an IPv6 connection until you have done a DHCPv6 request to the Juniper. I previously had my ERL set up with my static IPv6 addresses, and when the new firmware was installed, I lost the IPv6 connection. To restore it, I kept the static addresses I am using, but also added some config to get the ERL to request a DHCPv6 delegation. The new config does nothing with the delegated prefix - it just throws it away. But until it is requested, the Juniper now refuses to route IPv6 packets, even if you have a static IPv6 assignment. My guess is that every time the PPPoE connection needs to be reestablished, you will need to request a DHCPv6 delegation.
This makes sense. But I don't think it is to do with establishing the PPPoE connection, I believe it is the IP address valid lifetime expiring. I can do DHCPv6 but as the DHCPv6 service doesn't assign a global IP and gateway the box (sonicwall) doesn't assign a global IP automagically itself (which the Fritz does). It still works as traffic is routed over the LL address anyway, but I lose some capability (like logical probe monitoring).
Next step is to figure out if the DHCPv6 (ignoring the global IP issue) is stable. I'm capturing DHCPv6 packets, is there any point in grabbing RAs as well?
As I said, I am using static IPv6 addreses, including on my WAN port. My ERL is just doing the DHCPv6 request and discarding the result. I am guessing that when the DHCPv6 delegation expires, the Juniper will stop routing IPv6 packets from you. So I would suggest just putting in a DHCPv6 setup that ignores the resulting delegated prefix and see if that fixes your problem. The code that handles the DHCPv6 delegation in your router should automatically send a further request when the delegation gets old enough, and prevent it from expiring.
vulcannz:
fe31nz:
vulcannz:
I restarted my box, this did not fix the issue. I changed the WAN IPv6 interface from static to DHCPv6, this then fixed the connection. Then I changed it back to Static and connection stays up.
Note this still happens when the WAN interface is set to DHCPv6. Could it be related to RA timings/expiration's?
Since the latest update to the Junipers you are connecting to, you will not get an IPv6 connection until you have done a DHCPv6 request to the Juniper. I previously had my ERL set up with my static IPv6 addresses, and when the new firmware was installed, I lost the IPv6 connection. To restore it, I kept the static addresses I am using, but also added some config to get the ERL to request a DHCPv6 delegation. The new config does nothing with the delegated prefix - it just throws it away. But until it is requested, the Juniper now refuses to route IPv6 packets, even if you have a static IPv6 assignment. My guess is that every time the PPPoE connection needs to be reestablished, you will need to request a DHCPv6 delegation.
This makes sense. But I don't think it is to do with establishing the PPPoE connection, I believe it is the IP address valid lifetime expiring. I can do DHCPv6 but as the DHCPv6 service doesn't assign a global IP and gateway the box (sonicwall) doesn't assign a global IP automagically itself (which the Fritz does). It still works as traffic is routed over the LL address anyway, but I lose some capability (like logical probe monitoring).
Next step is to figure out if the DHCPv6 (ignoring the global IP issue) is stable. I'm capturing DHCPv6 packets, is there any point in grabbing RAs as well?
That matches what I've seen on my Mikrotik too. I've also just set up static assignments and don't use the delegated prefix for anything.
|
![]() ![]() ![]() |