Cannot recreate VLANs in 5.x

Hello, I’m too dumb to recreate VLAN configuration from 3.x.

I want to recreate this condition in 5.x:

VLAN - Turris Documentation is not detailed enough for me, I don’t get it.

Please, could you help me?

The switch configuration is now performed as if you would look into it from CPU point of view. Take the CPU port (and port 6 of course as well as it goes to CPU as well) and see in which bridge (network) they are part of. You want to add lan0 for port 0 and lan1 for port 1 and so on to the bridge where you would have originally eth0. Do not assign eth0, the kernel already knows about the lanX and ethX interconnection.
The second vlan is not used if I am looking correctly.
The third vlan is a little bit special. This is not even covered in our migration script as it wasn’t clear if anyone actually was using it this way. Actually you want to create bridge with protocol none where you add interfaces lan2.3 and lan3. The special syntax lanX.Y is that communication on that specific LAN port is tagged with Y.
You do not have to care about VLAN in switch. Just using separate bridge creates separate network. The only time you need to care about VLAN is when you want to tag communication going outside of the router-switch.

Many thank you Karel for insight! It works!

Regards,
Tim

After upgrading to 5.3 I am struggling to get my network re-configured. I have multiple VLANs using a mix of tagged and untagged ports. For my main network I have a VLAN that is available on two trunk ports as well as on two untagged ports. I created a interface for this network (with Protocol: “Static address”) and created a bridge over those 4 interfaces:

image

I have spent days to figure out why some devices are not reachable. It seems that there is no connection between VLAN 3 on the tagged ports and the untagged ports lan2 and lan4. For example, I can ping between the devices connected to ports lan2 and lan4 but I cannot ping my WLAN AP connected via port lan0.3 (with another switch inbetween). All devices do obtain IP configuration from the Omnia - I can see the IP addresses and lease times in Luci.

How do I get lan0.3/lan3.3 to talk to lan2/lan4?

To me it seems that I should do what was proposed above, just with my interfaces:

“Actually you want to create bridge with protocol none where you add interfaces lan2.3 and lan3.”

How do I create a bridge between VLANs at tagged ports and untagged ports?

I am aware of VLAN - Turris Documentation but I do not know how to create an interface with protocol ‘none’. And does this mean that I should create somehow a separate bridge or modify the bridge has been created when I checked the checkbox “Bridge interfaces”?

Some outputs from my terminal:

Command: ip -d link show dev lan0.3 | grep ‘vlan protocol’
vlan protocol 802.1Q id 3 <REORDER_HDR>

The same command for lan2 does not show anything

Command: brctl show

bridge name	bridge id		STP enabled	interfaces
br-DMZ		7fff.d858d7008385	no		lan0.1
							lan1
							lan3.1
br-Darknet		7fff.d858d7008385	no		lan0.3
							lan3.3
							lan4
							lan2
br-LoT		7fff.d858d7008385	no		lan0.4
							lan3.4
br-guest_turris		7fff.d858d7008385	no		lan0.5
							lan3.5
br-lan		7fff.d858d7008385	no		lan0.2
							lan3.2

Any help is greatly appreciated.

Set the protocol to Unmanaged.
Can you use tcpdump to verify that there is no traffic between lan2 and lan0.3?

I don’t know how to run TCPDUMP on the Omnia and currently have no other way either. Any pointer would be appreciated but I think it is not needed right now. There is definitely some traffic now between the tagged and untagged interfaces (see below) but my problems are not gone.

I am also not sure how the “unmanaged” interface should be used in my scenario. I might well miss something as I am not that competent in networking. I currently have an interface named ‘Darknet’ with a “Static Address” with the following configuration:

config interface 'Darknet'
	option proto 'static'
	option type 'bridge'
	option netmask '255.255.255.0'
	option ipaddr '192.168.67.13'
	list ifname 'lan0.3'
	list ifname 'lan3.3'
	list ifname 'lan4'

Earlier today, after my post here, I changed the line

   option ifname 'lan0.3 lan2 lan3.3 lan4'd

to

    list ifname 'lan0.3'
    list ifname 'lan2'
    list ifname 'lan3.3'
    list ifname 'lan4'

(I removed lan2 from this network since my earlier post)

and suddenly I was able to ping from my both PCs (connected to lan2 and lan4) to my WLAN AP (connected to a switch behind lan0.3). I thought now the problem is solved but I was wrong. I continued to re-configure my network (note: my network stopped working after the forced upgrade to 5.3 and I need to recreate some configurations (DHCP leases mainly)) and now I have connectivity problems again.

Right now I have 3 devices connected to ‘Darknet’:

  • WLAN AP connected to lan0.3 (via managed switch)
  • PC1 connected to lan3.3 (via managed switch)
  • PC2 connected to lan4

(all devices get their IP address via DHCP from the Omnia from the IP range configured for the Interface “Darknet”)

  • From PC1 I can only ping PC2 (AP is “Destination Host Unreachable”)
  • From PC2 I can ping PC1 and AP
  • From my Omnia I can ping everything.

I do not understand why this changed from before. Why can I now connect from lan2 to lan0.3 and lan3.3 but not from lan3.3 to lan0.3?

I am very confused :frowning:

I think I narrowed down the problem with VLANs. It seems that my Omnia does not route between two VLAN trunks. A physical port assigned to a VLAN seems to be able to communicate with a device that is behind a VLAN trunk (tagged interface) while two tagged interfaces seem not to be able to communicate with each other (at least in the same VLAN). I had two switches (with VLAN support) connected using VLAN trunks and I was not able to communicate between devices that were connected via those two switches.

I got my network now to work by connecting the second switch to the first switch and the first switch to the Omnia rather than connecting both switches directly to the Omnia. This is not ideal for my network topology but seems to work and I usually don’t have much traffic going on.