NTC Templates – Data Model Update

The NTC Templates library has a major overhaul for the templates going on that is going to create the need for a major release. As part of the planning for the 4.0.0 release of NTC Templates, there is an updated set of data models that are being applied for network device templates. The project is moving to a single common data model, which will allow for the transformation of the data into a single model that is common across the various vendor textFSM template. This is going to make all of your data structures look the same whether you are using Arista, Cisco, Juniper, or other vendor CLI within your Ansible or Python automations. The planned release date is October 10th.

Thank you to Michael Bear who helped significantly spearhead this effort, with the full support from the NTC Team.

NTC Templates History

NTC Templates is one of NTC’s oldest and most popular open source libraries. It is used across many automations to provide a structured data format from CLI unstructured text. It is available and incorporated with many common tools used to automate networks every day, including the capability to use it with Ansible, Netmiko, Scrapli, and others.

There have been some changes over time, but overall, the library is the go-to place for taking unstructured CLI output and converting it into structured data for use in your Python applications (Ansible as well, which is a Python library).

Data Model

With the 4.0.0 release of NTC-Templates, many of the individual templates are being updated to a common data model for various components. Anywhere there is the use of VLANs, for example, previously you may have seen any of the following textFSM keys:

• VLAN
• VLAN_ID
• VLAN_TAG
• TAG
• VLAN_NUMBER
• VLAN_NAME

Now, each of these will be migrated into a single data model with VLAN_ID being anything that represents a VLAN numerical representation, and VLAN_NAME wherever a string identification of a VLAN is made.

The same can be said for MAC addresses and prefixes. With MAC addresses there were places that would just be MAC, MAC_ADDR, MAC_ADD, and so on. The names of the keys are no longer going to be shortened. In sticking with the Zen of Python, these are going to be much more explicit.

What Do I Need to Do?

At this point, there are two options for being prepared properly. If you are writing your first automation applications, let’s move forward to 4.0.

Stay at 3.x

First, if everything is working well for you and you wish to remain on the 3.x templates, you need to make sure to pin your dependencies for the NTC Templates library to 3.x. If you are using requirements.txt:

ntc-templates>=3.0,<4.0

With poetry:

ntc-templates=^3

Update to 4.0

If you are looking to move forward to the common data model, you will need to update your automation applications and playbooks that leverage the keys. Take a look at the updated templates if you are working on Layer 1 – 3 components, such as VLANs, MAC addresses, and IP addresses. Put the automation through the paces and update as necessary for the keys.

Summary

The updated NTC Templates have had some strong updates over the years. Many contributions from the entire Network Automation Community. The move to this while somewhat painful at this particular time will reap many benefits to the years to come. This now will help enable automation capabilities such as:

• Pre-post comparison of different device types
• Comparison between different device types (including those from different vendors)
• Consistency for new onboarded templates
• Simplified downstream automations