What is not clear to me is the connection between switch and CPU:
I thought about some of these question, too:
But maybe someone from Turris team can explain this to us better?
swconfig dev switch0 help | grep cpuswitch0: 10.mvsw61xx(MV88E6176), ports: 7 (cpu @ 5), vlans: 64
See https://openwrt.org/docs/techref/swconfig:
There in the examples you can find only one CPU port. So maybe it’s a limitation of swconfig. I still think it doesn’t matter which port is named CPU. It’s just naming. Port 5/6 are connected to eth0/2 and that’s all that matters… When you install vanilla OpenWRT on TO only eth0 can be used. It think this is typical for OpenWRT and TO’s design is very unique. I think TurrisOS has some patches so that eth0/2 both can be used… But still only Port5 is named CPU
Nevertheless I can’t prove what I say here…
EDIT:
root@MarPort:~# swconfig dev switch0 show
Global attributes:
enable_vlan: 1
Port 0:
mask: 0x0000: (0)
qmode: 3
pvid: 3
link: port:0 link:up speed:1000baseT full-duplex
Port 1:
mask: 0x0000: (1)
qmode: 3
pvid: 1
link: port:1 link:down
Port 2:
mask: 0x0000: (2)
qmode: 3
pvid: 1
link: port:2 link:down
Port 3:
mask: 0x0000: (3)
qmode: 3
pvid: 1
link: port:3 link:down
Port 4:
mask: 0x0000: (4)
qmode: 3
pvid: 2
link: port:4 link:down
Port 5:
mask: 0x0000: (5)
qmode: 3
pvid: 0
link: port:5 link:up speed:1000baseT full-duplex
Port 6:
mask: 0x0000: (6)
qmode: 3
pvid: 2
link: port:6 link:up speed:1000baseT full-duplex
VLAN 1:
port_based: 0
vid: 1
ports: 1 2 3 5t
VLAN 2:
port_based: 0
vid: 2
ports: 4 6
VLAN 3:
port_based: 0
vid: 3
ports: 0 5t
VLAN 4:
port_based: 0
vid: 4
ports: 5t
I don’t see any difference between Port 5 and 6 in this output
True to my word I figured out that overriding the MAC of an iface that is not bridged (and plugged into a VLAN) is ceasing connectivity.
And that’s the point I think. So if there is no difference between ports (5 and 6) then where to choose which port will be linked to cpu?
I think I start to understand why just one port can be linked to CPU as “CPU port”.
In MikroTik it is similar: by default all flow goes directly to CPU over switch. If you want enable switch function then you must choose switch “master port” on switch and connect other switch ports to it. It can be always just one “master port” linked to CPU. So to reproduce Omnia setup on MT you can have eth1 as master port, eth2+eth3+eth4 as slaves of eth1 and eth5 out of this switch port group. By this setup there are two ports connected to CPU (eth1 and eth5). Then traffic is isloated between groups on switch but is connected on CPU bridge. At this point it is similar to Omnia setup. The only difference is that on MT you can choose which port will be switch CPU port.
So in Omnia case the RJ45 is not “soldered” directly to eth2 but to switch which gives you freedom to choose other RJ45 to be linked to eth2 but over the switch.
In theory if switch would have 9 ports then WAN RJ45 could be linked to eth1 over switch too.
The only difference I can see is that on Omnia I cannot choose switch CPU port but (or maybe I can but I don’t know how).
Again, TO’s Setup: https://doc.turris.cz/doc/en/howto/vlan_settings_omnia.
It all depends on how you set it up… The switch chip is just a dumb Layer 2 Switch. Just some MAC-Adress-Tables and internal VLAN-routing, that’s all. All ports of it are equal I think. How they are handeled is definded by config. CPU (SOC) is just a network device which is connected to the switch via 2(!) lines, that’s it.
Yes 
Is the second CPU working in this setup? Because in TOS4.HBD it is not and thus the switch would be limited to eth0.
I know. I was asking why just one port is tagged as CPU port and not both of them (5 and 6) and if it can be configured somehow to have both tagged as “CPU port” or how to configure/choose which of them will be “CPU port”. Because tagging is currently not working on port6/eth2.
There is hope for improvement with the upcoming TOS4.x, perhaps also that OpenWRT is close to releasing their next branch 19.01 with kernel 4.14 (4.19 perhaps in autumn).
Unfortunately the 2nd CPU is not working in the current TO 4.HBD state. But what I have seen is that at least the lan ports getting their own configurable ifaces and thus potentially allow for better tuning/fine graining of the switch.
lan0 → …/…/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:10/net/lan0
lan1 → …/…/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:10/net/lan1
lan2 → …/…/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:10/net/lan2
lan3 → …/…/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:10/net/lan3
lan4 → …/…/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:10/net/lan4
I just tested setting Port6/eth2 tagged for VLAN2 -> works.
Network config:
root@MarPort:~# cat /etc/config/network
config interface 'lan'
option force_link '1'
option type 'bridge'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.120.1'
option _orig_ifname 'eth0 eth2 wlan0 wlan1'
option _orig_bridge 'true'
option ifname 'eth0.1 eth2.2'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option vid '1'
option ports '1 2 3 5t'
config switch_vlan
option device 'switch0'
option vlan '2'
option vid '2'
option ports '4 6t'
Ifconfig:
root@MarPort:~# ifconfig
[..]
br-lan Link encap:Ethernet HWaddr D8:58:D7:00:51:BA
inet addr:192.168.120.1 Bcast:192.168.120.255 Mask:255.255.255.0
inet6 addr: fdca:86ed:31cf::1/60 Scope:Global
inet6 addr: XXX
inet6 addr: fe80::da58:d7ff:fe00:51ba/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1543838 errors:0 dropped:0 overruns:0 frame:0
TX packets:3868250 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:117289995 (111.8 MiB) TX bytes:5542136982 (5.1 GiB)
eth0 Link encap:Ethernet HWaddr D8:58:D7:00:51:BA
inet6 addr: fe80::da58:d7ff:fe00:51ba/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:891947 errors:0 dropped:0 overruns:0 frame:0
TX packets:2430333 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:532
RX bytes:70687094 (67.4 MiB) TX bytes:3552831921 (3.3 GiB)
Interrupt:37
eth0.1 Link encap:Ethernet HWaddr D8:58:D7:00:51:BA
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:862013 errors:0 dropped:0 overruns:0 frame:0
TX packets:2372316 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:47189110 (45.0 MiB) TX bytes:3509711343 (3.2 GiB)
[..]
eth2 Link encap:Ethernet HWaddr D8:58:D7:00:51:BC
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1264 errors:0 dropped:0 overruns:0 frame:0
TX packets:39735 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:532
RX bytes:235967 (230.4 KiB) TX bytes:5643857 (5.3 MiB)
Interrupt:40
eth2.2 Link encap:Ethernet HWaddr D8:58:D7:00:51:BC
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1264 errors:0 dropped:0 overruns:0 frame:0
TX packets:1451 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:213215 (208.2 KiB) TX bytes:409303 (399.7 KiB)
swconfig:
root@MarPort:~# swconfig dev switch0 show
Global attributes:
enable_vlan: 1
Port 0:
mask: 0x0000: (0)
qmode: 3
pvid: 3
link: port:0 link:up speed:1000baseT full-duplex
Port 1:
mask: 0x0000: (1)
qmode: 3
pvid: 1
link: port:1 link:down
Port 2:
mask: 0x0000: (2)
qmode: 3
pvid: 1
link: port:2 link:down
Port 3:
mask: 0x0000: (3)
qmode: 3
pvid: 1
link: port:3 link:down
Port 4:
mask: 0x0000: (4)
qmode: 3
pvid: 2
link: port:4 link:up speed:1000baseT full-duplex
Port 5:
mask: 0x0000: (5)
qmode: 3
pvid: 0
link: port:5 link:up speed:1000baseT full-duplex
Port 6:
mask: 0x0000: (6)
qmode: 3
pvid: 0
link: port:6 link:up speed:1000baseT full-duplex
VLAN 1:
port_based: 0
vid: 1
ports: 1 2 3 5t
VLAN 2:
port_based: 0
vid: 2
ports: 4 6t
VLAN 3:
port_based: 0
vid: 3
ports: 0 5t
VLAN 4:
port_based: 0
vid: 4
ports: 5tThis eth2.2 you defined manually in config or it was automatically generated by luci?
Could you post screenshot from luci switch cfg?
I see now. Thanks.
It’s logical. Luci Switch tab just can generate ifaces for eth0 because it’s the only CPU port known for swconfig.
You’re welcome.
And I see now, too. This is the function of defining a switch port as “CPU” I guess. Didn’t know that… But you can still configure Port6 manually.
Thanks for great discussion @protree @anon50890781.
Just one more question:
what means option reset '1' in config switch section?.
I can’t google it anywhere…
Definitly! I don‘t know what this config does…
–switch
Attribute 3 (none): reset (Reset the switch)
https://www.manpages.cz/en/turris-omnia-how-add-new-vlans-and-configuration-internal-switch/
With this config we configure a switch with name switch0, enable vlan support on this switch and reset device.
I would have thought that the option thus is effecting whether swconfig dev switch0 set reset bears fruit (reset ‘1’) or does not (reset ‘0’). However having tested it there was no difference and with either setting the switch settings got reset and the reset state thus survives a reboot.
Hence either it is a bug that it does not make a difference or the setting has another meaning.
Maybe it is a misconception on my end but I would have thought that clients connected to different vlans on the switch would not be able to communicate with each other, being a security feature (management vlan) and as otherwise common in switch hardware. Instead clients on different vlan ids and even with different subnets are able to ping each other. 
This happens either way with port 5 / 6 tagged or not.
The aforementioned links to the vlan config or OWRT documentation or the chip (Marvell 88E6176-TFJ2) documentation don’t really say.
How is VLAN segregation achieved on the switch as opposed through firewall zones?
Did a traceroute? I’m pretty sure they can ping each other over Layer 3 (routed). Routes are created automatically by OpenWRT (see output of route). Each Subnet (LuCi Interface) need its own firewall zone. Then you can define how forwarding should be handled.
This should give you an idea (combine it with information about my setup that I posted earlier)
EDIT: Default Output rule is “accept” (Not visible in screenshot)
