0% found this document useful (0 votes)
17 views6 pages

Ansible Playbook for Device Health Checks

The document provides an Ansible playbook for performing routine health checks on Cisco and Juniper network devices, assessing parameters like CPU usage, memory utilization, interface status, and hardware health. It includes detailed tasks for executing commands on both device types and capturing results for review. Additionally, prerequisites for running the playbook, such as required collections and inventory file setup, are outlined.

Uploaded by

samuela
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views6 pages

Ansible Playbook for Device Health Checks

The document provides an Ansible playbook for performing routine health checks on Cisco and Juniper network devices, assessing parameters like CPU usage, memory utilization, interface status, and hardware health. It includes detailed tasks for executing commands on both device types and capturing results for review. Additionally, prerequisites for running the playbook, such as required collections and inventory file setup, are outlined.

Uploaded by

samuela
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd

Below is an Ansible playbook to perform routine health checks on network devices

(such as Cisco or Juniper devices) to ensure they are operating optimally. This
script checks parameters like CPU usage, memory utilization, interface status, and
hardware health indicators.

---

### **Network Device Health Check Playbook**

#### **Playbook Code**


```yaml
---
- name: Perform Health Check on Network Devices
hosts: all
gather_facts: no
tasks:
- name: Check CPU usage on Cisco device
[Link].ios_command:
commands:
- show processes cpu sorted
register: cpu_result

- name: Check memory utilization on Cisco device


[Link].ios_command:
commands:
- show memory statistics
register: memory_result

- name: Check interface status on Cisco device


[Link].ios_command:
commands:
- show interfaces status
register: interface_result

- name: Check hardware health indicators on Cisco device


[Link].ios_command:
commands:
- show environment
register: hardware_result

- name: Print CPU usage result


debug:
var: cpu_result

- name: Print memory utilization result


debug:
var: memory_result

- name: Print interface status result


debug:
var: interface_result

- name: Print hardware health result


debug:
var: hardware_result

- name: Check CPU usage on Juniper device


[Link].junos_command:
commands:
- show system processes extensive
register: juniper_cpu_result

- name: Check memory utilization on Juniper device


[Link].junos_command:
commands:
- show system memory
register: juniper_memory_result

- name: Check interface status on Juniper device


[Link].junos_command:
commands:
- show interfaces terse
register: juniper_interface_result

- name: Check hardware health indicators on Juniper device


[Link].junos_command:
commands:
- show chassis hardware
register: juniper_hardware_result

- name: Print Juniper CPU usage result


debug:
var: juniper_cpu_result

- name: Print Juniper memory utilization result


debug:
var: juniper_memory_result

- name: Print Juniper interface status result


debug:
var: juniper_interface_result

- name: Print Juniper hardware health result


debug:
var: juniper_hardware_result
```

---

### **Explanation**

#### **Header and Setup**


1. **`---`**
Marks the beginning of the YAML file.

2. **`- name: Perform Health Check on Network Devices`**


This is the name of the play, indicating its purpose: performing health checks
on the network devices.

3. **`hosts: all`**
Specifies that the playbook should run on all the hosts in the inventory. These
can be Cisco and Juniper devices as defined in the inventory file.

4. **`gather_facts: no`**
Skips the fact gathering process, as it isn't necessary for this health check
task.

---
#### **Tasks for Cisco Devices**

5. **`- name: Check CPU usage on Cisco device`**


This task checks the CPU usage of the Cisco device.

6. **`[Link].ios_command:`**
Uses the `ios_command` module from the `[Link]` collection to run a command
on the Cisco device.

7. **`commands:`**
Specifies the command to be executed on the Cisco device. In this case, the
`show processes cpu sorted` command displays CPU utilization statistics.

8. **`register: cpu_result`**
Captures the output of the command in the `cpu_result` variable for later use.

9. **`- name: Check memory utilization on Cisco device`**


This task checks the memory utilization of the Cisco device.

10. **`commands:`**
Runs the command `show memory statistics`, which shows memory utilization on
the device.

11. **`register: memory_result`**


Captures the output of the memory check in the `memory_result` variable.

12. **`- name: Check interface status on Cisco device`**


This task checks the status of the interfaces on the Cisco device.

13. **`commands:`**
Runs the `show interfaces status` command to get interface status information
(up/down, administrative state).

14. **`register: interface_result`**


Captures the result of the interface status command in the `interface_result`
variable.

15. **`- name: Check hardware health indicators on Cisco device`**


This task checks the hardware health status of the Cisco device.

16. **`commands:`**
Runs the `show environment` command, which provides information about hardware
health such as temperature, fan status, and power supply.

17. **`register: hardware_result`**


Captures the result of the hardware health check in the `hardware_result`
variable.

18. **`- name: Print CPU usage result`**


This debug task prints the output of the CPU usage check to the console for
review.

19. **`debug:`**
The `debug` module is used to print variables for troubleshooting and
reporting.

20. **`var: cpu_result`**


Specifies the variable to be printed (`cpu_result`).
21. **`- name: Print memory utilization result`**
This debug task prints the output of the memory utilization check.

22. **`var: memory_result`**


Specifies the variable to be printed (`memory_result`).

23. **`- name: Print interface status result`**


This debug task prints the output of the interface status check.

24. **`var: interface_result`**


Specifies the variable to be printed (`interface_result`).

25. **`- name: Print hardware health result`**


This debug task prints the output of the hardware health check.

26. **`var: hardware_result`**


Specifies the variable to be printed (`hardware_result`).

---

#### **Tasks for Juniper Devices**

27. **`- name: Check CPU usage on Juniper device`**


This task checks the CPU usage on the Juniper device.

28. **`[Link].junos_command:`**
Uses the `junos_command` module from the `[Link]` collection to
execute commands on Juniper devices.

29. **`commands:`**
Specifies the command `show system processes extensive`, which displays CPU
statistics.

30. **`register: juniper_cpu_result`**


Captures the result of the command into the `juniper_cpu_result` variable.

31. **`- name: Check memory utilization on Juniper device`**


This task checks memory utilization on the Juniper device.

32. **`commands:`**
Runs the `show system memory` command to check memory usage.

33. **`register: juniper_memory_result`**


Captures the memory result in the `juniper_memory_result` variable.

34. **`- name: Check interface status on Juniper device`**


This task checks the interface status on the Juniper device.

35. **`commands:`**
Runs the `show interfaces terse` command, which provides concise information on
interface statuses.

36. **`register: juniper_interface_result`**


Captures the interface status result in the `juniper_interface_result`
variable.

37. **`- name: Check hardware health indicators on Juniper device`**


This task checks the hardware health on the Juniper device.
38. **`commands:`**
Runs the `show chassis hardware` command, which displays hardware health
indicators like the status of physical components (e.g., fans, temperature).

39. **`register: juniper_hardware_result`**


Captures the result of the hardware health check in the
`juniper_hardware_result` variable.

40. **`- name: Print Juniper CPU usage result`**


This debug task prints the output of the CPU usage check for the Juniper
device.

41. **`debug:`**
The `debug` module is used again to display the variable content.

42. **`var: juniper_cpu_result`**


Specifies the variable to be printed (`juniper_cpu_result`).

43. **`- name: Print Juniper memory utilization result`**


This debug task prints the output of the memory utilization check for the
Juniper device.

44. **`var: juniper_memory_result`**


Specifies the variable to be printed (`juniper_memory_result`).

45. **`- name: Print Juniper interface status result`**


This debug task prints the output of the interface status check for the Juniper
device.

46. **`var: juniper_interface_result`**


Specifies the variable to be printed (`juniper_interface_result`).

47. **`- name: Print Juniper hardware health result`**


This debug task prints the output of the hardware health check for the Juniper
device.

48. **`var: juniper_hardware_result`**


Specifies the variable to be printed (`juniper_hardware_result`).

---

### **Prerequisites**
1. **Install Required Collections**
Install the necessary Ansible collections for Cisco and Juniper devices:
```bash
ansible-galaxy collection install [Link] [Link]
```

2. **Define Inventory File**


Create an inventory file with your Cisco and Juniper devices. Example
(`[Link]`):
```yaml
cisco_devices:
hosts:
cisco_router:
ansible_host: [Link]
ansible_user: admin
ansible_password: admin
ansible_network_os: [Link]

juniper_devices:
hosts:
juniper_router:
ansible_host: [Link]
ansible_user: admin
ansible_password: admin
ansible_network_os: [Link]
```

3. **Run the Playbook**


Run the playbook to perform health checks:
```bash
ansible-playbook -i [Link] network_health_check.yml
```

---

### **Results**
- The playbook will output the CPU usage, memory utilization, interface statuses,
and hardware health for each device.
- It helps engineers proactively monitor device health and resolve issues before
they impact the network.

Common questions

Powered by AI

The playbook captures the output of each command execution into variables using the 'register' directive. It then uses the 'debug' module to print these results to the console. This makes the information readily available for engineers to review immediately, or capture in logs for further analysis, ensuring transparency and accessibility of critical health data .

The playbook uses different modules to execute commands on Cisco and Juniper devices. For Cisco devices, it employs the 'cisco.ios.ios_command' module with commands like 'show processes cpu sorted' for CPU checks and 'show memory statistics' for memory checks. For Juniper devices, it utilizes 'junipernetworks.junos.junos_command' with commands such as 'show system processes extensive' for CPU checks and 'show system memory' for memory checks. Though the specific commands differ, both systems follow similar structures for capturing and registering command outputs in variables .

The playbook performs hardware health checks by executing specific commands on the network devices. For Cisco devices, it runs the 'show environment' command and registers the output in 'hardware_result'. For Juniper devices, it utilizes the 'show chassis hardware' command and registers the result in 'juniper_hardware_result'. These outputs provide data on various physical components like temperature and fan status, essential for determining the devices' hardware condition .

Engineers can utilize the playbook outputs, such as CPU usage, memory utilization, interface statuses, and hardware health details, to proactively monitor the health of network devices. By analyzing this data, they can identify potential issues or performance degradations before they impact network operations, allowing for preemptive maintenance and minimizing downtime .

Before executing the playbook, it is necessary to install the required Ansible collections 'cisco.ios' and 'junipernetworks.junos'. Additionally, an inventory file must be defined, listing the network devices along with their IPs, login credentials, and relevant network OS types. Finally, the system running the playbook must have Ansible installed and configured correctly .

The inventory file specifies the network devices (like Cisco and Juniper routers) on which the playbook will be executed. It defines the hosts, their IP addresses, login credentials, and the network OS used. This allows Ansible to target the correct devices for running the specified health check commands, ensuring automation and ease of management across different network devices .

The 'register' keyword in an Ansible playbook is used to capture the output of a command or task into a variable. This allows the result to be accessed and used later in the playbook, such as printing it for debugging purposes or making decisions based on its content. For instance, in the playbook, outputs from commands like 'show processes cpu sorted' are stored in variables 'cpu_result' and can be printed or referenced subsequently .

The 'ansible_network_os' in the inventory file configuration specifies the network operating system of each target device (e.g., 'cisco.ios' for Cisco devices or 'juniper.junos' for Juniper devices). This designation ensures that Ansible uses the appropriate modules and command syntax for each device's OS, enabling correct and efficient task execution across heterogeneous network environments .

The Ansible playbook includes tasks to check CPU usage, memory utilization, interface status, and hardware health indicators on Cisco network devices. The commands used are: 'show processes cpu sorted' for CPU usage, 'show memory statistics' for memory utilization, 'show interfaces status' for interface status, and 'show environment' for hardware health .

The 'gather_facts: no' directive is used to skip the automatic gathering of system facts, which Ansible typically performs at the start of a playbook. In this specific context, it is not necessary because the health checks do not require these default system facts. Skipping this step can improve performance by reducing the playbook's execution time, especially if only specific commands and checks are needed .

You might also like