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 '. However as it is today,
> 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 ?
>Interface protocol family
>
> Then you could do 'family ' 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
