Utilice el juniper.device.software módulo de Ansible para instalar software en dispositivos Junos
Puede utilizar el módulo de juniper.device.software Ansible para instalar software en dispositivos que ejecutan Junos OS o dispositivos que ejecutan Junos OS Evolved.
Utilice Ansible para instalar software
Juniper Networks ofrece módulos de Ansible que le permiten instalar una imagen de software en dispositivos Junos. En la Tabla 1 se describen los módulos. Si ya está utilizando un conjunto determinado de módulos de la juniper.device colección, use el módulo para ese conjunto.
|
Colección |
Conjunto de módulos |
Nombre del módulo |
|---|---|---|
|
|
||
|
|
En las siguientes secciones se describe cómo usar el juniper.device.software módulo para instalar un paquete de software en un dispositivo Junos. En las secciones se describe cómo especificar la ubicación de la imagen de software y el proceso y las opciones generales de instalación del software. En las secciones también se describe cómo realizar situaciones de actualización más especializadas, como una actualización de host de máquina virtual, una actualización de software en servicio unificada (ISSU unificada) o una actualización de software sin interrupciones (NSSU) en dispositivos compatibles con estas características.
Cómo especificar la ubicación de la imagen del software
Cuando utilice el juniper.device.software módulo para instalar software en dispositivos Junos, puede descargar el paquete de software en el nodo de control de Ansible. De forma predeterminada, el módulo copia el paquete en el dispositivo de destino antes de realizar la instalación. Para entornos de chasis virtual mixtos, los paquetes de software deben residir en el nodo de control de Ansible. En el caso de dispositivos independientes o entornos de chasis virtual no mixtos, también puede indicar al módulo que instale una imagen de software que ya resida en el dispositivo Junos de destino o que resida en una URL a la que se pueda acceder desde el dispositivo de destino.
En la tabla 2 se describen los argumentos de módulo que se deben configurar en función de la ubicación del paquete de software. El módulo siempre debe incluir el , pkg_seto remote_package el local_packageargumento. El no_copy argumento predeterminado es false, que indica al módulo que copie el paquete de software desde la ubicación especificada en el nodo de control de Ansible al dispositivo de destino.
|
Ubicación del paquete de software |
|
|
|
|---|---|---|---|
|
Nodo de control de Ansible |
Omitir o establecer en |
Para dispositivos independientes o entornos de chasis virtual no mixtos: Establézcalo |
(Opcional) Ruta de acceso al archivo en el dispositivo de destino en el que se copia el paquete de software. El directorio predeterminado es /var/tmp. Si |
|
Para entornos de chasis virtual mixtos: Establézcalo |
– |
||
|
Ubicación remota |
– |
– |
URL desde la perspectiva del dispositivo Junos de destino desde el que se instala el paquete de software. |
|
Dispositivo de destino |
Establezca en |
– |
Ruta de acceso al archivo en el dispositivo de destino en el que ya debe residir el paquete de software. El directorio predeterminado es /var/tmp. |
Si el paquete de software reside en el nodo de control de Ansible, incluya el argumento adecuado para la instalación:
-
local_package: instale software en un dispositivo Junos independiente o en miembros de un chasis virtual no mixto. El valor del argumento es una sola cadena que especifica la ruta absoluta o relativa a la imagen de software. -
pkg_set: instalar software en los miembros de un chasis virtual mixto. El valor del argumento es una lista de cadenas que especifican las rutas de archivo absolutas o relativas de las imágenes de software, sin ningún orden en particular, para los distintos miembros del chasis virtual.Por ejemplo:
pkg_set: - 'software/jinstall-qfx-5-13.2X51-D35.3-domestic-signed.tgz' - 'software/jinstall-ex-4300-13.2X51-D35.3-domestic-signed.tgz'
De forma predeterminada, cuando se incluye el local_package argumento o pkg_set , el módulo copia cualquier paquete de software del nodo de control de Ansible al directorio /var/tmp del dispositivo Junos de destino (dispositivo individual o dispositivo principal de chasis virtual). Si desea copiar la local_package imagen a un directorio diferente, defina el remote_package argumento y especifique el directorio de destino. Si el remote_package argumento incluye un nombre de archivo, los nombres de archivo de los local_package argumentos y remote_package deben ser idénticos, o el módulo genera un error.
Si el paquete de software ya reside en el dispositivo Junos de destino (dispositivo individual o dispositivo principal de chasis virtual), el módulo debe incluir el no_copy: true argumento y también el remote_package argumento. El remote_package argumento especifica la ruta de acceso de archivo a un paquete de software existente en el dispositivo de destino. Si remote_package no especifica un directorio, el valor predeterminado es /var/tmp.
Si el paquete de software reside en una ubicación distinta del nodo de control de Ansible o del dispositivo de destino, el módulo debe incluir el remote_package argumento y especificar la ubicación del paquete de software. El valor de remote_package es una URL desde la perspectiva del dispositivo Junos de destino. Para obtener información acerca de los formatos de URL aceptables, consulte Formato para especificar nombres de archivo y URL en comandos de la CLI de Junos OS.
Descripción general del proceso de instalación
Para usar Ansible para instalar un paquete de software en un dispositivo Junos, ejecute el módulo y proporcione los juniper.device.software argumentos necesarios. Por ejemplo:
---
- name: Perform a Junos OS software upgrade
hosts: dc1
connection: local
gather_facts: no
tasks:
- name: Upgrade Junos OS
juniper.device.software:
local_package: "software/jinstall-ppc-17.3R1.10-signed.tgz"
no_copy: false
validate: true
register: response
- name: Print the response
ansible.builtin.debug:
var: response
Cuando ejecuta el juniper.device.software módulo, realiza las siguientes operaciones:
Una vez que el paquete de software está en el dispositivo de destino, ya sea que se haya descargado allí inicialmente o que el módulo lo haya copiado, el módulo realiza las siguientes operaciones:
-
Valida la configuración con el nuevo paquete, a menos que el
validateargumento se establezca enfalse.Nota: A partirjuniper.devicede la versión 2.0.4, elvalidateparámetro predeterminado estrue. En versiones anteriores, el valor predeterminado esfalse. -
Instala el paquete en cada motor de enrutamiento individual, a menos que
all_reesté establecido enfalse. -
Reinicia cada motor de enrutamiento actualizado, a menos que el
rebootargumento se establezca enfalse.
El software módulo le permite registrar el progreso de la instalación incluyendo el argumento module logfile . De forma predeterminada, solo se registran los mensajes de nivel de gravedad WARNING o superior. Para registrar mensajes de nivel de gravedad INFO o superior, que es necesario para registrar mensajes para el proceso de instalación general, ejecute el manual con la -v opción de línea de comandos o --verbose .
Cómo especificar valores de tiempo de espera
El juniper.device.software módulo realiza operaciones sobre una sesión de NETCONF. El tiempo predeterminado para que se agote el tiempo de espera de una RPC de NETCONF es de 30 segundos. Durante el proceso de instalación, ciertas operaciones aumentan el intervalo de tiempo de espera de RPC de la siguiente manera:
-
Copiar e instalar el paquete en el dispositivo: 1800 segundos (30 minutos)
-
Calcular la suma de comprobación: 300 segundos (5 minutos)
-
Realizar una limpieza de almacenamiento: 300 segundos (5 minutos)
En algunos casos, el proceso de instalación, el cálculo de la suma de comprobación o la limpieza del almacenamiento pueden superar estos intervalos de tiempo. Puede cambiar el valor de tiempo de espera de estas operaciones estableciendo los argumentos , checksum_timeouty cleanfs_timeout en install_timeoutel número requerido de segundos en la lista de argumentos del módulo. Por ejemplo:
- name: Upgrade Junos OS
juniper.device.software:
local_package: "software/jinstall-ppc-17.3R1.10-signed.tgz"
validate: true
install_timeout: 2000
checksum_timeout: 420
cleanfs_timeout: 600
Cómo especificar opciones de instalación que no tienen un argumento de módulo equivalente
Cuando se usa el juniper.device.software módulo para instalar software en un dispositivo, el módulo invoca la RPC adecuada para los argumentos de instalación incluidos. Por ejemplo, el módulo invoca la <request-package-add> RPC para instalaciones estándar de Junos OS, la <request-vmhost-package-add> RPC para actualizaciones de host de VM, la <request-package-in-service-upgrade> RPC para situaciones de ISSU unificadas, etc.
El módulo admite argumentos explícitos para muchas de las opciones de instalación, por ejemplo, la validate opción. El módulo también admite el kwargs argumento. El argumento le permite incluir cualquier opción adicional que admita RPC. El kwargs argumento toma un diccionario de pares clave/valor de opciones adicionales admitidas.
Para obtener la lista actual de opciones admitidas por el módulo, consulte la documentación de referencia de API para el módulo. Para obtener una lista de todas las opciones disponibles para una RPC específica, consulte la documentación del comando equivalente o busque la etiqueta de solicitud de la RPC en el Explorador de API XML de Junos.
Solo debe incluir opciones de instalación que el dispositivo Junos de destino admita para la RPC dada.
En el siguiente manual, el software módulo instala una imagen de software nueva en los hosts de destino. El módulo incluye el kwargs argumento con unlink: true. Este argumento, que elimina el paquete de software del directorio después de una actualización correcta, equivale a incluir la <unlink/> opción en la <request-package-add> RPC.
---
- name: Perform a Junos OS software upgrade
hosts: router1
connection: local
gather_facts: no
tasks:
- name: Upgrade Junos OS
juniper.device.software:
local_package: "software/jinstall-ppc-17.3R1.10-signed.tgz"
kwargs:
unlink: true
register: response
- name: Print the response
ansible.builtin.debug:
var: response
Cómo realizar una actualización del host de VM
En los dispositivos que tienen motores de enrutamiento compatibles con host de VM, Junos OS se ejecuta como una máquina virtual (VM) sobre un host basado en Linux (host VM). Una actualización de host de VM requiere un paquete de instalación de host de VM (junos-vmhost-install-x.tgz) y actualiza el sistema operativo host y Junos OS compatible. En la CLI, la actualización se realiza mediante el comando del request vmhost software add modo operativo, el cual corresponde a la <request-vmhost-package-add> RPC.
El juniper.device.software módulo admite el argumento para realizar una actualización del vmhost: true host de VM. Cuando el argumento está presente, el módulo realiza la instalación utilizando RPC <request-vmhost-package-add> .
El siguiente manual actualiza y reinicia el Junos OS y el host OS en los dispositivos especificados:
---
- name: Upgrade VM Hosts
hosts: vm_hosts
connection: local
gather_facts: no
tasks:
- name: Perform a VM host upgrade
juniper.device.software:
local_package: "junos-vmhost-install-qfx-x86-64-18.1R1.9.tgz"
vmhost: true
register: response
- name: Print the response
ansible.builtin.debug:
var: response
Cómo realizar una ISSU o NSSU unificada
El juniper.device.software módulo admite la realización de una ISSU unificada o una NSSU en dispositivos que admitan la función y cumplan los requisitos necesarios. Para obtener más información sobre las funciones unificadas de ISSU y NSSU, consulte la documentación del software del producto.
La función ISSU unificada le permite actualizar entre dos versiones diferentes de Junos OS sin interrupciones en el plano de control y con una interrupción mínima del tráfico. Para realizar una ISSU unificada, el software módulo debe incluir el issu: true argumento. Por ejemplo:
---
- name: Perform a Junos OS software upgrade
hosts: mx1
connection: local
gather_facts: no
tasks:
- name: Perform a unified ISSU
juniper.device.software:
local_package: "junos-install-mx-x86-64-17.2R1.13.tgz"
issu: true
register: response
- name: Print the response
ansible.builtin.debug:
var: response
La función NSSU le permite actualizar el software de Junos OS que se ejecuta en un conmutador o chasis virtual con motores de enrutamiento redundantes con una interrupción mínima del tráfico de red. Para realizar una NSSU, el software módulo debe incluir el nssu: true argumento. Por ejemplo:
---
- name: Perform a Junos OS software upgrade
hosts: ex1
connection: local
gather_facts: no
tasks:
- name: Perform an NSSU
juniper.device.software:
local_package: "jinstall-ex-4300-17.3R1.10-signed.tgz"
nssu: true
register: response
- name: Print the response
ansible.builtin.debug:
var: response
Cómo instalar software en un miembro del chasis virtual de la serie EX
Por lo general, cuando actualice un chasis virtual de la serie EX no mezclado, siga el proceso de instalación descrito en Descripción general del proceso de instalación para actualizar todo el chasis virtual. Sin embargo, puede haber ocasiones en las que necesite instalar software en conmutadores miembro específicos en el chasis virtual. El juniper.device.software módulo le permite instalar un paquete de software en conmutadores de miembro individual en un chasis virtual de la serie EX no mixto.
Para instalar software en miembros específicos, incluya el member_id argumento y defina una lista de cadenas que especifiquen los ID de miembro. El sistema instala el paquete de software desde el dispositivo principal del chasis virtual en los miembros especificados.
El siguiente manual de estrategia de Ansible actualiza el software en el miembro 0 y el miembro 1 del chasis virtual de la serie EX:
---
- name: Upgrade specific EX VC members
hosts: ex_vc
connection: local
gather_facts: no
vars:
OS_version: "23.2R1.13"
OS_package: "junos-install-ex-x86-64-23.2R1.13.tgz"
pkg_dir: "software"
log_dir: /var/log/
tasks:
- name: Check NETCONF connectivity
ansible.builtin.wait_for:
host: "{{ inventory_hostname }}"
port: 830
timeout: 5
- name: Install package on EX VC members
juniper.device.software:
version: "{{ OS_version }}"
local_package: "{{ pkg_dir }}/{{ OS_package }}"
member_id: ["0","1"]
logfile: "{{ log_dir }}/software.log"
Ejemplo: Uso de Ansible para instalar software
En este ejemplo, se utiliza el módulo para instalar una imagen de juniper.device.software software en un dispositivo que ejecuta Junos OS.
Requisitos
En este ejemplo, se utilizan los siguientes componentes de hardware y software:
-
Servidor de administración de configuración que ejecuta Ansible 2.17 o posterior con la
juniper.devicecolección instalada -
Dispositivo Junos con NETCONF habilitado y una cuenta de usuario configurada con los permisos adecuados
-
Par de claves público/privado SSH configurado para el usuario adecuado en el nodo de control de Ansible y en el dispositivo de Junos
-
Archivo de inventario de Ansible existente con los hosts necesarios definidos
Descripción general
En este ejemplo, se presenta un manual de estrategias de Ansible que utiliza el juniper.device.software módulo para actualizar Junos OS en los hosts del grupo de inventario especificado. En este ejemplo, la imagen de software reside en el nodo de control de Ansible y el módulo copia la imagen en el dispositivo de destino antes de instalarlo. El módulo no define explícitamente un host argumento, por lo que el módulo funciona en el host predeterminado, que es {{ inventory_hostname }}.
Este manual incluye la Check NETCONF connectivity tarea, que utiliza el ansible.builtin.wait_for módulo para intentar establecer una sesión de NETCONF con el dispositivo Junos mediante el puerto NETCONF 830 predeterminado. Si el nodo de control no puede establecer una sesión NETCONF con un dispositivo durante la ejecución del manual, omite las tareas restantes de la reproducción para ese dispositivo.
La Install Junos OS package tarea ejecuta el juniper.device.software módulo siempre que la comprobación de NETCONF se haya realizado correctamente. El version argumento define la versión de Junos OS deseada tal y como la informaría el show version comando en el dispositivo Junos. Durante la ejecución del libro de estrategias, el módulo comprueba primero que la versión solicitada aún no esté instalada en el dispositivo. Si la versión solicitada es diferente de la versión instalada actualmente, el módulo instala la versión solicitada.
El local_package argumento define la ruta del paquete de software de Junos OS en el nodo de control de Ansible. Durante la instalación, el módulo:
-
Realiza una operación de limpieza de almacenamiento en el dispositivo de destino
-
Copia la imagen del software en el directorio /var/tmp del dispositivo
-
Verifica la suma de comprobación del archivo
-
Valida el software nuevo con respecto a la configuración activa
-
Instala el software en cada motor de enrutamiento en el host de destino
De forma predeterminada, el juniper.device.software módulo reinicia cada motor de enrutamiento una vez completada la instalación; sin embargo, esta tarea se establece reboot: true explícitamente para mayor claridad.
La tarea almacena el resultado del módulo en la response variable y notifica a un controlador. Si no ejecuta el manual con el modo de comprobación, el wait_reboot controlador intenta establecer una sesión con el dispositivo para comprobar que el dispositivo vuelve a estar en línea. La wait_time variable define el período de tiempo durante el cual el nodo de control intenta volver a conectarse con el dispositivo.
En este ejemplo se incluye el logfile parámetro para registrar el progreso de la instalación. Este registro es importante para fines de depuración en caso de que se produzca un error en la instalación, así como para registrar las fechas y horas de las instalaciones en los dispositivos. El usuario que ejecuta el manual debe tener permisos para escribir en el archivo de registro especificado. De forma predeterminada, solo se registran los mensajes de nivel de gravedad WARNING o superior. En el ejemplo se ejecuta el manual con la -v opción de registrar mensajes de nivel de gravedad INFO o superior para supervisar la instalación.
Configuración
Creación del manual de estrategias de Ansible
Para crear un manual de estrategias que utilice el juniper.device.software módulo para instalar una imagen de software en un dispositivo Junos:
-
Incluya el texto reutilizable para el libro de jugadas y esta jugada, que ejecuta los módulos localmente.
--- - name: Install Junos OS hosts: mx1 connection: local gather_facts: no
-
Defina o importe las variables necesarias, que para este ejemplo incluyen la versión deseada de Junos OS y la ruta a la nueva imagen, entre otras.
vars: OS_version: "23.4R1.9" OS_package: "junos-install-mx-x86-64-23.4R1.9.tgz" pkg_dir: "software" log_dir: "{{ playbook_dir }}" netconf_port: 830 wait_time: 3600 -
(Opcional) Cree una tarea para comprobar la conectividad de NETCONF.
tasks: - name: Check NETCONF connectivity ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: "{{ netconf_port }}" timeout: 5 -
Cree la tarea para instalar el paquete de Junos OS en el dispositivo y notificar al controlador.
- name: Install Junos OS package juniper.device.software: version: "{{ OS_version }}" local_package: "{{ pkg_dir }}/{{ OS_package }}" reboot: true validate: true logfile: "{{ log_dir }}/software.log" register: response notify: - wait_reboot -
(Opcional) Cree una tarea para imprimir la respuesta del módulo.
- name: Print response ansible.builtin.debug: var: response -
Cree el controlador que comprueba que el dispositivo vuelve a estar en línea después de reiniciar.
El nombre del controlador debe ser el mismo al que se hace referencia en la tarea de instalación.
handlers: - name: wait_reboot ansible.builtin.wait_for: host: "{{ inventory_hostname }}" port: "{{ netconf_port }}" timeout: "{{ wait_time }}" when: not response.check_mode
Resultados
En el nodo de control de Ansible, revise el manual de estrategias completado. Si el manual no muestra el código deseado, repita las instrucciones de este ejemplo para corregirlo.
---
- name: Install Junos OS
hosts: mx1
connection: local
gather_facts: no
vars:
OS_version: "23.4R1.9"
OS_package: "junos-install-mx-x86-64-23.4R1.9.tgz"
pkg_dir: "software"
log_dir: "{{ playbook_dir }}"
netconf_port: 830
wait_time: 3600
tasks:
- name: Check NETCONF connectivity
ansible.builtin.wait_for:
host: "{{ inventory_hostname }}"
port: "{{ netconf_port }}"
timeout: 5
- name: Install Junos OS package
juniper.device.software:
version: "{{ OS_version }}"
local_package: "{{ pkg_dir }}/{{ OS_package }}"
reboot: true
validate: true
logfile: "{{ log_dir }}/software.log"
register: response
notify:
- wait_reboot
- name: Print response
ansible.builtin.debug:
var: response
handlers:
- name: wait_reboot
ansible.builtin.wait_for:
host: "{{ inventory_hostname }}"
port: "{{ netconf_port }}"
timeout: "{{ wait_time }}"
when: not response.check_mode
Ejecute el manual
Para ejecutar el manual de estrategias:
-
Emita el
ansible-playbookcomando en el nodo de control y proporcione la ruta del manual de estrategias y las opciones necesarias.user@ansible-cn:~/ansible$ ansible-playbook -v ansible-pb-junos-install-os.yaml Using /etc/ansible/ansible.cfg as config file PLAY [Install Junos OS] **************************************************** TASK [Check NETCONF connectivity] ****************************************** ok: [mx1a.example.com] => {"changed": false, "elapsed": 0, "match_groupdict": {}, "match_groups": [], "path": null, "port": 830, "search_regex": null, "state": "started"} TASK [Install Junos OS package] ******************************************** changed: [mx1a.example.com] => {"changed": true, "check_mode": false, "msg": "Package /home/user/ansible/software/junos-install-mx-x86-64-23.4R1.9.tgz successfully installed. Response from device is: \nVerified junos-install-mx-x86-64-23.4R1.9 signed by PackageProductionECP256_2023 method ECDSA256+SHA256\n [...output truncated...] NOTICE: 'pending' set will be activated at next reboot... Reboot successfully initiated. Reboot message: Shutdown NOW! [pid 79385]"} TASK [Print response] ****************************************************** ok: [mx1a.example.com] => { "response": { "changed": true, "check_mode": false, "failed": false, "msg": "Package /home/user/ansible/software/junos-install-mx-x86-64-23.4R1.9.tgz successfully installed. Response from device is: \nVerified junos-install-mx-x86-64-23.4R1.9 signed by PackageProductionECP256_2023 method ECDSA256+SHA256\nVerified auto-snapshot signed by PackageProductionECP256_2023 method ECDSA256+SHA256\n [...output truncated...] NOTICE: 'pending' set will be activated at next reboot... Reboot successfully initiated. Reboot message: Shutdown NOW! [pid 79385]" } } RUNNING HANDLER [wait_reboot] ********************************************** ok: [mx1a.example.com] => {"changed": false, "elapsed": 250, "match_groupdict": {}, "match_groups": [], "path": null, "port": 830, "search_regex": null, "state": "started"} PLAY RECAP ***************************************************************** mx1a.example.com : ok=4 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Verificación
Verificar la instalación
Propósito
Compruebe que la instalación del software se realizó correctamente.
Acción
La salida del libro de estrategias debe indicar cualquier tarea con errores. Sin embargo, también puede revisar el contenido del archivo de registro definido en el manual para obtener más información sobre la instalación. Aquí se muestra un ejemplo de salida de archivo de registro. Se han omitido algunos resultados por brevedad.
2024-08-23 22:20:49,455 - ncclient.transport.ssh - INFO - Connected (version 2.0, client OpenSSH_7.9) 2024-08-23 22:20:52,950 - ncclient.transport.ssh - INFO - Authentication (publickey) successful! ... 2024-08-23 22:21:00,770 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] computing checksum on local package: /home/user/ansible/software/junos-install-mx-x86-64-23.4R1.9.tgz 2024-08-23 22:21:08,070 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] cleaning filesystem ... ... 2024-08-23 22:21:08,329 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] before copy, computing checksum on remote package: /var/tmp/junos-install-mx-x86-64-23.4R1.9.tgz ... 2024-08-23 22:21:08,491 - paramiko.transport - INFO - Connected (version 2.0, client OpenSSH_7.9) 2024-08-23 22:21:08,958 - paramiko.transport - INFO - Authentication (publickey) successful! 2024-08-23 22:21:16,846 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 363528192 / 3635202890 (10%) 2024-08-23 22:21:24,405 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 727056384 / 3635202890 (20%) 2024-08-23 22:21:31,966 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 1090568192 / 3635202890 (30%) 2024-08-23 22:21:39,652 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 1454096384 / 3635202890 (40%) 2024-08-23 22:21:47,631 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 1817608192 / 3635202890 (50%) 2024-08-23 22:21:55,343 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 2181136384 / 3635202890 (60%) 2024-08-23 22:22:02,878 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 2544648192 / 3635202890 (70%) 2024-08-23 22:22:11,395 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 2908176384 / 3635202890 (80%) 2024-08-23 22:22:19,949 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 3271688192 / 3635202890 (90%) 2024-08-23 22:22:27,522 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] b'junos-install-mx-x86-64-23.4R1.9.tgz': 3635202890 / 3635202890 (100%) 2024-08-23 22:22:27,533 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] after copy, computing checksum on remote package: /var/tmp/junos-install-mx-x86-64-23.4R1.9.tgz ... 2024-08-23 22:22:44,891 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] checksum check passed. 2024-08-23 22:22:44,892 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] validating software against current config, please be patient ... ... 2024-08-23 22:27:52,538 - ncclient.transport.ssh - INFO - [host mx1a.example.com session-id 27526] Received message from host 2024-08-23 22:27:52,542 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] software validate package-result: 0 Output: Verified junos-install-mx-x86-64-23.4R1.9 signed by PackageProductionECP256_2023 method ECDSA256+SHA256 Adding junos-mx-x86-64-23.4R1.9 ... ... Validating against /config/juniper.conf.gz mgd: commit complete Validation succeeded 2024-08-23 22:27:52,542 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] installing software on RE0 ... please be patient ... ... 2024-08-23 22:30:57,510 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] software pkgadd package-result: 0 Output: Verified junos-install-mx-x86-64-23.4R1.9 signed by PackageProductionECP256_2023 method ECDSA256+SHA256 ... NOTICE: 'pending' set will be activated at next reboot... 2024-08-23 22:30:57,510 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] installing software on RE1 ... please be patient ... ... 2024-08-23 22:34:30,228 - jnpr.ansible_module.juniper.device.software - INFO - [mx1a.example.com] software pkgadd package-result: 0 Output: Pushing /var/tmp/junos-install-mx-x86-64-23.4R1.9.tgz to re1:/var/tmp/junos-install-mx-x86-64-23.4R1.9.tgz Verified junos-install-mx-x86-64-23.4R1.9 signed by PackageProductionECP256_2023 method ECDSA256+SHA256 ... NOTICE: 'pending' set will be activated at next reboot... ... 2024-08-23 22:34:30,732 - ncclient.operations.rpc - INFO - [host mx1a.example.com session-id 27526] Requesting 'CloseSession'
Significado
El contenido del archivo de registro indica que el manual copió e instaló correctamente la imagen en ambos motores de enrutamiento en el dispositivo de destino.
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.
juniper.device de la versión 2.0.4, el validate parámetro predeterminado es true. En versiones anteriores, el valor predeterminado es false.