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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 18 Jan 2018 09:41:25 +0200
From:   Ido Schimmel <idosch@...sch.org>
To:     Andrew Lunn <andrew@...n.ch>
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

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.