Strange behaviour with IPv6 Neighbor Discovery on different VLANs

RouterOS General
1

I have discovered a strange behavior in my IPv6 configuration and would like to understand if there is some wrong configuration on my side or if this is a regular behavior.

My network is splitted up in three vlans on the ether2 interface. On ether2 a Wi-Fi Access point is connected.

/interface vlan
add interface=ether2 name=vlan7-other vlan-id=7
add interface=ether2 name=vlan9-iot vlan-id=9
add interface=ether2 name=vlan16-office vlan-id=16

Depending on the SSID, my AP is linking a related vlan:

SSID Other = vlan 7
SSID IOT = vlan 9
SSID Office = vlan 16

To get an /56 Prefix Pool, I have added a dhcp-client to my pppoe interface:

/ipv6 dhcp-client
add add-default-route=yes default-route-tables=main interface=pppoe-telekom pool-name=pppoe-telekom-dhcpv6-pool request=prefix use-peer-dns=no

Only clients von vlan16-office shall get an IPv6 via SLAAC. I added an IPv6 address and activated ND:

/ipv6 address
add comment=pppoe-ipv6-adr address=::/64 eui-64=yes from-pool=pppoe-telekom-dhcpv6-pool interface=vlan16-office

/ipv6 nd
add advertise-dns=no advertise-mac-address=no disabled=no hop-limit=unspecified interface=vlan16-office managed-address-configuration=no mtu=unspecified other-configuration=no ra-delay=3s ra-interval=3m20s-10m ra-lifetime=30m ra-preference=medium reachable-time=unspecified retransmit-interval=unspecified

All clients on vlan 16 are getting IPv6 addresses.

But the strange thing is, also some clients on the other vlan 7 and vlan 9 are also getting IPv6 addresses from the prefix range. IPv6 routing for vlan 7 and vlan 9 is broken.

My assumption was that with ND configuration, I can control the IPv6 delegation to the clients.

Is there a misconfiguration in my setup or is this intentional behavior on the part of IPv6?

And an additional question:
Do I need an IPv6 address (/ipv6 address comment=vlan16-ipv6-adr) on my vlan16-office interface or can I activate SLAAC on the vlan 16 without adding an IPv6 address to the interface=vlan16-office?

2

The problem might be on your AP. Access Points usually have "multicast enhancement" features to improve the performance, and the "multicast enhancement" implementation of your AP might be buggy and causes the leak of the RA multicast messages.

To be sure that it's not due to the router, either disable the default IPv6 -> ND entry on the all interface, or add explicit IPv6 -> ND entries for vlan9-iot and vlan7-other with RA Lifetime cleared (no value, ra-lifetime=none).

Post your /ipv6 nd export output to be sure.

You probably meant "on my vlan16-office interface"? You don't actually have to add the /ipv6 address entry on vlan16-office for SLAAC, but then you'll need to manually add a correct entry under IPv6 -> ND -> Prefixes with the right prefix information and the interface. As you can see, adding the /ipv6 address entry with advertise=yes will automatically add a corresponding dynamic /ipv6 nd prefix entry for you that makes SLAAC works.

Side note: It appears that your WAN uses PPPoE client. In that case there is no need to turn on add-default-route=yes on the DHCPv6 Client instance. It's a hack that is not needed for PPPoE.

1 Like
3

Thank you for your reply.

Regarding vlan16-office interface: yes, this was a typo, I corrected it in my previous post to avoid confusion.

I have setup the AP with an Mikrotik AP and will reply with configuration when I'm back home.

4

ND is already disabled on the router: /ipv6 nd set [ find default=yes ] disabled=yes. I also removed RA Lifetime now: ra-lifetime=none.

This is the configuration of my Mikrotik AP with three SSIDs:

/interface bridge
add comment=bridge-vlan name=bridge-vlan vlan-filtering=yes

/interface vlan
add comment="Managed (vlan1)" interface=bridge-vlan name=vlan1-managed vlan-id=1
add comment="Other (vlan7 / v7)" interface=bridge-vlan name=vlan7-Other vlan-id=7
add comment="IoT (vlan9 / v9)" interface=bridge-vlan name=vlan9-iot vlan-id=9
add comment="Office (vlan16 / v16)" interface=bridge-vlan name=vlan16-Office vlan-id=16

/interface ethernet switch
set 0 cpu-flow-control=yes

/interface wifi security
add comment=security-v16 name=security-v16
add comment=security-v9 name=security-v9
add comment=security-v7 name=security-v7

/interface wifi
set [ find default-name=wifi2 ] channel.band=2ghz-ax comment="wifi-2GHz-v16 (Office)" .mode=ap .ssid=v16 name="wifi-2GHz-v16 (Office)" security=security-v16
set [ find default-name=wifi1 ] channel.band=5ghz-ax comment="wifi-5GHz-v16 (Office)" .mode=ap .ssid=v16 name="wifi-5GHz-v16 (Office)" security=security-v16
add comment="wifi-2GHz-v7 (Other)" .mode=ap .ssid=v7 master-interface="wifi-2GHz-v16 (Office)" name="wifi-2GHz-v7 (Other)" security=security-v7
add comment="wifi-2GHz-v9 (IoT)" .mode=ap .ssid=v9 master-interface="wifi-2GHz-v16 (Office)" name="wifi-2GHz-v9 (IoT)" security=security-v9
add comment="wifi-5-v7 (Other)" .mode=ap .ssid=v7 master-interface="wifi-5GHz-v16 (Office)" name="wifi-5-v7 (Other)" security=security-v7
add comment="wifi-5GHz-v9 (IoT)" .mode=ap .ssid=v9 master-interface="wifi-5GHz-v16 (Office)" name="wifi-5GHz-v9 (IoT)" security=security-v9

/interface bridge port
add bridge=bridge-ether comment=bridge-ether interface=ether2
add bridge=bridge-ether comment=bridge-ether interface=ether3
add bridge=bridge-ether comment=bridge-ether interface=ether4
add bridge=bridge-vlan comment=bridge-vlan-2GHz-v16 interface="wifi-2GHz-v16 (Office)" pvid=16
add bridge=bridge-vlan comment=bridge-vlan-5GHz-v16 interface="wifi-5GHz-v16 (Office)" pvid=16
add bridge=bridge-vlan comment=bridge-vlan interface=ether5
add bridge=bridge-vlan comment=bridge-vlan-2GHz-v7 interface="wifi-2GHz-v7 (Other)" pvid=7
add bridge=bridge-vlan comment=bridge-vlan-5GHz-v7 interface="wifi-5-v7 (Other)" pvid=7
add bridge=bridge-vlan comment=bridge-vlan-2GHz-v9 interface="wifi-2GHz-v9 (IoT)" pvid=9
add bridge=bridge-vlan comment=bridge-vlan-5GHz-v9 interface="wifi-5GHz-v9 (IoT)" pvid=9

/interface bridge vlan
add bridge=bridge-vlan comment=bridge-vlan tagged=bridge-vlan,ether5 untagged="wifi-2GHz-v16 (Office),wifi-2GHz-v9 (IoT),wifi-2GHz-v7 (Other),wifi-5GHz-v16 (Office),wifi-5GHz-v9 (IoT),wifi-5-v7 (Other)" vlan-ids=1-4094

I have seen, that IPv6 -> ND was enabled for all. Now I disabled it with /ipv6 nd set [ find default=yes ] disabled=yes. Maybe this was already the solution?

5

When I set ra-lifetime=none my client is getting an IPv6 address, but routing seems to be broken. https://test-ipv6.com gives me the freedback, that there is no IPv6 connection. With ra-lifetime=1800, the routing works again. Any idea what's the case here?

6

I've never used and configured WiFi using MikroTik AP devices, so I can't say much about the WiFi related configuration.

BUT this configuration export has a big red flag! As you can also read from MikroTik's documentation page:

They have a big red warning that says:

image
image794×125 5.55 KB

And that's exactly what you are violating by doing this:

Here you have vlan-ids=1-4094, but then have a list of ports in untagged. If you have value set for untagged, you need to create individual entries, one for each VLAN ID!

You'll need one with vlan-ids=7, where only "wifi-2GHz-v7 (Other)" and "wifi-5-v7 (Other)" are listed as untagged for example. Then one for vlan-ids=9, and another separate one for vlan-ids=16.

You can only specify multiple IDs/ID-ranges in vlan-ids when you only fill the values for tagged, as the documentation as warned.

1 Like
7

Setting ra-lifetime=none means the router no longer advertise itself as the gateway on that interface. In my previous post, I wrote about setting it on the two interfaces where you don't need to use IPv6. Without gateway the devices of course won't have internet access.

But I think the reason why your normal subnet also lost IPv6 internet access was because the RA of the two other VLANs (that say "no gateway here") were also leaking into the VLAN 16, due to the misconfiguration with vlan-ids I mentioned in the previous post.

1 Like
8

Thank you very much to make this clear again. I overlooked the important part of your post. :person_facepalming:

I didn't realize that. Thank you very much for linking the documentation. I will update my AP configuration and I will observe whether the phenomenon disappears as a result.

9

As @CGGXANNX already somehow hinted: you should never set any port as untagged member of a range of VLANs. It's exactly the reason for seeing both broadcast frames of all VLANs appear on the "non-elligible" interface. And NDs are multicast packets, technically those are broadcast over layer 2 (ethernet and WiFi).

Since ROS adds port, set with pvid, as untagged port to corresponding VLAN automatically, you should never need to do it manually (even less so to add it to range of VLANs).

1 Like
10

Thank you @CGGXANNX and @mkx for your replies. I think this was the reason and solution. After changing to explicit vlan id for each bridge entry, I did not observe the effect again.

1 Like