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
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
Quilnux likes this.
Felix Tiede
•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.
Quilnux
•Felix Tiede
•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).
Quilnux
•Felix Tiede
•- 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.Quilnux
•Felix Tiede
•It is just one RA of one VLAN appearing on another - wrong - VLAN.
Quilnux
•Felix Tiede
•Quilnux
•Felix Tiede
•It's definetely not just 2.
Quilnux
•Felix Tiede
•Felix Tiede
•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.
Quilnux
•Felix Tiede
•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.
Felix Tiede
•Explains a lot.
Felix Tiede
•Quilnux
•Felix Tiede
•Only I'm already running latest. 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).
Quilnux
•