Bookmark this page

Overcoming Real-world Challenges

Objectives

After completing this section, you should be able to employ Ansible to verify reachability between two network devices.

Verifying Reachability With ICMP

The Internet Control Message Protocol (ICMP), defined in RFC 792, is part of the Internet Protocol Suite. It was designed to provide a mechanism by which connecting devices communicate with end stations, such as a source hosts. It is best known today for testing reachability.

It is often useful to control which interface traffic is being sourced from when testing reachability. Both IOS and VyOS support this on the CLI, using slightly different syntaxes.

IOS extended ping is most familiar in a menu-driven form, but supports a single-line form. Many options are available; the following is a simple example:

# ping destination source source-ip-or-interface repeat repeatcount

The following is an example of the extended form of ping available under VyOS:

$ ping destination interface source-ip-or-interface count repeatcount

Generating ping Packets

The use of ping to verify reachability is illustrated here on VyOS.

The method is nearly identical with IOS, but uses the vyos_command module instead of ios_command, and uses the slightly different VyOS extended ping command syntax.

---
- name: test reachability using ICMP
  hosts: vyos
  gather_facts: no
  vars:
    count: 3
    # (to) and (fr) vars (destination and source interface IPs) are --extra-vars
    cmds: [ "ping {{ to }} interface {{ fr }} count {{ count }}" ]

  tasks:

    - name: on {{ inventory_hostname }} to {{ to }} from {{ fr }}
      vyos_command:
        commands: "{{ cmds }}"
      register: ping_result
      when: ansible_network_os == 'vyos'

    - name: display the result
      debug:
        msg: "{{ ping_result }}"

Viewing Results

The play from the example is performed and the results are shown here.

$ ansible-playbook -l spine01 -e"fr=10.10.5.1 to=10.10.5.2" \
> vyos-sourced-icmp-ping.yml

PLAY [test reachability using ICMP]
*******************************************************************************

TASK [on spine01 to 10.10.5.2 from 10.10.5.1]
*******************************************************************************
ok: [spine01]

TASK [display the result]
*******************************************************************************
ok: [spine01] => {
    "msg": {
        "changed": false,
        "failed": false,
        "stdout": [
            "PING 10.10.5.2 (10.10.5.2) from 10.10.5.1 : 56(84) bytes of data.\n64 bytes from 10.10.5.2: icmp_req=1 ttl=64 time=0.236 ms\n64 bytes from 10.10.5.2: icmp_req=2 ttl=64 time=0.287 ms\n64 bytes from 10.10.5.2: icmp_req=3 ttl=64 time=0.278 ms\n\n--- 10.10.5.2 ping statistics ---\n3 packets transmitted, 3 received, 0% packet loss, time 1998ms\nrtt min/avg/max/mdev = 0.236/0.267/0.287/0.022 ms"
        ],
        "stdout_lines": [
            [
                "PING 10.10.5.2 (10.10.5.2) from 10.10.5.1 : 56(84) bytes of data.",
                "64 bytes from 10.10.5.2: icmp_req=1 ttl=64 time=0.236 ms",
                "64 bytes from 10.10.5.2: icmp_req=2 ttl=64 time=0.287 ms",
                "64 bytes from 10.10.5.2: icmp_req=3 ttl=64 time=0.278 ms",
                "",
                "--- 10.10.5.2 ping statistics ---",
                "3 packets transmitted, 3 received, 0% packet loss, time 1998ms",
                "rtt min/avg/max/mdev = 0.236/0.267/0.287/0.022 ms"
            ]
        ]
    }
}

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

Redesigning For Consolidation

The consolidation phase: cloud plus a data center.

Figure 6.1: The consolidation phase
Revision: do457-2.5-4693601