From: Martin KaFai Lau <martin.lau@linux.dev>
To: Anton Protopopov <aspsk@isovalent.com>
Cc: Rumen Telbizov <rumen.telbizov@menlosecurity.com>,
David Ahern <dsahern@kernel.org>,
netdev@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jiri Olsa <jolsa@kernel.org>, Stanislav Fomichev <sdf@google.com>,
bpf@vger.kernel.org
Subject: Re: [PATCH v1 bpf-next 2/2] selftests/bpf: Add BPF_FIB_LOOKUP_MARK tests
Date: Mon, 25 Mar 2024 11:12:39 -0700 [thread overview]
Message-ID: <20e4ebd6-0f75-4472-88f3-96d07af6f665@linux.dev> (raw)
In-Reply-To: <ZgBA6X0QgP+TMFd9@zh-lab-node-5>
On 3/24/24 8:04 AM, Anton Protopopov wrote:
> On Sat, Mar 23, 2024 at 03:34:10PM -0700, Martin KaFai Lau wrote:
>> On 3/22/24 7:02 AM, Anton Protopopov wrote:
>>> This patch extends the fib_lookup test suite by adding a few test
>>> cases for each IP family to test the new BPF_FIB_LOOKUP_MARK flag
>>> to the bpf_fib_lookup:
>>>
>>> * Test destination IP address selection with and without a mark
>>> and/or the BPF_FIB_LOOKUP_MARK flag set
>>>
>>> To test this functionality another network namespace and a new veth
>>> pair were added to the test.
>>>
>>
>> [ ... ]
>>
>>> static const struct fib_lookup_test tests[] = {
>>> @@ -90,10 +105,47 @@ static const struct fib_lookup_test tests[] = {
>>> .daddr = IPV6_ADDR_DST, .expected_ret = BPF_FIB_LKUP_RET_SUCCESS,
>>> .expected_src = IPV6_IFACE_ADDR_SEC,
>>> .lookup_flags = BPF_FIB_LOOKUP_SRC | BPF_FIB_LOOKUP_SKIP_NEIGH, },
>>> + /* policy routing */
>>> + { .desc = "IPv4 policy routing, default",
>>> + .daddr = IPV4_REMOTE_DST, .expected_ret = BPF_FIB_LKUP_RET_SUCCESS,
>>> + .expected_dst = IPV4_GW1, .ifname = "veth3",
>>> + .lookup_flags = BPF_FIB_LOOKUP_MARK | BPF_FIB_LOOKUP_SKIP_NEIGH, },
>>> + { .desc = "IPv4 policy routing, mark doesn't point to a policy",
>>> + .daddr = IPV4_REMOTE_DST, .expected_ret = BPF_FIB_LKUP_RET_SUCCESS,
>>> + .expected_dst = IPV4_GW1, .ifname = "veth3",
>>> + .lookup_flags = BPF_FIB_LOOKUP_MARK | BPF_FIB_LOOKUP_SKIP_NEIGH,
>>> + .mark = MARK_NO_POLICY, },
>>> + { .desc = "IPv4 policy routing, mark points to a policy",
>>> + .daddr = IPV4_REMOTE_DST, .expected_ret = BPF_FIB_LKUP_RET_SUCCESS,
>>> + .expected_dst = IPV4_GW2, .ifname = "veth3",
>>> + .lookup_flags = BPF_FIB_LOOKUP_MARK | BPF_FIB_LOOKUP_SKIP_NEIGH,
>>> + .mark = MARK, },
>>> + { .desc = "IPv4 policy routing, mark points to a policy, but no flag",
>>> + .daddr = IPV4_REMOTE_DST, .expected_ret = BPF_FIB_LKUP_RET_SUCCESS,
>>> + .expected_dst = IPV4_GW1, .ifname = "veth3",
>>> + .lookup_flags = BPF_FIB_LOOKUP_SKIP_NEIGH,
>>> + .mark = MARK, },
>>> + { .desc = "IPv6 policy routing, default",
>>> + .daddr = IPV6_REMOTE_DST, .expected_ret = BPF_FIB_LKUP_RET_SUCCESS,
>>> + .expected_dst = IPV6_GW1, .ifname = "veth3",
>>> + .lookup_flags = BPF_FIB_LOOKUP_MARK | BPF_FIB_LOOKUP_SKIP_NEIGH, },
>>> + { .desc = "IPv6 policy routing, mark doesn't point to a policy",
>>> + .daddr = IPV6_REMOTE_DST, .expected_ret = BPF_FIB_LKUP_RET_SUCCESS,
>>> + .expected_dst = IPV6_GW1, .ifname = "veth3",
>>> + .lookup_flags = BPF_FIB_LOOKUP_MARK | BPF_FIB_LOOKUP_SKIP_NEIGH,
>>> + .mark = MARK_NO_POLICY, },
>>> + { .desc = "IPv6 policy routing, mark points to a policy",
>>> + .daddr = IPV6_REMOTE_DST, .expected_ret = BPF_FIB_LKUP_RET_SUCCESS,
>>> + .expected_dst = IPV6_GW2, .ifname = "veth3",
>>> + .lookup_flags = BPF_FIB_LOOKUP_MARK | BPF_FIB_LOOKUP_SKIP_NEIGH,
>>> + .mark = MARK, },
>>> + { .desc = "IPv6 policy routing, mark points to a policy, but no flag",
>>> + .daddr = IPV6_REMOTE_DST, .expected_ret = BPF_FIB_LKUP_RET_SUCCESS,
>>> + .expected_dst = IPV6_GW1, .ifname = "veth3",
>>> + .lookup_flags = BPF_FIB_LOOKUP_SKIP_NEIGH,
>>> + .mark = MARK, },
>>> };
>>> -static int ifindex;
>>> -
>>> static int setup_netns(void)
>>> {
>>> int err;
>>> @@ -144,12 +196,40 @@ static int setup_netns(void)
>>> if (!ASSERT_OK(err, "write_sysctl(net.ipv6.conf.veth1.forwarding)"))
>>> goto fail;
>>> + /* Setup for policy routing tests */
>>> + SYS(fail, "ip link add veth3 type veth peer name veth4");
>>> + SYS(fail, "ip link set dev veth3 up");
>>> + SYS(fail, "ip link set dev veth4 netns %s up", NS_REMOTE);
>>> +
>>> + SYS(fail, "ip addr add %s/24 dev veth3", IPV4_LOCAL);
>>> + SYS(fail, "ip netns exec %s ip addr add %s/24 dev veth4", NS_REMOTE, IPV4_GW1);
>>> + SYS(fail, "ip netns exec %s ip addr add %s/24 dev veth4", NS_REMOTE, IPV4_GW2);
>>> + SYS(fail, "ip addr add %s/64 dev veth3 nodad", IPV6_LOCAL);
>>> + SYS(fail, "ip netns exec %s ip addr add %s/64 dev veth4 nodad", NS_REMOTE, IPV6_GW1);
>>> + SYS(fail, "ip netns exec %s ip addr add %s/64 dev veth4 nodad", NS_REMOTE, IPV6_GW2);
>>
>> Trying to see if the setup can be simplified.
>>
>> Does it need to add another netns and setup a reachable IPV[46]_GW[12] gateway?
>>
>> The test is not sending any traffic and it is a BPF_FIB_LOOKUP_SKIP_NEIGH test.
>
> I think this will not work without another namespace, as FIB lookup will
> return DST="final destination", not DST="gateway", as the gateway is in the
> same namespace and can be skipped.
hmm... not sure I understand why it would get "final destination". Am I missing something?
To be specific, there is no need to configure the IPV[46]_GW[12] address:
- SYS(fail, "ip link set dev veth4 netns %s up", NS_REMOTE);
SYS(fail, "ip addr add %s/24 dev veth3", IPV4_LOCAL);
- SYS(fail, "ip netns exec %s ip addr add %s/24 dev veth4", NS_REMOTE, IPV4_GW1);
- SYS(fail, "ip netns exec %s ip addr add %s/24 dev veth4", NS_REMOTE, IPV4_GW2);
SYS(fail, "ip addr add %s/64 dev veth3 nodad", IPV6_LOCAL);
- SYS(fail, "ip netns exec %s ip addr add %s/64 dev veth4 nodad", NS_REMOTE, IPV6_GW1);
- SYS(fail, "ip netns exec %s ip addr add %s/64 dev veth4 nodad", NS_REMOTE, IPV6_GW2);
SYS(fail, "ip route add %s/32 via %s", IPV4_REMOTE_DST, IPV4_GW1);
SYS(fail, "ip route add %s/32 via %s table %s", IPV4_REMOTE_DST, IPV4_GW2, MARK_TABLE);
SYS(fail, "ip -6 route add %s/128 via %s", IPV6_REMOTE_DST, IPV6_GW1);
SYS(fail, "ip -6 route add %s/128 via %s table %s", IPV6_REMOTE_DST, IPV6_GW2, MARK_TABLE);
SYS(fail, "ip rule add prio 2 fwmark %d lookup %s", MARK, MARK_TABLE);
SYS(fail, "ip -6 rule add prio 2 fwmark %d lookup %s", MARK, MARK_TABLE);
[root@arch-fb-vm1 ~]# ip netns exec fib_lookup_ns /bin/bash
[root@arch-fb-vm1 ~]# ip -6 rule
0: from all lookup local
2: from all fwmark 0x2a lookup 200
32766: from all lookup main
[root@arch-fb-vm1 ~]# ip -6 route show table main
be:ef::b0:10 via fd01::1 dev veth3 metric 1024 linkdown pref medium
[root@arch-fb-vm1 ~]# ip -6 route show table 200
be:ef::b0:10 via fd01::2 dev veth3 metric 1024 linkdown pref medium
[root@arch-fb-vm1 ~]# ip -6 route get be:ef::b0:10
be:ef::b0:10 from :: via fd01::1 dev veth3 src fd01::3 metric 1024 pref medium
[root@arch-fb-vm1 ~]# ip -6 route get be:ef::b0:10 mark 0x2a
be:ef::b0:10 from :: via fd01::2 dev veth3 table 200 src fd01::3 metric 1024 pref medium
>
> Instead of adding a new namespace I can move the second interface to the
> root namespace. This will work, but then we're interfering with the root
> namespace.
>
>>> + SYS(fail, "ip route add %s/32 via %s", IPV4_REMOTE_DST, IPV4_GW1);
>>> + SYS(fail, "ip route add %s/32 via %s table %s", IPV4_REMOTE_DST, IPV4_GW2, MARK_TABLE);
>>> + SYS(fail, "ip -6 route add %s/128 via %s", IPV6_REMOTE_DST, IPV6_GW1);
>>> + SYS(fail, "ip -6 route add %s/128 via %s table %s", IPV6_REMOTE_DST, IPV6_GW2, MARK_TABLE);
>>> + SYS(fail, "ip rule add prio 2 fwmark %d lookup %s", MARK, MARK_TABLE);
>>> + SYS(fail, "ip -6 rule add prio 2 fwmark %d lookup %s", MARK, MARK_TABLE);
>>> +
>>> + err = write_sysctl("/proc/sys/net/ipv4/conf/veth3/forwarding", "1");
>>> + if (!ASSERT_OK(err, "write_sysctl(net.ipv4.conf.veth3.forwarding)"))
>>> + goto fail;
>>> +
>>> + err = write_sysctl("/proc/sys/net/ipv6/conf/veth3/forwarding", "1");
>>> + if (!ASSERT_OK(err, "write_sysctl(net.ipv6.conf.veth3.forwarding)"))
>>> + goto fail;
>>> +
>>> return 0;
>>> fail:
>>> return -1;
>>> }
>>
>> [ ... ]
>>
>>> @@ -248,6 +337,7 @@ void test_fib_lookup(void)
>>> prog_fd = bpf_program__fd(skel->progs.fib_lookup);
>>> SYS(fail, "ip netns add %s", NS_TEST);
>>> + SYS(fail, "ip netns add %s", NS_REMOTE);
>>
>>
next prev parent reply other threads:[~2024-03-25 18:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-22 14:02 [PATCH v1 bpf-next 0/2] BPF: support mark in bpf_fib_lookup Anton Protopopov
2024-03-22 14:02 ` [PATCH v1 bpf-next 1/2] bpf: add support for passing mark with bpf_fib_lookup Anton Protopopov
2024-03-24 17:38 ` David Ahern
2024-03-25 12:19 ` Anton Protopopov
2024-03-22 14:02 ` [PATCH v1 bpf-next 2/2] selftests/bpf: Add BPF_FIB_LOOKUP_MARK tests Anton Protopopov
2024-03-23 22:34 ` Martin KaFai Lau
2024-03-24 15:04 ` Anton Protopopov
2024-03-25 18:12 ` Martin KaFai Lau [this message]
2024-03-25 20:03 ` Anton Protopopov
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=20e4ebd6-0f75-4472-88f3-96d07af6f665@linux.dev \
--to=martin.lau@linux.dev \
--cc=andrii@kernel.org \
--cc=aspsk@isovalent.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dsahern@kernel.org \
--cc=jolsa@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rumen.telbizov@menlosecurity.com \
--cc=sdf@google.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.