Multiple WAN IPv6 RAs on 10g fiber

[ernestl]

It sounds like a misconfigured device behind ONT (00:24:45:fb:53:cf) is sending out RA which is not suppose to.

Can Sonic implement firewall filter to filter out other RAs that is not from Sonic router?

[mgoldburg]

Created pfSense feature request for supporting multiple RAs and router preferences.

Thanks for the creating the report!

Doesn't affect me yet as I'm still on the resold ATT service. Fortunately, there's a pfSense fix for ATT's insistence on handing out prefixes for individual /64s rather than something larger.

[brandonc]

I am trying to (elegantly) enable IPv6 with a 10g fiber connection. I have gotten it working with Prefix Delegation (PD) across a number of my interfaces. I am using a pfSense based firewall+router, which is connected to the AdTran 822v ONT.

I have unfortunately had to hard-code the default IPv6 gateway. My router sends a Router Solicitation (RS), resulting in the firewall's WAN interface receiving 2 Router Advertisements (RAs), see the tcpdumps below. The RAs are appropriately tagged with the preference.

The "low" preference RA is from MAC 00:24:45:fb:53:cf and "medium" preference RA is from MAC 5c:45:27:67:4e:80. The 00:24:45:* OUI is an AdTran MAC and the 5c:45:27:* OUI is a Juniper MAC. I am therefore assuming 00:24:45:fb:53:cf is the ONT and 5c:45:27:67:4e:80 is somewhere upstream on the OLT side.

The RA from 5c:45:27:67:4e:80 is the one that is needed for proper routing, otherwise IPv6 traffic gets dropped. While multiple RAs is valid, pfSense does not seem to handle it well. At least not as a client device on the WAN interface. It always ends up with the gateway from 00:24:45:fb:53:cf, not 5c:45:27:67:4e:80.

I tested with this my Linux+NetworkManager based PC directly connected to the ONT. It also receives the multiple RAs, but it receives the RA from 5c:45:27:67:4e:80 first. pfSense receives the RA from 00:24:45:fb:53:cf first. This behavior for both devices is consistent. I am not yet sure why it differs.

There might be something I can do on the pfSense side to better account for this. I need to explore this more. But I am wondering if I can just avoid the seemingly useless RA from the ONT (00:24:45:fb:53:cf) altogether?

Router Solicitation (from tcpdump):

Code: Select all

03:01:12.833032 xx:xx:xx:xx:xx:xx > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::3eec:efff:fe42:760 > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
	  source link-address option (1), length 8 (1): xx:xx:xx:xx:xx:xx
	    0x0000:  xxxx xxxx xxxx

Router Advertisements (from tcpdump):

Code: Select all

03:01:12.834313 00:24:45:fb:53:cf > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 78: (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::224:45ff:fefb:53cf > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 24
	hop limit 64, Flags [other stateful], pref low, router lifetime 0s, reachable time 0ms, retrans timer 0ms
	  source link-address option (1), length 8 (1): 00:24:45:fb:53:cf
	    0x0000:  0024 45fb 53cf

03:01:12.848009 5c:45:27:67:4e:80 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 78: (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::5e45:27ff:fe67:4e80 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 24
	hop limit 64, Flags [managed], pref medium, router lifetime 1800s, reachable time 0ms, retrans timer 0ms
	  source link-address option (1), length 8 (1): 5c:45:27:67:4e:80
	    0x0000:  5c45 2767 4e80

Hi there,

I'm sorry that you ran into issues with setting up IPv6 on our Fiber service. This is actually due to some problematic behavior we've recently become aware of with the new model 822 ONT's that we have been installing for our 10gbps Fiber service. It's awesome you were able to get it to work, but it's ultimately not ideal and we wanted to make a post regarding this for anyone else also experiencing this issue.

For these cases, we'll want to replace the model 822 ONT with our model 622 ONT's. 622's are just the previous model we had been using for our 10gbps service and does not exhibit this behavior, so it will make it a lot easier to get IPv6 set up.

If anyone is not sure which model ONT you have, here are some links with pictures of both units for everyone's reference.

https://help.sonic.com/hc/en-us/article ... dTran-822v

https://help.sonic.com/hc/en-us/article ... dTran-622v

@jgebroski We should have someone reaching out to you shortly to arrange an equipment swap.

If anyone has any questions or concerns, please let us know.

Kind regards,

[tarzxf]

If we're having IPv6 issues with a 622v ONT, is there hope?

[brandonc]

If we're having IPv6 issues with a 622v ONT, is there hope?

As far as we're aware, there shouldn't be any issues with the 622v. All we can say for certain is that if you have a 622, you are not affected by this specific issue where 822s send bogus RAs, as is demonstrated in jgeboski's dumps.

If you are experiencing any issues with the 622v, I would recommend posting your issue + logs on the forums, so that we can have our Network Operations team assess the issue.

Kind regards,

[tarzxf]

If we're having IPv6 issues with a 622v ONT, is there hope?

As far as we're aware, there shouldn't be any issues with the 622v. All we can say for certain is that if you have a 622, you are not affected by this specific issue where 822s send bogus RAs, as is demonstrated in jgeboski's dumps.

If you are experiencing any issues with the 622v, I would recommend posting your issue + logs on the forums, so that we can have our Network Operations team assess the issue.

Kind regards,

It was an ID10T error: my desktop was set to "Local-link Only" for IPv6. Changed that to pickup an address and IPv6 works as expected.

[brandonc]

It was an ID10T error: my desktop was set to "Local-link Only" for IPv6. Changed that to pickup an address and IPv6 works as expected.

Glad to hear you were able to figure out the issue and get it up and running on IPv6!

Please let us know if you run into any other issues or have any questions.

Kind regards,

[jgeboski]

I got my 822v ONT swapped out for a 622v today. I can confirm switching to the 622v resolves the bogus RA from the ONT.

[strangecargo]

Even with Rapid Commit being enabled and/or requesting the prefix over IPv4, I still had flakiness. I guess Rapid Commit or requesting the prefix over IPv4 just causes the non-ONT RA to come first more often. It seems this is just a race condition that I was mostly, but not completely winning.

pfSense has hidden rules for accepting RAs. It is not possible to block RAs in the Firewall Rules UI. Blocking the RA requires a rule be added very early before the rule to accept all RAs. I ended up creating a one-liner patch to block the RAs from AdTran ONTs and used the System Patches package to apply it:

I ran into the same issue trying to get IPv6 working reliably with pfSense on my 1g service, but my symptoms (and solution) were slightly different.

In my case, my IPv6 connectivity wouldn't work after a pfSense reboot until I did a manual release/renew on my WAN interface. After reading this post, I eventually figured out that the link-local IPv6 gateway address that the interface was using was different between when IPv6 was and wasn't working. I think there's a similar multiple-RA race condition that's happening in my case. I was able to use the same patching strategy as you, but I had to block a different netmask (fe80::219:9200:0:0/88), probably due to differences between the Adtran ONTs for 10g and 1g service.

Thanks a lot for figuring this out. I have no idea how long this would have taken me to figure out if I hadn't found this post.