Руководство по отладке и устранению неполадок сети

• Введение
• Как устранять неполадки
  • Включение журналирования сети и чтение файла журнала
  • Включение журналирования взаимодействия с сетевым устройством
  • Изоляция ошибки
• Категория «проблема с путем сокета»
• Категория «невозможно открыть оболочку»
  • Ошибка: «[Errno -2] Имя или служба неизвестны»
  • Ошибка: «Произошла ошибка аутентификации»
  • Ошибка: «подключение к хосту <hostname> вернуло ошибку» или «Неверный адрес»
  • Ошибка: «Нет доступных методов аутентификации»
  • Очистка постоянных подключений
• Проблемы с тайм-аутами
  • Тайм-аут бездействия постоянного подключения
  • Тайм-аут команды
  • Тайм-аут повторного подключения постоянного соединения
  • Проблемы с тайм-аутом из-за специфичного для платформы меню входа с типом подключения network_cli
• Проблемы с playbook
  • Ошибка: «Невозможно войти в режим конфигурации»
• Проблемы с прокси
  • delegate_to vs ProxyCommand
  • Использование бастионного/промежуточного хоста с подключением netconf
  • Включение настроек промежуточного хоста
  • Пример файла конфигурации ssh (~/.ssh/config)
• Разные проблемы
  • Периодические сбои при использовании типа подключения network_cli
  • Сбой задачи из-за несовпадения регулярного выражения ошибки в ответе команды при использовании типа подключения network_cli
  • Периодические сбои при использовании типа подключения network_cli из-за медленной сети или удаленного целевого хоста

Введение

Начиная с версии Ansible 2.1, теперь вы можете использовать знакомые модели Ansible для написания playbook и разработки модулей для управления разнородными сетевыми устройствами. Ansible поддерживает растущее количество сетевых устройств, используя как CLI через SSH, так и API (если доступен) транспорт.

В этом разделе обсуждается, как отлаживать и устранять неполадки модулей сети в Ansible 2.3.

Как устранять неполадки

Этот раздел посвящен устранению неполадок в модулях сети.

Ошибки, как правило, попадают в одну из следующих категорий:

Включение журналирования сети и чтение файла журнала

Платформы: Любые

Ansible 2.3 имеет улучшенное журналирование, помогающее диагностировать и устранять проблемы с модулями Ansible Networking.

Поскольку журналирование очень подробное, оно отключено по умолчанию. Его можно включить с помощью опций ANSIBLE_LOG_PATH и ANSIBLE_DEBUG на контроллере ansible, то есть на машине, на которой выполняется ansible-playbook.

Перед запуском ansible-playbook выполните следующие команды для включения журналирования:

# 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-playbook -vvvv ...

После завершения работы Ansible можно проверить файл журнала, созданный на контроллере ansible:

less $ANSIBLE_LOG_PATH

2017-03-30 13:19:52,740 p=28990 u=fred |  creating new control socket for host veos01:22 as user admin
2017-03-30 13:19:52,741 p=28990 u=fred |  control socket path is /home/fred/.ansible/pc/ca5960d27a
2017-03-30 13:19:52,741 p=28990 u=fred |  current working directory is /home/fred/ansible/test/integration
2017-03-30 13:19:52,741 p=28990 u=fred |  using connection plugin network_cli
...
2017-03-30 13:20:14,771 paramiko.transport userauth is OK
2017-03-30 13:20:15,283 paramiko.transport Authentication (keyboard-interactive) successful!
2017-03-30 13:20:15,302 p=28990 u=fred |  ssh connection done, setting terminal
2017-03-30 13:20:15,321 p=28990 u=fred |  ssh connection has completed successfully
2017-03-30 13:20:15,322 p=28990 u=fred |  connection established to veos01 in 0:00:22.580626

Из журнала обратите внимание:

• p=28990 — это PID (идентификатор процесса) процесса ansible-connection
• u=fred — это пользователь running, а не удалённый пользователь, от имени которого вы пытаетесь подключиться
• creating new control socket for host veos01:22 as user admin — хост:порт как пользователь
• control socket path is — расположение на диске, где создается сокет постоянного подключения
• using connection plugin network_cli — сообщает о том, что используется постоянное подключение
• connection established to veos01 in 0:00:22.580626 — время получения оболочки на удалённом устройстве

Из-за объёма файлов журнала, можно использовать grep для поиска конкретной информации. Например, после определения pid из строки creating new control socket for host, можно искать другие записи журнала подключения:

grep "p=28990" $ANSIBLE_LOG_PATH

Включение журналирования взаимодействия с сетевым устройством

Платформы: Любые

Ansible 2.8 добавило журналирование взаимодействия с устройствами в файл журнала, чтобы помочь диагностировать и устранять проблемы с модулями Ansible Networking. Сообщения записываются в файл, указанный опцией log_path в файле конфигурации Ansible или с помощью ANSIBLE_LOG_PATH , как описано в предыдущем разделе.

Убедитесь, что вы понимаете последствия включения этого параметра для безопасности. Журналирование взаимодействия с устройствами можно включить глобально в файле конфигурации или через переменные окружения, или для каждой задачи, передав специальную переменную.

Перед запуском ansible-playbook выполните следующие команды для включения журналирования:

# Specify the location for the log file
export ANSIBLE_LOG_PATH=~/ansible.log

Включение журналирования взаимодействия с устройствами для конкретной задачи

- name: get version information
  ios_command:
    commands:
      - show version
  vars:
    ansible_persistent_log_messages: True

Для глобального включения добавьте следующее в файл ansible.cfg:

[persistent_connection]
log_messages = True

или включите переменную окружения ANSIBLE_PERSISTENT_LOG_MESSAGES

Если задача завершается ошибкой на этапе инициализации подключения, рекомендуется включить этот параметр глобально. В противном случае, если отдельные задачи периодически терпят неудачу, этот параметр можно включить только для этих задач, чтобы найти причину.

После завершения работы Ansible можно проверить созданный на контроллере ansible файл журнала

Изоляция ошибки

Платформы: Любые

Как и при любой попытке отладки, важно максимально упростить тестовый случай.

В Ansible это можно сделать, убедившись, что вы работаете только с одним удалённым устройством:

• Используя ansible-playbook --limit switch1.example.net...
• Используя ad-hoc ansible команду

ad-hoc означает запуск Ansible для выполнения какой-либо быстрой команды на удалённом устройстве с использованием /usr/bin/ansible, а не языка оркестрации, которым является /usr/bin/ansible-playbook. В данном случае мы можем гарантировать подключение, попытавшись выполнить одну команду на удалённом устройстве:

ansible -m eos_command -a 'commands=?' -i inventory switch1.example.net -e 'ansible_connection=local' -u admin -k

В приведённом выше примере мы:

• подключаемся к switch1.example.net, указанному в файле инвентаризации inventory
• используем модуль eos_command
• выполняем команду ?
• подключаемся под именем пользователя admin
• указываем Ansible запросить пароль SSH, задав -k

Если ключи SSH настроены правильно, вам не нужно указывать параметр -k

Если соединение всё ещё не удаётся, вы можете объединить его с параметром enable_network_logging. Например:

# 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

Затем просмотрите файл журнала и найдите соответствующее сообщение об ошибке в остальной части данного документа.

Категория «socket_path issue»

Платформы: Любые

Сообщения socket_path does not exist or cannot be found и unable to connect to socket появились в Ansible 2.5. Эти сообщения указывают на то, что сокет, используемый для связи с удалённым сетевым устройством, недоступен или не существует.

Например:

fatal: [spine02]: FAILED! => {
    "changed": false,
    "failed": true,
    "module_stderr": "Traceback (most recent call last):\n  File \"/tmp/ansible_TSqk5J/ansible_modlib.zip/ansible/module_utils/connection.py\", line 115, in _exec_jsonrpc\nansible.module_utils.connection.ConnectionError: socket_path does not exist or cannot be found\n",
    "module_stdout": "",
    "msg": "MODULE FAILURE",
    "rc": 1
}

или

fatal: [spine02]: FAILED! => {
    "changed": false,
    "failed": true,
    "module_stderr": "Traceback (most recent call last):\n  File \"/tmp/ansible_TSqk5J/ansible_modlib.zip/ansible/module_utils/connection.py\", line 123, in _exec_jsonrpc\nansible.module_utils.connection.ConnectionError: unable to connect to socket\n",
    "module_stdout": "",
    "msg": "MODULE FAILURE",
    "rc": 1
}

Рекомендации по решению:

Следуйте шагам, описанным в включении ведения журнала сети.

Если в файле журнала найдено сообщение об ошибке:

2017-04-04 12:19:05,670 p=18591 u=fred |  command timeout triggered, timeout value is 30 secs

или

2017-04-04 12:19:05,670 p=18591 u=fred |  persistent connection idle timeout triggered, timeout value is 30 secs

Следуйте шагам, описанным в проблемах с таймаутами

Категория «Невозможно открыть оболочку»

Платформы: Любые

Сообщение unable to open shell появилось в Ansible 2.3. Это сообщение означает, что демону ansible-connection не удалось успешно связаться с удалённым сетевым устройством. Обычно это означает проблему с аутентификацией. Это сообщение «общего характера», что означает, вам необходимо включить :ref:logging`a_note_about_logging`, чтобы найти лежащие в основе проблемы.

Например:

TASK [prepare_eos_tests : enable cli on remote device] **************************************************
fatal: [veos01]: FAILED! => {"changed": false, "failed": true, "msg": "unable to open shell"}

или:

TASK [ios_system : configure name_servers] *************************************************************
task path:
fatal: [ios-csr1000v]: FAILED! => {
    "changed": false,
    "failed": true,
    "msg": "unable to open shell",
}

Рекомендации по решению:

Следуйте шагам, описанным в enable_network_logging.

После того, как вы определили сообщение об ошибке из файла журнала, конкретное решение можно найти в остальной части документа.

Ошибка: «[Errno -2] Имя или служба не известны»

Платформы: Любые

Указывает, что удалённый хост, к которому вы пытаетесь подключиться, недоступен.

Например:

2017-04-04 11:39:48,147 p=15299 u=fred |  control socket path is /home/fred/.ansible/pc/ca5960d27a
2017-04-04 11:39:48,147 p=15299 u=fred |  current working directory is /home/fred/git/ansible-inc/stable-2.3/test/integration
2017-04-04 11:39:48,147 p=15299 u=fred |  using connection plugin network_cli
2017-04-04 11:39:48,340 p=15299 u=fred |  connecting to host veos01 returned an error
2017-04-04 11:39:48,340 p=15299 u=fred |  [Errno -2] Name or service not known

Рекомендации по решению:

• Если вы используете опции provider:, убедитесь, что её подопция host: настроена правильно.
• Если вы не используете provider: и аргументы верхнего уровня, убедитесь, что ваш файл инвентаризации корректен.

Ошибка: «Ошибка аутентификации»

Платформы: Любые

Возникает, если учётные данные (имя пользователя, пароли или ключи SSH), переданные в ansible-connection (через ansible или ansible-playbook), не могут быть использованы для подключения к удалённому устройству.

Например:

<ios01> ESTABLISH CONNECTION FOR USER: cisco on PORT 22 TO ios01
<ios01> Authentication failed.

Рекомендации по решению:

Если вы указываете учётные данные через password: (прямо или через provider:) или переменную окружения ANSIBLE_NET_PASSWORD, возможно, paramiko (библиотека Python SSH, используемая Ansible) использует ключи SSH, и поэтому указанные вами учётные данные игнорируются. Чтобы выяснить, так ли это, отключите «поиск ключей». Это можно сделать так:

export ANSIBLE_PARAMIKO_LOOK_FOR_KEYS=False

Чтобы сделать это постоянным изменением, добавьте следующее в свой файл ansible.cfg:

[paramiko_connection]
look_for_keys = False

Ошибка: «подключение к хосту <hostname> вернуло ошибку» или «Неверный адрес»

Это может произойти, если отпечаток SSH не был добавлен в файл известных хостов Paramiko (библиотеки Python SSH).

При использовании постоянных подключений с Paramiko соединение работает в фоновом процессе. Если у хоста ещё нет действительного ключа SSH, по умолчанию Ansible запросит добавить ключ хоста. Это приведёт к сбоям подключений, работающих в фоновых процессах.

Например:

2017-04-04 12:06:03,486 p=17981 u=fred |  using connection plugin network_cli
2017-04-04 12:06:04,680 p=17981 u=fred |  connecting to host veos01 returned an error
2017-04-04 12:06:04,682 p=17981 u=fred |  (14, 'Bad address')
2017-04-04 12:06:33,519 p=17981 u=fred |  number of connection attempts exceeded, unable to connect to control socket
2017-04-04 12:06:33,520 p=17981 u=fred |  persistent_connect_interval=1, persistent_connect_retries=30

Рекомендации по решению:

Используйте ssh-keyscan для предварительной заполнения known_hosts. Вам необходимо убедиться, что ключи корректны.

ssh-keyscan veos01

или

Вы можете сказать Ansible автоматически принимать ключи

Метод переменной окружения:

export ANSIBLE_PARAMIKO_HOST_KEY_AUTO_ADD=True
ansible-playbook ...

ansible.cfg метод:

ansible.cfg

[paramiko_connection]
host_key_auto_add = True

Ошибка: «Нет доступных методов аутентификации»

Например:

2017-04-04 12:19:05,670 p=18591 u=fred |  creating new control socket for host veos01:None as user admin
2017-04-04 12:19:05,670 p=18591 u=fred |  control socket path is /home/fred/.ansible/pc/ca5960d27a
2017-04-04 12:19:05,670 p=18591 u=fred |  current working directory is /home/fred/git/ansible-inc/ansible-workspace-2/test/integration
2017-04-04 12:19:05,670 p=18591 u=fred |  using connection plugin network_cli
2017-04-04 12:19:06,606 p=18591 u=fred |  connecting to host veos01 returned an error
2017-04-04 12:19:06,606 p=18591 u=fred |  No authentication methods available
2017-04-04 12:19:35,708 p=18591 u=fred |  connect retry timeout expired, unable to connect to control socket
2017-04-04 12:19:35,709 p=18591 u=fred |  persistent_connect_retry_timeout is 15 secs

Рекомендации по решению:

Не указан пароль или ключ SSH

Очистка постоянных подключений

Платформы: Любые

В Ansible 2.3 сокеты постоянных подключений хранятся в ~/.ansible/pc для всех сетевых устройств. При запуске Ansible playbook постоянное сокет-соединение отображается при задании подробного вывода.

<switch> socket_path: /home/fred/.ansible/pc/f64ddfa760

Чтобы очистить постоянное соединение перед его истечением времени ожидания (по умолчанию таймаут составляет 30 секунд бездействия), просто удалите файл сокета.

Проблемы с таймаутами

Таймаут бездействия постоянного соединения

По умолчанию ANSIBLE_PERSISTENT_CONNECT_TIMEOUT установлен в 30 (секунд). Вы можете увидеть следующую ошибку, если это значение слишком мало:

2017-04-04 12:19:05,670 p=18591 u=fred |  persistent connection idle timeout triggered, timeout value is 30 secs

Рекомендации по решению:

Увеличить значение таймаута бездействия постоянного соединения:

export ANSIBLE_PERSISTENT_CONNECT_TIMEOUT=60

Чтобы сделать это постоянным изменением, добавьте следующее в ваш файл ansible.cfg:

[persistent_connection]
connect_timeout = 60

Таймаут команды

По умолчанию ANSIBLE_PERSISTENT_COMMAND_TIMEOUT установлен в 30 (секунд). В предыдущих версиях Ansible это значение по умолчанию было установлено в 10 секунд. Вы можете увидеть следующую ошибку, если это значение слишком мало:

2017-04-04 12:19:05,670 p=18591 u=fred |  command timeout triggered, timeout value is 30 secs

Рекомендации по решению:

• Вариант 1 (глобальная настройка таймаута команды): Увеличьте значение таймаута команды в файле конфигурации или установив переменную среды.

  export ANSIBLE_PERSISTENT_COMMAND_TIMEOUT=60
  

  Чтобы сделать это постоянным изменением, добавьте следующее в ваш файл ansible.cfg:

  [persistent_connection]
  command_timeout = 60
  

• Вариант 2 (настройка таймаута команды на задачу): Увеличьте таймаут команды на уровне задачи. Все сетевые модули поддерживают значение таймаута, которое можно установить для каждой задачи. Значение таймаута управляет временем в секундах, по истечении которого задача завершится с ошибкой, если команда не вернула результат.

  Для локального типа подключения:

  Рекомендации по решению:

  - name: save running-config
    ios_command:
      commands: copy running-config startup-config
      provider: "{{ cli }}"
      timeout: 30
  

  Для сетевых типов подключения network_cli, netconf (применимо начиная с версии 2.7):

  Рекомендации по решению:

  - name: save running-config
    ios_command:
      commands: copy running-config startup-config
    vars:
      ansible_command_timeout: 60
  

Некоторые операции занимают больше, чем стандартные 30 секунд. Хорошим примером является сохранение текущей конфигурации на устройствах IOS в конфигурацию по умолчанию. В этом случае изменение значения таймаута с 30 до 60 секунд предотвратит сбой задачи до завершения команды.

Таймаут повторной попытки постоянного соединения

По умолчанию ANSIBLE_PERSISTENT_CONNECT_RETRY_TIMEOUT установлен в 15 (секунд). Вы можете увидеть следующую ошибку, если это значение слишком мало:

2017-04-04 12:19:35,708 p=18591 u=fred |  connect retry timeout expired, unable to connect to control socket
2017-04-04 12:19:35,709 p=18591 u=fred |  persistent_connect_retry_timeout is 15 secs

Рекомендации по решению:

Увеличьте значение таймаута бездействия постоянного соединения. Примечание: Это значение должно быть больше значения таймаута SSH (значение таймаута в разделе параметров в файле конфигурации) и меньше значения таймаута бездействия постоянного соединения (connect_timeout).

export ANSIBLE_PERSISTENT_CONNECT_RETRY_TIMEOUT=30

Чтобы сделать это постоянным изменением, добавьте следующее в ваш файл ansible.cfg:

[persistent_connection]
connect_retry_timeout = 30

Проблема с таймаутом из-за специфичной для платформы панели входа с типом подключения network_cli

В Ansible 2.9 и более поздних версиях добавлены параметры конфигурации плагина подключения network_cli для обработки специфичных для платформы меню входа. Эти параметры можно задавать в качестве переменных группы/хоста или задач.

Пример: Обработка одиночных запросов на ввод логина с помощью переменных хоста

$cat host_vars/<hostname>.yaml
---
ansible_terminal_initial_prompt:
  - "Connect to a host"
ansible_terminal_initial_answer:
  - "3"

Пример: Обработка нескольких запросов на ввод логина удалённого хоста с помощью переменных хоста

$cat host_vars/<inventory-hostname>.yaml
---
ansible_terminal_initial_prompt:
  - "Press any key to enter main menu"
  - "Connect to a host"
ansible_terminal_initial_answer:
  - "\\r"
  - "3"
ansible_terminal_initial_prompt_checkall: True

Для обработки нескольких запросов на ввод:

• Значения ansible_terminal_initial_prompt и ansible_terminal_initial_answer должны быть списком.
• Последовательность запросов должна соответствовать последовательности ответов.
• Значение ansible_terminal_initial_prompt_checkall должно быть установлено на True.

Проблемы с playbook

В этом разделе описываются проблемы, вызванные проблемами в самом Playbook.

Ошибка: «Невозможно перейти в режим конфигурации»

Платформы: eos и ios

Это происходит, когда вы пытаетесь выполнить задачу, требующую привилегированного режима в оболочке пользователя.

Например:

TASK [ios_system : configure name_servers] *****************************************************************************
task path:
fatal: [ios-csr1000v]: FAILED! => {
    "changed": false,
    "failed": true,
   "msg": "unable to enter configuration mode",
}

Рекомендации по решению:

В Ansible до версии 2.5: Добавьте authorize: yes в задачу. Например:

- name: configure hostname
  ios_system:
    provider:
      hostname: foo
      authorize: yes
  register: result

Если для перехода в привилегированный режим требуется пароль, его можно указать с помощью auth_pass; если auth_pass не задан, будет использована переменная среды ANSIBLE_NET_AUTHORIZE.

Добавьте authorize: yes в задачу. Например:

- name: configure hostname
  ios_system:
  provider:
    hostname: foo
    authorize: yes
    auth_pass: "{{ mypasswordvar }}"
register: result

Проблемы с прокси

delegate_to против ProxyCommand

Новая система подключения для сетевых модулей в Ansible 2.3, использующая cli транспорт, больше не поддерживает использование директивы delegate_to. Для использования бастиона или промежуточного хоста перехода для подключения к сетевым устройствам через cli транспорт, сетевые модули теперь поддерживают использование ProxyCommand.

Для использования ProxyCommand, настройте параметры прокси в файле инвентаризации Ansible для указания хоста прокси.

[nxos]
nxos01
nxos02

[nxos:vars]
ansible_ssh_common_args='-o ProxyCommand="ssh -W %h:%p -q bastion01"'

При указанной выше конфигурации просто создайте и запустите playbook как обычно, без дополнительных изменений. Сетевой модуль теперь подключится к сетевому устройству, сначала подключившись к хосту, указанному в ansible_ssh_common_args, что равно bastion01 в данном примере.

Вы также можете установить целевой прокси для всех хостов, используя переменные среды.

export ANSIBLE_SSH_ARGS='-o ProxyCommand="ssh -W %h:%p -q bastion01"'

Использование бастионного/переходного хоста с подключением netconf

Включение настройки перехода

Бастион/хост перехода с подключением netconf можно включить:

• Установив переменную Ansible ansible_netconf_ssh_config либо в значение True, либо в путь к пользовательскому файлу конфигурации ssh
• Установив переменную окружения ANSIBLE_NETCONF_SSH_CONFIG в значение True, либо в путь к пользовательскому файлу конфигурации ssh
• Установив ssh_config = 1 или ssh_config = <ssh-file-path> в разделе netconf_connection

Если переменная конфигурации установлена в значение 1, то proxycommand и другие переменные ssh считываются из файла конфигурации ssh по умолчанию (~/.ssh/config).

Если переменная конфигурации установлена в путь к файлу, то proxycommand и другие переменные ssh считываются из заданного пользовательского файла ssh.

Пример файла конфигурации ssh (~/.ssh/config)

Host jumphost
  HostName jumphost.domain.name.com
  User jumphost-user
  IdentityFile "/path/to/ssh-key.pem"
  Port 22

# Note: Due to the way that Paramiko reads the SSH Config file,
# you need to specify the NETCONF port that the host uses.
# i.e. It does not automatically use ansible_port
# As a result you need either:

Host junos01
  HostName junos01
  ProxyCommand ssh -W %h:22 jumphost

# OR

Host junos01
  HostName junos01
  ProxyCommand ssh -W %h:830 jumphost

# Depending on the netconf port used.

Пример файла инвентаризации Ansible

[junos]
junos01

[junos:vars]
ansible_connection=netconf
ansible_network_os=junos
ansible_user=myuser
ansible_password=!vault...

Разные проблемы

Периодическое завершение работы при использовании типа подключения network_cli

Если командная строка, полученная в ответ, не соответствует правильно в плагине подключения network_cli, задача может периодически завершаться с усечённым ответом или сообщением об ошибке operation requires privilege escalation. Начиная с версии 2.7.1, добавлен новый таймер чтения буфера, чтобы гарантировать правильное соответствие запросам и отправку полного ответа в выходные данные. Значение таймера по умолчанию составляет 0,2 секунды и может быть скорректировано для каждой задачи или установлено глобально в секундах.

Пример установки таймера для каждой задачи

- name: gather ios facts
  ios_facts:
    gather_subset: all
  register: result
  vars:
    ansible_buffer_read_timeout: 2

Чтобы сделать это глобальным параметром, добавьте следующее в ваш файл ansible.cfg:

[persistent_connection]
buffer_read_timeout = 2

Задержка таймера для каждой команды, выполняемой на удалённом хосте, может быть отключена, установив значение в ноль.

Неудачная задача из-за несовпадения регулярного выражения ошибки в ответе команды при использовании типа подключения network_cli

В Ansible 2.9 и более поздних версиях добавлены параметры конфигурации плагина подключения network_cli для обработки регулярных выражений stdout и stderr для определения, состоит ли ответ на выполнение команды из нормального ответа или ответа об ошибке. Эти параметры могут быть установлены как переменные группы/хоста, или как переменные задач.

Пример: для несовпадающего ответа об ошибке

- name: fetch logs from remote host
  ios_command:
    commands:
      - show logging

Вывод выполнения playbook:

TASK [first fetch logs] ********************************************************
fatal: [ios01]: FAILED! => {
    "changed": false,
    "msg": "RF Name:\r\n\r\n <--nsip-->
           \"IPSEC-3-REPLAY_ERROR: Test log\"\r\n*Aug  1 08:36:18.483: %SYS-7-USERLOG_DEBUG:
            Message from tty578(user id: ansible): test\r\nan-ios-02#"}

Рекомендации по решению:

Измените регулярное выражение ошибки для отдельной задачи.

- name: fetch logs from remote host
  ios_command:
    commands:
      - show logging
  vars:
    ansible_terminal_stderr_re:
      - pattern: 'connection timed out'
        flags: 're.I'

Параметры регулярных выражений плагина терминала ansible_terminal_stderr_re и ansible_terminal_stdout_re имеют pattern и flags в качестве ключей. Значение ключа flags должно быть значением, принятым методом re.compile python.

Периодическое завершение работы при использовании типа подключения network_cli из-за медленной сети или удалённого целевого хоста

В Ansible 2.9 и более поздних версиях добавлен параметр конфигурации плагина подключения network_cli для управления количеством попыток подключения к удалённому хосту. По умолчанию количество попыток равно трём. После каждой попытки повтора задержка между повторами увеличивается в геометрической прогрессии (степень 2) в секундах, пока не будут исчерпаны максимальные попытки или не будут срабатывать таймеры persistent_command_timeout или persistent_connect_timeout.

Чтобы сделать это глобальным параметром, добавьте следующее в ваш файл ansible.cfg:

[persistent_connection]
network_cli_retries = 5