Arch Linux

mccurly

Member

Registered: 2015-06-05

Posts: 28

[SOLVED] Searching for new directions about VLAN implementation.

Hello everybody.

This is a follow-up to a previously solved (workaround) issue that I posted here in the forums:

At that time, I managed to get a solution by using an OpenWRT router that wirelessly 'relayed' the 192.168.115.XXX network, to the ISP Set-Top Box (STB) that was connected to that same OpenWRT router. One of the opkg packages that was used, to achieve this workaround, was, precisely, the

relayd

package.

Presently, that router is no longer used as a wireless extension device that was relaying the main ISP's LAN to its wired client. Instead, it is used as a smart switch to produce (?) and also relay the specified VLAN's to its clients.

Please, take a look at the following images:

What I mean by 'produce' is that the device 3, which is also a Wireless AP, (besides being a 'smart switch'), creates/tags a VLAN (more precisely, the 192.168.115.XXX), that it then 'distributes' through the ports that I configured, to the respective clients.

What I mean by 'relaying' the 'upstream' VLAN's, is the fact that, this Router (Wireless AP), also takes the tagged and untagged VLAN's that the device 2 ROUTER SERVER creates, and 'relays/retransmits' them to its own clients.

At the moment everything that is related to VLAN's is working well.

So, why am I bothering to change this setup?

First here is the picture of what I am looking for:

Basically, I am looking for a way to replace that 3,Wireless AP device with a 'machine' that will not have to make routing decisions and not hog the low spec 3 device. Please note that in the place that was previously occupied by the OpenWRT Wireless Router / AP, I am looking for a way to displace those  routing decisions to the Arch Linux Router and broadcast those networks through a 'dumb' VLAN switch that is able to output to any of its ports the network packets it receives on any other port.

Besides that, there are more disturbing quirks about the presently working setup.

For instance, I've noticed, recently, that this 3 device is behaving erratically, with things like not turning its switching capability back on if the upstream power supply has been cut and reestablished. Requiring manual intervention to repeat the power cycling by unplugging off its energy and replugging it back on. Since I doubt I have the required means to debug or solve this showstopper of an issue further, I am looking for a way of retiring that same 3 device.

Currently, the 2 device, the ROUTER SERVER, is a systemd-networkd, 'networkwise' ruled server.

I do not relish the possibility of keeping up this systemd-networkd solution nor any other solution based on scripting or any other available network management solution. I am almost ready to jump over from systemd-networkd to NetworkManager, solution, since I think the configuration that the 3 OpenWRT device could be more easily put in place with this latter network management solution, namely with its nmcli appliance. But I am not yet inclined or favoring either solutions.

What I am thinking is: if OpenWRT is able to do it, it should be able to be replicated here in Arch. After all it is linux is it not?

The 2, ROUTER SERVER (Arch Linux Router) is an x86_64 machine, Intel NUC, and it has two ethernet ports. One connected to the 1, ISP Router Gateway (upstream traffic) and the other handing-out downstream VLAN traffic (both tagged and untagged).

What I think I should be doing is a bridge between the two Router Server ports and and create VLAN's on that same bridge to  accomplish the job (similar  to what I am currently doing with the OpenWRT wap). Please take a look at the following pictures. But I do not know how to accomplish this. Not with systemd-networkd nor with nmcli.

Here are the pictures I was talking about:

Can anyone point me to the right direction?

Thank you for your reading and attention.

Cheers!

Last edited by mccurly (2025-05-23 14:48:30)

-thc

Member

Registered: 2017-03-15

Posts: 892

Re: [SOLVED] Searching for new directions about VLAN implementation.

Do not try to use VLANs with a "real" dumb switch. There are several reports that this - depending on the switch brand/model - may (accidentally) work or not at all. Use a small managed switch that fully supports VLANs instead.

NetworkManager lacks bridge support  - if you plan to establish a bridge interface with the two Ethernet ports on your server - stay on systemd-networkd.

The basic procedure goes like this. Create a bridge interface

# 10-br0.netdev
[NetDev]
Name=br0
Kind=bridge

Associate both Ethernet devices with the bridge (they "lose" their IP functionality)

# 15-ens33.network
[Match]
Name=ens33

[Network]
Bridge=br0

# 15-ens34.network
[Match]
Name=ens34

[Network]
Bridge=br0

And move all IP/VLAN assignments to the bridge interface

# 20-br0.network
[Match]
Name=br0

[Network]
Address=192.168...
Gateway=192.168...
DNS=192.168...

mccurly

Member

Registered: 2015-06-05

Posts: 28

Re: [SOLVED] Searching for new directions about VLAN implementation.

Hello, thank you for your support. Apologies for my late answer.

Do not try to use VLANs with a "real" dumb switch. There are several reports that this - depending on the switch brand/model - may (accidentally) work or not at all. Use a small managed switch that fully supports VLANs instead.

I was using the same exact switch for 'broadcasting/retransmitting' VLANs previously, with no glitch with it. Of course what happened in the past is no assurance of what will happen in the future… Nonetheless, I am willing to give it a try.

NetworkManager lacks bridge support (…)

Do you mean 'this' NetworkManager?

Am I interpreting this wrong or Is Arch Linux Network Manager different from mainline?

(...) if you plan to establish a bridge interface with the two Ethernet ports on your server - stay on systemd-networkd.

Well, I did try, last 13th of May, after seeing your answer. Actually tried to 'pull it off' during that whole day, but I did not succeed. At least in the way I was expecting or wishing to. I did not carry out thorough tests (only used one mobile phone to test) and, although it was connected to the SSID that is 'attached' to the 10.0.1.0/24 network, and having 'WWW' connectivity, it 'seemed' (yes it surprised me as well), that it got an IP address in the 192.168.115.0/24 network. I then thought that I was doing a major mistake with the configuration. (And maybe I was). But since I wasn't that systematic I pursued with trying to configure on because I thought that this setup I had would not quite 'cut it'…

So I did keep going until I only got the point where I could not bear with it any longer for that day. Exhausted and worse than I was in the beginning… Almost by that day's end I was also trying to stop using systemd-networkd and tried several ways to use NM way of doing things. And, thc, maybe your suggestion is the one that is going to prevail. Today (tonight, I mean) I am going to go with more attempts with systemd-networkd. I am confident that this time things are going to work out.

(...) if you plan to establish a bridge interface with the two Ethernet ports on your server - stay on systemd-networkd.

There is a detail on this latter quote. I am going to pick that exact detail: You said, "if you plan to establish a bridge interface(…)". This is an important detail that possibly I was clinging on to, but maybe it isn't that important after all, or it might even hinder things up more than I would have wanted to. My question is:

Do I have to necessarily use a bridge interface (which in OpenWRT terms may mean 'device')?

Perhaps I do not have to use any bridge at all, or do I?

Presently, that Arch Router / Server, that is being used for VLAN management at same time as being host for other network services, does not have any 'actual' bridge set up. Nevertheless, it can route data traffic as planned. So, to answer my own question, maybe, there will not be any need for any bridge device/interface (or whatever should be its correct designation). And if that would be the case, I apologize again for having made such an assumption. That one bridge would be needed to get this configuration to go.

Moreover, if we inspected:

…with a closer look and we had 'streamlined' that table with five (5) network ports, into only two (2) shouldn't we be getting something like:

I think, that, therefore, it will be easier to implement this with systemd-networkd. Won't it?

I am guessing it will…

I am going to try it and post back.

Thank you.

Last edited by mccurly (2025-05-17 21:20:14)

-thc

Member

Registered: 2017-03-15

Posts: 892

Re: [SOLVED] Searching for new directions about VLAN implementation.

Do you mean 'this' NetworkManager?

Am I interpreting this wrong or Is Arch Linux Network Manager different from mainline?

You've got me there - I have interpreted the absence of "brigde" topics in the Wiki in this way - I apologize.
Nevertheless I suggest staying on systemd-networkd.

Do I have to necessarily use a bridge interface (which in OpenWRT terms may mean 'device')?

As far as I know: If you have a "router/bridge" and two different devices have to transport/connect the same IP segment (192.168.115.x - what you are looking for) you have to use some kind of bridge. Otherwise (separate IP segments) you can use routing.

Please be aware that the OpenWRT combines bridging and VLAN filtering to enable you to give the bridge ports a "direction" - which is not a feature of a simple bridge (although systemd-networkd provides some kind of filtering via "[BRIDGEVLAN]" settings).

mccurly

Member

Registered: 2015-06-05

Posts: 28

Re: [SOLVED] Searching for new directions about VLAN implementation.

Nevertheless, I suggest staying on systemd-networkd.

Hi, I will try to do it that way. Thank you for your advice. In fact, I am already on the subject. Indeed, I am on it since this morning, but I did come here, and I did not catch this latest post of yours. (Forgot that the thread does not auto refresh on the browser… duh for myself…)

As far as I know: If you have a "router/bridge" and two different devices have to transport/connect the same IP segment (192.168.115.x - what you are looking for) you have to use some kind of bridge. Otherwise (separate IP segments) you can use routing.

I can honestly and only from my observation, (and head banging against this problem, of course), that you are correct on that assumption. Currently, I did establish some connectivity to the sub-devices that transport that 192.168.115.x LAN and… yes although the mobile phone that connects to the secondary access point does get an IP address, it does not communicate with the main (ISP) router, and the address that it gets is, most expectedly, within the range that the Arch router is handing to its clients, which kind of proves you are right on it.

Please be aware that the OpenWRT combines bridging and VLAN filtering to enable you to give the bridge ports a "direction" - which is not a feature of a simple bridge (although systemd-networkd provides some kind of filtering via "[BRIDGEVLAN]" settings).

OK “Roger that” I will document myself further then.

One aspect, though, this means that all the connected devices must be on the same bridge, don't they? Or can I do a mix of settings? Why do I ask this? Well, because, I have yet to figure out a lot about bridges, at least in our systemd-networkd way of doing things… I am guessing (probably wrong) that I could be 'better off' by keeping some configuration as is currently. Which doesn't mean that it could be doable… Correct? Hence, my question.

Again, thank you, and I will report back soon (I hope, at least).

Cheers!

-thc

Member

Registered: 2017-03-15

Posts: 892

Re: [SOLVED] Searching for new directions about VLAN implementation.

In your case (what you are looking for) you have to bridge the two devices and have to "move" all IP configuration to the bridge device. If your server had more physical network devices you could split parts of the configuration. AFAIK you can not "keep" a bridge members configuration or parts of it.

mccurly

Member

Registered: 2015-06-05

Posts: 28

Re: [SOLVED] Searching for new directions about VLAN implementation.

Hi,

Currently it is working.

It is made up out of systemd-networkd config files, and firewalld 'Natting'.

I intend to do a write up of the settings and the decisions made, and their inspirations as well.

There are some things that can be improved, maybe the trimming on the number of config files and their bridges.

And definitely on the way that I am currently doing my pi-hole docker inside that same server as a container.

As usual, things are always susceptible to improvement. But, for now here come the news. On the VLAN side of things (with the exception of a glitchy docker container of pi-hole), everything is working.

Note: the 'dumb' switch is doing is work. It is operating as I expected it to. Although It might misbehave in the future. As -thc has said.

I intend to be back soon with the working setup files.

Thank you folks!

Cheers!

mccurly

Member

Registered: 2015-06-05

Posts: 28

Re: [SOLVED] Searching for new directions about VLAN implementation.

Hello again.

Sorry for having taken this long to post back.

Here are all the settings:

########################################
########################################
#######                         ########
#######   configuration files   ########
#######                         ########
########################################
########################################


########################################

file: /etc/systemd/network/10-extern0.network

[Match]
Name=extern0

[Network]
Bridge=br115



########################################

file: /etc/systemd/network/10-intern0.network

[Match]
Name=intern0

[Network]
Address=10.0.1.16/24
Gateway=10.0.1.16
DHCP=no
DNS=10.0.1.16
DNS=192.168.115.254
DNS=1.1.1.1
DNS=1.0.0.1
VLAN=intern0.20
VLAN=intern0.30
VLAN=intern0.115



########################################

file: /etc/systemd/network/12-intern0.115.netdev

[NetDev]
Name=intern0.115
Kind=vlan

[VLAN]
Id=115



########################################

file: /etc/systemd/network/12-intern0.115.network

[Match]
Name=intern0.115

[Network]
Bridge=br115



########################################

file: /etc/systemd/network/12-intern0.20.netdev

[NetDev]
Name=intern0.20
Kind=vlan

[VLAN]
Id=20



########################################

file: /etc/systemd/network/12-intern0.20.network

[Match]
Name=intern0.20

[Network]
Address=10.0.20.16/24
Gateway=10.0.20.16
DNS=10.0.20.16
DNS=192.168.115.254
DNS=1.1.1.1



########################################

file: /etc/systemd/network/12-intern0.30.netdev

[NetDev]
Name=intern0.30
Kind=vlan

[VLAN]
Id=30



########################################

file: /etc/systemd/network/12-intern0.30.network

[Match]
Name=intern0.30

[Network]
Address=10.0.30.16/24
Gateway=10.0.30.16
DNS=10.0.30.16
DNS=192.168.115.254
DNS=1.1.1.1



########################################

file: /etc/systemd/network/20-br115.netdev

[NetDev]
Name=br115
Kind=bridge



########################################

file: /etc/systemd/network/20-br115.network

[Match]
Name=br115

[Network]
Address=192.168.115.230/24
Gateway=192.168.115.254
DNS=192.168.115.254





########################################
########################################
######                          ########
######      firewall zones      ########
######                          ########
########################################
########################################


public (active)
  target: DROP
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: br115
  sources: 192.168.115.0/24
  services: dhcpv6-client http https ssh
  ports: 
  protocols: 
  forward: no
  masquerade: yes
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 


home (default, active)
  target: ACCEPT
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: intern0
  sources: 10.0.1.0/24
  services: dhcpv6-client mdns samba-client ssh
  ports: 
  protocols: 
  forward: no
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 



iot (active)
  target: DROP
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: intern0.20
  sources: 10.0.20.0/24
  services: dhcp dns
  ports: 
  protocols: 
  forward: no
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 


guest (active)
  target: DROP
  ingress-priority: 0
  egress-priority: 0
  icmp-block-inversion: no
  interfaces: intern0.30
  sources: 10.0.30.0/24
  services: dhcp dns
  ports: 
  protocols: 
  forward: no
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 




########################################
########################################
######                          ########
######    firewall policies     ########
######                          ########
########################################
########################################

guest-web-policy (active)
  priority: -1
  target: ACCEPT
  ingress-zones: guest
  egress-zones: public
  services: 
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 


iot-web-policy (active)
  priority: -1
  target: ACCEPT
  ingress-zones: iot
  egress-zones: public
  services: 
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 


########################################
#########      the end       ###########
########################################

There are some things yet to improve. (I Guess) Namely the dockerized pihole that I have in the router as well.

I am going to dig a bit further on that pihole subject.

Thank you all for your assistance and especially to -thc.

Cheers!