13 Apr

Use Ansible to check SNMP on remote device

Best way to learn Ansible and the whole idea of automation is to start from the small playbooks and then grow big. If you first automate simple tasks, even those that may be easier and quicker to perform from the command line, you will learn how Ansible is working. Let’s say, we want to test if SNMP is responding on the remote host (we name it HostA). We will use SNMPv3 and authPriv security model. And of course, we want to write the Ansible playbook and run it on server HostNOC.

The local_action module

There is no standard Ansible module that will let us execute any SNMP query. So we need to find another way. In the first scenario, I will use the local_action module and execute snmpget or snmpwalk directly on Ansible host. Remeber to install SNMP package from your Linux distribution first on Ansible host. The local_action just run the command on a local system and returns its output.

---
- name: Check if SNMPv3 is working on remote host
  hosts: node_HostA
  connection: local
  gather_facts: no

  tasks:
    - name: Test SNMPv3
      local_action: command snmpwalk -v 3 -l authPriv -a SHA -A snmppasswd -x AES -X snmppasswd {{ inventory_hostname }} .1
      register: response

    - name: Print the complete response
      debug:
        var: response

 

Let’s use Ansible SNMP module

In the second playbook, I will use module snmp_fact. This module is designed to gather basic pieces of information about remote node using the SNMP protocol and insert them into ansible_facts key. We do not need this information, but depending on task result we will be able to determinate if SNMP on the remote host is responding or not.

Our playbook code:

---
- name: Check if SNMPv3 is working on remote host
  hosts: node_HostA
  connection: local
  gather_facts: no

  tasks:
    - name: Test SNMPv3
      snmp_facts:
        level: authPriv
        version: v3
        host: '{{ inventory_hostname }}'
        authkey: snmppasswd
        privkey: snmppasswd
        username: snmpuser
        privacy: aes
        integrity: sha
      register: response
      ignore_errors: True

    - name: Print the complete response
      debug:
        var: response

There are two tasks in this playbook. First one will run the snmp_facts module to query remote node. There is a list of parameters we need to provide for successful authentication. Check module documentation for a full list and parameters related to older versions of SNMP.

PLAY [Check if SNMPv3 is working on remote host] ***************************************************************************************************************************************************

TASK [Test SNMPv3] *********************************************************************************************************************************************************************************
fatal: [172.16.1.114]: FAILED! {"changed": false, "msg": "No SNMP response received before timeout"}
...ignoring

TASK [Print the complete response] *****************************************************************************************************************************************************************
ok: [172.16.1.114] {
 "response": {
 "changed": false, 
 "failed": true, 
 "msg": "No SNMP response received before timeout"
 }
}

PLAY RECAP *****************************************************************************************************************************************************************************************
172.16.1.114 : ok=2 changed=0 unreachable=0 failed=0

You can see the playbook failed because SNMP was not responding. Please notice I did a small trick in the playbook code. By setting the task flag ignore_error to True I made the playbook continue to next task, even if snmp_facts fails. The ansible_facts key is registered as a response variable. It will contain a result of SNMP query or error message. By ignoring the failure of the task we can either display error message in the second task as a part of a whole structure, or process it by an external filter or in other tasks. So failure is not always a bad thing if we know what we are doing.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

This website stores some user agent data. These data are used to provide a more personalized experience and to track your whereabouts around our website in compliance with the European General Data Protection Regulation. If you decide to opt-out of any future tracking, a cookie will be set up in your browser to remember this choice for one year. I Agree, Deny
596
%d bloggers like this: