No IPv6 on VLAN

Routers
22

Is this a bug @Alta-MikeD? I was using wan1 on the RJ45 now im using wan2 on SFP. Could tbis be why IPv6 isn’t working fully after switching?

23

So to clarify, IPv6 isn’t supported on multiple WANs (yet anyway), but there appears to be a bug in the way the ip6class is handled. It’s following the last provisioned WAN, not the active WAN.

If you have IPv6 enabled on both WAN1 and WAN2, try disabling IPv6 on the inactive interface.

24

I deleted all interfaces and made 1 new one. So it’s set back to WAN1 and is the only interface option.

Even setting /56 for PD which Cox supports I never did pull an address for additional subnets. So just reconfigured the WAN and rebooting.

Edit 2: After reboot with only 1 WAN interface I’m still not pulling /56. Native VLAN has IPv6 but any additionals are local only and not showing a router IPv6 address. @Alta-MikeD

],
“ipv6-address”: [

    ],
    "ipv6-prefix": [

    ],
    "ipv6-prefix-assignment": [

    ],
    "route": [
25

Hello,

Changing ip6class to wan_6 works only for VLAN1 (default), the other VLANS still gets only a link-local address.

I think that wan_6 is spawned only for ppp protocols, this is a quote from openwrt docs:

PPP-based protocols and option ipv6

PPP-based protocols - for example pppoe and pppoa - require that option ipv6 is specified in the parent config interface wan section. See WAN interface protocols. option ipv6 can take the value:

  • 0: disable IPv6 on the interface
  • 1: enable IPCP6 negotiation on the interface, but nothing else. If successful, the parent interface will be assigned a link-local address (prefix fe80::/10). All other IPv6 configuration is made in the wan6 interface which must be configured manually, as described below.
  • auto: (default) enable IPv6 on the interface. Spawn a virtual interface wan_6 (note the underscore) and start DHCPv6 client odhcp6c to manage prefix assignment. Ensure the lan interface has option ip6assign 64 (or a larger prefix size) set to redistribute the received prefix downstream.

Further configuration options, if required, can be given in the config interface wan6 section.

Note: In order to successfully receive DHCPv6 advertisement unicast messages from the dhcp6s to OpenWrt dhcp6c, you will need to have firewall rule for the WAN zone (already allowed in default):

26

@spx Okay, update from our end. IPv6 over PPPoE is broken, for a lack of better words. I’m not sure of the specifics, but I do know a fix is already being worked on.

In the interim I would recommend to expect it not to work properly (for PPPoE WAN types), if at all. I may suggest even disabling it temporarily until the fix is available, to mitigate unnecessary issues, but ultimately that is your decision.

27

Thank you Mike, I’ll wait for a fix then :pray:

1 Like
28

@spx No problem! I think that’s the best approach, and also why I wanted to share that immediately so you weren’t wasting more time trying to make it work. Sorry that I started to send you on a wild goose chase.

29

@Techout By chance did you ever create any DHCP Reservations? Would you like me to request data from various files or do you want me to take a look directly and report back? Offering as I see above you went with a site invite, so if you’d prefer in this case that I take a look directly, I’d be happy to. I’ll DM you my email in case, feel free to follow up here though with whatever your preference.

30

No DHCP set on the router no. I think you were the one I was emailing about that the other days as well correct? That clients with certain characters and DHCP reservations break it. Also yes shoot me a DM and I’ll send an invite @Alta-MikeD.

31

Yes, correct. Perfect, thanks!

32

So to circle back with regard to @Techout’s issue, it appears that there is a better configuration that can be used on Route10 side. I was able to fix it with some minor modifications. I have brought up my observations and config suggestions internally for discussion. Being a long weekend for us, I’m not expecting to hear back until next week, but I wanted to report our findings. I’ll add another follow up once available.

1 Like
33

It looks like spx’s network required a similar fix. It’s a little different because it’s PPPoE which is at least a little more “broken” but with the right combination of settings he’s also getting a /56 on the WAN and a /64 passing to each VLAN.

Both now have a config file in place to make these changes persistent until a proper fix is implemented.

We’ll follow up again once this is resolved.

1 Like
34

Thanks for all the help @Alta-MikeD!

1 Like
35

No problem! Happy to help.

36

I see there is an IPv6 fix in the new update! Is what you did now implemented?

37

Not quite, I haven’t asked so unknown to me. It does seem that provisioning is a bit different than before, but it’s not the same as what we used in that script file. I’ve actually been meaning to reach out to see if you wanted to try it and let me know.

It works fine on my Route10 (with Cogeco in Canada), but it did on the prior release too, so I can’t personally comment either way. I do not know if the changes would work with Cox or not. Please see below if you’re interested in trying it:

If you wanted to try you’d need to open web terminal, issue: mv /cfg/post-cfg.sh /cfg/post-cfg.sh.bak; reboot

Once it’s connected again you should trigger a provision from Control, like go to Network, click on the icon for Route10, expand advanced, and toggle Jumbo Frames on, then off, so that it pushes updated provisioning from Control. Then you’d want to check ifstatus wan6 to see if you’re still getting assigned a /56, or not.

If it’s broken again, you can easily revert with: mv /cfg/post-cfg.sh.bak /cfg/post-cfg.sh && /cfg/post-cfg.sh

If you’re willing to test, that actually would be great information to know.

EDIT: updated steps a bit

38

Yep happy to test. My next message was actually going to be how to disable or remove the script to see if its changed! Will test shortly and let you know.

1 Like
39

Instantly broke

40

Sorry about that, it should’ve been okay. Where did you land with things?

Sorry I wasn’t online again last night. The post-cfg.sh file is still on my Drive share at the same URL, if you need the original. Worst case you can delete the file, then scp it again, or copy + paste, whichever you had done before.

I actually updated the script slightly to print to syslog, instead of console, so that way the changes are logged with the regular device logs. I’ve tested it here.

And given that you were trying to switch back, I assume that this re-broke IPv6 for Cox?

41

Sorry I meant the first command broke it the command to revert it worked I didn’t need to SCP the config again. But on the new update without the script IPv6 is still broken.

1 Like