Newb questions - switches managed and unmanaged
-
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.
-
All great.. You still have the issue with every single broadcast/multicast frame going out over every single port… I showed you this in that other thread were you yet again suggest someone just use dumb switch for their vlans!
This is some of the WORSE freaking advice anyone could possible give!! Especially to people that are not up to speed on vlans.. I am just flabbergasted why someone with any networking understanding at all would ever suggest such a thing.. If you needed to use the dumb switch to be a repeater for a long run or something on your trunk uplink.. Ok do in a pinch, etc. But that you actually suggest users do this for their setup is just beyond me..
I just ordered different "smart" switch to replace that tp-link I got to play with.. Cost me a whole $35 bucks.. wow what a bank breaker for a 8 port gig switch - that actually understands vlans.. And this one allows you to remove vlan 1 from the ports its not suppose to be on ;)
-
Johnpoz. Please understand that I am not advocating managed switches not be used. In fact, I encourage their use. I'm just trying to point out some of the fallacies that exist, such as your claim that an unmanaged switch wouldn't know where to forward a VLAN frame. As far a receiving all those broadcasts, that would only happen if a device is configured to receive the VLAN. In this case, it's no worse than other unwanted broadcasts. If you have VLANs, there will be essentially the same amount of traffic on the network, including on trunks and going through switches etc. The only difference is that with a managed switch, the devices on access ports won't see anything from other VLANs. That's it. Now, with VLANs, you have some control over which switches receive the frames and what access ports pass it, but other than a bit of wasted bandwidth, unwanted VLAN frames will not harm network devices not configured for the VLAN, because they simply ignore those frames. Also, with the move to IPv6, broadcasts will disappear and the multicasts that replace them can be far more selective.
I bet after this discussion, you now know your ideas about the switch not knowing how to forward a VLAN frame were wrong and people here have a better understanding of Ethernet, VLANs etc. There's nothing magical about VLAN frames. They're just another Ethernet frame and passed as usual by switches.
BTW, I currently have a Cisco SD216 unmanaged, 100 Mb switch on my home network. I am considering replacing it with a Cisco managed gigabit switch, to pick up some of the features a managed switch provides (I use port mirroring a lot!). In the mean time, VLANs work just fine with the current, unmanaged switch. As I mentioned a while ago, in another thread, I experiment with things on my network and this is how I know VLANs do not have a problem with unmanaged switches. Instead of just taking a position, I verify it by trying and using Wireshark to see what's actually happening. I also do a lot of research, including that Ethernet book I mentioned.
-
And my position is taken from experience with unmanaged devices that DID NOT properly forward dot1q frames. You do realize it changes the maximum frame size from 1518 to 1522 bytes I assume? You must acknowledge that there might be some devices out there that get confused by that and drop your perfectly valid dot1q frames because they were not designed to deal with them.
It has been said time and time again that it might work and might not.
Though I em extremely glad it works for you in your environment with your gear, It is still lousy design practice and lousy advice.
 -
You do realize it changes the maximum frame size from 1518 to 1522 bytes I assume?
Yes, and I did mention older equipment may have problems. However, the spec has been updated over the years to allow larger frame to accommodate VLAN tags. Also, as I mentioned, a lot of equipment can now handle jumbo frames, which can be 9KB or more, a lot bigger than a VLAN frame.
-
Here's a bit more info:
"802.3ac 1998 Max frame size extended to 1522 bytes (to allow "Q-tag") The Q-tag includes 802.1Q VLAN information and 802.1p priority information."
from https://en.wikipedia.org/wiki/IEEE_802.3The 802.3ac spec, which extends the frame size to 1522 bytes was set in 1998. That's 19 years ago and a lot of equipment and been made, sold and scrapped in that time. Back around then, switches and 100 Mb were just starting to become popular and I bought an 8 port 10 Mb hub that cost then, more than twice what I paid for a 5 port managed gigabit switch last year.
-
I had a brand new, stupid, powerline adapter that would not pass 1522 and that was a lot more recent than 1998.
Still lousy advice.
Just stop. You lose. It might or might not work.
-
"I bet after this discussion, you now know your ideas about the switch not knowing how to forward a VLAN frame were wrong"
No not really, as have stated in every one of these threads… And there have been WAY too many of them when you bring it up.. That it might or might not work, etc. I have some old 10/100 switches for just drop them.. Been doing this for year and years - before there were even switches ;) To be honest many days it seems like yesterday was adding co processors to 486 machines and installing tcp/ip on the 3.1 windows they were running. Building still had thicknet in areas.. Remember the coax T connectors..
And can tell for FACT that many switches back a few years, latter than 1998 that is for sure!! would drop them.. Why should a "dumb" switch support Q-tag, etc..
I am with Derelict - if you want to discuss different hardware and the max frame size it will pass - great.. I have some older switches on the shelf I could fire up, etc. And we could test them.. But please do not bring up such HORRIBLE HORRIBLE advice to someone asking about vlans.. And even suggest to them that they can just use a dumb switch, etc. It FUD to be honest that your spreading.. And users are like parrots... They really do not understand a debate about "if" something can work, etc.. All they get out of is I heard on pfsense that I don't need smart switch to use vlans.. And such FUD spreads and spreads!
To be honest: Mods should go into every single thread where you have suggested such nonsense and put in a BIG RED NOTE stating this not valid advice - do not do this!! This is BAD!!
-
Hope this guy does not secure Networks for a living ;)
-
Do you guys realized the OP never even asked about VLANs? His question was whether pfSense requires managed switches. The answer is "no."
