Replacing part of the config in a single commit with load/merge


We have several VyOS VMs running as firewalls in our network, with quite large rulesets that are configured by automated processes. We are thinking in moving to a config-as-code architecture where we would keep each ruleset in a code repository, and push it to the VyOS when there is any change.

I checked which would be the best way to upload and install the ruleset in the VyOS using load/merge, but I find some difficulties:

  • Merge: Allows loading a partial config (such as the firewall branch of the config), but it merges with the existing ruleset, doesn’t replace it. If I delete the firewall branch and then merge, I get an error stating that you cannot merge with uncommited changes. This means I would have to do two commits, one for deleting the actual ruleset, and another to load the new one. It would take more time, and would leave the firewall unprotected inbetween.
  • Load: Doesn’t seem to support a partial load. If I load a ruleset config file, it deletes the rest of the VyOS config. I would have to do an extra step to merge the ruleset config file from the code repository with a static config file containing the rest of the VyOS config.

At this point, the second option, although not optimal, looks to me like the only feasible way, but I would like to know if somebody else has faced this, or if there are any other options to approach replacing part of a VyOS configuration.


IMO VyOS should replicate the JunOS model with loading configuration from: load factory-default | merge | override | patch | replace | set | update

Depending on context, you can use different keywords. Sometimes you want to merge with existing config. Sometimes you want to replace complete subconfig, and sometimes you want to only override.
JunOS also supports “patch” (like diff) config, so you can delete and set config in command in the style you see when you run “compare”.
All of these have different use cases, and are very nice to use when automating.
VyOS is lacking a lot of logic in this area unfortunately

But I suppose there is A LOT of work to be done to get it working as nice as junos has it.

This is in development: