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.mate...@nic.cz> wrote: > > Hello! > > On 6/7/19 3:15 PM, b...@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 >
