Skip to main content


Years later…
I finally fixed my #radvd installation: It now no longer pumps out router advertisements to the wrong #VLAN.

Apparently my infrastructure had issues with the source addresses always being the same #MAC. Now, with all-different MAC addresses for every VLAN it looks much better.

#router-advertisement #IPv6
sigh.
Might not have been that successful.

And I still don't know why I am seeing RA packets from the wrong VLAN on my network.
They seem to be caused by the switches, but I don't know why and why it is restricted to two special VLANs, not more, despite there should be more in that case. It's … embarassing.
Do any of the devices from one VLAN talk to any other devices on another VLAN? (Meaning devices from one can connect to devices on the other?)
Yes, there is IPv6 routing active between those VLANs.
The interesting part is: The RA packets do not show up on the wrong VLAN on the router (yes, I am sniffing the router's connection).
It's only behind the switches. And they should not send those RAs to the wrong VLAN(s).
RA’s will send between VLANs if those VLANs have an active route to communicate on. It may not be sending them to the wrong VLAN, it may be telling the other devices on the VLAN that there is another VLAN with devices on it. Is the RA sending a primary routing announcement or is it sending a beacon packet? Are the switches sending RA packets as a Store-and-Forward or is it creating the packet itself? Is the router between all the switches or do any of the switches directly connect to each other physically?
  • The radvd sends the RA only on the VLAN it is supposed to send it on - correct prefix on correct VLAN ID. No other RA leave the router, as sniffed on the router's single connection into the network.
  • The clients receive two RA's, one for each prefix on the IPv6 multicast address, with both source MAC addresses being correct for each prefix.
  • The switches are L2-only, thus they are not supposed to send any RA at all, and they are directly connected.
Fun fact: Same problem on the WiFi, so it's either every single switch and AP or it is just one switch for some obscure reason I can't lay my finger on.
If the switches are L2 then they are just doing a store and forward. So the router is the one producing it. But if the VLANs should be able to route to each other they both need to provide RAs on both VLANs.
The router provides the RAs on all the VLANs.
It is just one RA of one VLAN appearing on another - wrong - VLAN.
You said the two switches are connected directly together. Is it connected [router] -> [switch 1] -> [switch 2] ??
Which switch is receiving two RAs?
Apparently both, judging by the AP being connected to Switch 1. Or it's just 1 and it then also appears on 2.
It's definetely not just 2.
Are the VLANs separated between the switches are are both switches operating both VLANs?
All VLANs are operating over tagged interfaces, all VLANs are across all switches and the AP.
Seems there's a bug in the switch firmware.
Interfaces are assigned still assigned to old VLANs despite the port going down and back up and a different client with a different VLAN is authenticated on that port. So, apparently the dynamic VLAN assignment is never removed from the port and thus IPv6 multicasts in that (wrong) VLAN are still forwarded to the port despite the authenticated client not being part of it anymore.

Yet, the other way, from the client, does not work, which is obviously intended but in the case of IPv6 multicast router advertisements still bear the unwanted consequences.

Well, the switches are EOL and I will hardly get that bug fixed with its vendor, so I guess I need to deal with it until the switches are replaced.
Oh wow. Going EOL with a firmware bug is never good. Which brand is it?
IIRC it's an OEM Maxell chipset and I doubt it was ever noticed, as, despite their rather large feature set, these switches were marketed as SOHO "under the desk" switches, not precisely what I'm doing with them.

I'll try to file a bug with the vendor, but since my support contract ran out long before they went EOL, it's doubtful anyone will do something about it.
Confirmed. Problem extends to guest VLAN - a port becomes a member of the guest VLAN despite it authenticating for a different one.

Explains a lot.
Let's see how support responds to the bug report.
You know their just going to tell you to upgrade... lol. Yeah, I remember SOHO switches and routers. I always tried to steer clear of them because I knew they were likely just relabeled consumer products with a slightly modified firmware package.
You know their just going to tell you to upgrade...
Of course they do. I can sing that song while being dead under water.
Only I'm already running latest.
Yeah, I remember SOHO switches and routers.
These aren't too bad. At least I can pump a real gigabit per second through them.
At that time they were the only viable option with that feature set and without a fan, which was important, considering their placement in a noise-critical environment.

However, apparently my support contract hasn't run out yet and if I can persuade that first level support guy to push my detailed report upstream into engineering they might indeed find this a potential network security risk too and fix it anyway.
It is not too hard to reproduce and the fix shouldn't be that hard either. I'll wait - and potentially replace it anyway, given time (and opportunity).
These aren’t too bad. At least I can pump a real gigabit per second through them.
At that time they were the only viable option with that feature set and without a fan, which was important, considering their placement in a noise-critical environment.
Yeah that's true. I did get a small business (SMB) switch once with a loud fan but I was able to replace it with a much quieter option. But at the time, SOHO routers and switches were the cheapest option for 1Gbps you're not wrong about that.