To keep the networks healthy, cause connectivity matters

I love being a network engineer, even though I struggled to explain to non-networking people about the utmost relevance of network administration. However, during the last two years of the COVID-19 pandemic, the world could see the relevance of having connectivity. Networks are the highways of information. Data, applications, entertainment, and factories need the network connectivity roads to make the world run. It’s interesting that even network models to estimate traffic behavior use algorithms that are similar to the ones to estimate transportation.

To enable this communication, networks have to interconnect through routing protocols. There are many ways to configure routing; you can permit or restrict traffic to certain networks to leave some sectors isolated, and propagate routes to allow connectivity only to specific segments of your network.

When you configure routing settings to allow this interconnection, you not only want to reach the ultimate purpose of configuring connectivity, but you want to do this in an efficient manner.

The use of prefix-lists is one mechanism to permit a better use of resources in your routers. In this blog we are going to briefly cover why prefix-lists configuration is relevant, and how you can simplify this configuration through automation with Red Hat Ansible Automation Platform.

Why are prefix-lists relevant?

Prefix lists are commonly used to configure route maps and route filtering operations, and usually replace access lists. They are used for every routing protocol: BGP, OSPF, ISIS, and RIP are very common configurations among network operations.

Depending on the company and IT needs, routing configuration can be very dynamic: New routes will be added for route advertisements (prefixes), and removed networks will have their routes removed for prefix announcements.

How do they work?

Each statement of a prefix list has a sequence number to permit deletion or insertion of individual commands into a particular sequence position. Each command has a permit or deny action to match packets; permit implies a route is matched, while deny implies that a route is denied. Prefix-lists work similarly to access-lists in that ordered entries are processed sequentially and the evaluation of a prefix against a prefix list will end the moment a match is found.

A prefix-list command has a structure like:

ip prefix-list list-name [seq seq-value] {deny network/length | permit network/ length}[ge ge-value] [le le-value]

Now let’s see how we can automate this configuration in a simple and structured manner using network resource modules.

Using network resource modules to automate prefix-lists configuration

What’s an Ansible network resource module?

An Ansible network resource module can read and configure a specific resource, such as a prefix-list, on a network device. They allow for configuration of subsections or resources within the network device configuration, in a consistent way across multi-vendor network devices (Arista EOS, Cisco NX-OS, Cisco IOS and IOS-XE, Juniper JunOS, VYOS, and Cisco IOS-XR)

You can use the network resource modules to specify the behavior of your configuration by assigning the following states: merged, replaced, overridden, gathered, rendered, parsed, or deleted.

In very simple words, resource modules are the bricks, the solid foundation that allow you to create automation content ready for production.

Automating with playbooks

In a multi-vendor environment, you might want to configure in a simple and consistent manner. This is achieved in the following example through the selection of specific resource modules depending on OS conditions.

Note this demo environment has four routers:

rtr1 with Cisco IOS XE
rtr2 with Arista EOS
rtr3 with Juniper JUNOS
rtr4 with Arista EOS

You can see below highlighted how this works for Cisco IOS (IOS-XE router) and Arista EOS. This means the Juniper router will not be configured this time:

---
- name: configure prefix-lists
 hosts: network
 gather_facts: false


 tasks:
 - name: Merge IOS XE provided Prefix lists configuration
   cisco.ios.ios_prefix_lists:
     config:
       - afi: "ipv4"
         prefix_lists:
           - name: "v401"
             entries:
               - action: "deny"
                 prefix: "45.55.4.0/24"
                 sequence: 25
      
       - afi: ipv6
         prefix_lists:
           - name: test_ipv6
             description: this is ipv6 merge test
             entries:
               - action: deny
                 prefix: 2001:DB8:0:4::/64
                 ge: 80
                 le: 100
                 sequence: 10
     state: merged           
   when: ('ios' in ansible_network_os)


 - name: Merge EOS provided Prefix lists configuration
   arista.eos.eos_prefix_lists:
     config:
       - afi: "ipv4"
         prefix_lists:
           - name: "v401"
             entries:
               - sequence: 25
                 action: "deny"
                 address: "45.55.4.0/24"
               - sequence: 100
                 action: "permit"
                 address: "11.11.2.0/24"
                 match:
                   masklen: 32
                   operator: "ge"
           - name: "v402"
             entries:
               - action: "deny"
                 address: "10.1.1.0/24"
                 sequence: 10
                 match:
                   masklen: 32
                   operator: "ge"
       - afi: "ipv6"
         prefix_lists:
           - name: "v601"
             entries:
               - sequence: 125
                 action: "deny"
                 address: "5000:1::/64"
     state: merged           
   when: ('eos' in ansible_network_os)

After you run this template, you will see rtr3 was not impacted as it did not match the condition rules. Condition statements can follow different criterias, and this is particularly interesting when you have standard rules that you can follow such as hostnames or IP addresses per location, or network purpose (i.e. aggregation, core).

After the execution using Red Hat Ansible Automation Platform, you can even check the full configuration in a structure JSON format which looks like this:

Key takeaways

As you can see, you can keep governance of your network configuration but still add automation and logic into the most common configuration scenarios, such as prefix-lists.

Network resource modules can simplify the automation content creation process by providing the building blocks. We covered a multi-vendor scenario, including Arista EOS and Cisco IOS XE routers following specific rules, and this configuration can be extended for other scenarios following different rules according to your specific needs.

Continuing the network automation adventure:

Want to try Ansible Automation Platform in your own environment?

We offer an Ansible Automation Platform trial.

Interested in developing human-readable automation with Ansible?

DO007 is a free self-paced online video course to expand your automation skills. We also provide short self-paced, interactive labs with Ansible Automation Platform 2.

Want to learn more about network automation use cases?

Check out additional information about network automation use cases; you are also invited to try Ansible Automation Platform for a free trial.

Additional documentation to start can be found here:

Network automation instructional.
Network automation for everyone.
Network automation using Ansible.
Additional Ansible use cases.
Network automation using Ansible session by Ganesh Nalawade, that includes an explanation on why to use network resource modules.

Want to learn more about network resource modules?

You can check the available resource modules here:

Want to recreate the demo?

You can recreate this demo scenario anytime using the GitHub Code to recreate the automation for these tasks.

Originally posted on Ansible Blog
Author: Dafné Mendoza

Automating multi-vendor network prefix-lists