Thanks 2degrees.

Forums › 2degrees (including Slingshot, Orcon, Flip, Stuff Fibre, MyRepublic, 2talk and Vocus) › Thanks 2degrees.

Aredwood

3885 posts

Uber Geek

#239951 13-Aug-2018 00:20

My connection dropped for about 5min around midnight. And when it came back online, IPv6 started working.

Background- I use an Edge router lite. Have done so for practically the whole time I have had fibre 4+ years, originally with Snap, then 2deg. Around 6 months or so ago, I figured it is about time I got IPv6 working. But I couldn't get it working, and gave up. Assuming that I had made a configuration mistake with the Edge router.

Happy as this means that I actually did get my configuration correct. Although now I need to test that I have some working IPv6 firewall rules in place.

Batman

Mad Scientist
29766 posts

Uber Geek

Trusted

Lifetime subscriber

#2072303 13-Aug-2018 06:49

It's that official or just a "glitch"?

gregb

51 posts

Master Geek

#2072318 13-Aug-2018 07:29

I have had IPv6 running for many years (since Dec 2003). I recently (year or two) cut over to using native snap/2degrees IPv6 support. It has worked ok. Friday the 3rd August at 5:50am after a PPPoE restart from the remote end the IPv6 support broke. I've tried ringing the support line (most days), but I'm not getting any information from them (they are working on it, and there are other customers with the same issue).

My configuration is pfSense, 1500 mtu, static IPv4 and static IPv6, router setup to configure via DHCP6 (even though I ignore the prefix due to the static address). I can see the prefix given by DHCP6 is dynamic.

The best guess I have is that this issues relates to which BNG your PPPoE session is terminted on. I am on 'SNAP-08' (chch/enable). I know someone else on another BNG that works just fine with similar configuration (they are doing SLAAC for IPv6 configuration).

My understanding of what is provided by the IPv6 support is: A /56 is allocated. The first address is given to the BNG. The first /64 from the allocation is given to the PPPoE link (I give the second address to my access router). As a simple rule a /57 is now routable to the inside network (i.e. the top half of the allocation). I really don't understand the engineering decision as to why some of the allocation was used in the point to point link. Downsizing from a /48 to a /57 was inconvenient.

sidefx

3712 posts

Uber Geek

Trusted

#2072384 13-Aug-2018 08:31

Hmm, oh yeah mines back on ipv6 too. Interesting - pretty sure I turned it off waaay back (probably snap days) because there were various issues at the time. Not sure if it came back last night or a while back when I renewed my contract and got a new fritzbox. Pretty sure it was recent as I don't recall noticing the geekzone ipv6 logo for quite a while.

(Also had the brief outage last night - assumed it was chorus related as there were mentions of others on other ISPs having outages through the day and evening too?)

"I was born not knowing and have had only a little time to change that here and there." | Octopus Energy | Sharesies
- Richard Feynman

NickMack

962 posts

Ultimate Geek

Trusted

Lifetime subscriber

#2072473 13-Aug-2018 09:21

Hi All,

As part of our upgrades to 100gb backhaul across the network, the addition of new 100gb line cards etc. we've been testing new versions of Junos for our Juniper MX platform to take advantage of these new features and functionality. Now that this testing is complete, we are working through upgrading firmware on our PE/P nodes across the network. There are a bunch of them so it will take some time, we've completed a number already and we have a schedule we are working through. There is some change in behavior introduced in the new version of Junos which enables us to work around some of the issues we've previously seen before, there is also planned upgrade by Chorus which needs to be done due for a bug on the ONT's - https://www.geekzone.co.nz/forums.asp?forumid=85&topicid=239919 This is scheduled for upgrade beginning mid this month (any time now) https://sp.chorus.co.nz/product-update/oltont-software-upgrade-starting-mid-august. Great we've managed to work around some of the IPv6 issues :-)

Nick.

https://nick.mackechnie.co.nz | NZ ISP latency monitoring - https://smokeping.thenet.gen.nz

gregb

51 posts

Master Geek

#2072503 13-Aug-2018 10:01

Nick thanks for the update. My issues with IPv6 are new, not related to chorus (I'm on enable) and I assume the equipment is in the Chch DC (so the easiest to upgrade). I'm up for a workaround, but I'm not getting any visibility of what the issue is.

NickMack

962 posts

Ultimate Geek

Trusted

Lifetime subscriber

#2072519 13-Aug-2018 10:17

Hi Greg - PM me your details as the BNG where Christchurch customers terminate has already been upgraded.

Nick.

https://nick.mackechnie.co.nz | NZ ISP latency monitoring - https://smokeping.thenet.gen.nz

NickMack

962 posts

Ultimate Geek

Trusted

Lifetime subscriber

#2072870 13-Aug-2018 17:09

NickMack:

Hi All,

As part of our upgrades to 100gb backhaul across the network, the addition of new 100gb line cards etc. we've been testing new versions of Junos for our Juniper MX platform to take advantage of these new features and functionality. Now that this testing is complete, we are working through upgrading firmware on our PE/P nodes across the network. There are a bunch of them so it will take some time, we've completed a number already and we have a schedule we are working through. There is some change in behavior introduced in the new version of Junos which enables us to work around some of the issues we've previously seen before, there is also planned upgrade by Chorus which needs to be done due for a bug on the ONT's - https://www.geekzone.co.nz/forums.asp?forumid=85&topicid=239919 This is scheduled for upgrade beginning mid this month (any time now) https://sp.chorus.co.nz/product-update/oltont-software-upgrade-starting-mid-august. Great we've managed to work around some of the IPv6 issues :-)

Nick.

Update - I've had some of our team investigate this further today, we've made a slight change to the way we handle IPV6 allocations as detailed in the last paragraph.

At 2degrees we use DHCPv6 prefix delegation for static IPv6 subscribers using our RADIUS server to inform the BNG of the delegated prefix to use in its DHCPv6 advertisement.

The older version of BNG code required that subscriber static IPv6 be setup in a certain way to function, where the delegated and framed IPv6 attributes from RADIUS where set to the same value. This was required to force the BNG to install the subscriber IPv6 delegation into the BNGs forwarding table. As was mentioned by @GregB, this did mean that we used some of the static range for the point-to-point link between the BNG and CPE; this implementation is no longer supported on the newer version of code from Juniper and we’ve made changes to our RADIUS policy to support the new code.

The workaround implemented previously to support BNGs running both versions of code was to still advertise both attributes but change the values sent in the reply to the BNG. This is supported on BNGs running newer code but wasn’t necessary for subscriber IPv6 to function, where only the delegated attributed is needed. Looking at our workaround again in the lab and on production it seems that it’s not consistent (Depending on CPE/firmware etc.) what delegation the CPE uses in its DHCPv6 lease. To resolve this specific issue we’ve applied some changes to further define the radius attributes per software version on the BNG, so those BNGs running an older release of code will revert to the old way, and BNGs running newer versions of code will only use the delegated IPv6 prefix attribute.

Nick

https://nick.mackechnie.co.nz | NZ ISP latency monitoring - https://smokeping.thenet.gen.nz