SLACC Bleedthrough on VLANs
-
So, I just want to be clear that I'm using an unmanaged switch. It's a test lab where I'm seeing how everything can mingle and I understand the limitations of an unmanaged switch. The switch does pass the VLAN tags but it cannot assign them or modify them. I know I cannot have perfect control over the network flow in this setup unless I control each endpoint (which I do as this is a test lab setup). There are a number of VoIP phones, printers, and access points connected.
On the IPv4 side of things, everything seems to work great (no bleedthrough of any packets). Each endpoint has the 802.1p and 802.1q parameters specified for the ethernet frame tags.
The wireless access points allow me to do not only wireless endpoint isolation but also tag the ethernet frames in/out of the AP with a VLAN ID.
I think there is something about the link-local addresses in the IPv6 world that are causing issues.
-
no there is nothing about link-local that would be causing any issues. Layer 2 is Layer 2.. If you tagged it, its tagged!!
Your ports should be set to to only allow access to the vlan they are in, an the pvid should be set to the vlan you want..
What switch do you have, and what is the config.. If you do not set a pvid on the port, untagged traffic would be in that vlan. I see it all the time on these cheaper managed switches, or user new to vlans not correctly setting them and they put multiple untagged on a port, or don't set the pvid and and set the port to be tagged when a single host is on it, etc.
What is the make and model of your switch, and what is your port configuration.
"Each endpoint has the 802.1p and 802.1q parameters specified for the ethernet frame tags."
Your endpoint shouldn't give 2 shits what vlan its in.. It doesn't need to know or care about tagging anything - this is done by the switch when done correctly!! Or by the AP.. That you make such a statement that your setting 802.1q on the endpoint points me to believe you have a problem with your switch config.
The only time you should have to do such a thing on the endpoint if your going to have it in multiple vlans.. I do this on my discovery device for example It has a physical interface and I tagged the other vlans to it and then create sub interfaces with those specific vlan ids so it can see traffic in multiple vlans..
Your typical end point device would only ever be in 1 vlan.. Now a voip phone you hang a pc off would be specific config on the switch port to allow for the voip and data vlan, etc. But in the end the PC hanging off that phone wouldn't have a clue what vlan ID its on, etc.
Now you might set some qos on the PC if it was doing something special, so some traffic has a different priority than other.. But to do that you would normally have to set that switch port to trusted. Normally that is not done on the end point device either and you set that qos on the traffic somewhere else on the network not on the end device. If your going to set it on the endpoint device you have to make sure the switch port doesn't strip it off, etc.
-
if you are getting layer 2 bleed over, then you do not have your vlans configured correctly at your switch level would be my guess.
I have seen just that, though I know what the problem is. I have a TP-Link TL-901ND access point, which allows packets from the mail LAN onto the SSID for the VLAN.
-
If I don't set the VLAN ID on the VoIP phones they grab a native address. If I do set the VLAN ID they grab all info from the VLAN including DNS and gateway. It seems a lot of these endpoints are capable of working with unmanaged switches in this way.
-
So, I just want to be clear that I'm using an unmanaged switch.
Just asking for stuff on one "VLAN" to bleed over to another. In fact it's by design.
Get a managed switch. To do anything else is simply wasting time. Whatever you want to do with your time is up to you. Please don't waste ours.
-
My gut instinct tells me that pfSense is not setting the VLAN iD properly for the RADV daemon. DHCPv6 addresses get assigned to the proper vlans but the SLAAC addresses do not.
-
Your gut instinct is dead wrong. Get a managed switch. Stop being silly.
-
You offer no explanation for why DHCPv6 follows the VLAN settings but radvd doesn't. Surely as a moderator you can do better than your previous posts.
-
I am not going to waste my time with someone with a broken network by design. Put your tagged VLANs into a managed switch like they are supposed to be. It will work.
-
No thanks. If every device on the network is tagging layer 2 frames properly it should work.
Works in IPv4 mode just fine and DHCPv6.
-
Good luck.
-
Oh I read that completely wrong ;) I thought he said managed switch.. WTF - should really have more coffee before reading ;)
Yeah here with Derelict - what your trying to do is just plain moronic – if you want to use vlans, then you need a switch that can do vlans.. Trying to get all your devices to tag their traffic is just stupid plain and simple. A smart switch that does the basic features of vlans are cheap these days.. Even really full featured are reasonable..
I see cisco 10 port sg300 for $125 on amazon.. You can get a Zyxel 24 port with lots of features for $115
So excuses for trying to use a dumb switch for vlans by having all your devices tag their traffic is just plain moronic..
-
I appreciate the personal attack. But anyways…
There is clearly something wrong with radvd in pfSense. Even if I were to use a fully managed switch and set up VLAN trunks on it properly, radvd would still be sending all the IPv6 routes information to all of the vlans on the trunk port.
-
For the record, I have 9 VLANs configured on pfSense (2.3.4) going into a L2 managed switch, radvd is running, and no SLAAC bleedthrough whatsoever.
-
One thing you can do is fire up Wireshark, to see what's actually on the wire. Failing that, you can use the pfSense packet capture, though it's not quite as convenient as Wireshark.
. -
"Even if I were to use a fully managed switch and set up VLAN trunks on it properly, radvd would still be sending all the IPv6 routes information to all of the vlans on the trunk port."
So not only are you trying to do tagging with a switch that doesn't supports them, you don't seem to understand how tags even work?
As Derelict says - good luck with that ;) heheheeh
Here - I turned on managed RA on my dmz interface vlan 600.. Did a simple capture and there you go you can see its tag with vlan 600.. Now if doing the packet capture via the gui. It might not be capturing that - you need the "-e" which we could prob put in as a feature request for the packet capture.. But when you do a packet capture on a specific interface that is a specific vlan it will only show you traffic on that vlan. But will not list in the packet capture you download.
But you can see the RA, clearly marked with the tag I have on that interface
-
"Even if I were to use a fully managed switch and set up VLAN trunks on it properly, radvd would still be sending all the IPv6 routes information to all of the vlans on the trunk port."
So not only are you trying to do tagging with a switch that doesn't supports them, you don't seem to understand how tags even work?
A switch only has to pass the VLAN tags and just about any switch will. When you configure computer NICs for VLANs, those VLANs should still behave as separate networks, as they would with a managed switch. That is, if you have a network on VLAN5, only devices also on VLAN5 should receive the traffic. Devices with VLANs are quite common, such as VoIP. A phone would be on a VLAN, but still pass other traffic from a computer that passes through the phone. Many access points (at least other than the one I have) also properly support multiple VLANs.
Where a managed switch comes in handy is when you want devices to be on a specific VLAN, without having to configure them for it.
-
Where a managed switch comes in handy is when you want devices to be on a specific VLAN, without having to configure them for it.
And when the underlying OS doesn't support VLANs properly…Windows 10 anyone?!
-
Where a managed switch comes in handy is when you want devices to be on a specific VLAN, without having to configure them for it.
And when the underlying OS doesn't support VLANs properly…Windows 10 anyone?!
Yeah, well that's from Microsoft. ;)
I haven't tried on Windows, but Linux doesn't have a problem being configured for VLANs.
-
Here - I turned on managed RA on my dmz interface vlan 600.. Did a simple capture and there you go you can see its tag with vlan 600.. Now if doing the packet capture via the gui. It might not be capturing that - you need the "-e" which we could prob put in as a feature request for the packet capture.. But when you do a packet capture on a specific interface that is a specific vlan it will only show you traffic on that vlan. But will not list in the packet capture you download.
But you can see the RA, clearly marked with the tag I have on that interface
Try with it set to unimagaged on the vlans and managed on the native interface with DHCPv6 enabled. Even when I disable VLAN support on the NIC in multiple windows 10 boxes it still gets IPs via SLAAC.
