Setting up pfSense for VLAN and trunk port

Derelict

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.

JKnott

@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.

Derelict

No idea, dude. Untagged would pass, tagged wouldn't. It was a MoCA bridge that has since been punted downrange with prejudice.

NogBadTheBad

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

kiokoman

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

JKnott

@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.

kiokoman

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.

JKnott

@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.

kiokoman

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

johnpoz

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..

JKnott

@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.

JKnott

@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.