Send netdisco-users mailing list submissions to
netdisco-users@lists.sourceforge.net
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
netdisco-users-requ...@lists.sourceforge.net
You can reach the person managing the list at
netdisco-users-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netdisco-users digest..."
Today's Topics:
1. Re: fixing brocade model? (Jeroen van Ingen)
2. Re: fixing brocade model? (Joseph Bernard)
3. Adding Aerohive support (was: Re: netdisco-users Digest, Vol
110, Issue 3) (Jeroen van Ingen)
4. Re: The connected device information is incorrect on
Netdisco. (Oliver Gorwits)
5. Re: Missing Hostname for connected Nodes (Oliver Gorwits)
6. Re: Macsuck not possible on Cisco 2918 Switch (Oliver Gorwits)
7. Re: Error disabled ports report & discover behavior after IP
change. (Oliver Gorwits)
8. Re: inconsistent port search results (Oliver Gorwits)
--- Begin Message ---
Hi Joseph,
The mapping of SNMP identification (what you're seeing now) to "normal"
model names happens through the SNMP MIBs.
If you have the current MIBs for these switches, can you put them in a
new ticket in the netdisco-mibs tracker on Sourceforge
(https://sourceforge.net/p/netdisco/nd-mibs/) ?
I'll try to process the MIBs asap, or at least add the new model mappings.
Regards,
Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
On 11/12/2015 05:56 PM, Joseph Bernard wrote:
We have some Brocade ICX 7250 and ICX 7450 switches that work with
Netdisco, but their models appear for example as registration.61.2.2.1.3
instead of something like ICX7450-48P. Is that something I can fix or
something I need to put in a ticket somewhere? These are new switches
to the Brocade product line.
Thanks,
Joseph B.
------------------------------------------------------------------------------
_______________________________________________
Netdisco mailing list
netdisco-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netdisco-users
--- End Message ---
--- Begin Message ---
I see someone has already opened a ticket, so I’ll wait for that one to clear.
Thanks!
Joseph B.
On 11/13/15, 3:43 AM, "Jeroen van Ingen" <j.vaningensche...@utwente.nl> wrote:
>Hi Joseph,
>
>The mapping of SNMP identification (what you're seeing now) to "normal"
>model names happens through the SNMP MIBs.
>
>If you have the current MIBs for these switches, can you put them in a
>new ticket in the netdisco-mibs tracker on Sourceforge
>(https://sourceforge.net/p/netdisco/nd-mibs/) ?
>
>I'll try to process the MIBs asap, or at least add the new model mappings.
>
>
>Regards,
>
>Jeroen van Ingen
>ICT Service Centre
>University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
>
>
>On 11/12/2015 05:56 PM, Joseph Bernard wrote:
>> We have some Brocade ICX 7250 and ICX 7450 switches that work with
>> Netdisco, but their models appear for example as registration.61.2.2.1.3
>> instead of something like ICX7450-48P. Is that something I can fix or
>> something I need to put in a ticket somewhere? These are new switches
>> to the Brocade product line.
>>
>> Thanks,
>> Joseph B.
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Netdisco mailing list
>> netdisco-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/netdisco-users
>>
>
>
>------------------------------------------------------------------------------
>_______________________________________________
>Netdisco mailing list
>netdisco-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/netdisco-users
--- End Message ---
--- Begin Message ---
Hi Scott,
Generally speaking, two things are needed:
1. A new device class in SNMP::Info for vendor / equipment.
2. Adding the relevant SNMP MIBs for the gear to netdisco-mibs.
The MIBs for Aerohive are already included in netdisco-mibs, so only a
SNMP::Info device class is needed.
One thing in advance: Aerohive APs have a flaw in their SNMP support,
they won't report their model in the "normal" way. To report correct
model numbers, the new SNMP::Info class would have to include a
workaround for this issue until it's fixed in a newer HiveOS release.
See
https://community.aerohive.com/aerohive/topics/snmp-aps-not-using-a-distinct-sysobjectid-for-each-model
for a forum thread on this issue.
Regards,
Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
On 08/06/2015 04:28 AM, Golden, Scott wrote:
what is needed to add a vendor, we have aerohive wifi AP's and would
like to add to netdisco
*Scott Golden*
Systems Analyst
Boston Globe Media Partners, LLC
978-340-8207
scott.gol...@globe.com <mailto:scott.gol...@globe.com>
--- End Message ---
--- Begin Message ---
Hello,
Thank you for reporting this issue. To help us work out where the cause
may be, please could you provide the output of the following commands:
~netdisco/bin/netdisco-do show -d huawei_1 -e c_ip
~netdisco/bin/netdisco-do show -d huawei_1 -e c_if
~netdisco/bin/netdisco-do show -d huawei_1 -e c_port
Many thanks,
regards,
oliver.
On 2015-11-11 07:45, Zhangyuanyuan (D) wrote:
Hi, all
I met a problem with Netdisco, I had sent a email last week. But
there
was no response.
Could you help us analyze this issue. I will be deeply appreciated if
this issue can be solved.
The problem is that:
when the network is consisted of Huawei Cloudengine Switches, the
connected device information is incorrect on Netdisco, It’s
inconsistent with the Topology.
We have checked the packets that Huawei Switch sends to Netdisco, The
SNMP packets were correct, the LLDP information in SNMP packet was
consistent with the Topology. But, Netdisco showed wrong port
connection.
Here is the detail for this issue:
The LLDP information on Huawei Cloudengine is as follows:
<huawei_1>display lldp neighbor brief
Local Interface Exptime(s) Neighbor Interface Neighbor Device
-------------------------------------------------------------------------------------------
40GE2/0/2 103 40GE1/0/2 huawei_2
GE2/0/19 114 GE2/0/31 huawei_1
GE2/0/31 114 GE2/0/19 huawei_1
We can see that, GE2/0/19 is connected to GE2/0/31. GE2/0/31 is
another port on this device.
But, on Netdisco, we can see that GE2/0/19 is connected to itself.
1. The implementation of LLDP on Huawei device is according to the
protocol “802.1AB-2005”, The LLDP MIB description is as follows:
2. Huawei device use MIB node
“lldpRemoteSystemsData(1.0.8802.1.1.2.1.4)” for LLDP, In this node
“lldpRemPortId(1.0.8802.1.1.2.1.4.1.1.7)” is port’s neighbor
information；
3. According to protocol, “lldpRemPortId” is the remote port that
this device connects to.
“lldpRemPortId” is string type:
4. In the SNMP packet that Huawei Switch sents, the value of the
“lldpRemPortId” is correct.
Take port GE2/0/19 for example, The value of “lldpRemPortId” is as
bellow:
lldpRemPortId.169046155.80.1 = 47.45.32.2f.30.2f.33.31
//”169046155.80.1“ represents GE2/0/19 ” ,and
“47.45.32.2f.30.2f.33.31” represents G.E.2./.0./.31
lldpRemPortId.169046155.92.1 = 47.45.32.2f.30.2f.31.39 //”
169046155.92.1” represents GE2/0/19 “, and
“47.45.32.2f.30.2f.31.39” represents G.E.2./.0./.19.
lldpRemPortId.169046155.115.1 = 34.30.47.45.31.2f.30.2f.32
--- End Message ---
--- Begin Message ---
Hi,
On 2015-11-09 18:18, Steven Xu wrote:
Has anyone had trouble with missing hostnames for Netdisco V2 when
there were present in Netdisco V1? We're finding that some nodes seem
to have lost this information after upgrading.
The difference between v1 and v2 is that in ND1 the DNS was done
dynamically when you viewed the web page. In ND2 it is done at arpnip
time (when the MAC/IP node mapping is discovered).
Is there a difference between the resolver config on the two systems?
You can also run the ND2 arpnip in debug to see a message about DNS
resolving.
regards,
oliver.
--- End Message ---
--- Begin Message ---
Hi,
On 2015-11-06 15:14, Sebastian Rösch wrote:
I have a problem to macsuck addresses from a Cisco 2918 Switch (Cisco
IOS Software, C2918 Software (C2918-LANLITEK9-M), Version
12.2(44)SE6,
RELEASE SOFTWARE (fc1) ) They won´t be fetched.
When I do a simple snmpwalk the data isn´t also being fetched. What
should I do now? Do I need a special MIB?
If the data isn't appearing with snmpwalk then it could be an SNMP
"view" restriction (ACL)?
You might need to configure the device to permit access to the table
via SNMP. Sadly I can't lay my hands on the command right now but maybe
someone else can help?
regards,
oliver.
This is the link at cisco.com:
http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=1.3.6.1.4.1.9.1.965
Best Regards
Sebastian
--- End Message ---
--- Begin Message ---
On 2015-11-03 19:31, Sassan Dibadj wrote:
I see an administratively down ports report but not one for error
disabled ports. Is this status stored anywhere were we can create a
custom report for it?
I *think* this information is stored in a custom table that Netdisco
does not retrieve (portAdditionalOperStatus) because it's a specific
Cisco thing. You could still try:
~netdisco/bin/netdisco-do show -d 1.2.3.4 portAdditionalOperStatus
and look for 18 or errDisabled according to
https://supportforums.cisco.com/document/9366/how-check-if-port-set-errdisable-snmp
Also, I noticed that if a device's management IP changes and I want
to
rediscover it, the old device has to be deleted before it is possible
to add the new one because it seems like for discovers it will
attempt
to connect to the old IP even if you tell it to discover the new IP.
Both via CLI and Web. Just an observation, not sure if this is by
design or not.
It's sort of by design... the idea is that the device will be
rediscovered automatically via a neighbor relationship and renumbered
internally.
The advantage of the current behaviour is that all the commands and
searches work in Netdisco regardless of which name/interface/IP you
happen to know a device by.
If you wish to force it manually, yes you need to delete and re-add
*or* us the "renumber" facility in the netdisco-do command:
https://metacpan.org/pod/distribution/App-Netdisco/bin/netdisco-do
~netdisco/bin/netdisco-do renumber -d 192.0.2.1 -e 192.0.2.254
This is better because it carries across all the node/arp information.
regards,
oliver.
--- End Message ---
--- Begin Message ---
On 2015-11-03 16:11, Steven Xu wrote:
It's how it was designed, although I'm not sure whether to think of
it as a bug or not.
When you use a number, Netdisco treats it as a VLAN number and
searches for ports configured for that VLAN. When you include the *,
it treats it as some string, so it looks for ports with that
description, name and connected device.
Correct. There's a little arrow to the right of the search box which is
a drop-down menu for you to force Port/VLAN/Device searching.
regards,
oliver.
Steven
-----Mark Boolootian <boo...@ucsc.edu> wrote: -----
To: "netdisco-users@lists.sourceforge.net"
<netdisco-users@lists.sourceforge.net>
From: Mark Boolootian <boo...@ucsc.edu>
Date: 11/03/2015 05:05AM
Subject: [Netdisco] inconsistent port search results
Hi all,
I may be misunderstanding the semantics behind the port search,
but it appears to me that the results are inconsistent.
I have a port with an interface description "af24 test". If I perform
a port search for "test", I get back nothing. A port search for
"af24 test" returns the port of interest (see attached). Had I used
the "partial match" option, then the search for "test" pays off.
That all seems to make sense.
However, if I search for a port "7919-02" I get back a big pile of
entries (again, see attached). It seems to me that I shouldn't
have got these entries without selection "partial match".
Additionally, when I search for just "7919", I don't get back
anything,
but if I search for "*7919", I get back all the entries with 7919 in
the
interface description.
Bug?
many thanks,
mark
------------------------------------------------------------------------------
_______________________________________________
Netdisco mailing list
netdisco-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netdisco-users [1]
[attachment "af24 test search.png" removed by Steven Xu/fs/YorkU]
[attachment "test-search.png" removed by Steven Xu/fs/YorkU]
[attachment "7919-search.png" removed by Steven Xu/fs/YorkU]
Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/netdisco-users
--- End Message ---
------------------------------------------------------------------------------
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140
_______________________________________________
Netdisco mailing list - Digest Mode
netdisco-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netdisco-users
