update Network Advanced Topics for FQCN (#71325)
* update Network Advanced Topics for FQCN
This commit is contained in:
Sandra McCann
GitHub
parent
f82a1e06d7
commit
b6f10b9b52
7 changed files with 138 additions and 181 deletions
|
|
@ -20,7 +20,7 @@ The ``strategy`` plugin tells Ansible how to order multiple tasks on multiple ho
|
|||
|
||||
The default strategy is ``linear``. With strategy set to ``linear``, Ansible waits until the current task has run on all hosts before starting the next task on any host. Ansible may have forks free, but will not use them until all hosts have completed the current task. If each task in your playbook must succeed on all hosts before you run the next task, use the ``linear`` strategy.
|
||||
|
||||
Using the ``free`` strategy, Ansible uses available forks to execute tasks on each host as quickly as possible. Even if an earlier task is still running on one host, Ansible executes later tasks on other hosts. The ``free`` strategy uses available forks more efficiently. If your playbook stalls on each task, waiting for one slow host, consider using ``strategy: free`` to boost overall performance.
|
||||
Using the ``free`` strategy, Ansible uses available forks to execute tasks on each host as quickly as possible. Even if an earlier task is still running on one host, Ansible executes later tasks on other hosts. The ``free`` strategy uses available forks more efficiently. If your playbook stalls on each task, waiting for one slow host, consider using ``strategy: free`` to boost overall performance.
|
||||
|
||||
.. _network_faq_limit_show_running:
|
||||
|
||||
|
|
@ -41,7 +41,7 @@ Network modules support the use of a :ref:`proxy or jump host<network_delegate_t
|
|||
Set ``--forks`` to match your needs
|
||||
---------------------------------------------------------------------------------
|
||||
|
||||
Every time Ansible runs a task, it forks its own process. The ``--forks`` parameter defines the number of concurrent tasks - if you retain the default setting, which is ``--forks=5``, and you are running a playbook on 10 hosts, five of those hosts will have to wait until a fork is available. Of course, the more forks you allow, the more memory and processing power Ansible will use. Since most network tasks are run on the control host, this means your laptop can quickly become cpu- or memory-bound.
|
||||
Every time Ansible runs a task, it forks its own process. The ``--forks`` parameter defines the number of concurrent tasks - if you retain the default setting, which is ``--forks=5``, and you are running a playbook on 10 hosts, five of those hosts will have to wait until a fork is available. Of course, the more forks you allow, the more memory and processing power Ansible will use. Since most network tasks are run on the control host, this means your laptop can quickly become cpu- or memory-bound.
|
||||
|
||||
.. _network_faq_redacted_output:
|
||||
|
||||
|
|
@ -70,7 +70,7 @@ To avoid this problem, use long-form commands with the ``*_config`` modules:
|
|||
- hosts: all
|
||||
gather_facts: no
|
||||
tasks:
|
||||
- ios_config:
|
||||
- cisco.ios.ios_config:
|
||||
lines:
|
||||
- shutdown
|
||||
parents: interface GigabitEthernet1/0/11
|
||||
|
|
|
|||
|
|
@ -17,8 +17,8 @@ If you're new to Ansible, or new to using Ansible for network automation, start
|
|||
:caption: Advanced Topics
|
||||
|
||||
network_resource_modules
|
||||
faq
|
||||
network_best_practices_2.5
|
||||
network_debug_troubleshooting
|
||||
network_working_with_command_output
|
||||
faq
|
||||
platform_index
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Prerequisites
|
|||
|
||||
This example requires the following:
|
||||
|
||||
* **Ansible 2.5** (or higher) installed. See :ref:`intro_installation_guide` for more information.
|
||||
* **Ansible 2.10** (or higher) installed. See :ref:`intro_installation_guide` for more information.
|
||||
* One or more network devices that are compatible with Ansible.
|
||||
* Basic understanding of YAML :ref:`yaml_syntax`.
|
||||
* Basic understanding of Jinja2 templates. See :ref:`playbooks_templating` for more information.
|
||||
|
|
@ -35,7 +35,7 @@ Because Ansible is a flexible tool, there are a number of ways to specify connec
|
|||
|
||||
[all:vars]
|
||||
# these defaults can be overridden for any group in the [group:vars] section
|
||||
ansible_connection=network_cli
|
||||
ansible_connection=ansible.netcommon.network_cli
|
||||
ansible_user=ansible
|
||||
|
||||
[switches:children]
|
||||
|
|
@ -52,7 +52,7 @@ Because Ansible is a flexible tool, there are a number of ways to specify connec
|
|||
[eos:vars]
|
||||
ansible_become=yes
|
||||
ansible_become_method=enable
|
||||
ansible_network_os=eos
|
||||
ansible_network_os=arista.eos.eos
|
||||
ansible_user=my_eos_user
|
||||
ansible_password=my_eos_password
|
||||
|
||||
|
|
@ -64,7 +64,7 @@ Because Ansible is a flexible tool, there are a number of ways to specify connec
|
|||
[ios:vars]
|
||||
ansible_become=yes
|
||||
ansible_become_method=enable
|
||||
ansible_network_os=ios
|
||||
ansible_network_os=cisco.ios.ios
|
||||
ansible_user=my_ios_user
|
||||
ansible_password=my_ios_password
|
||||
|
||||
|
|
@ -74,7 +74,7 @@ Because Ansible is a flexible tool, there are a number of ways to specify connec
|
|||
vyos03 ansible_host=vyos-03.example.net
|
||||
|
||||
[vyos:vars]
|
||||
ansible_network_os=vyos
|
||||
ansible_network_os=vyos.vyos.vyos
|
||||
ansible_user=my_vyos_user
|
||||
ansible_password=my_vyos_password
|
||||
|
||||
|
|
@ -111,9 +111,9 @@ The following variables are common for all platforms in the inventory, though th
|
|||
|
||||
:ansible_connection:
|
||||
|
||||
Ansible uses the ansible-connection setting to determine how to connect to a remote device. When working with Ansible Networking, set this to ``network_cli`` so Ansible treats the remote node as a network device with a limited execution environment. Without this setting, Ansible would attempt to use ssh to connect to the remote and execute the Python script on the network device, which would fail because Python generally isn't available on network devices.
|
||||
Ansible uses the ansible-connection setting to determine how to connect to a remote device. When working with Ansible Networking, set this to an appropriate network connection option, such as``ansible.netcommon.network_cli``, so Ansible treats the remote node as a network device with a limited execution environment. Without this setting, Ansible would attempt to use ssh to connect to the remote and execute the Python script on the network device, which would fail because Python generally isn't available on network devices.
|
||||
:ansible_network_os:
|
||||
Informs Ansible which Network platform this hosts corresponds to. This is required when using ``network_cli`` or ``netconf``.
|
||||
Informs Ansible which Network platform this hosts corresponds to. This is required when using the ``ansible.netcommon.*`` connection options.
|
||||
:ansible_user: The user to connect to the remote device (switch) as. Without this the user that is running ``ansible-playbook`` would be used.
|
||||
Specifies which user on the network device the connection
|
||||
:ansible_password:
|
||||
|
|
@ -126,13 +126,13 @@ The following variables are common for all platforms in the inventory, though th
|
|||
Privilege escalation
|
||||
--------------------
|
||||
|
||||
Certain network platforms, such as Arista EOS and Cisco IOS, have the concept of different privilege modes. Certain network modules, such as those that modify system state including users, will only work in high privilege states. Ansible supports ``become`` when using ``connection: network_cli``. This allows privileges to be raised for the specific tasks that need them. Adding ``become: yes`` and ``become_method: enable`` informs Ansible to go into privilege mode before executing the task, as shown here:
|
||||
Certain network platforms, such as Arista EOS and Cisco IOS, have the concept of different privilege modes. Certain network modules, such as those that modify system state including users, will only work in high privilege states. Ansible supports ``become`` when using ``connection: ansible.netcommon.network_cli``. This allows privileges to be raised for the specific tasks that need them. Adding ``become: yes`` and ``become_method: enable`` informs Ansible to go into privilege mode before executing the task, as shown here:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[eos:vars]
|
||||
ansible_connection=ansible.netcommon.network_cli
|
||||
ansible_network_os=eos
|
||||
ansible_network_os=arista.eos.eos
|
||||
ansible_become=yes
|
||||
ansible_become_method=enable
|
||||
|
||||
|
|
@ -142,16 +142,16 @@ For more information, see the :ref:`using become with network modules<become_net
|
|||
Jump hosts
|
||||
----------
|
||||
|
||||
If the Ansible Controller doesn't have a direct route to the remote device and you need to use a Jump Host, please see the :ref:`Ansible Network Proxy Command <network_delegate_to_vs_ProxyCommand>` guide for details on how to achieve this.
|
||||
If the Ansible Controller does not have a direct route to the remote device and you need to use a Jump Host, please see the :ref:`Ansible Network Proxy Command <network_delegate_to_vs_ProxyCommand>` guide for details on how to achieve this.
|
||||
|
||||
Example 1: collecting facts and creating backup files with a playbook
|
||||
=====================================================================
|
||||
|
||||
Ansible facts modules gather system information 'facts' that are available to the rest of your playbook.
|
||||
|
||||
Ansible Networking ships with a number of network-specific facts modules. In this example, we use the ``_facts`` modules :ref:`eos_facts <eos_facts_module>`, :ref:`ios_facts <ios_facts_module>` and :ref:`vyos_facts <vyos_facts_module>` to connect to the remote networking device. As the credentials are not explicitly passed via module arguments, Ansible uses the username and password from the inventory file.
|
||||
Ansible Networking ships with a number of network-specific facts modules. In this example, we use the ``_facts`` modules :ref:`arista.eos.eos_facts <ansible_collections.arista.eos.eos_facts_module>`, :ref:`cisco.ios.ios_facts <ansible_collections.cisco.ios.ios_facts_module>` and :ref:`vyos.vyos.vyos_facts <ansible_collections.vyos.vyos.vyos_facts_module>` to connect to the remote networking device. As the credentials are not explicitly passed with module arguments, Ansible uses the username and password from the inventory file.
|
||||
|
||||
Ansible's "Network Fact modules" gather information from the system and store the results in facts prefixed with ``ansible_net_``. The data collected by these modules is documented in the `Return Values` section of the module docs, in this case :ref:`eos_facts <eos_facts_module>` and :ref:`vyos_facts <vyos_facts_module>`. We can use the facts, such as ``ansible_net_version`` late on in the "Display some facts" task.
|
||||
Ansible's "Network Fact modules" gather information from the system and store the results in facts prefixed with ``ansible_net_``. The data collected by these modules is documented in the `Return Values` section of the module docs, in this case :ref:`arista.eos.eos_facts <ansible_collections.arista.eos.eos_facts_module>` and :ref:`vyos.vyos.vyos_facts <ansible_collections.vyos.vyos.vyos_facts_module>`. We can use the facts, such as ``ansible_net_version`` late on in the "Display some facts" task.
|
||||
|
||||
To ensure we call the correct mode (``*_facts``) the task is conditionally run based on the group defined in the inventory file, for more information on the use of conditionals in Ansible Playbooks see :ref:`the_when_statement`.
|
||||
|
||||
|
|
@ -196,15 +196,15 @@ Next, create a playbook file called ``facts-demo.yml`` containing the following:
|
|||
#
|
||||
- name: Gather facts (eos)
|
||||
arista.eos.eos_facts:
|
||||
when: ansible_network_os == 'eos'
|
||||
when: ansible_network_os == 'arista.eos.eos'
|
||||
|
||||
- name: Gather facts (ios)
|
||||
cisco.ios.ios_facts:
|
||||
when: ansible_network_os == 'ios'
|
||||
when: ansible_network_os == 'cisco.ios.ios'
|
||||
|
||||
- name: Gather facts (vyos)
|
||||
vyos.vyos.vyos_facts:
|
||||
when: ansible_network_os == 'vyos'
|
||||
when: ansible_network_os == 'vyos.vyos.vyos'
|
||||
|
||||
###
|
||||
# Demonstrate variables
|
||||
|
|
@ -255,13 +255,13 @@ Next, create a playbook file called ``facts-demo.yml`` containing the following:
|
|||
arista.eos.eos_config:
|
||||
backup: yes
|
||||
register: backup_eos_location
|
||||
when: ansible_network_os == 'eos'
|
||||
when: ansible_network_os == 'arista.eos.eos'
|
||||
|
||||
- name: backup switch (vyos)
|
||||
vyos.vyos.vyos_config:
|
||||
backup: yes
|
||||
register: backup_vyos_location
|
||||
when: ansible_network_os == 'vyos'
|
||||
when: ansible_network_os == 'vyos.vyos.vyos'
|
||||
|
||||
- name: Create backup dir
|
||||
file:
|
||||
|
|
@ -273,13 +273,13 @@ Next, create a playbook file called ``facts-demo.yml`` containing the following:
|
|||
copy:
|
||||
src: "{{ backup_eos_location.backup_path }}"
|
||||
dest: "/tmp/backups/{{ inventory_hostname }}/{{ inventory_hostname }}.bck"
|
||||
when: ansible_network_os == 'eos'
|
||||
when: ansible_network_os == 'arista.eos.eos'
|
||||
|
||||
- name: Copy backup files into /tmp/backups/ (vyos)
|
||||
copy:
|
||||
src: "{{ backup_vyos_location.backup_path }}"
|
||||
dest: "/tmp/backups/{{ inventory_hostname }}/{{ inventory_hostname }}.bck"
|
||||
when: ansible_network_os == 'vyos'
|
||||
when: ansible_network_os == 'vyos.vyos.vyos'
|
||||
|
||||
Step 3: Running the playbook
|
||||
----------------------------
|
||||
|
|
@ -325,10 +325,10 @@ Example 2: simplifying playbooks with network agnostic modules
|
|||
|
||||
(This example originally appeared in the `Deep Dive on cli_command for Network Automation <https://www.ansible.com/blog/deep-dive-on-cli-command-for-network-automation>`_ blog post by Sean Cavanaugh -`@IPvSean <https://github.com/IPvSean>`_).
|
||||
|
||||
If you have two or more network platforms in your environment, you can use the network agnostic modules to simplify your playbooks. You can use network agnostic modules such as ``cli_command`` or ``cli_config`` in place of the platform-specific modules such as ``eos_config``, ``ios_config``, and ``junos_config``. This reduces the number of tasks and conditionals you need in your playbooks.
|
||||
If you have two or more network platforms in your environment, you can use the network agnostic modules to simplify your playbooks. You can use network agnostic modules such as ``ansible.netcommon.cli_command`` or ``ansible.netcommon.cli_config`` in place of the platform-specific modules such as ``arista.eos.eos_config``, ``cisco.ios.ios_config``, and ``junipernetworks.junos.junos_config``. This reduces the number of tasks and conditionals you need in your playbooks.
|
||||
|
||||
.. note::
|
||||
Network agnostic modules require the :ref:`network_cli <network_cli_connection>` connection plugin.
|
||||
Network agnostic modules require the :ref:`ansible.netcommon.network_cli <ansible_collections.ansible.netcommon.network_cli_connection>` connection plugin.
|
||||
|
||||
|
||||
Sample playbook with platform-specific modules
|
||||
|
|
@ -342,29 +342,29 @@ This example assumes three platforms, Arista EOS, Cisco NXOS, and Juniper JunOS.
|
|||
- name: Run Arista command
|
||||
arista.eos.eos_command:
|
||||
commands: show ip int br
|
||||
when: ansible_network_os == 'eos'
|
||||
when: ansible_network_os == 'arista.eos.eos'
|
||||
|
||||
- name: Run Cisco NXOS command
|
||||
cisco.nxos.nxos_command:
|
||||
commands: show ip int br
|
||||
when: ansible_network_os == 'nxos'
|
||||
when: ansible_network_os == 'cisco.nxos.nxos'
|
||||
|
||||
- name: Run Vyos command
|
||||
vyos.vyos.vyos_command:
|
||||
commands: show interface
|
||||
when: ansible_network_os == 'vyos'
|
||||
when: ansible_network_os == 'vyos.vyos.vyos'
|
||||
|
||||
Simplified playbook with ``cli_command`` network agnostic module
|
||||
----------------------------------------------------------------
|
||||
|
||||
You can replace these platform-specific modules with the network agnostic ``cli_command`` module as follows:
|
||||
You can replace these platform-specific modules with the network agnostic ``ansible.netcommon.cli_command`` module as follows:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
---
|
||||
- hosts: network
|
||||
gather_facts: false
|
||||
connection: network_cli
|
||||
connection: ansible.netcommon.network_cli
|
||||
|
||||
tasks:
|
||||
- name: Run cli_command on Arista and display results
|
||||
|
|
@ -377,7 +377,7 @@ You can replace these platform-specific modules with the network agnostic ``cli_
|
|||
- name: Display result to terminal window
|
||||
debug:
|
||||
var: result.stdout_lines
|
||||
when: ansible_network_os == 'eos'
|
||||
when: ansible_network_os == 'arista.eos.eos'
|
||||
|
||||
- name: Run cli_command on Cisco IOS and display results
|
||||
block:
|
||||
|
|
@ -389,7 +389,7 @@ You can replace these platform-specific modules with the network agnostic ``cli_
|
|||
- name: Display result to terminal window
|
||||
debug:
|
||||
var: result.stdout_lines
|
||||
when: ansible_network_os == 'ios'
|
||||
when: ansible_network_os == 'cisco.ios.ios'
|
||||
|
||||
- name: Run cli_command on Vyos and display results
|
||||
block:
|
||||
|
|
@ -401,7 +401,7 @@ You can replace these platform-specific modules with the network agnostic ``cli_
|
|||
- name: Display result to terminal window
|
||||
debug:
|
||||
var: result.stdout_lines
|
||||
when: ansible_network_os == 'vyos'
|
||||
when: ansible_network_os == 'vyos.vyos.vyos'
|
||||
|
||||
|
||||
If you use groups and group_vars by platform type, this playbook can be further simplified to :
|
||||
|
|
@ -422,10 +422,10 @@ If you use groups and group_vars by platform type, this playbook can be further
|
|||
|
||||
You can see a full example of this using group_vars and also a configuration backup example at `Network agnostic examples <https://github.com/network-automation/agnostic_example>`_.
|
||||
|
||||
Using multiple prompts with the ``cli_command``
|
||||
------------------------------------------------
|
||||
Using multiple prompts with the ``ansible.netcommon.cli_command``
|
||||
-------------------------------------------------------------------
|
||||
|
||||
The ``cli_command`` also supports multiple prompts.
|
||||
The ``ansible.netcommon.cli_command`` also supports multiple prompts.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
|
@ -465,7 +465,7 @@ For more information, see :ref:`magic_variables_and_hostvars`.
|
|||
Get running configuration
|
||||
-------------------------
|
||||
|
||||
The :ref:`arista.eos.eos_config <eos_config_module>` and :ref:`vyos.vyos.vyos_config <vyos_config_module>` modules have a ``backup:`` option that when set will cause the module to create a full backup of the current ``running-config`` from the remote device before any changes are made. The backup file is written to the ``backup`` folder in the playbook root directory. If the directory does not exist, it is created.
|
||||
The :ref:`arista.eos.eos_config <ansible_collections.arista.eos.eos_config_module>` and :ref:`vyos.vyos.vyos_config <ansible_collections.vyos.vyos.vyos_config_module>` modules have a ``backup:`` option that when set will cause the module to create a full backup of the current ``running-config`` from the remote device before any changes are made. The backup file is written to the ``backup`` folder in the playbook root directory. If the directory does not exist, it is created.
|
||||
|
||||
To demonstrate how we can move the backup file to a different location, we register the result and move the file to the path stored in ``backup_path``.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,25 +4,16 @@
|
|||
Network Debug and Troubleshooting Guide
|
||||
***************************************
|
||||
|
||||
This section discusses how to debug and troubleshoot network modules in Ansible.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
Starting with Ansible version 2.1, you can now use the familiar Ansible models of playbook authoring and module development to manage heterogeneous networking devices. Ansible supports a growing number of network devices using both CLI over SSH and API (when available) transports.
|
||||
|
||||
This section discusses how to debug and troubleshoot network modules in Ansible 2.3.
|
||||
|
||||
|
||||
|
||||
How to troubleshoot
|
||||
===================
|
||||
|
||||
This section covers troubleshooting issues with Network Modules.
|
||||
|
||||
Errors generally fall into one of the following categories:
|
||||
Ansible network automation errors generally fall into one of the following categories:
|
||||
|
||||
:Authentication issues:
|
||||
* Not correctly specifying credentials
|
||||
|
|
@ -36,7 +27,7 @@ Errors generally fall into one of the following categories:
|
|||
|
||||
.. warning:: ``unable to open shell``
|
||||
|
||||
The ``unable to open shell`` message is new in Ansible 2.3, it means that the ``ansible-connection`` daemon has not been able to successfully
|
||||
The ``unable to open shell`` message means that the ``ansible-connection`` daemon has not been able to successfully
|
||||
talk to the remote network device. This generally means that there is an authentication issue. See the "Authentication and connection issues" section
|
||||
in this document for more information.
|
||||
|
||||
|
|
@ -47,11 +38,11 @@ Enabling Networking logging and how to read the logfile
|
|||
|
||||
**Platforms:** Any
|
||||
|
||||
Ansible 2.3 features improved logging to help diagnose and troubleshoot issues regarding Ansible Networking modules.
|
||||
Ansible includes logging to help diagnose and troubleshoot issues regarding Ansible Networking modules.
|
||||
|
||||
Because logging is very verbose it is disabled by default. It can be enabled via the :envvar:`ANSIBLE_LOG_PATH` and :envvar:`ANSIBLE_DEBUG` options on the ansible-controller, that is the machine running ansible-playbook.
|
||||
Because logging is very verbose, it is disabled by default. It can be enabled with the :envvar:`ANSIBLE_LOG_PATH` and :envvar:`ANSIBLE_DEBUG` options on the ansible-controller, that is the machine running ``ansible-playbook``.
|
||||
|
||||
Before running ``ansible-playbook`` run the following commands to enable logging::
|
||||
Before running ``ansible-playbook``, run the following commands to enable logging::
|
||||
|
||||
# Specify the location for the log file
|
||||
export ANSIBLE_LOG_PATH=~/ansible.log
|
||||
|
|
@ -104,19 +95,21 @@ Enabling Networking device interaction logging
|
|||
|
||||
**Platforms:** Any
|
||||
|
||||
Ansible 2.8 features added logging of device interaction in log file to help diagnose and troubleshoot
|
||||
issues regarding Ansible Networking modules. The messages are logged in file pointed by ``log_path`` configuration
|
||||
option in Ansible configuration file or by set :envvar:`ANSIBLE_LOG_PATH` as mentioned in above section.
|
||||
Ansible includes logging of device interaction in the log file to help diagnose and troubleshoot
|
||||
issues regarding Ansible Networking modules. The messages are logged in the file pointed to by the ``log_path`` configuration
|
||||
option in the Ansible configuration file or by setting the :envvar:`ANSIBLE_LOG_PATH`.
|
||||
|
||||
.. warning::
|
||||
The device interaction messages consist of command executed on target device and the returned response, as this
|
||||
The device interaction messages consist of command executed on the target device and the returned response. Since this
|
||||
log data can contain sensitive information including passwords in plain text it is disabled by default.
|
||||
Additionally, in order to prevent accidental leakage of data, a warning will be shown on every task with this
|
||||
setting enabled specifying which host has it enabled and where the data is being logged.
|
||||
setting enabled, specifying which host has it enabled and where the data is being logged.
|
||||
|
||||
Be sure to fully understand the security implications of enabling this option. The device interaction logging can be enabled either globally by setting in configuration file or by setting environment or enabled on per task basis by passing special variable to task.
|
||||
Be sure to fully understand the security implications of enabling this option. The device interaction logging can be enabled either globally by setting in configuration file or by setting environment or enabled on per task basis by passing a special variable to the task.
|
||||
|
||||
Before running ``ansible-playbook`` run the following commands to enable logging::
|
||||
Before running ``ansible-playbook`` run the following commands to enable logging:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
# Specify the location for the log file
|
||||
export ANSIBLE_LOG_PATH=~/ansible.log
|
||||
|
|
@ -127,7 +120,7 @@ Enable device interaction logging for a given task
|
|||
.. code-block:: yaml
|
||||
|
||||
- name: get version information
|
||||
ios_command:
|
||||
cisco.ios.ios_command:
|
||||
commands:
|
||||
- show version
|
||||
vars:
|
||||
|
|
@ -141,14 +134,15 @@ To make this a global setting, add the following to your ``ansible.cfg`` file:
|
|||
[persistent_connection]
|
||||
log_messages = True
|
||||
|
||||
or enable environment variable `ANSIBLE_PERSISTENT_LOG_MESSAGES`
|
||||
or enable the environment variable `ANSIBLE_PERSISTENT_LOG_MESSAGES`:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
# Enable device interaction logging
|
||||
export ANSIBLE_PERSISTENT_LOG_MESSAGES=True
|
||||
|
||||
If the task is failing at the time on connection initialization itself it is recommended to enable this option
|
||||
globally else if an individual task is failing intermittently this option can be enabled for that task itself to
|
||||
find the root cause.
|
||||
If the task is failing on connection initialization itself, you should enable this option
|
||||
globally. If an individual task is failing intermittently this option can be enabled for that task itself to find the root cause.
|
||||
|
||||
After Ansible has finished running you can inspect the log file which has been created on the ansible-controller
|
||||
|
||||
|
|
@ -170,26 +164,28 @@ For Ansible this can be done by ensuring you are only running against one remote
|
|||
|
||||
`ad-hoc` refers to running Ansible to perform some quick command using ``/usr/bin/ansible``, rather than the orchestration language, which is ``/usr/bin/ansible-playbook``. In this case we can ensure connectivity by attempting to execute a single command on the remote device::
|
||||
|
||||
ansible -m eos_command -a 'commands=?' -i inventory switch1.example.net -e 'ansible_connection=local' -u admin -k
|
||||
ansible -m arista.eos.eos_command -a 'commands=?' -i inventory switch1.example.net -e 'ansible_connection=ansible.netcommon.network_cli' -u admin -k
|
||||
|
||||
In the above example, we:
|
||||
|
||||
* connect to ``switch1.example.net`` specified in the inventory file ``inventory``
|
||||
* use the module ``eos_command``
|
||||
* use the module ``arista.eos.eos_command``
|
||||
* run the command ``?``
|
||||
* connect using the username ``admin``
|
||||
* inform ansible to prompt for the ssh password by specifying ``-k``
|
||||
* inform the ``ansible`` command to prompt for the SSH password by specifying ``-k``
|
||||
|
||||
If you have SSH keys configured correctly, you don't need to specify the ``-k`` parameter
|
||||
If you have SSH keys configured correctly, you don't need to specify the ``-k`` parameter.
|
||||
|
||||
If the connection still fails you can combine it with the enable_network_logging parameter. For example::
|
||||
If the connection still fails you can combine it with the enable_network_logging parameter. For example:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
# Specify the location for the log file
|
||||
export ANSIBLE_LOG_PATH=~/ansible.log
|
||||
# Enable Debug
|
||||
export ANSIBLE_DEBUG=True
|
||||
# Run with 4*v for connection level verbosity
|
||||
ansible -m eos_command -a 'commands=?' -i inventory switch1.example.net -e 'ansible_connection=local' -u admin -k
|
||||
# Run with ``-vvvv`` for connection level verbosity
|
||||
ansible -m arista.eos.eos_command -a 'commands=?' -i inventory switch1.example.net -e 'ansible_connection=ansible.netcommon.network_cli' -u admin -k
|
||||
|
||||
Then review the log file and find the relevant error message in the rest of this document.
|
||||
|
||||
|
|
@ -202,7 +198,7 @@ Troubleshooting socket path issues
|
|||
|
||||
**Platforms:** Any
|
||||
|
||||
The ``Socket path does not exist or cannot be found`` and ``Unable to connect to socket`` messages are new in Ansible 2.5. These messages indicate that the socket used to communicate with the remote network device is unavailable or does not exist.
|
||||
The ``Socket path does not exist or cannot be found`` and ``Unable to connect to socket`` messages indicate that the socket used to communicate with the remote network device is unavailable or does not exist.
|
||||
|
||||
For example:
|
||||
|
||||
|
|
@ -259,7 +255,7 @@ Category "Unable to open shell"
|
|||
|
||||
**Platforms:** Any
|
||||
|
||||
The ``unable to open shell`` message is new in Ansible 2.3. This message means that the ``ansible-connection`` daemon has not been able to successfully talk to the remote network device. This generally means that there is an authentication issue. It is a "catch all" message, meaning you need to enable :ref:logging`a_note_about_logging` to find the underlying issues.
|
||||
The ``unable to open shell`` message means that the ``ansible-connection`` daemon has not been able to successfully talk to the remote network device. This generally means that there is an authentication issue. It is a "catch all" message, meaning you need to enable :ref:`logging <a_note_about_logging>` to find the underlying issues.
|
||||
|
||||
|
||||
|
||||
|
|
@ -508,21 +504,18 @@ Suggestions to resolve:
|
|||
.. code-block:: yaml
|
||||
|
||||
- name: save running-config
|
||||
ios_command:
|
||||
cisco.ios.ios_command:
|
||||
commands: copy running-config startup-config
|
||||
provider: "{{ cli }}"
|
||||
timeout: 30
|
||||
|
||||
For network_cli, netconf connection type (applicable from 2.7 onwards):
|
||||
|
||||
.. FIXME: Detail error here
|
||||
|
||||
Suggestions to resolve:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- name: save running-config
|
||||
ios_command:
|
||||
cisco.ios.ios_command:
|
||||
commands: copy running-config startup-config
|
||||
vars:
|
||||
ansible_command_timeout: 60
|
||||
|
|
@ -611,7 +604,7 @@ This section details issues are caused by issues with the Playbook itself.
|
|||
Error: "Unable to enter configuration mode"
|
||||
-------------------------------------------
|
||||
|
||||
**Platforms:** eos and ios
|
||||
**Platforms:** Arista EOS and Cisco IOS
|
||||
|
||||
This occurs when you attempt to run a task that requires privileged mode in a user mode shell.
|
||||
|
||||
|
|
@ -629,35 +622,7 @@ For example:
|
|||
|
||||
Suggestions to resolve:
|
||||
|
||||
In Ansible prior to 2.5 :
|
||||
Add ``authorize: yes`` to the task. For example:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- name: configure hostname
|
||||
ios_system:
|
||||
provider:
|
||||
hostname: foo
|
||||
authorize: yes
|
||||
register: result
|
||||
|
||||
If the user requires a password to go into privileged mode, this can be specified with ``auth_pass``; if ``auth_pass`` isn't set, the environment variable `ANSIBLE_NET_AUTHORIZE` will be used instead.
|
||||
|
||||
|
||||
Add ``authorize: yes`` to the task. For example:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- name: configure hostname
|
||||
ios_system:
|
||||
provider:
|
||||
hostname: foo
|
||||
authorize: yes
|
||||
auth_pass: "{{ mypasswordvar }}"
|
||||
register: result
|
||||
|
||||
|
||||
.. note:: Starting with Ansible 2.5 we recommend using ``connection: network_cli`` and ``become: yes``
|
||||
Use ``connection: ansible.netcommon.network_cli`` and ``become: yes``
|
||||
|
||||
|
||||
Proxy Issues
|
||||
|
|
@ -668,10 +633,8 @@ Proxy Issues
|
|||
delegate_to vs ProxyCommand
|
||||
---------------------------
|
||||
|
||||
The new connection framework for Network Modules in Ansible 2.3 that uses ``cli`` transport
|
||||
no longer supports the use of the ``delegate_to`` directive.
|
||||
In order to use a bastion or intermediate jump host to connect to network devices over ``cli``
|
||||
transport, network modules now support the use of ``ProxyCommand``.
|
||||
transport, network modules support the use of ``ProxyCommand``.
|
||||
|
||||
To use ``ProxyCommand``, configure the proxy settings in the Ansible inventory
|
||||
file to specify the proxy host.
|
||||
|
|
@ -751,8 +714,8 @@ Example Ansible inventory file
|
|||
junos01
|
||||
|
||||
[junos:vars]
|
||||
ansible_connection=netconf
|
||||
ansible_network_os=junos
|
||||
ansible_connection=ansible.netcommon.netconf
|
||||
ansible_network_os=junipernetworks.junos.junos
|
||||
ansible_user=myuser
|
||||
ansible_password=!vault...
|
||||
|
||||
|
|
@ -768,11 +731,11 @@ Miscellaneous Issues
|
|||
====================
|
||||
|
||||
|
||||
Intermittent failure while using ``network_cli`` connection type
|
||||
----------------------------------------------------------------
|
||||
Intermittent failure while using ``ansible.netcommon.network_cli`` connection type
|
||||
------------------------------------------------------------------------------------
|
||||
|
||||
If the command prompt received in response is not matched correctly within
|
||||
the ``network_cli`` connection plugin the task might fail intermittently with truncated
|
||||
the ``ansible.netcommon.network_cli`` connection plugin the task might fail intermittently with truncated
|
||||
response or with the error message ``operation requires privilege escalation``.
|
||||
Starting in 2.7.1 a new buffer read timer is added to ensure prompts are matched properly
|
||||
and a complete response is send in output. The timer default value is 0.2 seconds and
|
||||
|
|
@ -783,7 +746,7 @@ Example Per task timer setting
|
|||
.. code-block:: yaml
|
||||
|
||||
- name: gather ios facts
|
||||
ios_facts:
|
||||
cisco.ios.ios_facts:
|
||||
gather_subset: all
|
||||
register: result
|
||||
vars:
|
||||
|
|
@ -800,10 +763,10 @@ To make this a global setting, add the following to your ``ansible.cfg`` file:
|
|||
This timer delay per command executed on remote host can be disabled by setting the value to zero.
|
||||
|
||||
|
||||
Task failure due to mismatched error regex within command response using ``network_cli`` connection type
|
||||
--------------------------------------------------------------------------------------------------------
|
||||
Task failure due to mismatched error regex within command response using ``ansible.netcommon.network_cli`` connection type
|
||||
----------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
In Ansible 2.9 and later, the network_cli connection plugin configuration options are added
|
||||
In Ansible 2.9 and later, the ``ansible.netcommon.network_cli`` connection plugin configuration options are added
|
||||
to handle the stdout and stderr regex to identify if the command execution response consist
|
||||
of a normal response or an error response. These options can be set group/host variables or as
|
||||
tasks variables.
|
||||
|
|
@ -813,7 +776,7 @@ Example: For mismatched error response
|
|||
.. code-block:: yaml
|
||||
|
||||
- name: fetch logs from remote host
|
||||
ios_command:
|
||||
cisco.ios.ios_command:
|
||||
commands:
|
||||
- show logging
|
||||
|
||||
|
|
@ -836,7 +799,7 @@ Modify the error regex for individual task.
|
|||
.. code-block:: yaml
|
||||
|
||||
- name: fetch logs from remote host
|
||||
ios_command:
|
||||
cisco.ios.ios_command:
|
||||
commands:
|
||||
- show logging
|
||||
vars:
|
||||
|
|
@ -849,10 +812,10 @@ The terminal plugin regex options ``ansible_terminal_stderr_re`` and ``ansible_t
|
|||
the ``re.compile`` python method.
|
||||
|
||||
|
||||
Intermittent failure while using ``network_cli`` connection type due to slower network or remote target host
|
||||
------------------------------------------------------------------------------------------------------------
|
||||
Intermittent failure while using ``ansible.netcommon.network_cli`` connection type due to slower network or remote target host
|
||||
----------------------------------------------------------------------------------------------------------------------------------
|
||||
|
||||
In Ansible 2.9 and later, the ``network_cli`` connection plugin configuration option is added to control
|
||||
In Ansible 2.9 and later, the ``ansible.netcommon.network_cli`` connection plugin configuration option is added to control
|
||||
the number of attempts to connect to a remote host. The default number of attempts is three.
|
||||
After every retry attempt the delay between retries is increased by power of 2 in seconds until either the
|
||||
maximum attempts are exhausted or either the ``persistent_command_timeout`` or ``persistent_connect_timeout`` timers are triggered.
|
||||
|
|
|
|||
|
|
@ -1,21 +1,15 @@
|
|||
.. _resource_modules:
|
||||
|
||||
************************
|
||||
Network resource modules
|
||||
Network Resource Modules
|
||||
************************
|
||||
|
||||
Ansible 2.9 introduced network resource modules to simplify and standardize how you manage different network devices.
|
||||
Ansible network resource modules simplify and standardize how you manage different network devices. Network devices separate configuration into sections (such as interfaces and VLANs) that apply to a network service. Ansible network resource modules take advantage of this to allow you to configure subsections or *resources* within the network device configuration. Network resource modules provide a consistent experience across different network devices.
|
||||
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
Understanding network resource modules
|
||||
=======================================
|
||||
|
||||
Network devices separate configuration into sections (such as interfaces, VLANS, etc) that apply to a network service. Ansible network resource modules take advantage of this to allow you to configure subsections or *resources* within the network device configuration. Network resource modules provide a consistent experience across different network devices.
|
||||
|
||||
|
||||
Network resource module states
|
||||
===============================
|
||||
|
||||
|
|
@ -45,12 +39,12 @@ parsed
|
|||
Using network resource modules
|
||||
==============================
|
||||
|
||||
This example configures L3 interface resource on a Cisco IOS device, based on different state settings.
|
||||
This example configures the L3 interface resource on a Cisco IOS device, based on different state settings.
|
||||
|
||||
.. code-block:: YAML
|
||||
.. code-block:: yaml
|
||||
|
||||
- name: configure l3 interface
|
||||
ios_l3_interfaces:
|
||||
cisco.ios.ios_l3_interfaces:
|
||||
config: "{{ config }}"
|
||||
state: <state>
|
||||
|
||||
|
|
@ -127,7 +121,7 @@ Network resource modules return the following details:
|
|||
Example: Verifying the network device configuration has not changed
|
||||
====================================================================
|
||||
|
||||
The following playbook uses the :ref:`eos_l3_interfaces <eos_l3_interfaces_module>` module to gather a subset of the network device configuration (Layer 3 interfaces only) and verifies the information is accurate and has not changed. This playbook passes the results of :ref:`eos_facts <eos_facts_module>` directly to the ``eos_l3_interfaces`` module.
|
||||
The following playbook uses the :ref:`arista.eos.eos_l3_interfaces <ansible_collections.arista.eos.eos_l3_interfaces_module>` module to gather a subset of the network device configuration (Layer 3 interfaces only) and verifies the information is accurate and has not changed. This playbook passes the results of :ref:`arista.eos.eos_facts <ansible_collections.arista.eos.eos_facts_module>` directly to the ``arista.eos.eos_l3_interfaces`` module.
|
||||
|
||||
|
||||
.. code-block:: yaml
|
||||
|
|
@ -137,12 +131,12 @@ The following playbook uses the :ref:`eos_l3_interfaces <eos_l3_interfaces_modul
|
|||
gather_facts: false
|
||||
tasks:
|
||||
- name: grab arista eos facts
|
||||
eos_facts:
|
||||
arista.eos.eos_facts:
|
||||
gather_subset: min
|
||||
gather_network_resources: l3_interfaces
|
||||
|
||||
- name: Ensure that the IP address information is accurate.
|
||||
eos_l3_interfaces:
|
||||
arista.eos.eos_l3_interfaces:
|
||||
config: "{{ ansible_network_resources['l3_interfaces'] }}"
|
||||
register: result
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ For example::
|
|||
|
||||
---
|
||||
- name: wait for interface to be admin enabled
|
||||
eos_command:
|
||||
arista.eos.eos_command:
|
||||
commands:
|
||||
- show interface Ethernet4 | json
|
||||
wait_for:
|
||||
|
|
@ -49,7 +49,7 @@ results in an interface. For instance::
|
|||
|
||||
---
|
||||
- name: wait for interfaces to be admin enabled
|
||||
eos_command:
|
||||
arista.eos.eos_command:
|
||||
commands:
|
||||
- show interface Ethernet4 | json
|
||||
- show interface Ethernet5 | json
|
||||
|
|
@ -70,19 +70,19 @@ command index in ``[]``, where ``0`` is the first command in the commands list,
|
|||
Handling prompts in network modules
|
||||
===================================
|
||||
|
||||
Network devices may require that you answer a prompt before performing a change on the device. Individual network modules such as :ref:`ios_command <ios_command_module>` and :ref:`nxos_command <nxos_command_module>` can handle this with a ``prompt`` parameter.
|
||||
Network devices may require that you answer a prompt before performing a change on the device. Individual network modules such as :ref:`cisco.ios.ios_command <ansible_collections.cisco.ios.ios_command_module>` and :ref:`cisco.nxos.nxos_command <ansible_collections.cisco.nxos.nxos_command_module>` can handle this with a ``prompt`` parameter.
|
||||
|
||||
.. note::
|
||||
|
||||
``prompt`` is a Python regex. If you add special characters such as ``?`` in the ``prompt`` value, the prompt won't match and you will get a timeout. To avoid this, ensure that the ``prompt`` value is a Python regex that matches the actual device prompt. Any special characters must be handled correctly in the ``prompt`` regex.
|
||||
|
||||
You can also use the :ref:`cli_command <cli_command_module>` to handle multiple prompts.
|
||||
You can also use the :ref:`ansible.netcommon.cli_command <ansible_collections.ansible.netcommon.cli_command_module>` to handle multiple prompts.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
---
|
||||
- name: multiple prompt, multiple answer (mandatory check for all prompts)
|
||||
cli_command:
|
||||
ansible.netcommon.cli_command:
|
||||
command: "copy sftp sftp://user@host//user/test.img"
|
||||
check_all: True
|
||||
prompt:
|
||||
|
|
@ -104,7 +104,7 @@ In the following example, the second answer would be ignored and ``y`` would be
|
|||
|
||||
---
|
||||
- name: reboot ios device
|
||||
cli_command:
|
||||
ansible.netcommon.cli_command:
|
||||
command: reload
|
||||
prompt:
|
||||
- Save\?
|
||||
|
|
|
|||
|
|
@ -54,40 +54,40 @@ Settings by Platform
|
|||
.. table::
|
||||
:name: network-platform-table
|
||||
|
||||
=============================== ======================= =========== ======= ======= ===========
|
||||
.. ``ansible_connection:`` settings available
|
||||
-------------------------------------------------------- ------------------------------------------
|
||||
Network OS ``ansible_network_os:`` network_cli netconf httpapi local
|
||||
=============================== ======================= =========== ======= ======= ===========
|
||||
`Arista EOS`_ `[†]`_ ``eos`` ✓ ✓ ✓
|
||||
`Ciena SAOS6`_ ``saos6`` ✓ ✓
|
||||
`Cisco ASA`_ `[†]`_ ``asa`` ✓ ✓
|
||||
`Cisco IOS`_ `[†]`_ ``ios`` ✓ ✓
|
||||
`Cisco IOS XR`_ `[†]`_ ``iosxr`` ✓ ✓
|
||||
`Cisco NX-OS`_ `[†]`_ ``nxos`` ✓ ✓ ✓
|
||||
`Cloudengine OS`_ ``ce`` ✓ ✓ ✓
|
||||
`Dell OS6`_ ``dellos6`` ✓ ✓
|
||||
`Dell OS9`_ ``dellos9`` ✓ ✓
|
||||
`Dell OS10`_ ``dellos10`` ✓ ✓
|
||||
`Ericsson ECCLI`_ ``eric_eccli`` ✓ ✓
|
||||
`Extreme EXOS`_ ``exos`` ✓ ✓
|
||||
`Extreme IronWare`_ ``ironware`` ✓ ✓
|
||||
`Extreme NOS`_ ``nos`` ✓
|
||||
`Extreme SLX-OS`_ ``slxos`` ✓
|
||||
`Extreme VOSS`_ ``voss`` ✓
|
||||
`F5 BIG-IP`_ ✓
|
||||
`F5 BIG-IQ`_ ✓
|
||||
`Junos OS`_ `[†]`_ ``junos`` ✓ ✓ ✓
|
||||
`Lenovo CNOS`_ ``cnos`` ✓ ✓
|
||||
`Lenovo ENOS`_ ``enos`` ✓ ✓
|
||||
`Meraki`_ ``meraki`` ✓
|
||||
`MikroTik RouterOS`_ ``routeros`` ✓
|
||||
`Nokia SR OS`_ ``sros`` ✓ ✓
|
||||
`Pluribus Netvisor`_ ``netvisor`` ✓
|
||||
`Ruckus ICX`_ ``icx`` ✓
|
||||
`VyOS`_ `[†]`_ ``vyos`` ✓ ✓
|
||||
OS that supports Netconf `[†]`_ ``<network-os>`` ✓ ✓
|
||||
=============================== ======================= =========== ======= ======= ===========
|
||||
=============================== ================================ =========== ======= ======= ===========
|
||||
.. ``ansible_connection:`` settings available
|
||||
----------------------------------------------------------------- ------------------------------------------
|
||||
Network OS ``ansible_network_os:`` network_cli netconf httpapi local
|
||||
=============================== ================================ =========== ======= ======= ===========
|
||||
`Arista EOS`_ `[†]`_ ``arista.eos.eos`` ✓ ✓ ✓
|
||||
`Ciena SAOS6`_ ``ciena.saos6.saos6`` ✓ ✓
|
||||
`Cisco ASA`_ `[†]`_ ``cisco.asa.asa`` ✓ ✓
|
||||
`Cisco IOS`_ `[†]`_ ``cisco.ios.ios`` ✓ ✓
|
||||
`Cisco IOS XR`_ `[†]`_ ``cisco.iosxr.iosxr`` ✓ ✓
|
||||
`Cisco NX-OS`_ `[†]`_ ``cisco.nxos.nxos`` ✓ ✓ ✓
|
||||
`Cloudengine OS`_ ``community.network.ce`` ✓ ✓ ✓
|
||||
`Dell OS6`_ ``dellemc.os6.os6`` ✓ ✓
|
||||
`Dell OS9`_ ``dellemc.os9.os9`` ✓ ✓
|
||||
`Dell OS10`_ ``dellemc.os10.0s10`` ✓ ✓
|
||||
`Ericsson ECCLI`_ ``community.network.eric_eccli`` ✓ ✓
|
||||
`Extreme EXOS`_ ``community.network.exos`` ✓ ✓
|
||||
`Extreme IronWare`_ ``community.network.ironware`` ✓ ✓
|
||||
`Extreme NOS`_ ``community.network.nos`` ✓
|
||||
`Extreme SLX-OS`_ ``community.network.slxos`` ✓
|
||||
`Extreme VOSS`_ ``community.network.voss`` ✓
|
||||
`F5 BIG-IP`_ ✓
|
||||
`F5 BIG-IQ`_ ✓
|
||||
`Junos OS`_ `[†]`_ ``junipernetworks.junos.junos`` ✓ ✓ ✓
|
||||
`Lenovo CNOS`_ ``community.network.cnos`` ✓ ✓
|
||||
`Lenovo ENOS`_ ``community.network.enos`` ✓ ✓
|
||||
`Meraki`_ ✓
|
||||
`MikroTik RouterOS`_ ``community.network.routeros`` ✓
|
||||
`Nokia SR OS`_ ✓
|
||||
`Pluribus Netvisor`_ ``community.network.netvisor`` ✓
|
||||
`Ruckus ICX`_ ``community.network.icx`` ✓
|
||||
`VyOS`_ `[†]`_ ``vyos.vyos.vyos`` ✓ ✓
|
||||
OS that supports Netconf `[†]`_ ``<network-os>`` ✓ ✓
|
||||
=============================== ================================ =========== ======= ======= ===========
|
||||
|
||||
.. _Arista EOS: https://galaxy.ansible.com/arista/eos
|
||||
.. _Ciena SAOS6: https://galaxy.ansible.com/ciena/saos6
|
||||
|
|
@ -98,7 +98,7 @@ Settings by Platform
|
|||
.. _Cloudengine OS: https://galaxy.ansible.com/community/network
|
||||
.. _Dell OS6: https://github.com/ansible-collections/dellemc.os6
|
||||
.. _Dell OS9: https://github.com/ansible-collections/dellemc.os9
|
||||
.. _Dell OS10: https://galaxy.ansible.com/dellemc_networking/os10
|
||||
.. _Dell OS10: https://galaxy.ansible.com/dellemc/os10
|
||||
.. _Ericsson ECCLI: https://galaxy.ansible.com/community/network
|
||||
.. _Extreme EXOS: https://galaxy.ansible.com/community/network
|
||||
.. _Extreme IronWare: https://galaxy.ansible.com/community/network
|
||||
|
|
|
|||
Loading…
Reference in a new issue