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: Netdisco 2. (Oliver Gorwits)
2. Re: Error when discovering by DNS name (Simon Hobson)
3. Re: Netdisco 2. (Fredrik Andreasson)
4. Re: Netdisco 2. (Jeroen van Ingen)
5. Re: Error when discovering by DNS name (Francesco Schiavarelli)
6. Wrong Cisco device uptime (Francesco Schiavarelli)
7. Re: Wrong Cisco device uptime (Oliver Gorwits)
--- Begin Message ---
Hi Fredrik,
On 2014-06-12 13:31, Fredrik Andreasson wrote:
I don't get information from a HP Procurve Stack switch with a Master
and five slaves in a stack. I can probe the Master without no
problem,
and I use snmpwalk to receive info from slaves now using the
community
flag in snmpwalk public@stackslave1.
I don't personally have experience with HP stacks. I hope someone else
on this list does, and can say what their experience is.
So it seems from what you say that HP does not offer a single MAC
address table for the whole stack of devices on the master switch. Each
switch is still in a separate MAC address table and SNMP community
indexing is used to retrieve each one. Is that correct?
We already do something similar for VLANs (per-VLAN MAC address table).
To do this for a stack would require some patches to SNMP::Info and to
Netdisco. I hope there's also a single MAC address table we can use
instead :)
I hope someone else can offer more help/experience than this... :)
regards,
oliver.
--- End Message ---
--- Begin Message ---
Oliver Gorwits <[email protected]> wrote:
> I don't think there's any "problem" to fix here other than you
> accidentally not having RFC-compliant host names.
>
> Rather than put effort into patching all the world's software to deal
> with this, wouldn't it be better to rename your hosts to use "-" instead
> of "_", to follow the agreed standard?
In some environments, trying to get things fixed to be standards compliant is
like banging your head against a wall - it feels better when you stop ! My
other bugbear is trying to get people to stop using ".local" as in internal
domain name "because Microsoft suggest we use it".
--- End Message ---
--- Begin Message ---
Hi Oliver, and thank you for your time.
Short story,
The slaves are join up to the master by MAC address. To get info from a stack
member we need to probe the Stack Masters IP-address with a command like this
#snmpwalk Stackmaster-IP -c public@Stackmember01 <OID> .
As far I can see I can't find anything about setting this up in netdisco2. I
also found a MIB that is included in netdisco-mibs/hp folder that could be
useful hpstack.mib ?
Thanks in advance.
Regards
-Fredrik
-----Original Message-----
From: Oliver Gorwits [mailto:[email protected]]
Sent: Friday, June 13, 2014 12:26 PM
To: [email protected]
Subject: Re: [Netdisco] Netdisco 2.
Hi Fredrik,
On 2014-06-12 13:31, Fredrik Andreasson wrote:
> I don't get information from a HP Procurve Stack switch with a Master
> and five slaves in a stack. I can probe the Master without no problem,
> and I use snmpwalk to receive info from slaves now using the community
> flag in snmpwalk public@stackslave1.
I don't personally have experience with HP stacks. I hope someone else on this
list does, and can say what their experience is.
So it seems from what you say that HP does not offer a single MAC address table
for the whole stack of devices on the master switch. Each switch is still in a
separate MAC address table and SNMP community indexing is used to retrieve each
one. Is that correct?
We already do something similar for VLANs (per-VLAN MAC address table).
To do this for a stack would require some patches to SNMP::Info and to
Netdisco. I hope there's also a single MAC address table we can use instead :)
I hope someone else can offer more help/experience than this... :)
regards,
oliver.
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find
What Matters Most in Your Big Data with HPCC Systems Open Source. Fast.
Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems _______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
--- End Message ---
--- Begin Message ---
Hi Fredrik,
There are indeed two MIBs in the netdisco-mibs package that are relevant
for HP stacks: hpswitchstack.mib and hpstack.mib. It looks like the
first one is for pretty old gear and the second one is for newer
ProCurve switches; I'd expect the second one to be relevant for eg HP
2920 and 3800 switches.
If it's really necessary that a form of community-based stack member
selection is needed to poll the forwarding tables, then we'd need to add
some code to at least the relevant device class in SNMP::Info
(Layer2::HP) and probably also a bit to Netdisco to actually use it. And
yes, in that case we'd probably use HP-STACK-MIB to determine whether a
switch is stacked or not.
Regards,
Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
On 06/13/2014 01:11 PM, Fredrik Andreasson wrote:
Hi Oliver, and thank you for your time.
Short story, The slaves are join up to the master by MAC address. To
get info from
a stack member we need to probe the Stack Masters IP-address with a
command like this #snmpwalk Stackmaster-IP -c public@Stackmember01 <OID> .
As far I can see I can't find anything about setting this up in
netdisco2. I also found a MIB that is included in netdisco-mibs/hp
folder that could be useful hpstack.mib ?
Thanks in advance.
Regards
-Fredrik
-----Original Message-----
From: Oliver Gorwits [mailto:[email protected]]
Sent: Friday, June 13, 2014 12:26 PM
To: [email protected]
Subject: Re: [Netdisco] Netdisco 2.
Hi Fredrik,
On 2014-06-12 13:31, Fredrik Andreasson wrote:
I don't get information from a HP Procurve Stack switch with a Master
and five slaves in a stack. I can probe the Master without no problem,
and I use snmpwalk to receive info from slaves now using the community
flag in snmpwalk public@stackslave1.
I don't personally have experience with HP stacks. I hope someone else on this
list does, and can say what their experience is.
So it seems from what you say that HP does not offer a single MAC address table
for the whole stack of devices on the master switch. Each switch is still in a
separate MAC address table and SNMP community indexing is used to retrieve each
one. Is that correct?
We already do something similar for VLANs (per-VLAN MAC address table).
To do this for a stack would require some patches to SNMP::Info and to
Netdisco. I hope there's also a single MAC address table we can use instead :)
I hope someone else can offer more help/experience than this... :)
regards,
oliver.
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find
What Matters Most in Your Big Data with HPCC Systems Open Source. Fast.
Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems _______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
--- End Message ---
--- Begin Message ---
Hi Oliver,
in the general case you are right and I agree with you,
if there is a standard why not follow it?
But as someone already noted sometimes the right solution
is not practical and in this very specific case given that:
- underscores in DNS records is a controversial topic,
they are allowed everywhere except hostnames
(e.g. see RFC 2872)
- fix was one liner and the author was happy to apply it
- no other GNU software (that I know of) is enforcing this
constraint
I see no reason (apart from letting newbies like me learn
something new) to not apply such patch.
Anyway the issue is fixed in NetAddr::IP::Lite 4.075
thank you all
regards
On Wed, Jun 11, 2014 at 6:21 PM, Francesco Schiavarelli
<[email protected]> wrote:
> Hello,
>
> I was not aware of that constraint on hostnames,
> thank you for pointing out the relevant RFCs.
>
> Anyway I've found that the source problem lies within
> NetAddr::IP:Lite and I've already asked the package
> maintainers if they are willing to apply an easy fix
> given that every other GNU software I've dealt with
> has no problem with hostnames containing underscore
> character. So hopefully it will be fixed upstream.
>
> In the meantime I locally patched NetAddr::IP::Lite
> module but I'm having hard times figuring out how
> to force a module rebuilding, do you have any tips?
>
> Attached you will find the patch I'm using.
>
> thank you
> regards
>
> P.S.
> I tried to subscribe to nedisco-user ml two days ago
> but I'm still waiting for list admin approval, what is
> missing?
>
>
>
>
>
> On Mon, Jun 9, 2014 at 3:24 PM, Beals, Damon G <[email protected]> wrote:
>>
>> This is a bug that could be fixed, but a underscore is not valid for a DNS
>> record.
>>
>> The Internet standards (Request for Comments) for protocols mandate that
>> component hostname labels may contain only the ASCII letters 'a' through 'z'
>> (in a case-insensitive manner), the digits '0' through '9', and the hyphen
>> ('-'). The original specification of hostnames in RFC 952, mandated that
>> labels could not start with a digit or with a hyphen, and must not end with
>> a hyphen. However, a subsequent specification (RFC 1123) permitted hostname
>> labels to start with digits. No other symbols, punctuation characters, or
>> white space are permitted.
>>
>> Damon
>> ________________________________
>> From: Francesco Schiavarelli [[email protected]]
>> Sent: Monday, June 09, 2014 8:19
>> To: [email protected]
>> Subject: [Netdisco] Error when discovering by DNS name
>>
>> Hello,
>>
>> performing manual discovery by using DNS names
>> sometimes does not work depending on the hostname.
>>
>> If the hostname contains an underscore ("_" character)
>> then I get the following error:
>>
>> ~$ bin/netdisco-do discover -d test_router.example.com
>> [19106] info @0.000011> discover: started at Mon Jun 9 14:01:58 2014
>> [19106] info @0.000418> discover: finished at Mon Jun 9 14:01:58 2014
>> [19106] info @0.000580> discover: status error: error running job: Can't
>> call method "addr" on an undefined value at
>> /home/netdisco/perl5/lib/perl5/App/Netdisco/Daemon/Worker/Poller/Device.pm
>> line 50.
>>
>> If the hostname does not contain an underscore character
>> then the discovery is successfull:
>>
>> ~$ bin/netdisco-do discover -d test.example.com
>> [19140] info @0.000013> discover: started at Mon Jun 9 14:16:30 2014
>> [19140] info @6.384684> discover: finished at Mon Jun 9 14:16:36 2014
>> [19140] info @6.384977> discover: status done: Ended discover for
>> 123.123.123.123
>>
>> Discovering the same host using its IP address is ok.
>>
>> Do you have any idea?
>>
>> thank you
>> regards
>
>
--- End Message ---
--- Begin Message ---
Hi,
reported uptime is wrong on some cisco device.
As suggested here:
http://sourceforge.net/p/netdisco/mailman/message/31395702/
using snmpEngineTime from SNMP-FRAMEWORK-MIB instead of sysUptime from
SNMPv2-MIB can help to fix the problem.
On Netdisco detail page of a specific device (edge-rtr) I can read:
Uptime: 1 year 7 months 7 days 13:40:41
Cisco CLI command output:
edge-rtr#show version | i Uptime
Uptime for this control processor is 4 years, 16 weeks, 6 days, 22
hours, 25 minutes
reading SNMPv2-MIB::sysUpTime OID:
~$ snmpget -v 2c -c public edge-rtr 1.3.6.1.2.1.1.3.0
iso.3.6.1.2.1.1.3.0 = Timeticks: (757089462) 87 days, 15:01:34.62
reading SNMP-FRAMEWORK-MIB::snmpEngineTime OID:
$ snmpget -v 2c -c public edge-rtr 1.3.6.1.6.3.10.2.1.3.0
iso.3.6.1.6.3.10.2.1.3.0 = INTEGER: 128537973
Converting the outputs to a common format and summing them up we have:
1) Netdisco: 582 days, 13:40
2) show ver: 1578 days, 22:25
3) sysUpTime: 87 days, 15:01
4) snmpEngineTime: 1487 days, 16:59
My expected result is that Netdisco shows the same output as
"show version" CLI command.
Looking at Netdisco source seems there's no code to take into account
more than 1 uptime wrap and in my case it has wrapped 3 times.
In fact sysUpTime wraps about after 497 days and with simple math:
87 (sysUpTime) + 3 * 497 = 1578 (show ver)
Do you think it would be possible to use snmpEngineTime to detect the
number of wraps and use this as offset to sysUpTime?
In pseudo code it would be something like:
sysUpTime + (((snmpEngineTime * 100) >> 32) + 1) << 32
Comments are welcome!
thank you
regards
--- End Message ---
--- Begin Message ---
Hi Francesco,
Do you think it would be possible to use snmpEngineTime to detect the
number of wraps and use this as offset to sysUpTime?
This seems a good suggestion to me, but I'll wait for other devs to
consider it as well.
Are you able to produce a patch, or do you want us to work on that?
regards,
oliver.
On 2014-06-17 14:40, Francesco Schiavarelli wrote:
Hi,
reported uptime is wrong on some cisco device.
As suggested here:
http://sourceforge.net/p/netdisco/mailman/message/31395702/
using snmpEngineTime from SNMP-FRAMEWORK-MIB instead of sysUptime
from
SNMPv2-MIB can help to fix the problem.
On Netdisco detail page of a specific device (edge-rtr) I can read:
Uptime: 1 year 7 months 7 days 13:40:41
Cisco CLI command output:
edge-rtr#show version | i Uptime
Uptime for this control processor is 4 years, 16 weeks, 6 days, 22
hours, 25 minutes
reading SNMPv2-MIB::sysUpTime OID:
~$ snmpget -v 2c -c public edge-rtr 1.3.6.1.2.1.1.3.0
iso.3.6.1.2.1.1.3.0 = Timeticks: (757089462) 87 days, 15:01:34.62
reading SNMP-FRAMEWORK-MIB::snmpEngineTime OID:
$ snmpget -v 2c -c public edge-rtr 1.3.6.1.6.3.10.2.1.3.0
iso.3.6.1.6.3.10.2.1.3.0 = INTEGER: 128537973
Converting the outputs to a common format and summing them up we
have:
1) Netdisco: 582 days, 13:40
2) show ver: 1578 days, 22:25
3) sysUpTime: 87 days, 15:01
4) snmpEngineTime: 1487 days, 16:59
My expected result is that Netdisco shows the same output as
"show version" CLI command.
Looking at Netdisco source seems there's no code to take into account
more than 1 uptime wrap and in my case it has wrapped 3 times.
In fact sysUpTime wraps about after 497 days and with simple math:
87 (sysUpTime) + 3 * 497 = 1578 (show ver)
Do you think it would be possible to use snmpEngineTime to detect the
number of wraps and use this as offset to sysUpTime?
In pseudo code it would be something like:
sysUpTime + (((snmpEngineTime * 100) >> 32) + 1) << 32
Comments are welcome!
thank you
regards
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk
Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
--- End Message ---
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Netdisco mailing list - Digest Mode
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users
