Closed jnicholson56 closed 6 months ago
Is this specific to vmhost device or any Junos device?
I have only tested it on vmhost devices. I don't remember anything in the underlying code that was specific to vmhost. I would expect this behavior on any junos device.
On Tue, Feb 13, 2024, 13:49 apurvaraghu @.***> wrote:
Is this specific to vmhost device or any Junos device?
— Reply to this email directly, view it on GitHub https://github.com/Juniper/ansible-junos-stdlib/issues/624#issuecomment-1942180960, or unsubscribe https://github.com/notifications/unsubscribe-auth/AILVUEVJSZXCSOKGM5IUYBLYTOYSXAVCNFSM6AAAAAA3BY2ZEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBSGE4DAOJWGA . You are receiving this because you authored the thread.Message ID: @.***>
Hi @jnicholson56 Thanks , I have tested with Dual RE MX device with connection: local From the logs it looks to be image downloaded to RE0 , RE0 is installed first and then package is pushed to RE1 , RE1 installation happens .
May 6 13:27:57 [NETCONF] - [25609] Incoming: <?xml version="1.0" encoding="UTF-8"?><nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:2c00ec5
5-ce53-405a-ba9d-e484925ae3a2"><request-package-add><no-validate/><package-name>http://10.220.22.5//junos-x86-64-21.4R3-S2.3.tgz</package-name><re0/></request-package-add>
</nc:rpc>]]>]]>
May 6 13:27:57 [NETCONF] - [25609] Outgoing: <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/20.3R0/junos" xmlns:nc="
urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:2c00ec55-ce53-405a-ba9d-e484925ae3a2">
May 6 13:27:57 [NETCONF] - [25609] Outgoing: <pipe>
May 6 13:27:57 [NETCONF] - [25609] Outgoing: <more-no-more/>
May 6 13:27:57 [NETCONF] - [25609] Outgoing: </pipe>
May 6 13:27:57 [NETCONF] - [25609] Outgoing: <cli>
May 6 13:27:57 [NETCONF] - [25609] Outgoing: <ignore-signals>
hup
</ignore-signals>
May 6 13:27:57 [NETCONF] - [25609] Outgoing: </cli>
May 6 13:27:57 [NETCONF] - [25609] Outgoing: <output>
May 6 13:28:54 [NETCONF] - [25609] Outgoing: /var/tmp/junos-x86-64-21.4R3-S2.3.tgz.25814 77 MB 77 MBps
May 6 13:28:54 [NETCONF] - [25609] Outgoing: Renaming to junos-x86-64-21.4R3-S2.3.tgz ...
May 6 13:29:08 [NETCONF] - [25609] Outgoing: Verified junos-x86-64-21.4R3-S2.3 signed by PackageProductionECP256_2022 method ECDSA256+SHA256
May 6 13:30:43 [NETCONF] - [25609] Outgoing: Verified deebe signed by PackageProductionECP256_2022 method ECDSA256+SHA256
May 6 13:30:43 [NETCONF] - [25609] Outgoing: Verified dsa signed by PackageProductionECP256_2022 method ECDSA256+SHA256
May 6 13:30:43 [NETCONF] - [25609] Outgoing: Verified dsa-x86-64-21.4R3-S2 signed by PackageProductionECP256_2022 method ECDSA256+SHA25
May 6 13:32:02 [NETCONF] - [25609] Incoming: <?xml version="1.0" encoding="UTF-8"?><nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:071ea19
a-054c-4e98-a6ab-46d2f9effc99"><request-package-add><no-validate/><package-name>http://10.220.22.5//junos-x86-64-21.4R3-S2.3.tgz</package-name><re1/></request-package-add>
</nc:rpc>]]>]]>
May 6 13:32:02 [NETCONF] - [25609] Outgoing: <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/20.3R0/junos" xmlns:nc="
urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:071ea19a-054c-4e98-a6ab-46d2f9effc99">
May 6 13:32:02 [NETCONF] - [25609] Outgoing: <pipe>
May 6 13:32:02 [NETCONF] - [25609] Outgoing: <more-no-more/>
May 6 13:32:02 [NETCONF] - [25609] Outgoing: </pipe>
May 6 13:32:02 [NETCONF] - [25609] Outgoing: <cli>
May 6 13:32:02 [NETCONF] - [25609] Outgoing: <ignore-signals>
hup
</ignore-signals>
May 6 13:32:02 [NETCONF] - [25609] Outgoing: </cli>
May 6 13:32:02 [NETCONF] - [25609] Outgoing: <output>
May 6 13:32:02 [NETCONF] - [25609] Outgoing: Fetching package...
May 6 13:32:02 [NETCONF] - [25609] Outgoing: </output>
May 6 13:33:00 [NETCONF] - [25609] Outgoing: <output>
May 6 13:33:00 [NETCONF] - [25609] Outgoing: Pushing /var/tmp/mchassis-install.tgz to re1:/var/tmp/junos-x86-64-21.4R3-S2.3.tgz
May 6 13:33:00 [NETCONF] - [25609] Outgoing: </output>
May 6 13:34:59 [NETCONF] - [25609] Outgoing: <pipe>
May 6 13:34:59 [NETCONF] - [25609] Outgoing: <more-no-more/>
May 6 13:34:59 [NETCONF] - [25609] Outgoing: </pipe>
May 6 13:34:59 [NETCONF] - [25609] Outgoing: <cli>
I have not yet tested the installation on vmhost device, I will check it and update the logs here .
Thanks ,
Hi @jnicholson56 Thanks , When we set the parameter all_re: True in the playbook
We are sending the following RPC to RE0 of the device, as part of the RPC execution, image gets downloaded to the RE0 and installation continues.
<request-package-add><no-validate/><package-name>http://x,x,x,x//junos-x86-64-21.4R3-S2.3.tgz</package-name><re0/></request-package-add>
After successful completion of the above RPC, another request-package-add RPC for RE1 is executed, as part of the RPC execution, image gets downloaded to the RE0 and pushed to the RE1 for installation,
<request-package-add><no-validate/><package-name>http://x.x.x.x//junos-x86-64-21.4R3-S2.3.tgz</package-name><re1/></request-package-add>
It is as per the implementation of the RPC / command executed on the device, which downloads the package to the local RE from remote URL before installation.
Thanks & Regards Chidanand
Right. that was the behavior I also observed. My ask was can it be changed?
The first test you did is a bit confusing. I think what is happening is that when you tell it to install to RE1, it is downloading the file to RE0 (primary) and then pushing it to RE1. It looks like it is still downloading twice as opposed to once. Each RE has the download from 10.220.22.5 portion which to me says it is downloading from that ftp server.
RE0:
May 6 13:27:57 [NETCONF] - [25609] Incoming: <?xml version="1.0" encoding="UTF-8"?><nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:2c00ec5
5-ce53-405a-ba9d-e484925ae3a2"><request-package-add><no-validate/><package-name>http://10.220.22.5//junos-x86-64-21.4R3-S2.3.tgz</package-name><re0/></request-package-add>
</nc:rpc>]]>]]>
RE1:
May 6 13:32:02 [NETCONF] - [25609] Incoming: <?xml version="1.0" encoding="UTF-8"?><nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:071ea19
a-054c-4e98-a6ab-46d2f9effc99"><request-package-add><no-validate/><package-name>http://10.220.22.5//junos-x86-64-21.4R3-S2.3.tgz</package-name><re1/></request-package-add>
</nc:rpc>]]>]]>
May 6 13:33:00 [NETCONF] - [25609] Outgoing: Pushing /var/tmp/mchassis-install.tgz to re1:/var/tmp/junos-x86-64-21.4R3-S2.3.tgz
I have observed that you can watch /var/home/remote/
on the primary RE and you will see a tmp folder with a random name will be added for each download.
routername-re0> file list detail
/var/home/remote/:
total blocks: 163912
drwx------ 2 remote 20 512 Dec 12 05:45 ...transferring.file.........2o9l6k/
drwx------ 2 remote 20 512 Dec 12 05:45 ...transferring.file.........FtnMHJ/
drwx------ 2 remote 20 512 Dec 12 05:45 ...transferring.file.........P0HGuw/
drwx------ 2 remote 20 512 Dec 12 05:45 ...transferring.file.........qjHyFX/
Hi @jnicholson56 Thanks for the information. I will explore the supported "request system software add /request-package-add" command options and update .
Thanks Chidanand
Hi @jnicholson56
After going through the documentation of "request system software add" JUNOS CLI command, this is the default behavior of JUNOS CLI/RPC command to download the package to the RE0 and install the package.
JUNOS CLI/RPC command does not provide the option to install the both the REs with single download.
We rely on the underlying JUNOS CLI/RPC commands to perform the ansible tasks and JUNOS CLI command does not provide any such options and this is the limitation of JUNOS CLI/RPC command.
request system software add http://x.x.x.x//junos-x86-64-21.4R3-S2.3.tgz ?
Possible completions:
<[Enter]> Execute this command
best-effort-load Load succeeds if at least one statement is valid
delay-restart Don't restart processes
force Force addition of package (ignore warnings)
no-copy Don't save copies of package files
no-validate Don't check compatibility with current configuration
on-primary Install image on primary partition while booted on secondary partition
re0 Install package on RE0
re1 Install package on RE1
reboot Reboot system after adding package
unlink Remove the package after successful installation
+ upgrade-with-config Additional configs ('text/xml' format) to be applied on upgrade
validate Check compatibility with current configuration
validate-on-host Remote host or user@host for configuration validation
validate-on-routing-engine Routing engine for configuration validation
| Pipe through a command
If we don't specify the RE0/RE1 , then by default it downloads the image to the current RE and install the packages request system software add http://x.x.x.x//junos-x86-64-21.4R3-S2.3.tgz
when we specify RE0, then it downloads the image to the RE0 and proceeds with installation .
when we specify RE1, then it downloads the image to the RE0 and pushes the image to RE1 and proceeds with installation
we can try ISSU option for Dual RE devices , since it is the same JUNOS CLI/RPC command with option "in-service-upgrade" might download the images again to both the REs .
Please proceed with JUNOS PR for single package download option needs to be supported .
Thanks Chidanand
Thank you for looking into this. I will pursue this with my account team using a PR.
Issue Type
Module Name
juniper.device collection
OS / Environment
Tested on the following versions: 20.2.R3-S3.6 20.2.R3.9 20.2.R3-S2.5 22.2R3.15
Not specific to any version
Summary
When upgrading a router and designating a remote_package, Ansible initiates a file transfer for each RE independently instead of downloading once and installing on both RE's.
For RE0, the package is downloaded to the primary RE and staged to RE0. For RE1, the package is downloaded to the primary RE and started to RE1.
This happens if RE0 or RE1 is primary.
SW packages can be large and take quite some time to download depending on how far away the file server is or what version of JUNOS is being used. Duplicating downloads can double this time and cause upgrades to take too long to complete.
Steps to reproduce
Ran playbook with the following upgrade task.
Expected results
The package should be downloaded once and stage to both RE's versus a download per RE.
Actual results