search

openwrt / openwrt

This repository is a mirror of https://git.openwrt.org/openwrt/openwrt.git It is for reference only and is not active for check-ins. We will continue to accept Pull Requests here. They will be merged via staging trees then into openwrt.git.
Other
20.27k stars 10.49k forks source link

FS#1622 - DSA switch port vlan #8499

Open openwrt-bot opened 6 years ago

openwrt-bot commented 6 years ago

opotonil:

Device: Turris Omnia Version: OpenWRT-18.06-rc1

Steps to reproduce:

Network configuration: config interface 'lan' option type 'bridge' option ifname 'lan0 lan1 lan2 lan3 lan4.1' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0'

config interface 'dmz' option type 'bridge' option ifname 'lan4.2' option proto 'static' option ipaddr '192.168.2.1' option netmask '255.255.255.0'

From router, I have ping with the other device on both vlan:

ping -c 3 192.168.1.5

PING 192.168.1.5 (192.168.1.5): 56 data bytes 64 bytes from 192.168.1.5: seq=0 ttl=64 time=0.434 ms 64 bytes from 192.168.1.5: seq=1 ttl=64 time=0.335 ms 64 bytes from 192.168.1.5: seq=2 ttl=64 time=0.333 ms

--- 192.168.1.5 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.333/0.367/0.434 ms

ping -c 3 192.168.2.5

PING 192.168.2.5 (192.168.2.5): 56 data bytes 64 bytes from 192.168.2.5: seq=0 ttl=64 time=0.455 ms 64 bytes from 192.168.2.5: seq=1 ttl=64 time=0.341 ms 64 bytes from 192.168.2.5: seq=2 ttl=64 time=0.337 ms

--- 192.168.2.5 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.337/0.377/0.455 ms

But from other device connected to lan0 port I can't do ping. More exactly, the situation is the next:

openwrt-bot commented 6 years ago

opotonil:

I forget add information about the bridge:

brctl show

bridge name bridge id STP enabled interfaces br-dmz 7fff.d858d70060c0 no lan4.2 br-lan 7fff.d858d70060c0 no lan0 lan1 lan2 lan3 lan4.1 wlan0 wlan1

I too have try with "ip-bridge":

bridge vlan show

port vlan ids lan0 None lan1 None lan2 None lan3 None br-dmz None lan4.2 None br-lan None lan4.1 None wlan0 None wlan1 None

But I think I needs some kernel module to can use it:

bridge vlan add vid 1 dev br-lan

RTNETLINK answers: Not supported

bridge vlan add vid 1 dev br-lan untaged

RTNETLINK answers: Not supported

openwrt-bot commented 6 years ago

ffainelli:

You need CONFIG_BRIDGE_VLAN_FILTERING for these commands to work. What platform/Soc/switch model are you using?

openwrt-bot commented 6 years ago

opotonil:

I am using (mvebu - cortexa9)

I am not sure about of the switch model, I think it is a Marvell 88E6176:

The trouble is only with the switch ports, the other devices (wlan0 and wlan1) part of the bridge work as expected. So I think CONFIG_BRIDGE_VLAN_FILTERING can't help... but I don't know much about this theme.

PS: Confirmed, the switch is Marvell 88E6176

dmesg | grep switch

[ 0.984318] mv88e6085 f1072004.mdio-mii:10: switch 0x1760 detected: Marvell 88E6176, revision 1 [ 1.523476] mv88e6085 f1072004.mdio-mii:10: switch 0x1760 detected: Marvell 88E6176, revision 1 [ 1.698508] DSA: switch 0 0 parsed

openwrt-bot commented 6 years ago

opotonil:

Solved in part (for "br-lan", "br-dmz" continue pending).

First is required compile the kernel with the option "CONFIG_BRIDGE_VLAN_FILTERING" an install the package "ip-bridge". Then is needed change UCI configuration to use "lan4", with "lan4.1" it do not work:

config interface 'lan' option type 'bridge' option ifname 'lan0 lan1 lan2 lan3 lan4' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0'

To continue enabling vlan filtering in the "br-lan" bridge:

echo "1" > /sys/class/net/br-lan/bridge/vlan_filtering

And finally, configure the vlan as tagged in the switch port:

bridge vlan add vid 1 dev lan4 master

Getting:

bridge vlan

port vlan ids lan0 1 PVID Egress Untagged

lan1 1 PVID Egress Untagged

lan2 1 PVID Egress Untagged

lan3 1 PVID Egress Untagged

lan4 1

br-lan 1 PVID Egress Untagged

veth0 1 PVID Egress Untagged

wlan1 1 PVID Egress Untagged

wlan0 1 PVID Egress Untagged

But now, How can I configure the second bridge "br-dmz" if I can't add the same interface "lan4" to two bridges and I can't use "lan4.1" and "lan4.2"?

openwrt-bot commented 6 years ago

opotonil:

I am trying replicate my old swconfig configuration:

config interface 'lan' option type 'bridge' option ifname 'eth0.1' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0'

config interface 'dmz' option type 'bridge' option ifname 'eth1.2' option proto 'static' option ipaddr '192.168.2.1' option netmask '255.255.255.0'

config switch option name 'switch0' option reset '1' option enable_vlan '1'

config switch_vlan option device 'switch0' option vlan '1' option ports '0 1 2 3 4t 6t'

config switch_vlan option device 'switch0' option vlan '2' option ports '4t 5t'

openwrt-bot commented 6 years ago

opotonil:

I don't understand anything!!! It must be an bug somewhere

If I boot with this config: config interface 'lan' option type 'bridge' option ifname 'lan0 lan1 lan2 lan3 lan4.1' option proto 'static' [...]

config interface 'dmz' option type 'bridge' option ifname 'lan4.2' option proto 'static' [...]

Do not work, but if change the config, for example, to: config interface 'lan' option type 'bridge' option ifname 'lan0 lan1 lan3 lan4' option proto 'static' [...]

config interface 'dmz' option type 'bridge' option ifname 'lan2' option proto 'static' [...]

Now I reload the network: /etc/init.d/network reload

And I change the network configuration to the first configuration: config interface 'lan' option type 'bridge' option ifname 'lan0 lan1 lan2 lan3 lan4.1' option proto 'static' [...]

config interface 'dmz' option type 'bridge' option ifname 'lan4.2' option proto 'static' [...]

Now I reload the network again: /etc/init.d/network reload

All work ok (ping from Linux PC connected to lan0): $ ping -c3 192.168.1.5 PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data. 64 bytes from 192.168.1.5: icmp_seq=1 ttl=64 time=0.598 ms 64 bytes from 192.168.1.5: icmp_seq=2 ttl=64 time=0.576 ms 64 bytes from 192.168.1.5: icmp_seq=3 ttl=64 time=0.574 ms

--- 192.168.1.5 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2039ms rtt min/avg/max/mdev = 0.574/0.582/0.598/0.029 ms

$ ping -c3 192.168.2.5 PING 192.168.2.5 (192.168.2.5) 56(84) bytes of data. 64 bytes from 192.168.2.5: icmp_seq=1 ttl=64 time=0.598 ms 64 bytes from 192.168.2.5: icmp_seq=2 ttl=64 time=0.576 ms 64 bytes from 192.168.2.5: icmp_seq=3 ttl=64 time=0.574 ms

--- 192.168.2.5 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2039ms rtt min/avg/max/mdev = 0.574/0.582/0.598/0.029 ms

PS: To this workaround to work is required a kernel with CONFIG_BRIDGE_VLAN_FILTERING

openwrt-bot commented 5 years ago

rmounce:

As the contributor of hardware support for the Turris Omnia I received a direct request for feedback on this issue, and thought it best to share my thoughts publicly.

I did have VLANs working fine with swconfig / mvsw61xx, but the Omnia was switched to DSA shortly before hardware support was merged. I didn't notice the issue at that point as I was only testing with a single VLAN client device, not switching between ports. Sorry to say that I did notice this issue myself after support was merged, indeed it remains a blocker for putting my Omnia into production!

I believe there is an intention to migrate all DSA supported devices from swconfig (including Linksys WRT1900AC & family), so this issue will need to be solved for those devices too.

The suggested VLAN filtering solution is good if you can configure everything directly with 'bridge'. I don't think UCI currently supports configuring it, and I think there will be many other parts of OpenWrt that assume each network has its own unique bridge device, rather than a unique VLAN on a shared bridge.

The former certainly maps better to the switch hardware to which we are offloading, but configuration is less intuitive than lan4.2 VLAN sub-interfaces IMHO. There are also special cases such as remapping VLANs between ports e.g. two different ISP links come in tagged as VLAN 2, and you want to bridge both of them through to your own link as VLAN 3 and 4 while also using VLAN 2 on your link for another pre-existing VLAN. You can't do this kind of VLAN remapping / translation on anything short of insanely expensive enterprise switches, but it is trivial to do in software with the kernel :)

I don't know if DSA supports offloading bridged VLAN sub-interfaces in the first place, but even then it will need to be bypassed to handle hairy cases like this. I've long been attracted to DSA because of this idea; presenting a well defined interface that can treat individual switch ports like normal NIC interfaces and achieve all of the same crazy $#!t in software, while transparently offloading the rest to hardware wherever possible.

Another shortcoming of DSA that I saw a patch for but is not yet merged to my knowledge, is the ability to use multiple 'CPU' uplink ports such as those that exist on the Turris Omnia. I don't know if mv88e6xxx-class hardware supports L4 hashing or even L2 hashing to split traffic somewhat evenly across links. Maybe some kind of scheme that can sample the traffic for each port / VLAN across the CPU port and re-balance every few minutes. Personally I was happy with static assignment of VLANs to switch uplink ports, as is achievable with the 'dumb' swconfig driver. A perfect solution may not exist, but right now DSA can't use more than 50% of the switch uplink to my most powerful router even in the best case.

Sorry for presenting a rant with more questions than answers. It's late here down under and the actual task of implementing a solution in the kernel or even deeper into the bowels of OpenWrt/UCI is beyond me, though I'd love to help/test if I had the time :)

openwrt-bot commented 4 years ago

opotonil:

The trouble continue in OpenWrt 19.07.0

openwrt-bot commented 4 years ago

LuKePicci:

I started reading this while looking for current support status of DSA into vanilla OpenWrt. I'm used to work with DSA because of my experience with hacked Technicolor devices running Homeware (above version 10), where DSA exists since OpenWrt 12 forks on Broadcom switches.

But now, How can I configure the second bridge "br-dmz" if I can't add the same interface "lan4" to two bridges and I can't use "lan4.1" and "lan4.2"?

This is how I would implement your setup for Broadcom DSA switch on Homeware:

config interface 'lan' option ifname 'vlan_eth1 vlan_eth3' option type 'bridge' option proto 'static' option netmask '255.255.255.0' option force_link '0' option ip6assign '0' option ipaddr '192.168.1.1' option ipv6 '0'

config interface 'dmz' option ifname 'vdmz_eth0 vdmz_eth2' option type 'bridge' option proto 'static' option netmask '255.255.255.0' option force_link '0' option ip6assign '0' option ipaddr '192.168.2.1' option ipv6 '0'

config interface 'wan' option proto 'dhcp' option graceful_restart '1' option auto '1' option ifname 'waneth4' option ipv6 '0'

config interface 'voip' option auto '1' option proto 'static' option defaultroute '1' option peerdns '0' option ip4table 'voip' option ifname 'voipeth4' option netmask '255.255.248.0' option ipaddr '10.42.0.2'

config interface 'ont' option proto 'static' option netmask '255.255.255.0' option ipv6 '0' option ip6assign '0' option ipaddr '192.168.100.42' option ifname 'eth4' option force_link '0'

config device 'waneth4' option enabled '1' option type '8021q' option name 'waneth4' option macaddr 'A4:91:B1:xx:xx:xE' option ifname 'eth4' option vid '835'

config device 'wanptm0' option type '8021q' option name 'wanptm0' option macaddr 'A4:91:B1:xx:xx:xE' option ifname 'ptm0' option vid '835'

config device 'voipeth4' option enabled '1' option type '8021q' option name 'voipeth4' option macaddr 'A4:91:B1:xx:xx:xF' option ifname 'eth4' option vid '935'

config device 'voipptm0' option type '8021q' option name 'voipptm0' option macaddr 'A4:91:B1:xx:xx:xF' option ifname 'ptm0' option vid '935'

config route 'voip_default' option interface 'voip' option netmask '255.0.0.0' option metric '1' option target '10.0.0.0/8' option gateway '10.42.0.1'

config device 'vdmz_eth0' option type '8021q' option ifname 'eth0' option name 'vlan_eth0' option mtu '1500' option vid '2'

config device 'vlan_eth1' option type '8021q' option ifname 'eth1' option name 'vlan_eth1' option mtu '1500' option vid '1'

config device 'vdmz_eth2' option type '8021q' option ifname 'eth2' option name 'vlan_eth2' option mtu '1500' option vid '2'

config device 'vlan_eth3' option type '8021q' option ifname 'eth3' option name 'vlan_eth3' option mtu '1500' option vid '1'

config switch 'bcmsw_int' option reset '1' option type 'bcmsw' option qosimppauseenable '0' option jumbo '1' option unit '0' option enable_vlan '0'

config switch 'bcmsw_ext' option reset '1' option type 'bcmsw' option qosimppauseenable '0' option unit '1' option enable_vlan '1' option jumbo '1'

config switch_vlan 'lan_switch' option device 'bcmsw_ext' option vlan '1' option ports '2 4 8t'

config switch_vlan 'dmz_switch' option device 'bcmsw_ext' option vlan '2' option ports '1 3 8t'

As you can see there are some config device '...' in there, which looks very similar to macvlan devices but also supports selecting the vlan. They are referred to as "manual configuration" of driver-level VLAN devices and as said [[https://openwrt.org/docs/guide-user/network/vlan/switch_configuration#creating_driver-level_vlans|in the wiki]] it is indeed more powerful then the automatic dot notation (eg. lan4.2). Did you try that way too?

openwrt-bot commented 4 years ago

n8v8R:

VLAN filtering does not work out of the box due to particular CPU - Switch setup (dual CPU, each CPU featuring its own physical lane to the Switch chip, CPU eth0 <-> Switch port 6 and CPU eth1 <-> Switch port 5) and in lieu of Linux kernel support for such setup.

The device manufacturer has a developed a patch [1], which makes it work, that is not available in OpenWrt however (and communication about patch acceptance in Linux kernel appear stalled [2])

Otherwise VLAN tag management would appear to be working with the //bridge v// command as outlined in the Linux documentation [3 | 4]. There is however currently no support for it in OpenWrt [5].

Also the OpenWrt forum is exhibiting various threads about the correct use of //bridge v// and the mounting confusion about DSA now that with the Master branch more devices are being moved to DSA.

[1] https://gitlab.labs.nic.cz/turris/turris-build/-/blob/hbd/patches/openwrt/wip/0009-mvebu-turris-omnia-multi-cpu-dsa.patch
[2] https://www.spinics.net/lists/netdev/msg595295.html
[3] [[https://www.linux.org/docs/man8/bridge.html]]
[4] [[https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html]]
[5] [[https://github.com/openwrt/luci/issues/2798]]