update Node/Device explanation

This commit is contained in:
Oliver Gorwits
2015-02-27 15:28:42 +00:00
parent 8aa8661b4c
commit 71b7d44eea

View File

@@ -15,21 +15,26 @@ 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).
Nodes on the other hand are passive as far as Netdisco is concerned. The only
job which contacts a Node is nbtstat, which makes NetBIOS queries. Nodes are
learned about via the MAC and ARP tables on Devices. Sometimes you might run
an SNMP agent on a server (Node), and in this case Netdisco will treat it as a
Device unless you prevent this using the C<discover_no> or C<discover_only>
configuration.
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 aren't, you'll need to configure manual
topology within the web interface (or simply have standalone Devices).
If you don't see links between Devices in Netdisco, it's either because
they're not running a neighbor protocol, or for some reason not reporting the
relationships to Netdisco. Use the C<show> command to troubleshoot this:
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, it's
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 C<discover_no>,
C<discover_no_type>, or C<discover_only> configuration settings. If you don't
see links between Devices in Netdisco, it might be because they're not running
a neighbor protocol, or for some reason not reporting the relationships to
Netdisco. Use the C<show> command to troubleshoot this:
~netdisco/bin/netdisco-do show -d 192.0.2.1 -e c_id