netdisco-users Digest, Vol 113, Issue 13

netdisco-users-request Mon, 30 Nov 2015 11:59:22 -0800

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: ??: The connected device information is incorrect on
      Netdisco. (Jeroen van Ingen)
   2. Re: netdisco2 adding new MIBs (Martin L?rcher)
   3. Re: Missing Hostname for connected Nodes (Steven Xu)
   4. Cisco UCS Fabric Interconnect macsuck failure (inetjunkmail)

--- Begin Message ---

Hi,

At first glance these outputs look okay. I don't see yet how Netdiscowould store this in the database as GE2/0/19 at 3.3.3.3 being connectedto itself.

We can try to reproduce & debug this further if we have a full snmpwalkfor at least the 3.3.3.3 device; using that snmpwalk output, we cansimulate a device, discover it in Netdisco and verify step by step howthe neighbor relations are determined.

Would it be possible for someone from Huawei to produce a full snmpwalkfor the 3.3.3.3 device, ie starting from oid .1 and including the .1.0subtree? Preferably in a compressed (gzip or zip) file format.

(specifically requesting inclusion of .1.0, which should be present onall devices when being snmpwalked from .1, but I've seen gear thatdoesn't include .1.0 under .1...)



Regards,

Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands


On 11/24/2015 01:58 PM, Zhangyuanyuan (D) wrote:

Hi oliver,

We have two device: "192.168.1.247" and "192.168.1.246". Here is the output of 
the related commands. It seems that all informations are correct.

--------------------------------------------------------------------------------------------------------------------------------------------------

192.168.1.247

netdisco@dc-lmt:~$ ~netdisco/bin/netdisco-do show -d 192.168.1.247 -e c_id
[6870] 2015-11-24 17:43:12  info show: started at Tue Nov 24 12:43:12 2015
\ {
     169046155.80.1    "e4:68:a3:f9:17:81",
     169046155.92.1    "e4:68:a3:f9:17:81",
     169046155.115.1   "00:6d:88:34:87:01"
}
[6870] 2015-11-24 17:43:12  info show: finished at Tue Nov 24 12:43:12 2015
[6870] 2015-11-24 17:43:12  info show: status done: Showed c_id response from 
192.168.1.247.


netdisco@dc-lmt:~$ ~netdisco/bin/netdisco-do show -d 192.168.1.247 -e c_ip
[6876] 2015-11-24 17:43:32  info show: started at Tue Nov 24 12:43:32 2015
\ {
     169046155.80.1    "3.3.3.3",
     169046155.92.1    "3.3.3.3",
     169046155.115.1   "2.2.2.2"
}
[6876] 2015-11-24 17:43:33  info show: finished at Tue Nov 24 12:43:33 2015
[6876] 2015-11-24 17:43:33  info show: status done: Showed c_ip response from 
192.168.1.247.

netdisco@dc-lmt:~$ ~netdisco/bin/netdisco-do show -d 192.168.1.247 -e c_if
[6895] 2015-11-24 17:44:17  info show: started at Tue Nov 24 12:44:17 2015
\ {
     169046155.80.1    80,
     169046155.92.1    92,
     169046155.115.1   115
}
[6895] 2015-11-24 17:44:18  info show: finished at Tue Nov 24 12:44:18 2015
[6895] 2015-11-24 17:44:18  info show: status done: Showed c_if response from 
192.168.1.247.

netdisco@dc-lmt:~$ ~netdisco/bin/netdisco-do show -d 192.168.1.247 -e c_port
[6897] 2015-11-24 17:44:24  info show: started at Tue Nov 24 12:44:24 2015
\ {
     169046155.80.1    "GE2/0/31",
     169046155.92.1    "GE2/0/19",
     169046155.115.1   "40GE1/0/2"
}
[6897] 2015-11-24 17:44:25  info show: finished at Tue Nov 24 12:44:25 2015
[6897] 2015-11-24 17:44:25  info show: status done: Showed c_port response from 
192.168.1.247.

--------------------------------------------------------------------------------------------------------------------------------------------------

192.168.1.246

netdisco@dc-lmt:~$ ~netdisco/bin/netdisco-do show -d 192.168.1.246 -e c_id
[6872] 2015-11-24 17:43:19  info show: started at Tue Nov 24 12:43:19 2015
\ {
     241393620.172.1   "e4:68:a3:f9:17:81"
}
[6872] 2015-11-24 17:43:20  info show: finished at Tue Nov 24 12:43:20 2015
[6872] 2015-11-24 17:43:20  info show: status done: Showed c_id response from 
192.168.1.246.


netdisco@dc-lmt:~$ ~netdisco/bin/netdisco-do show -d 192.168.1.246 -e c_ip
[6874] 2015-11-24 17:43:25  info show: started at Tue Nov 24 12:43:25 2015
\ {
     241393620.172.1   "3.3.3.3"
}
[6874] 2015-11-24 17:43:26  info show: finished at Tue Nov 24 12:43:26 2015


netdisco@dc-lmt:~$ ~netdisco/bin/netdisco-do show -d 192.168.1.246 -e c_if
[6893] 2015-11-24 17:44:11  info show: started at Tue Nov 24 12:44:11 2015
\ {
     241393620.172.1   172
}
[6893] 2015-11-24 17:44:12  info show: finished at Tue Nov 24 12:44:12 2015
[6893] 2015-11-24 17:44:12  info show: status done: Showed c_if response from 
192.168.1.246.



netdisco@dc-lmt:~$ ~netdisco/bin/netdisco-do show -d 192.168.1.246 -e c_port
[6899] 2015-11-24 17:44:32  info show: started at Tue Nov 24 12:44:32 2015
\ {
     241393620.172.1   "40GE2/0/2"
}
[6899] 2015-11-24 17:44:33  info show: finished at Tue Nov 24 12:44:33 2015
[6899] 2015-11-24 17:44:33  info show: status done: Showed c_port response from 
192.168.1.246.
netdisco@dc-lmt:~$


Best regards.




-----邮件原件-----
发件人: Oliver Gorwits [mailto:[email protected]]
发送时间: 2015年11月23日 17:10
收件人: Chenjie (Jacy, Enterprise Romania GTAC); 
[email protected]
抄送: Zoujing (Jingo Zou, DCLMT); Zhangyuanyuan (D); Wuwei (Bryan); Zhaoshaoqi
主题: Re: [Netdisco] The connected device information is incorrect on Netdisco.

Hi Jacy,

On 2015-11-17 08:44, Chenjie (Jacy, Enterprise Romania GTAC) wrote:

Please be informed that we tried to contact support from Netdisco but
nobody reply us, I am wondering if you have any other ways to contact
them since we are not familiar with this Netdisco company.


I already replied to you with the following request:

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.


Many thanks！

Best regards,

Jacy,

FROM: Zhangyuanyuan (D)
  SENT: Wednesday, November 11, 2015 9:46 AM
  TO: [email protected]
  CC: Chenjie (Jacy, Enterprise Romania GTAC); Zhaoshaoqi; Zoujing
(Jingo Zou, DCLMT); Wuwei (Bryan)
  SUBJECT: The connected device information is incorrect on Netdisco.

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


------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140
_______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users

--- End Message ---

--- Begin Message ---

Hi Oliver,

the devices are identified as:

avaya / VSP8284XSQ:     SNMP::Info::Layer3::Passport
avaya / rapidCity.209:  SNMP::Info::Layer3::Passport

rapidCity.209 is the Avaya VSP-7254XSQ.

But we get always "validate_autoload_method(hasCDP) Unable to resolve method" 
on these devices at discover process.

On a "avaya / VSP9010" wich is also identified as " 
SNMP::Info::Layer3::Passport" the discover succeeds - also on the older Avaya 
passport devices (ERS8xxx).

Any hints?

Regards
Martin

-----Ursprüngliche Nachricht-----
Von: Oliver Gorwits [mailto:[email protected]] 
Gesendet: Samstag, 28. November 2015 20:19
An: [email protected]
Betreff: Re: [Netdisco] netdisco2 adding new MIBs

Hi Martin,

On 2015-11-26 16:49, Martin Lärcher wrote:
> the same here with Avaya VSP 8000 and VSP 7200.
>
> But this devices should support SONMP too, or?
>
> We get always "validate_autoload_method(hasCDP) Unable to resolve 
> method"

Well, according to the current release of SNMP::Info, SONMP is included in the 
support neighbor protocols, and is checked for:

https://metacpan.org/pod/SNMP::Info#Topology-Information

However this relies on the device being identified correctly in the first place 
(as something which supports SONMP) - what we call the Device Class. You can 
see the Device Class in the web interface under the device details tab, or at 
the command line when run in debug, when the SNMP connection is made. If it's 
not specific to the vendor/platform, then it's likely SONMP is not being tested.

The creation of a new device class is also a little tricky, if required.

regards,
oliver.


> Running with debug shows the following:
>
> SNMP::Info::_global lldp_sys_cap : LLDP-MIB::lldpLocSysCapEnabled.0 :
> .1.0.8802.1.1.2.1.3.6.0
>
> SNMP::Info::_global(lldp_sys_cap) NOSUCHOBJECT at 
> /home/netdisco/perl5/lib/perl5/App/Netdisco/Core/Discover.pm line 676.
>
> SNMP::Info::_load_attr lldp_rem_id : LLDP-MIB::lldpRemChassisId :
> .1.0.8802.1.1.2.1.4.1.1.5 error:snmp_translate_obj:Unknown OID hasCDP
>
> SNMP::Info::_validate_autoload_method(hasCDP) Unable to resolve 
> method.
>
> SNMP::Info::_global sonmp_run :
> S5-ETH-MULTISEG-TOPOLOGY-MIB::s5EnMsTopStatus.0 :
> .1.3.6.1.4.1.45.1.6.13.1.2.0 error:snmp_translate_obj:Unknown OID 
> hasFDP
>
> SNMP::Info::_validate_autoload_method(hasFDP) Unable to resolve 
> method.
>
> error:snmp_translate_obj:Unknown OID hasEDP
>
> SNMP::Info::_validate_autoload_method(hasEDP) Unable to resolve 
> method.
>
> error:snmp_translate_obj:Unknown OID hasAMAP
>
> SNMP::Info::_validate_autoload_method(hasAMAP) Unable to resolve 
> method.
>
> SNMP::Info::_load_attr sonmp_topo_port :
> S5-ETH-MULTISEG-TOPOLOGY-MIB::s5EnMsTopNmmPort :
> .1.3.6.1.4.1.45.1.6.13.2.1.1.2 SNMP::Info::_load_attr sonmp_topo_ip :
> S5-ETH-MULTISEG-TOPOLOGY-MIB::s5EnMsTopNmmIpAddr :
> .1.3.6.1.4.1.45.1.6.13.2.1.1.3 error:snmp_translate_obj:Unknown OID 
> hasCDP
>
> SNMP::Info::_validate_autoload_method(hasCDP) Unable to resolve 
> method.
>
> [23437] 2015-11-25 15:55:22 debug  [192.168.x.x] neigh - CDP/LLDP not 
> enabled!
>
> [23437] 2015-11-25 15:55:22  info discover: finished at Wed Nov 25
> 16:55:22 2015 [23437] 2015-11-25 15:55:22  info discover: status
> done: Ended discover for 192.168.x.x
>
> Regards
>
> Martin
>
> VON: [email protected]
> [mailto:[email protected]]
> GESENDET: Freitag, 20. Februar 2015 10:54
> AN: [email protected]
> BETREFF: Re: [Netdisco] netdisco2 adding new MIBs
>
> Hello Oliver,
>
> thanks for your answer.
>
>> If you're not seeing any icon, then probably the neighbor protocols 
>> aren't working correctly on that uplink (CDP, LLDP, etc). You can 
>> discover the devices manually using the web form at the homepage of
> your
>> Netdisco installation, or at the command line using netdisco-do.
>
> Yes, you're right. The vsp4000 do not know anything about LLDP 
> (*damn*). It is on the Avaya roadmap for further enhancement. Until 
> then we'll have to add devices manually :-(
>
>> OK, I will come back to this... at the moment there isn't an easy
> way,
>> but I will try to think of something.
>
> Thanks for thinking about an easy way to add new mibs.
> Maybe it's possible to create a website where mibs can be uploaded and 
> processed so that the result can be shared with others that are using 
> these mibs. But maybe I'm not thinking very well and it's more 
> complicated than I can imagine :-)
>
> Greetings Mathias
>
> ArcelorMittal Bremen GmbH
>
> Vorsitzender des Aufsichtsrates: Hedwig Vergote
>
> Vorstand der GmbH: Dr. Dietmar Ringel, Vorsitzender, Rudolf Egbert, 
> Jörn Pufpaff, Dr. Paul Benteler
>
> Sitz der Gesellschaft: Bremen
>
> Amtsgericht Bremen, HRB 15474 HB


------------------------------------------------------------------------------
_______________________________________________
Netdisco mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users

--- End Message ---

--- Begin Message --- Hi Oliver,

This problem seems like it was caused by some code changes I made locally to improve query performance. Whoops! Unfortunately, things aren't stable enough for me to push performance improvements yet.

Steven

-----Oliver Gorwits <[email protected]> wrote: -----
To: <[email protected]>
From: Oliver Gorwits <[email protected]>
Date: 11/16/2015 04:12PM
Subject: Re: [Netdisco] Missing Hostname for connected Nodes

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.

------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users

--- End Message ---

--- Begin Message ---

We're trying to macsuck a pair of Cisco UCS 6200 Fabric Interconnects and
getting some errors.   For each MAC the debug output contains the following
error:

[14565] 2015-11-30 18:57:38 debug  [172.26.126.6] macsuck 00:20:26:a1:36:f7
- port 0 has no bp_index mapping - skipping


We never paid much attention to these in the past but we do have some MAC
to port mappings from a few months ago so it may have broken as a result of
a code upgrade on our devices.


SNMP::Info::device_type() layers:01000110 id:9 sysDescr:"Cisco NX-OS(tm)
ucs, Software (ucs-6100-k9-system), Version 5.2(3)N2(2.26c), RELEASE
SOFTWARE Copyright (c) 2002-2013 by Cisco Systems, Inc.   Compiled
10/6/2015 14:00:00"


We upgraded Netdisco today to see it tha would help but it had no efect.

SoftwareVersion*App::Netdisco <http://netdisco.org/>*2.033004DB Schema
<https://metacpan.org/module/netdisco-db-deploy>v40Dancer
<http://http//perldancer.org/>1.3202Bootstrap <http://getbootstrap.com/>
2.3.1PostgreSQL <http://www.postgresql.org/>PostgreSQL 9.2.14 on
x86_64-redhat-linux-gnu, compiled by gcc (GCC) 4.8.3 20140911 (Red Hat
4.8.3-9), 64-bit.
 DBI 1.631, DBD::Pg 2.19.3SNMP::Info <http://snmp-info.sourceforge.net/>3.30
Perl <http://www.perl.org/>5.016003



Can you provide any guidance on diagnosing the issue?

--- End Message ---

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140

_______________________________________________
Netdisco mailing list - Digest Mode
[email protected]
https://lists.sourceforge.net/lists/listinfo/netdisco-users

netdisco-users Digest, Vol 113, Issue 13

Reply via email to