Credit for the slide below goes to Brad Edgeworth and Dustin Schuemann. All screenshots are my own.
Now that we’ve covered the infrastructure of the Cisco SD-WAN solution, it’s time we start talking about how we plan our network deployments. For that, we need to leverage a newer, better version of something most enterprises have been doing for years in some form: Templates.
Think about how device templates are constructed today. How do we leverage them? Usually, it starts with trying to cast the widest nets possible, targeting the features that most devices will share.
For example, a common template is the NMS template which includes things like Netflow settings, Syslog targets, logging and other monitoring features an enterprise will utilize for the entire infrastructure. Of course, not all feature commands are the same, and so such templates are commonly split up by the code base as well (IOS, IOS-XE, IOS-XR, etc).
Looking at NMS templates and the considerations around other things which may necessitate the branching of templates into sub-templates (regionalized monitoring, as an example), we can start to see that many features could require multiple templates to be created.
Let’s now extend this outward from the feature level and start talking about platform considerations. Are we talking about fixed chassis platforms? Modular ones? What functions are performed by the platforms? Is the 3945 router exclusively used in the WAN? Are there 3945s working as CUBE routers for collaboration? Does the enterprise use the Catalyst 9300 switch as an access-layer switch exclusively? Are there small branches to consider where it may also serve in a collapsed core function? The features will almost certainly be different based on the specialized functions and hardware. Without following this white rabbit too far, you can begin to see the challenges.
So why do we put so much work into creating templates? Simple: Because they scale.
Imagine the alternative to templates. Every time a new device was deployed, you’d have to go scrape a config from a similar production device, change all the device-specific variables (such as IP addressing) and paste it into the new device. The potential for human error is high and the time invested is also high. Templates work because they are repeatable, reduce human error, and scale the deployment and management of devices far beyond what the standard NOC ‘cut-and-paste-config’ engineer is capable. For an investment of front-end time and effort, an immeasurable amount of back-end time and effort can be saved.
So how do Cisco SD-WAN templates stack up? The short answer is, like building blocks.
Each template has shared configuration, which will be the same across all devices attached, and also device-specific variables. These variables can be filled in one at a time when they are deployed, or a CSV file can be generated for the template, filled in, and then uploaded to apply the values. From a scalability perspective, if deploying 1000 devices, this is by far the better choice.
CLI Templates
CLI templates most closely match what many enterprises are still doing today, where the template is a basic configuration with variables dedicated to device-specific information. The CLI template provides the largest freedom to do an entire template at once and then replicate that across other devices, and makes a lot of sense if there is a large fleet of similar devices with exactly the same deployment. Another strength of the CLI template is that it will be the first to support brand new features that may exist in code but not yet be modeled in vManage.
Note that the CLI template’s strengths become weaknesses if there’s a lot of variability in deployment, due to the template’s inability to compartmentalize.
Feature Templates
There’s a lot of effort to create feature templates, but the benefit of the front-end work is that the templates provide maximum flexibility and scalability, which lowers effort on the back-end. The drawback of feature templates is that they have to be modeled in vManage to be used, so the newest code features may only be available via CLI templates pending vManage upgrades.
The main strength of feature templates is in modularity. Different feature templates can be swapped to create entirely new device templates, whereas a CLI template requires an entire template be created for each variant. In enterprises without variation, CLI templates require less work to develop, but in enterprises with a lot of different features and options, the feature template is king.
Creating Templates
All templates begin with specifying for what type of device the template is intended.
For CLI templates, after specifying the device type, the exact configuration commands are applied directly to the template. Any variables must be defined at this stage. If there are current CLI templates to use as a baseline, it can be uploaded directly.
Creating feature templates is akin to building a house, one brick at a time. A significant amount of time should be spent planning these in order to maximize their scalability and usability. While each feature template is configured separately, they will attach to a device template in order to meet a design.
Deploying Templates
Ultimately, feature templates must be attached to device templates, and the device templates are then attached to whichever devices will use that template. This differs from CLI templates, which are attached directly to the devices which will utilize them.
The application of templates is done via vManage by attaching device templates to specific devices.
Once the templates are attached, any device-specific variables must be supplied. Again, this can be done on a per-device basis, or via CSV with the fields populated.
At this point, it’s just a matter of pushing the templates to the devices to which they are attached. This will be done via the vManage, using Netconf/Yang as the southbound protocol. No ‘login, paste config’ automation here.
Speaking of automation, the team over at Cisco DevNet have been doing some very timely heavy lifting around SD-WAN automation. I highly recommend you head over and check it out! The vManage web GUI is functional, but requires a lot of clicks. With API calls, the generation and application of templates can be greatly accelerated.
