On 7 June 2017 at 00:43, Vincent Bernat <ber...@luffy.cx> wrote:
>  ❦  6 juin 2017 14:30 +0100, Oliver Elliott <oliver.elli...@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]


[1] That’s the plan at least, the reality though is that vendor bugs
are plentiful.

Reply via email to