Voyager fibre IPv6 on ERL or pfSense. Anyone using this combination?

Forums › Voyager › Voyager fibre IPv6 on ERL or pfSense. Anyone using this combination?

1 | 2 | 3

3885 posts

Uber Geek
+1 received by user: 1749

#2075777 19-Aug-2018 14:52

SirHumphreyAppleby:
Aredwood:Check your firewall settings. It might be blocking ICMP packet too large notification packets.

I'm not sure how the system detects if large MTU (RFC4638) support is available on the WAN, but the documentation for pfSense indicates it falls back to a lower value if not supported.

Setting the MTU to 1500 for PPPoE correctly bumps the values up to 1508 for the Ethernet and VLAN interfaces (em driver), but the MTU remains fixed at 1492, suggesting there isn't end-to-end support. If that's the case, that may explain why the ERL misbehaves.

@Taubin... I'd not risk rebooting, just in case. Back in the early days with Bigpipe, I did once in a while get an address via PPPoE (this is why I was looking in to issues such as race conditions and the order interfaces were brought up in pfSense). I didn't get 'reliable' IPv6 until I switched to IPoE, and then suddenly, it was gone.

The system detects large packet support by just sending out packets as normal. In IPv6, if a packet is too large for a router to forward onwards to the destination server. Instead of fragmenting the large packet into smaller ones. It drops the packet and sends a "packet is too large" ICMP reply. To tell your system what MTU to use for just that connection.

Even if your connection supports 1500MTU, there would probably be servers out there on the internet that are connected via tunnels or other connections that only support lower MTU values. So you would definitely have problems connecting to such servers if all of your packets are being dropped. And your computer is not getting the ICMP replies to tell it to use a lower MTU for connections to that server.

BMarquis

465 posts

Ultimate Geek
+1 received by user: 577

Trusted

Chorus

Lifetime subscriber

#2075915 19-Aug-2018 20:36

Taubin:

I just had a glance at my ONT and it does have a QR code on it, so it seems to be one of the ones affected. I look forward to a firmware update from Chorus. So it seems my issue is most likely different to yours.

The issue is with a specific combination of ONT (the one printed with "Type 200" by the Chorus logo, which also has a QR code) and a particular OLT Line card.

ONTs without QR codes - the older generation ONT - are not affected at all.

BMarquis

465 posts

Ultimate Geek
+1 received by user: 577

Trusted

Chorus

Lifetime subscriber

#2075916 19-Aug-2018 20:48

SirHumphreyAppleby:

Hopefully! I can't say I'm at all impressed with an at least six month (as planned) delay diagnosing and fixing the issue, keeping ISPs and users in the dark about what is happening. I've wasted many hours on this issue, reading, posting, switching routers and configuring. Then there is your time for which I am most grateful (this applies to everyone, but especially michaelmurfy), and helpdesk time - Voyager has been very thorough with their support. It has also cost me a bit of cash switching ISPs, but at least I didn't invest in new hardware, which I would have if I'd not previously had IPv6 working here.

I can understand the frustration. The cause of the delay was a timing issue - we had to bundle it in with an already-planned OLT and ONT upgrade.
It's not a trivial project to deliver, the testing alone takes months. This testing includes more IPv6 test cases now.

It was also tricky to narrow down the impacted combination, which made no sense to us - it looked, initially, like an intermittent fault. The number of complaints were low - because IPv6.
Was a head-scratcher for a while.

I can't do much but apologise for the time (and money) it has cost you - so sorry about that.

My offer still stands - anyone who wants to know if they are affected can PM me, and I'll personally check for you.

RSPs should have been getting some comms about the upgrade plan/timing. I'll check on this and post in the other thread.

Edit: @SirHumphreyAppleby Actually, I just realised that based on our PMs a while back you aren't affected by our issue...

SirHumphreyAppleby

2939 posts

Uber Geek
+1 received by user: 1860

#2075937 19-Aug-2018 21:35

BMarquis:

Edit: @SirHumphreyAppleby Actually, I just realised that based on our PMs a while back you aren't affected by our issue...

@BMarquis, yes, that's correct (also acknowledged earlier in this thread). The reason I started this thread was to independently verify my configuration should work, which @michaelmurfy has done. So while we know there is an issue, we still aren't really any closer to understanding where that issue is. I am however now more confident it's not a PEBKAC issue at my end. Bigpipe and Voyager both seemed confident their ends were set up correctly, and the logs provided earlier in this thread by Voyager also suggest their configuration is correct.

I have numbers printed on my ONTs to distinguish them. Perhaps I could send you those and you could look in to any changes that may have occurred around 25 August 2017? IPv6 connectivity was initially lost when I requested a speed change. I did change ONT with the switch to Voyager, so it would seem reasonable to be suspicious of any changes that occurred upstream around that time.

BMarquis

465 posts

Ultimate Geek
+1 received by user: 577

Trusted

Chorus

Lifetime subscriber

#2075947 19-Aug-2018 21:59

SirHumphreyAppleby:

BMarquis:

Edit: @SirHumphreyAppleby Actually, I just realised that based on our PMs a while back you aren't affected by our issue...

@BMarquis, yes, that's correct (also acknowledged earlier in this thread). The reason I started this thread was to independently verify my configuration should work, which @michaelmurfy has done. So while we know there is an issue, we still aren't really any closer to understanding where that issue is. I am however now more confident it's not a PEBKAC issue at my end. Bigpipe and Voyager both seemed confident their ends were set up correctly, and the logs provided earlier in this thread by Voyager also suggest their configuration is correct.

I have numbers printed on my ONTs to distinguish them. Perhaps I could send you those and you could look in to any changes that may have occurred around 25 August 2017? IPv6 connectivity was initially lost when I requested a speed change. I did change ONT with the switch to Voyager, so it would seem reasonable to be suspicious of any changes that occurred upstream around that time.

There are no fixes for IPV6 in the new version of software for the older ONTs, so I don't think this is going to be fixed magically by the upgrade.

While I don't know which BNG hardware Voyager use - their trace showing IPv6CP as "Opened" would probably indicate the BNG and your router have successfully negotiated their way through IPv6CP. so any issues are likely to be router or device related, rather then in our network.

Happy to do some further analysis with you.

Feel free to send me whatever numbers you have printed on them (hopefully they are the SLIDs). Failing that, I might need your address or the ONT serial numbers (ALCLxxxxxxx)

Tinkerisk

4798 posts

Uber Geek
+1 received by user: 3660

#2075955 19-Aug-2018 22:39

I can't contribute to the specific needs of your ISP since mine are different. Maybe you have a static IPv6 address (it doesn't seem to be). If not, I wonder that there are no config commands like

1) prefix-only ### DHCPv6 servers handle IA_NA and IA_PD requests on eth0.10 vlan - usage depends highly on the ISP

> set interfaces ethernet eth0 vif 10 pppoe 0 dhcpv6-pd prefix-only

2) rapid-commit enable ### reduces to 2 DHCPv6 instead of 4 messages on eth0.10 vlan

> set interfaces ethernet eth0 vif 10 pppoe 0 dhcpv6-pd rapid-commit enable

3) address autoconf ### eth0.10 vlan uses SLAAC to build IPv6 host address. No public IPv6 address when absent!

> set interfaces ethernet eth0 vif 10 pppoe 0 ipv6 address autoconf

4) dup-addr-detect-transmits 1 ### controls the number of IPv6 duplicate address detection attempts

> set interfaces ethernet eth0 vif 10 pppoe 0 ipv6 dup-addr-detect-transmits 1

- NET: FTTH & VDSL, OPNsense, 10G backbone, GWN APs
- SRV: 12 RU HA server cluster, 0.1 PB storage on premise
- IoT: thread, zigbee, tasmota, BidCoS, LoRa, WX suite, IR
- 3D: two 3D printers, 3D scanner, CNC router, laser cutter

Lenovo

Shop now for Lenovo laptops and other devices (affiliate link).

SirHumphreyAppleby

2939 posts

Uber Geek
+1 received by user: 1860

#2075961 20-Aug-2018 04:35

@Tinkerisk, thank you for your suggestions.

Tinkerisk:

I can't contribute to the specific needs of your ISP since mine are different. Maybe you have a static IPv6 address (it doesn't seem to be). If not, I wonder that there are no config commands like

1) prefix-only ### DHCPv6 servers handle IA_NA and IA_PD requests on eth0.10 vlan - usage depends highly on the ISP

> set interfaces ethernet eth0 vif 10 pppoe 0 dhcpv6-pd prefix-only

This was suggested by michaelmurfy for my ERL configuration and did not result in any change in behaviour. It's also part of my standard pfSense configuration.

2) rapid-commit enable ### reduces to 2 DHCPv6 instead of 4 messages on eth0.10 vlan

> set interfaces ethernet eth0 vif 10 pppoe 0 dhcpv6-pd rapid-commit enable

I've had this enabled previously following other IPv6 guides. I can confirm after testing again this morning, there is no change in behaviour.

3) address autoconf ### eth0.10 vlan uses SLAAC to build IPv6 host address. No public IPv6 address when absent!

> set interfaces ethernet eth0 vif 10 pppoe 0 ipv6 address autoconf

Unless I am mistaken, SLAAC should be the simplest configuration possible. Using SLAAC on the WAN shows no public address assignments on either the ERL or under pfSense.

4) dup-addr-detect-transmits 1 ### controls the number of IPv6 duplicate address detection attempts

> set interfaces ethernet eth0 vif 10 pppoe 0 ipv6 dup-addr-detect-transmits 1

I currently have this value.

Tinkerisk

4798 posts

Uber Geek
+1 received by user: 3660

#2075962 20-Aug-2018 05:26

Hmmm. I'm sure you have already taken into account to re-boot everything after changes since I found out that the ER is a little bit like a Diva when it comes to IPv6 (sometimes it really needs a shutdown power off - re-start).

Tinkerisk

4798 posts

Uber Geek
+1 received by user: 3660

#2079502 27-Aug-2018 04:53

SirHumphreyAppleby:

I currently have this value.

Could you solve it in the meantime?

SirHumphreyAppleby

2939 posts

Uber Geek
+1 received by user: 1860

#2079505 27-Aug-2018 07:17

Tinkerisk:

Could you solve it in the meantime?

No solution yet.

Packet captures show DHCPv6 solicit requests being sent, but no reply is logged. The issue is presently with @BMarquis (Chorus) who can hopefully establish where the requests or replies get to in the network.

mako

3 posts

Wannabe Geek

#2081529 30-Aug-2018 17:02

Im having the same problem getting IPV6 to work using UFB. The tech support are telling me that chorus have a problem with their cards.

Samsung

Shop now on Samsung phones, tablets, TVs and more (affiliate link).

SirHumphreyAppleby

2939 posts

Uber Geek
+1 received by user: 1860

#2081545 30-Aug-2018 17:08

mako:

Im having the same problem getting IPV6 to work using UFB. The tech support are telling me that chorus have a problem with their cards.

That is correct. The problem is only confirmed to occur with specific hardware. If you have a type 200 ONT (has a QR code on the front), it may be this issue. If not, all hope is not lost just yet - Chorus is continuing to investigate the issue I am experiencing with my configuration using the type 100 ONT.

If you do have a type 100, it would helpful if you could reply with your router model and configuration details.

mako

3 posts

Wannabe Geek

#2081585 30-Aug-2018 17:22

SirHumphrey (By the way I love that show)

I'm using a Huawei HG659 with voyager. my ONT is type 200.

Basic Information of connection taken from my router

IP Address Type IPV4 + IPV6

IPV6 Address Type SLAAC

SirHumphreyAppleby

2939 posts

Uber Geek
+1 received by user: 1860

#2081588 30-Aug-2018 17:28

mako:

SirHumphrey (By the way I love that show)

I'm using a Huawei HG659 with voyager. my ONT is type 200.

Thank you - brilliant show. The references to Concorde and the Channel Tunnel are dated, but otherwise it's as valid today as it was in 1979.

With the type 200 ONT, it's almost certainly going to be the card issue. For IPv6 on the Huawei, you just need to do the following...

Change IP Protocol Version to IPv4 + IPv6
Set the IPv6 addressing type is set to SLAAC

mako

3 posts

Wannabe Geek

#2081591 30-Aug-2018 17:42

SirHumphreyAppleby:
mako:

SirHumphrey (By the way I love that show)

I'm using a Huawei HG659 with voyager. my ONT is type 200.

Thank you - brilliant show. The references to Concorde and the Channel Tunnel are dated, but otherwise it's as valid today as it was in 1979.

With the type 200 ONT, it's almost certainly going to be the card issue. For IPv6 on the Huawei, you just need to do the following...

Change IP Protocol Version to IPv4 + IPv6

Set the IPv6 addressing type is set to SLAAC

So IPV6 doesn’t work for UFB for everyone, or some select customers

Regards Mako

1 | 2 | 3