[194905] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Templating/automating configuration

daemon@ATHENA.MIT.EDU (tim@pelican.org)
Wed Jun 7 05:23:37 2017

X-Original-To: nanog@nanog.org
Date: Wed, 7 Jun 2017 10:23:33 +0100 (BST)
From: "tim@pelican.org" <tim@pelican.org>
To: "Brian Knight" <ml@knight-networks.com>
In-Reply-To: <15c7f2a5774.1172f0fe6152890.1660807234594437578@knight-networks.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org

Hi Brian,=0A=0AOn Tuesday, 6 June, 2017 21:48, "Brian Knight" <ml@knight-ne=
tworks.com> said:=0A=0A> Because we had different sources of truth which we=
re written in-house, we wound up=0A> rolling our own template engine in Pyt=
hon. It took about 3 weeks to write the=0A> engine and adapt existing templ=
ates.  Given a circuit ID, it generates the full=0A> config for copy and pa=
ste into a terminal session.  It also hooks into a=0A> configuration parser=
 tool, written in-house, that tracks configured interfaces, so=0A> it is ea=
sy to see whether the template would overwrite an existing interface.=0A=0A=
Interesting.  I'm going through much the same process at the moment, due to=
 similar requirements - multiple sources of truth, validation that there's =
no clash with existing configs, but also with a requirement for network-wid=
e atomic operations.  The latter has been a strong driver for a custom tool=
 - it's now grabbing an exclusive lock on all the devices, making all the c=
hecks, pushing all the config, commit check everywhere, commit everywhere, =
and only once all the commits succeed, release the locks.  If any of those =
steps fail anywhere, we get to roll back everywhere.  (Obviously with appro=
priate timeouts / back-offs / deadlock prevention, and specific to platform=
s with sane config management - no vanilla IOS).=0A=0ADid you find anything=
 to give you a leg-up on config parsing, or did you have to do that complet=
ely from scratch?  At the moment, I'm working with PyEZ (I know, vendor loc=
k-in, but we're firmly a Juniper shop, and going in eyes-open to the lock-i=
n) to build a limited model of just the parts of the config I'm interested =
in validating, and it seems to be working.=0A=0A> If I had a free hand and =
unlimited budget, I would find a single app that=0A> functions as a source =
of truth for all circuits and products, which includes a=0A> templating eng=
ine that hooks in easily.=0A=0APlus the business buy-in and the resource to=
 go back and standardise all the existing configs, so the application can f=
ully parse and understand the network before it starts.  That, and a pony :=
)=0A=0ARegards,=0ATim.=0A


home help back first fref pref prev next nref lref last post