On 7 June 2017 at 00:43, Vincent Bernat <bernat@luffy.cx> wrote:
❦ 6 juin 2017 14:30 +0100, Oliver Elliott <Oliver.Elliott@bristol.ac.uk> :
I echo Ansible. I'm using it with NAPALM and jinja2 templates to push and verify config on switches.
Why not using the builtin ability of ansible for most vendors? (genuine question)
http://docs.ansible.com/ansible/list_of_network_modules.html
One reason, which is our reason for using NAPALM with Ansible, is that the built in Ansible modules often just edit certain lines of config in the target device. For example, the Cisco IOS module within Ansible scans the device config for say the line starting with "Interface Etherernet 1/1" and then I tell it to ensure the lines " ip vrf customer A" and " ip address x.x.x.x n.n.n.n" are under the search line. It's OK but its text matching and not fool proof. It also doesn't help me to guarantee the state of our tin (I might push an update to one interface on a device and simultaneously someone else might pushes an update to a different interface, our respective views of the device config might not include each other’s updates). We use the NAPALM module although it needs to be a bit more than just NAPALM, its not a panacea. We generate a full device config (even for a one line interface update) and push that into atomic storage (git), when then pass that file from git to NAPALM. NAPALM will copy the file to the device and do a full config replace for us, and we can get a diff from before and after that process and report that back and ensure that exactly what we wanted to change has been changed only. All changes come through git which act’s like a queue meaning that if two people make simultaneous updates to different interfaces there’ll be a git commit/push error. [1] Cheers, James. [1] That’s the plan at least, the reality though is that vendor bugs are plentiful.