In this chapter, we examine Device and Feature Templates, which are part of the legacy configuration model, which is now called UX1.0 (short form for User Experience 1.0). 

Cisco acquired Viptela in 2017, rebranded their SD-WAN solution into Cisco SD-WAN, and started deploying it to customers using the existing UX1.0 approach - device templates, feature templates, and centralized policies. Although this approach provided a flexible configuration framework, it quickly became obvious that it had lots of inefficiencies in large-scale deployments.

To address these inefficiencies, Cisco introduced a new configuration model in release 20.8 in 2022 called UX2.0. It replaced the traditional device template approach with Configuration Groups, Feature Profiles, and Policy Groups. However, all new deployments were still done using the old UX1.0 model, even though the new features were already embedded in firmware.

With release 20.12 in 2023, Cisco began recommending UX 2.0 for all new deployments. UX 1.0 remained supported for existing environments, allowing organizations to continue using their established configurations and migrate whenever they want. So, for context going further in the book:

• When we say UX1.0, we mean Device and Feature Templates, and Centralized Policies.
• When we say UX2.0, we mean Configuration Groups, Policy Groups, and Topology.

Device Configuration Fundamentals

Before we start with UX1.0 - Device and Feature Templates, let’s first discuss how we network engineers have been configuring network devices in a broader context. We can summarize the approaches in three distinct categories, as follows:

The legacy approach: CLI (human to device)

For decades, we network engineers configured routers and switches one device at a time using the command-line interface (the CLI). You are most likely very familiar with it, so there is no need for any explanations. However, I want to emphasize a few aspects of the CLI. It is, by nature, created to allow communication between a human and a network device. For example, you execute commands directly on а router. In essence, you talk directly to the network device. There is nothing in between, as shown in the diagram below.

Network administrators are pretty familiar with CLI. So much so that some engineers never thought about the following aspects of it:

• CLI doesn’t have a standardized structure – different hardware platforms and operating systems have different syntax (IOS, IOS-XE, IOS-XR, NX-OS, etc.).
• Using the CLI requires a high level of preparation and knowledge - there are roughly 6000+ commands on an IOS-XE router.
• It leads to deployment complexity - commands are generally executed in order, and the order matters.
• It lacks real-time guidance - I know we have the ?, but it is not enough. What is the minimum necessary configuration in a given use case? You need to know beforehand. What is the recommended config for a given use case? There is no interactive guidance.
• CLI code is not reusable and is very susceptible to human error - It is hard to achieve network-wide config standardization. Some commands are always missing here and there.
• It is associated with a decentralized management model – you configure each device separately and store the config on the device itself. The device cannot contact you back in the middle of the night and tell you – “Oops, I lost my configuration file due to a power outage. Can you send me the latest config back?”

Anyway, CLI is an essential part of networking. It has more low-level access to the box’s hardware than the GUI/API and is an irreplaceable troubleshooting instrument. However, it is no longer the configuration tool of the present. Nor of the future.

The present approach: API (device-to-device)

For a long time, it has been evident that we must transition from the decentralized management model to a centralized one where the user (a network admin) interacts with a centralized management node using a graphical user interface (GUI). The management node then deploys the configuration to the device fleet via configuration transactions, as shown below.

This approach has many benefits over the CLI. First, there is the GUI. Even if some don’t like it, the GUI provides interactive workflows, smart defaults, and other real-time configuration guidance that help network admins.

The centralized management node also allows for more scalable configuration deployment. In case of an unexpected reboot of a network device, one can contact the centralized management node and download its configuration back at any given moment. The centralized node provides many additional improvements. It is an enabler of automation, 3rd party device programming through API calls, and so on.

The future approach: AI (AI to device)

Let’s not pretend AI does not exist and everything is as it has always been. AI is here, and it will probably make its way into all industries, including networking. That’s why I’ve included this configuration model just because it is becoming clear that AI will play a major role in how we operate networks. In fact, the first steps in this direction are already visible.

At some point in the very near future, instead of writing CLI commands and defining templates or configuration groups, we may simply tell the management node (vManage or an external AI agent) what we want the network to do using natural language. 
An AI agent could then translate this intent into the required configuration and deploy it to the appropriate devices, as shown in the following diagram.

Cisco is already moving in this direction with the concept of AgenticOps, where AI agents can prepare basic configurations, deploy them, and validate results. However, in my opinion, this doesn’t necessarily mean that network engineers disappear from the process. Quite the opposite in fact. Engineers will remain an important part of the control and validation loop.

Network Engineer in-the-loop

I think the configuration model will change, but somebody still has to decide what the network should do. I expect a typical network change in the near future to look something like this:

1. Network administrator specifies the intent.

   Instead of creating the configuration manually via CLI or GUI, the administrator describes the required change to an AI agent using natural language.

2. The AI agent generates the required configuration.

   The agent analyzes the current network state and source of truth. It then generates the required configuration and opens a change request via ServiceNow or another ITSM tool.

3. The network admin reviews the proposed change.

   This is the most important step in my view. The network engineer reviews what the AI intends to configure, the expected results, and the potential blast radius. The engineer can then approve or reject the change.

4. The AI agent deploys the approved change.

   Once approved, the agent connects to the management platform or directly to the devices through an API, SSH, or another supported interface and applies the configuration.

5. The AI agent observes the network after the change.

   The agent then collects operational data and compares the resulting network state against the requested intent, the source of truth, and the previous baseline.

6. The network admin validates the post-change state.

   The administrator reviews the post-change results and decides whether the change was successful. If everything works as expected, the change is closed. If something is wrong, the engineer can request a rollback, after which the AI agent restores the previous known-good configuration.

This operational workflow shown above is a much more realistic near-term model than the idea of AI taking over the network administration role. I think that nobody will give an AI model unrestricted access to the production network. Typically, the network is the most critical infrastructure with the largest blast radius that can bring down the entire organization in seconds. 

Additionally, if you think about it, the network domain differs from most IT shops. There are no sandboxes, virtual test environments, and a pre-production environment where you can test what AI agents do before moving them to production. In most organizations, the network is this one big super critical infrastructure that enforces the organizations’ traffic and security rules. 

And this touches another reason why I think the network will be less affected by AI than other IT shops. As organizations deploy more AI agents, they will need a reliable way to control what those agents are allowed to reach. Not every AI agent should have access to every database, application, or piece of sensitive information that the organization has.

In my personal view, the network is the place to enforce these security boundaries for AI agents. Micro-segmentation, identity-based access control, zero-trust, and application-aware security can limit where an AI agent can connect. In that sense, the network may gradually become one of the main enforcement points for AI governance inside the organization.

So, rather than making networking less important, the rapid adoption of AI agents may actually increase the importance of the network. One very likely scenario is that organizations will start tagging agents’ traffic with Scalable Group Tags (SGTs), for example, and then propagate this tag across the entire network to identify the AI agent and control what it is allowed to access.

New Skills

And this leads us to the skillset that future network engineers will have to have. I think that engineers nowadays must not focus that much on the way we configure the device fleet. For me, it becomes more and more valuable to understand the architectural, security, and business side of features and capabilities than to know how to configure them. Let’s take Direct Internet Access (DIA), for example. It is way more valuable to know the answers to these questions:

• Why does my organization need DIA?
• Why is DIA a good choice for our existing network architecture?
• What are the technical/business problems that DIA solves for my organization? 

It is least valuable to know the steps to configure DIA. At some point, there will likely be an interactive wizard in vManage that will guide you on enabling the feature.

At the same time, new skills will become much more valuable. Network engineers will need to know how to define a reliable source of truth and a network baseline. They will also need to express requirements in a form that AI can understand without ambiguity.

For example, the better we define a task, the less room we leave for AI to make incorrect assumptions. For example, a good change request may specify the exact implementation steps, their order, the expected result after each step, the validation checks, and the rollback conditions. In that case, the AI is not being asked to think. It is being asked to execute a clearly defined procedure. Writing clear, unambiguous change tasks, will be a skill on its own.

Another important skill will be the ability to review configurations and implementation procedures generated by AI. Engineers must be able to decide whether the proposed configuration is technically correct, whether the sequence of changes is safe, and whether the expected outcome matches the design. After deployment, they must also know how to validate the network state and recognize when something has gone wrong.

Therefore, strong architectural knowledge, protocol knowledge, troubleshooting skills, and the ability to review and validate configurations remain critical.

AI may change how we configure networks, but it does not remove the need to understand how networks work. I think that the value chain in the near future will look like this:

AI will become very strong at the HOW. We, network engineers, should become stronger at everything around it.

• Understand the business problem (very important).
• Understand the architecture (the most important).
• Choose the right technology.
• Define how it fits the existing architecture.
• Identify dependencies and risks.
• Define the requirements in a super exact, unambiguous way.
• Define what successful change looks like.
• Define how the post-change results will be validated.

I would summarize the skills change like this:

• In the past two decades, a great network engineer was often the person who knew exactly how to configure the network. Very good at HOW.
• In the near future, a great network engineer will be the person who knows why the network must change, what the correct change should be, and whether the result is actually correct. Very good at WHY and WHAT.

In that context, I have written this book with a special focus on the architectural side of features.

Now moving on, let’s focus on Cisco SD-WAN’s approach to device configuration, starting with the Ux1.0’s Device and Feature Templates.