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

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

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

  • Включение ведения журнала сети и чтение файла журнала
  • Включение ведения журнала взаимодействия с сетевым устройством
  • Изоляция ошибки
• Устранение неполадок с путями сокетов

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

  • Ошибка: «[Errno -2] Имя или служба не известны»
  • Ошибка: «Произошла ошибка аутентификации»
  • Ошибка: «подключение к хосту <hostname> вернуло ошибку» или «Неверный адрес»
  • Ошибка: «Нет доступных методов аутентификации»
  • Очистка постоянных подключений

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

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

• Проблемы с playbook

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

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

  • delegate_to vs ProxyCommand
  • Использование бастионного/переходного хоста с подключением netconf
  • Включение настроек переходного хоста
  • Пример файла конфигурации ssh (~/.ssh/config)

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

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

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

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

Проблемы с аутентификацией

• Неправильное указание учетных данных
• Удаленное устройство (сетевой коммутатор/маршрутизатор) не переходит на другие методы аутентификации
• Проблемы с ключами SSH

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

• Могут возникнуть при попытке извлечь большое количество данных
• Могут маскировать проблему с аутентификацией

Проблемы с playbook

• Использование delegate_to вместо ProxyCommand. Дополнительную информацию см. в руководстве по прокси сети.

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

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

Ansible включает ведение журнала для диагностики и устранения неполадок модулей 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 (ID процесса) процесса ansible-connection
• u=fred — это пользователь running ansible, а не удалённый пользователь, от имени которого вы пытаетесь подключиться
• 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 включает ведение журнала взаимодействия с устройствами в файл журнала для диагностики и устранения неполадок модулей 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
  cisco.ios.ios_command:
    commands:
      - show version
  vars:
    ansible_persistent_log_messages: True

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

[persistent_connection]
log_messages = True

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

# Enable device interaction logging
export ANSIBLE_PERSISTENT_LOG_MESSAGES=True

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

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

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

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

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

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

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

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

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

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

• подключаемся к switch1.example.net, указанному в файле инвентаризации inventory
• используем модуль arista.eos.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 ``-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

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

Устранение неполадок с путями сокетов

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

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

Например:

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 XX does not exist or cannot be found. See Troubleshooting socket path issues in the Network Debug and Troubleshooting Guide\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 XX. See Troubleshooting socket path issues in Network Debug and Troubleshooting Guide\n",
    "module_stdout": "",
    "msg": "MODULE FAILURE",
    "rc": 1
}

Предложения по решению:

1. Проверьте, что у вас есть права записи в путь сокета, указанный в сообщении об ошибке.
2. Следуйте инструкциям, описанным в включении журналирования сети.

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

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-connection не смог успешно связаться с удаленным сетевым устройством. Обычно это означает проблему с аутентификацией. Это сообщение общего характера, поэтому необходимо включить журналирование, чтобы определить основную причину проблемы.

Например:

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

[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
    cisco.ios.ios_command:
      commands: copy running-config startup-config
      provider: "{{ cli }}"
      timeout: 30
  

  Предложения по решению:

  - name: save running-config
    cisco.ios.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 (значение таймаута в разделе defaults файла конфигурации) и меньше, чем значение таймаута бездействия постоянного подключения (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.

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

Платформы: Arista EOS и Cisco IOS

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

Например:

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

Предложения по решению:

Используйте connection: ansible.netcommon.network_cli и become: yes

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

delegate_to против ProxyCommand

Для использования бастиона или промежуточного хоста перехода для подключения к сетевым устройствам через транспорт 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.
# In other words, 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=ansible.netcommon.netconf
ansible_network_os=junipernetworks.junos.junos
ansible_user=myuser
ansible_password=!vault...

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

Непрерывный сбой при использовании типа подключения ansible.netcommon.network_cli

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

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

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

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

[persistent_connection]
buffer_read_timeout = 2

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

Ошибка задачи из-за несоответствия регулярного выражения ошибки в ответе команды, использующей тип подключения ansible.netcommon.network_cli

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

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

- name: fetch logs from remote host
  cisco.ios.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
  cisco.ios.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.

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

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

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

[persistent_connection]
network_cli_retries = 5