Solución de problemas de errores de conexión de Ansible al administrar dispositivos Junos
En las siguientes secciones se describen los errores de conexión que puede encontrar al usar Ansible para administrar dispositivos Junos. En estas secciones también se presentan las posibles causas y soluciones de cada error.
Solución de problemas de conexión fallida, comando desconocido o errores de intérprete no encontrado
Problema
Descripción
Cuando se ejecuta un juniper.device módulo o un junipernetworks.junos módulo de la juniper.device colección, el nodo de control de Ansible genera un error acerca de una conexión fallida, un comando desconocido o no poder localizar el intérprete de Python. Por ejemplo:
UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ", "unreachable": true}
o bien
unknown command: /bin/sh\r\n
o bien
[ERROR]: Task failed: Action failed: The module interpreter '/home/user/projects/Ansible/.venv/bin/python' was not found.
Causa
Estos errores pueden surgir cuando el nodo de control de Ansible no ejecuta el módulo localmente.
Normalmente, Ansible requiere Python en el nodo administrado. El nodo de control de Ansible envía el módulo al nodo, donde se ejecuta y, a continuación, se elimina. Los juniper.device módulos no requieren Python en el dispositivo administrado, ya que utilizan la API XML de Junos y NETCONF para interactuar con el dispositivo. Por lo tanto, para realizar operaciones en dispositivos Junos, debe ejecutar los módulos localmente en el nodo de control de Ansible donde está instalado Python. Si Ansible intenta ejecutar un módulo directamente en el dispositivo Junos, genera un error.
Solución
Para indicar al nodo de control de Ansible que ejecute los módulos localmente, debe definir los parámetros de conexión adecuados para el conjunto de módulos. Puede definir los parámetros en diferentes ubicaciones, por ejemplo, en el archivo de inventario, en los archivos de variables de host o grupo, en el manual de estrategias o como argumentos de línea de comandos. El tipo de conexión varía en función del conjunto de módulos que elija y, en algunos casos, del módulo individual. Para obtener más información, consulte:
Solución de errores de host desconocidos
Problema
Descripción
Cuando se ejecuta un juniper.device módulo o un junipernetworks.junos módulo de la juniper.device colección, el nodo de control de Ansible genera un error acerca de un host, un patrón de host o una dirección desconocidos.
"msg": "Unable to make a PyEZ connection: ConnectUnknownHostError(dc1a.example.net)"
o bien
[WARNING]: Could not match supplied host pattern, ignoring: name
o bien
"msg": "[Errno -5] No address associated with hostname"
Causa
Estos errores se producen cuando el archivo de inventario de Ansible no define el host o el nodo de control de Ansible no puede resolver el nombre de host.
Cuando se ejecuta un módulo de Ansible, ya sea directamente o desde un manual, se debe definir cualquier host al que se haga referencia en los argumentos del módulo o en el manual, en el archivo de inventario de Ansible. La ubicación predeterminada del archivo de inventario es /etc/ansible/hosts. El nodo de control de Ansible debe ser capaz de resolver los nombres de host de cualquier host que defina en el archivo de inventario.
Solución
Actualice el archivo de inventario de Ansible para incluir el host que falta y asegúrese de que la resolución DNS funciona correctamente.
Para obtener más información sobre el archivo de inventario de Ansible, consulte Descripción del archivo de inventario de Ansible al administrar dispositivos Junos , así como la documentación oficial de Ansible en https://www.ansible.com/.
Solución de problemas de conexión rechazada y errores de socket
Problema
Descripción
Cuando se ejecuta un juniper.device módulo o un junipernetworks.junos módulo de la juniper.device colección, el nodo de control de Ansible genera un ConnectRefusedError error o un error de socket. Por ejemplo:
"msg": "Unable to make a PyEZ connection: ConnectRefusedError(dc1a.example.net)"
o bien
"msg": "Could not open socket to 198.51.100.101:830"
Causa
La causa más probable de estos errores es que NETCONF a través de SSH no está habilitado en el dispositivo Junos.
Para probar rápidamente si NETCONF está habilitado, verifique que la cuenta de usuario que ejecuta el módulo de Ansible pueda iniciar correctamente una sesión de NETCONF con el dispositivo.
user@ansible-cn:~$ ssh user@dc1a.example.net -p 830 -s netconf
Si el usuario puede establecer correctamente una sesión de NETCONF con el dispositivo en el puerto NETCONF predeterminado (830) o en un puerto configurado específicamente para NETCONF en su dispositivo, entonces NETCONF está habilitado. De lo contrario, debe habilitar NETCONF a través de SSH en el dispositivo.
Solución
Habilite el servicio NETCONF-over-SSH en el dispositivo de Junos.
[edit] user@host# set system services netconf ssh user@host# commit
Solución de errores del sistema operativo de la red host
Problema
Descripción
Cuando se ejecuta un junipernetworks.junos módulo de la juniper.device colección (juniper.device.junos_* module), el nodo de control de Ansible genera un host network os error. Por ejemplo:
[ERROR]: Task failed: Unable to automatically determine host network os. Please manually configure ansible_network_os value for this host
Causa
Los juniper.device.junos_* módulos requieren que especifique el SO de red de Ansible como juniper.device.junos para los hosts de destino que ejecutan Junos OS o los hosts de destino que ejecutan Junos OS Evolved.
Solución
Defina la ansible_network_os variable en la ubicación adecuada para su entorno y en la sintaxis necesaria para el formato del archivo. Por ejemplo, puede definir la variable en su archivo de inventario o en sus archivos de variables de host o grupo.
El siguiente archivo de inventario con formato INI de ejemplo define el SO de red de Ansible como juniper.device.junos para los hosts del grupo de junos inventario:
[junos] router1.example.com router2.example.com router3.example.com [junos:vars] ansible_network_os=juniper.device.junos ansible_connection=ansible.netcommon.netconf