On 2022-08-11 13:28, Ido Schimmel wrote:
I'm talking about roaming, not forwarding. Let's say you have a locked entry with MAC X pointing to port Y. Now you get a packet with SMAC X from port Z which is unlocked. Will the FDB entry roam to port Z? I think it should, but at least in current implementation it seems that the "locked" flag will not be reset and having locked entries pointing to an unlocked port looks like a bug.
In general I have been thinking that the said setup is a network configuration error as I was arguing in an earlier conversation with Vladimir. In this setup we must remember that SMAC X becomes DMAC X in the return traffic on the open port. But the question arises to me why MAC X would be behind the locked port without getting authed while being behind an open port too? In a real life setup, I don't think you would want random hosts behind a locked port in the MAB case, but only the hosts you will let through. Other hosts should be regarded as intruders.
If we are talking about a station move, then the locked entry will age out and MAC X will function normally on the open port after the timeout, which was a case that was taken up in earlier discussions.
But I will anyhow do some testing with this 'edge case' (of being behind both a locked and an unlocked port) if I may call it so, and see to that the offloaded and non-offloaded cases correspond to each other, and will work satisfactory.
I think it will be good to have a flag to enable the mac-auth/MAB feature, and I suggest just calling the flag 'mab', as it is short.
Otherwise I don't see any major issues with the whole feature as it is.
On Fri, Aug 12, 2022 at 02:29:48PM +0200, netdev@kapio-technology.com wrote:
On 2022-08-11 13:28, Ido Schimmel wrote:
I'm talking about roaming, not forwarding. Let's say you have a locked entry with MAC X pointing to port Y. Now you get a packet with SMAC X from port Z which is unlocked. Will the FDB entry roam to port Z? I think it should, but at least in current implementation it seems that the "locked" flag will not be reset and having locked entries pointing to an unlocked port looks like a bug.
In general I have been thinking that the said setup is a network configuration error as I was arguing in an earlier conversation with Vladimir. In this setup we must remember that SMAC X becomes DMAC X in the return traffic on the open port. But the question arises to me why MAC X would be behind the locked port without getting authed while being behind an open port too? In a real life setup, I don't think you would want random hosts behind a locked port in the MAB case, but only the hosts you will let through. Other hosts should be regarded as intruders.
If we are talking about a station move, then the locked entry will age out and MAC X will function normally on the open port after the timeout, which was a case that was taken up in earlier discussions.
But I will anyhow do some testing with this 'edge case' (of being behind both a locked and an unlocked port) if I may call it so, and see to that the offloaded and non-offloaded cases correspond to each other, and will work satisfactory.
It would be best to implement these as additional test cases in the current selftest. Then you can easily test with both veth pairs and loopbacks and see that the hardware and software data paths behave the same.
I think it will be good to have a flag to enable the mac-auth/MAB feature, and I suggest just calling the flag 'mab', as it is short.
Fine by me, but I'm not sure everyone agrees.
Otherwise I don't see any major issues with the whole feature as it is.
Will review and test the next version.
Thanks
On 2022-08-14 16:55, Ido Schimmel wrote:
On Fri, Aug 12, 2022 at 02:29:48PM +0200, netdev@kapio-technology.com wrote:
On 2022-08-11 13:28, Ido Schimmel wrote:
I'm talking about roaming, not forwarding. Let's say you have a locked entry with MAC X pointing to port Y. Now you get a packet with SMAC X from port Z which is unlocked. Will the FDB entry roam to port Z? I think it should, but at least in current implementation it seems that the "locked" flag will not be reset and having locked entries pointing to an unlocked port looks like a bug.
I have made the locked entries sticky in the bridge, so that they don't move to other ports.
In general I have been thinking that the said setup is a network configuration error as I was arguing in an earlier conversation with Vladimir. In this setup we must remember that SMAC X becomes DMAC X in the return traffic on the open port. But the question arises to me why MAC X would be behind the locked port without getting authed while being behind an open port too? In a real life setup, I don't think you would want random hosts behind a locked port in the MAB case, but only the hosts you will let through. Other hosts should be regarded as intruders.
If we are talking about a station move, then the locked entry will age out and MAC X will function normally on the open port after the timeout, which was a case that was taken up in earlier discussions.
But I will anyhow do some testing with this 'edge case' (of being behind both a locked and an unlocked port) if I may call it so, and see to that the offloaded and non-offloaded cases correspond to each other, and will work satisfactory.
It would be best to implement these as additional test cases in the current selftest. Then you can easily test with both veth pairs and loopbacks and see that the hardware and software data paths behave the same.
How many loops would be needed to have a selftest with a HUB and a MAC on both a locked and an unlocked port?
I think it will be good to have a flag to enable the mac-auth/MAB feature, and I suggest just calling the flag 'mab', as it is short.
I have now created the flag to enable Mac-Auth/MAB with iproute2: bridge link set dev DEV macauth on|off
with the example output from 'bridge -d link show dev DEV' when macauth is enabled: 1: ethX: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 19 hairpin off guard off root_block off fastleave off learning on flood off mcast_flood on bcast_flood on mcast_router 1 mcast_to_unicast off neigh_suppress off vlan_tunnel off isolated off locked mab on
The flag itself in the code is called BR_PORT_MACAUTH.
Fine by me, but I'm not sure everyone agrees.
On Fri, Aug 19, 2022 at 11:51:11AM +0200, netdev@kapio-technology.com wrote:
On 2022-08-14 16:55, Ido Schimmel wrote:
On Fri, Aug 12, 2022 at 02:29:48PM +0200, netdev@kapio-technology.com wrote:
On 2022-08-11 13:28, Ido Schimmel wrote:
I'm talking about roaming, not forwarding. Let's say you have a locked entry with MAC X pointing to port Y. Now you get a packet with SMAC X from port Z which is unlocked. Will the FDB entry roam to port Z? I think it should, but at least in current implementation it seems that the "locked" flag will not be reset and having locked entries pointing to an unlocked port looks like a bug.
I have made the locked entries sticky in the bridge, so that they don't move to other ports.
Please make sure that this design choice is explained in the commit message. To be clear, it cannot be "this is how device X happens to work".
In general I have been thinking that the said setup is a network configuration error as I was arguing in an earlier conversation with Vladimir. In this setup we must remember that SMAC X becomes DMAC X in the return traffic on the open port. But the question arises to me why MAC X would be behind the locked port without getting authed while being behind an open port too? In a real life setup, I don't think you would want random hosts behind a locked port in the MAB case, but only the hosts you will let through. Other hosts should be regarded as intruders.
If we are talking about a station move, then the locked entry will age out and MAC X will function normally on the open port after the timeout, which was a case that was taken up in earlier discussions.
But I will anyhow do some testing with this 'edge case' (of being behind both a locked and an unlocked port) if I may call it so, and see to that the offloaded and non-offloaded cases correspond to each other, and will work satisfactory.
It would be best to implement these as additional test cases in the current selftest. Then you can easily test with both veth pairs and loopbacks and see that the hardware and software data paths behave the same.
How many loops would be needed to have a selftest with a HUB and a MAC on both a locked and an unlocked port?
I assume you want a hub to simulate multiple MACs behind the same port. You don't need a hub for that. You can set the MAC using mausezahn. See '-a' option:
" -a <src-mac|keyword> Use specified source MAC address with hexadecimal notation such as 00:00:aa:bb:cc:dd. By default the interface MAC address will be used. The keywords ''rand'' and ''own'' refer to a random MAC address (only unicast addresses are created) and the own address, respectively. You can also use the keywords mentioned below although broadcast-type source addresses are officially invalid. "
I think it will be good to have a flag to enable the mac-auth/MAB feature, and I suggest just calling the flag 'mab', as it is short.
I have now created the flag to enable Mac-Auth/MAB with iproute2: bridge link set dev DEV macauth on|off
You have 'macauth' here, but 'mab' in the output below. They need to match. I prefer the latter unless you have a good reason to use 'macauth'.
with the example output from 'bridge -d link show dev DEV' when macauth is enabled: 1: ethX: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 19 hairpin off guard off root_block off fastleave off learning on flood off mcast_flood on bcast_flood on mcast_router 1 mcast_to_unicast off neigh_suppress off vlan_tunnel off isolated off locked mab on
The flag itself in the code is called BR_PORT_MACAUTH.
Fine by me, but I'm not sure everyone agrees.
On 2022-08-21 09:08, Ido Schimmel wrote:
On Fri, Aug 19, 2022 at 11:51:11AM +0200, netdev@kapio-technology.com wrote:
On 2022-08-14 16:55, Ido Schimmel wrote:
On Fri, Aug 12, 2022 at 02:29:48PM +0200, netdev@kapio-technology.com wrote:
On 2022-08-11 13:28, Ido Schimmel wrote:
> I'm talking about roaming, not forwarding. Let's say you have a locked > entry with MAC X pointing to port Y. Now you get a packet with SMAC X > from port Z which is unlocked. Will the FDB entry roam to port Z? I > think it should, but at least in current implementation it seems that > the "locked" flag will not be reset and having locked entries pointing > to an unlocked port looks like a bug.
I have made the locked entries sticky in the bridge, so that they don't move to other ports.
Please make sure that this design choice is explained in the commit message. To be clear, it cannot be "this is how device X happens to work".
The real issue I think is that the locked entry should mask the MAC address involved (as the description I gave for zero-DPV entries and actually also storm prevention entries ensure), so that there is no forwarding to the address on any port, otherwise it will allow one-way traffic to a host that is not trusted. Thus flooding of unknown unicast on a locked port should of course be disabled ('flood off'), so that there is no way of sending to an unauthorized silent host behind the locked port.
The issue with the locked entry appearing on another SW bridge port from where it originated, I think is more of a cosmetic bug, though I could be mistaken. But adding the sticky flag to locked entries ensures that they do not move to another port.
This of course does that instant roaming is not possible, but I think that the right approach is to use the ageing out of entries to allow the station move/roaming.
The case of unwanted traffic to a MAC behind a locked port with a locked entry is what I would regard as more worthy of a selftest. The sticky flag I know will ensure that the locked entries do not move to other ports, and since it is only in the bridge this can be tested (e.g. using 'bridge fdb show dev DEV'), I think that the test would be superfluos. What do you think of that and my other consideration for a test?
I have now created the flag to enable Mac-Auth/MAB with iproute2: bridge link set dev DEV macauth on|off
You have 'macauth' here, but 'mab' in the output below. They need to match. I prefer the latter unless you have a good reason to use 'macauth'.
with the example output from 'bridge -d link show dev DEV' when macauth is enabled: 1: ethX: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 19 hairpin off guard off root_block off fastleave off learning on flood off mcast_flood on bcast_flood on mcast_router 1 mcast_to_unicast off neigh_suppress off vlan_tunnel off isolated off locked mab on
The flag itself in the code is called BR_PORT_MACAUTH.
Fine by me, but I'm not sure everyone agrees.
I will change it in iproute2 to: bridge link set dev DEV mab on|off
On Sun, Aug 21, 2022 at 03:43:04PM +0200, netdev@kapio-technology.com wrote:
On 2022-08-21 09:08, Ido Schimmel wrote:
On Fri, Aug 19, 2022 at 11:51:11AM +0200, netdev@kapio-technology.com wrote:
On 2022-08-14 16:55, Ido Schimmel wrote:
On Fri, Aug 12, 2022 at 02:29:48PM +0200, netdev@kapio-technology.com wrote:
On 2022-08-11 13:28, Ido Schimmel wrote:
> > I'm talking about roaming, not forwarding. Let's say you have a locked > > entry with MAC X pointing to port Y. Now you get a packet with SMAC X > > from port Z which is unlocked. Will the FDB entry roam to port Z? I > > think it should, but at least in current implementation it seems that > > the "locked" flag will not be reset and having locked entries pointing > > to an unlocked port looks like a bug.
I have made the locked entries sticky in the bridge, so that they don't move to other ports.
Please make sure that this design choice is explained in the commit message. To be clear, it cannot be "this is how device X happens to work".
The real issue I think is that the locked entry should mask the MAC address involved (as the description I gave for zero-DPV entries and actually also storm prevention entries ensure), so that there is no forwarding to the address on any port, otherwise it will allow one-way traffic to a host that is not trusted. Thus flooding of unknown unicast on a locked port should of course be disabled ('flood off'), so that there is no way of sending to an unauthorized silent host behind the locked port.
The issue with the locked entry appearing on another SW bridge port from where it originated, I think is more of a cosmetic bug, though I could be mistaken. But adding the sticky flag to locked entries ensures that they do not move to another port.
This of course does that instant roaming is not possible, but I think that the right approach is to use the ageing out of entries to allow the station move/roaming.
I personally think that the mv88e6xxx semantics are very weird (e.g., no roaming, traffic blackhole) and I don't want them to determine how the feature works in the pure software bridge or other hardware implementations. On the other hand, I understand your constraints and I don't want to create a situation where user space is unable to understand how the data path works from the bridge FDB dump with mv88e6xxx.
My suggestion is to have mv88e6xxx report the "locked" entry to the bridge driver with additional flags that describe its behavior in terms of roaming, ageing and forwarding.
In terms of roaming, since in mv88e6xxx the entry can't roam you should report the entry with the "sticky" flag. In terms of ageing, since mv88e6xxx is the one doing the ageing and not the bridge driver, report the entry with the "extern_learn" flag. In terms of forwarding, in mv88e6xxx the entry discards all matching packets. We can introduce a new FDB flag that instructs the entry to silently discard all matching packets. Like we have with blackhole routes and nexthops.
I believe that the above suggestion allows you to fully describe how these entries work in mv88e6xxx while keeping the bridge driver in sync with complete visibility towards user space.
It also frees the pure software implementation from the constraints of mv88e6xxx, allowing "locked" entries to behave like any other dynamically learned entries modulo the fact that they cannot "unlock" a locked port.
Yes, it does mean that user space will get a bit different behavior with mv88e6xxx compared to a pure software solution, but a) It's only the corner cases that act a bit differently. As a whole, the feature works largely the same. b) User space has complete visibility to understand the behavior of the offloaded data path.
The case of unwanted traffic to a MAC behind a locked port with a locked entry is what I would regard as more worthy of a selftest. The sticky flag I know will ensure that the locked entries do not move to other ports, and since it is only in the bridge this can be tested (e.g. using 'bridge fdb show dev DEV'), I think that the test would be superfluos. What do you think of that and my other consideration for a test?
If we go with the above suggestion, then you can have a mv88e6xxx-specific selftest that tests the corner cases where mv88e6xxx acts a bit differently from the pure software bridge.
I have now created the flag to enable Mac-Auth/MAB with iproute2: bridge link set dev DEV macauth on|off
You have 'macauth' here, but 'mab' in the output below. They need to match. I prefer the latter unless you have a good reason to use 'macauth'.
with the example output from 'bridge -d link show dev DEV' when macauth is enabled: 1: ethX: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 19 hairpin off guard off root_block off fastleave off learning on flood off mcast_flood on bcast_flood on mcast_router 1 mcast_to_unicast off neigh_suppress off vlan_tunnel off isolated off locked mab on
The flag itself in the code is called BR_PORT_MACAUTH.
Fine by me, but I'm not sure everyone agrees.
I will change it in iproute2 to: bridge link set dev DEV mab on|off
And s/BR_PORT_MACAUTH/BR_PORT_MAB/ ?
On 2022-08-22 07:40, Ido Schimmel wrote:
On Sun, Aug 21, 2022 at 03:43:04PM +0200, netdev@kapio-technology.com wrote:
I personally think that the mv88e6xxx semantics are very weird (e.g., no roaming, traffic blackhole) and I don't want them to determine how the feature works in the pure software bridge or other hardware implementations. On the other hand, I understand your constraints and I don't want to create a situation where user space is unable to understand how the data path works from the bridge FDB dump with mv88e6xxx.
My suggestion is to have mv88e6xxx report the "locked" entry to the bridge driver with additional flags that describe its behavior in terms of roaming, ageing and forwarding.
In terms of roaming, since in mv88e6xxx the entry can't roam you should report the entry with the "sticky" flag.
As I am not familiar with roaming in this context, I need to know how the SW bridge should behave in this case. In this I am assuming that roaming is regarding unauthorized entries. In this case, is the roaming only between locked ports or does the roaming include that the entry can move to a unlocked port, resulting in the locked flag getting removed?
In terms of ageing, since mv88e6xxx is the one doing the ageing and not the bridge driver, report the entry with the "extern_learn" flag.
Just for the record, I see that entries coming from the driver to the bridge will always have the "extern learn" flag set as can be seen from the SWITCHDEV_FDB_ADD_TO_BRIDGE events handling in br_switchdev_event() in br.c, which I think is the correct behavior.
In terms of forwarding, in mv88e6xxx the entry discards all matching packets. We can introduce a new FDB flag that instructs the entry to silently discard all matching packets. Like we have with blackhole routes and nexthops.
Any suggestions to the name of this flag?
I believe that the above suggestion allows you to fully describe how these entries work in mv88e6xxx while keeping the bridge driver in sync with complete visibility towards user space.
It also frees the pure software implementation from the constraints of mv88e6xxx, allowing "locked" entries to behave like any other dynamically learned entries modulo the fact that they cannot "unlock" a locked port.
Yes, it does mean that user space will get a bit different behavior with mv88e6xxx compared to a pure software solution, but a) It's only the corner cases that act a bit differently. As a whole, the feature works largely the same. b) User space has complete visibility to understand the behavior of the offloaded data path.
I will change it in iproute2 to: bridge link set dev DEV mab on|off
And s/BR_PORT_MACAUTH/BR_PORT_MAB/ ?
Sure, I will do that. :-)
On Mon, Aug 22, 2022 at 09:49:28AM +0200, netdev@kapio-technology.com wrote:
On 2022-08-22 07:40, Ido Schimmel wrote:
On Sun, Aug 21, 2022 at 03:43:04PM +0200, netdev@kapio-technology.com wrote:
I personally think that the mv88e6xxx semantics are very weird (e.g., no roaming, traffic blackhole) and I don't want them to determine how the feature works in the pure software bridge or other hardware implementations. On the other hand, I understand your constraints and I don't want to create a situation where user space is unable to understand how the data path works from the bridge FDB dump with mv88e6xxx.
My suggestion is to have mv88e6xxx report the "locked" entry to the bridge driver with additional flags that describe its behavior in terms of roaming, ageing and forwarding.
In terms of roaming, since in mv88e6xxx the entry can't roam you should report the entry with the "sticky" flag.
As I am not familiar with roaming in this context, I need to know how the SW bridge should behave in this case.
I think I wasn't clear enough. The idea is to make the bridge compatible with mv88e6xxx in a way that is discoverable by user space by having mv88e6xxx add the locked entry with flags that describe the hardware behavior. Therefore, it's not a matter of "how the SW bridge should behave", but having it behave in a way that matches the offloaded data path.
From what I was able to understand from you, the "locked" entry cannot roam at all in mv88e6xxx, which can be described by the "sticky" flag.
In this I am assuming that roaming is regarding unauthorized entries.
Yes, talking about "locked" entries that are notified by mv88e6xxx to the bridge.
In this case, is the roaming only between locked ports or does the roaming include that the entry can move to a unlocked port, resulting in the locked flag getting removed?
Any two ports. If the "locked" entry in mv88e6xxx cannot move once installed, then the "sticky" flag accurately describes it.
In terms of ageing, since mv88e6xxx is the one doing the ageing and not the bridge driver, report the entry with the "extern_learn" flag.
Just for the record, I see that entries coming from the driver to the bridge will always have the "extern learn" flag set as can be seen from the SWITCHDEV_FDB_ADD_TO_BRIDGE events handling in br_switchdev_event() in br.c, which I think is the correct behavior.
Yes.
In terms of forwarding, in mv88e6xxx the entry discards all matching packets. We can introduce a new FDB flag that instructs the entry to silently discard all matching packets. Like we have with blackhole routes and nexthops.
Any suggestions to the name of this flag?
I'm not good at naming, but "blackhole" is at least consistent with what we already have for routes and nexthop objects.
I believe that the above suggestion allows you to fully describe how these entries work in mv88e6xxx while keeping the bridge driver in sync with complete visibility towards user space.
It also frees the pure software implementation from the constraints of mv88e6xxx, allowing "locked" entries to behave like any other dynamically learned entries modulo the fact that they cannot "unlock" a locked port.
Yes, it does mean that user space will get a bit different behavior with mv88e6xxx compared to a pure software solution, but a) It's only the corner cases that act a bit differently. As a whole, the feature works largely the same. b) User space has complete visibility to understand the behavior of the offloaded data path.
I will change it in iproute2 to: bridge link set dev DEV mab on|off
And s/BR_PORT_MACAUTH/BR_PORT_MAB/ ?
Sure, I will do that. :-)
Thanks
On 2022-08-23 08:48, Ido Schimmel wrote:
On Mon, Aug 22, 2022 at 09:49:28AM +0200, netdev@kapio-technology.com wrote:
As I am not familiar with roaming in this context, I need to know how the SW bridge should behave in this case.
In this case, is the roaming only between locked ports or does the roaming include that the entry can move to a unlocked port, resulting in the locked flag getting removed?
Any two ports. If the "locked" entry in mv88e6xxx cannot move once installed, then the "sticky" flag accurately describes it.
But since I am also doing the SW bridge implementation without mv88e6xxx I need it to function according to needs. Thus the locked entries created in the bridge I shall not put the sticky flag on, but there will be the situation where a locked entry can move to an unlocked port, which we regarded as a bug. In that case there is two possibilities, the locked entry can move to an unlocked port with the locked flag being removed or the locked entry can only move to another locked port?
On Tue, Aug 23, 2022 at 09:13:54AM +0200, netdev@kapio-technology.com wrote:
On 2022-08-23 08:48, Ido Schimmel wrote:
On Mon, Aug 22, 2022 at 09:49:28AM +0200, netdev@kapio-technology.com wrote:
As I am not familiar with roaming in this context, I need to know how the SW bridge should behave in this case.
In this case, is the roaming only between locked ports or does the roaming include that the entry can move to a unlocked port, resulting in the locked flag getting removed?
Any two ports. If the "locked" entry in mv88e6xxx cannot move once installed, then the "sticky" flag accurately describes it.
But since I am also doing the SW bridge implementation without mv88e6xxx I need it to function according to needs. Thus the locked entries created in the bridge I shall not put the sticky flag on, but there will be the situation where a locked entry can move to an unlocked port, which we regarded as a bug.
I do not regard this as a bug. It makes sense to me that an authorized port can cause an entry pointing to an unauthorized port to roam to itself. Just like normal learned entries. What I considered as a bug is the fact that the "locked" flag is not cleared when roaming to an authorized port.
In that case there is two possibilities, the locked entry can move to an unlocked port with the locked flag being removed or the locked entry can only move to another locked port?
My suggestion is to allow roaming and maintain / clear the "locked" flag based on whether the new destination port is locked or not.
On 2022-08-23 09:24, Ido Schimmel wrote:
On Tue, Aug 23, 2022 at 09:13:54AM +0200, netdev@kapio-technology.com wrote:
On 2022-08-23 08:48, Ido Schimmel wrote:
On Mon, Aug 22, 2022 at 09:49:28AM +0200, netdev@kapio-technology.com wrote:
As I am not familiar with roaming in this context, I need to know how the SW bridge should behave in this case.
In this case, is the roaming only between locked ports or does the roaming include that the entry can move to a unlocked port, resulting in the locked flag getting removed?
Any two ports. If the "locked" entry in mv88e6xxx cannot move once installed, then the "sticky" flag accurately describes it.
But since I am also doing the SW bridge implementation without mv88e6xxx I need it to function according to needs. Thus the locked entries created in the bridge I shall not put the sticky flag on, but there will be the situation where a locked entry can move to an unlocked port, which we regarded as a bug.
I do not regard this as a bug. It makes sense to me that an authorized port can cause an entry pointing to an unauthorized port to roam to itself. Just like normal learned entries. What I considered as a bug is the fact that the "locked" flag is not cleared when roaming to an authorized port.
In that case there is two possibilities, the locked entry can move to an unlocked port with the locked flag being removed or the locked entry can only move to another locked port?
My suggestion is to allow roaming and maintain / clear the "locked" flag based on whether the new destination port is locked or not.
Thus I understand it as saying that the "locked" flag can also be set when roaming from an unlocked port to a locked port?
On Tue, Aug 23, 2022 at 09:37:54AM +0200, netdev@kapio-technology.com wrote:
On 2022-08-23 09:24, Ido Schimmel wrote:
On Tue, Aug 23, 2022 at 09:13:54AM +0200, netdev@kapio-technology.com wrote:
On 2022-08-23 08:48, Ido Schimmel wrote:
On Mon, Aug 22, 2022 at 09:49:28AM +0200, netdev@kapio-technology.com wrote:
As I am not familiar with roaming in this context, I need to know how the SW bridge should behave in this case.
In this case, is the roaming only between locked ports or does the roaming include that the entry can move to a unlocked port, resulting in the locked flag getting removed?
Any two ports. If the "locked" entry in mv88e6xxx cannot move once installed, then the "sticky" flag accurately describes it.
But since I am also doing the SW bridge implementation without mv88e6xxx I need it to function according to needs. Thus the locked entries created in the bridge I shall not put the sticky flag on, but there will be the situation where a locked entry can move to an unlocked port, which we regarded as a bug.
I do not regard this as a bug. It makes sense to me that an authorized port can cause an entry pointing to an unauthorized port to roam to itself. Just like normal learned entries. What I considered as a bug is the fact that the "locked" flag is not cleared when roaming to an authorized port.
In that case there is two possibilities, the locked entry can move to an unlocked port with the locked flag being removed or the locked entry can only move to another locked port?
My suggestion is to allow roaming and maintain / clear the "locked" flag based on whether the new destination port is locked or not.
Thus I understand it as saying that the "locked" flag can also be set when roaming from an unlocked port to a locked port?
"learning on locked on" is really a misconfiguration, but it can also happen today and entries do not roam with the "locked" flag for the simple reason that it does not exist. I see two options:
1. Do not clear / set "locked" flag during roaming. Given learning should be disabled on locked ports, then the only half interesting case is roaming to an unlocked port. Keeping the "locked" flag basically means "if you were to lock the port, then the presence of this entry is not enough to let traffic with the SA be forwarded by the bridge". Unlikely that anyone will do that.
2. Always set "locked" flag for learned entries (new & roamed) on locked ports and clear it for learned entries on unlocked ports.
Both options are consistent in how they treat the "locked" flag (either always do nothing or always set/clear) and both do not impact the integrity of the solution when configured correctly (disabling learning on locked ports). I guess users will find option 2 easier to understand / work with.
On 2022-08-23 14:36, Ido Schimmel wrote:
On Tue, Aug 23, 2022 at 09:37:54AM +0200, netdev@kapio-technology.com wrote:
"learning on locked on" is really a misconfiguration, but it can also happen today and entries do not roam with the "locked" flag for the simple reason that it does not exist. I see two options:
- Do not clear / set "locked" flag during roaming. Given learning
should be disabled on locked ports, then the only half interesting case is roaming to an unlocked port. Keeping the "locked" flag basically means "if you were to lock the port, then the presence of this entry is not enough to let traffic with the SA be forwarded by the bridge". Unlikely that anyone will do that.
- Always set "locked" flag for learned entries (new & roamed) on
locked ports and clear it for learned entries on unlocked ports.
Both options are consistent in how they treat the "locked" flag (either always do nothing or always set/clear) and both do not impact the integrity of the solution when configured correctly (disabling learning on locked ports). I guess users will find option 2 easier to understand / work with.
Roaming to a locked port with an entry without the locked bit set would open the port for said MAC without necessary authorization. Thus I think that the only real option is the 2. case.
On 2022-08-23 08:48, Ido Schimmel wrote:
I'm not good at naming, but "blackhole" is at least consistent with what we already have for routes and nexthop objects.
I have changed it the name "masked", as that is also the term used in the documentation for the zero-DPV entries, and I think that it will generally be a more accepted term. Thus the name of the flag is now "BR_FDB_ENTRY_MASKED".
I hope that is fine with you?
On Tue, Aug 23, 2022 at 01:41:51PM +0200, netdev@kapio-technology.com wrote:
On 2022-08-23 08:48, Ido Schimmel wrote:
I'm not good at naming, but "blackhole" is at least consistent with what we already have for routes and nexthop objects.
I have changed it the name "masked", as that is also the term used in the documentation for the zero-DPV entries, and I think that it will generally be a more accepted term.
"blackhole" is an already accepted term and at least to me it is much more clear than "masked". Keep in mind that both L2 neighbours (FDB) and L3 neighbours share the same uAPI and eventually we might want to extend the use of this flag for L3 neighbours (at least Spectrum supports it), so it needs to make sense for both.
On 2022-08-25 11:36, Ido Schimmel wrote:
On Tue, Aug 23, 2022 at 01:41:51PM +0200, netdev@kapio-technology.com wrote:
On 2022-08-23 08:48, Ido Schimmel wrote:
I'm not good at naming, but "blackhole" is at least consistent with what we already have for routes and nexthop objects.
I have changed it the name "masked", as that is also the term used in the documentation for the zero-DPV entries, and I think that it will generally be a more accepted term.
"blackhole" is an already accepted term and at least to me it is much more clear than "masked". Keep in mind that both L2 neighbours (FDB) and L3 neighbours share the same uAPI and eventually we might want to extend the use of this flag for L3 neighbours (at least Spectrum supports it), so it needs to make sense for both.
Okay, I will do that then...
On 2022-08-25 11:36, Ido Schimmel wrote:
On Tue, Aug 23, 2022 at 01:41:51PM +0200, netdev@kapio-technology.com wrote:
On 2022-08-23 08:48, Ido Schimmel wrote:
I'm not good at naming, but "blackhole" is at least consistent with what we already have for routes and nexthop objects.
I have changed it the name "masked", as that is also the term used in the documentation for the zero-DPV entries, and I think that it will generally be a more accepted term.
"blackhole" is an already accepted term and at least to me it is much more clear than "masked". Keep in mind that both L2 neighbours (FDB) and L3 neighbours share the same uAPI and eventually we might want to extend the use of this flag for L3 neighbours (at least Spectrum supports it), so it needs to make sense for both.
I have changed the name of the flag to 'blackhole', but the struct entry in switchdev_notifier_fdb_info and a function input parameter is still named 'masked'. If that should be changed before I send out V5, please let me know as I hope to get this patch set accepted.
On 2022-08-21 09:08, Ido Schimmel wrote:
I assume you want a hub to simulate multiple MACs behind the same port. You don't need a hub for that. You can set the MAC using mausezahn. See '-a' option:
" -a <src-mac|keyword> Use specified source MAC address with hexadecimal notation such as 00:00:aa:bb:cc:dd. By default the interface MAC address will be used. The keywords ''rand'' and ''own'' refer to a random MAC address (only unicast addresses are created) and the own address, respectively. You can also use the keywords mentioned below although broadcast-type source addresses are officially invalid. "
Ido, I am not so known to the selftests, so I am wondering why I don't see either check_err or check_fail fail, whichever I use, when I think they should and then they are not really checking...
local mac=10:20:30:30:20:10
$MZ $h1 -t udp -a $mac -b rand bridge fdb show dev $swp1 | grep -q "$mac vlan 1 master br0 locked" check_err $? "MAB station move: no locked entry on first injection"
$MZ $h2 -t udp -a $mac -b rand bridge fdb show dev $swp1 | grep -q "$mac vlan 1 master br0 locked" check_err $? "MAB station move: locked entry did not move"
What is wrong here?
For a mv88e6xxx test I guess I can make a check to verify that this driver is in use?
On Wed, Aug 24, 2022 at 10:29:20PM +0200, netdev@kapio-technology.com wrote:
On 2022-08-21 09:08, Ido Schimmel wrote:
I assume you want a hub to simulate multiple MACs behind the same port. You don't need a hub for that. You can set the MAC using mausezahn. See '-a' option:
" -a <src-mac|keyword> Use specified source MAC address with hexadecimal notation such as 00:00:aa:bb:cc:dd. By default the interface MAC address will be used. The keywords ''rand'' and ''own'' refer to a random MAC address (only unicast addresses are created) and the own address, respectively. You can also use the keywords mentioned below although broadcast-type source addresses are officially invalid. "
Ido, I am not so known to the selftests, so I am wondering why I don't see either check_err or check_fail fail, whichever I use, when I think they should and then they are not really checking...
local mac=10:20:30:30:20:10 $MZ $h1 -t udp -a $mac -b rand bridge fdb show dev $swp1 | grep -q "$mac vlan 1 master br0 locked" check_err $? "MAB station move: no locked entry on first injection" $MZ $h2 -t udp -a $mac -b rand bridge fdb show dev $swp1 | grep -q "$mac vlan 1 master br0 locked" check_err $? "MAB station move: locked entry did not move"What is wrong here?
Did you try adding a sleep between mausezahn and the FDB dump? At least that is what learning_test() is doing. It is possible that the packet is not sent / processed fast enough for the bridge to learn it before the dump.
For a mv88e6xxx test I guess I can make a check to verify that this driver is in use?
Not in a generic forwarding test. Maybe in tools/testing/selftests/drivers/net/dsa/
My preference would be to get as much tests as possible in tools/testing/selftests/net/forwarding/bridge_locked_port.sh.
I'm not sure which tests you are planning for mv88e6xxx, but we can pass / fail test cases based on the flags we observe in the FDB dump. For example, if the entry has the "sticky" flag, then the expectation is that the roaming test will fail. Otherwise, it should pass.
On 2022-08-25 11:23, Ido Schimmel wrote:
Ido, I am not so known to the selftests, so I am wondering why I don't see either check_err or check_fail fail, whichever I use, when I think they should and then they are not really checking...
local mac=10:20:30:30:20:10 $MZ $h1 -t udp -a $mac -b rand bridge fdb show dev $swp1 | grep -q "$mac vlan 1 master br0locked" check_err $? "MAB station move: no locked entry on first injection"
$MZ $h2 -t udp -a $mac -b rand bridge fdb show dev $swp1 | grep -q "$mac vlan 1 master br0locked" check_err $? "MAB station move: locked entry did not move"
What is wrong here?
Did you try adding a sleep between mausezahn and the FDB dump? At least that is what learning_test() is doing. It is possible that the packet is not sent / processed fast enough for the bridge to learn it before the dump.
I missed the call to log_test at the end of the test.
For a mv88e6xxx test I guess I can make a check to verify that this driver is in use?
Not in a generic forwarding test. Maybe in tools/testing/selftests/drivers/net/dsa/
My preference would be to get as much tests as possible in tools/testing/selftests/net/forwarding/bridge_locked_port.sh.
I now have a roaming test in tools/testing/selftests/net/forwarding/bridge_locked_port.sh, but it will not pass with mv88e6xxx as it is meant for the SW bridge.
I can check if the sticky flag is set on the locked entry and then skip the test if it is.
The bridge_locked_port.sh test is linked in tools/testing/selftests/drivers/net/dsa/, but if I cannot check if the mv88e6xxx driver or other switchcores are in use, I cannot do more.
I'm not sure which tests you are planning for mv88e6xxx, but we can pass / fail test cases based on the flags we observe in the FDB dump. For example, if the entry has the "sticky" flag, then the expectation is that the roaming test will fail. Otherwise, it should pass.
On Thu, Aug 25, 2022 at 12:27:01PM +0200, netdev@kapio-technology.com wrote:
On 2022-08-25 11:23, Ido Schimmel wrote:
Ido, I am not so known to the selftests, so I am wondering why I don't see either check_err or check_fail fail, whichever I use, when I think they should and then they are not really checking...
local mac=10:20:30:30:20:10 $MZ $h1 -t udp -a $mac -b rand bridge fdb show dev $swp1 | grep -q "$mac vlan 1 master br0locked" check_err $? "MAB station move: no locked entry on first injection"
$MZ $h2 -t udp -a $mac -b rand bridge fdb show dev $swp1 | grep -q "$mac vlan 1 master br0locked" check_err $? "MAB station move: locked entry did not move"
What is wrong here?
Did you try adding a sleep between mausezahn and the FDB dump? At least that is what learning_test() is doing. It is possible that the packet is not sent / processed fast enough for the bridge to learn it before the dump.
I missed the call to log_test at the end of the test.
For a mv88e6xxx test I guess I can make a check to verify that this driver is in use?
Not in a generic forwarding test. Maybe in tools/testing/selftests/drivers/net/dsa/
My preference would be to get as much tests as possible in tools/testing/selftests/net/forwarding/bridge_locked_port.sh.
I now have a roaming test in tools/testing/selftests/net/forwarding/bridge_locked_port.sh, but it will not pass with mv88e6xxx as it is meant for the SW bridge.
I can check if the sticky flag is set on the locked entry and then skip the test if it is.
Instead of skipping it you can check that roaming fails when "sticky" is set.
The bridge_locked_port.sh test is linked in tools/testing/selftests/drivers/net/dsa/, but if I cannot check if the mv88e6xxx driver or other switchcores are in use, I cannot do more.
Since the behavior of the HW data path is reflected to the software bridge and user space via "sticky" / "blackhole" / "extern_learn", you should be able to add test cases to the generic selftest. For example, if "blackhole" is set, then simple ping is expected to fail. Otherwise it is expected to pass.
On 2022-08-25 13:58, Ido Schimmel wrote:
On Thu, Aug 25, 2022 at 12:27:01PM +0200, netdev@kapio-technology.com wrote:
Instead of skipping it you can check that roaming fails when "sticky" is set.
I think that the sticky flag topic generally is beyond the MAB feature, and it doesn't really fit into the bridge_locked_port.sh. But anyhow I guess I can add it to the bridge_sticky_fdb.sh tests.
The bridge_locked_port.sh test is linked in tools/testing/selftests/drivers/net/dsa/, but if I cannot check if the mv88e6xxx driver or other switchcores are in use, I cannot do more.
Since the behavior of the HW data path is reflected to the software bridge and user space via "sticky" / "blackhole" / "extern_learn", you should be able to add test cases to the generic selftest. For example, if "blackhole" is set, then simple ping is expected to fail. Otherwise it is expected to pass.
The problem here is that the "blackhole" flag can only be set now from the mv88e6xxx driver under a locked port, and the locked port itself will not allow ping to work anyhow without a FDB entry free of the "locked" flag, as the MAB tests verify. And disabling MAB on the locked port on the mv88e6xxx will clean the locked entries.
So I see it as a flag for future use, otherwise I will have to add a userspace command to enable the "blackhole" flag.
I have now made station move tests for both the locked port and MAB cases.
linux-kselftest-mirror@lists.linaro.org
-
Ido Schimmel -
netdev＠kapio-technology.com