Solucionar 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. Estas secciones también presentan posibles causas y soluciones para cada error.
Solucionar problemas de errores de conexión fallidos o no válidos
Problema
Descripción
Durante la ejecución de un juniper.device módulo en un dispositivo Junos, el nodo de control de Ansible genera un error sobre una conexión SSH fallida o un comando desconocido. Por ejemplo:
UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ", "unreachable": true}
o
unknown command: /bin/sh\r\n
Causa
Estos errores pueden producirse cuando el módulo no se ejecuta localmente en el nodo de control de Ansible.
Normalmente, Ansible requiere Python en el nodo administrado, y el nodo de control de Ansible envía el módulo al nodo, donde se ejecuta y luego se elimina. Los módulos de Juniper Networks no requieren Python en los dispositivos Junos, ya que usan Junos PyEZ y la API XML de Junos a través de 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, inclúyalos juniper.device connection: local en el manual de estrategias de Ansible o incluya el argumento de la --connection local línea de comandos al ejecutar módulos individuales. Por ejemplo:
--- - name: Get Device Facts hosts: junos connection: local gather_facts: no
Solucionar problemas de errores de host desconocidos
Problema
Descripción
Durante la ejecución de un juniper.device módulo, el nodo de control de Ansible genera un ConnectUnknownHostError error.
"msg": "Unable to make a PyEZ connection: ConnectUnknownHostError(dc1a.example.net)"
Causa
El host no está definido en el archivo de inventario de Ansible o el nodo de control de Ansible no puede resolver el nombre de host.
Al ejecutar un módulo de Ansible, ya sea directamente o desde un libro de estrategias, cualquier host al que se haga referencia en los argumentos del módulo o en el libro de estrategias debe definirse en el archivo de inventario de Ansible. La ubicación predeterminada del archivo de inventario es /etc/ansible/hosts. Si el archivo de inventario hace referencia a un nombre de host, el nodo de control de Ansible debe poder resolver el nombre de host.
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 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/.
Solucionar problemas de errores de conexión rechazada
Problema
Descripción
Durante la ejecución de un juniper.device módulo, el nodo de control de Ansible genera un ConnectRefusedError error. Por ejemplo:
"msg": "Unable to make a PyEZ connection: ConnectRefusedError(dc1a.example.net)"
Causa
La causa más probable de un error de conexión rechazada es que NETCONF sobre 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 que esté configurado específicamente para NETCONF en su dispositivo, entonces NETCONF estará habilitada. De lo contrario, debe habilitar NETCONF sobre SSH en el dispositivo.
Solución
Habilite el servicio NETCONF-over-SSH en el dispositivo Junos.
[edit] user@host# set system services netconf ssh user@host# commit