Skip to main content

Network automation with Ansible validated content

Ansible Network Border Gateway Protocol (BGP) validated content collection focuses on platform-agnostic network automation and enhances BGP management.
Image
How to enter the world of Linux containers

Photo by Skitterphoto from Pexels

Ansible validated content is use-case-focused automation content packaged as collections that contain Ansible plugins, roles, and playbooks that you can use as an automation job through Ansible Automation Platform.

[ Learn the difference between Ansible and Red Hat Ansible Automation Platform. ]

One of these collections, Network Border Gateway Protocol (BGP) validated content, focuses on platform-agnostic network automation and enhances the experience of BGP management by providing production-ready content.

Ways to use the Network BGP collection

The network.bgp collection enables users to manage BGP resources independent of platforms and perform BGP health checks. It includes the following capabilities:

  • Build brownfield inventory: The persist action enables users to get BGP global and address family facts and store them as inventory host_vars. The idea is to have this dynamic inventory as a single source of truth for any action.
  • Display structured configuration: The gather action enables users to gather and display the BGP global and address family facts.
  • Deploy changes: The deploy action enables users to deploy the host_vars facts changes to the device.
  • BGP health checks: The health_check action enables users to fetch the current status of BGP Neighborship health for a given network operating system.

[ Related reading: Network automation with Ansible filters ]

Build an Ansible inventory

The persist action enables users to get the BGP global and BGP address family running configuration facts, create the new inventory directory, and store the result as YAML in host_vars in that directory. This dynamic inventory is a single source of truth for other BGP management actions. This is extremely useful considering the complexity and size of BGP routing and allows network engineers to quickly obtain an updated inventory in a simple way for BGP resources.

The native command output for the BGP summary on one of the routers is shown below:

R1#sh ip bgp summary
BGP router identifier 192.168.255.229, local AS number 500
BGP table version is 3, main routing table version 3
2 network entries using 288 bytes of memory
2 path entries using 168 bytes of memory
2/2 BGP path/bestpath attribute entries using 320 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 776 total bytes of memory
BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs

Neighbor  V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
12.0.0.1  4    500   19052   19065    3      0    0    1w5d     1
23.0.0.1  4    500       0       0    1      0    0    never    Idle

To get this BGP configuration and save it as YAML-based host_vars for the inventory, write a task like this:

---
- hosts: ios
  gather_facts: false
  tasks:
    - name: Network BGP Management
      ansible.builtin.include_role:
        name: network.bgp.run
      vars:
        action: persist

Execute the Ansible playbook with the ansible-playbook command:

$ ansible-playbook example.yml

Here is the new inventory directory structure:

$ tree inventory
inventory
├── host_vars
│   └── 192.168.122.220
│       ├── bgp_address_family.yaml
│       └── bgp_global.yaml
└── inventory.yaml

Observe that it created files for non-empty results with names similar to resource module names. The content of these files are resource module-gathered facts:

$ cat inventory/host_vars/192.168.122.220/bgp_global.yaml
bgp_global:
    as_number: '500'
    bgp:
        log_neighbor_changes: true
    neighbors:
    -   neighbor_address: 12.0.0.1
        peer_group: CCIE
    -   neighbor_address: 23.0.0.1
        remote_as: '500'
    -   neighbor_address: CCIE
        remote_as: '500'
        update_source: Loopback1
        version: 4
    networks:
    -   address: 10.0.0.0

[ Check out Network automation for everyone, a complimentary book from Red Hat. ]

Deploy BGP configuration

The deploy action enables users to deploy the host_vars facts changes in dynamic inventory onto the network devices.

I'll change update_source to Loopback0 in the bgp_global.yaml file:

$ cat inventory/host_vars/192.168.122.220/bgp_global.yaml
bgp_global:
    as_number: '500'
    bgp:
        log_neighbor_changes: true
    neighbors:
    -   neighbor_address: 12.0.0.1
        peer_group: CCIE
    -   neighbor_address: 23.0.0.1
        remote_as: '500'
    -   neighbor_address: CCIE
        remote_as: '500'
        update_source: Loopback0
        version: 4
    networks:
    -   address: 10.0.0.0

Now that you have modified the bgp_global host_vars, you can use the deploy action:

---
- hosts: ios
  gather_facts: false
  tasks:
    - name: Network Resource Manager
      ansible.builtin.include_role:
        name: resource_manager
      vars:
        action: deploy

Execute the Ansible playbook with the ansible-playbook command:

$ ansible-playbook example.yml

Confirm these changes on the box with the native command, as shown below:

R1#show running-config | section ^router bgp
router bgp 500
 bgp log-neighbor-changes
 network 10.0.0.0
 neighbor CCIE peer-group
 neighbor CCIE remote-as 500
 neighbor CCIE password cisco123
 neighbor CCIE update-source Loopback0
 neighbor CCIE version 4
 neighbor 12.0.0.1 peer-group CCIE
 neighbor 23.0.0.1 remote-as 500  

Examine the result to learn more about the tasks executed internally.

[ Related: Network automation for everyone ]

Display BGP configuration

The gather action enables users to gather and display the facts for bgp_address_family and bgp_global resources:

---
- hosts: ios
  gather_facts: false
  tasks:
    - name: Network BGP Manager
      ansible.builtin.include_role:
        name: network.bgp.run
      vars:
        actions:
          - name: gather

Execute the Ansible playbook with the ansible-playbook command:

$ ansible-playbook example.yml

Here is a snippet from the output of the gather action:

…
TASK [network.base.resource_manager : Resource Facts] ***********************************************************************************************************************
ok: [192.168.122.220] => {
    "msg": {
        "ansible_connection": "ansible.netcommon.network_cli",
        "ansible_network_os": "cisco.ios.ios",
        "changed": false,
        "failed": false,
        "gathered": {
            "as_number": "500"
        },
        "resource_module_name": "cisco.ios.ios_bgp_address_family"
    }
}

…

View the detailed output in the project's repository.

[ Download now: A system administrator's guide to IT automation. ]

Run health checks

The health_check action enables users to perform various BGP health checks.

  • all_neighbors_up: This health check returns successful only when all the BGP neighbors are up and running.
  • all_neighbors_down: This health check returns successful only when all the neighbors are down.
  • min_neighbors_up: This health check takes min_count as input and returns successful only when the specified number of neighbors are up and running.

The following is an Ansible playbook example using action: health_check with all_neighbors_up and displaying the result:

---
- hosts: ios
  gather_facts: false
  tasks:
    - name: Network BGP Manager
      ansible.builtin.include_role:
        name: network.bgp.run
      vars:
        actions:
          - name: health_check
            vars:
              checks:
                - name: all_neighbors_up

Execute the Ansible playbook with the ansible-playbook command:

$ ansible-playbook example.yml -i inventory.yaml

Here is the result:

fatal: [192.168.122.220]: FAILED! => {
    "failed_when_result": true,
    "health_checks": {
        "all_neighbors_up": {
            "check_status": "unsuccessful",
            "down": 1,
            "total": 2,
            "up": 1
        },
        "status": "unsuccessful"
    }
}
…

Please note that all_neighbors_up failed. It failed because there were two BGP neighbors, and only one was in the Established state.

You can also perform a health check for a minimum number of neighbors. Use the details variable to get more details about the BGP neighborship state:

---
- hosts: ios
  gather_facts: false
  tasks:
    - name: Network BGP Manager
      ansible.builtin.include_role:
        name: network.bgp.run
      vars:
        actions:
          - name: health_check
            vars:
              details: true
              checks:
                - name: min_neighbors_up
                  min_count: 1

Execute the Ansible playbook with the ansible-playbook command:

$ ansible-playbook example.yml -i inventory.yaml

Here is the result:

TASK [network.bgp.run : BGP health checks] *************************************************************************
ok: [192.168.122.220] => {
    "failed_when_result": false,
    "health_checks": {
        "min_neighbors_up": {
            "check_status": "successful",
            "details": {
                "neighbors": [
                    {
                        "bgp_table_version": 3,
                        "input_queue": 0,
                        "msg_rcvd": 19169,
                        "msg_sent": 19183,
                        "output_queue": 0,
                        "peer": "12.0.0.1",
                        "peer_as": 500,
                        "peer_state": "Established",
                        "uptime": "1w5d",
                        "version": 4
                    }
                ]
            },
            "down": 1,
            "total": 2,
            "up": 1
        },
        "status": "successful"
    }
}

PLAY RECAP ***************************************************************
192.168.122.220              : ok=5    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
…

Note that you received a successful health check this time, as there was one BGP neighbor in the Established state. You also received detailed neighbor attributes including version and uptime.

Wrapping up

Network BGP-validated content helps enhance the experience of resource module consumption by providing production-ready content. By using the persist, gather, and deploy actions, network engineers can gain flexibility and adopt platform Network BGP automation. You can also perform the health check on BGP neighborship with health_check action.

See these resources to learn more about the Red Hat Ansible Automation Platform and network automation:


This article is based on Fundamentals of network automation with Ansible validated content using the network.base collection and the author's presentation at AnsibleFest 2022.

Topics:   Ansible   Networking  
Author’s photo

Rohit Thakur

Rohit Thakur is a Senior Software Engineer for Red Hat Ansible Automation. He brings over 8 years in development of telecommunication networks, optical networks, and network automation. More about me

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.