device template vs service template

[erdemk]

Hello,

I just wanted to ask some guidance on how to split the config of a CPE between device template and service template.

Say, i have got a basic l3vpn service, like the ones in /examples/service-provider/mpls-vpn. So, following conf is managed by NSO via l3vpn service : 

   1- interface local, 2- interface link-to-PE, 3- router bgp

Say, i use ZTP to onboard CPE devices as explained in related dcloud case.

My question is , how would i split the config between ZTP day1 config template and service template.

As far as i can imagine, there are 2 main options : 

option1 : include all service related config in service template, and any other config like ntp or management interface or etc. in the day1 device template.

option2 : include all config in service template.

The difference between 2 options is on managing the out-of-the-band changes, at least for this basic service.

# vpn l3vpn ford deep-check-sync outformat cli will only display the missing service config

# devices device <device-name> compare config outformat cli will display all the missing and excessive device configs.

And given the information above , i think both of them are manageable, but there may be some aspects that i cannot foresee.

I appreciate any guidance and/or practical experience.

Many thanks in advance.

erdem

[vleijon · Accepted solution]

This is a design question and depends on situation and personal taste.

But, I have a personal opinion: I like to put as little as possible into the on boarding configuration and as much as possible in the service proper, possibly through a layered service involving a "base" service for the device type and a "feature" service for the VPN or whatever you are putting on top of this.

The reason for this is that your base might change, you might add security fixes or similar in your base config, and if it is a service it is easier to update the templates and re-deploy. Things that are in the onboarding template is more "fire and forget".  Of course the day0 config needs enough to keep the device safe and onboard the device.

The drawback is that it might be slightly more complex to deploy the initial configuration in that format, but I still prefer it that way. That is also because I want to deliver more of a smack-down on out of band changes.

[erdemk]

May you clarify:

By saying base service and feature service, are you refering to lsa or stacked services or regular services ?

Thanks

[vleijon]

I was envisioning a stacked service. Imagine the scenario where you have multiple services, say you have an l3vpn service as well as an internal bgp service and that some routers get the l3vpn service and some get the bgp service. You might still want to apply a common base template to all services with things such as snmp-settings, loghosts et.c, this could be accomplished by a shared stacked service that is responsible just for these base settings.

But, if you never have a need like that it might just be a part of your regular service. It might still be helpful to think of some things as ‘base config’ and some as ‘feature config’ and keeping them in different templates or parts of your template just to conceptually treat them differently.

[erdemk]

Thanks for the clarification. I understand your point which, i also believe, is valid. 

I will re-visit stacked services.

Regards.

[erdemk]

I get it

thanks