Support of XML API for FWT and ARP lookup about netdot HOT 21 OPEN

Hi Vincent!

I don't have a need personally, but I wouldn't object to incorporating your code.
It looks like it needs the get_fwt part still.

from netdot.

Hi Carlos,

I've added get_fwt ( vink78@73e3bf5 ).

It works fine locally. Maybe someone can test it before I create a pull request?

from netdot.

Hi,
I'm trying to test this, but the version on vink78 repo seems to crash my apache (no error_log or message in /var/log/messages telling me what's going on), the only lines i see are:
Found = in conditional, should be == at /usr/local/netdot/lib/Netdot/Model/Device.pm line 4335.
Found = in conditional, should be == at /usr/local/netdot/lib/Netdot/Model/Device.pm line 5340.
wich i see also when trying the official version from cvicente/Netdot.git (not crashing apache but warnings are there)

I couldn't test it with Pg (I wanted to try that too) due to other errors. So I had to go with mysql, tried with both repos.

It might be a problem related to my "too new" OS debian 9.7. Using Netdot 1.0.7 from cvicente github (here), don't crash apache2 (after applying the patches included for Ubuntu). But i cannot add a device (the Palo Alto I intended to use to test this code), i think i may not have my mibs right, the same device with the same community from the same host answer to snmpwalk.

root@nicopc:~# snmpwalk -v 2c -c 'community123!' 10.1.1.104 .1.3.6.1.2.1.1.1
iso.3.6.1.2.1.1.1.0 = STRING: "Palo Alto Networks PA-5000 series firewall"
root@nicopc:~# /usr/local/netdot/bin/updatedevices.pl -I -d -v 2 -c "community123\!" -H 10.1.1.104
Found = in conditional, should be == at /usr/local/netdot/lib/Netdot/Model/Device.pm line 4335.
Found = in conditional, should be == at /usr/local/netdot/lib/Netdot/Model/Device.pm line 5340.
INFO - /usr/local/netdot/bin/updatedevices.pl started at Mon Feb  4 16:49:10 2019
INFO - Updating single device: 10.1.1.104
DEBUG - Device::search: 10.1.1.104 not found in DB
DEBUG - Device::_get_snmp_session: Trying SNMPv2 session with 10.1.1.104, community community123\!
SNMP::Info::_validate_autoload_method(sysServices) Unable to resolve method.
SNMP::Info::_validate_autoload_method(sysDescr) Unable to resolve method.
SNMP::Info::specify() - Could not get info from device at /usr/local/netdot/lib/Netdot/Model/Device.pm line 3876.
DEBUG - Device::_get_snmp_session: 10.1.1.104: SNMPv2 failed. Trying SNMPv1
SNMP::Info::_validate_autoload_method(sysServices) Unable to resolve method.
SNMP::Info::_validate_autoload_method(sysDescr) Unable to resolve method.
SNMP::Info::specify() - Could not get info from device at /usr/local/netdot/lib/Netdot/Model/Device.pm line 3876.
DEBUG - Device::_get_snmp_session: Failed SNMPv1 session with 10.1.1.104 community 'community123\!'
ERROR: Device::_get_snmp_session: Cannot connect to 10.1.1.104. Tried communities: community123\!
root@nicopc:~# /usr/local/netdot/bin/updatedevices.pl -I -d -v 2 -c "community123!" -H 10.1.1.104
Found = in conditional, should be == at /usr/local/netdot/lib/Netdot/Model/Device.pm line 4335.
Found = in conditional, should be == at /usr/local/netdot/lib/Netdot/Model/Device.pm line 5340.
INFO - /usr/local/netdot/bin/updatedevices.pl started at Mon Feb  4 16:49:20 2019
INFO - Updating single device: 10.1.1.104
DEBUG - Device::search: 10.1.1.104 not found in DB
DEBUG - Device::_get_snmp_session: Trying SNMPv2 session with 10.1.1.104, community community123!
SNMP::Info::_validate_autoload_method(sysServices) Unable to resolve method.
SNMP::Info::_validate_autoload_method(sysDescr) Unable to resolve method.
SNMP::Info::specify() - Could not get info from device at /usr/local/netdot/lib/Netdot/Model/Device.pm line 3876.
DEBUG - Device::_get_snmp_session: 10.1.1.104: SNMPv2 failed. Trying SNMPv1
SNMP::Info::_validate_autoload_method(sysServices) Unable to resolve method.
SNMP::Info::_validate_autoload_method(sysDescr) Unable to resolve method.
SNMP::Info::specify() - Could not get info from device at /usr/local/netdot/lib/Netdot/Model/Device.pm line 3876.
DEBUG - Device::_get_snmp_session: Failed SNMPv1 session with 10.1.1.104 community 'community123!'
ERROR: Device::_get_snmp_session: Cannot connect to 10.1.1.104. Tried communities: community123!

root@nicopc:~# cat /usr/local/netdot/etc/Site.conf | grep -i mib -A5
# Netdot shares a set of workable MIBs with the Netdisco project.
# The following variable specifies where the netdisco MIBs were installed in
# this system.
SNMP_MIBS_PATH  => '/usr/share/netdisco/mibs',

# Add or remove specific vendors as you see fit. Do not remove 'net-snmp' and 'rfc' 
SNMP_MIB_DIRS            =>  [ 'allied', 'arista', 'aruba', 'asante', 
                               'cabletron', 'cisco', 'cyclades', 'dell', 
			       'enterasys', 'extreme', 'foundry',  
			       'hp', 'juniper', 'netscreen', 'net-snmp',
			       'nortel', 'paloalto', 'rfc' ],

from netdot.

Hi @nicolatron,

If apache crash, it might be possible that some perl modules are missing:

• LWP::UserAgent
• HTTP::Request
• HTTP::Headers
• URI::Escape
• XML::LibXML

You can install it from existing debian packages or cpan.

Can you try to run updatedevice.pl to see what else is missing?

PS: I use an old redhat 6.10 for netdot.

from netdot.

Hi Vincent, thanks.
I don't think it was a problem of missing libraries becouse on the same host changing to cvicente/Netdot version and just doing the make install it worked, anyway for the sake of testing your code i'll use an old vm i have around with SLES11SP3. Any effort to make Netdot work on newer versions should be used on the official repo (hopefully with your code merged).
I'll post the results.

from netdot.

OS: SLES11SP3
Having this error:

ERROR: Can't locate object method "load_xml" via package "XML::LibXML" at /usr/local/netdot/lib/Netdot/Model/Device/API/Paloalto.pm line 249.

maqueta-netdot:~ # perldoc -m XML::LibXML | grep VERSION
use vars qw($VERSION @ISA @EXPORT @EXPORT_OK %EXPORT_TAGS
$VERSION = "1.66"; # VERSION TEMPLATE: DO NOT CHANGE
bootstrap XML::LibXML $VERSION;
  my ($runtime_version) = LIBXML_RUNTIME_VERSION() =~ /^(\d+)/;
  if ( $runtime_version < LIBXML_VERSION ) {
    warn "Warning: XML::LibXML compiled against libxml2 ".LIBXML_VERSION.

Vincent. Do you prefer that i move this to your fork?.

Added onodrim.defaultdomain's ip to /etc/hosts>
Also checked "Get ARP, Get FWT in netdot UI for this device

DEBUG - onodrim.defaultdomain: SNMP update completed in 1 sec
ERROR: Can't locate object method "load_xml" via package "XML::LibXML" at /usr/local/netdot/lib/Netdot/Model/Device/API/Paloalto.pm line 249.

from netdot.

just read i have to update XML::LibXML to version 1.70. Having problems to get cpan to update/communicate. I'm on it.

from netdot.

After upgrading XML::LibXML (to 2.0133) (had to install libxml2-devel rpm) error went away.
Sadly the PaloAlto is no longer on production and only has connected the managent interface and don't have traffic going through it, so i don't know if this test is good enought, any advice to improve it?. I don't have direct admin access to the firewall.
At least we know the code is not breaking anything, i can add and update other devices, and everything seems to work.

from netdot.

INFO - onodrim.defaultdomain: ARP cache fetched. 0 entries in 0 sec
DEBUG - onodrim.defaultdomain: FWT fetched. 0 entries in 0 sec

This means that no ARP and no FWT were found.

The script parse the output of 'show mac all' and 'show arp all' using API.

If you have no mac and no arp, it might explain why you have no entries.

from netdot.

The ARP cache can't be empty, it's talking to my cacti host wich is in another subnet so it must have it's gateway in the arp table at least, the problem seems to be Netdot is not detecting any IP for the device ("IP Info" is empty), and thus no subnet to validate arp entries against, as such arp validation will fail except for loopback devices. I don't know why Netdot is not adding the IP on the management interface. I've tried adding the IP manually for the mgmt interace in the "IP Info", and pinging the PaloAlto from other hosts in the management network, to make sure there are more entries in the ARP table, but the results are the same.
DEBUG - onodrim.defaultdomain: FWT fetched. 0 entries in 1 sec
DEBUG - onodrim.defaultdomain: FWT empty
INFO - onodrim.defaultdomain: ARP cache fetched. 0 entries in 0 sec
WARN - Device::API::_validate_arp: We have no subnet information. ARP validation will fail except for link-local addresses
INFO - onodrim.defaultdomain: IPv6 ND cache fetched. 0 entries in 0 sec
DEBUG - onodrim.defaultdomain: ARP cache empty
Updated SNMP::Info to 3.64, no changes.

from netdot.

I've the following on my Site.conf:

IGNORE_IPS_FROM_ARP_NOT_WITHIN_SUBNET => 0,

Even if subnet is not created, ARP is added.

On my PA5050, the ARP from management interface is not displayed.

from netdot.

Tried that, but as you said i can't see ARP entries (i no longer see the line of _validate_arp in the log, so that change worked).
Out of curiosity. Without that validation don't you see every public internet iP that passes the firewall on your ARP tables?.

from netdot.

I've installed Netdot from scratch (not easy) on a Debian 9.7 server:

• I've installed a lot of deb package , but, I had to install SNMP::Info from cpan
• paloalto mibs are required (from https://github.com/netdisco/netdisco-mibs )
• I followed the thread from here https://netdot-devel.osl.uoregon.narkive.com/2vaBwwGS/netdot-bug-1904-new-cannot-start-apache2-with-netdot-mason to start apache
• I've to enable FWT and ARP Collection:
  

I was able to collect FWT and ARP from my API keys.

from netdot.

Hello, I got admin access to the Palo Alto, and could create the API key (something i had not done/configure in the previous tests), your code works.
I don't get any ARP entries but that is also true if I curl the show arp command directly to the API (no results), tried to manually add some arp entries but had no luck with it showing, anyway that's a different problem, the FWT is correctly collected from the API.
Your fork works for me regarding Palo Alto API, and brakes nothing of the rest, i've added 148 devices and had it running for some weeks and everything is ok. Personally I see no reason not to do a pull request.
DEBUG - onodrim.defaultdomain: SNMP update completed in 0 sec
DEBUG - PhysAddr::format_address_db: MAC address (00:0e:38:e2:2f:e5) formatted for DB storage to: 000AAAAAAFE5
DEBUG - Device::API::Paloalto::_get_fwt_from_api: onodrim.defaultdomain: ae1.1507 -> 000AAAAAAFE5
DEBUG - PhysAddr::format_address_db: MAC address (00:0e:38:e2:2f:e5) formatted for DB storage to: 000AAAAAAFE5
DEBUG - Device::API::Paloalto::_get_fwt_from_api: onodrim.defaultdomain: ae1.1501 -> 000AAAAAAFE5
DEBUG - PhysAddr::format_address_db: MAC address (00:0e:38:e2:2f:e5) formatted for DB storage to: 000AAAAAAFE5
DEBUG - Device::API::Paloalto::_get_fwt_from_api: onodrim.defaultdomain: ae1.1499 -> 000AAAAAAFE5
DEBUG - onodrim.defaultdomain: FWT fetched. 3 entries in 0 sec
DEBUG - onodrim.defaultdomain: Updating Forwarding Table (FWT)
DEBUG - PhysAddr::fast_update: Updating MAC addresses in DB
DEBUG - PhysAddr::fast_update: Done Updating: 1 addresses in 0 sec
DEBUG - onodrim.defaultdomain: FWT updated. 3 entries in 0 sec
INFO - onodrim.defaultdomain: ARP cache fetched. 0 entries in 0 sec
INFO - onodrim.defaultdomain: IPv6 ND cache fetched. 0 entries in 0 sec
DEBUG - onodrim.defaultdomain: ARP cache empty
INFO - Device::snmp_update: onodrim.defaultdomain: Finished updating
INFO - bin/updatedevices.pl total runtime: 2 sec

from netdot.

@vink78 did you do the pull request at last?. I think this is great. And could be used as a starting point to add support for more devices with this kind of access.

from netdot.

@nicolatron It's an old work. I've rebased my branch on latest master:

https://github.com/vink78/Netdot/tree/palo

Can you try it? I think it need an XML perl lib to work...

On my site.conf, I've added something similar as:

FETCH_DEVICE_INFO_VIA_API => {
    '^panPA-(VM|\d+)'       => 'Paloalto',
},


DEVICE_API_KEYS => [
    {   pattern     => 'fw.*',
        token       => '<a secret token>',
        transport   => 'HTTPS',
        timeout     => '30',
     },
],

If something is missing, I'll add it. If you have no issue, I'll to a PR.

from netdot.

fulloutput.txt
Hello, i've installed it. I didn't had to install any extra libraries, and everything seems ok.
Got the API key using:
curl -X GET 'fiirewall.dns.name/api/?type=keygen&user=username&password=password' -k
(had to use -k as firewall os is old and key is deemed weak).
Then I configured the token on Site.conf.

Polling gives no error, but I see no ARP or FWT entries added, again this is a non productive device, which only has active management interface and HA. Just to check i added some static arp entries, and created the networks in netdot that device is using (seems using --add-subnets 1 is not adding them). Also on the device->IP info i see no entries. I think the fact that entries are not added have to do with this (there is layer 3 interface where arp entries can be added)

In the device:
user@onodrim(active)> show arp all

maximum of entries supported : 20480
default timeout: 1800 seconds
total ARP entries in table : 4
total ARP entries shown : 4
status: s - static, c - complete, e - expiring, i - incomplete

interface ip address hw address port status ttl

ethernet1/13 10.101.10.10 f0:1f:af:02:96:36 ethernet1/13 s N/A
ethernet1/13 10.101.10.20 f0:1f:af:02:96:40 ethernet1/13 s N/A
ethernet1/14 10.101.10.11 f0:1f:af:02:96:37 ethernet1/14 s N/A
vlan.xxxx 10.x.y.z aa:0c:29:69:d4:64 ae1.xxxx s N/A

And the updatedevice.pl -d relevant results:
DEBUG - onodrim.defaultdomain: FWT fetched. 0 entries in 0 sec
DEBUG - onodrim.defaultdomain: FWT empty
WARN - Device::API::_validate_arp: We have no subnet information. ARP validation will fail except for link-local addresses
DEBUG - PhysAddr::format_address_db: MAC address (f0:1f:af:02:96:40) formatted for DB storage to: F01FAF029640
DEBUG - Device::API::_validate_arp: onodrim.defaultdomain: valid: ethernet1/13 -> 10.101.10.20 -> F01FAF029640
DEBUG - PhysAddr::format_address_db: MAC address (f0:1f:af:02:96:36) formatted for DB storage to: F01FAF029636
DEBUG - Device::API::_validate_arp: onodrim.defaultdomain: valid: ethernet1/13 -> 10.101.10.10 -> F01FAF029636
DEBUG - PhysAddr::format_address_db: MAC address (f0:1f:af:02:96:37) formatted for DB storage to: F01FAF029637
DEBUG - Device::API::_validate_arp: onodrim.defaultdomain: valid: ethernet1/14 -> 10.101.10.11 -> F01FAF029637
DEBUG - PhysAddr::format_address_db: MAC address (aa:0c:29:69:d4:64) formatted for DB storage to: AA0C2969D464
DEBUG - Device::API::_validate_arp: onodrim.defaultdomain: valid: vlan.xxxx -> 10.x.y.z -> AA0C2969D464
INFO - onodrim.defaultdomain: ARP cache fetched. 0 entries in 1 sec
WARN - Device::API::_validate_arp: We have no subnet information. ARP validation will fail except for link-local addresses
INFO - onodrim.defaultdomain: IPv6 ND cache fetched. 0 entries in 0 sec
DEBUG - onodrim.defaultdomain: ARP cache empty
INFO - Device::snmp_update: onodrim.defaultdomain: Finished updating
INFO - /opt/netdot/netdot/prod/netdot-1.0.7/bin/updatedevices.pl total runtime: 4 sec

Full updatedevice.pl -d output attached.

from netdot.

See this:
WARN - Device::API::_validate_arp: We have no subnet information. ARP validation will fail except for link-local addresses

Do you have the same behaviour when you modify your site.conf:

IGNORE_IPS_FROM_ARP_NOT_WITHIN_SUBNET => 0,

from netdot.

After modifying that line ARP entries are added, ARP entry created in device view, and everything looks good.
INFO - onodrim.defaultdomain: ARP cache fetched. 4 entries in 0 sec
[...]
DEBUG - Ipblock::fast_update: Done Updating: 4 addresses in 0 sec
Bellow are arp entries in csv
IP,Physical Address,Interface
10.97.160.116,AA0C2969D464,onodrim.defaultdomain [vlan.1501]
10.101.10.10,F01FAF029636,onodrim.defaultdomain [ethernet1/13]
10.101.10.11,F01FAF029637,onodrim.defaultdomain [ethernet1/14]
10.101.10.20,F01FAF029640,onodrim.defaultdomain [ethernet1/13]
I'll edit some of my posts to remove useless information and save some scrolling time.

from netdot.

Hello,
I have this on production with several Palo Alto firewalls getting a few thousand ARP entries and working all right.
One caveat I had was that on the PAN-PRODUCT-MIB.my shipped with netdisco-mibs our products were missing, and I had to add them to the mib so I could match the correct device types in Site.conf. But that is not related to the Palo Alto API.
Another caveat is that some Physical Address are imported with value 0 (instead of corrent MAC address) but that is a behaviour I've detected on other devices, not only on the Palos. I guess it's cases where the relevant FWT entry timeout on the device but the ARP cache still contains it, or something like that, happends also from device CLI where it's show as incomplete MAC in some cases. The information is anyways relevant as at least it let you see what interface that given IP was coming from.
As far as I can tell, this is working well, and a pull request would be great.
By the way thank you very much both Vink78, Carlos and the rest of contributors.

Best regards

from netdot.

@vink78
Hello Vincent.
At least in my case netdot is not getting ip/mask or vlan information for the interfaces of the PaloAltos. I've read somewhere PaloAlto doesn't implement IP-MIB, so it can't be obtained via SNMP.
I've modified PaloAlto.pm so that it gets interface information via API and update device's ip/mask (and create subnets if needed) with that information. I think I cannot do a pull request on your repo, but if you are interested it is the palo branch of my repo. Initial tests are showing good results, but I won't try it on production yet.
I'm considering how can I add to netdot additional information like tag (vlan id), vsys, zone, fwt (more like the vrouter the interface belongs to not the forwarding table). Maybe as a *palo*vsys: xxx zone: xxx vrf: xxx *palo* entry on the ipblock comment (updatable on the next run if such tag \*palo\*.*\*palo\* exists in ipblock.comment). Interface tag (vlan id) may be used directly as vlan id for the subnet in question (where the ip of an interfaces resides). In my use case I don't see a problem with that.

We have pairs of firewalls (principal/failover) so the latest to be polled gets the ips (except for HA interfaces that have different IP on each device), so I'm thinking about disabling get ARP and get FWT from backup devices, maybe after a first run to document HA ip/mask on backup device.
Relevant branch is in
https://github.com/nicolatron/Netdot/tree/palo_ips/
I think i've only made changes to PaloAlto.pm (added sub _populate_interaces and a call to it prior to the call to get_arp_from_api ). So it should be trivial to carry over and test.
Best regards

from netdot.