> On 17/08/2018, at 10:54 PM, Antti Ristimäki <antti.ristim...@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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
