The Power of CLI Add-On Features: Simplifying Multi-Line Commands

The Challenge

CLI add-on templates are incredibly useful and can be powerful when used effectively. However, one common challenge we encounter during deployments is handling multi-line commands tied to a single variable.

Consider a CLI template structured like this:

  crypto engine
  compliance shield disable
  service internal
  {{command_1}}
  {{command_2}}
  {{command_3}}
  

Each command variable can represent any command that you might use to append or alter existing configurations. For example, let’s map the variables as follows:

{{command_1}} → Interface GigabitEthernet0/0/1
{{command_2}} → description "LAN INTERFACE"
{{command_3}} → ip address 192.168.168.10 255.255.255.0

In this case, the commands pushed to the cEdge router through this multi-line add-on would be:

  Interface
  GigabitEthernet0/0/1
  description "LAN
  INTERFACE"
  ip address
  192.168.168.10 255.255.255.0

This effectively configures an interface. However, it requires engineers to populate three separate variables to achieve the desired result. As the number of required variables increases, the configuration process can become excessively complex and challenging to manage.

A Simplified Solution

What if we could consolidate those three lines of configuration into a single variable? Imagine having one variable, cli_command_1}}, that could encapsulate all three lines:

  Interface
  GigabitEthernet0/0/1
  description "LAN
  INTERFACE"
  ip address
  192.168.168.10 255.255.255.0

Wouldn’t that be a significant time-saver? Indeed, there is a way to achieve this.

Testing the Approach

Let’s start by configuring an interface from the CLI on the cEdge:

Figure 1: Existing Interface Configuration

  interface
  GigabitEthernet0/0/1
   no ip address
   negotiation auto
   end

Then, using config-t mode, we can structure the configuration in a single line:

  config-t
  interface
  GigabitEthernet0/0/1; description "LAN INTERFACE"; ip address
  192.168.168.10 255.255.255.0
  commit

Let’s see the results after executing the commands.

We receive no errors on the router and after validation we can tell that the commands were executed successfully as shown below:

Template Implementation

Based on the logic above, here’s how my CLI add-on template looks (see provided images for reference).

The template is now set up to expect input for the field full_cli_config. For one of the routers using this template, I populated full_cli_config with:

  interface
  GigabitEthernet0/0/1; description "LAN INTERFACE"; ip address
  192.168.168.10 255.255.255.0

Before we push the configuration, let’s preview the config to ensure everything looks correct.

We can see that vManage parsed the commands properly and ready to push the change. A few moments later…..

Success!

Validation

Now, let’s review two crucial commands on the router:

  show running-config
  interface GigabitEthernet0/0/1
  show sdwan
  running-config

It’s essential for the show run and show sdwan run outputs of an interface to match in IOS-XE SD-WAN, as discrepancies could lead to significant issues.

Managing Multiple Templates with Same CLI add-on feature template:

Now, let’s explore a potential dilemma: what happens if this CLI feature template is associated with multiple templates, and other devices require that the full_cli_config variable not modify their interfaces? Fortunately, there’s a simple solution: use the “!” character in that variable to ensure nothing gets pushed.

For example, if I have another router Linked to the same CLI add-on that doesn’t require interface updates, I can simply enter “!” where full_cli_config is requested.

By inserting a “!” into the configuration, we effectively communicate to the router that we do not want to implement any changes at that point in the command sequence. The “!” serves as a placeholder for “no command” or “do nothing.” Consequently, when you check the configuration using the show running-config or show sdwan running-config commands, you won’t find any additional “!” characters affecting the output—since the router interprets this specific input as an instruction to skip that line altogether. Thus, there’s no risk of inadvertently altering your configuration.

Use Cases

Imagine managing 500 devices all running smoothly on a single template. However, one device has a unique requirement; while all other devices are configured with static IP addresses, this particular device needs to use DHCP instead. Here’s an example of a feature template set  with static ip address

Can we override this with a CLI template? Absolutely! Utilizing the same logic, we can append a CLI add-on template to the main template with a cli variable that looks like:

  interface
  GigabitEthernet0/0/0; ip address dhcp

This approach also applies if you want to add a secondary IP address or a description such as “VRRP.” The possibilities are endless! However, engineers must exercise caution, as overriding existing configurations can lead to unexpected results—especially if they overlook the implications of a CLI template.

Conclusion

CLI add-on features significantly enhance the configuration process by simplifying the management of multi-line commands. By consolidating multiple commands into a single variable, engineers can streamline their workflows and minimize complexity. This method not only improves efficiency but also helps maintain consistency across various devices. However, caution should be exercised when overriding existing settings to prevent unintended consequences. Overall, leveraging these add-on features can lead to more effective network management and deployment strategies.

Published: 25-04-11