Kernel protocol and different namespaces
Hi, 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? I've found previous post https://bird.network.cz/pipermail/bird-users/2014-October/009393.html suggesting that only option is to use multiple instances of Bird, each running in different namespace. I was hoping I could just stick to one instance and export routes to different namespaces. Regards -- Kuba Nowacki
It’s not possible - the whole purpose of namespaces *is* separation. The only way to exchange routes is to run multiple instances of bird in the different namespaces and set up a (veth) link between them. Best Remco
On 7 Jun 2019, at 09:19, Jakub Nowacki <jnowacki@greywizard.com> wrote:
Hi,
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?
I've found previous post https://bird.network.cz/pipermail/bird-users/2014-October/009393.html <https://bird.network.cz/pipermail/bird-users/2014-October/009393.html> suggesting that only option is to use multiple instances of Bird, each running in different namespace. I was hoping I could just stick to one instance and export routes to different namespaces.
Regards -- Kuba Nowacki
I disagree. I am quite sure this is technologically possible. As in, the Linux kernel should allow you to do this.
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.
For some simple testing on how to traverse network namespaces, you can use ip netns. Best Regards On Fri, 7 Jun 2019 09:42:43 +0200 remco van mook <remco.vanmook@gmail.com> wrote:
It’s not possible - the whole purpose of namespaces *is* separation. The only way to exchange routes is to run multiple instances of bird in the different namespaces and set up a (veth) link between them.
Best
Remco
On 7 Jun 2019, at 09:19, Jakub Nowacki <jnowacki@greywizard.com> wrote:
Hi,
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?
I've found previous post https://bird.network.cz/pipermail/bird-users/2014-October/009393.html <https://bird.network.cz/pipermail/bird-users/2014-October/009393.html> suggesting that only option is to use multiple instances of Bird, each running in different namespace. I was hoping I could just stick to one instance and export routes to different namespaces.
Regards -- Kuba Nowacki
Hello! On 6/7/19 3:15 PM, bird@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
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@nic.cz> wrote:
Hello!
On 6/7/19 3:15 PM, bird@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
Alexander Zubkov <green@qrator.net> writes:
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.
Why not? -Toke
On Fri, Jun 7, 2019 at 5:44 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
Alexander Zubkov <green@qrator.net> writes:
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.
Why not?
We do not want direct routing between namespaces. And also add some additional interfaces - it is a hardware switch, so it could disturb something. But may be not. This could be an option too. I just wrote that it could be not the best one. We have not tested yet, just considering possibilities.
-Toke
What about having the veth's in separate VRF's inside the netns's? Do you need the full BGP features on the Unix socket, or just a pipe-like transport? Not promising now that I'll implement it soon, just trying to define the feature request, yet it should be quite easy to create. Maria On June 7, 2019 6:00:14 PM GMT+02:00, Alexander Zubkov <green@qrator.net> wrote:
On Fri, Jun 7, 2019 at 5:44 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
Alexander Zubkov <green@qrator.net> writes:
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.
Why not?
We do not want direct routing between namespaces. And also add some additional interfaces - it is a hardware switch, so it could disturb something. But may be not. This could be an option too. I just wrote that it could be not the best one. We have not tested yet, just considering possibilities.
-Toke
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
I'm not sure right now that its kernel supports vrf. Anyway, I know there are some ways to connect them in terms of its current possibilities. And we will do it one way or another. I just wanted to propose a feature that could make such setups easier and probably is not too hard to implement and does not brake internal things. I would be also glad to hear from Jakub if it will help him too. Of course bgp is not the only option here, it is just the most familiar to me as a prtocol working over a stream socket and that would keep communities etc. Pipe would be fine too, but it does not have "on the wire representation" now, I suppose. And I am not sure about things like - when the route is received, it is checked with local interfaces etc. I think pipe skips most of this stuff. But I'm not familiar with the internals of bird, just assuming what pros and cons could be. On Fri, Jun 7, 2019 at 7:21 PM Maria Jan Matějka <jan.matejka@nic.cz> wrote:
What about having the veth's in separate VRF's inside the netns's?
Do you need the full BGP features on the Unix socket, or just a pipe-like transport? Not promising now that I'll implement it soon, just trying to define the feature request, yet it should be quite easy to create.
Maria
On June 7, 2019 6:00:14 PM GMT+02:00, Alexander Zubkov <green@qrator.net> wrote:
On Fri, Jun 7, 2019 at 5:44 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
Alexander Zubkov <green@qrator.net> writes:
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.
Why not?
We do not want direct routing between namespaces. And also add some additional interfaces - it is a hardware switch, so it could disturb something. But may be not. This could be an option too. I just wrote that it could be not the best one. We have not tested yet, just considering possibilities.
-Toke
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Thinking once more about it, with respect to the interfaces and so, the BGP transported over Unix socket seems to be quite simple feature to do. I'll see what can be done with that. Maria On June 7, 2019 8:06:30 PM GMT+02:00, Alexander Zubkov <green@qrator.net> wrote:
I'm not sure right now that its kernel supports vrf. Anyway, I know there are some ways to connect them in terms of its current possibilities. And we will do it one way or another. I just wanted to propose a feature that could make such setups easier and probably is not too hard to implement and does not brake internal things. I would be also glad to hear from Jakub if it will help him too. Of course bgp is not the only option here, it is just the most familiar to me as a prtocol working over a stream socket and that would keep communities etc. Pipe would be fine too, but it does not have "on the wire representation" now, I suppose. And I am not sure about things like - when the route is received, it is checked with local interfaces etc. I think pipe skips most of this stuff. But I'm not familiar with the internals of bird, just assuming what pros and cons could be.
On Fri, Jun 7, 2019 at 7:21 PM Maria Jan Matějka <jan.matejka@nic.cz> wrote:
What about having the veth's in separate VRF's inside the netns's?
Do you need the full BGP features on the Unix socket, or just a
pipe-like transport? Not promising now that I'll implement it soon, just trying to define the feature request, yet it should be quite easy to create.
Maria
On June 7, 2019 6:00:14 PM GMT+02:00, Alexander Zubkov
<green@qrator.net> wrote:
On Fri, Jun 7, 2019 at 5:44 PM Toke Høiland-Jørgensen <toke@toke.dk>
wrote:
Alexander Zubkov <green@qrator.net> writes:
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.
Why not?
We do not want direct routing between namespaces. And also add some additional interfaces - it is a hardware switch, so it could disturb something. But may be not. This could be an option too. I just wrote that it could be not the best one. We have not tested yet, just considering possibilities.
-Toke
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 6/7/19 12:14 PM, Maria Jan Matějka wrote:
Thinking once more about it, with respect to the interfaces and so, the BGP transported over Unix socket seems to be quite simple feature to do.
I thought, and my initial tests support, that Unix sockets are network namespace specific. # netstat -aFunix Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eno1 1500 77564888 0 614 0 66111123 0 0 0 BMRU lo 65536 68143909 0 0 0 68143909 0 0 0 LRU # ip netns add test # ip netns exec test /bin/netstat -aFunix Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg lo 65536 0 0 0 0 0 0 0 0 L # ip netns del test So, I'm not sure if that's going to work the way that you want. -- Grant. . . . unix || die
On 6/7/19 12:14 PM, Maria Jan Matějka wrote:
Thinking once more about it, with respect to the interfaces and so, the BGP transported over Unix socket seems to be quite simple feature to do.
I thought, and my initial tests support, that Unix sockets are network namespace specific.
# netstat -aFunix Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eno1 1500 77564888 0 614 0 66111123 0 0 0 BMRU lo 65536 68143909 0 0 0 68143909 0 0 0 LRU # ip netns add test # ip netns exec test /bin/netstat -aFunix Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg lo 65536 0 0 0 0 0 0 0 0 L # ip netns del test
So, I'm not sure if that's going to work the way that you want.
It will work the same way as the BIRD control socket works. You can try it by the attached script (run by root) which uses socat for demonstration. Maria
Yes. Looks like they are accounted in their own network namespace, it is quite reasonable. But they are still can be accessed via the file system from another namespaces. I can confirm that it works too. An example with the bird control socket: localhost:~/run# birdc -s retn/bird.ctl show status BIRD 2.0.4 ready. BIRD 2.0.4 Router ID is 87.245.192.0 Current server time is 2019-06-07 20:47:32.479 Last reboot on 2019-06-07 20:45:17.425 Last reconfiguration on 2019-06-07 20:45:17.425 Daemon is up and running localhost:~/run# ip netns exec retn birdc -s retn/bird.ctl show status BIRD 2.0.4 ready. BIRD 2.0.4 Router ID is 87.245.192.0 Current server time is 2019-06-07 20:47:49.452 Last reboot on 2019-06-07 20:45:17.425 Last reconfiguration on 2019-06-07 20:45:17.425 Daemon is up and running On Fri, Jun 7, 2019 at 10:41 PM Maria Matejka <jan.matejka@nic.cz> wrote:
On 6/7/19 12:14 PM, Maria Jan Matějka wrote:
Thinking once more about it, with respect to the interfaces and so, the BGP transported over Unix socket seems to be quite simple feature to do.
I thought, and my initial tests support, that Unix sockets are network namespace specific.
# netstat -aFunix Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eno1 1500 77564888 0 614 0 66111123 0 0 0 BMRU lo 65536 68143909 0 0 0 68143909 0 0 0 LRU # ip netns add test # ip netns exec test /bin/netstat -aFunix Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg lo 65536 0 0 0 0 0 0 0 0 L # ip netns del test
So, I'm not sure if that's going to work the way that you want.
It will work the same way as the BIRD control socket works. You can try it by the attached script (run by root) which uses socat for demonstration.
Maria
I'm in similar situation. Trying to run Bird on hardware that runs on top of kernel that doesn't support vrf. Not sure if I understand correctly. Not sure how using Linux sockets would allow you to achieve separation between different namespaces? You would still need at least different Bird process, right? On Fri, Jun 7, 2019 at 11:08 PM Alexander Zubkov <green@qrator.net> wrote:
Yes. Looks like they are accounted in their own network namespace, it is quite reasonable. But they are still can be accessed via the file system from another namespaces. I can confirm that it works too. An example with the bird control socket:
localhost:~/run# birdc -s retn/bird.ctl show status BIRD 2.0.4 ready. BIRD 2.0.4 Router ID is 87.245.192.0 Current server time is 2019-06-07 20:47:32.479 Last reboot on 2019-06-07 20:45:17.425 Last reconfiguration on 2019-06-07 20:45:17.425 Daemon is up and running localhost:~/run# ip netns exec retn birdc -s retn/bird.ctl show status BIRD 2.0.4 ready. BIRD 2.0.4 Router ID is 87.245.192.0 Current server time is 2019-06-07 20:47:49.452 Last reboot on 2019-06-07 20:45:17.425 Last reconfiguration on 2019-06-07 20:45:17.425 Daemon is up and running
On Fri, Jun 7, 2019 at 10:41 PM Maria Matejka <jan.matejka@nic.cz> wrote:
On 6/7/19 12:14 PM, Maria Jan Matějka wrote:
Thinking once more about it, with respect to the interfaces and so, the BGP transported over Unix socket seems to be quite simple feature to do.
I thought, and my initial tests support, that Unix sockets are network namespace specific.
# netstat -aFunix Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eno1 1500 77564888 0 614 0 66111123 0 0 0
BMRU
lo 65536 68143909 0 0 0 68143909 0 0 0 LRU # ip netns add test # ip netns exec test /bin/netstat -aFunix Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg lo 65536 0 0 0 0 0 0 0 0 L # ip netns del test
So, I'm not sure if that's going to work the way that you want.
It will work the same way as the BIRD control socket works. You can try it by the attached script (run by root) which uses socat for demonstration.
Maria
-- Kuba Nowacki Senior NetOps M: +(48) 605 508 118 E: jnowacki@greywizard.com GreyWizard Sp. z o.o. ul. Palacza 113 60-273 Poznań, Poland NIP: 779-24-22-423 Regon: 302744400 KRS: 0000512326 greywizard.com support@greywizard.com +48 22 201 33 13 Sąd Rejonowy w Poznaniu, VIII Wydział Gospodarczy Krajowego Rejestru Sądowego. Kapitał zakładowy 10000 PLN.
Yes, different bird processes in each namespace. And if you need to "leak" routes between them for some reason, then you need to connect them somehow to pass routes between processes. There are concerns of course if you want to export those routes into routing table, because of separated interfaces, but at that point you should already know pretty well what dirty things you are trying to do. :) On Wed, Jun 12, 2019 at 3:15 PM Jakub Nowacki <jnowacki@greywizard.com> wrote:
I'm in similar situation. Trying to run Bird on hardware that runs on top of kernel that doesn't support vrf. Not sure if I understand correctly. Not sure how using Linux sockets would allow you to achieve separation between different namespaces? You would still need at least different Bird process, right?
On Fri, Jun 7, 2019 at 11:08 PM Alexander Zubkov <green@qrator.net> wrote:
Yes. Looks like they are accounted in their own network namespace, it is quite reasonable. But they are still can be accessed via the file system from another namespaces. I can confirm that it works too. An example with the bird control socket:
localhost:~/run# birdc -s retn/bird.ctl show status BIRD 2.0.4 ready. BIRD 2.0.4 Router ID is 87.245.192.0 Current server time is 2019-06-07 20:47:32.479 Last reboot on 2019-06-07 20:45:17.425 Last reconfiguration on 2019-06-07 20:45:17.425 Daemon is up and running localhost:~/run# ip netns exec retn birdc -s retn/bird.ctl show status BIRD 2.0.4 ready. BIRD 2.0.4 Router ID is 87.245.192.0 Current server time is 2019-06-07 20:47:49.452 Last reboot on 2019-06-07 20:45:17.425 Last reconfiguration on 2019-06-07 20:45:17.425 Daemon is up and running
On Fri, Jun 7, 2019 at 10:41 PM Maria Matejka <jan.matejka@nic.cz> wrote:
On 6/7/19 12:14 PM, Maria Jan Matějka wrote:
Thinking once more about it, with respect to the interfaces and so, the BGP transported over Unix socket seems to be quite simple feature to do.
I thought, and my initial tests support, that Unix sockets are network namespace specific.
# netstat -aFunix Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eno1 1500 77564888 0 614 0 66111123 0 0 0
BMRU
lo 65536 68143909 0 0 0 68143909 0 0 0 LRU # ip netns add test # ip netns exec test /bin/netstat -aFunix Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg lo 65536 0 0 0 0 0 0 0 0 L # ip netns del test
So, I'm not sure if that's going to work the way that you want.
It will work the same way as the BIRD control socket works. You can try it by the attached script (run by root) which uses socat for demonstration.
Maria
--
Kuba Nowacki
Senior NetOps
M: +(48) 605 508 118
E: jnowacki@greywizard.com
GreyWizard Sp. z o.o.
ul. Palacza 113
60-273 Poznań, Poland
NIP: 779-24-22-423
Regon: 302744400
KRS: 0000512326
greywizard.com
support@greywizard.com
+48 22 201 33 13
Sąd Rejonowy w Poznaniu, VIII Wydział Gospodarczy Krajowego Rejestru Sądowego. Kapitał zakładowy 10000 PLN.
Ok, now I have the whole picture. Having option to exchange routes between multiple BIRD processes on same box (but in different namespaces) would allow to simplify management of configuration. Hoping this could get implemented. For now I believe only viable option is to have completely separated Bird processes with separated configuration files :/ On Wed, Jun 12, 2019 at 3:35 PM Alexander Zubkov <green@qrator.net> wrote:
Yes, different bird processes in each namespace. And if you need to "leak" routes between them for some reason, then you need to connect them somehow to pass routes between processes. There are concerns of course if you want to export those routes into routing table, because of separated interfaces, but at that point you should already know pretty well what dirty things you are trying to do. :)
On Wed, Jun 12, 2019 at 3:15 PM Jakub Nowacki <jnowacki@greywizard.com> wrote:
I'm in similar situation. Trying to run Bird on hardware that runs on top of kernel that doesn't support vrf. Not sure if I understand correctly. Not sure how using Linux sockets would allow you to achieve separation between different namespaces? You would still need at least different Bird process, right?
On Fri, Jun 7, 2019 at 11:08 PM Alexander Zubkov <green@qrator.net> wrote:
Yes. Looks like they are accounted in their own network namespace, it is quite reasonable. But they are still can be accessed via the file system from another namespaces. I can confirm that it works too. An example with the bird control socket:
localhost:~/run# birdc -s retn/bird.ctl show status BIRD 2.0.4 ready. BIRD 2.0.4 Router ID is 87.245.192.0 Current server time is 2019-06-07 20:47:32.479 Last reboot on 2019-06-07 20:45:17.425 Last reconfiguration on 2019-06-07 20:45:17.425 Daemon is up and running localhost:~/run# ip netns exec retn birdc -s retn/bird.ctl show status BIRD 2.0.4 ready. BIRD 2.0.4 Router ID is 87.245.192.0 Current server time is 2019-06-07 20:47:49.452 Last reboot on 2019-06-07 20:45:17.425 Last reconfiguration on 2019-06-07 20:45:17.425 Daemon is up and running
On Fri, Jun 7, 2019 at 10:41 PM Maria Matejka <jan.matejka@nic.cz> wrote:
On 6/7/19 12:14 PM, Maria Jan Matějka wrote:
Thinking once more about it, with respect to the interfaces and so, the BGP transported over Unix socket seems to be quite simple
feature
to do.
I thought, and my initial tests support, that Unix sockets are network namespace specific.
# netstat -aFunix Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eno1 1500 77564888 0 614 0 66111123 0 0 0 BMRU lo 65536 68143909 0 0 0 68143909 0 0 0 LRU # ip netns add test # ip netns exec test /bin/netstat -aFunix Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg lo 65536 0 0 0 0 0 0 0 0 L # ip netns del test
So, I'm not sure if that's going to work the way that you want.
It will work the same way as the BIRD control socket works. You can try it by the attached script (run by root) which uses socat for demonstration.
Maria
--
Kuba Nowacki
Senior NetOps
M: +(48) 605 508 118
E: jnowacki@greywizard.com
GreyWizard Sp. z o.o.
ul. Palacza 113
60-273 Poznań, Poland
NIP: 779-24-22-423
Regon: 302744400
KRS: 0000512326
greywizard.com
support@greywizard.com
+48 22 201 33 13
Sąd Rejonowy w Poznaniu, VIII Wydział Gospodarczy Krajowego Rejestru Sądowego. Kapitał zakładowy 10000 PLN.
-- Kuba Nowacki Senior NetOps M: +(48) 605 508 118 E: jnowacki@greywizard.com GreyWizard Sp. z o.o. ul. Palacza 113 60-273 Poznań, Poland NIP: 779-24-22-423 Regon: 302744400 KRS: 0000512326 greywizard.com support@greywizard.com +48 22 201 33 13 Sąd Rejonowy w Poznaniu, VIII Wydział Gospodarczy Krajowego Rejestru Sądowego. Kapitał zakładowy 10000 PLN.
Yes, BIRD processes in distinct netns's are separated (in context of network) and the suggested change is just to allow BGP session over Unix socket instead of TCP (to allow for route exchange without configuring a link between netns's). Maria On 6/13/19 8:52 AM, Jakub Nowacki wrote:
Ok, now I have the whole picture. Having option to exchange routes between multiple BIRD processes on same box (but in different namespaces) would allow to simplify management of configuration. Hoping this could get implemented. For now I believe only viable option is to have completely separated Bird processes with separated configuration files :/
On Wed, Jun 12, 2019 at 3:35 PM Alexander Zubkov <green@qrator.net <mailto:green@qrator.net>> wrote:
Yes, different bird processes in each namespace. And if you need to "leak" routes between them for some reason, then you need to connect them somehow to pass routes between processes. There are concerns of course if you want to export those routes into routing table, because of separated interfaces, but at that point you should already know pretty well what dirty things you are trying to do. :)
On Wed, Jun 12, 2019 at 3:15 PM Jakub Nowacki <jnowacki@greywizard.com <mailto:jnowacki@greywizard.com>> wrote:
I'm in similar situation. Trying to run Bird on hardware that runs on top of kernel that doesn't support vrf. Not sure if I understand correctly. Not sure how using Linux sockets would allow you to achieve separation between different namespaces? You would still need at least different Bird process, right?
On Fri, Jun 7, 2019 at 11:08 PM Alexander Zubkov <green@qrator.net <mailto:green@qrator.net>> wrote:
Yes. Looks like they are accounted in their own network namespace, it is quite reasonable. But they are still can be accessed via the file system from another namespaces. I can confirm that it works too. An example with the bird control socket:
localhost:~/run# birdc -s retn/bird.ctl show status BIRD 2.0.4 ready. BIRD 2.0.4 Router ID is 87.245.192.0 Current server time is 2019-06-07 20:47:32.479 Last reboot on 2019-06-07 20:45:17.425 Last reconfiguration on 2019-06-07 20:45:17.425 Daemon is up and running localhost:~/run# ip netns exec retn birdc -s retn/bird.ctl show status BIRD 2.0.4 ready. BIRD 2.0.4 Router ID is 87.245.192.0 Current server time is 2019-06-07 20:47:49.452 Last reboot on 2019-06-07 20:45:17.425 Last reconfiguration on 2019-06-07 20:45:17.425 Daemon is up and running
On Fri, Jun 7, 2019 at 10:41 PM Maria Matejka <jan.matejka@nic.cz <mailto:jan.matejka@nic.cz>> wrote: > > > On 6/7/19 12:14 PM, Maria Jan Matějka wrote: > >> Thinking once more about it, with respect to the interfaces and so, > >> the BGP transported over Unix socket seems to be quite simple feature > >> to do. > > > > I thought, and my initial tests support, that Unix sockets are network > > namespace specific. > > > > # netstat -aFunix > > Kernel Interface table > > Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP > > TX-OVR Flg > > eno1 1500 77564888 0 614 0 66111123 0 0 0 BMRU > > lo 65536 68143909 0 0 0 68143909 0 0 0 LRU > > # ip netns add test > > # ip netns exec test /bin/netstat -aFunix > > Kernel Interface table > > Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP > > TX-OVR Flg > > lo 65536 0 0 0 0 0 0 0 > > 0 L > > # ip netns del test > > > > So, I'm not sure if that's going to work the way that you want. > > It will work the same way as the BIRD control socket works. > You can try it by the attached script (run by root) which uses socat for > demonstration. > > Maria
--
Kuba Nowacki
Senior NetOps
M: +(48) 605 508 118
E: jnowacki@greywizard.com <mailto:jnowacki@greywizard.com>
GreyWizard Sp. z o.o.
ul. Palacza 113
60-273 Poznań, Poland
NIP: 779-24-22-423
Regon: 302744400
KRS: 0000512326
greywizard.com <http://greywizard.com>
support@greywizard.com <mailto:support@greywizard.com>
+48 22 201 33 13
Sąd Rejonowy w Poznaniu, VIII Wydział Gospodarczy Krajowego Rejestru Sądowego. Kapitał zakładowy 10000 PLN.
--
Kuba Nowacki
Senior NetOps
M: +(48) 605 508 118
E: jnowacki@greywizard.com <mailto:jnowacki@greywizard.com>
GreyWizard Sp. z o.o.
ul. Palacza 113
60-273 Poznań, Poland
NIP: 779-24-22-423
Regon: 302744400
KRS: 0000512326
greywizard.com <http://greywizard.com>
support@greywizard.com <mailto:support@greywizard.com>
+48 22 201 33 13
Sąd Rejonowy w Poznaniu, VIII Wydział Gospodarczy Krajowego Rejestru Sądowego. Kapitał zakładowy 10000 PLN.
On 6/13/19 5:19 AM, Maria Matejka wrote:
Yes, BIRD processes in distinct netns's are separated (in context of network)
Other namespaces can influence things too.
the suggested change is just to allow BGP session over Unix socket instead of TCP (to allow for route exchange without configuring a link between netns's).
Why limit it to BGP sessions over a Unix socket? Why not allow other IGPs / EGPs over a Unix socket as well? -- Grant. . . . unix || die
On 6/13/19 12:52 AM, Jakub Nowacki wrote:
Ok, now I have the whole picture. Having option to exchange routes between multiple BIRD processes on same box (but in different namespaces) would allow to simplify management of configuration.
I don't understand what Unix sockets provide that a vEth pair can't provide. Yes, the vEth pair would require IPs and neighbor configurations. But I don't see that as a blocker. I would expect that it's possible to apply filters to control what is imported and exported. I would also expect similar filters to be applied to the Unix sockets too. I'm sure there's something that I'm missing. But I don't know what it is. -- Grant. . . . unix || die
On 6/7/19 2:33 PM, Maria Matejka wrote:
It will work the same way as the BIRD control socket works.
Hum. Very intriguing. Upon further investigation, it seems as if my test was flawed. I should have used -A, not -F. Thank you for the proof of concept. Aside: Unix sockets as a cross network namespace communications mechanism is going to have some interesting implications. }:-)
You can try it by the attached script (run by root) which uses socat for demonstration.
Yep. It works as advertised. Thank you! -- Grant. . . . unix || die
On 6/7/19 1:19 AM, Jakub Nowacki wrote:
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?
Maybe indirectly. Do you need bidirectional synchronization of routes / routing tables? How often will the routes / routing tables change?
I've found previous post https://bird.network.cz/pipermail/bird-users/2014-October/009393.html suggesting that only option is to use multiple instances of Bird, each running in different namespace. I was hoping I could just stick to one instance and export routes to different namespaces.
I'm not aware of a way that BIRD itself can do this across network namespaces. But there may still be a way to do it. What would happen if you told BIRD about additional routing tables in the main (default / unnamed) namespace and then used something outside of BIRD to replicate that routing table into a routing table in a different network namespace? Let BIRD do it's thing between main (254) and netns1 (101) / netns2 (102) / netns3 (103). Then you have something scrape the netnsX (10X) routing table in the main (…) namespace and put the routes into the desired routing table, likely main (254), inside the various network namespaces. It may be crude, but I think you could do something as simple as 1) flush the routing table in the network namespace, and then set up a while loop to read lines from the output of "ip route show table netns1" and mung them into an "ip route add …" command inside the network namespace. (Possibly via "ip netns exec netns1 ip route add …".) There's probably room for optimization. Possibly with NetLink or the likes to receive notifications of updates from the kernel and be smarter about adding / removing routes in the (remote) network namespace. -- Grant. . . . unix || die
participants (9)
-
Alexander Zubkov -
bird＠ipv2.de -
Grant Taylor -
Jakub Nowacki -
Maria Jan Matejka -
Maria Jan Matějka
-
Maria Matejka
-
remco van mook -
Toke Høiland-Jørgensen