VLAN confusion

[Josephny]

Still trying to understand VLANs.

Just watched this video, where the presenter is showing how to keep wlan and lan uses separated using vlans. I was hoping it would be a simple project that would further my understanding of vlans.

https://youtu.be/4UKRsrN91UE?si=uxf4SUzLGvt4wNGZ

The presenter creates 2 separate bridges (for WLAN and LAN). I’ve read many posts here where the recommendation is a single bridge.

And, there are so very many steps, some of which I understand and some not (like when to choose as the interface wlan1 and when to choose vlan10).

And, his set up is running 7.6 with WIRELESS (not WiFi), which I think means the older wireless package, right? Is this difference significant for the purposes of VLANs?

(Yes, I’ve read PCunite’s VLAN instructions about 20 times.)

[erlinden]

So sad to read that PCUnite’s topic is not sufficient. That is absolutely straight forward.
Can you share your current config and explain what you exactly want?

[Josephny]

So sad to read that PCUnite's topic is not sufficient. That is absolutely straight forward.
Can you share your current config and explain what you exactly want?

I truly do not mean to disparage PCUnite's work. I know it has helped many people, and it is obvious how much effort it took.

I don't have a config that I am working on.

I do have a complex (for me) environment that I would like to incorporate VLANs into (for the security and efficiency as well as for me to learn another super cool thing).

In a nutshell, I have 8 geographically separate locations, all running MT equipment and connected using Wireguard over Internet connections.

2 of these locations have Ubiquiti Unifi UDM primary routers that I added a hEX behind to handle Wireguard and a couple of other services.

All locations have wifi users, as well as wired cameras and IoT devices. Some has wired servers (Home Assistant, Blue Iris, Proxmox, etc.)

Basically, once a wifi user has access to any location, they are on a 192.168.x.0/24 network that is Wireguard-connected to all the other location's 192.168.y.0/24 networks. (Sort of like one big 192.168.0.0/16 network.) Luckily, I don't have (yet) any particularly good hackers at these locations.

[sindy]

The way you describe your network suggests that you may lack some bits of information. VLANs are intended to create virtually separated logical L2 networks on a physical L2 infrastructure (leaving L2 tunnels aside for a moment). The fact that people freely interchange the terms “VLAN” and “subnet” doesn’t help understanding the topic to novices - it’s just the best current practice to use a dedicated VLAN for each individual subnet that makes people not to distinguish between the two terms in common contexts. But to understand how VLANs work, what they are good for and where they can and cannot be used, it is necessary to distinguish between these two terms.

Can you tell the difference between an “L2 interface” and an “L3 interface”? Can you tell whether Wireguard is an L2 one or an L3 one and provide arguments for such a conclusion?

[Josephny]

The way you describe your network suggests that you may lack some bits of information. VLANs are intended to create virtually separated logical L2 networks on a physical L2 infrastructure (leaving L2 tunnels aside for a moment). The fact that people freely interchange the terms “VLAN” and “subnet” doesn’t help understanding the topic to novices - it’s just the best current practice to use a dedicated VLAN for each individual subnet that makes people not to distinguish between the two terms in common contexts. But to understand how VLANs work, what they are good for and where they can and cannot be used, it is necessary to distinguish between these two terms.

Can you tell the difference between an “L2 interface” and an “L3 interface”? Can you tell whether Wireguard is an L2 one or an L3 one and provide arguments for such a conclusion?

I have only the basic of understanding: L2 is data link (i.e., mac address) level; L3 is IP level. WG is L3 because it uses IP routing.

Subnets (such as the 254 (I think) /24 networks under 192.168.0.0/16) are also L3.

I do not understand the implications of VLAN’s purpose “to create a virtually separated logical L2 network.”

[Lokamaya]

In the past, before vlan was known, we needed many physical ports to deploy many subnets, i.e. each subnet attached to a specific port.

With vlan, we can deploy many subnets on few ports.

[sindy]

I do not understand the implications of VLAN's purpose "to create a virtually separated logical L2 network."

Before VLANs, devices connected to the same switch could all receive frames from each other - the switch only took care about the destination MAC address of each frame. If you wanted to prevent devices from one group from reaching devices in another group, each group had to use its own switch and no connection between the switches must have existed.

The next step is that you can "somehow" organize the ports on a switch into logical groups and allow each port to only forward traffic to other ports within its own group. These groups of ports already are virtual LANs (VLANs) but so-called port-based ones, and if you wanted to add more switches into such a setup, you would have to interconnect them using a dedicated cable for each group, making it impractical for multi-switch setups.

So rather than using some proprietary internal mapping table, 802.1Q (and 802.1ad) specify how to add the information about the group of ports (=VLAN) a given frame belongs to into the header part of the frame itself as it ingresses through the port. An additional header, called VLAN tag, is used for this purpose, and it gets inserted between the source MAC address field and the ethertype field of the Ethernet header (which is what actually happens in hardware, for other purposes, it is better to think abouth the same somewhat differently, not relevant right now). On egress, each port only lets a frame out to the wire if the VLAN ID in the frame matches the ID of the group the egress port belongs to, and removes the VLAN tag as it egresses the frame. So from the outside perspective, the switch behaves as if its ports were grouped into isolated port groups.

The above describes a behavior of "access" ports to a VLAN, i.e. those to which you connect equipment that itself does not support (or at least use) the concept of VLANs and VLAN tags.

But to make use of these VLAN tags to make it simple to extend the port groups across multiple switches, it is necessary to introduce "trunk" ports that belong to multiple VLANs. These ports do not remove or add the VLAN tags, just forward the frames unchanged. So if switch A and switch B are interconnected using a trunk port, a frame that entered switch A through an access port to VLAN 7 can egress through any other access port to VLAN 7 on switch A, but also get to switch B via the trunk port and egress through any access port to VLAN 7 on switch B.

From this point on, we switch from "what has to be done to partition on a common L2 network into multiple virtual ones" thinking to the "how can we make use of the 802.1Q tagged infrastructure beyond only creating virtual LANs with access ports".

Before, I said you would have to use one interconnection cable per VLAN if you wanted to interconnect two partitioned switches. With the trunk link between the switches, this is not necessary any more, but if you want a router to talk to two VLANs, you still need a dedicated physical interface on the router to be connected to an access port to each VLAN. So the next step is to make the router also understand 802.1Q, connect it to the switch using a trunk port, and take care about VLAN tagging and untagging on the router itself, using what Cisco calls "subinterfaces" and Mikrotik calls "VLAN interfaces".

Did any of the above help?

[Josephny]

I do not understand the implications of VLAN’s purpose “to create a virtually separated logical L2 network.”

Before VLANs, devices connected to the same switch could all receive frames from each other - the switch only took care about the destination MAC address of each frame. If you wanted to prevent devices from one group from reaching devices in another group, each group had to use its own switch and no connection between the switches must have existed.

The next step is that you can “somehow” organize the ports on a switch into logical groups and allow each port to only forward traffic to other ports within its own group. These groups of ports already are virtual LANs (VLANs) but so-called port-based ones, and if you wanted to add more switches into such a setup, you would have to interconnect them using a dedicated cable for each group, making it impractical for multi-switch setups.

So rather than using some poprietary internal mapping table, 802.1Q (and 802.1ad) specify how to add the information about the group of ports (=VLAN) a given frame belongs to into the header part of the frame itself as it ingresses through the port. An additional header, called VLAN tag, is used for this purpose, and it gets inserted between the source MAC address field and the ethertype field of the Ethernet header (which is what actually happens in hardware, for other purposes, it is better to think abouth the same somewhat differently, not relevant right now). On egress, each port only lets a frame out to the wire if the VLAN ID in the frame matches the ID of the group the egress port belongs to, and removes the VLAN tag as it egresses the frame. So from the outside perspective, the switch behaves as if its ports were grouped into isolated port groups.

The above describes a behavior of “access” ports to a VLAN, i.e. those to which you connect equipment that itself does not support (or at least use) the concept of VLANs and VLAN tags.

But to make use of these VLAN tags to make it simple to extend the port groups across multiple switches, it is necessary to introduce “trunk” ports that belong to multiple VLANs. These ports do not remove or add the VLAN tags, just forward the frames unchanged. So if switch A and switch B are interconnected using a trunk port, a frame that entered switch A through an access port to VLAN 7 can egress through any other access port to VLAN 7 on switch A, but also get to switch B via the trunk port and egress through any access port to VLAN 7 on switch B.

From this point on, we switch from “what has to be done to partition on a common L2 network into multiple virtual ones” thinking to the “how can we make use of the 802.1Q tagged infrastructure beyond only creating virtual LANs with access ports”.

Before, I said you would have to use one interconnection cable per VLAN if you wanted to interconnect two partitioned switches. With the trunk link between the switches, this is not necessary any more, but if you want a router to talk to two VLANs, you still need a dedicated physical interface on the router to be connected to an access port to each VLAN. So the next step is to make the router also understand 802.1Q, connect it to the switch using a trunk port, and take care about VLAN tagging and untagging on the router itself, using what Cisco calls “subinterfaces” and Mikrotik calls “VLAN interfaces”.

Did any of the above help?

Helped tremendously! I imagine it might be obvious to people who already understand these things, but the way you explained it is much clearer than I’ve seen elsewhere.

I will need to re-read this several more time (perhaps rephrasing it and making notes so I can better learn it).

I understand this is just the basics, but I would sure like to understand better what you were referring to about consuing IP subnetting with VLANs. Or, perhaps more importantly, how to think about an environment like mine with multiple locations each with its own /24 subnet and how VLANs would be best utilized.

Thank you.

[Josephny]

Still confused:

Regarding access ports:

On egress, each port only lets a frame out to the wire if the VLAN ID in the frame matches the ID of the group the egress port belongs to, and removes the VLAN tag as it egresses the frame. So from the outside perspective, the switch behaves as if its ports were grouped into isolated port groups.

“Egress” means a frame exiting the router or switch, right?

Do I understand correctly then that an “access” port on a router only allows frames to leave that have a VLAN tag that matches certain specifications (and then strips the tag)?

I am still confused.

From other readings/tutorials/videos, an “access” port is used to allow traffic regardless of VLAN tagging.

[sindy]

how to think about an environment like mine with multiple locations each with its own /24 subnet and how VLANs would be best utilized.

Since all the interconnections between your locations/sites are L3 ones, and since there is only a single subnet on each site, there is no useful place for VLANs. VLANs start making sense in scenarios where you want to use administrative groups of network devices on a single site and treat each group individually regarding what it is allowed to do network-wise. Think of the following:

• local users can get both to the internet and to any local resource (printer, NAS, IoT devices that happen to have a local configuration interface)
• IoT (home automation) devices can connect nowhere else but to the internet
• guest WiFi devices can connect nowhere else but to the internet

The usual way to achieve this is to use a dedicated subnet for each group of users, with its own DHCP server, and use firewall rules to permit devices from each source subnet to initiate connections only according to the above list. If everything is connected wirelessly, you can create a virtual wireless interface with its own SSID and password for each group and put each such interface into its own subnet, and you still do not need VLANs for that. But once you add devices connected using cables to the mix, and you want cable-connected devices and wirelessly connected devices to share the same subnet, VLANs become handy. Or if you want to use a common SSID for all devices but use a MAC address or username/password combination to put each of them into an appropriate subnet, you also need VLANs because the mapping between an SSID and an interface is 1:1 and the wireless access list rules or RADIUS responses are only able to tell the AP what VLAN tag to associate with the wireless client.

[sindy]

“Egress” means a frame exiting the router or switch, right?

Correct.

Do I understand correctly then that an “access” port on a router only allows frames to leave that have a VLAN tag that matches certain specifications (and then strips the tag)?

Indeed. The “certain specifications” are actually just the VLAN ID associated to the port, although the way it is configured may seem more complicated.

From other readings/tutorials/videos, an “access” port is used to allow traffic regardless of VLAN tagging.

First, to explain something, you need to simplify. So I’ve only mentioned the simplest and strictest setup, where the access ports only tag ingressing tagless frames with a single VLAN ID and only let frames with that single VLAN ID to egress, stripping the tag, whilst trunk ports let through any VLAN ID in either direction.

In reality, there are many shades of grey in between:

• “access port” and “trunk port” are just ways to describe the behavior of a switch port with regard to a particular VLAN ID. The same port may handle at most one VLAN ID using the “access treatment” (add the VLAN tag to ingressing frames without one and stripping it from egressing frames bearing the correct one) and any number of other VLAN IDs using the “trunk treatment” (which keeps the tags unchanged in both directions).
• the switches can be configured to use the VLAN ID to discriminate between frames already at ingress (i.e. a frame whose VLAN ID is not on the permissive list for a port will not get even from the wire to the inside of the switch) or only as late as at egress (the permissive list controls which VLAN IDs are allowed to get from the inside of the switch to the wire).
• on ingress, some headers of the frame may be used to choose a VLAN ID in addition to the physical port (mac address, ethertype, even some L3 fields)
• …

So on Mikrotik, if vlan filtering is enabled on the bridge but ingress filtering is not activated, a port that is configured solely as an access one for a single VLAN ID will indeed allow even a tagged frame to ingress, regardless the VLAN ID in the tag. But if that frame carries an IP packet and something responds to it, the response will not be able to egress via the same port because it is configured as an access one and the response is likely to bear the same VLAN ID like the request, so a “wrong” one for that port.

If vlan filtering is disabled on a bridge, the access (untagged) or trunk (tagged) roles of the ports for the VLAN ID are ignored and no tagging/untagging and/or filtering takes place at all, neither on ingress nor on egress.

[Josephny]

“Egress” means a frame exiting the router or switch, right?

Correct.

Do I understand correctly then that an “access” port on a router only allows frames to leave that have a VLAN tag that matches certain specifications (and then strips the tag)?

Indeed. The “certain specifications” are actually just the VLAN ID associated to the port, although the way it is configured may seem more complicated.

From other readings/tutorials/videos, an “access” port is used to allow traffic regardless of VLAN tagging.

First, to explain something, you need to simplify. So I’ve only mentioned the simplest and strictest setup, where the access ports only tag ingressing tagless frames with a single VLAN ID and only let frames with that single VLAN ID to egress, stripping the tag, whilst trunk ports let through any VLAN ID in either direction.

In reality, there are many shades of grey in between:

• “access port” and “trunk port” are just ways to describe the behavior of a switch port with regard to a particular VLAN ID. The same port may handle at most one VLAN ID using the “access treatment” (add the VLAN tag to ingressing frames without one and stripping it from egressing frames bearing the correct one) and any number of other VLAN IDs using the “trunk treatment” (which keeps the tags unchanged in both directions).
• the switches can be configured to use the VLAN ID to discriminate between frames already at ingress (i.e. a frame whose VLAN ID is not on the permissive list for a port will not get even from the wire to the inside of the switch) or only as late as at egress (the permissive list controls which VLAN IDs are allowed to get from the inside of the switch to the wire).
• on ingress, some headers of the frame may be used to choose a VLAN ID in addition to the physical port (mac address, ethertype, even some L3 fields)
• …

So on Mikrotik, if vlan filtering is enabled on the bridge but ingress filtering is not activated, a port that is configured solely as an access one for a single VLAN ID will indeed allow even a tagged frame to ingress, regardless the VLAN ID in the tag. But if that frame carries an IP packet and something responds to it, the response will not be able to egress via the same port because it is configured as an access one and the response is likely to bear the same VLAN ID like the request, so a “wrong” one for that port.

If vlan filtering is disabled on a bridge, the access (untagged) or trunk (tagged) roles of the ports for the VLAN ID are ignored and no tagging/untagging and/or filtering takes place at all, neither on ingress nor on egress.

I truly appreciate your efforts, but I think this is over my head. I’m having such a hard time understanding this.

Is this correct:

ACCESS PORTS:

1. Allows tagless frames on ingress
2. Tags frames that, at ingress (when they arrive at the port), arrive tagless with a VLAN ID (PVID?)
3. Remove tags from frames at egress (when they leave the device)

TRUNK PORTS allow all frames in and out without requiring, adding, or removing a VLAN tag.

TAGGED PORTS only allow ingress and egress to frames with the specified VLAN tag.

I can’t even begin to comprehend the ingress filtering active, multiple VLAN IDs, untagged coming in and response frames not being able to egress, etc.

[sindy]

The vernacular is indeed confusing and varies between vendors. For me, a TAGGED port is just an unusual name for a TRUNK port.

And the ACCESS and TRUNK really only express the behaviors as you’ve summarized them.

I can’t even begin to comprehend the ingress filtering active, multiple VLAN IDs, untagged coming in and response frames not being able to egress, etc.

That’s exactly the reason why I’ve started from the simple basics - access and trunk. The rest can only come with experience from practical testing. Only a chosen few (myself not included) can fully understand things without hands-on experience.

[anav]

From my learning experience, I tend to generally (although they are a bit connected ) think of
/interface bridge ports as the INGRESS identifier…
/interface bridge vlan as the EGRESS identifier…

MT is unique in its setup but regardless of tools, the /interface bridge port line either has a PVID entry assigned (access port), which automatically assigns/tags to incoming untagged frames with that VLAN tag, or the config line does not have a PVID, and this is assumed in most cases to be a trunk port ( hybrid port being an exception ).

INGRESS

We have Two Tools for ingress identifier.
A. frame type - detects if the packet contains a tagged vlan entry or not
B. ingress filtering - compares incoming tagged packet tagged vlan-id to /interface bridge vlans for any corresponding tagged match ( same port / vlan-id )

Ingress in terms of bridge ports means what happens to frames that are tagged correctly, tagged incorrectly or untagged.
There are four conditions in ingress that can occur
(i) packet has no vlan tag
(ii) packet has vlan tag that exists on the bridge and more importantly on the same port in /interface vlan bridge settings.
(iii) packet has vlan tag that exists on the bridge and but NOT on the same port
(iv) packet has vlan tag does not exist on either port or bridge

A. FRAME TYPES
When I create a bridge port line, the first thing I do is use is the appropriate frame-type
a. For trunk ports to automatically reject any packets without tags use: frame-types=admit-only-vlan-tagged
b. For access ports to automatically reject any packets with tags use: frame-types=admit-priority-and-untagged
c. For hybrid ports ( DO NOT USE frame-type ) as both tagged and untagged packets are expected at the port.

Security Note1: Frame type setting on trunk ports eliminates any access to the device by the native vlan 1 untagged.
Note2: Frame types does not ascertain VLAN-ID.
Note3: Frame types is independent of ingress-filtering

A. INGRESS-FILTERING

Ingress-Filtering=ON
Case (i) No effect for untagged packets
Case (ii) Router reads vlan-id of packets and sees match at /interface bridge vlan for the same port → the traffic is accepted.
Case (iii) Router reads vlan-id of packets and sees NO match at /interface bridge vlan for the same port → the traffic is dropped
Case (iv) Router reads vlan-id of packets and sees NO match at /interface bridge vlan for the same port → the traffic is dropped

Ingress-Filtering=OFF
Case (i) No effect for untagged packets
Case (ii) Router does no matching → the traffic is accepted.
Case (iii) Router does no matching → the traffic is accepted.
Case (iv) Router does no matching → the traffic is accepted.

EGRESS

In general, Egress means what will happen to tagged packets when they leave a port, which boils down to leave the tags on or strip the tag off.
In the case of a trunk port, tagged packets are left as as.
In the case of an access port, tagged packets are stripped of their tags when exiting the port.

On the MT device, Egress controls not only what happens to the status of the tag packets (keep tagged or strip tag), it also identifies all ports associated with the that VLAN-ID. Thus the /interface bridge vlan controls where else the traffic may travel to and answers the question - what other ports are valid to send this traffic. ( what I call the in-between traffic). Note that mac tables are used to assist the router in determining where the in-between traffic must go.

Ex. incoming port 2 (tagged or untagged for that matter), where ports 3,4 are also identified as being on the same vlan. If no mac table entry exists, the traffic is sent to both 3,4 and then awaits return traffic and reading off the src-mac address of the frame return, establishes a time-limited mac-table entry for that return port.

[Josephny]

Thank you all very much for your help towards my understanding.

Every time I look at it with renewed energy to mast this topic I find myself moving away.

Maybe someday when I can devote more time to learning this it will work.

For now, this is just beyond me.

[anav]

https://www.youtube.com/watch?v=jC6MJTh9fRE
https://www.youtube.com/watch?v=2QOFNTF4nyU
https://www.youtube.com/watch?v=MmwF1oHOvmg

[Josephny]

https://www.youtube.com/watch?v=jC6MJTh9fRE
https://www.youtube.com/watch?v=2QOFNTF4nyU
https://www.youtube.com/watch?v=MmwF1oHOvmg

These videos illustrate the probelm quite well.

Having watched a ton of these, and read a ton of explanations, I know 85% of the stuff in these videos.

These videos do a very nice job (simple enough to follow yet accurate and detailed enought to be of use), but only for a second here and there brush by the concepts that I am finding difficult.

For example, they teach that “access” ports are the same as “untagged” ports and that access ports only allow 1 vlan.

Well, imagine if you did not already understand that and you can see how it makes no sense. Even after working on this for years, I can’t understand how to reconsile that sentence.

I’ll try: Access ports are used to connect devices that do not themselves add a vlan tag (desktop computers, perhaps), and the router/switch with that access port (that the non-vlan-tag inserting device is attached to) will attach a vlan tag to those frames, as specified by the PVID (or is it native vlan) tag for that port. When frames exit that port, the tag is stripped. Well, how the heck does that fit in with the cute animated models of creating virtual networks to reduce broadcast traffic and provide flexible security features?

If I can’t get past this, how in the world can I get to the useful stuff you all use to make cool things happen?

[sindy]

Well, how the heck does that fit in with the cute animated models of creating virtual networks to reduce broadcast traffic and provide flexible security features?

Exactly the same way like totally isolated physical LANs would. The only thing that VLANs themselves provide is this kind of isolation without need for dedicated switches for each LAN, nothing more, nothing less.

The less devices are in the same (V)LAN, the less broadcast traffic lives there, as each device is a source of broadcast traffic. The less devices that have a possibility to send packets to each other directly (because they share the same subnet and (V)LAN), without any intermediate device that could use some restrictive policies to filter such traffic, the lower the number of devices that can get infected by malware if one of them is.

How you make use of segmenting the network into small areas ((V)LANs), among which the traffic has to flow via at least a firewall, is a separate thing.

[Josephny]

Well, how the heck does that fit in with the cute animated models of creating virtual networks to reduce broadcast traffic and provide flexible security features?

Exactly the same way like totally isolated physical LANs would. The only thing that VLANs themselves provide is this kind of isolation without need for dedicated switches for each LAN, nothing more, nothing less.

The less devices are in the same (V)LAN, the less broadcast traffic lives there, as each device is a source of broadcast traffic. The less devices that have a possibility to send packets to each other directly (because they share the same subnet and (V)LAN), without any intermediate device that could use some restrictive policies to filter such traffic, the lower the number of devices that can get infected by malware if one of them is.

How you make use of segmenting the network into small areas ((V)LANs), among which the traffic has to flow via at least a firewall, is a separate thing.

I understand (I think) that VLANs are nothing more and nothing less than a way to segment a physical network without additional hardware.

I think, however, that the implications for this (the uses and benefits) are great and include more than just a reduction in broadcast traffic across the LAN. I think that the largest benefit is what can be categorized as “security” whereby access to certain devices by certain other devices is controlled by way of VLAN assignment.

Is this correct?

[sindy]

I think that the largest benefit is what can be categorized as “security” whereby access to certain devices by certain other devices is controlled by way of VLAN assignment.

It is not controlled by VLANs themselves. VLANs just give you the possibility to prevent direct communication among those devices. Devices in one VLAN (and subnet!) can only communicate with devices in another VLAN (and subnet) via a router, despite the fact that they are connected to the same switch. Of course this is only true for switches that themselves support tagging and untagging. Such switches are often called “managed” ones, another blurry term.