Newb questions - switches managed and unmanaged
-
do i have to replace all of my unmanaged switches with managed ones? Or can I route them all into one managed switch to one nic on the pfSense box? I have three nics in the box now, wan, lan and opt1. currently WITHOUT pfsense hooked up I have everything coming into a netgear 16 port unmanaged 1000 switch connected to my cable modem/router Arris with spectrum running 240 down and 25 up. Plex, wd my cloud, kodi, voip, etc the usual connections, wired and wireless.
I see some posts saying the unmanaged switch is connected into the pfsense box and then other posts say only managed switches will work. Im confused and my eyes are tired from so much reading.
Appreciate the help thank you
-
That depends entirely on what you're trying to do. You need a managed switch if you want to separate the VLANs into separate networks. If you can have native LAN and VLANs on the same port, then an unmanaged switch will work. For example, if you have a Wifi access point that supports VLANs and multiple SSIDs, you can configure the VLAN on pfSense, pass it through an unmanaged switch to the AP and it will work fine.
-
Man.
Except that every switch port on the whole network will see all broadcast traffic regardless of VLAN. Don't try to do DHCP or IPv6 or anything.
-
Man.
Except that every switch port on the whole network will see all broadcast traffic regardless of VLAN. Don't try to do DHCP or IPv6 or anything.
Funny thing. I have just that setup here. I have an unmanaged switch between the pfSense firewall/router and the rest of the network. I've had VLANs on it for years. What you will see on the switch port is the native LAN traffic and VLAN frames. That may or may not be an issue, depending on your needs. The VLAN frames will be ignored by any device not configured for that VLAN. Likewise, native LAN traffic will not appear on the VLANs. A device, such as an access point or VoIP phone that's configured for both will receive both. A managed switch beyond that unmanaged switch will be able to properly separate the traffic, as it would with any trunk port.
For those who say you can't pass VLAN traffic through an unmanaged switch, please compare it with a trunk port on a managed switch, where both native and VLAN traffic is present. What's the difference?
-
We have been through this before.
The VLAN frames will be ignored by any device not configured for that VLAN.
Maybe.
You cannot depend on something that does not speak (or is not configured to speak) dot1q to do the right thing with dot1q traffic. It might or it might not.
If EVERYTHING connected to the switch is dot1q-aware then yes, as long as the switch doesn't mangle the frames somehow it should work.
I consider your advice in this case to be pretty lousy.
-
Please show me an interface that will accept a VLAN frame, when it's not configured for it. To understand why this is so, you have to look at an Ethernet frame. Assume you've got an IP packet carried over Ethernet. IP normally uses Ethernet II and not 802.3. So, you have the MAC addresses, followed by the Ethertype field denoting IPv4. When that frame is received, the operating system will look at that Ethertype value and send the IP packet to the IP stack and discard the Ethernet frame. Now, with a VLAN, a 4 byte VLAN tag is inserted where the Ethertype field was. The first 2 bytes of that tag is now the Ethertype for VLAN. So, the OS, will now process that frame as from a VLAN, figure out which one and process accordingly, stripping off the Ethernet frame, including VLAN tag, and sending the IP packet up the IP stack. If there is no valid VLAN supported, the frame will be discarded entirely So, no computer interface that's not configured to use a VLAN will received it. And, as I mentioned, unmanaged switches won't do anything with the VLAN tag. They simply pass on every valid Ethernet frame, no matter what's in the Ethertype field.
I mentioned VoIP phones earlier. With those, a VLAN is often used for the phone traffic and native LAN for the computer traffic. A computer plugged into the phone will receive only native LAN traffic, but that same computer plugged directly into the LAN will see both native and VLAN¹ traffic, but ignore the VLAN, as it's not configured for it. Same applies to access points that support VLANs and multiple SSIDs. Only devices configured for a VLAN will receive VLAN traffic. All others will discard it.
1. Cisco can do things differently, using Cisco Discovery Protocol (CDP) to recognize the phone and then allow the VLAN onto the wire. Otherwise, a computer plugged into the port would see only native traffic. Other makes just use a trunk port, carrying both native and VLAN traffic.
-
Sigh. Do what you want. It is shitty, lazy design to have broadcast traffic for another broadcast domain on a switchport on which it does not belong.
-
Sigh. Do what you want. It is shitty, lazy design to have broadcast traffic for another broadcast domain on a switchport on which it does not belong.
The VLAN frames containing broadcast will appear at the NIC, but will be discarded, if the computer is not configured to use that VLAN. That would be less work than a broadcast on the native LAN. Also, where is the VLAN decision made? If in the NIC, then the computer won't see it at all. If in the computer's network stack, then it would receive and discard the VLAN frame..
Also, what's the context? If a large corporate network, with hundreds or thousands¹ of users, then you'd definitely want to keep them separate. However, even there, if VoIP is used and computers plugged into the back of phones, then you'd still have native and VLAN on the same wire. On a small network, such as in a home or small office, I doubt it would make much difference, particularly with the trend to gigabit.
Of course, with the move to IPv6, we'll not have to worry as much about broadcasts. Things that used to use broadcast now use multicast, where the multicast group can have as few as one listener.
1. Back in the late 90s, I worked at IBM Canada, where there were over 4000 people working in the building. While that was before VoIP, if it had been available then, having both VoIP VLAN and native LAN on the same wire would have resulted in the savings of over 4000 switch ports (ignoring the fact they used token ring back then). For that kind of money, you'd have native and VLAN on the same wire.
-
The difference being the VoIP phone is specifically designed to deal with dot1q, as is the switch it is connected to.
Just going to have to agree to disagree.
When I sniff an access port I don't expect to see every VLAN on campus.
You do.
Go ahead.
We don't need to talk about the fact that any device anywhere in the networks you design can hop onto any VLAN they want by simply tagging appropriately.
-
sorry for opening up a can of worms. wasnt my intention. I just want to get the network off the ground and then build from there. I believe I grasp the concepts and the points of contention presented by all who have responded and I offer thanks for the input.
So, in theory unless I am wrong, I should create a vlan and assign DHCP to it, establish firewall rules and it will work with my un-managed switch for now? Then my next step in this wonderful learning curve will be to acquire a managed switch and work on separating my traffic such as Voip and access points? Also, just to clarify, I CAN route traffic from the un-managed switch to a managed switch and then to the pfSense box via vlans?
Again, I am grateful for the assistance and best wishes
-
Also, just to clarify, I CAN route traffic from the un-managed switch to a managed switch and then to the pfSense box via vlans?
Yes, the unmanaged switch will pass the VLAN traffic to managed switches, where the VLAN can be handled as desired.
-
Also, just to clarify, I CAN route traffic from the un-managed switch to a managed switch and then to the pfSense box via vlans?
Yes, the unmanaged switch
willmight pass the VLAN traffic to managed switches, where the VLAN can be handled as desired.It's up to you if ya want to have bad design & potential security holes….
Not all dumb switches pass vlan tags correctly. Some do, others don't.
-
The difference being the VoIP phone is specifically designed to deal with dot1q, as is the switch it is connected to.
Just going to have to agree to disagree.
When I sniff an access port I don't expect to see every VLAN on campus.
You do.
Go ahead.
We don't need to talk about the fact that any device anywhere in the networks you design can hop onto any VLAN they want by simply tagging appropriately.
I am not advocating putting user's computers on a trunk port, thought that may be necessary when running VoIP & data through the same port, with VoIP on a VLAN, when using other than Cisco gear.
In that situation, when you're configuring the switch, you allow only the desired VLAN, should there be others that you don't want available to users.
Even with VLAN traffic on the wire, a computer has to be configured to access it. That requires admin rights, which users don't generally have in business environments.The main point of my argument is that an unmanaged switch does not cause the problems some people imagine. For example johnpos, in another thread, claimed that the switch would not see the MAC addresses. That's nonsense, as the MAC addresses are completely unchanged and in the same place as always. A switch passes proper Ethernet frames and a frame with a VLAN tag is still a valid frame, but with a different Ethertype than before. The original Ethertype is still there, just 4 bytes further back, and restored to it's original position when the VLAN tag is removed.
So, in the corporate world, with managed switches, by all means use access ports, configured for the appropriate VLAN, bearing in mind VoIP on VLAN may require placing users on a trunk port. In a small network, an unmanaged switch would work just fine. Also there's nothing special with phones in this regard. They can be configured for VLAN or not, as could a computer. Other than the VLAN tags, what difference is there on the wire, when a phone and computer share a port? The phone could be configured with or without VLAN and it would cause the same amount of traffic on the wire either way. So, where's the problem?
-
sorry for opening up a can of worms. wasnt my intention. I just want to get the network off the ground and then build from there. I believe I grasp the concepts and the points of contention presented by all who have responded and I offer thanks for the input.
So, in theory unless I am wrong, I should create a vlan and assign DHCP to it, establish firewall rules and it will work with my un-managed switch for now? Then my next step in this wonderful learning curve will be to acquire a managed switch and work on separating my traffic such as Voip and access points? Also, just to clarify, I CAN route traffic from the un-managed switch to a managed switch and then to the pfSense box via vlans?
Again, I am grateful for the assistance and best wishes
I think to start you should forget about VLANs, especially since you have unmanaged switches. Get everything up and running first. It is by no means necessary to separate traffic onto VLANs, especially on a small home network. At a later point when you decide to separate traffic and get new switches/APs, etc, you can do so.
As for the question about combining managed and unmanaged switches, this is the 'can of worms." Without getting into when/whether it will work, suffice to say it is not a recommended practice.
-
The only place that dumb switches can play a part in a vlan network that is ok to do as a downstream switch from an access port on specific vlan. Say you have a small smart switch that you are doing vlans. And on one of these vlans you want to place more devices so you need more ports. All of these ports will be on 1 vlan.. So in that case you could use a dumb switch connected to your smart switch with the smart switch setting that uplink port to be on whatever vlan you want all the dumb ports to be on..
This is fine to do if you need to save a few bucks and have no need to do multiple vlans on the dumb switch.. This dumb switch will only ever see traffic for the vlan its connected too. That being said a entry level smart switch these days is only a few bucks more than a dumb switch.. Comes down to how many ports you need, etc. What feature set you want on your "smart/managed" switch, etc. But there are many many "smart" switches that are sub 100$ as low as 30$ etc.. (with some caveats on some of these real cheap ones).. The tp-link 108E you see all over the place does not allow you to remove vlan 1 from any of the ports.. But its far better than trying to do vlans over a fully dumb switch that is for sure.
"It is by no means necessary to separate traffic onto VLANs, especially on a small home network"
While it is not "necessary" no - with the mass spread of iot devices and their lack of security.. I would highly recommend separation of such devices from you normal network, with tight controls on what they can and can not do either to your other vlans or even outbound. And not a bad idea to keep an eye on what they are doing outbound, etc.
With pfsense, a few dollars for a switch and AP that can do vlans - and you can isolate and separate with ease..
-
The only place that dumb switches can play a part in a vlan network that is ok to do as a downstream switch from an access port on specific vlan. Say you have a small smart switch that you are doing vlans. And on one of these vlans you want to place more devices so you need more ports. All of these ports will be on 1 vlan.. So in that case you could use a dumb switch connected to your smart switch with the smart switch setting that uplink port to be on whatever vlan you want all the dumb ports to be on..
This is fine to do if you need to save a few bucks and have no need to do multiple vlans on the dumb switch.. This dumb switch will only ever see traffic for the vlan its connected too. That being said a entry level smart switch these days is only a few bucks more than a dumb switch.. Comes down to how many ports you need, etc. What feature set you want on your "smart/managed" switch, etc. But there are many many "smart" switches that are sub 100$ as low as 30$ etc.. (with some caveats on some of these real cheap ones).. The tp-link 108E you see all over the place does not allow you to remove vlan 1 from any of the ports.. But its far better than trying to do vlans over a fully dumb switch that is for sure.
"It is by no means necessary to separate traffic onto VLANs, especially on a small home network"
While it is not "necessary" no - with the mass spread of iot devices and their lack of security.. I would highly recommend separation of such devices from you normal network, with tight controls on what they can and can not do either to your other vlans or even outbound. And not a bad idea to keep an eye on what they are doing outbound, etc.
With pfsense, a few dollars for a switch and AP that can do vlans - and you can isolate and separate with ease..
-
With pfsense, a few dollars for a switch and AP that can do vlans - and you can isolate and separate with ease..
Like with those TP-Link managed switches. ;)
-
Broken, crappy gear is a completely separate issue than broken, crappy design.
-
We have been through this before.
The VLAN frames will be ignored by any device not configured for that VLAN.
Maybe.
You cannot depend on something that does not speak (or is not configured to speak) dot1q to do the right thing with dot1q traffic. It might or it might not.
If EVERYTHING connected to the switch is dot1q-aware then yes, as long as the switch doesn't mangle the frames somehow it should work.
I consider your advice in this case to be pretty lousy.
In other words, undefined behavior by the spec with arbitrary implementation and tested by manufacturers.
-
In other words, undefined behavior by the spec with arbitrary implementation and tested by manufacturers.
What is defined is switches pass valid Ethernet frames and VLAN tagged frames are still valid Ethernet frames. For a switch to pass a frame, it requires source & destination MACs and a valid CRC. If it has those, the frame is valid and passed, no matter what's between the source MAC and CRC.
What is also defined is devices not configured for a VLAN ignore any VLAN frames.
Unless you examine the Ethertype field, you can't tell whether it's a VLAN frame or not.
Managed switches can look at the VLAN tag and take appropriate action. Unmanaged switches just pass it on as usual.
Here's a list of Ethertype values that could be found after the source MAC. And with 802.3, there could be any number, up to 1500. It makes no difference to a switch. It just passes the valid frames.
https://en.wikipedia.org/wiki/EtherType#ExamplesOn a modern LAN, you're likely to see 0x0800 for IPv4, 0x86DD for IPv6 and 0x9100 for VLAN tags. You may also see 802.3 frames for spanning tree.