Incorrect info aside, Sonic recently rolled out their IPv6 here in Santa Rosa. After a reboot, pfSense was able to pull a /56. Posting some screenshots in case its helpful (vlan interfaces are all set to track with assigned prefix IDs, RA, etc.).smeiners wrote:Just chatted with support trying to get IPv6 to work on my pfsense setup. I got a surprising response:
When I asked to clarify:Your router would be configured to grab an IPV6 address, or an IPV4 address. Our system is designed to provide your device with either, depending on what it is requesting. It all depends on how your router is configured.
And for the record, I had this working when I was on Xfinity so I know it's not the router's fault.As mentioned above, our equipment is designed to provide your equipment with what it is requesting. We can't provide your router with two IP addresses. It will grab an IPV4 or IPV6 address, depending on which is enabled on your device.
IPv6 with Sonic ONT
Internet access discussion, including Fusion, IP Broadband, and Gigabit Fiber!
176 posts
Page 12 of 18
Hi Graeme,graeme_stewart wrote:Multiple customers have this issue (myself included) the ONT reports IPv6 as "service down", please, please can we get some technical assistance troubleshooting this?
I'm sorry to hear that you're having trouble getting IPv6 working on your connection. I did double check your specific circuit on our end and see there's other customers on the same network card serving your neighborhood with an active /56 address on their Eero's, so IPv6 is active in your neighborhood.
We are pretty limited in how we can help with the router configuration for third party routers as we are only trained on our rental equipment. However, we can try sending you a rental Eero to test with to rule out the router config.
Kind regards,
Brandon C.
Customer Support
Sonic
Customer Support
Sonic
If n is the number of customers on this card with an active /56 is n > 1? If that answer is yes, I'll keep debugging on my end.and see there's other customers on the same network card serving your neighborhood with an active /56 address on their Eero's
Graeme, there's at least one customer on your pon segement with at /56 active.graeme_stewart wrote:If n is the number of customers on this card with an active /56 is n > 1? If that answer is yes, I'll keep debugging on my end.and see there's other customers on the same network card serving your neighborhood with an active /56 address on their Eero's
Kelsey Cummings
System Architect, Sonic.net, Inc.
System Architect, Sonic.net, Inc.
That's an ambiguous answer to a yes/no question, which is odd. Maybe you're being polite and trying to suggest it's a dumb question (also ok).
Is n > 1 (not n =>1) where n is the number of IPv6 customers with an active /56 delegation?
Is n > 1 (not n =>1) where n is the number of IPv6 customers with an active /56 delegation?
Also, my router shows the connection to the Adtran, and it responding, but not with a globally routable v6 address:
Which is consistent with the earlier Adtran showing as v6 service down.
Code: Select all
Jul 07 16:17:48 Firewalla dhcpcd[1648729]: /var/lib/dhcpcd/duid: Success
Jul 07 16:17:48 Firewalla dhcpcd[1648729]: DUID 00:04:3b:90:37:80:4f:79:10:18:81:6e:ae:b2:72:47:78:a7
Jul 07 16:17:48 Firewalla dhcpcd[1648729]: eth0: IAID 31:31:07:8f
Jul 07 16:17:48 Firewalla dhcpcd[1648729]: eth0: IA type 25 IAID 00:00:00:01
Jul 07 16:17:48 Firewalla dhcpcd[1648729]: DUID 00:04:3b:90:37:80:4f:79:10:18:81:6e:ae:b2:72:47:78:a7
Jul 07 16:17:48 Firewalla dhcpcd[1648729]: eth0: soliciting a DHCPv6 lease
Jul 07 16:17:48 Firewalla dhcpcd[1648729]: eth0: IAID 31:31:07:8f
Jul 07 16:17:48 Firewalla dhcpcd[1648729]: eth0: IA type 25 IAID 00:00:00:01
Jul 07 16:17:48 Firewalla dhcpcd[1648729]: eth0: soliciting a DHCPv6 lease
Jul 07 16:17:49 Firewalla dhcpcd[1648729]: eth0: soliciting an IPv6 router
Jul 07 16:17:49 Firewalla dhcpcd[1648729]: eth0: soliciting an IPv6 router
Jul 07 16:17:49 Firewalla dhcpcd[1648729]: eth0: Router Advertisement from fe80::224:45ff:fefa:e350
Jul 07 16:17:49 Firewalla dhcpcd[1648729]: eth0: Router Advertisement from fe80::224:45ff:fefa:e350
It just means I manually thumbed through all of the active customers on your pon segment and stopped when I found someone with an active and functional /56 lease which is confirmation enough that it ought to work for you.graeme_stewart wrote:That's an ambiguous answer to a yes/no question, which is odd. Maybe you're being polite and trying to suggest it's a dumb question (also ok).
Kelsey Cummings
System Architect, Sonic.net, Inc.
System Architect, Sonic.net, Inc.
I'd be a happy customer if Sonic could get their own SDX Adtran 822v reporting as something other than IPv6 "ServiceDown".it ought to work for you
Performing a tcpdump on the edge router and see no replies from the Adtran. I'll continue troubleshooting, but this (and other customers seeing the same problem), seems to correlate to a Sonic side issue. Would love to be proven wrong.
Code: Select all
10:30:33.249682 IP6 (flowlabel 0xf11dd, hlim 1, next-header UDP (17) payload length: 206) fe80::226d:31ff:fe31:78f.dhcpv6-client > ff02::1:2.dhcpv6-server: [bad udp cksum 0x5893 -> 0xe6c5!] dhcp6 solicit (xid=17cadf (client-ID type 4) (elapsed-time 0) (vendor-class) (rapid-commit) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/56 pltime:0 vltime:0)) (IA_NA IAID:825296783 T1:0 T2:0) (Client-FQDN) (reconfigure-accept) (option-request DNS-server DNS-search-list SNTP-servers Client-FQDN opt_82 opt_83))
10:30:34.222691 IP6 (flowlabel 0xf11dd, hlim 1, next-header UDP (17) payload length: 206) fe80::226d:31ff:fe31:78f.dhcpv6-client > ff02::1:2.dhcpv6-server: [bad udp cksum 0x5893 -> 0xe664!] dhcp6 solicit (xid=17cadf (client-ID type 4) (elapsed-time 97) (vendor-class) (rapid-commit) (IA_PD IAID:1 T1:0 T2:0 (IA_PD-prefix ::/56 pltime:0 vltime:0)) (IA_NA IAID:825296783 T1:0 T2:0) (Client-FQDN) (reconfigure-accept) (option-request DNS-server DNS-search-list SNTP-servers Client-FQDN opt_82 opt_83))
At this point I'm giving up, and will wait for this to become an issue where Sonic actually provides some effective troubleshooting support on the customer side. They should - at a minimum - be able to objectively demonstrate that the ONT is seeing IPv6 traffic, yet they seem unable or unwilling to even do that.
- Packet is a response from a DHCPv6 server to a client, telling the client that it currently has no IPv6 addresses to assign, but providing the DNS server details.
Code: Select all
14:26:16.854690 IP6 (class 0xc0, hlim 64, next-header UDP (17) payload length: 187) fe80::fac0:1ff:fe1f:6b58.dhcpv6-server > fe80::1c76:8729:43bc:c724.dhcpv6-client: [udp sum ok] dhcp6 advertise (xid=661ff6 (client-ID hwaddr/time type 1 time 494972833 6c40088bf1fa) (server-ID vid 0000058366383a63) (IA_NA IAID:0 T1:0 T2:0 (IA_ADDR :: pltime:0 vltime:0 (status-code NoAddrsAvail))) (DNS-server ns1.sonic.net ns2.sonic.net))
Hi Graeme,
It looks like your 822v is running in bridge mode, so unless it's eating your packets, the ONT won't come into play. I have not personally verified IPv6 through the 822v, but we're getting into spooky territory if that's the problem.
I've verified your PON has 12 subs with active /56 PD allocations so this looks to be a problem with your setup.
In order for DHCPv6 PD to function, we'll need allow rules for ICMPv6 from fe80::/10. Per RFC 3316 Section 5.2 (https://www.ietf.org/rfc/rfc3315.txt), we'll also need a rule allowing UDP source port 547, destination port 546. In my experience, all this traffic comes from link local (fe80::/10), but feel free to leave the source address term out.
Destination port 546
Source port 547
Protocol UDP
Source address fe80::/10
Let me know how it goes and we'll take it from there.
It looks like your 822v is running in bridge mode, so unless it's eating your packets, the ONT won't come into play. I have not personally verified IPv6 through the 822v, but we're getting into spooky territory if that's the problem.
I've verified your PON has 12 subs with active /56 PD allocations so this looks to be a problem with your setup.
In order for DHCPv6 PD to function, we'll need allow rules for ICMPv6 from fe80::/10. Per RFC 3316 Section 5.2 (https://www.ietf.org/rfc/rfc3315.txt), we'll also need a rule allowing UDP source port 547, destination port 546. In my experience, all this traffic comes from link local (fe80::/10), but feel free to leave the source address term out.
Destination port 546
Source port 547
Protocol UDP
Source address fe80::/10
Let me know how it goes and we'll take it from there.
Tomoc
Sonic NOC
Sonic NOC
176 posts
Page 12 of 18