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. logic for extracting serial numbers for Cisco stacks
(Mark Boolootian)
2. Re: sql query help sought (Mark Boolootian)
3. Re: sql query help sought (Oliver Gorwits)
--- Begin Message ---
Hi all,
I'm trying to figure out how Netdisco is
able to extract serial numbers for members
in Cisco stacks. I examined:
netdisco-do show -d 192.168.1.1 -e entPhysicalSerialNum
which yields much data, with the switch
serial numbers located at indices 1000, 2000,
etc.
What I'm wondering is how Netdisco decides
on number of members in a stack, and whether
it relies on the value of those indices for selecting
serial numbers (or perhaps there is another way).
Any hints most welcome.
many thanks,
mark
--- End Message ---
--- Begin Message ---
Hi Oliver,
> In addition to Christian's excellent reply, I would also advise
> to take a look at the expire/freshness configuration options
> which relate to nodes and IPs:
>
> https://github.com/netdisco/netdisco/wiki/Configuration#node_freshness
>
> This is because if you want to report on nodes only seen within
> two hours and are seeing spurious results, you may need to adjust
> the expiry which might be much longer.
Thanks for calling that out. I'm a little puzzled about the
"seeing spurious results" part of that. Shouldn't the query
that Christian crafted only yield entries for which the time
last seen was within two hours of when the query is issued?
Any older entries won't be included.
The expiry *is* much longer - 90 days in our case. But I
assume that isn't relevant. Except for the fact that you made
this comment :-)
best,
mark
--- End Message ---
--- Begin Message ---
err yeah you're right, time_last in the DB probably will be enough with the
two hour constraint.
Have a look at the options anyway... they can help with a ballooning DB
size if you're tracking wireless of v6 closely.
Oliver.
On Tue, 23 Apr 2019 at 19:14, Mark Boolootian <[email protected]> wrote:
> Hi Oliver,
>
> > In addition to Christian's excellent reply, I would also advise
> > to take a look at the expire/freshness configuration options
> > which relate to nodes and IPs:
> >
> > https://github.com/netdisco/netdisco/wiki/Configuration#node_freshness
> >
> > This is because if you want to report on nodes only seen within
> > two hours and are seeing spurious results, you may need to adjust
> > the expiry which might be much longer.
>
>
> Thanks for calling that out. I'm a little puzzled about the
> "seeing spurious results" part of that. Shouldn't the query
> that Christian crafted only yield entries for which the time
> last seen was within two hours of when the query is issued?
> Any older entries won't be included.
>
> The expiry *is* much longer - 90 days in our case. But I
> assume that isn't relevant. Except for the fact that you made
> this comment :-)
>
> best,
> mark
>
--- End Message ---
_______________________________________________
Netdisco mailing list - Digest Mode
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
