VLAN(s) - bridge confusion

Greetings all,

as @psherman kindly advised me that my "device clearly uses swconfig", I started researching how to configure VLANs.

After partially successful fight with the various sources this is what I do understand:

  • I need to enumerate and (optionally) name the VLAN(s) in the Network - Switch section;
  • In the same section I establish the relationship between the CPU (eth0), the VLAN(s), and physical ports of the router/switch; and
  • these two actions automatically create a virtual VLAN(s) device(s) eth0.X, the X identifying the enumerated VLAN.

On a related, but different note, I think that I understand the difference between the Interface and the Device. In my understanding it enables a device without a built-in switch to nevertheless use VLAN(s) by creating a "connection" - interface - to a device with VLAN aware switch.

What I do not understand is the following:

  • the created virtual VLAN(s) device(s) eth0.X are not associated with MAC address(es); and
  • to associate the virtual VLAN(s) device(s) eth0.X with MAC adress(es) I need to create a bridge.

I have read and re-read the definition of a bridge, but it is clear that I am still missing an important concept because:

  1. Since the Network - Switch section clearly associates the eht0.X with the eth0 and the ports, what is the purpose of further creating a bridge?
  2. It is unclear whether I need to create individual bridges for the individual eth0.X or add them eth0.X into the br-lan. It seems the former, but I do not understand why because by my experiments, both actions result in eth0.X MAC address association.

Any explanation would be appreciated.

Kindest regards,


A bridge is the software equivalent of an unmanaged switch.

You can think of a network interface as having exactly one 'virtual' port. A bridge is required if you will be connecting more than one physical interface to a network interface.

In the case of swconfig, multiple ethernet ports on the same switch are actually treated as a single physical interface (in DSA, each port is treated as a physical interface). A wifi radio is also a physical interface. So if you plan to connect the network interface to ethernet + wifi, or 2 or more radios for wifi (i.e. 2.4G and 5G radios), a bridge is required.

Do not add them to the existing br-lan. You need individual bridges for each eth0.x assignment. If your bridge contains multiple eth0.x entries, it would collapse the VLANs into a single unmanaged domain, and that will cause problems. Therefore, if you have eth0.1 and eth0.5, they should each be contained in their own bridge.


Hi psherman,

thank you for your reply.

Ah, but this is exactly what I do not understand. As I understand it,I will be using a single physical interface per network interface, i.a., a single VLAN will be used per a single (LAN) physical port, thus no radio.

O.K., that explains it form the practical stand-point, so from this point I consider it solved.

Saying that, although I will still try to find some clarification regarding the former issue. so I understand it at conceptual level.

Kindest regards,


Yeah... so to say it in the other direction:

  • if you will only be using a single physical interface (i.e. ethernet via the swtich only on a swconfig device, or a single wifi radio only), you can skip the bridge entirely and put the physical interface device into the network interface itself.

Does that help?

1 Like

Hi psherman,

I appreciate your engagement, but your statement does and does not help.

It helps in that it confirms my understanding that I should not need a bridge.

Unfortunately, it does not help in my understanding of the concept. Let me try one last time.

As I understand it, the Network - Switch makes the connection between (each of) the virtual interface eth0.X and the corresponding physical LAN port. In fact, it seems that it can make a connection between a single virtual eth0.X interface and a plurality of physical LAN ports. So, according to your terminology I have one-to-many relationship - without a bridge.

Thus, the need of the bridge, whatever the functionality it adds is not required.

So, perhaps I am still missing an important concept - the bridge. To my defense, there are literally tens+ posts asking about the bridge.

Kindest regards,


No worries. I'll try again. Admittedly this is confusing and it's hard to explain.

If what I say next doesn't actually fully answer the confusion, would you post your /etc/config/network file -- I can use that to discuss specifics and even make some examples.

(conversely, apologies if I go too basic here and/or explain more than you need)

Yes. The switch chip inside most (maybe even all??) OpenWrt supported routers is VLAN aware. With that in mind, consider that the switch chip typically has 4 or 5 external/physical ports, and 1 (or sometimes 2) internal ports that connect to the main SoC/CPU.

When we talk about eth0, that is the SoC's eth0 port which is wired to the switch. We can use dotted vlan notation to send 802.1q tagged frames over that connection to enable VLANs... so now we can use eth0.x and eth0.y, etc.

The switch chip itself is configurable for the VLANs we wish to use. Each switch port (including the internal one that goes to the SoC's eth0) will be defined for it's VLAN membership and tagged/untagged status for each VLAN. The 802.1q standard allows:

  • zero or one untagged network
  • zero, one, or many tagged networks.

Typically, we have all VLANs available as tagged on the internal port that goes to the SoC's eth0 port... so that generates eth0.1, eth0.x, ... eth0.n. Then we define the configuration for each of the external ports according to our needs. So let's say you have the physical ports lan 1 and 2 associated with VLAN 1, lan 3 is VLAN 5, and port lan 4 is a trunk with VLAN 1 untagged and VLAN 5 tagged.

As mentioned before, swconfig syntax says that eth0.1 and eth0.5 is the "device" or "port" that the SoC/CPU sees for use in bridges or network interfaces.... each acts as a single physical interface despite the fact that there are multiple physical ports behind the eth0.x designators.

This is true if (and only if):

  • you're using a device that still uses swconfig (DSA is a different animal)
  • all of the physical ports in question are covered by the switch.
  • Only ethernet is being used -- wifi is not part of the equation.

The bridge is required if you:

  • use wifi + ethernet
  • use multiple wifi radios
  • need to connect multiple ethernet ports that are not all part of a switch
    • for example, some devices have a 4 lan + 1 wan arrangement where the wan port doesn't physically connect to the switch -- if you want to put the wan port together with the lan ports, you need a bridge to do that.

I hope that was a better explanation.

1 Like

Hi psherman,

thank you for the reply.

No worries, my middle name is Moron(tm), but the explanation is so clear that even I can understand it (I think). I think the team should rope you to write the documentation.

This is one of the concepts that I had missed, thank you for writing this.

This is a concept I entirely missed. So, let me re-state, how I understand it. The reason that one needs a bridge is because there is no (physical) connection between the SOC chip and the radios and/or WAN port. The bridge then creates a virtual connection.

If I understand it correctly, the practical question remaining is the following. Since I created the VLANs to physical LAN ports assignement in the Network - Switch, and the software understood it and created the corresponding eth0.X and I do not need br-eth0.X, why the software did not assign the MAC addresses except for the eth0.1, for which it created br-lan.

Or, am I still missing something?

Kindest regards,


By default, all packets emitted by eth0.X will have the same MAC address, regardless of the value of X. This seems like it could not work, but it does. MAC addresses only need to be unique within a physical or virtual network segment, and VLANs are separate segments.

1 Like

Hi mk24,

thank you for your reply.

Yes, that was what I discovered, when I did add the br-lan0.X for the corresponding eth0.X. What my, obviously unclear question was, why, if I do not need the br-lan0.X per my (hopefully correct) understanding form @psherman's explanation, the system-created eth0.X are not assigned MAC addresses.

Kindest regards,


A bridge is only needed if you also need a psuedo-switch in software to handle something more than the one Ethernet VLAN on a network. The main use for that is wifi APs inside the router. Also some models have additional Ethernet ports that are not part of the switch chip. In order to include those in the same network with a hardware-switched port, a software bridge is needed.

swconfig models can approach software bridges two ways:

  • bridge-vlans inside one bridge. This is the new way which is more directly compatible with DSA systems.
  • separate non-vlan bridge for each VLAN. By non-vlan bridge I mean that packets inside the bridge are not VLAN tagged, and the networks are kept separate by having separate bridges. Packets become VLAN tagged when they are sent out of the bridge to or from a tagged CPU port.

Hi mk24,

thank you for your attempt to help.

Yes, this is consistent with my understanding based on @psherman's writing.


Unless there is a terminology issue, this is inconsistent, please cf. post 2 (emphasis supplied):

In fact, this is consistent with your second point:

Saying that, it does not address my question. Since I am not using any of the internally not-connected devices, e.g., the radio, I should not need a bridge, *cf. post 6:

So, if I do not need bridge, why there is not a MAC to eht0.X assignment/association unless/until I create a br-lan0.X for each of the eth0.X? And, why the software (automatically) created br-lan for the eth0.1?

Kindest regards,


It might be a terminology thing...
bridge-vlans are a considerably different method of configuring the switch -- they are required in most situations when working on a DSA based device. The structures and syntax can be used with swconfig based devices (and even non-switch based devices), but I personally prefer to use the older method with independent bridges when working with swconfig based systems.

IMO, just ignore bridge-vlans for now because they are really very different. But if you do happen to want to read up on how DSA works, here's a guide.

The "base" device is eth0. When you create a VLAN on eth0, you create eth0.x and this inherits the MAC of the base device.

This is not an 'automatic' creation, but rather a default structure.

While there are lots of permutations, in a swconfig device, the lan is usually associated with eth0 or VLAN 1 via eth0 (i.e. eth0.1) when there is a VLAN aware switch. Then, for devices that also have wifi (i.e. wifi routers among many others), the default behavior is to have the ethernet/lan ports associated with the lan network interface and the wifi also linked against the lan (wifi is disabled by default, but the network assignment is defined). Because ethernet + wifi is used, a bridge is required. This construct of a bridge for the lan -- br-lan -- has thus become a default config item for essentially all OpenWrt installations. There is no harm in having a bridge defined, though, even if there isn't anything else attached to the bridge (i.e. no wifi, etc.).

1 Like

Hi psherman,

thank you for the reply, it is getting more and more clear.

But this is exactly the problem that I am experiencing and asking about. When the eth0.X, X>1 is created, there is not - at least in the GUI - the MAC address associated with the eth0.X. Once I add the br-lan0.X the MAC address appears in the GUI next to both the br-lan0.1 and the eth0.X.

Perhaps a bug in the software?

Kindest regards,


The MAC exists, it's just not shown under the eth0.x device. It has to exist such that the interface has an L2 presence (without a MAC, it is not possible do communicate at L2).

It will be the same as what is shown under eth0 (which should also be the same as eth0.1).

I don't know if I would call it a bug... maybe just an implicit inherited property. I can, however, understand how this would be confusing.

Hi psherman,

thank you again.

Ha, ha, I did not proceed to testing the L2 communication, as I was not sure about all the bridge, VLAN, magically appearing MAC address, etc.

Now I can move forward.

Kindest regards,


Glad we were able to answer your questions... yes, this stuff is hard to wrap your head around when you're first learning VLANs and all the nuances of how the physical interfaces, network interfaces, bridges, and the like all work together.

1 Like

Hi psherman,


Without being ungrateful to the developers, after all, they are more interested to solve problems/add features, the documentation has a lot to be desired. Especially with networking being a rather complex subject.

On the other hand, it is great that the forum has so many people willing to help.

Until the next issue I encounter. :wink:

Kindest regards, and once again thank you for your patience.


This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.