Mailing List Archive

Yes, change the group to be applied from the root of the config.

On Thu, 21 May 2020 at 11:53, Chuck Anderson <cra@wpi.edu> wrote:

> Is there any way to inherit a configuration group setting, but only if
> the parent object already exists? For example, if I apply this:
>
> 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?
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
--
Regards,

Mark Tees
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Sorry I misread that :/

What you are wanting is more complex in second pass.



On Thu, 21 May 2020 at 12:18, Mark Tees <marktees@gmail.com> wrote:

> Yes, change the group to be applied from the root of the config.
>
> On Thu, 21 May 2020 at 11:53, Chuck Anderson <cra@wpi.edu> wrote:
>
>> Is there any way to inherit a configuration group setting, but only if
>> the parent object already exists? For example, if I apply this:
>>
>> 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?
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
> --
> Regards,
>
> Mark Tees
>
--
Regards,

Mark Tees
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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.


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.


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.

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

> Any NMS(es) you recommend? This one looks interesting:
>
> https://napalm-automation.net/enms-hackathon-project-presentation/
>
> and it is still under development.

I am opinionated and not necessarily right. But as far as I know there
isn't really a great provisioning tool out there. And if you can make
some heavy assumption, for example that every device is like junos
that it accepts full configuration and figures out how to get from
current to new full, then it's really easy to get 100% of configs from
systems. Even for journeyman developer like myself it's just weekend
POC to have something to show.

Ideally you'd do something like this:
a) dump all configs as flat files, per router
b) develop tool to push those configs to network, replacing existing ones
c) start moving data from file to database, targeting biggest wins first

So no matter how poor your data hygiene is or how far the goal is, you
can actually start moving day1 and keep moving every day, instead of
some massive 0-100 project. This isn't a project it isn't even a
process, it's culture.


If you can't make that assumption, then I'm not sure if those
platforms even deserve to be automated, rather plan to replace them
and keep in life support with whatever process you are familiar with.
If network configurations are immutable, never changed, only replaced,
a very hard problem becomes very easy.

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 21/May/20 13:19, Saku Ytti wrote:

>
> So no matter how poor your data hygiene is or how far the goal is, you
> can actually start moving day1 and keep moving every day, instead of
> some massive 0-100 project. This isn't a project it isn't even a
> process, it's culture.

This.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

> This isn't a project it isn't even a process, it's culture.

Well said.


Hi Chuck,

> 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?

One hackish way to accomplish this would be with a commit script which
dynamically expands the configuration group content. Something like this:
https://gist.github.com/tonusoo/9e343660c23b35c74630760dcf96b24b


WBR,
Martin
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp