This knowledge base has moved to the documentation site. Please visit the knowledge base here for the most up to date content. This site is no longer maintained.

Ansible: Gathering Facts on Cumulus Linux

Follow

This article outlines the process for using Ansible in a lab environment to gather information (which Ansible calls facts) about a Cumulus Linux switch, where Ansible is run off of a physical server or virtual machine on the same network as the switch.

Requirements

  • A Cumulus Linux switch
  • A host running Ansible
  • Set up a basic Ansible lab, or have an understanding of and past experience with Ansible

How to Gather Facts from the CLI

  1. Make sure the hostname is in DNS. Ping the DNS hostname of the Cumulus Linux switch:
    sean at server in ~
    $ ping sw1
    PING sw1 (192.168.100.11) 56(84) bytes of data.
    64 bytes from sw1 (192.168.100.11): icmp_req=1 ttl=64 time=0.197 ms
    64 bytes from sw1 (192.168.100.11): icmp_req=2 ttl=64 time=0.163 ms
    ^C
    --- sw1 ping statistics ---
    2 packets transmitted, 2 received, 0% packet loss, time 1000ms
    rtt min/avg/max/mdev = 0.163/0.180/0.197/0.017 ms sean at server in ~
    $
  2. Utilize the Ansible setup command, where sw1 is the DNS name of your switch1, where -m means which module you are selecting to run, --ask-pass will prompt you for the password (most automation environments utilize SSH keys for authentication instead of passwords), -vvvv gives you all the debugs (not needed but will help you troubleshoot) and -u root makes the user root instead of your login to the host device running Ansible.
    ansible sw1 -m setup --ask-pass -vvvv -u root
  3. Ansible will connect to the switch utilizing the provided user (in this case, root) and the provided password. This should be the exact same way a user would connect to the switch via SSH. If able to connect, Ansible will run the setup module and gather facts about the Cumulus switch.

What Facts are Gathered?

Ansible will gather numerous facts. For this article, a DNI et-7448bf model running Cumulus Linux 2.0.1 was used. Some facts will be highlighted here that were found important for a playbook being written. The entire results of the setup command can be found here.

The version of Cumulus Linux

  • What is returned by the setup command?
     "ansible_lsb": { 
    "description": "2.0.1-fffbbda-201403232243-final",
    "id": "\"Cumulus Networks\"",
    "major_release": "2",
    "release": "2.0.1"
    },
  • An example utilizing the variable:
    - name: install image file (installs to opposite slot)
    command: /usr/cumulus/bin/cl-img-install -f http://192.168.100.1/{{ image }}
    when: ansible_lsb.release not in image

The above task in a playbook can use any fact gathered in the setup command (run automatically on any playbook unless purposelessly turned off). This example utilizes the ansible_lsb.release variable obtained in setup and compares it to the example playbook's specific variable of {{image}}. The playbook being written would upgrade the Cumulus switch for this task utilizing the cl-img-install command. Creating a conditional statement utilizing "when:" keeps you from wasting time installing unless the image given by the user running this playbook was different than the image currently running on the switch {{ansible_lsb.release}}.

The Hostname

  • What is returned by the setup command?
     "ansible_hostname": "sw1",
  • An example utilizing the variable:
    - name: configure MOTD with version # for user
    lineinfile: dest=/etc/motd regexp='^sw.*bin$' line='{{ ansible_hostname }} - running version {{ image }}' backrefs=yes
    register: result

This example utilizes the hostname as well as the internal variable {{image}}, which is not returned by the Ansible setup gathering the facts. The above task updates the MOTD on the Cumulus Linux switch with the current hostname and what image the switch is running. An example would be: sw1 - running version CumulusLinux-2.0.1-powerpc.bin.

The Management MAC Address

  • What is returned by the setup command?
    "ansible_eth0": { 
    "active": true,
    "device": "eth0",
    "ipv4": {
    "address": "192.168.100.11",
    "netmask": "255.255.255.0",
    "network": "192.168.100.0"
    },
    "ipv6": [
    {
    "address": "fe80::4638:39ff:fe00:3410",
    "prefix": "64",
    "scope": "link"
    }
    ],
    "macaddress": "44:38:39:00:34:10",
    "mtu": 1500,
    "promisc": false,
    "type": "ether"
    },
  • An example utilizing the variable:
    - name: writing report to /var/log/mac-script.log
    shell: "echo {{ansible_hostname}}: Script Completed Successfully at {{ansible_date_time.time}} - Version {{ansible_lsb.release}} MAC for eth0 is {{ansible_etho.macaddress}} >> /tmp/upgrade-script.log"
    delegate_to: 127.0.0.1

An example output for this task would be "sw1: Script Completed Successfully at 18:53:24 - Version 2.0.1 MAC for eth0 is 44:38:39:00:34:10". The script above outputs that text to a file it creates called upgrade-script.log, located in the /tmp/ directory.

Comments

This support portal has moved

Cumulus Networks is now part of the NVIDIA Networking Business Unit! The NVIDIA Cumulus Global Support Services (GSS) team has merged its operations with the NVIDIA Mellanox support services team.

You can access NVIDIA Cumulus support content from the Mellanox support portal.

You open and update new cases on the Mellanox support portal. Any previous cases that have been closed have been migrated to the Mellanox support portal.

Cases that are still open on the Cumulus portal will continue to be managed on the Cumulus portal. Once these cases close, they will be moved to the Mellanox support portal.

Powered by Zendesk