Mangement VRF and systemd integration


Hey!

I have noticed the '/etc/vrf/systemd.conf' file which lead to me to the following documentation: https://docs.cumulusnetworks.com/display/DOCS/Management+VRF.

The documentation gives some examples, notably ntp, snmpd and hsflowd. However, it says nothing about ssh. Despite being in '/etc/vrf/systemd.conf', sshd doesn't need to be started as 'ssh@mgmt' to log users in the management context. Using 'vrf task identify', I see the main daemon is in the default VRF while the children spawned on each connections are in the mgmt VRF. Should I use 'ssh@mgmt' instead? Why would SSH not be entirely bound to the mgmt VRF?

I notice that rsyslog is not part of the services and instead, it has been modified to allow specifying a device to bind to. What's the reason of rsyslog not playing nice with VRF? I ask that to identify other services that could have this problem.

I find it cumbersome to have a service for the default VRF and a different service for the mgmt VRF. I understand this gives the user the ability to run the services in any VRF, but it's also easy to make an error and starts the service in the default VRF. I was thinking of running my own copy of 'systemd-vrf-generator' that justs add overrides to the normal name. For example, '/run/systemd/generator/snmpd.service.d/vrf.conf' would have the same content than '/run/systemd/generator/snmpd@.service.d/vrf.conf' except '%I' is already replaced by 'mgmt'. I wonder why you didn't go this road. Maybe there is a difficulty I didn't see?

BTW, this would be interesting to have the functionality integrated in systemd directly. The override would be simpler. It would be similar to the 'JoinsNamespaceOf' directive.

3 replies

Userlevel 3
Programs (including service daemons) running in a VRF, have a different routing table, by definition.
If ssh (or others) ran only in a VRF, then you wouldn't be able to use them for ports that are not in that VRF. Therefore you need multiple instance of a service, for services that are not VRF aware.

Services such as rsyslogd, that are aware of interfaces (at least potentially) need modifications to know about VRFs, and when to use them (or not).

We did look into adding VRF awareness to systemd, in a manner similar to name space awareness.
That requires a newer version of systemd, and we may very well still do that, but not until we move to a newer version of systemd, which may not happen for a while yet.
Dave Olson wrote:

Programs (including service daemons) running in a VRF, have a different routing table, by definit...

For systemd, I wrote a small patch against systemd 215 which adds a "BindToVRF=" directive. I am using it without a generator, by just dropping "/etc/systemd/system/XXXX.service.d/vrf.conf" files with "BindToVRF=mgmt". This way, I can keep the original names and it simplifies the configuration management.

Patch here: https://github.com/systemd/systemd/compare/master...vincentbernat:feature/bindtovrf

Since it's quite specific to Cumulus Linux, I didn't try to adapt it to more recent versions of systemd and to upstream it.
Dave Olson wrote:

Programs (including service daemons) running in a VRF, have a different routing table, by definit...

Hi Vincent:

Thanks for writing the systemd patch. It has been on my To-Do list for a while to write something similar.

In regards to your other questions:

"Should I use 'ssh@mgmt' instead?"

The global service allows 1 daemon to handle all logins regardless of network interface the connections arrives on. Connections through a VRF are bound to the VRF even though the daemon is "global". If desired you can use ssh@mgmt to only allow ssh connections through the management VRF and interface. User's choice.

You asked about rsyslog:

"I notice that rsyslog is not part of the services and instead, it has been modified to allow specifying a device to bind to. What's the reason of rsyslog not playing nice with VRF?"

Ideally all services that use Layer 3 networking are "VRF aware" (or aware of the bind-to-device option) in which case users configure the vrf option for the service. The reality is that few programs support SO_BINDTODEVICE or IP_PKTINFO. The vrf 'helper' (ip vrf exec) was written to run programs in a VRF context to overcome the limitation with the extensive existing code bases. But, the vrf helper has its limitations, especially when programs are started from systemd. rsyslog was one of those programs that was too hard to start in a vrf context using the vrf helper. Since the maintainer for rsyslog is active and receptive to patches, I decided the better return on investment is to add a bind-to-device option to rsyslog.

And your comment about systemd integration:

"I find it cumbersome to have a service for the default VRF and a different service for the mgmt VRF. I understand this gives the user the ability to run the services in any VRF, but it's also easy to make an error and starts the service in the default VRF. I was thinking of running my own copy of 'systemd-vrf-generator' that justs add overrides to the normal name. For example, '/run/systemd/generator/snmpd.service.d/vrf.conf' would have the same content than '/run/systemd/generator/snmpd@.service.d/vrf.conf' except '%I' is already replaced by 'mgmt'. I wonder why you didn't go this road. Maybe there is a difficulty I didn't see?"

We needed a solution that works for all VRF instances, not just the Management VRF. For example, users can deploy multiple dhcrelay instances in different VRFs. The systemd instance capability provides a convenient parameterization where the instance name is the VRF. That allows 1 set of service files to be used for multiple VRFs without having to maintain VRF specific files for services that may not be used. In addition, when a VRF is deleted it is easy to identify services started by systemd and running in the VRF so the services can be shutdown properly.

And finally:
"BTW, this would be interesting to have the functionality integrated in systemd directly."

That is the long term objective. There are a lot of details and it takes time. Your systemd patch certainly helps. Thanks.

Reply