From: andrew at lunn.ch (Andrew Lunn)
Subject: [Linux-kselftest-mirror] [RFC PATCH net-next 00/12] selftests: forwarding: Add VRF-based tests
Date: Thu, 18 Jan 2018 00:11:11 +0100 [thread overview]
Message-ID: <20180117231111.GG5894@lunn.ch> (raw)
In-Reply-To: <c8c4a3ef-f21d-0e13-5d35-dfa212c439ab@gmail.com>
> >> 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.
But for top or rack switches, 16 ports, 8 loopback cables, that does
give interesting setups. If i were writing tests for that class of
routers, that would be the hardware setup i would define.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: andrew@lunn.ch (Andrew Lunn)
Subject: [Linux-kselftest-mirror] [RFC PATCH net-next 00/12] selftests: forwarding: Add VRF-based tests
Date: Thu, 18 Jan 2018 00:11:11 +0100 [thread overview]
Message-ID: <20180117231111.GG5894@lunn.ch> (raw)
Message-ID: <20180117231111.0bxewW38FKvBKS_X_3YiMrPyMIZNm7Hswohp_WXVNXU@z> (raw)
In-Reply-To: <c8c4a3ef-f21d-0e13-5d35-dfa212c439ab@gmail.com>
> >> 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.
But for top or rack switches, 16 ports, 8 loopback cables, that does
give interesting setups. If i were writing tests for that class of
routers, that would be the hardware setup i would define.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew@lunn.ch>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: David Ahern <dsahern@gmail.com>,
Ido Schimmel <idosch@mellanox.com>,
netdev@vger.kernel.org, linux-kselftest@vger.kernel.org,
davem@davemloft.net, shuah@kernel.org,
nikolay@cumulusnetworks.com, roopa@cumulusnetworks.com,
andy@greyhouse.net, jiri@mellanox.com, mlxsw@mellanox.com,
saeedm@mellanox.com, tariqt@mellanox.com, jhs@mojatatu.com,
lucasb@mojatatu.com, vivien.didelot@savoirfairelinux.com,
jakub.kicinski@netronome.com, simon.horman@netronome.com
Subject: Re: [RFC PATCH net-next 00/12] selftests: forwarding: Add VRF-based tests
Date: Thu, 18 Jan 2018 00:11:11 +0100 [thread overview]
Message-ID: <20180117231111.GG5894@lunn.ch> (raw)
In-Reply-To: <c8c4a3ef-f21d-0e13-5d35-dfa212c439ab@gmail.com>
> >> 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.
But for top or rack switches, 16 ports, 8 loopback cables, that does
give interesting setups. If i were writing tests for that class of
routers, that would be the hardware setup i would define.
Andrew
next prev parent reply other threads:[~2018-01-17 23:11 UTC|newest]
Thread overview: 105+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-15 19:18 [Linux-kselftest-mirror] [RFC PATCH net-next 00/12] selftests: forwarding: Add VRF-based tests idosch
2018-01-15 19:18 ` Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] " Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] [RFC PATCH net-next 01/12] selftests: forwarding: Add initial testing framework idosch
2018-01-15 19:18 ` Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] " Ido Schimmel
2018-01-17 20:56 ` dsahern
2018-01-17 20:56 ` David Ahern
2018-01-17 20:56 ` [Linux-kselftest-mirror] " David Ahern
2018-01-17 21:18 ` andrew
2018-01-17 21:18 ` Andrew Lunn
2018-01-17 21:18 ` [Linux-kselftest-mirror] " Andrew Lunn
2018-01-17 21:26 ` dsahern
2018-01-17 21:26 ` David Ahern
2018-01-17 21:26 ` [Linux-kselftest-mirror] " David Ahern
2018-01-15 19:18 ` [Linux-kselftest-mirror] [RFC PATCH net-next 02/12] selftests: forwarding: Add a test for FDB learning idosch
2018-01-15 19:18 ` Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] " Ido Schimmel
2018-01-15 19:41 ` andrew
2018-01-15 19:41 ` Andrew Lunn
2018-01-15 19:41 ` [Linux-kselftest-mirror] " Andrew Lunn
2018-01-15 20:05 ` idosch
2018-01-15 20:05 ` Ido Schimmel
2018-01-15 20:05 ` [Linux-kselftest-mirror] " Ido Schimmel
2018-01-15 21:01 ` andrew
2018-01-15 21:01 ` Andrew Lunn
2018-01-15 21:01 ` [Linux-kselftest-mirror] " Andrew Lunn
2018-01-17 20:48 ` dsahern
2018-01-17 20:48 ` David Ahern
2018-01-17 20:48 ` [Linux-kselftest-mirror] " David Ahern
2018-01-17 21:01 ` jiri
2018-01-17 21:01 ` Jiri Pirko
2018-01-17 21:01 ` [Linux-kselftest-mirror] " Jiri Pirko
2018-01-17 22:46 ` roopa
2018-01-17 22:46 ` Roopa Prabhu
2018-01-17 22:46 ` [Linux-kselftest-mirror] " Roopa Prabhu
2018-01-17 22:59 ` roopa
2018-01-17 22:59 ` Roopa Prabhu
2018-01-17 22:59 ` [Linux-kselftest-mirror] " Roopa Prabhu
2018-01-17 23:31 ` jiri
2018-01-17 23:31 ` Jiri Pirko
2018-01-17 23:31 ` [Linux-kselftest-mirror] " Jiri Pirko
2018-01-18 0:15 ` dsahern
2018-01-18 0:15 ` David Ahern
2018-01-18 0:15 ` [Linux-kselftest-mirror] " David Ahern
2018-01-18 7:16 ` idosch
2018-01-18 7:16 ` Ido Schimmel
2018-01-18 7:16 ` [Linux-kselftest-mirror] " Ido Schimmel
2018-01-18 7:51 ` jiri
2018-01-18 7:51 ` Jiri Pirko
2018-01-18 7:51 ` [Linux-kselftest-mirror] " Jiri Pirko
2018-01-15 19:18 ` [Linux-kselftest-mirror] [RFC PATCH net-next 03/12] selftests: forwarding: Add a test for flooded traffic idosch
2018-01-15 19:18 ` Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] " Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] [RFC PATCH net-next 04/12] selftests: forwarding: Add a test for basic IPv4 and IPv6 routing idosch
2018-01-15 19:18 ` Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] " Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] [RFC PATCH net-next 05/12] selftests: forwarding: Create test topology for multipath routing idosch
2018-01-15 19:18 ` Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] " Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] [RFC PATCH net-next 06/12] selftests: forwarding: Test IPv4 weighted nexthops idosch
2018-01-15 19:18 ` Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] " Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] [RFC PATCH net-next 07/12] selftests: forwarding: Test IPv6 " idosch
2018-01-15 19:18 ` Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] " Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] [RFC PATCH net-next 08/12] selftests: forwarding: Add tc offload check helper idosch
2018-01-15 19:18 ` Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] " Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] [RFC PATCH net-next 09/12] selftests: forwarding: Add MAC get helper idosch
2018-01-15 19:18 ` Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] " Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] [RFC PATCH net-next 10/12] selftests: forwarding: Allow to get netdev interfaces names from commandline idosch
2018-01-15 19:18 ` Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] " Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] [RFC PATCH net-next 11/12] selftests: forwarding: Allow to pass commandline options idosch
2018-01-15 19:18 ` Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] " Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] [RFC PATCH net-next 12/12] selftests: forwarding: Introduce tc flower matching tests idosch
2018-01-15 19:18 ` Ido Schimmel
2018-01-15 19:18 ` [Linux-kselftest-mirror] " Ido Schimmel
2018-01-15 20:14 ` [Linux-kselftest-mirror] [RFC PATCH net-next 00/12] selftests: forwarding: Add VRF-based tests dsahern
2018-01-15 20:14 ` David Ahern
2018-01-15 20:14 ` [Linux-kselftest-mirror] " David Ahern
2018-01-15 23:17 ` jiri
2018-01-15 23:17 ` Jiri Pirko
2018-01-15 23:17 ` [Linux-kselftest-mirror] " Jiri Pirko
2018-01-15 23:48 ` dsahern
2018-01-15 23:48 ` David Ahern
2018-01-15 23:48 ` [Linux-kselftest-mirror] " David Ahern
2018-01-16 7:59 ` idosch
2018-01-16 7:59 ` Ido Schimmel
2018-01-16 7:59 ` [Linux-kselftest-mirror] " Ido Schimmel
2018-01-17 22:51 ` f.fainelli
2018-01-17 22:51 ` Florian Fainelli
2018-01-17 22:51 ` [Linux-kselftest-mirror] " Florian Fainelli
2018-01-17 23:11 ` andrew [this message]
2018-01-17 23:11 ` Andrew Lunn
2018-01-17 23:11 ` [Linux-kselftest-mirror] " Andrew Lunn
2018-01-18 7:41 ` idosch
2018-01-18 7:41 ` Ido Schimmel
2018-01-18 7:41 ` [Linux-kselftest-mirror] " Ido Schimmel
2018-01-18 12:46 ` andrew
2018-01-18 12:46 ` Andrew Lunn
2018-01-18 12:46 ` [Linux-kselftest-mirror] " Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180117231111.GG5894@lunn.ch \
--to=unknown@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.