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: ND2 strange node behaviour (Nikolaos Milas)
2. Re: ND2 strange node behaviour (Mark Cooper)
3. Re: ND2 strange node behaviour (Oliver Gorwits)
4. Re: ND2 strange node behaviour (Nikolaos Milas)
5. Re: ND2 strange node behaviour (Robert Kerr)
--- Begin Message ---
On 29/5/2014 12:58 μμ, Robert Kerr wrote:
Maybe this behaviour could be made configurable?
I can see advantages to both methods depending how frequently devices
move in an environment and whether there are (m)any undiscovered
devices. How often you run the macsuck would be an issue too. The less
often you run a macsuck the more the older behaviour makes sense.
If this approach is followed, it could be configurable at the node
level: for example, a checkbox called "Sticky" could be added as a
separate field in ND2, next to each node.
If a user checks this checkbox, it would mean: "If this node has been
detected ('last seen') during the latest scan, then it should be
displayed as an active node in the "Connected Devices" column (Ports tab
for the device), regardless whether its MAC address was detected during
macsuck."
It seems this issue is caused by the particular type of node. A
workaround would be to configure the node MAC Address on the specific
port of the switch as static.
What would you people think is a better approach? Manipulating ND2 so as
to force it to display a particular node (e.g. using a "Sticky" option
or sth similar), or manipulating the switch itself (to configure static
MAC Addresses on particular ports)?
In any case, probably adding this option in ND2 shouldn't hurt and it
would provide flexibility.
Nick
--- End Message ---
--- Begin Message ---
I would never set static MACs on switches in any environment (exception being a
highly secure one, alphabet soup guys style).
Historically Cisco switches will not always report a MAC on a port even while
it has a node that is being spoken to. It is always hit or miss on getting it
to show a MAC that is learned dynamically per port. You can find it at layer 3
with the arp cache and even ping the device. Then go to the port where you
know the device is located and try to get it to show you what MACs it has
learned on that port, it's a crap shoot, no telling if it will tell you one is
there or not.
I used to help write a tool we used for billing customers based on number of
switch ports used throughout their environment (over 1k locations). We went
with octets counting up from last look to current look to know, trying to use
MACs as a way to know was/is completely hit or miss.
Thanks,Mark Cooper
*Cooper's Communications*
[email protected]
> On 29/5/2014 12:58 μμ, Robert Kerr wrote:
>
> > Maybe this behaviour could be made configurable?
> >
> > I can see advantages to both methods depending how frequently devices
> > move in an environment and whether there are (m)any undiscovered
> > devices. How often you run the macsuck would be an issue too. The less
> > often you run a macsuck the more the older behaviour makes sense.
>
> If this approach is followed, it could be configurable at the node
> level: for example, a checkbox called "Sticky" could be added as a
> separate field in ND2, next to each node.
>
> If a user checks this checkbox, it would mean: "If this node has been
> detected ('last seen') during the latest scan, then it should be
> displayed as an active node in the "Connected Devices" column (Ports tab
> for the device), regardless whether its MAC address was detected during
> macsuck."
>
> It seems this issue is caused by the particular type of node. A
> workaround would be to configure the node MAC Address on the specific
> port of the switch as static.
>
> What would you people think is a better approach? Manipulating ND2 so as
> to force it to display a particular node (e.g. using a "Sticky" option
> or sth similar), or manipulating the switch itself (to configure static
> MAC Addresses on particular ports)?
>
> In any case, probably adding this option in ND2 shouldn't hurt and it
> would provide flexibility.
>
> Nick
>
> ------------------------------------------------------------------------------
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> _______________________________________________
> Netdisco mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/netdisco-users
>
--- End Message ---
--- Begin Message ---
On 2014-05-29 22:59, Nikolaos Milas wrote:
If a user checks this checkbox, it would mean: "If this node has been
detected ('last seen') during the latest scan, then it should be
displayed as an active node in the "Connected Devices" column (Ports
tab
for the device), regardless whether its MAC address was detected
during
macsuck."
It's an interesting suggestion. Here are my thoughts:
1) in a way, we already have such a "sticky" flag, except it's called
"Show Archived". What you're asking for is for only the most recent
archived node entry to be shown, when there's no active node.
2) I'm reluctant to make Netdisco 2 show information which does not
reflect what it actually discovered from the device. It's likely that by
doing so we fix your situation but someone else will report things are
now broken for them.
3) Personally I've never seen nodes popping in and out of the MAC
address table (nor mention on, say, c-nsp), but it's interesting to hear
Mark's report. If it _is_ widespread then yes, it'd be good to cope with
the problem in Netdisco somehow.
We might be able to do something like "Show Most Recent Archived" as an
option in the sidebar. There is a cookie storing sidebar prefs so once
set, it should be remembered for your future searches.
I'm not going to rush into anything - I think other users and
developers should have input on this. However thanks for the feedback, I
do think we can improve on the display, but just not sure which way at
the moment.
p.s. patches welcome, of course, if anyone wants to give it a go! :)
regards,
oliver.
--- End Message ---
--- Begin Message ---
On 30/5/2014 9:59 πμ, Oliver Gorwits wrote:
3) Personally I've never seen nodes popping in and out of the MAC
address table (nor mention on, say, c-nsp), but it's interesting to hear
Mark's report. If it_is_ widespread then yes, it'd be good to cope with
the problem in Netdisco somehow.
I can confirm that this phenomenon happens to practically all our
switches: about 30 Cisco 2960/2950 of various types and a couple Cisco
SRW2024-K9 (SG300-28).
Mark's report surely provides important feedback on the subject, and
confirms our findings.
I don't know if this problem could be mitigated by providing an
alternative macsuck mode (let's call it "extended macsuck" or
"multi-macsuck") which would not simply do a single macsuck but instead
it would do multiple mucsucks at (configurable) intervals for a
(configurable) period and consider alive all nodes that have been
detected (in the mac address table) at least once during this period.
The "extended macsuck" period could probably be configured (at least
initially) to be equal to the mac-address-table aging period (default
300 sec in Cisco switches) and the interval could be initially set to,
say 10 sec; this would mean 30 macsucks for one "extended macsuck".
If such a patch is not difficult to implement, we could try and test how
this works.
We might be able to do something like "Show Most Recent Archived" as an
option in the sidebar. There is a cookie storing sidebar prefs so once
set, it should be remembered for your future searches.
I'm not going to rush into anything - I think other users and
developers should have input on this. However thanks for the feedback, I
do think we can improve on the display, but just not sure which way at
the moment.
p.s. patches welcome, of course, if anyone wants to give it a go!
Unfortunately I cannot provide any patch, as I am not a software
developer. However, I am available to test any suggested patch in our
environment.
Best regards,
Nick
--- End Message ---
--- Begin Message ---
On 30/05/14 07:59, Oliver Gorwits wrote:
> 3) Personally I've never seen nodes popping in and out of the MAC
> address table (nor mention on, say, c-nsp), but it's interesting to hear
> Mark's report. If it _is_ widespread then yes, it'd be good to cope with
> the problem in Netdisco somehow.
One example I can think of is devices that do wake-on-LAN - they'll keep
the link up to listen for the magic packet, but not be transmitting
anything and so drop out of the MAC table. Granted these devices are
'off' at the time this happens - but if they're still physically
connected to the port, and the port link is up it is more logical to me
for them to be shown on the port than not.
I do think this is very dependant on macsuck frequency - if you're
running a macsuck every minute then whether that MAC is present right
now may be more important than if you only run it once an hour or once
every 6 hours.
--
Robert Kerr
--- End Message ---
------------------------------------------------------------------------------
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet
_______________________________________________
Netdisco mailing list - Digest Mode
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
