[Solved] Internet redudancy with two routers and two connections

anon45274024 · January 5, 2020, 9:32pm

Oh wait one, there is a way perhaps:

remove say lan3 from the lan bridge
create lan3.1 and add it to the lan bridge
create lan3.2 and add it to the TO's WAN firewall and use it in mwan3

configure the switch that host the SAT m-r with the necessary tagging and you should be good to go even with a single wire

lampra1 · January 5, 2020, 9:37pm

Thank you, I will try this.
I will do my "homework" with the configuration of my switches and return here.

lampra1 · January 9, 2020, 1:55am

I configured my switch for vlan1. Then I created a lan0.1 on TO and added it to the lan bridge but I lost connectivity to the lan. Even if i create a new interface with lan0.1 (bridged or not) I can't connect to lan devices.
Any idea how to proceed?

Summary

bridge v a dev br-lan self vid 1 untagged pvid
RTNETLINK answers: Not supported

root@Turris:~# lsmod | grep 802
root@Turris:~# 

root@Turris:~# ubus -S call system board
{"kernel":"4.14.95","hostname":"Turris","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"OpenWrt","version":"18.06.2","revision":"r7676-cddd7b4c77","target":"mvebu\/cortexa9","description":"OpenWrt 18.06.2 r7676-cddd7b4c77"}}

root@Turris:~# bridge v
port	vlan ids
lan1	None
lan2	None
lan3	None
lan4	None
br-lan	None
wlan0	None
lan0.1	None

root@Turris:~# cat /proc/lan0.1
lan0.1  VID: 1	 REORDER_HDR: 1  dev->priv_flags: 1201
         total frames received            0
          total bytes received            0
      Broadcast/Multicast Rcvd            0

      total frames transmitted            0
       total bytes transmitted            0
Device: lan0
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings: 

root@Turris:~# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 532
    link/ether d8:58:d7:00:30:38 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 532
    link/ether d8:58:d7:00:30:36 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 532
    link/ether d8:58:d7:00:30:37 brd ff:ff:ff:ff:ff:ff
5: lan0@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether d8:58:d7:00:30:36 brd ff:ff:ff:ff:ff:ff
6: lan1@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether d8:58:d7:00:30:36 brd ff:ff:ff:ff:ff:ff
7: lan2@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether d8:58:d7:00:30:36 brd ff:ff:ff:ff:ff:ff
8: lan3@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether d8:58:d7:00:30:36 brd ff:ff:ff:ff:ff:ff
9: lan4@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether d8:58:d7:00:30:36 brd ff:ff:ff:ff:ff:ff
10: wwan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether a2:e3:41:a9:2c:08 brd ff:ff:ff:ff:ff:ff
12: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether d8:58:d7:00:30:36 brd ff:ff:ff:ff:ff:ff
14: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
    link/ether 04:f0:21:22:dc:5e brd ff:ff:ff:ff:ff:ff
31: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1360 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none 
34: lan0.1@lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
    link/ether d8:58:d7:00:30:36 brd ff:ff:ff:ff:ff:ff

anon45274024 · January 9, 2020, 11:16am

That would indicate the necessary kernel build configuration flag

CONFIG_BRIDGE_VLAN_FILTERING=

not being set and thus the feature to

selectively receive and forward traffic based on VLAN information in the packet any VLAN information configured on the bridge port or bridge device.

is not working.

Even if the flag would be set it may still not be working on the TO due to

is not what I wrote

ip l and bridge bridge v serve different purposes ^[1] in the VLAN context.

For your use case bridge vlan filtering may not be necessary.

TOL3 = TO LAN3 port
EMS = external managed switch (that hosts the SAT and other LAN clients)
EMSpT = external managed switch port that connects by single wire to TOL3
EMSpS = external managed switch port that connects the SAT
EMSpL = = external managed switch port that connects the LAN clients

TOL3 < ---- single wire ---- > EMSpT

Now building a VLAN trunk

On the TO

/etc/config/network

config interface 'lan'
	option ifname 'lan0 lan1 lan2 lan3.1'

config interface 'vlan_EMS'
	proto='none'
	option ifname='lan3.2'

/etc/config/firewall

config zone
	option name 'wan'
	list device 'eth2'
	list device 'lan3.2'

Restart network and use lan3.2 in mwan

On the EMS

configure EMSpT as trunk port - tagged egress with VLAN IDs 1 and 2
configure EMSpS as access port - untagged egress with VLAN ID 2
configure EMSpL as access port - untagged egress with VLAN ID 1

^[1] https://github.com/openwrt/luci/issues/2798#issuecomment-569430845

mk24 · January 9, 2020, 1:56pm

I don't have any experience with DSA but I thought it was supposed to be simple.

Each physical Ethernet cable port appears as an independent interface like it's a direct port into the CPU, even though there may actually be a hardware switch involved.
For conventional untagged "access" ports, include multiple ports in the interface in /etc/config/network.
For a cable to emit / receive tagged packets, add a VLAN number to the port name. Using the same port with different VLANs in different networks will build a "trunked" connection.

The config system is then supposed to abstract the device's hardware details and build out the desired topology using an optimal combination of hardware switching and software bridging. That's the pipe dream anyway.

anon45274024 · January 9, 2020, 3:54pm

It actually works, that said:

managing VLAN tagging for bridges and lan ports requires to be set

multi-cpu-dsa requires a patch (connect more than one CPU to the switch dev) for vlan_filtering to work
currently no LuCI support for managing vlan_filtering

lampra1 · January 9, 2020, 4:02pm

Actually, this was my bad in switch configuration. I didn't have the port configured as tagged so the untagged traffic was not passing through. Now that the switch is correctly configured, it works as expected (even with lan0.1 where the cable is now attached). I will need to install the third switch and finish the configuration but this seems trivial now.

Thank you vary much.

system · January 19, 2020, 4:02pm

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