Re: Templating/automating configuration

[Jimmy Hess]

On Wed, Jun 14, 2017 at 3:55 PM, Job Snijders  wrote:
> On Wed, Jun 14, 2017 at 09:35:59PM +0100, Nick Hilliard wrote:
>> Graham Johnston wrote:
>> > Would you be able to provide any further insight into your Don’t #5 –
>> > “Don’t agree to change management. Managers are rarely engineers and
>> > should not be making technical decisions. (nor should sales)“.
>>
>> What do you think the purpose of change control / management is?
>
> well, http://dilbert.com/strip/1995-05-29

> On Wed, Jun 14, 2017 at 09:35:59PM +0100, Nick Hilliard wrote:
>> What do you think the purpose of change control / management is?

Bureaucratic change control implementations using the ITIL view
of change control with a formal CAB are likely an (over)reaction
to human mistakes causing outages,  most of which could probably
be avoided  with a simpler  less-formal process such as peer or
team review.

Change control functions as a risk transfer away from operations teams to
CAB board members,   since if things go wrong b/c of a change: it is now
the CAB's fault.There may also be bias towards change-aversity
if the CAB cannot be held accountable for issues that come from
delaying or rejecting  important maintenance.

Overall purpose for change control / management,  when applied to  substantial
modifications to an operating environment or configuration of
business-critical network/applications is

To mitigate possibility of damage/outages from high-impact / high-risk
changes made by humans to systems and network-devices by
requiring standards of formal written documentation and  planning,
combined with  peer review And approvals by business and technical
stakeholders for the maintenance time,  including evaluation  of
exact proposed configuration changes,   implementation plans,
and backout/contingency plan:   for  possible errors or omissions.


But as with most things
can be taken to an unreasonable extreme.

The use of change management procedures has a high
associated cost, b/c the time and labor to implement
even simple relatively low-risk changes can be dramatically
increased with an unreasonable delay,  and extensive test labs
may be necessary.There may actually be increases in
various risks,  if any kind of maintenance is delayed or
lost in the paperwork.

-- 
-JH

Re: Templating/automating configuration

[Mike Meredith]

On Wed, 14 Jun 2017 21:35:59 +0100, Nick Hilliard  may
have written:
> What do you think the purpose of change control / management is?

To provide employment for change managers of course.

-- 
Mike Meredith, University of Portsmouth
Chief Systems Engineer, Hostmaster, Security, and Timelord!
 


pgpcohqknZUzV.pgp
Description: OpenPGP digital signature

Re: Templating/automating configuration

[Job Snijders]

On Wed, Jun 14, 2017 at 09:35:59PM +0100, Nick Hilliard wrote:
> Graham Johnston wrote:
> > Would you be able to provide any further insight into your Don’t #5 –
> > “Don’t agree to change management. Managers are rarely engineers and
> > should not be making technical decisions. (nor should sales)“.
> 
> What do you think the purpose of change control / management is?

well, http://dilbert.com/strip/1995-05-29

Re: Templating/automating configuration

[Nick Hilliard]

Graham Johnston wrote:
> Would you be able to provide any further insight into your Don’t #5 –
> “Don’t agree to change management. Managers are rarely engineers and
> should not be making technical decisions. (nor should sales)“.

What do you think the purpose of change control / management is?

Nick

Re: Templating/automating configuration

['Job Snijders']

Hi Graham,

The talk was giving in context of motivating people to start with
network automation and help them go from 'no automation' to a step
further 'some automation'.

On Wed, Jun 14, 2017 at 07:50:05PM +, Graham Johnston wrote:
> Would you be able to provide any further insight into your Don’t #5 –
> “Don’t agree to change management. 

I think the development team of the network automation software should
define their own process around change management. If you want to use
kanban? great! if you want to use simple fifo model applied to issues
filed on your private github project? great! My point was: don't let
someone from higher up dictate how, and when you do software releases.

Another aspect is that you most likely will have proceses that should
run without any human intervention: such as the nightly update for all
EBGP prefix-filters. You don't want to end up in a situation where a
computer generates those configs and has to hand them over to a human
for some additional checks and subsequently pushing it out to the
network. Imagine having the computer print out your automatically
generated configs, a human pick them up, review them, and type them back
into a computer for the changes to take effect! That would be terrible.

> Managers are rarely engineers and should not be making technical
> decisions. (nor should sales)“.

That was a simple point: ideally a manager enables you to do your work,
and trusts you to do the work. If you have a manager who opinionatedly
argues with you on tabs vs spaces or how to push a configuration to a
device, you might find that you don't have enough freedom of movement to
succesfully bootstrap the automation project.

In other words: don't roll over and blindly accept what other
(inexperienced) folks within the organisation tell you, try to find your
own path. However, do make sure you steal the good ideas from the
sysadmins: they often are ahead of netops in terms of automation and
understanding idempotency.

Kind regards,

Job

RE: Templating/automating configuration

[Graham Johnston]

Job,

Would you be able to provide any further insight into your Don’t #5 – “Don’t 
agree to change management. Managers are rarely engineers and should not be 
making technical decisions. (nor should sales)“.

Thanks,
Graham

From: Job Snijders [mailto:j...@ntt.net]
Sent: Tuesday, June 6, 2017 4:03 PM
To: Brian Knight <m...@knight-networks.com>; Graham Johnston 
<johnst...@westmancom.com>
Cc: nanog@nanog.org
Subject: Re: Templating/automating configuration

Hi,

Here are some extra pointers:

https://youtube.com/watch?v=C7pkab8n7ys

https://www.nanog.org/sites/default/files/dosdontsnetworkautomation.pdf

https://github.com/coloclue/kees

Kind regards,

Job


On Tue, 6 Jun 2017 at 13:49, Brian Knight 
<m...@knight-networks.com<mailto:m...@knight-networks.com>> wrote:
Because we had different sources of truth which were written in-house, we wound 
up rolling our own template engine in Python. It took about 3 weeks to write 
the engine and adapt existing templates.  Given a circuit ID, it generates the 
full config for copy and paste into a terminal session.  It also hooks into a 
configuration parser tool, written in-house, that tracks configured interfaces, 
so it is easy to see whether the template would overwrite an existing interface.



I used the Jinja2 template engine, along with pyodbc/unixODBC/FreeTDS for 
access to a Microsoft SQL backend.



The keys for us are:



* extracting information from a source of truth

* validating the information for correctness

* making sure you don't overwrite existing config

* outputting the right templates for the circuit features



It made more sense to write a tool than it did to try to adapt something for 
our environment.



If I had a free hand and unlimited budget, I would find a single app that 
functions as a source of truth for all circuits and products, which includes a 
templating engine that hooks in easily.



-Brian





 On Tue, 06 Jun 2017 08:22:59 -0500 Graham Johnston 
johnst...@westmancom.com<mailto:lt%3bjohnst...@westmancom.com> wrote 












Short of complete SDN, for those of you that have some degree of configuration 
templating and/or automation tools what is it that you run? I'm envisioning 
some sort of tool that let's me define template snippets of configuration and 
aids in their deployment to devices. I'm okay doing the heaving lifting in 
defining everything, I'm just looking for the tool that stitches it together 
and hopefully makes things a little less error prone for those who aren't as 
adept.



Graham Johnston

Network Planner

Westman Communications Group

204.717.2829

johnst...@westmancom.com<mailto:johnst...@westmancom.com>mailto:johnst...@westmancom.com<mailto:johnst...@westmancom.com>

Re: Templating/automating configuration

[Gordon Cook]

agree
 again all of  the above
 
thanks
> On Jun 11, 2017, at 7:58 PM, Gordon Cook  wrote:
> 
> again  I understand and agree
> 
> 
> 
> the reach of your drowning analysis and understanding is awesome
> 
> hi randy bush
> 
> 
> oops and hi jp confused of calcutta and chris locke rage boy  
> 
>> On Jun 7, 2017, at 6:17 PM, Andrew Dampf  wrote:
>> 
>> Salt is great for generating configs based on jinja templates, and you can
>> use napalm in conjunction with salt to push the configs to the device on a
>> set schedule (typically this is done hourly). If manual changes are made to
>> the router, salt would override them on the next run, so it's a great way
>> to make sure configs are consistent.
>> 
>> 
>> On Tue, Jun 6, 2017 at 9:25 AM Graham Johnston 
>> wrote:
>> 
>>> Short of complete SDN, for those of you that have some degree of
>>> configuration templating and/or automation tools what is it that you run?
>>> I'm envisioning some sort of tool that let's me define template snippets of
>>> configuration and aids in their deployment to devices. I'm okay doing the
>>> heaving lifting in defining everything, I'm just looking for the tool that
>>> stitches it together and hopefully makes things a little less error prone
>>> for those who aren't as adept.
>>> 
>>> Graham Johnston
>>> Network Planner
>>> Westman Communications Group
>>> 204.717.2829 <(204)%20717-2829>
>>> johnst...@westmancom.com
>>> 
>>> 
>> 
> 
> 

Re: Templating/automating configuration

[Gordon Cook]

again  I understand and agree



the reach of your drowning analysis and understanding is awesome

hi randy bush


oops and hi jp confused of calcutta and chris locke rage boy  

> On Jun 7, 2017, at 6:17 PM, Andrew Dampf  wrote:
> 
> Salt is great for generating configs based on jinja templates, and you can
> use napalm in conjunction with salt to push the configs to the device on a
> set schedule (typically this is done hourly). If manual changes are made to
> the router, salt would override them on the next run, so it's a great way
> to make sure configs are consistent.
> 
> 
> On Tue, Jun 6, 2017 at 9:25 AM Graham Johnston 
> wrote:
> 
>> Short of complete SDN, for those of you that have some degree of
>> configuration templating and/or automation tools what is it that you run?
>> I'm envisioning some sort of tool that let's me define template snippets of
>> configuration and aids in their deployment to devices. I'm okay doing the
>> heaving lifting in defining everything, I'm just looking for the tool that
>> stitches it together and hopefully makes things a little less error prone
>> for those who aren't as adept.
>> 
>> Graham Johnston
>> Network Planner
>> Westman Communications Group
>> 204.717.2829 <(204)%20717-2829>
>> johnst...@westmancom.com
>> 
>> 
> 

Re: Templating/automating configuration

[Andrew Dampf]

Salt is great for generating configs based on jinja templates, and you can
use napalm in conjunction with salt to push the configs to the device on a
set schedule (typically this is done hourly). If manual changes are made to
the router, salt would override them on the next run, so it's a great way
to make sure configs are consistent.


On Tue, Jun 6, 2017 at 9:25 AM Graham Johnston 
wrote:

> Short of complete SDN, for those of you that have some degree of
> configuration templating and/or automation tools what is it that you run?
> I'm envisioning some sort of tool that let's me define template snippets of
> configuration and aids in their deployment to devices. I'm okay doing the
> heaving lifting in defining everything, I'm just looking for the tool that
> stitches it together and hopefully makes things a little less error prone
> for those who aren't as adept.
>
> Graham Johnston
> Network Planner
> Westman Communications Group
> 204.717.2829 <(204)%20717-2829>
> johnst...@westmancom.com
>
>

Re: Templating/automating configuration

[James Bensley]

On 7 June 2017 at 19:52, Brian Knight  wrote:
> The import process to the database runs directly on our rancid server, 
> reading 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 parsed 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 
> change is made and when the database gets updated, so we still strongly 
> encourage running the pre-config checks for new circuits.  But with PyEZ, it 
> looks like you easily could, after grabbing that lock, validate the existing 
> config before pushing down new config.  Lots of possibilities there.  I'm 
> envious that you have a vendor-written Python module as a choice!
...
>
> Or, at least, rebuild the existing configs based on the new source of truth, 
> 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.

Re: Templating/automating configuration

[Brian Knight]

 On Wed, 07 Jun 2017 04:23:33 -0500 t...@pelican.org wrote 




Hi Brian,



On Tuesday, 6 June, 2017 21:48, "Brian Knight" m...@knight-networks.com 
said:



 Because we had different sources of truth which were written in-house, we 
wound up

 rolling our own template engine in Python. It took about 3 weeks to write 
the

 engine and adapt existing templates. Given a circuit ID, it generates the 
full

 config for copy and paste into a terminal session. It also hooks into a

 configuration parser tool, written in-house, that tracks configured 
interfaces, so

 it is easy to see whether the template would overwrite an existing 
interface.



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-wide 
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 checks, 
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 appropriate timeouts 
/ back-offs / deadlock prevention, and specific to platforms with sane config 
management - no vanilla IOS).





Did you find anything to give you a leg-up on config parsing, or did you have 
to do that completely from scratch? At the moment, I'm working with PyEZ (I 
know, vendor lock-in, but we're firmly a Juniper shop, and going in eyes-open 
to the lock-in) to build a limited model of just the parts of the config I'm 
interested in validating, and it seems to be working.





The import process to the database runs directly on our rancid server, reading 
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 parsed 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 change 
is made and when the database gets updated, so we still strongly encourage 
running the pre-config checks for new circuits.  But with PyEZ, it looks like 
you easily could, after grabbing that lock, validate the existing config before 
pushing down new config.  Lots of possibilities there.  I'm envious that you 
have a vendor-written Python module as a choice!





 If I had a free hand and unlimited budget, I would find a single app that

 functions as a source of truth for all circuits and products, which 
includes a

 templating engine that hooks in easily.



Plus the business buy-in and the resource to go back and standardise all the 
existing configs, so the application can fully parse and understand the network 
before it starts. That, and a pony :)





Or, at least, rebuild the existing configs based on the new source of truth, so 
that subsequent config parsing conforms to a single standard.



Regards,

Tim.









Cheers,



-Brian

Re: Templating/automating configuration

[t...@pelican.org]

Hi Brian,

On Tuesday, 6 June, 2017 21:48, "Brian Knight"  said:

> Because we had different sources of truth which were written in-house, we 
> wound up
> rolling our own template engine in Python. It took about 3 weeks to write the
> engine and adapt existing templates.  Given a circuit ID, it generates the 
> full
> config for copy and paste into a terminal session.  It also hooks into a
> configuration parser tool, written in-house, that tracks configured 
> interfaces, so
> it is easy to see whether the template would overwrite an existing interface.

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-wide 
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 checks, 
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 appropriate timeouts 
/ back-offs / deadlock prevention, and specific to platforms with sane config 
management - no vanilla IOS).

Did you find anything to give you a leg-up on config parsing, or did you have 
to do that completely from scratch?  At the moment, I'm working with PyEZ (I 
know, vendor lock-in, but we're firmly a Juniper shop, and going in eyes-open 
to the lock-in) to build a limited model of just the parts of the config I'm 
interested in validating, and it seems to be working.

> If I had a free hand and unlimited budget, I would find a single app that
> functions as a source of truth for all circuits and products, which includes a
> templating engine that hooks in easily.

Plus the business buy-in and the resource to go back and standardise all the 
existing configs, so the application can fully parse and understand the network 
before it starts.  That, and a pony :)

Regards,
Tim.

Re: Templating/automating configuration

[James Bensley]

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

Re: Templating/automating configuration

[Vincent Bernat]

 ❦  6 juin 2017 14:30 +0100, Oliver Elliott  :

> 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
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Templating/automating configuration

[Oliver Elliott]

I echo Ansible. I'm using it with NAPALM and jinja2 templates to push and
verify config on switches.

Oli

On 6 June 2017 at 14:27, Pui Edylie  wrote:

> Hi,
>
> Take a look at Ansible
>
> https://www.ansible.com/
>
> Our whole infra is automated using it and it is great!
>
> Regards,
> Edy
>
>
>
> On 6/6/2017 9:22 PM, Graham Johnston wrote:
>
>> Short of complete SDN, for those of you that have some degree of
>> configuration templating and/or automation tools what is it that you run?
>> I'm envisioning some sort of tool that let's me define template snippets of
>> configuration and aids in their deployment to devices. I'm okay doing the
>> heaving lifting in defining everything, I'm just looking for the tool that
>> stitches it together and hopefully makes things a little less error prone
>> for those who aren't as adept.
>>
>> Graham Johnston
>> Network Planner
>> Westman Communications Group
>> 204.717.2829
>> johnst...@westmancom.com
>>
>>
>>
>
>


-- 
Oliver Elliott
Senior Network Specialist
IT Services, University of Bristol
t: 0117 39 (41131)

Re: Templating/automating configuration

[Alexis Letessier]

Go templates: http://golang.org  Fast and simple with gRPC 
and other good stuff like kelsey’s confd (a daemon that watches for changes and 
update templates)

% go doc text/template
package template // import "text/template"

Package template implements data-driven templates for generating textual
output.

To generate HTML output, see package html/template, which has the same
interface as this package but automatically secures HTML output against
certain attacks.

Templates are executed by applying them to a data structure. Annotations in
the template refer to elements of the data structure (typically a field of a
struct or a key in a map) to control execution and derive values to be
displayed. Execution of the template walks the structure and sets the
cursor, represented by a period '.' and called "dot", to the value at the
current location in the structure as execution proceeds.

The input text for a template is UTF-8-encoded text in any format.
"Actions"--data evaluations or control structures--are delimited by "{{" and
"}}"; all text outside actions is copied to the output unchanged. Except for
raw strings, actions may not span newlines, although comments can.

Once parsed, a template may be executed safely in parallel.

Here is a trivial example that prints "17 items are made of wool".

type Inventory struct {
Material string
Countuint
}
sweaters := Inventory{"wool", 17}
tmpl, err := template.New("test").Parse("{{.Count}} items are made of 
{{.Material}}")
if err != nil { panic(err) }
err = tmpl.Execute(os.Stdout, sweaters)
if err != nil { panic(err) }

Alexis

> On 6 Jun 2017, at 15:22, Graham Johnston  wrote:
> 
> Short of complete SDN, for those of you that have some degree of 
> configuration templating and/or automation tools what is it that you run? I'm 
> envisioning some sort of tool that let's me define template snippets of 
> configuration and aids in their deployment to devices. I'm okay doing the 
> heaving lifting in defining everything, I'm just looking for the tool that 
> stitches it together and hopefully makes things a little less error prone for 
> those who aren't as adept.
> 
> Graham Johnston
> Network Planner
> Westman Communications Group
> 204.717.2829
> johnst...@westmancom.com
> 

Re: Templating/automating configuration

[Job Snijders]

Hi,

Here are some extra pointers:

https://youtube.com/watch?v=C7pkab8n7ys

https://www.nanog.org/sites/default/files/dosdontsnetworkautomation.pdf

https://github.com/coloclue/kees

Kind regards,

Job


On Tue, 6 Jun 2017 at 13:49, Brian Knight  wrote:

> Because we had different sources of truth which were written in-house, we
> wound up rolling our own template engine in Python. It took about 3 weeks
> to write the engine and adapt existing templates.  Given a circuit ID, it
> generates the full config for copy and paste into a terminal session.  It
> also hooks into a configuration parser tool, written in-house, that tracks
> configured interfaces, so it is easy to see whether the template would
> overwrite an existing interface.
>
>
>
> I used the Jinja2 template engine, along with pyodbc/unixODBC/FreeTDS for
> access to a Microsoft SQL backend.
>
>
>
> The keys for us are:
>
>
>
> * extracting information from a source of truth
>
> * validating the information for correctness
>
> * making sure you don't overwrite existing config
>
> * outputting the right templates for the circuit features
>
>
>
> It made more sense to write a tool than it did to try to adapt something
> for our environment.
>
>
>
> If I had a free hand and unlimited budget, I would find a single app that
> functions as a source of truth for all circuits and products, which
> includes a templating engine that hooks in easily.
>
>
>
> -Brian
>
>
>
>
>
>  On Tue, 06 Jun 2017 08:22:59 -0500 Graham Johnston &
> lt;johnst...@westmancom.com wrote 
>
>
>
>
>
>
>
>
>
>
>
> Short of complete SDN, for those of you that have some degree of
> configuration templating and/or automation tools what is it that you run?
> I'm envisioning some sort of tool that let's me define template snippets of
> configuration and aids in their deployment to devices. I'm okay doing the
> heaving lifting in defining everything, I'm just looking for the tool that
> stitches it together and hopefully makes things a little less error prone
> for those who aren't as adept.
>
>
>
> Graham Johnston
>
> Network Planner
>
> Westman Communications Group
>
> 204.717.2829
>
> johnst...@westmancom.commailto:johnst...@westmancom.com;
>
>
>
>
>
>

Re: Templating/automating configuration

[Brian Knight]

Because we had different sources of truth which were written in-house, we wound 
up rolling our own template engine in Python. It took about 3 weeks to write 
the engine and adapt existing templates.  Given a circuit ID, it generates the 
full config for copy and paste into a terminal session.  It also hooks into a 
configuration parser tool, written in-house, that tracks configured interfaces, 
so it is easy to see whether the template would overwrite an existing interface.



I used the Jinja2 template engine, along with pyodbc/unixODBC/FreeTDS for 
access to a Microsoft SQL backend.



The keys for us are:



* extracting information from a source of truth

* validating the information for correctness

* making sure you don't overwrite existing config

* outputting the right templates for the circuit features



It made more sense to write a tool than it did to try to adapt something for 
our environment.



If I had a free hand and unlimited budget, I would find a single app that 
functions as a source of truth for all circuits and products, which includes a 
templating engine that hooks in easily.



-Brian





 On Tue, 06 Jun 2017 08:22:59 -0500 Graham Johnston 
johnst...@westmancom.com wrote 











Short of complete SDN, for those of you that have some degree of configuration 
templating and/or automation tools what is it that you run? I'm envisioning 
some sort of tool that let's me define template snippets of configuration and 
aids in their deployment to devices. I'm okay doing the heaving lifting in 
defining everything, I'm just looking for the tool that stitches it together 
and hopefully makes things a little less error prone for those who aren't as 
adept. 



Graham Johnston 

Network Planner 

Westman Communications Group 

204.717.2829 

johnst...@westmancom.commailto:johnst...@westmancom.com; 

Re: Templating/automating configuration

[Christopher Morrow]

https://youtu.be/ltqXgtLWXFo

and the assocaited pdf
https://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf

On Tue, Jun 6, 2017 at 10:09 AM, Nick Hilliard  wrote:

> Graham Johnston wrote:
> > Short of complete SDN, for those of you that have some degree of
> > configuration templating and/or automation tools what is it that you
> > run? I'm envisioning some sort of tool that let's me define template
> > snippets of configuration and aids in their deployment to devices.
> > I'm okay doing the heaving lifting in defining everything, I'm just
> > looking for the tool that stitches it together and hopefully makes
> > things a little less error prone for those who aren't as adept.
>
> you would probably want to look at napalm for something like this.  It
> will back-end into ansible or more recently, salt stack.
>
> Nick
>

Re: Templating/automating configuration

[Stefan]

http://ipspace.net - search on everything ref network automation, under
webinars. Ivan is among the best in analysis and consolidation of such
info, and in documenting all options you may have.

Once you see what he has to offer, and definitely not only in the network
automation space, you may want to subscribe to all his webinars repository
access.

Regards,
***Stefan

On Jun 6, 2017 8:24 AM, "Graham Johnston"  wrote:

> Short of complete SDN, for those of you that have some degree of
> configuration templating and/or automation tools what is it that you run?
> I'm envisioning some sort of tool that let's me define template snippets of
> configuration and aids in their deployment to devices. I'm okay doing the
> heaving lifting in defining everything, I'm just looking for the tool that
> stitches it together and hopefully makes things a little less error prone
> for those who aren't as adept.
>
> Graham Johnston
> Network Planner
> Westman Communications Group
> 204.717.2829
> johnst...@westmancom.com
>
>

Re: Templating/automating configuration

[Nick Hilliard]

Graham Johnston wrote:
> Short of complete SDN, for those of you that have some degree of
> configuration templating and/or automation tools what is it that you
> run? I'm envisioning some sort of tool that let's me define template
> snippets of configuration and aids in their deployment to devices.
> I'm okay doing the heaving lifting in defining everything, I'm just
> looking for the tool that stitches it together and hopefully makes
> things a little less error prone for those who aren't as adept.

you would probably want to look at napalm for something like this.  It
will back-end into ansible or more recently, salt stack.

Nick

Re: Templating/automating configuration

[Pui Edylie]

Hi,

Take a look at Ansible

https://www.ansible.com/

Our whole infra is automated using it and it is great!

Regards,
Edy


On 6/6/2017 9:22 PM, Graham Johnston wrote:

Short of complete SDN, for those of you that have some degree of configuration 
templating and/or automation tools what is it that you run? I'm envisioning 
some sort of tool that let's me define template snippets of configuration and 
aids in their deployment to devices. I'm okay doing the heaving lifting in 
defining everything, I'm just looking for the tool that stitches it together 
and hopefully makes things a little less error prone for those who aren't as 
adept.

Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.com