On Thu, May 21, 2020 at 07:56:10AM +0300, Saku Ytti wrote: > Hey Chuck > > > set groups ND6 interfaces irb unit <*> family inet6 nd6-stale-time 600 > > set interfaces apply-groups ND6 > > > > then all irb interfaces get a "family inet6" with link-local > > addressing created and the nd6-state-time setting applied. How do I > > inherit the nd6-stale-time setting only if there is already a > > configured "family inet6" so I don't get IPv6 link-locals on IRBs > > where I only want IPv4? > > As far as I know, you can't. I'm sure if you push this at JNPR they > are able to support it via 'family <inet6>'. However as it is today, > <inet6> only works for user input, not for parameters or keywords, > which I suspect is not actually that huge change in parser. > So if this would in in parser: > > set family ? > <family> Interface protocol family > > Then you could do 'family <inet6>' and it would only apply when that > family exists. However, now as it's not user-input, it doesn't work > and I don't think there is a way.
Is Phil Shafer reading? > Having said that, configuration groups in junos are really great tool, > while usually people use them to avoid repating themselves, I think > perhaps even better use-case is to use them as namespaces, for > example, put all your standard static config in 'template' namespace. > So you you can programmatically do this: > > edit groups template > delete > load merge relative https://nms/junos.template > commit and-quit > > Leaving all device-specific config intact, while normalising all generic > config. Another great use (thanks to Phil Shafer for the suggestion) is to use configuration groups combined with user classes as a finer-grained access control mechanism for automation. set system login class AUTO-PREFIX-LIST permissions configure set system login class AUTO-PREFIX-LIST permissions view set system login class AUTO-PREFIX-LIST permissions view-configuration set system login class AUTO-PREFIX-LIST allow-commands junoscript set system login class AUTO-PREFIX-LIST allow-configuration "(groups AUTO-PREFIX-LIST policy-options .*)" set system login user autoprefix class AUTO-PREFIX-LIST set policy-options prefix-list LIST1 apply-groups AUTO-PREFIX-LIST set policy-options prefix-list LIST2 apply-groups AUTO-PREFIX-LIST set policy-options prefix-list LIST3 apply-groups AUTO-PREFIX-LIST The lists are populated by NETCONF script that cannot access any other "policy-options" config, but can still create/delete new lists whose names are not known beforehand: set groups AUTO-PREFIX-LIST policy-options prefix-list LIST1 10.10.10.10/32 set groups AUTO-PREFIX-LIST policy-options prefix-list LIST1 20.10.10.10/32 set groups AUTO-PREFIX-LIST policy-options prefix-list LIST1 30.10.10.10/32 set groups AUTO-PREFIX-LIST policy-options prefix-list LIST2 10.20.20.20/32 set groups AUTO-PREFIX-LIST policy-options prefix-list LIST2 20.20.20.20/32 set groups AUTO-PREFIX-LIST policy-options prefix-list LIST3 30.20.20.20/32 > And further, don't use configuration groups, at all :) Do it all on > NMS side, so that you are less reliant on vendor tools and > limitations. Then you have as much flexibility on them as you wish and > it works for all your vendors. Any NMS(es) you recommend? This one looks interesting: https://napalm-automation.net/enms-hackathon-project-presentation/ and it is still under development. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp