Search for a command to run...
What is & How to | step-by-step guideline
![[Part 10] Cisco SD-WAN Configuration Templates](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1695446323913%2Fe8f0badb-5b63-4546-a832-627577fb9f99.jpeg&w=3840&q=75)
Visit to see more: https://linktr.ee/nddnam
I am an enthusiastic Network Engineer with 7+ years of experience working on MPLS L3VPN Network projects, Cisco SDWAN Deployment, and Enterprise Networks.
I love to automate every daily task and think Dev-Ops as always. Thus, I am entering the DevNet world.
No comments yet. Be the first to comment.
Uncover the power of SD-WAN in our insightful blog series. Explore benefits, implementation strategies, and real-world use cases.
SD-WAN Data Plane
In this blog, I'll show how to use Ansible to automate interface configuration across multiple Cisco IOS-XE routers using a loop. This is especially useful for bulk interface provisioning and ensuring consistency across your edge routers. Objective C...
Lab topology and sample configs for testing Segment Routing with SR-TE and PCE on Cisco IOS XE routers. 🖥️ Topology [ R1 ]---[ R2 ]---[ R3 ]---[ R4 ] | | |-------------------------| R1: PCC (client), Source R4: Dest...
![[SR-MPLS] LAB Segment Routing with SR-TE and PCE](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1746671465429%2F97233c37-df08-47a4-9148-0ccdc7b49622.png&w=3840&q=75)
How IGP convergence ties into Fast Reroute (FRR) and Segment Routing - Traffic Engineering (SR-TE) 🔁 IGP + Fast Reroute (FRR) IGP convergence usually takes tens to hundreds of milliseconds—even up to a few seconds depending on the topology and tuni...
![[SR-MPLS] IGP & SR-TE Segment Routing - Traffic Engineering](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1746670805015%2F8e6879c4-0dbd-4513-9327-9026de08933f.png&w=3840&q=75)
Azure Load Balancer vs. Application Gateway
A Deep Dive into Secure Cloud Connectivity
In Cisco SD-WAN, you can set up configurations in two main ways. The network administrator can either put in the settings by typing commands directly using the command line (CLI) as usual.
Another way is by using a visual interface called Manager GUI - it's like using a point-and-click system to set things up. Using vManage GUI is better because it's less likely to make mistakes and can recover from problems automatically.
When you're setting up configurations for WAN Edge devices or controllers using the Manager GUI, a network administrator follows a process. They use something called a "device template" which is like a blueprint for how the device should be set up. This device template can be based on two types:
CLI (command line)
Feature template.
When making a CLI template, all the setup instructions must be included in the template, not just parts of it. On the other hand, feature templates are like building blocks, where each block is a specific feature like a piece of a puzzle. These feature templates define what you want the device to do, like setting up how it handles data, manages connections, and more. This could include things like routing rules, how different parts connect, and a protocol for managing the network.
You can reuse these feature templates in different device templates, which makes things more flexible and easier to manage. This flexibility is why feature templates are recommended. They're not limited to a specific type of device either. The person setting up the network only needs to think about what they want to achieve with the configuration.
When Manager applies the configuration to a specific device, whether it's a Cisco IOS-based device or a Viptela OS device, it knows how to put in the right instructions in a way that the device understands.
Device templates serve as a collection of feature templates designed for specific types of devices. This means that you might have several device templates tailored to the same hardware model, depending on factors like the device's location, connectivity choices, or its designated role in the network. It's important to note that a device template cannot be used across different device types. However, feature templates can be shared across various device types.
A device template comprises four primary components or groups:
Basic Information: This section covers crucial items like System, Logging, AAA, BFD, and OMP feature templates.
Transport and Management VPN: Here, you'll find templates for configuring VPN 0 and VPN 512. This includes settings like underlay routing protocols and interface configurations.
Service VPN: This section is dedicated to configurations for service VPNs or LAN-facing templates. It's where you'll set up parameters for BGP, OSPF, and interfaces.
Additional Templates: In this section, you'll encounter templates for local policies, security policies, SNMP configurations, and more.
Feature templates enhance the flexibility of configuration options significantly.
For instance, they allow you to define variables for configuration parameters. This smartly reduces the number of templates needed for your deployment while maintaining modularity.
To illustrate, consider a scenario with MPLS transports using various physical interface numbers like Gi0/0, Gi0/1, and so forth. Initially, you might consider creating separate feature templates for each interface with different IP addresses, resulting in multiple templates.
However, by utilizing variables for both the physical interface and IP address choices, the administrator can streamline this into a single feature template that remains applicable across all device templates. This approach streamlines the configuration process and ensures consistency throughout.
In templates, you can define three types of values:
Default: These are factory default values that can't be changed. For instance, default BFD timers.
Global: Values set here are applied wherever this configuration is used. For example, SNMP community strings are applied globally to all devices using this template. The advantage is that updating the template's global option later automatically updates all relevant device templates.
Device Specific: These values are set using user-defined variables. For instance, setting interface names. These values are defined when attaching the device template to a specific device.
Some template options might not have all three types, depending on the configuration. For instance, a BGP AS number won't have a default value.
There are numerous feature templates to configure, including:
System: Basic system info like System IP, Site ID, and Hostname.
BFD: Adjust BFD timers and app-route multipliers for transports/colors.
OMP: Change graceful restart timers or control redistribution into OMP.
Security: Modify IPsec settings like anti-replay, authentication, and encryption.
VPN: Define service VPNs, routing protocol redistribution, or static routing.
BGP/OSPF: Configure BGP/OSPF in VPNs or VRFs.
VPN Interface: Define interfaces in service VPNs/VRFs with options like IP Address, QoS, ACLs, and NAT.
Feature templates are used in device templates. After creating a device template, you apply it to a specific device/group. Remember, device templates are specific to a device type. If feature templates have variables, values must be filled when attaching the device template. Successful configuration syntax checks are done in vManage before pushing to the device.
Variables can be populated within the vManage workflow or via a CSV file. The latter is useful for provisioning multiple devices simultaneously.
Note.
If the device loses control plane connectivity to vManage during configuration push, it initiates a 5-minute rollback timer. Failing reconnection within this time, it rolls back to the last-known good configuration. The network admin is notified of the sync issue and can address it accordingly.
Get the Cisco SD-WAN Zero-to-One ebook
Using the CLI template is the most manual way you need to create the maintain the WAN Edge devices configuration using Command Lines.
But in some specific situations, such as testing some configuration parts and functions, you need to change a small piece of configuration frequently to check the result, the CLI template is good to go.
In the real-world business, the individual device CLI templates for each WAN Edge are usually used, because it will minimize the maintenance impacts when you adjust the configuration template for one of the WAN Edges.
Or just simply that you are a Network Admin guy, who loves the Command Lines.
From vManage > Configuration > Templates > Create Template > CLI Template
Enter the required fields Device Model, Template Name, and Descriptions.
Then you can upload your existing CLI configuration file using “Select a File”, or even you can manually enter your configuration CLI there.
From here, maybe you are thinking that it’s tough, how can we remember the CLI structure and syntax if we don’t have the existing configuration file?
No worries, we can use the function “Load Running config from reachable device”.
From the drop-down list, select the reachable WAN Edge, and it will load the full running-config of the selected WAN Edge here.
Tips: You can also SSH or Console to your running WAN Edge, and copy the running-configuration using the output of the command “show sdwan running-config” and Paste here.
Next, adjust the configuration like system-ip, site-id, hostname, or WAN IP Address, to match your target WAN Edge. And Click “Add” to create the CLI Template.
In some cases, we would like to create a single CLI template that can be reusable and attached to more than one WAN Edge.
Let’s think, the system-ip, WAN IP Address, etc. are unique and could not be duplicated between WAN Edges.
Thus, how can we use the same CLI template for many WAN Edges?
The Variables can be used to input the Values into the CLI template when attaching to devices.
Thus, while attaching CLI template to WAN Edges, the Variables require the Value inputted from Network Admin.
It means for each WAN Edge you can input different values and still use the same CLI template.
On the other hand, there are templates that define the configuration settings for specific SD-WAN features, such as Quality of Service (QoS) or Firewall rules.
By using feature templates, network administrators can quickly configure and deploy these features across multiple devices, ensuring consistency in the configuration and optimizing network performance.
One of the different points between CLI and Feature template when creating the Device template from the Feature template, “Device Role” is required to select two options:
SDWAN Edge: Almost the WAN Edge model will be set in this role as a normal cEdge.
Service Node: Until now, only CSR1kv and C8000v (new version of CSR1kv) supported this role. For more information about Service Node, check here.
In this post, I will go with SDWAN Edge mode with the C1111X-8P device.
The remaining parts are Template Name and Descriptions will be the same as CLI Template.
The above attachment and Figure 10 shows that there are some Main parts of the configuration
Basic Information
Transport & Management VPN
Service VPN
Cellular
Additional Templates
Switchport
Note, these parts is for the C1111X-8P model, and it can be different when you choose another device model.
Look at Figure 11, you can see the list of Feature Templates which are used to build your Device template like a Block Puzzle game.
For example, in Basic Information Part, we have Cisco System, Cisco Loggin, Cisco NTP, Cisco AAA, Cisco BFD, etc. I will call those Basic Information child parts.
Moreover, when you create the new Device Template from the Feature template, all of the required parts will be added using Factory_Default_xxx Feature Templates which are predefined by Cisco.
You can check their contents and use them in your Device Template. Note that the predefined template will be named “Factory_Default_xxxx” or “Default_xxxx“.
In this post, I gonna show you how to establish the very first simple Device template, so let’s go to define some basic simple Feature Templates.
vManage > Configuration > Templates > Feature > Add Template >*Select Device Model > Select Template*
As I mentioned above Basic Information is like the child configuration part of the Device Template, and Figure 12 show that Cisco AAA, Cisco BFD, etc. are child template of Basic information part.
For Example, I will create my own custom Cisco AAA Feature Template, the structure will be as below:
Device Template > Basic Information > Cisco AAA
In the Cisco AAA Feature templates, you can easily see there are other child parts inside like LOCAL, RADIUS, TACACS, Authentication and Authorization Order, etc.
In this device template, I would like to add a new local user to the target WAN Edge, so I will create a Feature Template Cisco AAA and add the user as below.l
Once the feature template Cisco AAA is created, let's go back and create Device Template from Feature Template as mentioned in above Figure 10.
I think from here, you can understand the concept of Feature Templates clearly.
Note that you can use a Feature Template to put into many Device Templates with the same device model selected.
Same as CLI Template, Feature Template can use the Variable to be flexible and attached to many WAN Edges with the same template.
I will demonstrate with the example that I will create the VPN 0 Feature Template to match the DUAL-WAN requirement.
I will input the fixed value VPN-ID = 0 because the requirement is to create VPN 0.
Go next with IPv4 Route to set the default route with dual next-hop (Dual WAN).
You can enter your fixed value of next-hop IP Addresses there, but our target is to use this Feature Template for many WAN Edges on another site.
So we can set these as Variables and will input the specific value when attaching the template to devices.
Even if you use the Device template from CLI Template or Feature Template, the same concept and structure are applied. Let's consider the requirements, and balance the convenience and safety maintenance when you choose the type of templates.
Hope the posts help you more clearly understand how to use the Cisco SDWAN Templates.
