ktbyers / netmiko

Multi-vendor library to simplify Paramiko SSH connections to network devices
MIT License
3.62k stars 1.31k forks source link

Netmiko output blank - paloalto_panos #2864

Open nathaniel-mills opened 2 years ago

nathaniel-mills commented 2 years ago

Hi,

I run Netmiko for bulk packet captures in AWS. It works well but there is never output when using the Palo Alto (paloalto_panos) device type. Output for Cisco works well. An example would be:

from netmiko import ConnectHandler

print("Connecting to Palo Alto to show clock")

virtual_palo = {
    'device_type': 'paloalto_panos',
    'host':   '192.168.1.100',
    'username': 'automationadmin',
    'password': 'ciscothenpalo123',
}
net_connect = ConnectHandler(**virtual_palo)

output = net_connect.send_command('show clock')
print(output)

print("Connecting to Cisco Switch to show clock")

cisco_switch = {
    'device_type': 'cisco_ios',
    'host':   '192.168.1.101',
    'username': 'automationadmin',
    'password': 'ciscothenpalo123',
}
net_connect = ConnectHandler(**cisco_switch)

output = net_connect.send_command('show clock')
print(output)

This is just an example by the way, I don't run the scripts to show the clock :-). The output would be:

python3 test_script.py
Connecting to Palo Alto to show clock

Connecting to Cisco Switch to show clock
10:18:46.830 BST Tue Jul 19 2022

You see the issue. By the way this is my Netmiko version:

pip show netmiko
Name: netmiko
Version: 4.1.1
Summary: Multi-vendor library to simplify legacy CLI connections to network devices
Home-page: https://github.com/ktbyers/netmiko
Author: Kirk Byers
Author-email: ktbyers@twb-tech.com
License: MIT
Location: /usr/local/lib/python3.9/site-packages
Requires: ntc-templates, paramiko, pyserial, pyyaml, scp, setuptools, tenacity, textfsm

PAN-OS:

vm-license: VM-100
vm-cap-tier: 6.5 GB
vm-cpu-count: 2
vm-memory: 7857036
vm-mode: Amazon AWS
cloud-mode: cloud
sw-version: 10.1.5-h1

Any help would be great thanks.

ktbyers commented 2 years ago

Can you capture the log output and post it here:

https://github.com/ktbyers/netmiko/blob/develop/COMMON_ISSUES.md#enable-netmiko-logging-of-all-reads-and-writes-of-the-communications-channel

You can obscure anything in the log that is confidential to your environment.

nathaniel-mills commented 2 years ago

Thanks,

Please see attached file: test.log

ktbyers commented 2 years ago

@nathaniel-mills Does it work if you do?

from netmiko import ConnectHandler

print("Connecting to Palo Alto to show clock")

virtual_palo = {
    'device_type': 'paloalto_panos',
    'host':   '192.168.1.100',
    'username': 'automationadmin',
    'password': 'ciscothenpalo123',
}
net_connect = ConnectHandler(**virtual_palo)

output = net_connect.send_command('show clock', expect_string=r"#")
print(output)

print("Connecting to Cisco Switch to show clock")

Note, I added the expect_string argument to the send_command() call.

nathaniel-mills commented 2 years ago

So 😄 ... It didn't work as per your tweak, however it does work with:

output = net_connect.send_command('show clock', expect_string=r">")
print(output)

Or:

output = net_connect.send_command_timing('show clock')
print(output)

My colleague just pointed out a gap of lines before and after the actual time when jumping in on the CLI:

automationadmin@ip-192-168-1-100> show clock

Thu Jul 21 00:57:10 PDT 2022

automationadmin@ip-192-168-1-100> exit

I think the expect string is a good "fix". I guess I just misunderstood the exact workings of the command. By the way last question if I may. What would be the ideal expect string to look out for in my case?

  1. ">"
  2. "PDT"
ktbyers commented 2 years ago

The expect_string should probably be the trailing character for the prompt:

So in the log file you posted earlier:

LON-CGH-SWA-041#

You would use a r"#".

In the device above, you would use a r">".

If you have a mix of devices that use either a # or > then probably a regex like: r"[>#]" would work.

This really shouldn't have been required i.e. it means there is something still going wrong in Netmiko, but the above will potentially work as a workaround.

nathaniel-mills commented 2 years ago

Thanks a bunch for this. The switch was Cisco which ends with the #, however above that in the logs the Palo Alto ends with the >. I'll definitely settle with the workaround and I suppose a future release may address this long term.

Thanks again!

nathaniel-mills commented 2 years ago

Current workarounds:

output = net_connect.send_command('show clock', expect_string=r">")
print(output)

Or:

output = net_connect.send_command_timing('show clock')
print(output)
ktbyers commented 2 years ago

I am going to re-open this issue (as it does indicate there is an underlying Netmiko bug which should be fixed).

GayanDilanka commented 1 year ago

Hi for me also below one worked

output = net_connect.send_command('show clock', expect_string=r">") print(output)

sliddjur commented 9 months ago

expect_string=r">" seem to solve everything in regards to palo alto issues and netmiko

SecretSkills01 commented 2 months ago

Hello ! I've tried the workaround on our PaloAlto while in config mode, but it does not seem to work. current_peer_address = net_connect.send_command("show network ike gateway GW-Test peer-address", expect_string=r"#")

Any idea on it? In the Logs I see that the command has sucessfully run but my variable current_peer_address keeps being empty. The trailing character for the prompt while in config mode is "#".

ktbyers commented 2 months ago

@SecretSkills01 You probably need to post your Netmiko session_log and a broader section of your code.

isomogyi commented 1 month ago

The higher version devices do have a lag in cli interaction. When netmiko tries to auto-detect the correct prompt of the device, issues an ENTER and waits a little bit. If no response comes in then it sends it again and again. Then, when executing the cli command itself, it is prepend by the device prompt as many times as many enters have been issued followed by the real reply. After that - netmiko wants to return the result as anything before the prompt but as the prompt (from find_prompt's enters) is the pattern at the very beginning - effectively an empty string is returned.

In my case - passing fast_cli=False to ConnectHandler, seems to fix the find_prompt's eagerness.