Automation: Dealing with Vendor-Specific Configuration Keywords

One of the students in our Building Network Automation Solutions online course asked an interesting question:

I’m building an IPsec multi-vendor automation solution and am now facing the challenge of vendor-specific parameter names. For example, to select the AES-128 algorithm, Juniper uses ‌aes-128-cbc, Arista aes128, and Checkpoint AES-128.

I guess I need a kind of Rosetta stone to convert the IKE/IPSEC parameters from a standard parameter to a vendor-specific one. Should I do that directly in the Jinja2 template, or in the Ansible playbook calling the template?

Both options are awkward. It would be best to have a lookup table mapping parameter values from the data model into vendor-specific keywords, for example:

aes:
  junos: aes-128-cbc
  eos: aes128-gcm-xpn
  checkpoint: AES-128

You could then read that lookup table into an Ansible variable (let’s call it rosetta) with include_vars module, and use it in Jinja2 templates. For example, to select the vendor-specific cipher name, use…

{{ rosetta[cipher][ansible_network_os] }}

… in a Jinja2 template, assuming the cipher name is in variable cipher and your inventory consistently sets ansible_network_os for every device where you want to have IPsec/MACsec configured.

You could optimize this idea as much as you wish. For example, assuming you created Ansible inventory groups based on device operating system, you could save the vendor-specific attributes in group_vars.

1 comments:

  1. ... or to avoid cluttering your "view" (i.e. the config lines) with logic, put the vendor specific items into a vendor specific config snippet/template file with a descriptive name and let the code/playbook/logic select the right file(s).

    As always: it depends :) E.g. how many different vendor specific keyworks and lines do you need, and do you really need to support the plethora of permutations for crypto algs, or are you allowed a certain opinionated model.

Add comment
Sidebar