04-16-2019 06:21 AM
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
Solved! Go to Solution.
04-16-2019 08:08 AM
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.
04-16-2019 08:08 AM
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.
04-16-2019 09:09 AM
May you clarify:
By saying base service and feature service, are you refering to lsa or stacked services or regular services ?
Thanks
04-16-2019 09:49 AM
04-16-2019 03:11 PM
Thanks for the clarification. I understand your point which, i also believe, is valid.
I will re-visit stacked services.
Regards.
04-16-2019 09:03 AM
I get it
thanks
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide