Hoi,
On Thu, Dec 22, 2022 at 4:08 PM Matthew Smith via lists.fd.io <mgsmith=
netgate....@lists.fd.io> wrote:
>
> On Thu, Dec 22, 2022 at 7:09 AM Petr Boltík <petr.bol...@gmail.com> wrote:
>
>>
>> - To make "plugin linux_nl_plugin.so" working, you need to run VPP inside
>> netns dataplane (same as bird). This can be done by editing VPP systemd
>> startup file (add something like "
>> NetworkNamespacePath=/var/run/netns/dataplane" ) and ensuring that netns
>> "dataplane" will be started first.
>>
>
> I run VPP in the default netns and use FRR & iproute2 in the dataplane
> netns and it works fine. I test this regularly on AWS, Azure, KVM, and bare
> metal. I don't set the netns with vppctl CLI commands though, I set it in
> startup.conf with 'linux-cp { default netns dataplane }'. I will look into
> whether something is broken with the CLI command.
>
I run VPP in default netns and Bird2 & iproute2 in the dataplane netns. I
set default netns dataplane in startup.conf also.
I think OP has a different problem, because I do see their netlink messages
arriving otherwise. One test that you can do, is in the network namespace,
change the link attribute (like ip link set <dev> mtu 1500; or ip link set
<dev> up; or down; and then see if 'vppctl show int' reflects that change.
That would demonstrate that end-to-end, netlink messages are arriving from
the dataplane netns, through kernel, through linux_nl plugin and finally
into the dataplane.
One plausible explanation for the behavior is that linux_nl starts the
netlink listener immediately, based on startup.conf, and it does not change
its mind when you specify 'lcp netns default' on the CLI, in other words:
it will only listen to one namespace, namely the one it found when it
started up. I think this is OP's issue, and if so, then 'lcp netns' is
broken in linux-cp, it can never work, and actually should be considered
harmful because there will only be one netns listened to, so changing it
midflight will give erratic results. The same is true for the 'netns'
argument to lcp create -- the only place where linux_nl will ever pick up
netlink messages is in the very first namespace it started in, as specified
in startup.conf.
As a point of comparison - lcpng will start a netlink listener *once the
first LIP is created*; which is why it will start the listener in either
what was setup in startup.conf, or what it changed to with 'lcp default
netns', to any value set before the very first interface pair is created.
'lcp default netns' works there, but as with linux_nl, if any LIP is
created in a netns other than the initial one which has the (one and only)
netlink listener in it), it will give unexpected results.
I think we should:
- remove lcp netns default from CLI
- remove changing the netns from API
- force use of only startup.conf to start the netlink listener in that, and
only that, network namespace.
Thoughts ?
--
Pim van Pelt <p...@ipng.nl>
PBVP1-RIPE - http://www.ipng.nl/
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22371): https://lists.fd.io/g/vpp-dev/message/22371
Mute This Topic: https://lists.fd.io/mt/95817807/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
