+Matthew Smith <mgsm...@netgate.com> and +Jon Loeliger <j...@netgate.com> can
you let me know what you think?
Does Netgate value the 'lcp default netns' or ability to create LIPs in a
namespace other than 'dataplane'?
As I described, I think the ability to change these in the API, or set them
in 'lcp create' yields erratic behavior.
groet,
Pim
On Thu, Dec 22, 2022 at 4:28 PM Pim van Pelt <p...@ipng.nl> wrote:
> 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/
>
--
Pim van Pelt <p...@ipng.nl>
PBVP1-RIPE - http://www.ipng.nl/
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22434): https://lists.fd.io/g/vpp-dev/message/22434
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]
-=-=-=-=-=-=-=-=-=-=-=-
