• Skip to main content
  • Skip to footer

Andrew Roderos

Networking and Security

  • Blog
  • Resources
    • Book List
    • Freebies
  • About
  • Contact

Ansible: Perform network availability check

05/01/2025 by Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

In my previous post, we explored validating IP addresses and conducting network availability checks on a firewall. While these checks are valid, they don’t provide a comprehensive view of the network’s overall status, especially in bigger networks. In this post, we’ll explore a playbook that can be incorporated to perform network availability checks. However, this may not be valid in some environments where ICMP is not allowed.

This post contains affiliate links, which means I may earn a commission if you click through and make a purchase. This comes at no additional cost to you. Full disclosure here.

The Ansible playbook

This Ansible playbook complements the previous post. While the previous playbook checks network availability against the target firewall, this playbook will perform a ping sweep on the user input address. However, it is important to note that this playbook is only effective in networks that allow ICMP packets.

Breaking it down

To help those folks who are new to Ansible, I will break down each section of the playbook.

- name: Run fping with Network Availability Check
  hosts: localhost
  connection: local
  gather_facts: false

The playbook begins by specifying its name, followed by the host or group of hosts to run the playbook against. In this example, we’re running it on the local machine (hosts: localhost) with a local connection. We’re not gathering facts about the system to speed up execution. In this case, the user will input the IP address and prefix by specifying it in the ansible-playbook -e command option.

First task

Update

Originally, the playbook assumed that the fping utility is installed on the control node, which is the machine from which Ansible CLI tools are executed.

To ensure that the fping is installed, add this task above the first task covered below.

    - name: Ensure fping is installed
      ansible.builtin.package:
        name: fping
        state: present

This task assumes fping is installed and runs the command against the user input network. The -ga option tells fping to generate a target list and show only live hosts. The {{ ipadd1 }} is a variable that should contain the IP address or network range to check. The result is stored in a variable called fping_result, and we ignore any errors to ensure the playbook continues even if fping encounters issues.

tasks:
    - name: Run fping against primary network
      ansible.builtin.command: "fping -ga {{ ipadd1 }}"
      register: fping_result
      ignore_errors: true

Running the playbook

Let’s test the first task and observe its behavior. In this case, I chose a network that I know there are live hosts.

$ ansible-playbook fping.yml -e "ipadd1=172.26.72.0/25"

PLAY [Run fping with Network Availability Check] ************************************************************************************************************************************************************************

TASK [Run fping against primary network] ********************************************************************************************************************************************************************************
fatal: [localhost]: FAILED! => {"changed": true, "cmd": ["fping", "-ga", "172.26.72.0/25"], <-- Output omitted for brevity -->
...ignoring

TASK [ansible.builtin.debug] ********************************************************************************************************************************************************************************************
ok: [localhost] => {
    "fping_result": {
        "changed": true,
        "cmd": [
            "fping",
            "-ga",
            "172.26.72.0/25"
        ],
        "delta": "0:00:06.237512",
        "end": "2025-04-27 17:21:47.020792",
        "failed": true,
        "msg": "non-zero return code",
        "rc": 1,
        "start": "2025-04-27 17:21:40.783280",
        "stderr": <-- Output omitted for brevity -->
        "stderr_lines": [
            "ICMP Host Unreachable from 172.26.72.56 for ICMP Echo sent to 172.26.72.3",
            "ICMP Host Unreachable from 172.26.72.56 for ICMP Echo sent to 172.26.72.3",
            "ICMP Host Unreachable from 172.26.72.56 for ICMP Echo sent to 172.26.72.3",
            "ICMP Host Unreachable from 172.26.72.56 for ICMP Echo sent to 172.26.72.3",
		<-- Output omitted for brevity -->
        ],
        "stdout": "172.26.72.1\n172.26.72.36\n172.26.72.43\n172.26.72.56\n172.26.72.64\n172.26.72.65\n172.26.72.67\n172.26.72.78\n172.26.72.27",
        "stdout_lines": [
            "172.26.72.1",
            "172.26.72.36",
            "172.26.72.43",
            "172.26.72.56",
            "172.26.72.64",
            "172.26.72.65",
            "172.26.72.67",
            "172.26.72.78",
        ]
    }
}

As expected, we can see that some hosts responded to the pings. Please note the stdout_lines, as we will be using it later.

If there are no live hosts, the stdout_lines will be an empty list, as shown below.

$ ansible-playbook fping.yml -e "ipadd1=172.26.73.0/25"

<-- Output omitted for brevity -->

        "stdout": "",
        "stdout_lines": []
    }
}

PLAY RECAP **************************************************************************************************************************************************************************************************************
localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=1

Second task

This task counts the number of hosts with successful responses from the network specified by the user. The ansible.builtin.set_fact module creates a new variable called successful_pings that counts the lines in our command output. We’re accessing fping_result.stdout_lines and piping it to the length Jinja filter to count each host that responded.

    - name: Count successful responses from network
      ansible.builtin.set_fact:
        successful_pings: "{{ fping_result.stdout_lines | length }}"

Running the playbook

As you can see, our second task successfully counted eight active hosts in the specified subnet. If you revisit the earlier task, it matches the count of the live hosts on the list.

$ ansible-playbook fping.yml -e "ipadd1=172.26.72.0/25"

PLAY [Run fping with Network Availability Check] ************************************************************************************************************************************************************************

TASK [Run fping against primary network] ********************************************************************************************************************************************************************************
fatal: [localhost]: FAILED! => {"changed": true, "cmd": ["fping", "-ga", "172.26.72.0/26"], <-- Output omitted for brevity -->
...ignoring

TASK [Count successful responses from network] **************************************************************************************************************************************************************************
ok: [localhost]

TASK [ansible.builtin.debug] ********************************************************************************************************************************************************************************************
ok: [localhost] => {
    "successful_pings": "8"
}

PLAY RECAP **************************************************************************************************************************************************************************************************************
localhost                  : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=1

Third task

The final task displays the network’s availability status by printing a message based on the conditions that are met. The content of the message is determined by a conditional statement. In this case, if there were any successful pings, it indicates that the network is not available because responding hosts suggest that the network is in use. If there were no successful pings, then it displays a message that the network is available.

    - name: Display network status
      ansible.builtin.debug:
        msg: >-
          {%- if successful_pings | int > 0 -%}
          Network {{ ipadd1 }} is not available ({{ successful_pings }} host(s) responded).
          {%- else -%}
          Network {{ ipadd1 }} is available (no hosts responded).
          {%- endif -%}

Let’s break down the message section of the task so that folks who are new to Jinja2 can understand it. The msg part defines what message will be displayed. The >- symbols tell Ansible to handle multiple lines of text while preserving formatting.

Inside the message, we have some decision-making logic using Jinja2 templating, the stuff inside the {%- and -%}. Take note that the hyphens (-) are just a way to control whitespace in the output, making the message look cleaner.

Want to learn more about Ansible?

Learn how to automate using Ansible

Ansible for DevOps

The if successful_pings | int > 0 part checks if any hosts responded to the ping test. The | int converts our count to a number for comparison. If that value is more than 0, then the Network 172.26.72.0/25 is not available (8 host(s) responded). will be displayed.

The else section triggers when no hosts respond and will show Network 172.26.72.0/25 is available (no hosts responded). message.

Running the playbook

Let’s test the playbook on two networks: one with live hosts and the other without.

With live hosts

As expected, the message displayed that the network was unavailable since there were eight hosts responded to the pings.

$ ansible-playbook fping.yml -e "ipadd1=172.26.72.0/25"

PLAY [Run fping with Network Availability Check] ************************************************************************************************************************************************************************

TASK [Run fping against primary network] ********************************************************************************************************************************************************************************
fatal: [localhost]: FAILED! => {"changed": true, "cmd": ["fping", "-ga", "172.26.72.0/25"], <-- Output omitted for brevity -->
...ignoring

TASK [Count successful responses from network] **************************************************************************************************************************************************************************
ok: [localhost]

TASK [Display network status] *******************************************************************************************************************************************************************************************
ok: [localhost] => {
    "msg": "Network 172.26.72.0/25 is not available (8 host(s) responded)."
}

PLAY RECAP **************************************************************************************************************************************************************************************************************
localhost                  : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=1

Without live hosts

As expected, the message displayed that the network was available since no hosts responded to the pings.

$ ansible-playbook fping.yml -e "ipadd1=172.26.73.0/25"

PLAY [Run fping with Network Availability Check] ************************************************************************************************************************************************************************

TASK [Run fping against primary network] ********************************************************************************************************************************************************************************
fatal: [localhost]: FAILED! => {"changed": true, "cmd": ["fping", "-ga", "172.26.73.0/25"], <-- Output omitted for brevity -->
...ignoring

TASK [Count successful responses from network] **************************************************************************************************************************************************************************
ok: [localhost]

TASK [Display network status] *******************************************************************************************************************************************************************************************
ok: [localhost] => {
    "msg": "Network 172.26.73.0/25 is available (no hosts responded)."
}

PLAY RECAP **************************************************************************************************************************************************************************************************************
localhost                  : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=1

Final words

This playbook provides a simple yet effective way to check network availability. By running fping and analyzing its output, we can quickly determine if a network is free or in use. Incorporating this playbook can save time and reduce the chance of human error in network management tasks.

Related posts

Ansible: Accepting user input variables
Ansible: Cisco Login Banner

BUY ME COFFEE

Did you find this content useful?
If so, show your appreciation by buying me a coffee!

☕️ Buy me a coffee

Disclosure

AndrewRoderos.com is a participant of a few referral programs, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to company websites.

Filed Under: Automation Tagged With: Ansible, Linux, Network Automation

About Andrew Roderos

I am a network security engineer with a passion for networking and security. Follow me on Twitter, LinkedIn, and Instagram.

Footer

WANT TO REACH ME?

Let’s talk!

CONTACT ME

Copyright © 2019–2026 · Andrew Roderos · All Rights Reserved · Privacy Policy · Terms of Use