[194918] in North American Network Operators' Group
Re: Templating/automating configuration
daemon@ATHENA.MIT.EDU (James Bensley)
Wed Jun 7 15:30:14 2017
X-Original-To: nanog@nanog.org
In-Reply-To: <15c83e689c5.b67adcbb317379.1778392953822404155@knight-networks.com>
From: James Bensley <jwbensley@gmail.com>
Date: Wed, 7 Jun 2017 20:29:39 +0100
To: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On 7 June 2017 at 19:52, Brian Knight <ml@knight-networks.com> wrote:
> The import process to the database runs directly on our rancid server, re=
ading the downloaded configs out of the appropriate directory within rancid=
. Most of our gear is Cisco, so the ciscoconfparse module for Python helps =
a lot with organizing and querying the config. From there, the config is p=
arsed for key items like interface name, description, configured bandwidth,=
etc., and that info is then added or updated as necessary in the database.
>
>
>
> Because it's dependent on rancid, there is some lag time between when a c=
hange is made and when the database gets updated, so we still strongly enco=
urage running the pre-config checks for new circuits. But with PyEZ, it lo=
oks like you easily could, after grabbing that lock, validate the existing =
config before pushing down new config. Lots of possibilities there. I'm e=
nvious that you have a vendor-written Python module as a choice!
...
>
> Or, at least, rebuild the existing configs based on the new source of tru=
th, so that subsequent config parsing conforms to a single standard.
Cisco IOS and IOS-XE have config locks on the CLI, as well as
automatic configuration rollbacks and the ability to generate a config
diff on deice. For some reason lots of people seem to forget/ignore
this.
If you are using NAPALM then I believe you can also implement this
through NAPALM.
Cheers,
James.
