Re: [j-nsp] any way to do group inheritence only if parent exists?
> 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
Re: [j-nsp] any way to do group inheritence only if parent exists?
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
Re: [j-nsp] any way to do group inheritence only if parent exists?
> 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
[j-nsp] any way to do group inheritence only if parent exists?
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
Re: [j-nsp] any way to do group inheritence only if parent exists?
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. 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
Re: [j-nsp] any way to do group inheritence only if parent exists?
Sorry I misread that :/ What you are wanting is more complex in second pass. On Thu, 21 May 2020 at 12:18, Mark Tees wrote: > Yes, change the group to be applied from the root of the config. > > On Thu, 21 May 2020 at 11:53, Chuck Anderson 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
Re: [j-nsp] any way to do group inheritence only if parent exists?
Yes, change the group to be applied from the root of the config. On Thu, 21 May 2020 at 11:53, Chuck Anderson 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
[j-nsp] any way to do group inheritence only if parent exists?
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