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
persistaction 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
gatheraction enables users to gather and display the BGP global and address family facts. - Deploy changes: The
deployaction enables users to deploy the host_vars facts changes to the device. - BGP health checks: The
health_checkaction 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
successfulonly when all the BGP neighbors are up and running. - all_neighbors_down: This health check returns
successfulonly when all the neighbors are down. - min_neighbors_up: This health check takes
min_countas 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.
Sull'autore
Altri risultati simili a questo
Red Hat Ansible Automation Platform: Measuring Business Impact with Dashboard and Analytics
A 5-step playbook for unified automation and AI
Technically Speaking | Taming AI agents with observability
Building practical self-healing IT | Technically Speaking
Ricerca per canale
Automazione
Novità sull'automazione IT di tecnologie, team e ambienti
Intelligenza artificiale
Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque
Hybrid cloud open source
Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido
Sicurezza
Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti
Edge computing
Aggiornamenti sulle piattaforme che semplificano l'operatività edge
Infrastruttura
Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale
Applicazioni
Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili
Virtualizzazione
Il futuro della virtualizzazione negli ambienti aziendali per i carichi di lavoro on premise o nel cloud