Send netdisco-users mailing list submissions to
netdisco-users@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/netdisco-users
or, via email, send a message with subject or body 'help' to
netdisco-users-requ...@lists.sourceforge.net
You can reach the person managing the list at
netdisco-users-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. Re: Manual topology config (Oliver Gorwits)
2. Re: Manual topology config (Simon Hobson)
3. Re: Manual topology config (Oliver Gorwits)
4. Re: Change of snmp credentials (Oliver Gorwits)
5. Re: Linux SNMP issues (Was: Manual topology config) (Simon Hobson)
6. Re: Expire nodes / devices problem (Tobias Gerlach)
--- Begin Message ---
On 2016-10-02 09:08, Simon Hobson wrote:
Oliver Gorwits <oli...@cpan.org> wrote:
Marvellous! Could you do me a favour and send over any LLDP and SNMP
config you used (off list is fine)? I would like to include more
instructions for Linux routers in the docs.
Will do, I've still got some more boxes to do so I can check I haven't
missed anything. It'll have to wait till I next have some "slack" time
at work though - it's one of those "filler" jobs.
No worries, we're all doing this in spare time ;-)
Thanks again,
oliver.
--- End Message ---
--- Begin Message ---
Oliver Gorwits <oli...@cpan.org> wrote:
> Marvellous! Could you do me a favour and send over any LLDP and SNMP
> config you used (off list is fine)?
OK, here goes - but I've just been through the same steps on another box and
it's not working properly. These all apply to Debian Wheezy. As will probably
be obvious, I'm "no expert" in most of this.
Basic steps :
apt-get install --no-install-recommends snmpd lldpd
edit /etc/default/lldpd
DAEMON_ARGS="-k -x -l -m <IP>"
where <IP> is the main IP address you want to report as the device management
address. This is in an HP switch environment so I'm using LLDP.
restart lldpd
edit /etc/snmp/snmpd.conf
Under AGENT BEHAVIOUR, comment out
agentAddress udp:127.0.0.1:161
and uncomment
agentAddress udp:161,udp6:[::1]:161
Under ACCESS CONTROL
Where it has
#rocommunity secret 10.0.0.0/16
add
rocommunity <your secret> <your management device IP/net>
Under SYSTEM INFORMATION, change sysServices to suit the host
sysServices 76
Default is 72, 74 is suitable for a host that's supporting level 2 (eg Xen host
running virtual switches (aka bridges)), 76 for a device that's also doing
level 3 routing
https://tools.ietf.org/html/rfc3418
And if running a firewall, allow SNMP traffic in.
Now, at one location this is working just fine(ish - see below on VLANs). I did
have a bit of a hiccup as one of our providers is sending CDP packets up the
wire, these were being passed through one HP switch and picked up by another
that shouldn't have even been able to see the traffic (different VLAN) !
Disabling CDP on that latter device worked around the problem - though I think
it's a problem with the first switch which is one of the "not very smart"
models.
Now, here's where it gets interesting !
This morning I tried to do the same steps on a box I have at another site,
linked via a VPN - changing the lldpd config to do CDP instead of LLDP. I
deleted the Pseudo device in NetDisco and tried to discover this device.
The device is found, but not it's interfaces or any neighbour information. If I
do "netdisco-do discover -d <IP> -DI", on a working device I see entries like
this :
debug [a.a.a.a] device - aliased as *.*.*.*
...
debug resolving 12 aliases with max 50 outstanding requests
...
debug [a.a.a.a] interfaces - removed 8 interfaces
debug [a.a.a.a] interfaces - added 8 new interfaces
...
<some LLDP stuff>
and a few "SNMP::Info::_validate_autoload_method(hasCDP) Unable to resolve
method."
On the device that doesn't discover properly, I see entries like :
debug resolving 0 aliases with max 50 outstanding requests
...
SNMP::Info::_validate_autoload_method(hasCDP) Unable to resolve method.
...
debug [b.b.b.b] neigh - CDP/LLDP not enabled!
As a test, I enabled LLDP on the switch this remote system is connected to, and
get the same results "debug [b.b.b.b] neigh - CDP/LLDP not enabled!" lldpctl
shows the switch from the Linux box, and show lldp neighbors on the switch
shows the Linux box.
As an aside ... On checking another device that uses VLANs, I see that has
"SNMP::Info::_validate_autoload_method(i_vlan_type) Unable to resolve method."
in the discover debug as well. To add, this seems to be the case for all 4
devices I've looked at today.
Finally, I'll add that some obvious differences between the systems are : amd64
vs i686, kernel 2.6.32 vs 3.2.0, using backports or not (snmpd and lldpd both
same versions). To summarise :
Router 1: 2.6.32-5-xen-686 running as PV guest on Xen, no VLANs present,
aliases detected, interfaces detected, neighbours detected
Router 2: 3.2.0-4-amd64 bare metal, VLANs not detected, aliases not detected,
interfaces not detected, neighbours not detected
Host 1: 3.2.0-4-amd64, VLANs not detected, aliases interfaces and neighbours
detected
Host 2 (hosts router 1): 3.2.0-4-686-pae, VLANs not detected, aliases
interfaces and neighbours detected
--- End Message ---
--- Begin Message ---
Hi Simon,
On 2016-10-03 12:51, Simon Hobson wrote:
OK, here goes - but I've just been through the same steps on another
box and it's not working properly. These all apply to Debian Wheezy.
As will probably be obvious, I'm "no expert" in most of this.
From my understanding (feeble itself) your steps look about right, and I
will reformat them into a Netdisco doc - many thanks!!
The device is found, but not it's interfaces or any neighbour
information. If I do "netdisco-do discover -d <IP> -DI", on a working
device I see entries like this :
This smells to me like the system is running the protocols just fine,
but not reporting their status in SNMP. This is not uncommon. Netdisco
is picking up the neighbor information only from the SNMP tables served
from the device. If they're missing, then it looks like features are
missing even when they're running fine. The snmp agent running on the
linux machine needs to know about the tables, usually through a subagent
which would be provided by lldpd.
https://vincentbernat.github.io/lldpd/usage.html
http://www.snmp.com/ciagent/agentdef.html
You can probe the linux server tables, if you know what you're looking
for, using Netdisco:
https://metacpan.org/pod/distribution/App-Netdisco/lib/App/Netdisco/Manual/Troubleshooting.pod#Dump-an-SNMP-object-for-a-Device
Over to the "unable to resolve method" errors.... this is Netdisco
saying that the "device class" for this device (i.e. the platform it
chose) doesn't seem to have support for the feature. The device class is
shown in the Device Details page of the web, or on the CLI if you run
netdisco-do with -D for debug. Has it just the generic
SNMP::Info::Layer3 ?
You can play around by using the above troubleshooting command but
forcing a particular class, to see if pretending to be something else
would help. Then we can patch across support for the feature from the
supporting class (to SNMP::Info::Layer3::Linux, or whatever):
~netdisco/bin/netdisco-do show -d 192.0.2.1 -e Layer3::C6500::interfaces
So some things are consistent like VLANs not being detected, and others
such as the interfaces are inconsistent between the systems. I admit our
Linux router support is a bit feeble :(.
regards,
oliver.
debug [a.a.a.a] device - aliased as *.*.*.*
...
debug resolving 12 aliases with max 50 outstanding requests
...
debug [a.a.a.a] interfaces - removed 8 interfaces
debug [a.a.a.a] interfaces - added 8 new interfaces
...
<some LLDP stuff>
and a few "SNMP::Info::_validate_autoload_method(hasCDP) Unable to
resolve method."
On the device that doesn't discover properly, I see entries like :
debug resolving 0 aliases with max 50 outstanding requests
...
SNMP::Info::_validate_autoload_method(hasCDP) Unable to resolve method.
...
debug [b.b.b.b] neigh - CDP/LLDP not enabled!
As a test, I enabled LLDP on the switch this remote system is
connected to, and get the same results "debug [b.b.b.b] neigh -
CDP/LLDP not enabled!" lldpctl shows the switch from the Linux box,
and show lldp neighbors on the switch shows the Linux box.
As an aside ... On checking another device that uses VLANs, I see that
has "SNMP::Info::_validate_autoload_method(i_vlan_type) Unable to
resolve method." in the discover debug as well. To add, this seems to
be the case for all 4 devices I've looked at today.
Finally, I'll add that some obvious differences between the systems
are : amd64 vs i686, kernel 2.6.32 vs 3.2.0, using backports or not
(snmpd and lldpd both same versions). To summarise :
Router 1: 2.6.32-5-xen-686 running as PV guest on Xen, no VLANs
present, aliases detected, interfaces detected, neighbours detected
Router 2: 3.2.0-4-amd64 bare metal, VLANs not detected, aliases not
detected, interfaces not detected, neighbours not detected
Host 1: 3.2.0-4-amd64, VLANs not detected, aliases interfaces and
neighbours detected
Host 2 (hosts router 1): 3.2.0-4-686-pae, VLANs not detected, aliases
interfaces and neighbours detected
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Netdisco mailing list
netdisco-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netdisco-users
--- End Message ---
--- Begin Message ---
Hi Linwood,
Jeroen already gave a good reply a little while ago, and acknowledged
there was a strange behaviour in your case. I have spent some time
looking at this and can now report on the resultant change (with a more
detailed reply for the benefit of the list archive).
On 2016-07-26 20:16, o...@leferguson.com wrote:
I finally found there is a "community" table that stashes an IP and
the community tags that last worked.
Should deleting a host perhaps clear out any IP's in the community
table that have been associated with that device?
There is a "community" table that caches the SNMPv2 write string, as
well as hint(s) for snmp_auth config tag names if they are used.
The reason to cache any community string, and the snmp_auth config tag
names, is to allow faster reconnection to a device once we have
previously connected. The reason to put some data in a separate table is
to allow improved security if you have 3rd-party applications accessing
the Netdisco database: you can apply RBAC in PostgreSQL to restrict them
to not seeing the "community" table.
When config is initialised for a Netdisco job, the SNMP configuration
matching the cached tag hint jumps to the top of the list of all
possible SNMP configurations, to hopefully allow faster polling. This
was intentional but did not take into account your situation of wanting
to change the community string in use for a device, where more than one
string would work.
So I have fixed this bug. When a device is deleted all the community
information is also deleted. Assuming you have reordered the tags within
snmp_auth config, on rediscovery Netdisco will walk the full list and
use the first successful community.
This fix will be in the next release.
regards,
oliver.
--- End Message ---
--- Begin Message ---
Oliver Gorwits <oli...@cpan.org> wrote:
> On 2016-10-03 12:51, Simon Hobson wrote:
>> OK, here goes - but I've just been through the same steps on another
>> box and it's not working properly. These all apply to Debian Wheezy.
>> As will probably be obvious, I'm "no expert" in most of this.
>
> From my understanding (feeble itself) your steps look about right, and I
> will reformat them into a Netdisco doc - many thanks!!
Missed a couple of settings for snmpd :
Under SYSTEM INFORMATION change sysLocation and sysContact to sensible values.
Under ACCESS CONTROL, comment out "rocommunity public default -V systemonly"
These are the only differences I can see between the config files. The latter
is optional and stops giving basic information to just about anyone capable of
getting SNMP packets to/from your device.
>> The device is found, but not it's interfaces or any neighbour
>> information. If I do "netdisco-do discover -d <IP> -DI", on a working
>> device I see entries like this :
Ah, this is a bit ... embarrassing ...
Rather hard to spot until I noticed that things got "worse" when I commented
out that "pubic" line above, and I couldn't get snmpwalk to work. On a closer
inspection of snmpd.conf I realised I'd mistyped the community secret. NetDisco
had correctly discovered the device initially using "public" - which doesn't
give the information (such as interfaces) being asked for.
Once I corrected that error, up pop the interfaces and IP addresses and
neighbour.
Just had to add a manual connection for the tunnel.
BTW - the device info shows :
Vendor / Model Net-SNMP / linux
OS / Version Linux / 3.2.0-4-amd64 / Net-SNMP 5.4.3
Description Linux <hostname> 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u1
x86_64
SNMP Class SNMP::Info::Layer3::NetSNMP
So that leaves the VLAN information which doesn't seem to be supported by
<something> in the stack.
> I admit our Linux router support is a bit feeble :(.
I'll take it, warts and all :-)
In the grand scheme of things, it's a relatively minor annoyance - the
"neighbour map" in NetDisco2 is really cool for wandering around the network.
--- End Message ---
--- Begin Message ---
Hello Oliver,
thank you for your replay.
I run the expire task again and can confirm that nodes and devices
older 14 days are deleted from the "device" and "node" table.
But again no entries from the "node_ip" table were deleted.
Do you have an idea why?
Here is the debug output:
> netdisco-do expire -DQ
[4823] 2016-10-04 12:55:27 info expire: started at Tue Oct 4 14:55:27 2016
SELECT me.version, me.installed
FROM dbix_class_schema_versions me
WHERE 1 = 0
SELECT me.version
FROM dbix_class_schema_versions me
ORDER BY installed DESC
LIMIT '1'
BEGIN WORK
DELETE FROM device_ip
WHERE ip IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
)
DELETE FROM device_vlan
WHERE ip IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
)
DELETE FROM device_power
WHERE ip IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
)
DELETE FROM device_module
WHERE ip IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
)
DELETE FROM community
WHERE ip IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
) AND snmp_auth_tag IS NULL
UPDATE community
SET snmp_comm_rw = NULL
WHERE ip IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
)
DELETE FROM admin
WHERE device IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
)
DELETE FROM topology
WHERE dev1 IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
) OR dev2 IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
)
DELETE FROM device_port_power
WHERE ip IN (
SELECT me.ip
FROM device_port me
WHERE ip IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
)
)
DELETE FROM device_port_vlan
WHERE ip IN (
SELECT me.ip
FROM device_port me
WHERE ip IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
)
)
DELETE FROM device_port_wireless
WHERE ip IN (
SELECT me.ip
FROM device_port me
WHERE ip IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
)
)
DELETE FROM device_port_ssid
WHERE ip IN (
SELECT me.ip
FROM device_port me
WHERE ip IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
)
)
DELETE FROM node_ip
WHERE mac IN (
SELECT me.mac
FROM node_ip me
LEFT JOIN node nodes
ON nodes.mac = me.mac
WHERE nodes.active AND me.mac IN (
SELECT me.mac
FROM node me
WHERE switch IN (
SELECT me.ip
FROM device_port me
WHERE ip IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
)
)
)
GROUP BY me.mac
HAVING count( nodes.mac ) = 0
)
DELETE FROM node_nbt
WHERE mac IN (
SELECT me.mac
FROM node_nbt me
LEFT JOIN node nodes
ON nodes.mac = me.mac
WHERE nodes.active AND me.mac IN (
SELECT me.mac
FROM node me
WHERE switch IN (
SELECT me.ip
FROM device_port me
WHERE ip IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
)
)
)
GROUP BY me.mac
HAVING count( nodes.mac ) = 0
)
DELETE FROM node_monitor
WHERE mac IN (
SELECT me.mac
FROM node me
WHERE switch IN (
SELECT me.ip
FROM device_port me
WHERE ip IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
)
)
)
DELETE FROM node_wireless
WHERE mac IN (
SELECT me.mac
FROM node me
WHERE switch IN (
SELECT me.ip
FROM device_port me
WHERE ip IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
)
)
)
DELETE FROM node
WHERE switch IN (
SELECT me.ip
FROM device_port me
WHERE ip IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
)
)
DELETE FROM device_port
WHERE ip IN (
SELECT me.ip
FROM device me
WHERE last_discover < ( now( ) - '1209600' ::interval )
)
DELETE FROM device
WHERE last_discover < ( now( ) - '1209600' ::interval )
COMMIT
BEGIN WORK
DELETE FROM node_ip
WHERE mac IN (
SELECT me.mac
FROM node_ip me
LEFT JOIN node nodes
ON nodes.mac = me.mac
WHERE nodes.active AND me.mac IN (
SELECT me.mac
FROM node me
WHERE time_last < ( now( ) - '1209600' ::interval )
)
GROUP BY me.mac
HAVING count( nodes.mac ) = 0
)
DELETE FROM node_nbt
WHERE mac IN (
SELECT me.mac
FROM node_nbt me
LEFT JOIN node nodes
ON nodes.mac = me.mac
WHERE nodes.active AND me.mac IN (
SELECT me.mac
FROM node me
WHERE time_last < ( now( ) - '1209600' ::interval )
)
GROUP BY me.mac
HAVING count( nodes.mac ) = 0
)
DELETE FROM node_monitor
WHERE mac IN (
SELECT me.mac
FROM node me
WHERE time_last < ( now( ) - '1209600' ::interval )
)
DELETE FROM node_wireless
WHERE mac IN (
SELECT me.mac
FROM node me
WHERE time_last < ( now( ) - '1209600' ::interval )
)
DELETE FROM node
WHERE time_last < ( now( ) - '1209600' ::interval )
COMMIT
BEGIN WORK
DELETE FROM node_ip
WHERE mac IN (
SELECT me.mac
FROM node_ip me
LEFT JOIN node nodes
ON nodes.mac = me.mac
WHERE nodes.active AND me.mac IN (
SELECT me.mac
FROM node me
WHERE ( NOT active ) AND time_last < ( now( ) - '1209600' ::interval )
)
GROUP BY me.mac
HAVING count( nodes.mac ) = 0
)
DELETE FROM node_nbt
WHERE mac IN (
SELECT me.mac
FROM node_nbt me
LEFT JOIN node nodes
ON nodes.mac = me.mac
WHERE nodes.active AND me.mac IN (
SELECT me.mac
FROM node me
WHERE ( NOT active ) AND time_last < ( now( ) - '1209600' ::interval )
)
GROUP BY me.mac
HAVING count( nodes.mac ) = 0
)
DELETE FROM node_monitor
WHERE mac IN (
SELECT me.mac
FROM node me
WHERE ( NOT active ) AND time_last < ( now( ) - '1209600' ::interval )
)
DELETE FROM node_wireless
WHERE mac IN (
SELECT me.mac
FROM node me
WHERE ( NOT active ) AND time_last < ( now( ) - '1209600' ::interval )
)
DELETE FROM node
WHERE ( NOT active ) AND time_last < ( now( ) - '1209600' ::interval )
COMMIT
BEGIN WORK
DELETE FROM admin
WHERE entered < ( now( ) - '1209600' ::interval )
COMMIT
[4823] 2016-10-04 12:55:41 info expire: finished at Tue Oct 4 14:55:41 2016
[4823] 2016-10-04 12:55:41 info expire: status done: Checked expiry
for all Devices and Nodes
Regards Tobias
PS: Netdisco run as user netdisco, not as root for sure :)
2016-09-19 11:07 GMT+02:00 Tobias Gerlach <tobi...@gmail.com>:
> Hello,
>
> I'm running the latest Netdisco version and I'm wondering why no
> entries are removed from the node_ip table. I expected to find there
> no MAC adresses older than 14 days here after running the expire job.
> Any ideas or suggestions? Thanks a lot in advance.
>
> # cat environments/deployment.yml
> ..
> expire_devices: 14
> expire_nodes: 14
> expire_nodes_archive: 14
> ..
>
> # netdisco-do expire
> [25938] 2016-09-19 08:56:56 info expire: started at Mon Sep 19 10:56:56 2016
> [25938] 2016-09-19 08:56:57 info expire: finished at Mon Sep 19 10:56:57 2016
> [25938] 2016-09-19 08:56:57 info expire: status done: Checked expiry
> for all Devices and Nodes
>
> node_ip table:
> Actions mac ip active time_first time_last dns
> Edit Delete 64:27:37:59:10:11 10.239.48.133 FALSE
> 2014-10-21 20:07:13.548594 2014-10-21 20:07:13.385271 NULL
> Edit Delete cc:07:ab:f2:07:e9 10.253.68.234 FALSE
> 2014-11-13 12:00:57.858954 2014-11-13 16:16:23.115927 NULL
> Edit Delete 90:1b:0e:03:3a:3f 10.84.21.75 TRUE
> 2014-11-10 08:16:04.133489 2014-11-10 08:16:03.584933 NULL
> Edit Delete 9c:fc:01:a1:d9:93 10.247.237.231 FALSE
> 2015-07-13 21:52:10.267051 2015-07-14 00:27:23.878609 NULL
> ...
--- End Message ---
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Netdisco mailing list - Digest Mode
netdisco-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netdisco-users
