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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 18 Jan 2018 13:46:14 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        David Ahern <dsahern@...il.com>,
        Ido Schimmel <idosch@...lanox.com>, netdev@...r.kernel.org,
        linux-kselftest@...r.kernel.org, davem@...emloft.net,
        shuah@...nel.org, nikolay@...ulusnetworks.com,
        roopa@...ulusnetworks.com, andy@...yhouse.net, jiri@...lanox.com,
        mlxsw@...lanox.com, saeedm@...lanox.com, tariqt@...lanox.com,
        jhs@...atatu.com, lucasb@...atatu.com,
        vivien.didelot@...oirfairelinux.com, jakub.kicinski@...ronome.com,
        simon.horman@...ronome.com
Subject: Re: [RFC PATCH net-next 00/12] selftests: forwarding: Add VRF-based
 tests

> > > >>
> > > >>                              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?

By default, we have port separation. So you can add individual IP
addresses to interfaces, and ping from them. In fact, this is the
first test i always run. My test setup uses 4 ports of the switch, and
connects a USB-Ethernet dongle to each port. The 4 USB cables then
connect to my host running the tests. I setup four parallel subnets,
and ping across each.

I've never used vrf, so i've no idea if that will just work on top.

> 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.

We are all L2. So no route needed. No ACLs either.

So in theory, this could be used with DSA. But in practice, only
having two test ports really restricts you from doing anything
interesting. You need a minimum of 3, and all my tests use 4. Given
your double requirements, that means you actually need a switch with 8
external ports. I don't know of any DSA board which has that.

  Andrew