Script crashes if switch is using EOS version 4.23

[kosichd]

Trying to use ZTP to boot switches that are running 4.23 out of the box. Boostrap.py crashes with this error:

Apr 6 20:13:02 ZeroTouch: %ZTP-4-EXEC_SCRIPT_FAIL: Config script exited with an error. Error code: 1. Output: =============== Exception raised in '/usr/bin/python /tmp/zt-download ' (PID 29599; PPID 2096) ===============. Local variables by frame (innermost frame last):. File "/tmp/zt-download", line 90, in . cvAddr = 'www.arista.io'. cvproxy = ''. e = ImportError('No module named SysdbHelperUtils',). enrollmentToken =

Which seems to point to point to the below portion of the code. Does this just not work with EOS <4.24? Many switches are still coming out of the box running <4.24. When we upgraded the switch to 4.28, then tried again, the script worked. But this somewhat defeats the purpose of ZTP, where we are using CVaaS to upgrade the EOS once it is moved to the undefinied container.

82 ############## SysdbHelperUtils IMPORT HANDLING ##############
83 # SysdbHelperUtils library is not present in most EOS versions <4.24. Thus in such a
84 # case, we locally upgrade the EOS version and reboot the device. After the upgrade,
85 # EOS version of device must be upgraded and import for SysdbHelperUtils will not fail.
86 try:
87 from SysdbHelperUtils import SysdbPathHelper
88 except ImportError as e:

[toddhsimmons]

This comes directly from the deployment guide for ZTP. It takes 4.25.5+ If I recieved a batch that didn't have the required software version I'd complain to my account team immediately! Onboarding Devices: ZTP as-a-Service Requirements Arista’s Zero Touch Provisioning is used to configure a switch without user intervention. Built to fully leverage the power of Arista’s Extensible Operating System (EOS), ZTP as-a-Service provides a flexible solution to onboard EOS devices into CloudVision as-a-Service. Requirements: * DHCP Server: EOS device should be able to reach arista.io by obtaining valid IP settings from a DHCP server * EOS Version: The device should be running EOS version 4.25.5 or 4.26.1 or newer. * Permit ZTP in CloudVision as-a-Service Cluster: ZTP as-a-Service should be enabled in the CVaaS cluster via: Provisioning > Zero Touch Provisioning > Manage Permitted Devices

…

________________________________ From: kosichd ***@***.***> Sent: Thursday, April 6, 2023 8:01 PM To: aristanetworks/cloudvision-ztpaas-utils ***@***.***> Cc: Subscribed ***@***.***> Subject: [aristanetworks/cloudvision-ztpaas-utils] Script crashes if switch is using EOS version 4.23 (Issue #6) Trying to use ZTP to boot switches that are running 4.23 out of the box. Boostrap.py crashes with this error: Apr 6 20:13:02 ZeroTouch: %ZTP-4-EXEC_SCRIPT_FAIL: Config script exited with an error. Error code: 1. Output: =============== Exception raised in '/usr/bin/python /tmp/zt-download ' (PID 29599; PPID 2096) ===============. Local variables by frame (innermost frame last):. File "/tmp/zt-download", line 90, in . cvAddr = 'www.arista.io<https://urldefense.com/v3/__http:/www.arista.io__;!!BS-MXwIi!AperyiTsT8GTwar1sy4vx0ija-bAooLw-JNHy4MWws4-sDC9PMerI0OBq9oqZX36DbbbVmsDYHV3Fbfo$>'. cvproxy = ''. e = ImportError('No module named SysdbHelperUtils',). enrollmentToken = Which seems to point to point to the below portion of the code. Does this just not work with EOS <4.24? Many switches are still coming out of the box running <4.24. When we upgraded the switch to 4.28, then tried again, the script worked. But this somewhat defeats the purpose of ZTP, where we are using CVaaS to upgrade the EOS once it is moved to the undefinied container. 82 ############## SysdbHelperUtils IMPORT HANDLING ############## 83 # SysdbHelperUtils library is not present in most EOS versions <4.24. Thus in such a 84 # case, we locally upgrade the EOS version and reboot the device. After the upgrade, 85 # EOS version of device must be upgraded and import for SysdbHelperUtils will not fail. 86 try: 87 from SysdbHelperUtils import SysdbPathHelper 88 except ImportError as e: — Reply to this email directly, view it on GitHub<#6>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AYAPI2PMLXPLBIR33T6QW3TW75ROTANCNFSM6AAAAAAWWBQ36I>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[sujeethvs]

Workaround for this is, you could populate eosUrl. This needs to be a http URL pointing to a SWI image hosted on the local network. If eosUrl is populated, the switch gets upgraded with the pointed SWI image if eos version is less than 4.24 during ZTP.

[kosichd]

Thanks for the replies on this. I wish Arista would stop shipping new switches with such dated code from manufacturing. However, our account team gave us the workaround that Sujeethvs mentioned and it works fine. Here is the EOS CLI syntax in case others come across this thread and do not have a HTTP server -- you can use a switch to serve up the image. This is executed on the switch that owns 1.1.1.1that you want to use as a HTTP server. Then the ZTP script needs to be populated with 1.1.1.1 for eosURL: as Sujeethvs mentioned:

switch#cli vrf mgmt
switchvrf:mgmt)#bash sudo python3 -m http.server 80 --bind 1.1.1.1 --directory /mnt/flash/
Serving HTTP on 1.1.1.1 port 80 (http://1.1.1.1:80/) ..