TOS5 VLAN Nightmare

I have spent a week with try to configure VLAN on TOS5 without any luck. What worked smoothly on TOS3.x, here is pain in the a** :frowning:

What I can do is nothing special. Just get two separated LAN segments, one for main network, second for Guests. But because I have disabled WiFi on Turris and use two Mikrotik APs for my Wifi I have to use TRUNK port to get traffic from them to Turris. And of course i can use DHCP for both networks…

At first I have configured second bridge for Guest, assign here IP, set DHCP and splitted lan4 to lan4.10 and lan4.20 to get VLANs.

On first look, things worked. Till time when my wife started to complain for big lags during browsing on his laptop connected by Wifi. I have started to digg in, and discover that sometimes ping on www.seznam.cz get 3000 ms.

Deep analysis discovered that ARP replies have stopped to work. Laptop flooding net by ARP requests to get IP of the default gateway (and turris IP), but no reply arrived. But sometimes arrived ARP query from Turris with default GW IP and then ARP table has been satisfied and things started to work for a while.

I provided investigations from Wifi to Mikrotiks and finally arrived to Turris. All points that problem is here…


I have reverted completely net config of my VLANs on Mikrotik and started to check Turris VLANs. Time for some testLab work…

To do this, I have created testing environment on my Turris:

* VLAN10: lan0, lan1.10
* VLAN20: lan2, lan1.20

Configured two bridges, g1, g2, and asign:

* g1: lan0, lan1.10
* g2: lan2, lan 1.20

To connect on TRUNK port, I use laptop with Hyper-V bridge and modify management interface VLAN tag to 10 or 20 depends on VLAN which I can join…


On first try. DHCP works smoothly on access ports (lan0, lan2) but on the trunk, it is lottery. Sometimes i get rerply, sometimes not, obviously when i get reply for one VLAN, then iface is “locked” to this subnet and VLAN ( Vlid 10 for example) next DHCP request for VLAN20 failed completely.

By deeper investigation I have found that lan1.10 and lan1.20 has same MAC address. Because these devices works as “strippers” of the VLAN tag, then in my ARP table has two records with same mac, one for lan1.10 and second for lan1.20. It’s a reason why ARP replies can’t arrive correctly, because here is not clear to which VLAN it can be delivered…

Then looks logical to use different MAC adresses for these virtual devices and things started to go well… But I haven’t uck with this approach too…

Anyway, with this technology I’m not able to configure reliable VLANs with trunk port (s)


Some people on the forum mentioned VLAN Awarness Bridge(s). Maybe it will works???

Seems that nobody discover that it’s COMPLETELY DIFFERENT technology to get VLANs working and can’t be mixed with previous approach with lan1.10 virtual devices. But, ok, after discovered this fact, I have got a try to this way too.

This technology is very simmilar to classical managed switches. You create one switch (bridge), assign physical ports to the switch, (set ip dev bridge master) and then define vlan table by bridge vlan commands.

Additionaly, when I try to capture packets in the bridge by tcpdump -i
-v -e
I can see vlan tags, so it’s closest to target. But problem with this technology is how to assign “VLAN access ports” to the bridge to allow correct DHCP functioanlity for all VLANs etc.

I have tried to create virtuals eth0:0 or eth1:0 by ifconfig command but these links are not visible for bridge vlan command. I have tried virtual dummy devices (sudo ip link set name eth10 dev dummy0) and assign to them IP from requested vlan ranges, put them to the bridge… But again, no luck. Unable to get DHCP functional, ARPs problems again…

Then even to use VLAN Awarness Bridge(s) I’m not able to get VLANs with TRUNK port and DHCP functional.


I have spent so much time to “learn” these new LAN technologies by OpenWRT way, and push my Turris to do what I want. No luck. Time what I want to spent on other, original projects, which i share with comunity…
I don’t thing that I’m beginner in networking. But I’m from little bit different world (Windows, Mikrotik). I know how things work. Anyway, with TOS3 and switch approach my VLANs has worked smoothly. With TOS5, I waste a week to get things go by right way, with no luck. And by looking through the Turris forum posts, I’m not alone…

I expect many dehonesting comments onto this post from users on the forum. I expect mentions that my requirements are special, need deep knowledge, it’s only for experienced users, Turris is only for special people etc… I have got this kind of mentions 2 times before from NIC team mebers (PEPE)…

So I can afford to present one mention to NIC team too: OpenWRT and TOS documentation is mix of outdated pages, complete opposite recipes, and chaotic pages. It can brings headache to anybody who is looking here for help. And seems that Turris documentation goes by this same way.

  • Old Forum
  • New forum
  • Old doc site
  • New doc site
  • Outdated pages
  • One page says One thing, second completely opposite thing…

I know better is to start buid from scratch, it’s simplier and more quick approach then maintain current state… But it’s horrible approach for all users. And remember, these users bought your expensive device with expectations that it will works, will get some support and will helps them to handle personal networking tasks…

I’m using OpenWRT since early years from 2000 decade and I have been advocate for OpenWRT… In these times, all was clear and updated. User has been able to set things based on recipe on the OpenWRT pages easily. Now it’s gone.

So far so god. Is time to say goodbye Turris and OpenWRT. I have ordered APU2 device and going to run pfSense here. It will be cheaper then Turris or Mox (240GB SSD included), allows to me easily set Suricata, ReverseProxy, OpenRadius and many other things on one place, with clear maintained documantation. I briefly goes through pfSense doc site, and it’s COMPLETELY DIFFERENT approach then Turris/OpenWRT doc.

And remember that it’s same bussiness model as CZNIC Turris/Mox bussines. Modified linux distro free for use and selling certified hardware devices to make profit.


My post is long. My post is farewell. I do not expect that someone will react with functional recipe how to make VLANs with Trunk and DHCP functional. It’s just simple remember to CZNIC, that devices (especially Expensive devices) are here for customers and users, not for developers and people who watch on their customers as stupids second category people. From the forum, i have got feeling that CZNIC team completely forget this. And remember, we PAID lot of money for Turris. So, any kind of maintenance and support can be really good. It’s good habit if you are selling something “exclusive”…

4 Likes

VLAN on TOS 5 is one of the reason, why not update from TOS 3.

@viktor Just notice. TOS5 is Linux. VLAN on Linux is nothing special. No reason to not support VLAN on TOS5. But maybe is an bug inside the TOS5 and it’s kernel, or is necessary to configure it specially. Many peple on the forum tried to get VLANs functional. I do not understand why someone from NIC team didn’t spend day or two to investigate the problem and prepare some official info… CZNIC must be full of networking experts, with deep linux networking knowledge. I think that it can’t be big problem for them…

Have you read up on Linux’s DSA documentation Total obsolete VLAN documentation ?

That aside there are some bugs in Linux’s DSA code that can cause issues and are being fixed mostly in Kernel 5.4 and up and not all of it gets backported to kernel 4.14 (OpenWrt 19.7.x | TOS5.x), albeit the TOS dev already implemented some patching on their own in TOS5.x

So we have to wait for OpenWrt 20.xx and TOS 6. With kernel 5.4 will be also better support for SFP.

What to wait for? DSA works as intended in TOS5 as well as VLAN tag management, either by the kernel or DSA. For the latter the user has to read up the available documentation, no UCI parsing currently available from OpenWrt or TOS, thus no UI either.

2 Likes

Well, that’s a statement. You are not alone, but why didn’t you look into forum before writing this post? @anon82920800 described in detail how to use dsa… (link and also read the following posts).
But I totally second that there is no official documentation from team for it, which I deem the wrong way. And it is also the wrong way to always insist in referring to upstream documentation - this project was clearly promoted to deliver necessary documentation how-tos. And VLAN configuration definitely belongs to it…

2 Likes

Turris Team, please add this topic to the docs. Thank you!

And thank you for your comment, @anon82920800. I just updated to TOS5. Than I was looking at the documentation page to see how to configure a VLAN. I found: nothing. But I found this topic here. I think VLAN needs to be mentioned in the documentation, too. A good reason to “bump the topic to the top of its list”.

1 Like

This is already documented in our documentation. See it here:

In past, there were details in our forum and Gitlab how you can add VLANs.

2 Likes

Well, this information is about how to create software VLANs where traffic needs to pass CPU and therefore causes load. So as long as this does not invoke bridge or if-commands (which is still not available upstream if I’m not mistaken) it is the worse solution compared with CLI-options.
Why do you not list the exact bridge-commands to invoke hardware-based VLANs in documentation or at least link upstream manuals?
But bottom line: yes, this does work.

1 Like