New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FS#1622 - DSA switch port vlan #8499
Comments
opotonil: I forget add information about the bridge:
I too have try with "ip-bridge":
But I think I needs some kernel module to can use it:
|
ffainelli: You need CONFIG_BRIDGE_VLAN_FILTERING for these commands to work. What platform/Soc/switch model are you using? |
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
|
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
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"? |
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'
|
opotonil: I don't understand anything!!! It must be an bug somewhere If I boot with this config:
Do not work, but if change the config, for example, to:
Now I reload the network: And I change the network configuration to the first configuration:
Now I reload the network again: All work ok (ping from Linux PC connected to lan0):
PS: To this workaround to work is required a kernel with CONFIG_BRIDGE_VLAN_FILTERING |
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 :) |
opotonil: The trouble continue in OpenWrt 19.07.0 |
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.
This is how I would implement your setup for Broadcom DSA switch on Homeware:
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? |
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 |
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:
The text was updated successfully, but these errors were encountered: