Setting up pfSense for VLAN and trunk port
-
@johnpoz https://www.neowin.net/forum/topic/1317426-pfsense-first-time-build-question/
with a little bit of gimp....What program did you use? visio? dia?
-
If your going to play with vlan - yes get a vlan capable switch.. While sure a dumb switch should not strip the tags.. Its not going to isolate any tagged traffic either.. So any broadcast traffic is going to go tall all ports! So anything connected to the switch will see all broadcast traffic no matter what vlan its tagged for.
edit: those were done in visio.
edit2: Ah my alias over on neowin.. Sssh - don't spread that around ;)
-
@johnpoz said in Setting up pfSense for VLAN and trunk port:
While sure a dumb switch should not strip the tags.
Why would any dumb switch strip the tags? A tag is just 4 more bytes, with the new Ethertype field set to indicate a VLAN.
-
I didn't say it would.. Dude you and your running vlans over a dumb switch.. Get over it already.. It has nothing to do with the switch won't strip them... Its the fact that it won't actually isolate the traffic like it should ;)
edit:
And while security might not be a major concern in a "home" network.. Since the switch doesn't actually understand tags, and has no way of limiting what tags can be used on specific ports.. Anyone that plugs into such a network can just set their device to tag their traffic for whatever vlan ID they want to be on. And its not like it would be hard to see even what IDs are play because every port is going to see all the different vlan ID via the broadcast traffic.If say the min cost of a vlan switch was like 100's of dollars or something, I might see taking a shortcut in a home setup.. But a vlan capable switch can be had for less than a 4 pack of good beer ;)
If your wanting to run vlans, then you need vlan capable switch - PERIOD! Its the cost of wanting to run vlans.. Put your dumb switches downstream of the smart switch, where all the devices on the dumb switch will be in 1 vlan, etc.
So its not like your dumb switches have sit on a shelf or get thrown away, they can still be quite useful in a growing network.
-
@johnpoz said in Setting up pfSense for VLAN and trunk port:
I didn't say it would.. Dude you and your running vlans over a dumb switch.. Get over it already.. It has nothing to do with the switch won't strip them... Its the fact that it won't actually isolate the traffic like it should ;)
I wasn't advocating one way or the other re using VLANs, although I do recommend them. My issue is with those who seem to think there's something magic that keeps a dumb switch from passing tagged frames, when the difference between tagged and untagged is the contents of the Ethertype field, which a dumb switch is incapable of even recognizing, let alone blocking.
-
I have had non-dot1q gear refuse to pass dot1q frames. If the spec sheet doesn't say 802.1q, you get what you get if you try to pass dot1q frames with it. Don't expect a lot of sympathy here if it doesn't work for you or you have strange problems.
-
@Derelict said in Setting up pfSense for VLAN and trunk port:
I have had non-dot1q gear refuse to pass dot1q frames.
How was it doing that? In order to block a tagged frame, it has to recognize it. I don't see an unmanaged switch doing that. A switch is supposed to pass all valid Ethernet frames, regardless of the Ethertype/length field contents. On the other hand, a managed switch could be configured to block them.
-
No idea, dude. Untagged would pass, tagged wouldn't. It was a MoCA bridge that has since been punted downrange with prejudice.
-
Whatever you decide to do make the 3rd octet of the IPv4 addresses ( assuming your using /24s ) the VLAN ID, makes things easier in the long run
-
The switch chips used may support tagging, so the default behaviour is depending on the setup the manufacturer uses. This can vary from batch to batch as they often change chip vendors or the setup. The behavior of a cheap unmanaged switch and a cheap smartmanaged/managed switch of the same vendors can be identical/with little difference. Most low end switch chips support tagged frames, the setup is stored in the eeprom or microcontroller but it's not always the case. for the others vlan tag are considered invalid frames
-
@kiokoman said in Setting up pfSense for VLAN and trunk port:
The switch chips used may support tagging
What's to support? A tag is simply a different Ethertype and 4 more bytes. Since a switch is supposed to pass all Ethertypes, why should it block VLAN?
Take a look at an Ethernet frame. It has the destination and source MACs, Ethertype/length, payload and CRC. That's it. Why should an unmanaged switch consider the VLAN tag or any other Ethertype?
On the other hand I have come across some computers (notebooks) that don't support VLANs.
Incidentally, I'm probably the only one here who's actually hand wired an Ethernet controller. A bit over 30 years ago, I wired up a couple on prototyping boards for Data General Eclipse computers.
-
sorry it was not clear, the setup stored in the eeprom or microcontroller tell the chip to consider vlan tag invalid frames or not. so you can possible end up with a unmanaged switch that make it pass or not.
-
@kiokoman said in Setting up pfSense for VLAN and trunk port:
sorry it was not clear, the setup stored in the eeprom or microcontroller tell the chip to consider vlan tag invalid frames or not. so you can possible end up with a unmanaged switch that make it pass or not.
Why would an unmanaged switch even care? What's it supposed to do, if it's unmanaged? In order to not pass a frame, the switch would have to read the Ethertype field and say I don't want to pass this. Why go to all that trouble, when a switch is supposed to pass all Ethertype/length values?
BTW, in those Eclipse computers I used to work with, I actually worked at the microcode level, which is the programming within the CPU. Those systems used 4 AMD 4 bit slice processors to create a 16 bit CPU.
-
typical unmanaged switch has a nominal MTU of 1500 bytes. So does a typical managed switch. Adding a vlan tag adds 4 bytes, making the frame 1504 bytes long, other stuff actually can makes the frame bigger,
It is the frame size that prevents the unmanaged switch from passing the traffic, not the content of the frame.
Unmanaged switches deal with this as: dropping the frames, truncating the frames, crashing entirely, and sometimes working.Why go to all that trouble to set the switch like this .. i can only speculate here, could be a hardware limitation sometimes or could be a marketing decision like when they was selling the same identical cd burner with different firmware to cap speed at x2 x4 x8 and selling it with different price
-
Doesn't matter pass or not pass.. That is NOT THE POINT!!
They don't understand them, so they don't actually isolate traffic... Every port will see broadcasts from every vlan you setup on your devices with tags.
There is zero security - and all it takes is someone smart enough to use google, and vague understanding what a vlan is to jump them...
Your also just promoting BAD HABITS and misunderstanding to new users that wanting to get into vlans....
If you as a long time guy in the biz, who fully understands vlans and think its ok for whatever chewing gum and rubber band network your throwing together is ok with it that is fine... But you suggesting to some new person to vlans that its possible or could do or whatever with their existing dumb switch is just wrong at every freaking level - PERIOD!!
If you want to run a network with vlans, then your infrastructure needs to understand them and be able to actually use them - not just pass the traffic be it tagged or not. If your ok with some jury rigged nonsense on your network have at it... But please don't even mention it when some new user asks how do I do vlans..
-
@kiokoman said in Setting up pfSense for VLAN and trunk port:
typical unmanaged switch has a nominal MTU of 1500 bytes. So does a typical managed switch. Adding a vlan tag adds 4 bytes, making the frame 1504 bytes long, other stuff actually can makes the frame bigger,
As I mentioned, frame expansion, to 1522 bytes, happened 21 years ago, with 802.3ac. Since then, there has been further frame expansion to where 9000 byte jumbo frames are now often used. Some gear goes to 16K or so. So, any gear that can't handle more than 1500 would have to be pretty old. If you do find some, then reduce the MTU on your network to 1496, which will leave room for the tag. A couple of messages up, I mentioned I hand wired some Ethernet controllers. Back in those days, there was a hard limit because hardware (discrete logic vs ASICs as used now) was so expensive. On the other hand, there is a limit with 802.3 frames, where the Ethertype/length field contains a maximum length of 1500. Even then the length field now follows after the VLAN tag.
-
@johnpoz said in Setting up pfSense for VLAN and trunk port:
Doesn't matter pass or not pass.. That is NOT THE POINT!!
The point I've been trying to make is that people have a lot of assumptions that are false. There has never been a reason for unmanaged switches to block VLANs. Think back to the original Ethernet, which ran over coax cable, without switches or even hubs. There was nothing to block anything. When hubs came along, they behaved exactly like the coax, in that they didn't block anything. Then came switches, which then again passed everything, though since they buffered frames, there was a limitation on how big the frames could be. Switches started to become popular back in the late 90s, around the time of 802.3ac. However, at no point was there ever any reason to block VLAN frames in an unmanaged switch. As for using VLANs on managed vs unmanaged switches, I agree managed switches should be used and have one on my home network. But that does not mean unmanaged switches can't be used, nor shouldn't be used on a small network as you might find in a home network. There are also many applications where VLANs and native LAN are used on the same wire. One common application is VoIP phones that have a computer port. With these, a computer is plugged into the phone, which then connects to the switch. Another would be WiFi access points, with multiple SSIDs.
If I were to build a network today and had a say in the equipment used, then I would always go with managed switches, but I often don't have that say and have built many networks, in small businesses, without them.