I'm not sure what you mean by this... can you elaborate?
There are some situations where people may use a device name rather than the raw ethx.y or whatever. This can be handy in certain situations, but it seems to be technically unnecessary most of the time and might actually conflict in some cases (especially with DSA).
Sorry. So what I mean is the following. I have a router from the ISP in bridge mode > going into my current router only two ports, more specifically it goes in eth0 or the WAN port, then I have eth1 left. I connect eth1 to a managed 8 port switch where I want to have all my vlans that I created in the router as interfaces, so the VLAN41_Nas should be at port 4 in the managed switch.
To achieve this I currently have the following:
Network > Interfaces > Devices br-lan (mapped to eth1, device type: bridge device) and in the Bridge VLAN filtering tab (not sure why they are not tagged?):
Then I have the 802.1q entries for each vlan both of which are configured as a device type in the firewall and the interface (Network > Firewalls and Network > Interfaces menu):
What's redundant in my setup, and more importantly, exactly how/why?
I prefer to look at text file... let's see the output of cat /etc/config/network
from yesterday:
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix '[redacted]'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth1'
config interface 'lan'
option device 'br-lan.71'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
config interface 'wan'
option device 'eth0'
option proto 'pppoe'
option username '[redacted]'
option password '[redacted]'
option ipv6 'auto'
option peerdns '1'
option dns '8.8.8.8 8.8.4.4'
config interface 'wan6'
option device 'eth0'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix 'auto'
option peerdns '1'
list dns '2001:4860:4860::8888'
list dns '2001:4860:4860::8844'
config interface 'wwan'
option proto 'dhcp'
config bridge-vlan
option device 'br-lan'
option vlan '1'
list ports 'eth1:t'
config bridge-vlan
option device 'br-lan'
option vlan '21'
list ports 'eth1:t'
config bridge-vlan
option device 'br-lan'
option vlan '31'
list ports 'eth1:t'
config bridge-vlan
option device 'br-lan'
option vlan '41'
list ports 'eth1:t'
config bridge-vlan
option device 'br-lan'
option vlan '51'
list ports 'eth1:t'
config bridge-vlan
option device 'br-lan'
option vlan '61'
list ports 'eth1:t'
config bridge-vlan
option device 'br-lan'
option vlan '71'
list ports 'eth1:t'
config bridge-vlan
option device 'br-lan'
option vlan '81'
list ports 'eth1:t'
config interface 'VLAN21_admin'
option proto 'static'
option device 'br-lan.21'
option ipaddr '192.168.2.1'
option netmask '255.255.255.0'
config interface 'VLAN41_NAS'
option proto 'static'
option device 'br-lan.41'
option ipaddr '192.168.4.1'
option netmask '255.255.255.0'
config interface 'VLAN31_PC'
option proto 'static'
option device 'br-lan.31'
option ipaddr '192.168.3.1'
option netmask '255.255.255.0'
config interface 'VLAN51_Server'
option proto 'static'
option device 'br-lan.51'
option ipaddr '192.168.5.1'
option netmask '255.255.255.0'
config device
option type '8021q'
option ifname 'br-lan'
option vid '91'
option name 'br-lan.91'
config interface 'VLAN61_IoT'
option proto 'static'
option device 'br-lan.61'
option ipaddr '192.168.6.1'
option netmask '255.255.255.0'
config interface 'VLAN91_Guest'
option proto 'static'
option device 'br-lan.91'
option ipaddr '192.168.9.1'
option netmask '255.255.255.0'
config device
option type '8021q'
option ifname 'br-lan'
option vid '111'
option name 'br-lan.111'
config interface 'VLAN111_General'
option proto 'static'
option device 'br-lan.111'
option ipaddr '192.168.11.1'
option netmask '255.255.255.0'
So I see 802.1q stanzas for VLAN 91 and VLAN 111.
It seems that you do not have bridge-vlans defined for these VLANs, which is a bit unusual given that you have bridge-VLANs assigned for the other VLANs. I'm guessing this isn't causing problems because you've only got one port in the bridge and both of those VLANs would just be tagged on that port anyway. However, for consistency, I'd recommend removing the 802.1q stanzas and replacing them with bridge-VLANs:
config bridge-vlan
option device 'br-lan'
option vlan '91'
list ports 'eth1:t'
config bridge-vlan
option device 'br-lan'
option vlan '1111'
list ports 'eth1:t'
When a bridge-VLAN is created, an implicit 802.1q device is created under the hood, so the .1q stanzas are not necessary. But obviously you need to make sure that the bridge-VLANs are there -- I probably mis-advised earlier if I didn't realize that they weren't already setup.
So the reason these don't have a bridged-VLAN is because I have more vlans than on-switch assigned VLANs, basically the 91 and 111 are VLANs I am using for wifi, not LAN.
As for the 8021q stanza, it is interesting that the config itself doesn't mention it, because the situation in the GUI looks like this:
Now I have no idea why the 91 and 111 VLANs are the only ones that can be unconfigured, except that they are the only ones not assigned to a physical port?
So from this it looks like 8021q must exist if it's assigned to a LAN port, so much so that the GUI implictily shows it (even tho I did not create it I believe) without the option of deletion, and that the config files actually don't have those implicit entries that you can modify.
So are you saying that the other VLANs are used on other devices downstream of this router (i.e. a managed switch or a VLAN aware AP), but that these two networks are not? If that's the case, they do not need 802.1q stanzas because 802.1q is only relevant via wired ethernet (it doesn't apply to wifi, except in certain setups that are rather uncommon).
Like I said, the 802.1q device is created implicitly by means of the bridge-vlan.
As I mentioned above, they are only relevant if they are tied to a physical port -- and they are in fact tied, but indirectly:
the ifname line ties it to br-lan which in turn has a physical port defined under it:
If you have a managed switch downstream of this router and you configure it to expect VLANs 91 and 111 (both tagged), you'll see that the connection is indeed there.
Right, because they are implicitly generated, and they cannot be deleted because doing so would break the config since the 802.1q tags are necessary.
If they did, that would be explicitly defined. The implicit definition occurs because there is a higher level structure that relies on the 802.1q tags.
To be clear, if those two networks only exist for wifi on this exact device, you should remove the 802.1q stanzas and replace them with empty bridges. (technically, they aren't VLANs if they aren't connected to ethernet).
You would delete these:
And create empty bridges in their place:
config device
option name 'br-guest'
option type 'bridge'
option bridge_empty '1'
config device
option name 'br-general'
option type 'bridge'
option bridge_empty '1'
And then edit the network interfaces to use the new bridges:
config interface 'VLAN91_Guest'
option proto 'static'
option device 'br-guest'
option ipaddr '192.168.9.1'
option netmask '255.255.255.0'
...
config interface 'VLAN111_General'
option proto 'static'
option device 'br-general'
option ipaddr '192.168.11.1'
option netmask '255.255.255.0'
In fact, the bridge is only required if the network will be used on more than one physical interface. So a bridge is necessary if you are using wifi + ethernet, or 2 or more wifi radios. But it is not required when you are using only a single wifi radio. If that's the case, you can actually entirely omit the bridges I just suggested and then remove the device lines from those networks.
Ok to wrap it up.
If I only have them on a single physical interface, say port VLAN_2 on Port 2 on the switch, then I actually don't even need the bridge for any of the other VLANs? AKA:
I do have uses for both wifi + ethernet though for the rest, but not for the guest network. So if I only create a single wifi ssid assigned to each 91 and 111 VLANs, then I don't need to bother even bridging them?
Correct.
What are those setups?
The GUI shows them as greyed out (not possible to be unconfigured, since they are implictily created and flagged with "ifname" in config device?
If it is on ethernet only and based on a single-port device, you can skip bridge-vlans and bridges entirely. But there may be nuance here, so it depends on the details.
Correct, as long as the "single wifi ssid" is referring to just a single band/radio (either 2.4G or 5G). If you want to use both bands (2.4 + 5), you need to use a bridge (even if the SSID is the same).
Certain mesh/B.A.T.M.A.N situations where the VLANs are encapsulated over a PTP / PTMP link. This type of link uses the same physical hardware, but is configured such that you cannot connect a normal wifi client (i.e. phone, computer, etc.) -- the other side must be a corresponding PTP/PTMP configuration.
Regarding the bridges and such.... let's make up a fictitious scenario:
(all assuming a single ethernet port device that doesn't have a switch):
From the above, we could say that:
/etc/config/wireless.If you have any remaining question about the specifics of using a bridge, bridge-vlan, or no bridge at all, let's actually use your specific configuration flesh that out. What we'd need is to have a list of VLANs and their desired connectivity like my made up example above.
Oh damn, thank you so much! I believe everything is clear to me now. However I have no idea what do you mean by the following:
At a base level, if a network will have just a single radio attached, no device definition is required (or desired) in the network config file. Specifically, wireless hardware should never be referenced in that file (all the wireless stuff happens in... you guessed it... /etc/config/wireless). So, the network interface might look like this:
config interface 'guest'
option proto 'static'
option ipaddr '10.5.9.1'
option netmask '255.255.255.0'
Then, in the SSID configuration (within /etc/config/wireless), there would be the standard option network 'guest' line to connect that SSID to the correct network.
Now, in some specific and somewhat rare situations, the sequencing and timing of the of the boot cycle can create a "race condition" in which the wireless hardware/config and network interfaces don't reliably initialize in the right order. In those cases, the SSID may not be able to attach to the network or an error may appear about not being able to claim an interface (can't remember the exact error). In those situations, an empty bridge will be able to break the timing dependency insofar as the SSID connects to the bridge, and the network interface connects to the bridge. You can literally visualize this as a physical bridge with a central pylon (let's use some hand-waving for the structural integrity) 
... if you had to span the entire distance of the bridge without the central pylon, both sides have to be 'ready' before you can start assembling the truss/deck. However, if both sides can independently work towards the central pylon, one side can get started a bit earlier while the other abutment is still in construction.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.