Manual Reference Pages - APP::NETDISCO::MANUAL::TROUBLESHOOTING (3)
App::Netdisco::Manual::Troubleshooting - Tips and Tricks for Troubleshooting
Understanding Nodes and Devices
The two basic components in Netdiscos world are Nodes and Devices. Devices
are your network hardware, such as routers, switches, and firewalls. Nodes are
the end-stations connected to Devices, such as workstations, servers,
printers, and telephones.
Devices respond to SNMP, and therefore can report useful information about
themselves such as interfaces, operating system, IP addresses, as well as
knowledge of other systems via MAC address and ARP tables. Devices are
actively contacted by Netdisco during a discover (and other polling jobs such
as macsuck, arpnip).
Netdisco discovers Devices using neighbor protocols such as CDP and LLDP. We
assume your Devices are running these protocols and learning about their
connections to each other. If they arent, youll need to configure manual
topology within the web interface (or simply have standalone Devices).
Nodes, on the other hand, are passive as far as Netdisco is concerned. The
only job that contacts a Node is nbtstat, which makes NetBIOS queries. Nodes
are learned about via the MAC and ARP tables on upstream Devices.
Because Netdisco only learns about Devices through a neighbor protocol, its
possible to run an SNMP agent on a Node. Only if the Node is also advertising
itself via a neighbor protocol will Netdisco treat it as a Device. This can
account for undesired behaviour, such as treating a server (Node) as a Device,
or vice versa only recognising a switch (Device) as a Node.
To prevent avoid discovery of any target as a Device, use the discover_no,
discover_no_type, or discover_only configuration settings. If you dont
see links between Devices in Netdisco, it might be because theyre not running
a neighbor protocol, or for some reason not reporting the relationships to
Netdisco. Use the show command to troubleshoot this:
~netdisco/bin/netdisco-do show -d 192.0.2.1 -e c_id
Understanding Netdisco Jobs
Please read the section above, if youve not yet done so.
Netdisco has four principal job types:
The actions as named above will operate on one device only. Complimentary job
types discoverall, macwalk, arpwalk, and nbtwalk will enqueue one
corresponding single-device job for each known device. The Netdisco backend
daemon will then process the queue (in a random order).
Gather information about a Device, including interfaces, vlans, PoE status,
and chassis components (modules). Also learns about potential new Devices via
neighbor protocols and adds jobs for their discovery to the queue.
Gather MAC to port mappings from known Devices reporting Layer 2 capability.
Wireless client information is also gathered from Devices supporting the
Gather MAC to IP mappings from known Devices reporting layer 3 capability.
Poll a Node to obtain its NetBIOS name.
Run a netdisco-do Task with Debugging
The netdisco-do command has several debug flags which will show whats
going on internally. Usually you always add -D for general Netdisco
debugging, then -I for SNMP::Info logging and -Q for SQL tracing. For
~netdisco/bin/netdisco-do discover -d 192.0.2.1 -DIQ
You will see that SNMPv2 community strings are hidden by default, to make the
output safe for sending to Netdisco developers. To show the community string,
set the SHOW_COMMUNITY environment variable:
SHOW_COMMUNITY=1 ~netdisco/bin/netdisco-do discover -d 192.0.2.1 -DIQ
Dump an SNMP object for a Device
This is useful when trying to work out why some information isnt displaying
correctly (or at all) in Netdisco. It may be that the SNMP response isnt
understood. Netdisco can dump any leaf or table, by name:
~netdisco/bin/netdisco-do show -d 192.0.2.1 -e interfaces
~netdisco/bin/netdisco-do show -d 192.0.2.1 -e Layer2::HP::interfaces
You can combine this with SNMP::Info debugging, shown above (-I).
Interactive SQL terminal on the Netdisco Database
Start an interactive terminal with the Netdisco PostgreSQL database. If you
pass an SQL statement in the -e option then it will be executed.
~netdisco/bin/netdisco-do psql -e SELECT ip, dns FROM device
~netdisco/bin/netdisco-do psql -e COPY (SELECT ip, dns FROM device) TO STDOUT WITH CSV HEADER
The last example above is useful for sending data to Netdisco developers, as
its more compact and readable than the standard tabular output (second
Database Schema Redeployment
The database schema can be fully redeployed (even over an existing
installation), in a safe way, using the following command:
Debug HTTP Requests and Configuration
You can see HTTP Headers received by Netdisco, and other information such as
how its parsing the config file, by enabling the Dancer debug plugin. First
download the plugin:
~netdisco/bin/localenv cpanm --notest Dancer::Debug
Then run the web daemon with the environment variable to enable the feature:
DANCER_DEBUG=1 ~/bin/netdisco-web restart
A side panel appears in the web page with debug information. Be sure to turn
this off when youre done (stop and start without the environment variable)
otherwise secrets could be leaked to end users.
Neighbor Relations on Juniper EX
The LLDP configuration should look like:
|perl v5.20.3 ||APP::NETDISCO::MANUAL::TROUBLESHOOTING (3) ||2015-07-13 |
Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.