-
Well like I said I have never seen an issue but I've always been careful to avoid tagged and untagged traffic (for the wrong reason it turns out ::)). The worst that can happen is that something that isn't configured quite right strips the tags somewhere in the chain such that traffic arrives on the wrong interface in pfSense. If you are only handling tagged traffic on the NIC those packets will just be dropped.
You are very unlikely to see any issue if you have everything configured correctly.
You will need to investigate how your unmanaged switches handle VLAN tagged packets.
Steve
-
@cmb:
I've never seen a problem mixing untagged and tagged on a single port. Problems aren't why it's not a recommended practice. It can be possible to drop from a tagged VLAN into the untagged VLAN, which is why most switch vendors specifically recommend not using the untagged VLAN on trunk ports (amongst other possible reasons, none of which are related to functionality problems caused by doing so).
Thanks for that.
Am I likely to run into problems do you think?
Basically, thinking of using the vlan feature of my access points to create two vlans, and leaving anything connected directly to the lan as untagged. No vlan switches as such (just the AP's), but guess this would count as a 'trunk' between the AP and the PFsense NIC? It does go through 1 or 2 unmanaged switches.
Have I got you right that you connect your AP to pfSense via unmanaged switches? In theory your unmanaged switches do strip off the vlan tags form your AP traffic. This way network packets coming from your AP cannot be attributed to the right network within your pfSense box.
If your AP emitts vlan tagged traffic and you are not going to use a managed switch, you should connect your AP directly to pfSense. I've read about it in the pfSense forum but cannot find the thread anymore.
Peter
-
Have I got you right that you connect your AP to pfSense via unmanaged switches? In theory your unmanaged switches do strip off the vlan tags form your AP traffic. This way network packets coming from your AP cannot be attributed to the right network within your pfSense box.
If I recall correctly, at least one reader of these forums has reported that packets with VLAN tags go through their unmanaged switch with VLAN tags preserved. My suspicion is that an unmanaged switch probably wouldn't bother to strip VLAN tags. But it is better to check than assume.
-
I think I will just use an additional NIC to be safe. It will be easier in the long run, with any fault finding or replacing of failed APs etc.
I currently have one NIC as LAN, cabled to an 8 way switch, 4 Poe ports on this feed 4 APs in one building, spread around. There is then a cable from here to another building over the road, which connects to an identical Poe switch which itself feeds two APs. There is then a couple bits if kit (jukebox and tv) connected directly to the switches on non Poe ports.
I think I will use a second NIC, and have one feeding one switch, and one feeding the other. That way the APs in one building will be on one NIC, and those in the other building on the other NIC.
I currently use the DHCP range 192.168.11.1-192.168.15.254, the interface being 192.168.8.1/21
I would put the second range as 192.168.18.1-192.168.23.254, this interface being 192.168.16.1/21Ideally I would swap to a 172.16.x.x range, but the jukebox has hardcoded IP, subnet, gateway and DNS, and only the jukebox company can change this, so easier to leave at 192.168.x.x
-
If I recall correctly, at least one reader of these forums has reported that packets with VLAN tags go through their unmanaged switch with VLAN tags preserved. My suspicion is that an unmanaged switch probably wouldn't bother to strip VLAN tags. But it is better to check than assume.
Thanks, wallabybob, you're absolutely right.
Peter
-
Exactly.
You might think that any switch capable of handling jumbo frames would also be able to cope with VLAN tags. However I guess it is up to the firmware author to correctly identify/deal with them.
It's an interesting topic though with no definitive answer after a few minutes Googling. There are many people saying 'absolutely definitely not, will never work' and also, more rational, people saying 'it might'. Here a good post:
http://blog.pressure.net.nz/2008/11/the-amazing-unmanaged-trunk-mode-switch/I agree that adding a separate NIC will be better in almost every way if you have that ability. :)
Steve
-
Indeed from experiences of others, it seems most unmanaged switches will pass through 802.1Q tags with no problem. I've seen several customer networks doing so for years with no issues. I would never rely on that in any network of mine though and can't say I'd recommend it.
-
Ok.
I have split the network across two interfaces now, and it is all up and running.
I add some static IP mappings to some MAC's to force them to keep the same IP, for particular staff members iPhones etc. In the DHCP stats, it shows these users as being "online" with BOTH IP's, one for one interface and one for the other. I have added them to both DHCP config pages as a static mapping. Is this going to cause issues?
Thanks.
-
Ok.
I have split the network across two interfaces now, and it is all up and running.
I add some static IP mappings to some MAC's to force them to keep the same IP, for particular staff members iPhones etc. In the DHCP stats, it shows these users as being "online" with BOTH IP's, one for one interface and one for the other. I have added them to both DHCP config pages as a static mapping. Is this going to cause issues?
Thanks.
I've configured multiple static dhcp mappings for the same MAC address in different networks. This setup is running for more than a year now without issues. I'm observing as well that often a MAC address is shown "online" in multiple networks at the same time. But that's so far the only "issue".
Peter
-
Yes, It seems to work fine and as expected. I didn't notice the DHCP status page showing multiple entries until I was off-site and looking at them remotely, and so could not check. I have since gone past the site and checked, and all seems to work just fine.
Thanks.