[j-nsp] Network automation vs. manual config

[Michael Lee]

We have daily work to configure basic load balancer, customer certs and open firewalls, daily 5-15 tickets, without some sort of automation that will be waste a lot of resources for Sr people. So I used ansible and some python and shell script.

Also considering to use Yaml, Jinja2 for standard template for nexus switch base provisioning, standardize tacacs, snmp, features, not, and some ACLs

Just a thought

Sent from my iPhone

> On Aug 17, 2018, at 6:06 AM, Michael Still <stillwaxin at gmail.com> wrote:
> 
> Side note on apply groups and display inheritance. I've submitted a Juniper
> ER for an enhancement to have the ability to have ' | display inheritance'
> a 'default' cli behavior (configurable via 'set cli display-inheritance'
> option that is defaulted to off). I've also asked for a login-class option
> to enable this for specific user role such as front line NOC users who may
> benefit from having it on by default. This is ER-077163 if you want to poke
> your Juniper SE about it.
> 
> The reason I've asked for this is specifically because I've seen NOC
> personnel spend many cycles investigating an issue not realizing that
> particular hidden apply-group config was affecting their investigation.
> 
> I have a couple other semi-related (to automation / configuration
> enhancement) ER's going if folks are interested and would like to chat
> about those directly.
> 
> 
>> On Fri, Aug 17, 2018 at 8:20 AM Nathan Ward <juniper-nsp at daork.net> wrote:
>> 
>> 
>>> On 17/08/2018, at 10:54 PM, Antti Ristimäki <antti.ristimaki at csc.fi>
>> wrote:
>>> 
>>> Another option is to apply the auto-generated configuration via
>> apply-groups and apply all manual configurations explicitly so that the
>> automatic and manual configurations merge with each other. The positive
>> side of this approach is that it makes easy to develop the automation tools
>> so that manual configs are not overridden by auto-generated config, but I
>> personally see somewhat inconvenient that one really doesn't see the
>> effective running-config when using apply-groups, unless one remembers to
>> display inheritance.
>> 
>> We’ve implemented this at a network I support, seems to be going well. We
>> approach it slightly differently though, in a way which may help solve your
>> usability problem, in a bit of a roundabout way. In short, we build groups
>> in to almost everything so people are used to doing display inheritance if
>> they need to look deeper at things. It’s not perfect, but it’s the best way
>> I’ve found to manage large bits of JunOS config.
>> 
>> We have 3 types of groups:
>> Global* - common on every router they exist on, applied at top level only
>> Local* - unique to this router, applied at any level
>> * - common on every router they exist on, applied at any level
>> 
>> All our groups have apply-flags omit;
>> 
>> Local* groups are only used when something is re-used several times on the
>> one router - for example on our BNGs, a list of DHCP interfaces in each of
>> the routing-instances we might push a subscriber in to.
>> 
>> So, for example:
>> - GlobalDualREMX sets up whatever our standard things are for an MX with
>> 2 REs, applied at top level.
>> - “MPLS" is applied at `interfaces blah` and `protocols rsvp interface
>> blah`, etc and includes our per-interface MPLS config.
>> - VRFCustomers includes our import/export policies for our Customers VRF
>> (applied inside a routing-instance), and the loopback filter config for the
>> Customers VRF loopback (applied inside an interface).
>> 
>> The only config that’s outside groups is config unique to that router -
>> so, IP addressing, routing-instance names and RDs, interfaces (though they
>> have apply-groups within them for many settings), hostname, etc.
>> 
>> This means:
>> 1) Config is short because of apply-flags omit. Seeing things unique to
>> this router is easy. It’s easy to spot differences as apply-groups are
>> different - and that’s all you generally need to look for. I just looked,
>> our BNGs are all about 500 lines of config, and all have identical group
>> config on them. Most of the config is rsvp-te tunnels, and access network
>> interfaces.
>> 2) When we want to look deeper, we know to do `| display inheritance |
>> except #` and it becomes muscle memory - this really is the bit that helps
>> your use case, haha.
>> 3) We can copy our groups from a git repository, load replace (in our git
>> reply they all have replace tags) and commit. Keeping the common config
>> consistent is super easy. Automating this is one “leg” of automation and
>> solves almost all of our automation requirements.
>> 4) We can do bespoke mucking about outside the groups, and it’s obvious
>> what those things are, and what things need to be tidied up in to groups,
>> or what is junk temp config that needs to be thrown out.
>> 
>> I think where this could work for you, is to have your automation apply
>> any router-specific config just like a human would - outside the groups,
>> but leveraging the groups as much as possible. If you want to keep your
>> manual/automated config seperate, stick the automated config in a big
>> single group - that way, manual config will override it, and it’ll be very
>> clear that it’s there and where it’s come from.
>> 
>> --
>> Nathan Ward
>> 
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
> 
> 
> -- 
> [stillwaxin at gmail.com ~]$ cat .signature
> cat: .signature: No such file or directory
> [stillwaxin at gmail.com ~]$
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp