Open Gharwen opened 3 months ago
Hello,
This behavior is part of pyATS. It's been a while since I touched this code, and to be honest - I don't have a lab to test it on.
That said, it looks like there's an extra comma after switch_enable
. Can you try removing it?
Hi Oren,
Removing the comma doesn't change anything. Regarding python syntax this comma is optional and it doesn't matter if it's there or not. As you can see in your original backend.py there is also a comma behind switch_password although it's the last variable in the "default" dictionary.
Connecting to a switch ends in 'ERROR: Problem connecting to ...
In the logs I can see that VanillaISE did a "show version | include operating mode" after it is connected to the switch. Then it did a "term length 0", "term width 0" and again a "show version". But then it tried a "config term" which is not allowed because the user is a priv 14.
Regarding my research and what I found out, I must mention that I am not a programmer, but a network administrator. However, I have a basic knowledge of programming languages.
In the backend.py I see that the variabel for the enable password will be loaded.
(line 33): switch_enable = os.environ.get("SWITCH_ENABLE", "")
But "switch_enable" is not used anywhere else, unlike "switch _user" or "switch_password", which are used when building the testbed_template.
(line 60 - 64) "credentials": { "default": { "username": switch_user, "password": switch_password, }
The connection process is probably controlled via Genie and Unicon. My search for the syntax to insert the enable password into the testbed_template has revealed that it should look like this:
But no enable mode is requested after connection. After “show version”, an attempt is still made to enter configuration mode directly with “config term”.
By the way... When I'm using a priv 15 user everything is OK. But due to our security requirements I have to use a priv 14 (or lower) user who has to request the enable mode followed by a password. And the presence of the corresponding variable tells me that this should actually be the case in the script.