We only set the default netns via startup.conf, so it is not critical to us
to be able to do it via CLI/API.
We don't currently create interface pairs in any netns other than the
default one. So it's not critical for us to be able to set a netns on a
per-pair basis currently.
-Matt
On Sun, Jan 8, 2023 at 5:54 PM Pim van Pelt <p...@ipng.nl> wrote:
> +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 (#22435): https://lists.fd.io/g/vpp-dev/message/22435
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]
-=-=-=-=-=-=-=-=-=-=-=-
