VLANs. Use an assigned interface as parent?



  • I've been reading and playing around with VLANs in my lab. One thing I'm wondering about that I haven't seen an answer for is about the VLAN parent. 99.9% of the time, I see people using LAN as the parent interface. However, one blog writeup said that was bad practice and you should really be using an unassigned interface as the parent for your VLANs and to leave the LAN interface alone.

    Is there anything to this or is it a load of nonsense?



  • @KOM

    I have also seen that and don't understand why. If you have separate interfaces, you'll need a switch to combine them, to be sent over the wire. If you don't do that, and go with separate networks, there's no point of having VLANs. All a VLAN tag is, is a different Ethertype value, in the first 2 bytes after the source MAC, and an extra 4 bytes in the frame, to handle the tag. That's it. There is nothing magic about VLANs that make them special in any other way. Putting VLANs and native LAN on the same wire is no different than IPv4 and IPv6 on the same wire. It was the same back in the days of NetBIOS mixed with IPv4, IPX or even SNA. They're all valid Ethernet frames.

    Incidentally, when I was at IBM, back in the late 90s, we had NetBIOS, IPv4 and SNA all on the same token ring network. Same deal.



  • The only thing I could imagine was suspicion of VLANs in general and the fear that they could somehow escape the boundary and be able to mingle with LAN traffic.



  • @KOM
    Well, they're all on the same wire, so in that sense they're already mingled. Beyond that, the device has to be configured to support VLANs. Managed switches do that, of course, but many devices don't, so they just ignore the VLAN frames. Even computers that support VLANs have to be configured to do so and if the computer is properly locked down, then even an knowledgeable person couldn't enable VLANs. The only instance I can think of where the packets mingle is with the flakey TP-Link gear. Regardless, having separate interfaces has nothing to do with that.



  • Mostly nonsense, but prone to a lot of misunderstanding! I have seen plenty of messages on the forum with a tone of thou shalt only use another interface and it shall thusly only be using tagged frames. Yeah it will work too, but isn't necessary, just uses more interfaces.

    The thing you need to keep in mind is that when people talk about VLANs there is some amount of confusion with the jargon as different terms means different things to different people depending on what their networking background is, thanks to a lack of consensus among the industry.

    An example:
    In the Cisco world a trunk is considered to be an interface that will pass all the vlans (unless explicitly listed), but in the HP/Aruba world, trunk means an aggregate interface that might run LACP.
    Keep in mind that on a managed switch, on its backplane, all frames always have tags, even if you aren't using any VLANs.

    Some terms for reading the rest:

    • Tagged: There is a VLAN-ID present in the frame
    • Untagged: There is no VLAN-ID present in the frame, it is just a normal packet.
    • Access mode: The switch port is only participating in a single VLAN and all communication is untagged.
    • Trunk mode: The switch is going to participate in multiple VLANs.
    • Native VLAN: When operating in Trunk mode, the VLAN, typically by default VLAN 1, that is sending or receiving untagged frames.

    From a FreeBSD / pfSense perspective, the parent interface will be running untagged frames, and the VLAN sub-interfaces will be tagging the frames. The underlying OS, FreeBSD fully supports this, but the switch it connects to needs to be setup accordingly.

    An example:

    • Configure the switch port 1 in trunk mode, or whatever your vendor calls it.
    • Set native vlan 1, and add VLAN 2,3,4 to the trunk.
    • Untagged frames arriving from the device connected to port 1 will be placed onto VLAN 1 internally in the switch backplane.
    • Frames that were part of VLAN 1 that leave port 1 will have their VLAN tag stripped off before going out.
    • Tagged frames arriving on port 1 that are tagged for VLAN 2, 3 or 4 will be accepted and delivered to the backplane. Frames arriving from other VLANs will be dropped.
    • Tagged frames needing to be sent out port 1 will only be from VLAN 2, 3 or 4, so for example a broadcast on VLAN 3 will leave port 1, with a tag of 3, but a broadcast on VLAN 99 won't leave port 1

    Setup the pfSense:
    LAN interface: 192.168.11.1/24 In this case the LAN interface is untagged on VLAN 1
    VLAN 2 interface: 192.168.22.1/24. This will be tagged frames on VLAN 2
    VLAN 3 interface: 192.168.33.1/24. This will be tagged frames on VLAN 3
    VLAN 4 interface: 192.168.44.1/24. This will be tagged frames on VLAN 4
    Be sure to setup appropriate firewall rules to allow communication between the various networks.

    Add your devices to the switch
    If you want a PC to use only VLAN 3, then you would set the corresponding port to access mode on vlan 3. This means that the switch will only allow the port to participate in VLAN 3. There will be nt tagged frames sent from the port (it will strip off VLAN 3 tag before transmitting the frame), and any tagged frames received on the port will be dropped.

    If you have a VoIP phone then things get a bit more complex, let's say that VLAN 2 is your voice VLAN and VLAN 3 is your PC VLAN and that you want to connect a PC to the second port on the VoIP phone or maybe directly to the port.
    You would typically set the switch port to trunk mode (yes, some vendors have a hybrid mode, some auto-detect voip phones, etc), set trunk mode with vlans 2 and 3, and set vlan 3 as native vlan. The phone is configured similarly.
    This will allow you to use the port for a dual purpose, if you plug the phone in, it will forward the data VLAN (3) out the second port of the phone, but if you plug a PC into the port, you'll also get the data VLAN (3) because it is untagged.

    If you want to use an access point that supports multiple SSIDs with different VLANs or many VLANs on a single SSID, you would configure the switch port in trunk mode, add the VLANs you want, and the native vlan set to the VLAN you want the management interface of the AP to be on.

    If you want to connect another switch and forward all the VLANs to it, then set the port in trunk mode, and make sure all VLANs are configured. The native VLAN needs to be configure the same way on both switches. Alternatively if you want to run only tagged VLANs between switches, some vendors REQUIRE that you have at least one native VLAN, then you could use some "unused" VLAN and set that.

    Lastly, if you are using Cisco switches (like 2960, or 3750), if you use something other than native VLAN 1, STP, and VTP will get pretty unhappy.

    Good luck!



  • @awebster said in VLANs. Use an assigned interface as parent?:

    In the Cisco world a trunk is considered to be an interface that will pass all the vlans (unless explicitly listed), but in the HP/Aruba world, trunk means an aggregate interface that might run LACP.

    I first came across VLANs on Adtran gear, which used trunk and access ports, just like Cisco. Adtran's AOS is pretty much a clone of Cisco's IOS.

    I agree there's a lot of misinformation and superstition around VLANs, as many people don't understand them. Also, different names for the same thing from different companies is nothing new. I have many years experience in the telecom field and just working with someone from a different carrier often involves determining what they mean by a certain term.



  • My tiny brain is still having a hard time wrapping my head around everything VLAN-related. The last time I mentioned how I was weak on VLANs, someone recommended I read this 600+ page book...

    @awebster I think I may have understood 4 or 5 of the words you used... 😆 😆



  • @KOM said in VLANs. Use an assigned interface as parent?:

    My tiny brain is still having a hard time wrapping my head around everything VLAN-related. The last time I mentioned how I was weak on VLANs, someone recommended I read this 600+ page book...

    A VLAN is supposed to look like a physically separate network, even though it's sharing the network. As mentioned, a VLAN simply has a 4 byte tag inserted, which the hardware recognizes as a separate "network". The tag uses a different Ethertype value, to differentiate it from other Ethernet traffic. Other frame types, such as IPv4, IPv6, IPX and many more, have a different Ethertype value. The only way traffic is supposed to pass between different VLANs (and native LAN) is via a router or layer 3 switch. Some people will try to claim some hardware will not pass VLAN frames. This is nonsense, as any Ethernet switch, etc., is supposed to be able to pass EVERY frame type. The only possible issue would be ancient gear that can't handle the extra 4 bytes, when the full 1500 byte MTU is used. In that case, just configure the network for 1496 MTU and problem solved. However, given that i's been 20 years since the frame size was expanded to handle VLAN tags and more, that would have to be really ancient gear.

    So, if you're working with VLANs, just consider them to be separate networks, connected via a router, and you'll be fine.


  • LAYER 8

    yeah, like you say @awebster , i'm experimenting vlan with my cisco and using the wizard it set the port to trunk but i can manually select access mode if i want a single vlan to pass. also i've made some test with other switch, i was unable to find an unmanaged switch that was unable to pass vlan tag, i think we was discussing about it with @JKnott in another 3d? well even chinese 5 port shit was able to handle it. not that i'm suggesting to use it for that but it was a curiosity that I had to satisfy



  • I understand at an abstract level. I think my main problem with them is knowing the proper flow of things, and a zillion What if? and What about? questions that you don't typically find answers to in a book. For example, I don't understand the circumstances under which tags are added or removed, or why you would want untagged traffic for scenario X but tagged for Y, etc. Fortunately for me, I don't really need to care about them at the moment -- just like IPv6.



  • Incidentally, several years ago, I worked on a network with 3 VLANs on top of the native LAN. It was in a retirement home. The native LAN was the office network, with VLANs for the VoIP phone system, residents Internet access and management separate from the native LAN, so that users couldn't interfere with device configuration, even if they had the password. The WiFi access points also used the VLANs for separate staff and resident SSIDs.



  • I have a Ubiquiti LR-AP and I've wanted to segment the trusted house wifi traffic versus untrusted, but I run a Mikrotik hEX at home and I have no idea how to do VLANs on it (I have no desire to learn either since I hate their interface.) Maybe one day if I can ever afford a Netgate device, I'll reconfigure everything.



  • @KOM

    As I said, start with thinking in terms of separate networks. Then apply VLANs as necessary. The VLAN tags are used only on trunk ports, where you want to have more than one "network". This is often used with VoIP phones and multiple SSID access points. Access ports do not ever carry tags, other in the unique exception of some switches that can recognize VoIP phones and put them on the VLAN. The phones (or other equipment) are recognized by the MAC address prefix, which is configured into the switch. The tags are added or removed by switches and other equipment configured to use them. For example, pfSense can be configured to use VLANs. So, it would add the appropriate tag when sending a frame and remove it from received frames. In a managed switch, you could have several VLANs on the trunk port and the switch sorts them out to the various access ports, where the tag is removed.

    One very useful way to learn about this is with packet capture. Managed switches generally have a port mirror function, where a computer running Wireshark can monitor traffic for a different switch port. With Wireshark, you can examine the frames, see the VLAN value and more. In fact, a few years ago, I bought a cheap 5 port managed switch, just for that purpose.



  • @KOM

    I have no experience with either Ubiquiti or Mikrotik, so I can't help you with them, but the principles should still apply.



  • Access ports do not ever carry tags

    Ubiquiti apparently allows you to define multiple SSIDs on different VLANs, so it must have some notion of them. Or is this me not understanding again?

    Mikrotik is a nice little affordable unit but it's based on iptables and their interface is powerful but difficult. I would much prefer a Netgate box but I don't have $350 for a home router. The Mikrotik was $130 for a PoE unit with 5 switch ports.



  • @KOM said in VLANs. Use an assigned interface as parent?:

    Ubiquiti apparently allows you to define multiple SSIDs on different VLANs, so it must have some notion of them. Or is this me not understanding again?

    Yes. If a port carries VLANs it's a trunk port and if not it's an access port, according to Cisco. Ubiquiti may have different terms for the same thing. That access port will connect to a trunk port on the switch, so that the VLANs will be available. It then strips off the VLAN tags, when sending the frames to the appropriate SSID.



  • @KOM said in VLANs. Use an assigned interface as parent?:

    @awebster I think I may have understood 4 or 5 of the words you used...

    While I am not an educator by any strech of the imagination, I do, in my role as network architect, spend a lot of my day explaining networking concepts to my clients, so any feedback you can bring on how I can make it clearer / better would be much appreciated.



  • @JKnott said in VLANs. Use an assigned interface as parent?:

    So, if you're working with VLANs,

    ... you must absolutely, unequivocally, unconditionally, with out a doubt, be using a managed switch. I had to add this in because VLAN questions come up pretty frequently on the forums only to discover after a bunch of back-and-forth, that the OP isn't using a managed switch!



  • @awebster

    A managed switch is needed if you want to configure VLANs, separate access ports from trunks, etc. An unmanaged switch will pass VLANs just fine, but that's all it can do, management has to be done elsewhere. Regardless, I am in favour of managed switches in general. These days, I would only put a dumb switch in a situation where a managed switch would bring no advantage. On my home network, I have a mananged switch, but also an unmanaged one in my living room, connecting my TV, A/V receiver, Blu-ray player and PVR to the single Ethernet port there.



  • @JKnott I have seen both managed and unmanaged switches do strange things:

    • An HP 8 port managed (1800-8G) switch, which while it appears to work properly on the surface, with IPv6 DHCPv6 it is completely broken, the connected device gets an IPv6 address on every VLAN, despite it not being configured to allow those VLANs!
    • Netgear GS110TP managed switch allows you to configure more than one untagged VLAN on a single port.
    • Unmanaged switches, typically the cheap Chinese variety not passing anything frames with VLAN tags.


  • @awebster said in VLANs. Use an assigned interface as parent?:

    • Unmanaged switches, typically the cheap Chinese variety not passing anything frames with VLAN tags.

    If you know, does this confuse the ethernet controller, then everything gets dropped?

    Jeff



  • @awebster

    Then those switches are defective. That HP sounds like the TP-Link switches.

    Also, what is an unmanaged switch doing checking for a VLAN tag? The contents of the Ethertype field in the tag is all that makes the difference between a VLAN and any other Ethernet frame type. The Ethertype field is just data in the frame. That same field, in addition to the Ethertype on DIX II, is used for length with 802.3 Ethernet, which means any value, up to 1500, is valid. Do unmanaged switches check for the contents of that field, when they're not supposed to?



  • @akuma1x

    I used to have a cheap Chinese switch on my network and it had no problem passing VLAN tagged frames. When someone makes this sort of claim, it would be nice if they did some testing to verify it's actually happening. Again, any unmanaged switch that can't pass VLANs is defective.



  • @JKnott said in VLANs. Use an assigned interface as parent?:

    Again, any unmanaged switch that can't pass VLANs is defective.

    I think there is another dimension to this, namely QoS. When running in a multi-vlan network, if you have voice and/or video or other highly drop sensitive traffic to contend with, passing that through an unmanaged switch may not respect 802.1p and / or DSCP in the frames, unless it specifically says it is supported in the product docs.
    While YMMV with unmanaged switches, I would not recommend passing any VLANs through them, ever. Saves the headaches of having to go back later and troubleshoot the network because you added some new VLAN or protocol and things aren't working the way you expect it to.
    Managed switches have come down in price quite a bit lately, so there's really no excuse not to use them.



  • @awebster said in VLANs. Use an assigned interface as parent?:

    passing that through an unmanaged switch may not respect 802.1p and / or DSCP in the frames

    I would never expect it to.

    Think about the evolution of Ethernet. Originally, the NICs connected to a coax cable, without switches or even hubs. Then came hubs, which had to behave exactly as the original coax networks, collisions and all. Then came switches, which remained transparent, like hubs and coax, but also brought in full duplex operation and things went from there. This means that an unmanaged switch is supposed to appear to the computers exactly the same as a hub or coax network, in that it does absolutely nothing to interfere with the traffic. It was only with managed switches that the ability to do more came in.

    Bottom line, there is no difference at all in the way unmanaged switches behave compared to hubs and coax, other than full duplex and higher speeds.



  • @JKnott said in VLANs. Use an assigned interface as parent?:

    I would never expect it to.

    Sadly some claim to. Some vendor's unmanaged switches mention QoS support in their literature, so at first glance your initial reaction is "hey, it must be a managed switch", only to realise that nope, you were fooled, they call it a "smart switch". This is confusing since yet other vendors call their less than a full CLI of management a "smart" managed switch.

    Bottom line, there is no difference at all in the way unmanaged switches behave compared to hubs and coax, other than full duplex and higher speeds.

    Well said! I might have added "are supposed to" before behave, because... broken.



  • @akuma1x said in VLANs. Use an assigned interface as parent?:

    If you know, does this confuse the ethernet controller, then everything gets dropped?

    Confuse, probably... The switch I was using (unmanaged Netgear PoE) would correctly pass the untagged frames but drop the tagged frames. I tried it in a home VoIP setup with PC plugged into the back of the phone. Phone kept coming up on the the untagged data VLAN, it couldn't see voice VLAN. Moved it onto a managed switch (the port that was feeding the unmanaged switch, so config was identical), and it worked first shot.



  • Moving back to the OP's question,
    The easiest way I've come up with to explain vlans is to first think of dividing the switch into separate switches. You have different networks on those switches, and could put them in a segregated opt interface on the firewall. Ports 1-12 belong to lan and ports 13-23 are the guest lan. Now imagine the separate switches, or virtual lans, being represented by numerical tags the switch attaches to the traffic. EQ- your lan is 10 and your guest is 20. You configure port 24 on your switch to carry traffic for both networks. Traffic from you lan gets marked 10 and guest traffic gets marked 20. You connect 24 to the firewall, where instead of setting up lan and guest on separate ports, you tell the firewall that traffic marked 10 is your lan, and if it's marked 20, it's guest traffic.
    Vlans in Unifi are easy- in this example, you would set the switchport the ap is in to untagged 10, tagged 20.
    You would then create a wireless ssid for guest and specify vlan 20.
    I'm using 10 and 20 here, but using the parent interface is basically using the default vlan 1
    If you stick to the default vlan for you lan, it makes things a bit easier, but by Cisco standards, this is sloppy and poor practice. Traffic somehow not getting tagged comes out on vlan 1, you would ideally not want this on your lan.


  • Netgate Administrator

    The biggest confusion I see is people using the term VLAN1 to mean untagged traffic and encoutering something configured to actually use VLAN1 tagged. Never use VLAN1!

    The reason I recommend not using tagged and untagged traffic on the same interface if you can avoid it is that the most common problem I see with (usually cheap ass) switches is tags getting stripped when they shouldn't. Those can end up on the parent interface which is harmless if it's unassigned. Of course that should never happen but....

    Steve



  • I use VLANs to segregate my WiFi traffic and VPN; I have a VLAN for my private WiFi, a VLAN for my guest WiFi, a VLAN for my VPN, and my wired LAN is untagged. All of it plugs into a cheapo unmanaged D-Link gigabit switch, which passes it just fine. All of this goes out over my LAN port (assigned as such).

    The APs are VLAN-aware (and tag and filter the appropriate packets) and of course pfSense is VLAN-aware on the other end. Sure I might be able to do some magic configuration on one of my wired ethernet systems to be able to touch VLAN-tagged traffic, but given that there are only ethernet ports in the office and bedrooms, if a bad actor has access to my wired LAN, I have bigger problems than them picking up stuff off the VLANs.

    In the meantime, any communication between those three segments (Guest WiFi, Private WiFi, LAN) is at the pleasure of my firewall rules -- which is to say guest WiFi can't see 💩 while the others are, by and large, unfettered (though there are some restrictions on VPN).


Log in to reply