Re: [RFC PATCH net-next 00/12] selftests: forwarding: Add VRF-based tests

[Ido Schimmel <idosch@idosch.org>]

Hi Andrew, Florian

On Thu, Jan 18, 2018 at 12:11:11AM +0100, Andrew Lunn wrote:
> > >> However, a similar kind of flexibility can be achieved by using VRFs and
> > >> by looping the switch ports together. For example:
> > >>
> > >>                              br0
> > >>                               +
> > >>                vrf-h1         |           vrf-h2
> > >>                  +        +---+----+        +
> > >>                  |        |        |        |
> > >>     192.0.2.1/24 +        +        +        + 192.0.2.2/24
> > >>                swp1     swp2     swp3     swp4
> > >>                  +        +        +        +
> > >>                  |        |        |        |
> > >>                  +--------+        +--------+
> > >>
> 
> > Agreed this is really cool! For DSA enabled switches, we usually have a
> > host that does the test sequencing and then execute commands remotely on
> > the DUT, but we might be able to get such a similar framework up and
> > running on the DUT itself without too much hassle.
> 
> I think the problem we will have is a lack of ports. Most DSA switches
> have 4 or 5 ports. Given the need for two ports per bridge port, we
> will be limited to bridges with just two members. That really limits
> what sort of tests you can do.

I was actually interested in feedback from you guys. Looking at
dsa_slave_changeupper() I see you don't forbid the enslavement to a VRF
and that you set STP state to forwarding when a port leaves a bridge
(good). Does that mean you're able to use some of these tests on your
switches?

The reason we can use these tests for mlxsw is that we support VRF and
ACL offload. At least in the above example, swp4 is able to receive
packets directed at 192.0.2.2 because we program the device with the
host route 192.0.2.2/32.