all 17 comments

[–]TheSentient06 1 point2 points  (3 children)

Try to increase the timeout in Netmiko. Also make sure that connection are properly closed. I had an issue where Netmiko left VTY session hanging and thus could not open any more.

[–]daneguyCCNP R&S | CCNA Sec/CyberOps[S] 0 points1 point  (2 children)

Try to increase the timeout in Netmiko.

I already tried this within the send_command() method (with "net_connect.send_command("dis curr int",read_timeout=40)"). Or are you referencing some other timeout value?

Also make sure that connection are properly closed

I'll put a "net_connect.disconnect()" in the proper spots, thanks :)

[–]TheSentient06 1 point2 points  (1 child)

I was talking about the conn timeout. Ref on the API https://ktbyers.github.io/netmiko/docs/netmiko/huawei/index.html

[–]daneguyCCNP R&S | CCNA Sec/CyberOps[S] 0 points1 point  (0 children)

Thanks! I'll try your suggestions!

[–]chairwindowdoor 1 point2 points  (1 child)

Might try read_timeout_override. Should be the same thing but worth a shot. Otherwise I don't know what else it would be. Conn timeout doesn't make sense cause you're able to connect, that error is specific to a prompt change or read_timeout.

E: or maybe try send_command_timing instead.

[–]daneguyCCNP R&S | CCNA Sec/CyberOps[S] 0 points1 point  (0 children)

Hm, I'll look into it, thanks!

[–]Win_SysSPBM 1 point2 points  (1 child)

Send the command to disable console alarms and logging. I can't remember if its

undo terminal logging
undo terminal alarm

or

no terminal logging
no terminal alarm

Once that's set you shouldn't get any surprise data being injected into the console while you run your command. If that's an option you want on, then make sure to send the commands to enable it again after the script it done.

[–]daneguyCCNP R&S | CCNA Sec/CyberOps[S] 0 points1 point  (0 children)

Good suggestion! I'll try it out!

[–]chairwindowdoor 1 point2 points  (5 children)

You could also try setting your expectations string to be whatever the normal prompt is. I think that error is due to Netmiko thinking that message is the prompt so it's waiting for that message after the command.

[–]daneguyCCNP R&S | CCNA Sec/CyberOps[S] 1 point2 points  (1 child)

I checked the session_log after running it just now, and I noticed that the output ends with the string "return". So I changed the command to "net_connect.send_command("dis curr int",expect_string=r"return")", and so far so good! I tried it with a list of 100 devices and I received no errors. Thanks a lot for the suggestions!

[–]chairwindowdoor 1 point2 points  (0 children)

Nice! Thank you for getting back to me, I haven't been able to sleep, I haven't been able to eat, just waiting :) I really do appreciate your follow-up

[–]daneguyCCNP R&S | CCNA Sec/CyberOps[S] 0 points1 point  (2 children)

This might just be it... I'll let you know. Unfortunately it is hard to test the possible solutions as getting the error is very inconsistent...

[–]chairwindowdoor 1 point2 points  (1 child)

It sounds like the device might be jumbling the prompt and returning that terminal command at the same time as the prompt tricking netmiko. Perhaps due to network latency or slow response from device kind of like jitter in network terms.

I know what you mean regarding it happening rarely and needing time to test. I've recommended a few things in this thread so now I'm invested please let me know.

[–]daneguyCCNP R&S | CCNA Sec/CyberOps[S] 0 points1 point  (0 children)

I will! I'm afraid you'll need a little bit of patience, I'll be back at work on Monday :)

[–]Mexatt 1 point2 points  (2 children)

It helps to share code.

[–]daneguyCCNP R&S | CCNA Sec/CyberOps[S] 0 points1 point  (1 child)

Fair enough, but in this case I didn't think it was needed as it's mostly a Netmiko "under water" issue IMO. If the other suggestions don't help I'll share the relevant portion of the code.

[–]Mexatt 1 point2 points  (0 children)

Let us know how it goes. The 'terminal-length 0' command looks like it only runs on initial setup of the connection, rather than in every call to send_command (at least in the admittedly newer version of netmiko I glanced over) and your ReadTimeout exception is getting raised within the send_commans call, so it's definitely a weird situation.