Current lan ip's
TO: Lan 10.0.10.1
Satellite router: 10.0.10.53 lan & 88.xx.xx.xx wan
Managed switches and clients: 10.0.10.0/24
I could use the managed switches to assign all the clients to VLAN ID 1.
I could use the managed switch1 to assign the incoming satellite port to VLAN ID 1 & 2.
How should I configure TO in order to accept lan traffic from VLAN ID 1 and also create an interface (with VLAN ID 2) to be used with mwan3 that routes traffic to the satellite router?
VLAN ID 1 is set as default for all swtich ports, which are in untagged state - just run bridge v on the ssh cli to check/see.
The lan port on the TO that connects to the external switch should preferably not be enslaved in a bridge device. On that lan port, say lan4, change the VLAN ID to 2 with
bridge v a dev lan4 vid 2 pvid untagged
suppose the external swtich been configured accordingly.
If it does not work however try on TO instead
bridge v a dev lan4 vid 1 pvid untagged && bridge v a dev lan4 vid 2
root@Turris:~# bridge v
-ash: bridge: not found
root@Turris:~# opkg install bridge
Installing bridge (1.5-6) to root...
Downloading http://downloads.openwrt.org/releases/18.06.2/packages/arm_cortex-a9_vfpv3/packages/bridge_1.5-6_arm_cortex-a9_vfpv3.ipk
Configuring bridge.
root@Turris:~# bridge v
-ash: bridge: not found
The last port (wan) was "fried" by a lightening!!!!
root@Turris:~# ip l | grep lan
5: lan0@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
6: lan1@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
7: lan2@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
8: lan3@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
9: lan4@eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
12: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
14: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP mode DEFAULT group default qlen 1000
Right then, now it gets a bit complicated - because
I am not familiar with mwan3 and how it relates (WAN) firewall zones and whether it can distinguish VLAN traffic on a single TO lan port as WAN and LAN
your network layout
TO's Multi-CPU-DSA and bridge vlan_filtering
Supposedly all WAN facing ports should be in the TO's WAN firewall zone, least that would be my understanding.
Since the SAT modem-router connects to a swtich, that also hosts various LAN clients, it would not make sense to be assigned to the TO's WAN firewall zone however and likely cause firewall related issues, not sure whether/how mwan3 relates to firewall zones.
If however the SAT modem-router is not firewalled somewhere else but plugged into LAN firewall zone at the TO it would create a security risk.
From that perspective it would be sensible to run 2 wires between the external switch and the TO - one for the LAN traffic and one for the traffic with the SAT modem-router. Does that make sense and is feasible to setup?
Running a second wire is feasible but complicated for the moment as I will need to dig the ground. I assume that installing a third managed switch after the satellite router would be easier for now. Please note that only the managed switches are connected to the un-managed switch ports of the satellite router.
Though, maybe what you proposed is also doable. From what I understand from this explanation, I might be able to tag the traffic from clients using the managed switches. Then all the untagged traffic will be from the satellite router which could be assigned a PVID before reaching TO.
I will need to read a bit about VLAN configuration on my switches (TL-SG108PE) and return here.
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
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
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.
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.
scrap that one, it is unusable then?