how to make FRR know about configured netns on a centos system?
Hi all, I have a centos7 system with netns pre-created and populated with an interface: $ sudo ip netns exec ns-data ip -4 -br a lo UNKNOWN 127.0.0.1/8 eth1 UP 192.168.1.101/24 Whereas my base routing instance has a management interface: $ ip -4 -br a lo UNKNOWN 127.0.0.1/8 eth0 UP 10.0.0.101/24 I want to run vtysh and be able to navigate/configure these VRFs, but I cant see the ns-data VRF even if I launch vtysh in that namespace. [centos@pc1 ~]$ sudo vtysh pc1.nuage.lab# show interface Interface eth0 is up, line protocol is up Link ups: 0 last: (never) Link downs: 0 last: (never) vrf: Default-IP-Routing-Table index 2 metric 0 mtu 1500 speed 4294967295 flags: <UP,BROADCAST,RUNNING,MULTICAST> Type: Ethernet HWaddr: fa:16:3e:28:67:f8 inet 10.0.0.101/24 broadcast 10.0.0.255 inet6 fe80::f816:3eff:fe28:67f8/64 Interface Type Other Interface lo is up, line protocol is up Link ups: 0 last: (never) Link downs: 0 last: (never) vrf: Default-IP-Routing-Table index 1 metric 0 mtu 65536 speed 0 flags: <UP,LOOPBACK,RUNNING> Type: Loopback Interface Type Other pc1.nuage.lab# show vrf vrf ns-data inactive If I try to create a VRF with a namespace name mathing my existing netns, I got this error: pc1.nuage.lab(config)# vrf ns-data pc1.nuage.lab(config-vrf)# netns ns-data % [ZEBRA] Unknown command: netns ns-data What am I doing wrong here? -- BR, Roman Dodin
Hi Roman, depending on what you want to do, there are 2 different approaches to network namespaces with FRR: (a) using them to implement VRFs and have FRR be aware of them (b) using them to implement virtual routers and run FRR inside of them For a management interface separation -- where you don't need any interaction between the management and routing netns -- I would suggest you do (b). Now, unfortunately the standard init scripts won't start FRR in a network namespace for you. You'll have to wire that up for yourself. But on the other hand, after that's done you just have a "normal" FRR installation and don't need to deal with VRFs. If you want to run more than one FRR "virtual router", you can use the `-N` option. In that case each netns runs the full set of all daemons. If you want to do (a), there is the `--vrfwnetns` option to pass to zebra at startup, but I don't actually know the details on this since I haven't run such a setup. [https://frrouting.readthedocs.io/en/latest/zebra.html#cmdoption-zebra-n] Lastly, if you want to use Linux kernel VRF support, that works by creating "vrf" type devices inside the 1 network namespace. Cheers, -David
Thanks David! Indeed I use a namespace to isolate the management interface of a centos system from the data namespace which needs to run bgpd and ospfd You said there is no provided way to run frr services in a non default namespace and one needs to wire that themselves. But since this seems like a very common approach to follow (separating management domain from others), how does the community deal with it? Any examples maybe? Thanks for you help вс, 28 окт. 2018 г., 0:06 David Lamparter <equinox@diac24.net>:
Hi Roman,
depending on what you want to do, there are 2 different approaches to network namespaces with FRR:
(a) using them to implement VRFs and have FRR be aware of them (b) using them to implement virtual routers and run FRR inside of them
For a management interface separation -- where you don't need any interaction between the management and routing netns -- I would suggest you do (b).
Now, unfortunately the standard init scripts won't start FRR in a network namespace for you. You'll have to wire that up for yourself. But on the other hand, after that's done you just have a "normal" FRR installation and don't need to deal with VRFs. If you want to run more than one FRR "virtual router", you can use the `-N` option. In that case each netns runs the full set of all daemons.
If you want to do (a), there is the `--vrfwnetns` option to pass to zebra at startup, but I don't actually know the details on this since I haven't run such a setup. [https://frrouting.readthedocs.io/en/latest/zebra.html#cmdoption-zebra-n]
Lastly, if you want to use Linux kernel VRF support, that works by creating "vrf" type devices inside the 1 network namespace.
Cheers,
-David
On Sun, Oct 28, 2018 at 10:25:05AM +0300, Roman Dodin wrote:
Thanks David! Indeed I use a namespace to isolate the management interface of a centos system from the data namespace which needs to run bgpd and ospfd
You said there is no provided way to run frr services in a non default namespace and one needs to wire that themselves. But since this seems like a very common approach to follow (separating management domain from others), how does the community deal with it? Any examples maybe?
We had a discussion about this a few weeks ago where I think the consensus was that we should add the "-N" parameter to watchfrr and the init script. At this point this is a missing-feature bug that needs fixing :) My personal setup is a bit aged and outdated so I kinda don't want to share it since it should be done differently nowadays, mostly because I don't use watchfrr. I have 2 init scripts, one that has a lot of iproute2 calls to set all the devices up, and the other one to start FRR. Then I just start the daemons individually like this: svcs="polyeidos:ospfd polyeidos:ospf6d polynices:ospfd polynices:ospf6d polyeidos:bgpd" start() { # zebra has already been started! for I in $svcs; do ns="${I%:*}" dm="${I#*:}" pid=`pgrep -f "zebra -N $ns"` ebegin "Starting netns routing - $ns($pid)/$dm" nsenter -m -n -t $pid start-stop-daemon --quiet --start --exec /usr/lib/frr/$dm \ --pidfile /run/frr/$ns/$dm.pid -- -N $ns -A ::1 -d eend $? done } Note that there is a little bit of trickery going on there with "nsenter" instead of "ip netns exec". The reason for this is simple: "ip netns exec" creates a new mount namespace every time it is executed. It uses the existing network namespace, but *always* creates a mount namespace so it can mount /sys properly (and bind-mount some config files in /etc.) This leads to a lot of mount namespaces existing and on my setup caused problems with mount propagation / unmounting and remounting things. So I decided to make "zebra" the "owner" of the namespace and always use "nsenter" so I get the same mount namespace. It's probably not relevant for you but I want to mention this here for other people and/or if someone finds these mails by googling "FRR netns" :D (This is maybe something that should be fixed in iproute2.) To do things "better", we should have the -N option on watchfrr, and then watchfrr can be the "owner" of the namespace maybe... That said, if you only have one namespace where FRR is running you don't need the -N option. You could simply do a "ip netns exec NAMESPACE watchfrr <watchfrr options>". Editing the existing init script should work fine for that, you can put "ip netns exec" (or "nsenter") before the start-stop-daemon calls and everything works out. In all cases, you need something to create and set up your network namespace with the proper devices and so on... that's not something we can do in a generic way in a FRR init script. Cheers, -David
participants (2)
-
David Lamparter -
Roman Dodin