Re: DSA Mini-tutorial still marked as Work In Progress
On Fri, 9 Sep 2022, Michael Richardson wrote: Jo-Philipp Wich wrote: > Bluntly speaking, DSA is the thing that gives you one Linux network > device per switch port and bridge VLAN filtering is the stuff that > allows you declaring swconfig-esque VLAN port groups on top of an > arbitrary bridge interface. .. > Another conceptual issue I see is that people came to expect a > dedicated "switch" configuration ui which is something that does not > really work with DSA devices anymore since there is no dedicated switch > hardware entity to interact with anymore (DSA takes care of completely > abstracting this away from the user point of view) and that > bridge-vlans just happen to be a configuration detail of a bridge, and > that there happens to be a bridge "br-lan" by default, but a system > could have multiple bridges, or none at all. > So we should also explain why there is no central "switch > configuration" anymore and that this does not translate into a loss of > functionality, but that the former semi opague swconfig switch > configuration entity was dissolved into a bunch of ethernet devices > inside a bridge... +1 One thing that we do need to show is what ethernet devices are on the switch, there is a considerable CPU load to routing traffic through the processor vs through the switch, so when people are deciding what ports to use for different purposes, they need to easily be able to see this info. David Lang ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
Jo-Philipp Wich wrote: > Bluntly speaking, DSA is the thing that gives you one Linux network > device per switch port and bridge VLAN filtering is the stuff that > allows you declaring swconfig-esque VLAN port groups on top of an > arbitrary bridge interface. .. > Another conceptual issue I see is that people came to expect a > dedicated "switch" configuration ui which is something that does not > really work with DSA devices anymore since there is no dedicated switch > hardware entity to interact with anymore (DSA takes care of completely > abstracting this away from the user point of view) and that > bridge-vlans just happen to be a configuration detail of a bridge, and > that there happens to be a bridge "br-lan" by default, but a system > could have multiple bridges, or none at all. > So we should also explain why there is no central "switch > configuration" anymore and that this does not translate into a loss of > functionality, but that the former semi opague swconfig switch > configuration entity was dissolved into a bunch of ethernet devices > inside a bridge... +1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
Hey Luiz, On 8.09.2022 06:28, Luiz Angelo Daros de Luca wrote: - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" - VLAN filtering disabled Bridging virtual 802.1q interfaces might fail in some scenarios, like when you use vlan1 or mix tagged with untagged traffic (https://github.com/openwrt/openwrt/issues/9066) I do recommend bridge-vlan as the first option, although ip-bridge is not installed by default. I know that it is a little bit off topic but I would love some transitioning code that could mimic swconfig devices as if they were DSA. Instead of using swconfig settings for tagged vlans/isolated ports, just create fake lan1, lan2, wan interfaces (802.1q) and derive the swconfig settings from that. I've been doing that for some time, creating switch_vlan configs from bridge+bridge-vlan and replacing the user ports with the CPU port in every related bridge-vlan. This way I can share the config with swconfig, DSA and even devices without switches (VM like gns3) if I rename eth0, eth1, eth2 to lan1, wan, lan2. The only downsides are that untagged bridging is done using software bridge and the config is generated as a single-shot step (uci-default). However, if that mapping is done inside netifd, I believe it might be able to better handle those cases. I tried this two months ago, here are the steps I took to be precise: ## Set up the Interfaces - Put each port on a different VLAN as untagged, set the CPU port tagged. - Rename ethX.y to the switch port name you want (optional). - There’s currently no way. So just ignore ethX.y interfaces and manually create VLAN interfaces of ethX with the interface name mimicking DSA. - Put the manually created interfaces on a VLAN filtering enabled bridge. ## Untagged - Set a VLAN ID as untagged on the manually created interfaces. - Configure LAN with that VLAN interface of the bridge to be able to reach the router from the switch ports. This works great until tagged frames are involved: ## Tagged - Set a VLAN ID as tagged for a manually created interface. - Create a new network with that VLAN interface of the bridge. Set IP to 192.168.1.1/24 and use a firewall zone with everything allowed. - Set that VLAN ID on the computer and set IP to 192.168.1.2/24. - Ping 192.168.1.2 from the router. - See if tagged frames pass the switch port with the bridge VLAN filtering feature. - Tagged frames leave the switch port. However, tagged frames coming in will be dropped since the port was configured to only allow untagged frames. If someone is confused like I was before, swconfig’s VLAN filtering won’t interfere with bridge VLAN filtering because they are separate systems. With these findings, there are two changes I can see being made to swconfig: - Allow custom names for the VLAN interface of the CPU port. - Allow forwarding tagged frames to the CPU port coming from a switch port set as untagged. Nonetheless, this is extremely hacky so I just put this out here for some fun talk. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
On 8.09.2022 02:54, Florian Fainelli wrote: On 9/7/2022 3:00 PM, Sebastian Moeller wrote: Hi Jo, I was under the impression* that bridge-vlan filtering is something that can be relegated to the switch hardware, while creating a bridge between VLAN interfaces happens in software. Is that wrong? It is incorrect. DSA offloads the bridge to the switch hardware whether you have VLAN filtering or not. When the bridge is not VLAN aware (vlan_filtering=0) what it means is that the Linux bridge, and the underlying switch MUST accept both VLAN and non-VLAN tagged frames. If you do want VLAN tagged frames in that bridge, then you are supposed to terminate VLAN traffic by creating upper VLAN devices such as lan1.10, lan2.10 etc. but the switching between lan1.10 and lan2.10 still happens in hardware because those VLAN devices are offloaded into the switch hardware. When vlan_filtering=1 is set, the hardware is configured to only accept untagged PVID frames as well as whichever VLAN tagged frames you have configured. For instance, if you configured your bridge this way with: lan1, lan2, lan3 and lan4 part of br-lan with vlan_filtering=1, each switch port will be programmed to be in the bridge's default_pvid (1, unless changed), and if you sent a VLAN tagged frame with VLAN ID 2 towards any of those ports, and assuming the switch hardware is capable of it, that VLAN ID 2 frame creates an egress VID violation and is discarded. If not discarded in hardware it would be discarded in software. I've made a detailed write up of this here: https://openwrt.org/playground/arinc9/bridge-vlan-filtering#egress_untagged_egress_tagged_and_pvid Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial
On 8.09.2022 10:54, Thibaut wrote: Hi, Le 8 sept. 2022 à 08:49, Arınç ÜNAL a écrit : On 8.09.2022 00:12, Jo-Philipp Wich wrote: [...] Anyhow, so while I agree that: Interfaces section should be called Networks. Devices section should be called Interfaces. ... it will directly contradict /etc/config/network, where networks are called `config interface` and interfaces are called `config device` likely leading to even more confusion. How about we change "config interface" to "config network" while also allowing interface or automatically converting to network for backwards compatibility, and keep "config device" intact as it's an acceptable term anyway? Sounds good. Incidentally, the config/network « interface » is referred to as « network » in config/firewall, so we already halfway there. I think changing devices to interfaces on LuCI entries is fine. If we keep « devices » (which I think is fine), I believe LuCI and uci should agree on the term. Otherwise we would still have confusion. Well, it would still be less confusing than the state we're currently in. Anyway, converting "config interface" to "config network" and "config device" to "config iface" is an option. What do you say Jo? Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial
Hi, > [...] > Meanwhile I wonder if a few specific cases wouldn't need to be better > addressed. For instance ppp or wwan create extra « Interfaces » (in current > Luci lingo), some having the related protocol - PPPoE/NCM, some having > protocol « Virtual Dynamic Interface » (for ipv4/ipv6) - which I personally > find confusing, especially as the virtual ones only show up in Luci and not > on commandline. Logical networks do not show up on the command line either (in the sense of netdevs you can query with ifconfig or ip). You can see them with "ifstatus" or "ubus list network", but the same applies to "virtual dynamic interfaces". You can see them in ubus, you can query them with "ifstatus", you should be able to "ifdown" them - so they are not more or less visible than other explicitly declared logical interfaces. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial
On 8.09.2022 00:12, Jo-Philipp Wich wrote: Hi, I wrote this mostly because the LuCI interface itself makes a distinction between the "Devices" tab and the "Interfaces" tab. But maybe this isn't the best way to describe what goes there. I agree that there are inconsistencies in LuCI. The only place I see the terminology correctly stated is on the wireless section: Network: Lists all entries on the Interfaces section. Choose the network(s) you want to attach to this wireless interface or > fill out the custom field to define a new network. Which correctly states that: Interfaces section should be called Networks. Devices section should be called Interfaces. I agree that there's inconsistencies, I eventually want to clean that up. Part of the terminology stems from uci itself, where `config interface` declares logical *networks* while *interfaces* (as in Linux netdevs) are referred to as `config device` (and `config wifi-*iface*` for wireless, which probably should be named differently too). Personally I am fine with rebranding the logical network entities (lan, wan, loopback etc.) to "networks" but I am unsure about renaming what is currently "devices" to "interfaces" as it would then intersect with the current meaning of interfaces... I believe the incorrect use of interfaces should definitely be addressed. However, the OpenWrt community should be made aware of the changes on LuCI via the mailing list and an announcement post on OpenWrt forum which refers to my Networks & Network Interfaces wiki page which, I believe, properly explains networks and interfaces. https://openwrt.org/playground/arinc9/network.interfaces We'll figure out the Wiki pages for networking with Rich so this page makes its way on the OpenWrt Wiki. Anyhow, so while I agree that: Interfaces section should be called Networks. Devices section should be called Interfaces. ... it will directly contradict /etc/config/network, where networks are called `config interface` and interfaces are called `config device` likely leading to even more confusion. How about we change "config interface" to "config network" while also allowing interface or automatically converting to network for backwards compatibility, and keep "config device" intact as it's an acceptable term anyway? I think changing devices to interfaces on LuCI entries is fine. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
> - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" > - VLAN filtering disabled Bridging virtual 802.1q interfaces might fail in some scenarios, like when you use vlan1 or mix tagged with untagged traffic (https://github.com/openwrt/openwrt/issues/9066) I do recommend bridge-vlan as the first option, although ip-bridge is not installed by default. I know that it is a little bit off topic but I would love some transitioning code that could mimic swconfig devices as if they were DSA. Instead of using swconfig settings for tagged vlans/isolated ports, just create fake lan1, lan2, wan interfaces (802.1q) and derive the swconfig settings from that. I've been doing that for some time, creating switch_vlan configs from bridge+bridge-vlan and replacing the user ports with the CPU port in every related bridge-vlan. This way I can share the config with swconfig, DSA and even devices without switches (VM like gns3) if I rename eth0, eth1, eth2 to lan1, wan, lan2. The only downsides are that untagged bridging is done using software bridge and the config is generated as a single-shot step (uci-default). However, if that mapping is done inside netifd, I believe it might be able to better handle those cases. Regards, Luiz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
On 9/7/2022 3:00 PM, Sebastian Moeller wrote: Hi Jo, I was under the impression* that bridge-vlan filtering is something that can be relegated to the switch hardware, while creating a bridge between VLAN interfaces happens in software. Is that wrong? It is incorrect. DSA offloads the bridge to the switch hardware whether you have VLAN filtering or not. When the bridge is not VLAN aware (vlan_filtering=0) what it means is that the Linux bridge, and the underlying switch MUST accept both VLAN and non-VLAN tagged frames. If you do want VLAN tagged frames in that bridge, then you are supposed to terminate VLAN traffic by creating upper VLAN devices such as lan1.10, lan2.10 etc. but the switching between lan1.10 and lan2.10 still happens in hardware because those VLAN devices are offloaded into the switch hardware. When vlan_filtering=1 is set, the hardware is configured to only accept untagged PVID frames as well as whichever VLAN tagged frames you have configured. For instance, if you configured your bridge this way with: lan1, lan2, lan3 and lan4 part of br-lan with vlan_filtering=1, each switch port will be programmed to be in the bridge's default_pvid (1, unless changed), and if you sent a VLAN tagged frame with VLAN ID 2 towards any of those ports, and assuming the switch hardware is capable of it, that VLAN ID 2 frame creates an egress VID violation and is discarded. If not discarded in hardware it would be discarded in software. Hope this helps. Regards Sebastian *) Not sure where I got that impression from On Sep 7, 2022, at 23:48, Jo-Philipp Wich wrote: Hi Rich, that tutorial is good ground work imho. One thing I repeatedly noticed (not in the document, but in forum and irc chatter) is that over the time, DSA and bridge VLAN filtering became conflated into one concept while they're actually different pieces; one can do bridge VLAN filtering without DSA and one can utilize DSA without doing bridge VLAN filtering. Bluntly speaking, DSA is the thing that gives you one Linux network device per switch port and bridge VLAN filtering is the stuff that allows you declaring swconfig-esque VLAN port groups on top of an arbitrary bridge interface. I think this is something we should try to better convey in the documentation. For example simple common use cases like: - Making each switch port it's own independent interface with own subnet or - Break out one switch port to turn it into some kind of restricted IoT or guest network access port or - Bridge each ethernet port to another SSID don't require bridge VLAN filtering or touching VLANs in general at all (in contrast to former swconfig). The per-port net devices just have to be taken out of the br-lan bridge and either be put into another bridge or configured as independent network devices. Bridge VLAN filtering on the other hand is only actually needed if you want to deal with VLAN tagged traffic inside the bridge. And even then there's sometimes alternative ways, for example the following two scenarios should be functionally equivalent: - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" - VLAN filtering disabled vs. - Bridge device "br-lan" containing "lan1 lan2 lan3" - VLAN filtering enabled - Bridge VLAN #10 containing lan1 as tagged, lan2 as tagged, lan3 as tagged - VLAN device br-lan.10 on top of br-lan In the former case you would put your IP address settings onto the dedicated "br-vlan10" bridge device while in the latter case you would configure the IP addressing on the "br-lan.10" subinterface of the "br-lan" bridge. So maybe it makes sense to focus on the "with DSA, your switch just becomes a linux bridge over a bunch of netdevs" aspect in the mini tutorial and break out any bridge-VLAN related information into a separate advanced VLAN tutorial. Another conceptual issue I see is that people came to expect a dedicated "switch" configuration ui which is something that does not really work with DSA devices anymore since there is no dedicated switch hardware entity to interact with anymore (DSA takes care of completely abstracting this away from the user point of view) and that bridge-vlans just happen to be a configuration detail of a bridge, and that there happens to be a bridge "br-lan" by default, but a system could have multiple bridges, or none at all. So we should also explain why there is no central "switch configuration" anymore and that this does not translate into a loss of functionality, but that the former semi opague swconfig switch configuration entity was dissolved into a bunch of ethernet devices inside a bridge... ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org
Re: DSA Mini-tutorial still marked as Work In Progress
On 9/7/2022 3:17 PM, David Lang wrote: with DSA, do you HAVE to go through the cpu interface and kernel to bridge different ports on the switch? or can you still do vlan routing inside the switch? DSA offloads the bridge to the switch hardware, so if the hardware switch can do its job and forward frames in hardware from port A to port B, it will do it. DSA has little significance here, the same constraints apply/applied to swconfig as well. for the Scale conference, I've done a lot of work using the switch for passing vlan tagged traffic on to other systems while only sending some of it to the CPU (the CPU would be a very significant bottleneck if I tried to send everything though it) David Lang On Wed, 7 Sep 2022, Jo-Philipp Wich wrote: Hi Rich, that tutorial is good ground work imho. One thing I repeatedly noticed (not in the document, but in forum and irc chatter) is that over the time, DSA and bridge VLAN filtering became conflated into one concept while they're actually different pieces; one can do bridge VLAN filtering without DSA and one can utilize DSA without doing bridge VLAN filtering. Bluntly speaking, DSA is the thing that gives you one Linux network device per switch port and bridge VLAN filtering is the stuff that allows you declaring swconfig-esque VLAN port groups on top of an arbitrary bridge interface. I think this is something we should try to better convey in the documentation. For example simple common use cases like: - Making each switch port it's own independent interface with own subnet or - Break out one switch port to turn it into some kind of restricted IoT or guest network access port or - Bridge each ethernet port to another SSID don't require bridge VLAN filtering or touching VLANs in general at all (in contrast to former swconfig). The per-port net devices just have to be taken out of the br-lan bridge and either be put into another bridge or configured as independent network devices. Bridge VLAN filtering on the other hand is only actually needed if you want to deal with VLAN tagged traffic inside the bridge. And even then there's sometimes alternative ways, for example the following two scenarios should be functionally equivalent: - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" - VLAN filtering disabled vs. - Bridge device "br-lan" containing "lan1 lan2 lan3" - VLAN filtering enabled - Bridge VLAN #10 containing lan1 as tagged, lan2 as tagged, lan3 as tagged - VLAN device br-lan.10 on top of br-lan In the former case you would put your IP address settings onto the dedicated "br-vlan10" bridge device while in the latter case you would configure the IP addressing on the "br-lan.10" subinterface of the "br-lan" bridge. So maybe it makes sense to focus on the "with DSA, your switch just becomes a linux bridge over a bunch of netdevs" aspect in the mini tutorial and break out any bridge-VLAN related information into a separate advanced VLAN tutorial. Another conceptual issue I see is that people came to expect a dedicated "switch" configuration ui which is something that does not really work with DSA devices anymore since there is no dedicated switch hardware entity to interact with anymore (DSA takes care of completely abstracting this away from the user point of view) and that bridge-vlans just happen to be a configuration detail of a bridge, and that there happens to be a bridge "br-lan" by default, but a system could have multiple bridges, or none at all. So we should also explain why there is no central "switch configuration" anymore and that this does not translate into a loss of functionality, but that the former semi opague swconfig switch configuration entity was dissolved into a bunch of ethernet devices inside a bridge... ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
with DSA, do you HAVE to go through the cpu interface and kernel to bridge different ports on the switch? or can you still do vlan routing inside the switch? for the Scale conference, I've done a lot of work using the switch for passing vlan tagged traffic on to other systems while only sending some of it to the CPU (the CPU would be a very significant bottleneck if I tried to send everything though it) David Lang On Wed, 7 Sep 2022, Jo-Philipp Wich wrote: Hi Rich, that tutorial is good ground work imho. One thing I repeatedly noticed (not in the document, but in forum and irc chatter) is that over the time, DSA and bridge VLAN filtering became conflated into one concept while they're actually different pieces; one can do bridge VLAN filtering without DSA and one can utilize DSA without doing bridge VLAN filtering. Bluntly speaking, DSA is the thing that gives you one Linux network device per switch port and bridge VLAN filtering is the stuff that allows you declaring swconfig-esque VLAN port groups on top of an arbitrary bridge interface. I think this is something we should try to better convey in the documentation. For example simple common use cases like: - Making each switch port it's own independent interface with own subnet or - Break out one switch port to turn it into some kind of restricted IoT or guest network access port or - Bridge each ethernet port to another SSID don't require bridge VLAN filtering or touching VLANs in general at all (in contrast to former swconfig). The per-port net devices just have to be taken out of the br-lan bridge and either be put into another bridge or configured as independent network devices. Bridge VLAN filtering on the other hand is only actually needed if you want to deal with VLAN tagged traffic inside the bridge. And even then there's sometimes alternative ways, for example the following two scenarios should be functionally equivalent: - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" - VLAN filtering disabled vs. - Bridge device "br-lan" containing "lan1 lan2 lan3" - VLAN filtering enabled - Bridge VLAN #10 containing lan1 as tagged, lan2 as tagged, lan3 as tagged - VLAN device br-lan.10 on top of br-lan In the former case you would put your IP address settings onto the dedicated "br-vlan10" bridge device while in the latter case you would configure the IP addressing on the "br-lan.10" subinterface of the "br-lan" bridge. So maybe it makes sense to focus on the "with DSA, your switch just becomes a linux bridge over a bunch of netdevs" aspect in the mini tutorial and break out any bridge-VLAN related information into a separate advanced VLAN tutorial. Another conceptual issue I see is that people came to expect a dedicated "switch" configuration ui which is something that does not really work with DSA devices anymore since there is no dedicated switch hardware entity to interact with anymore (DSA takes care of completely abstracting this away from the user point of view) and that bridge-vlans just happen to be a configuration detail of a bridge, and that there happens to be a bridge "br-lan" by default, but a system could have multiple bridges, or none at all. So we should also explain why there is no central "switch configuration" anymore and that this does not translate into a loss of functionality, but that the former semi opague swconfig switch configuration entity was dissolved into a bunch of ethernet devices inside a bridge... ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
Hi Jo, I was under the impression* that bridge-vlan filtering is something that can be relegated to the switch hardware, while creating a bridge between VLAN interfaces happens in software. Is that wrong? Regards Sebastian *) Not sure where I got that impression from > On Sep 7, 2022, at 23:48, Jo-Philipp Wich wrote: > > Hi Rich, > > that tutorial is good ground work imho. One thing I repeatedly noticed (not in > the document, but in forum and irc chatter) is that over the time, DSA and > bridge VLAN filtering became conflated into one concept while they're actually > different pieces; one can do bridge VLAN filtering without DSA and one can > utilize DSA without doing bridge VLAN filtering. > > Bluntly speaking, DSA is the thing that gives you one Linux network device per > switch port and bridge VLAN filtering is the stuff that allows you declaring > swconfig-esque VLAN port groups on top of an arbitrary bridge interface. > > I think this is something we should try to better convey in the documentation. > > For example simple common use cases like: > > - Making each switch port it's own independent interface with own subnet > > or > > - Break out one switch port to turn it into some kind of restricted IoT or > guest network access port > > or > > - Bridge each ethernet port to another SSID > > don't require bridge VLAN filtering or touching VLANs in general at all (in > contrast to former swconfig). The per-port net devices just have to be taken > out of the br-lan bridge and either be put into another bridge or configured > as independent network devices. > > Bridge VLAN filtering on the other hand is only actually needed if you want to > deal with VLAN tagged traffic inside the bridge. And even then there's > sometimes alternative ways, for example the following two scenarios should be > functionally equivalent: > > - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" > - VLAN filtering disabled > > vs. > > - Bridge device "br-lan" containing "lan1 lan2 lan3" > - VLAN filtering enabled > - Bridge VLAN #10 containing lan1 as tagged, lan2 as tagged, lan3 as tagged > - VLAN device br-lan.10 on top of br-lan > > > In the former case you would put your IP address settings onto the dedicated > "br-vlan10" bridge device while in the latter case you would configure the IP > addressing on the "br-lan.10" subinterface of the "br-lan" bridge. > > So maybe it makes sense to focus on the "with DSA, your switch just becomes a > linux bridge over a bunch of netdevs" aspect in the mini tutorial and break > out any bridge-VLAN related information into a separate advanced VLAN > tutorial. > > Another conceptual issue I see is that people came to expect a dedicated > "switch" configuration ui which is something that does not really work with > DSA devices anymore since there is no dedicated switch hardware entity to > interact with anymore (DSA takes care of completely abstracting this away from > the user point of view) and that bridge-vlans just happen to be a > configuration detail of a bridge, and that there happens to be a bridge > "br-lan" by default, but a system could have multiple bridges, or none at all. > > So we should also explain why there is no central "switch configuration" > anymore and that this does not translate into a loss of functionality, but > that the former semi opague swconfig switch configuration entity was dissolved > into a bunch of ethernet devices inside a bridge... > > > > ~ Jo > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
Hi Rich, that tutorial is good ground work imho. One thing I repeatedly noticed (not in the document, but in forum and irc chatter) is that over the time, DSA and bridge VLAN filtering became conflated into one concept while they're actually different pieces; one can do bridge VLAN filtering without DSA and one can utilize DSA without doing bridge VLAN filtering. Bluntly speaking, DSA is the thing that gives you one Linux network device per switch port and bridge VLAN filtering is the stuff that allows you declaring swconfig-esque VLAN port groups on top of an arbitrary bridge interface. I think this is something we should try to better convey in the documentation. For example simple common use cases like: - Making each switch port it's own independent interface with own subnet or - Break out one switch port to turn it into some kind of restricted IoT or guest network access port or - Bridge each ethernet port to another SSID don't require bridge VLAN filtering or touching VLANs in general at all (in contrast to former swconfig). The per-port net devices just have to be taken out of the br-lan bridge and either be put into another bridge or configured as independent network devices. Bridge VLAN filtering on the other hand is only actually needed if you want to deal with VLAN tagged traffic inside the bridge. And even then there's sometimes alternative ways, for example the following two scenarios should be functionally equivalent: - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" - VLAN filtering disabled vs. - Bridge device "br-lan" containing "lan1 lan2 lan3" - VLAN filtering enabled - Bridge VLAN #10 containing lan1 as tagged, lan2 as tagged, lan3 as tagged - VLAN device br-lan.10 on top of br-lan In the former case you would put your IP address settings onto the dedicated "br-vlan10" bridge device while in the latter case you would configure the IP addressing on the "br-lan.10" subinterface of the "br-lan" bridge. So maybe it makes sense to focus on the "with DSA, your switch just becomes a linux bridge over a bunch of netdevs" aspect in the mini tutorial and break out any bridge-VLAN related information into a separate advanced VLAN tutorial. Another conceptual issue I see is that people came to expect a dedicated "switch" configuration ui which is something that does not really work with DSA devices anymore since there is no dedicated switch hardware entity to interact with anymore (DSA takes care of completely abstracting this away from the user point of view) and that bridge-vlans just happen to be a configuration detail of a bridge, and that there happens to be a bridge "br-lan" by default, but a system could have multiple bridges, or none at all. So we should also explain why there is no central "switch configuration" anymore and that this does not translate into a loss of functionality, but that the former semi opague swconfig switch configuration entity was dissolved into a bunch of ethernet devices inside a bridge... ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial
Hi, >> I wrote this mostly because the LuCI interface itself makes a distinction >> between the "Devices" tab and the "Interfaces" tab. But maybe this isn't the >> best way to describe what goes there. > > I agree that there are inconsistencies in LuCI. The only place I see the > terminology correctly stated is on the wireless section: > > Network: Lists all entries on the Interfaces section. > >> Choose the network(s) you want to attach to this wireless interface or > > fill out the custom field to define a new network. > > Which correctly states that: > > Interfaces section should be called Networks. > Devices section should be called Interfaces. I agree that there's inconsistencies, I eventually want to clean that up. Part of the terminology stems from uci itself, where `config interface` declares logical *networks* while *interfaces* (as in Linux netdevs) are referred to as `config device` (and `config wifi-*iface*` for wireless, which probably should be named differently too). Personally I am fine with rebranding the logical network entities (lan, wan, loopback etc.) to "networks" but I am unsure about renaming what is currently "devices" to "interfaces" as it would then intersect with the current meaning of interfaces... Anyhow, so while I agree that: > Interfaces section should be called Networks. > Devices section should be called Interfaces. ... it will directly contradict /etc/config/network, where networks are called `config interface` and interfaces are called `config device` likely leading to even more confusion. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial
On 07/09/2022 21:32, Rich Brown wrote: On Sep 6, 2022, at 5:33 PM, Florian Fainelli wrote: I don't see much content to document DSA. All DSA does is creating a network interface for each switch port. What I think should be properly documented is the Bridge VLAN filtering feature. I have made some efforts to do that on my playground here: https://openwrt.org/playground/arinc9/start ... Maybe this is enough to reference since it contains basic use cases, and not so basic ones, too: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/dsa/configuration.rst -- I have the sense that the terminology surrounding DSA is very murky. But in the DSA Mini-tutorial, (https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial) I made a distinction between "Devices" and "Interfaces in the Terminology section. - Devices are things that 'send bits' without regard for IP address or subnets - Interfaces correspond to IP subnet ranges, and the routing function within the router moves packets between interfaces. I wrote this mostly because the LuCI interface itself makes a distinction between the "Devices" tab and the "Interfaces" tab. But maybe this isn't the best way to describe what goes there. I agree that there are inconsistencies in LuCI. The only place I see the terminology correctly stated is on the wireless section: Network: Lists all entries on the Interfaces section. > Choose the network(s) you want to attach to this wireless interface or > fill out the custom field to define a new network. Which correctly states that: Interfaces section should be called Networks. Devices section should be called Interfaces. Perhaps we could get the designer of the LuCI interface and other networking gurus to weigh in on how to describe this. Thanks. Rich PS I don't have a dog in this fight. If the entire Mini-tutorial were scrapped, and replaced with a description of what's true and correct, I would be happy. Thanks again Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial
> On Sep 6, 2022, at 5:33 PM, Florian Fainelli wrote: > >> I don't see much content to document DSA. All DSA does is creating a network >> interface for each switch port. What I think should be properly documented >> is the Bridge VLAN filtering feature. I have made some efforts to do that on >> my playground here: >> https://openwrt.org/playground/arinc9/start >> ... > > Maybe this is enough to reference since it contains basic use cases, and not > so basic ones, too: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/dsa/configuration.rst > -- I have the sense that the terminology surrounding DSA is very murky. But in the DSA Mini-tutorial, (https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial) I made a distinction between "Devices" and "Interfaces in the Terminology section. - Devices are things that 'send bits' without regard for IP address or subnets - Interfaces correspond to IP subnet ranges, and the routing function within the router moves packets between interfaces. I wrote this mostly because the LuCI interface itself makes a distinction between the "Devices" tab and the "Interfaces" tab. But maybe this isn't the best way to describe what goes there. Perhaps we could get the designer of the LuCI interface and other networking gurus to weigh in on how to describe this. Thanks. Rich PS I don't have a dog in this fight. If the entire Mini-tutorial were scrapped, and replaced with a description of what's true and correct, I would be happy. Thanks again ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
On 07/09/2022 00:33, Florian Fainelli wrote: On 9/4/2022 2:32 PM, Arınç ÜNAL wrote: Hi Rich, On 4.09.2022 17:58, Rich Brown wrote: Folks, The DSA Mini-tutorial on the Wiki (https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial) is still marked as a "Work In Progress" I should know - I wrote this up as we were getting ready to ship 21.02, and I thought that we should have something about DSA on the wiki. But I don't really know anything about DSA - I simply pieced the article together from a few forum posts. And I never received any direct feedback or saw any updates to the wiki page. I was "makin' a lot of stuff up" as I wrote that page. It's the best I could do, but nothing that's written there should be taken as gospel. The italics near the top indicate areas of uncertainty. I also was guessing about the difference between device and interface definitions. Here's my request: It would do my heart good to have someone who's knowledgeable about DSA read through the page and either make direct corrections, or send me a note and I'll make them. Thanks. I don't see much content to document DSA. All DSA does is creating a network interface for each switch port. What I think should be properly documented is the Bridge VLAN filtering feature. I have made some efforts to do that on my playground here: https://openwrt.org/playground/arinc9/start I know I was supposed to deliver much more, much earlier. I still have a huge list of things to do on LuCI, UCI and OpenWrt Wiki, forcefully pushed down to the bottom of my task list. Maybe this is enough to reference since it contains basic use cases, and not so basic ones, too: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/dsa/configuration.rst This is great. Though, I'd rather link it from somewhere that can make use of the reStructuredText file, like GitHub. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
On 9/4/2022 2:32 PM, Arınç ÜNAL wrote: Hi Rich, On 4.09.2022 17:58, Rich Brown wrote: Folks, The DSA Mini-tutorial on the Wiki (https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial) is still marked as a "Work In Progress" I should know - I wrote this up as we were getting ready to ship 21.02, and I thought that we should have something about DSA on the wiki. But I don't really know anything about DSA - I simply pieced the article together from a few forum posts. And I never received any direct feedback or saw any updates to the wiki page. I was "makin' a lot of stuff up" as I wrote that page. It's the best I could do, but nothing that's written there should be taken as gospel. The italics near the top indicate areas of uncertainty. I also was guessing about the difference between device and interface definitions. Here's my request: It would do my heart good to have someone who's knowledgeable about DSA read through the page and either make direct corrections, or send me a note and I'll make them. Thanks. I don't see much content to document DSA. All DSA does is creating a network interface for each switch port. What I think should be properly documented is the Bridge VLAN filtering feature. I have made some efforts to do that on my playground here: https://openwrt.org/playground/arinc9/start I know I was supposed to deliver much more, much earlier. I still have a huge list of things to do on LuCI, UCI and OpenWrt Wiki, forcefully pushed down to the bottom of my task list. Maybe this is enough to reference since it contains basic use cases, and not so basic ones, too: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/dsa/configuration.rst -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial
On 05/09/2022 15:22, Rich Brown wrote: Hello Arınç (and the rest of the list), It's good to hear from you again. On Sep 4, 2022, at 5:32 PM, Arınç ÜNAL wrote: I don't see much content to document DSA. All DSA does is creating a network interface for each switch port. What I think should be properly documented is the Bridge VLAN filtering feature. I have made some efforts to do that on my playground here: https://openwrt.org/playground/arinc9/start I had not looked at your pages recently but we should make sure all the information makes it out of the playground into the main wiki. I see that we have slightly different definitions for "interface" and "device" in DSA. Here are the versions: DSA Mini-Tutorial - Terminology: https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial#terminology Playground - Definition of a Network Interface https://openwrt.org/playground/arinc9/network.interfaces#definition_of_a_network_interface Because I don't really know about DSA, I don't know how important it is to call an Ethernet switch port a "device" or whether it's OK simply to call it an "Ethernet interface". I think the term "device" comes from the Linux kernel development. https://www.kernel.org/doc/html/latest/networking/netdevices.html Both terms represent the same thing so it's not a big deal. I'd rather call it network interface as it's an established term for computer networking. It's not the ethernet switch port that I'm calling an interface but rather, the network interface that DSA creates by utilizing hardware which is that ethernet switch port. I think I explain this well on the Network & Network Interfaces page: > Network interfaces can be created by making use of physical devices (a switch, a NIC, a wireless NIC) and/or features of the software (vlan, bridging, tunnelling). How could we start to merge all these documents? Thanks. I've been planning to do this for a long time. We can just put these two pages, Bridge VLAN Filtering and Network & Network Interfaces, under a unified Computer Networking section on the wiki. My two pages are mostly ready for everyone to see. The "Networking" section looks like a good place to put DSA Networking and my pages on. I believe the Linux Network Interfaces and DSA Mini-Tutorial pages include great amount of misinformation. Those can be dealt with later. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
re: DSA Mini-tutorial
Hello Arınç (and the rest of the list), It's good to hear from you again. > On Sep 4, 2022, at 5:32 PM, Arınç ÜNAL wrote: > > I don't see much content to document DSA. All DSA does is creating a network > interface for each switch port. What I think should > be properly documented is the Bridge VLAN filtering feature. I have made some > efforts to do that on my playground here: > > https://openwrt.org/playground/arinc9/start I had not looked at your pages recently but we should make sure all the information makes it out of the playground into the main wiki. I see that we have slightly different definitions for "interface" and "device" in DSA. Here are the versions: DSA Mini-Tutorial - Terminology: https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial#terminology Playground - Definition of a Network Interface https://openwrt.org/playground/arinc9/network.interfaces#definition_of_a_network_interface Because I don't really know about DSA, I don't know how important it is to call an Ethernet switch port a "device" or whether it's OK simply to call it an "Ethernet interface". How could we start to merge all these documents? Thanks. Rich PS Thoughts from other readers would be welcome! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
Hi Rich, On 4.09.2022 17:58, Rich Brown wrote: Folks, The DSA Mini-tutorial on the Wiki (https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial) is still marked as a "Work In Progress" I should know - I wrote this up as we were getting ready to ship 21.02, and I thought that we should have something about DSA on the wiki. But I don't really know anything about DSA - I simply pieced the article together from a few forum posts. And I never received any direct feedback or saw any updates to the wiki page. I was "makin' a lot of stuff up" as I wrote that page. It's the best I could do, but nothing that's written there should be taken as gospel. The italics near the top indicate areas of uncertainty. I also was guessing about the difference between device and interface definitions. Here's my request: It would do my heart good to have someone who's knowledgeable about DSA read through the page and either make direct corrections, or send me a note and I'll make them. Thanks. I don't see much content to document DSA. All DSA does is creating a network interface for each switch port. What I think should be properly documented is the Bridge VLAN filtering feature. I have made some efforts to do that on my playground here: https://openwrt.org/playground/arinc9/start I know I was supposed to deliver much more, much earlier. I still have a huge list of things to do on LuCI, UCI and OpenWrt Wiki, forcefully pushed down to the bottom of my task list. Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel