FRR: Load VRF kernel module upon initial startup, disable use of vrfs when not available

[jbemmel]

Fixes https://github.com/ipspace/netlab/issues/1209

[ipspace]

Love the idea. However:

• Ideally, we'd fix this in the FRR quirks. Also, solving it in the FRR quirks would stop netlab up early enough if FRR uses vrf module instead of crashing the Ansible playbook.
• modprobe can be executed as non-root but will fail if it needs to load the driver. As the vrf driver is loaded if installed, this shouldn't be a big deal.
• I would deal with the VRF module separately (in the VRF configuration task list if we solve it in Ansible, or as part of FRR quirks).

Finally:

• run_once is implemented by executing the task on a single node, which means that the netlab_mgmt_vrf would be set only for that node.

So, I would propose to add the "modprobe" call to FRR quirks and act on that. It would also be easier to cache the results there (ensuring we only call modprobe once). I could add that if you wish (but not before tomorrow or so).

[ipspace]

... also, if we just want to test whether the VRF module is loaded, looking for 'vrf' in lsmod printout is a better alternative.

[jbemmel]

Finally:

• run_once is implemented by executing the task on a single node, which means that the netlab_mgmt_vrf would be set only for that node.

I tested for that, actually. The modprobe runs once, but the failure handler runs for every frr node :)

[jbemmel]

... also, if we just want to test whether the VRF module is loaded, looking for 'vrf' in lsmod printout is a better alternative.

I checked that the vrf kernel module is loaded automatically on demand when one issues the ip link ... type vrf command. So it not being loaded doesn't mean that it won't work

[ipspace]

• run_once is implemented by executing the task on a single node, which means that the netlab_mgmt_vrf would be set only for that node.

I tested for that, actually. The modprobe runs once, but the failure handler runs for every frr node :)

That's REALLY NICE to know (thanks a million), I'm just worried that the behavior might change in another Ansible release.

Anyway, should we go down this path or implement a quirk? Using a quirk would give us more control earlier in the process, and the ability to generate a warning.

[jbemmel]

Anyway, should we go down this path or implement a quirk? Using a quirk would give us more control earlier in the process, and the ability to generate a warning.

I modeled it after what we're doing for the mpls kernel modules, I think this is similar and consistent. I do agree that the vrf module case is different and should be checked for and aborted earlier in the process, with a decent warning

The 'initial' config can work with or without management vrf

[ipspace]

Anyway, should we go down this path or implement a quirk? Using a quirk would give us more control earlier in the process, and the ability to generate a warning.

I modeled it after what we're doing for the mpls kernel modules, I think this is similar and consistent.

To be fair, we probably added the MPLS hack before implementing device quirks ;)

I do agree that the vrf module case is different and should be checked for and aborted earlier in the process, with a decent warning

We have to be consistent and do one or the other for the VRF and the MPLS modules.

The 'initial' config can work with or without management vrf

... but it would be nice to know that we turned the management VRF off ;)

Anyway, will merge this one as-is and then work on a more generic solution. Thank you!