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 (Oliver Gorwits)
2. Re: Pending Device Discovery (Oliver Gorwits)
--- Begin Message ---
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]>
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)
>
> *337.205.4652* <337.205.4652>
> *[email protected]* <[email protected]>
> _______________________________________________
> Netdisco mailing list
> [email protected]
> https://sourceforge.net/p/netdisco/mailman/netdisco-users/
--- End Message ---
--- Begin Message ---
Don't worry too much about the length of that list, which is internal
workings really. However you want to focus on SNMP connection which are the
real slow bit.
You can either use discover_no to avoid devices, or use acl's in
device_auth, so when netdisco does try to discover, it has no credentials
and skips very quickly. The former (discover_no) is more efficient as it
can be used in netdisco's SQL.
On Wed, 13 Feb 2019 at 13:46, Les Begnaud <[email protected]>
wrote:
> 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* <337.205.4652>
>
> *[email protected]* <[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]>
> 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)
>
>
> *337.205.4652* <337.205.4652>
>
> *[email protected]* <[email protected]>
>
> _______________________________________________
> Netdisco mailing list
> [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
