Send netdisco-users mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. Re: Pending Device Discovery (Les Begnaud)
--- Begin Message ---
Interesting ideas. I don’t really like the idea of requiring a renumber later,
as it kind of puts us in the same boat (also we don’t always have an alias IP
to even discover).
I really do think that retrying after 7 days works for us, my only concern with
this method is that the snmp connect failure list is going to be very long if I
don’t get exclusions working properly (VOIP phones, access points, switches we
don’t manage, etc will all be getting added to that list. I have a test
environment with about 20 sites added and the list is already 5 pages long)
Let me know if there’s anything in particular you would like me to test and I’d
be glad to. I’m unfamiliar with device_identity, but reading up on it this may
make your 2nd option viable!
Les Begnaud
Systems Engineer (Sys Lord)
RADER
337.205.4652
[email protected]
From: Oliver Gorwits <[email protected]>
Sent: Wednesday, February 13, 2019 7:46 AM
To: [email protected]
Subject: Re: [Netdisco] Pending Device Discovery
Hi Les,
I have a few ideas, after pondering this for a while (it's a good scenario to
support, I think)...
* as Nic helpfully pointed out, modern netdicso will retry failing discover
jobs and eventually park IPs in a "skip" list. However the list is revisited
now and again to retry, I think once every seven days. So if you queue a
discover, it may get parked, but then a week later things should be fine.
Depends if you can wait that long.
* if you're staging a device, do you assign a secondary IP / alias, locally
in your office, alongside the destination site identity? You could have a
(second?) netdisco poller running at your office which discovers the device
under this alias as part of your setup procedure. Then when it's in the field,
or even at the end of your provisioning at HQ, you issue a netdisco "renumber"
job and the next discover will use the other identity.
* The downside to this is that there is a design feature which actually
prevents it working, and also a bug I just spotted. Both can be fixed :-D
* also it requires a manual step and risks being forgotten (the device
will still be in netdisco, but not being updated, and eventually expire out)
I had a few other thoughts (using device_identity) but they wouldn't work
without further changes to netdisco, so let's see how the above feels first. I
will try to get the bug fixed in the next few days.
Let us know,
Oliver.
On Fri, 1 Feb 2019 at 17:52, Les Begnaud
<[email protected]<mailto:[email protected]>> wrote:
We have a process in which we stage devices at our office before sending out
into the field. There are currently two situations where we can get into a
state that leaves a device not added to netdisco:
• Replacing a failed device
o The mgmt. IP of the device is not routable, as the IP is being routed to
the site, not to our office staging area
• Creating a brand new site
o If a user forgets to do the discovery, we have to wait until the device is
on site and online before running a discover
o This is prone to being forgotten and then we are left with the device not
being discovered until it is “found” later
I think a clean solution to both problems would be a way to stage a device to
discover. A simple solution would be to manually add it to the devices table in
the DB with some flag that says it’s undiscovered, a better solution might be
to update the schema to include a pending devices table that gets discovered on
a different interval than the regular devices.
It's also possible that this functionality already exists, and I just am not
looking in the right place.
As a side note, neighbor discovery helps us out often here, but the router
product that we use doesn’t support LLDP MIBS… so there’s a big break in the
dynamic discovery that can happen. The router can be discovered via OSPF, but
the switches behind it won’t be discovered (though a replaced device with a new
IP can be)
Les Begnaud
Systems Engineer (Sys Lord)
[cid:[email protected]]
337.205.4652<tel:337.205.4652>
[email protected]<mailto:[email protected]>
_______________________________________________
Netdisco mailing list
[email protected]<mailto:[email protected]>
https://sourceforge.net/p/netdisco/mailman/netdisco-users/
--- End Message ---
_______________________________________________
Netdisco mailing list - Digest Mode
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
