Ansible Network Resource Purge parameter

May 10, 2021 by Sean Cavanaugh

Red Hat Ansible Network Automation continues to be a popular domain for Red Hat Ansible Automation Platform. We have continually developed additional resource modules to make automating network appliances easier, and more approachable, for novices and experts alike. These resource modules provide a consistent experience across multiple network vendors. There are seven main state parameters for resource modules: merged, replaced, overridden, deleted, gathered, rendered and parsed. The Ansible network team is adding one more parameter, purged, to this tool chest for resource modules. This blog will cover the purged parameter and show use-cases through a practical example.

network purge blog

For this example, we will be using two BGP resource modules to configure a Cisco network device. We will be using the bgp_global module, which was covered in Rohit’s blog post, and the bgp_address_family module. The BGP configuration is split between these two separate modules to simplify configuration and data models associated with them.

Let’s start with a data model:

bgp_global:
    as_number: '65000'
    bgp:
        log_neighbor_changes: true
        router_id:
            address: 192.168.1.1
    neighbor:
    -   activate: true
        address: 10.200.200.2
        remote_as: 65001
bgp_address_family:
    address_family:
    -   afi: ipv4
        neighbor:
        -   activate: true
            address: 10.200.200.2
        network:
        -   address: 10.25.25.0
            mask: 255.255.255.0
        -   address: 10.25.26.0
            mask: 255.255.255.0
        -   address: 10.100.100.0
            mask: 255.255.255.0
        -   address: 10.200.200.0
            mask: 255.255.255.0
        -   address: 172.16.0.0
        -   address: 192.168.1.1
            mask: 255.255.255.255
    as_number: '65000’

NOTE: If you are new to resource modules, you can quickly create these data models by using the state: gathered parameter to read in a brown-field (already configured) network devices and save that configuration to structured data (e.g. YAML) 

We can push this data model configuration to our Cisco network device very easily with a simple Ansible Playbook:

---
- name: configure BGP for blog
  hosts: cisco
  gather_facts: false
  tasks:
  - name: Use the bgp_global resource module
    cisco.ios.ios_bgp_global:
      config: "{{ bgp_global }}"

  - name: Use the bgp_address_family
    cisco.ios.ios_bgp_address_family:
      config: "{{ bgp_address_family }}

You can copy this playbook directly from Github 

To execute the playbook:

ansible-playbook merge_ios_bgp.yaml

The output will look similar to the following:

network purge blog 2

Finally let’s look at the generated configuration on our Cisco IOS network device:

rtr1#sh run | s router bgp
router bgp 65000
 bgp router-id 192.168.1.1
 bgp log-neighbor-changes
 neighbor 10.200.200.2 remote-as 65001
 !
 address-family ipv4
  network 10.25.25.0 mask 255.255.255.0
  network 10.25.26.0 mask 255.255.255.0
  network 10.100.100.0 mask 255.255.255.0
  network 10.200.200.0 mask 255.255.255.0
  network 172.16.0.0
  network 192.168.1.1 mask 255.255.255.255
  neighbor 10.200.200.2 activate
 exit-address-family

So finally here is the easy part, using our new state: purged parameter: you can delete the entire bgp configuration on a device using one task. This might be often relevant on lab networks or when you want to start with a clean-state configuration.

  - name: Use the bgp_global resource module
    cisco.ios.ios_bgp_global:
      state: purged

Difference between purged and deleted:

The state: deleted parameter is very similar, however it has two primary purposes different than purged. Deleted has the ability to remove the specified configuration with the config parameter. If no configuration is specified it will delete that entire resource (e.g. all address family configuration if using the bgp_address_family module). However, there are multiple resource modules that make up BGP configuration. This means you would need multiple modules running state: deleted to remove all the BGP configuration. The state: purged parameter allows you to use  bgp_global resource module to remove all BGP configuration simplifying your Ansible Playbooks.

Now we can execute the playbook and manually check the configuration to see what it did:

network purge blog 3

In the above screenshot (from the Ansible Automation Platform Web UI) you can see that the playbook ran successfully and the BGP configuration is now removed.

Checking the running configuration on the Cisco router will reflect the change:


rtr1#sh run | s router bgp
rtr1#

Why would I use one over the other?

Many people are automating brownfield networks, or even networks where a mix of manual changes and automated changes are taking place. You might want to remove all BGP configuration from multiple devices where you have no SoT (Source of Truth) setup. This allows a playbook writer to use one task to destroy just BGP configuration versus a multiple-module method. This is just another tool in your resource module toolbelt!

 

Where do I go next?

All the examples in this blog post are on Github here.

More info on Red Hat Ansible Network Automation

Want to try Red Hat Ansible Automation Platform? The free trial is here.

Share:

Topics:
Network Automation


 

Sean Cavanaugh

Sean is a Principal Product Marketing Manager, Ansible, where he brings over 10 years of experience building and automating computer networks. Sean previously worked for both Cumulus Networks and Cisco Systems where he helped customers deploy, manage and automate their network infrastructure. He resides in Chapel Hill, NC with his wife and children and tweets from @IPvSean.


rss-icon  RSS Feed

RH-ansible-automation-platform_trial-banner
rh-ansiblefest-blog-image-600x500