Kernel protocol and different namespaces

[Alexander Zubkov]

Hello,

We want to use bird with different namespaces too, but proposed
changes is not an option for us anyway because of somewhat proprietary
kernel we are working with (there are some missing definitions for
namespaces in headers and vanilla does not fit). So we are also
thinking about several instances of bird as Maria Jan Matějka
suggests. But we need to find some way to interconnect them. But we
think creating a veth interface is not a best option for us. If bird
could somehow excange routes over a unix socket for example (may be
run bgp over it) - that would be helpful for us and possibly for Jakub
Nowacki, who started the topic. Of course we can overcome it with a
couple of socat-s or haproxy-s in both namespaces, but that multiplies
components and makes the whole operations less stable.

On Fri, Jun 7, 2019 at 4:58 PM Maria Jan Matejka <jan.matejka at nic.cz> wrote:
>
> Hello!
>
> On 6/7/19 3:15 PM, bird at ipv2.de wrote:
> > I disagree. I am quite sure this is technologically possible. As in, the Linux kernel should allow you to do this.
>
> Well, it is definitely possible, yet it probably is not feasible nor reasonable.
>
> > From my understanding of (network) namespace, a process that is root should be able to use setns() to change its namespace.
> > I doubt bird is capable of this, as is, but it should be possible to patch it in order to do this.
>
> It is probably more efficient to write another piece of routing software capable of doing this.
> It would include quite a lot of changes in the device subsystem including support for many interfaces
> named the same, support for reading interface notifications from all network namespaces configured
> (and even passing the network namespace information to BIRD in a reliable way is tricky),
> proper handling of network namespace creation and deletion during reconfiguration, ... you just don't
> want to do that. Trust me.
>
> And even if you wrote some patch to do this, I won't merge it (and I bet Ondrej won't merge it as well).
> It is complicated and time needed to merge it isn't worth the outcome. See the paragraph before.
>
> Moreover, the namespace separation is intended to do separation (aka. light virtualization) and BIRD
> should not cross the boundary. I admit this is somehow deliberate, anyway this is how the namespaces
> are presented and developed -- as light virtualization. I don't think it would be legitimate for BIRD
> to fiddle with the network namespaces, or worse, if you run it in the non-default namespace,
> it should not leave its aviary just passing through the netting.
>
> The virtualized guest routing should be done there in the guest, not in the hypervisor. The fact that
> BIRD is usually started as root (and then dropping its privileges while switching to its dedicated user)
> doesn't approve you to use BIRD in such a magical way.
>
> If you need to do virtual routing and forwarding, if you want to split your network into several
> data planes, virtual routers or whatever else, it should be enough to use VRF.
>
> >>> I'm trying to figure out if it's possible to use protocol kernel to export routes to OS routing table that are in different Linux namespaces. Is this possible at all?
>
> You can:
> * use VRF's, which is supported by BIRD v2
> * run one instance of BIRD per network namespace and connect them by BGP via veth
>
> If any of these are somehow broken, please report a bug.
>
> Thank you for your understanding
> Maria
>