Network automation with Ansible validated content
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:
- Network automation guide
- Network automation hands-on self-paced labs
- Automate your network eBook
- Network automation web page
- Overview of Ansible's integration with various networking solutions
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.
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