On Sat, Aug 29, 2026 at 11:11:50PM +0200, Andrea Mayer wrote:
> On Fri, 28 Aug 2026 18:04:41 +0200
> Alessio Faina <[email protected]> wrote:
>
> > [snip]
> >
>
> Hi Alessio,
>
> > I tried multiple methods:
> > the first approach is yours, but I can see the following error with any
> > iproute2
> > version I'm using (I tried 5.5 to 5.18): when running
> > "ip -netns ${rtdst_name}" command, it always returns
> >
> > RTNETLINK answers: File exists
> > 2
>
> EEXIST means that the object is already there, and says nothing about
> vrftable. When ip does not know vrftable it refuses the command itself,
> with the error you showed earlier: either "to" is duplicate,
> or "vrftable" is a garbage.
>
> In a netns created by the check there is nothing to collide with, so EEXIST
> does not come from the way I suggested. The full command and output would
> settle it.
>
> > I tried the following approach as well,
> >
> > # set the decap route for decapsulating packets which arrive from
> > # the rtdst router and destined to the hsdst host.
> > - ip -netns ${rtdst_name} -6 route add ${vpn_sid}/128 table
> > ${LOCALSID_TABLE_ID} \
> > - encap seg6local action End.DT4 vrftable ${tid} dev vrf-${tid}
> > + if ! ip -netns ${rtdst_name} -6 route add ${vpn_sid}/128 table
> > ${LOCALSID_TABLE_ID} \
> > + encap seg6local action End.DT4 vrftable ${tid} dev
> > vrf-${tid} 2>/dev/null; then
> > + echo "SKIP: SRv6 End.DT4 vrftable not supported in iproute2"
> > + cleanup
> > + exit "${ksft_skip}"
> > + fi
> >
> > where the test is checked at vrftable creation time, and it would
> > cleanup and exit as expected from standard tests.
> >
> > But obviously this gets the same RTNETLINK answer as an error.
> >
>
> This is a setup step, not a check. The skip decision is taken while the
> topology is being built, because setup_vpn_config() is called several times
> inside setup(). The check should run before setup(), once.
>
> The way I suggested runs the route add with vrftable in a throwaway netns,
> created and removed by the check itself.
> test_encap_lookup_supp_or_ksft_skip() in srv6_encap_lookup_l3vpn_test.sh
> has that shape: it creates the netns, adds the device it needs, tries its
> route, and on failure cleans up and exits ksft_skip. For the dt4 and dt6
> tests that device is a vrf bound to the table passed to vrftable, and the
> netns also needs the strict mode.
>
> > Then another approach came to my mind, and it seems to be quite reliable.
> > Practically checking if the ip command contains the string "vrftable"
> > using the "strings" command, and if not, skip the test.
> >
> > Something like this:
> >
> > +test_iproute2_vrftable_supp_or_ksft_skip()
> > +{
> > + if ! strings $(command -v ip) | grep -q "vrftable"; then
> > + echo "SKIP: SRv6 End.DT4 vrftable not supported in iproute2"
> > + exit "${ksft_skip}"
> > + fi
> > +}
> > +
> >
> > What do you think about it?
>
> I would rather not add a new tool dependency to these two tests. The
> route add uses ip, which the test needs anyway.
>
> Ciao,
> Andrea
Hi Andrea,
I understand, what you say makes sense; in the end what you originally
suggested seems to be the best approach.
I tried this
+test_iproute2_vrftable_supp_or_ksft_skip()
+{
+ ip netns add __vrftable_test 2>/dev/null
+ ip netns exec __vrftable_test sh -c "echo 1 >
/proc/sys/net/vrf/strict_mode"
+ ip -netns __vrftable_test link add vrf-100 type vrf table 100
+ ip -netns __vrftable_test link set vrf-100 up
+ if ! ip -netns __vrftable_test -6 route add fc00::1/128 \
+ encap seg6local action End.DT4 vrftable 100 dev vrf-100
2>/dev/null; then
+ ip netns del __vrftable_test 2>/dev/null
+ echo "SKIP: SRv6 vrftable not supported in iproute2"
+ exit "${ksft_skip}"
+ fi
+ ip netns del __vrftable_test 2>/dev/null
+}
+
+test_iproute2_vrftable_supp_or_ksft_skip
+
and seems to be behaving as expected in my environment for multiple
iproute2 versions. If you're happy with it I'll send a v2 to net-next.
Kind regards,
-Alessio Faina
