Send Netdot-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://osl.uoregon.edu/mailman/listinfo/netdot-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 Netdot-users digest..."
Today's Topics:
1. updatedevices.pl endless loop (Patrick Landry)
2. Re: updatedevices.pl endless loop (Anton Berezin)
3. Re: updatedevices.pl endless loop (Patrick Landry)
----------------------------------------------------------------------
Message: 1
Date: Wed, 21 Jan 2015 09:27:22 -0600 (CST)
From: Patrick Landry <[email protected]>
Subject: [Netdot-users] updatedevices.pl endless loop
To: "netdot-users " <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
I am having a problem with updatedevices.pl entering what seems to be an
endless loop when communicating
with one particular device.
When I run
netdot/bin/updatedevices.pl -FA --host CLIENT-IP --communities COMM-STRING
--debug
the last debug lines printed are
DEBUG - CLIENT: Fetching IPv6 ND cache via SNMP
SNMP::Info::_load_attr ip_n2p_phys_addr : ipNetToPhysicalPhysAddress
If I run tcpdump on the appropriate interface on the netdot server I see the
same SNMP GetBulk/GetResponse
packets being repeated endlessly
09:16:49.556845 IP NETDOT-SERVER.35418 > CLIENT.snmp: C=COMM-STRING GetBulk(41)
N=0 M=20 ip.35.1.4.260.1.4.255.255.255.255
09:16:49.557636 IP CLIENT.snmp > NETDOT-SERVER.35418: C=COMM-STRING
GetResponse(596) ip.35.1.4.260.1.4.10.17.60.1=20_b3_99_57_65_2f
ip.35.1.4.260.1.4.10.17.60.2=d4_be_d9_6a_ae_1e
ip.35.1.4.260.1.4.10.17.60.20=ec_f4_bb_2f_df_94
ip.35.1.4.260.1.4.10.17.60.21=9c_93_4e_34_47_0f
ip.35.1.4.260.1.4.10.17.60.22=00_0e_7f_db_9b_09
ip.35.1.4.260.1.4.10.17.60.23=00_21_5a_7b_49_cd
ip.35.1.4.260.1.4.10.17.60.52=18_03_73_b4_85_6c
ip.35.1.4.260.1.4.10.17.60.53=d4_be_d9_1b_2a_b8
ip.35.1.4.260.1.4.10.17^C.60.54=90_b1_1c_6e_ad_81
ip.35.1.4.260.1.4.10.17.60.56=d4_be_d9_6b_47_59
ip.35.1.4.260.1.4.10.17.60.58=18_03_73_cd_ca_05
ip.35.1.4.260.1.4.10.17.60.61=90_b1_1c_62_06_40
ip.35.1.4.260.1.4.10.17.60.68=40_6c_8f_22_cd_1d
ip.35.1.4.260.1.4.10.17.60.71=b8_ca_3a_d0_97_c9
ip.35.1.4.260.1.4.10.17.60.76=d0_27_88_bb_03_0c
ip.35.1.4.260.1.4.10.17.60.78=00_1e_4f_b3_8e_50
ip.35.1.4.260.1.4.10.17.60.80=00_15_99_87_13_70
ip.35.1.4.260.1.4.10.17.60.81=d4_be_d9_a1_ac_c8
ip.35.1.4.260.1.4.10.17.60.82=b8_ac_6f_3!
8_6f_63 ip.35.1.4.260.1.4.10.17.60.83=d4_be_d9_a1_9c_02
The CLIENT is an "Enterasys Networks, Inc. S4 Chassis".
I checked the Netdot Redmine site but didn't see any issues that looked
applicable. If there is no quick answer here
I will open a new issue there.
TIA
--
Patrick Landry
Director, UCSS
University of Louisiana at Lafayette
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://osl.uoregon.edu/pipermail/netdot-users/attachments/20150121/4a79c356/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulfleur3.jpg
Type: image/jpeg
Size: 2228 bytes
Desc: not available
Url :
http://osl.uoregon.edu/pipermail/netdot-users/attachments/20150121/4a79c356/attachment-0001.jpg
------------------------------
Message: 2
Date: Wed, 21 Jan 2015 16:32:11 +0100
From: Anton Berezin <[email protected]>
Subject: Re: [Netdot-users] updatedevices.pl endless loop
To: Patrick Landry <[email protected]>
Cc: netdot-users <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Wed, Jan 21, 2015 at 09:27:22AM -0600, Patrick Landry wrote:
> I am having a problem with updatedevices.pl entering what seems to be an
> endless loop when communicating
> with one particular device.
> If I run tcpdump on the appropriate interface on the netdot server I see the
> same SNMP GetBulk/GetResponse
> packets being repeated endlessly
>
> 09:16:49.556845 IP NETDOT-SERVER.35418 > CLIENT.snmp: C=COMM-STRING
> GetBulk(41) N=0 M=20 ip.35.1.4.260.1.4.255.255.255.255
> 09:16:49.557636 IP CLIENT.snmp > NETDOT-SERVER.35418: C=COMM-STRING
> GetResponse(596) ip.35.1.4.260.1.4.10.17.60.1=20_b3_99_57_65_2f
> ip.35.1.4.260.1.4.10.17.60.2=d4_be_d9_6a_ae_1e
> ip.35.1.4.260.1.4.10.17.60.20=ec_f4_bb_2f_df_94
> ip.35.1.4.260.1.4.10.17.60.21=9c_93_4e_34_47_0f
> ip.35.1.4.260.1.4.10.17.60.22=00_0e_7f_db_9b_09
> ip.35.1.4.260.1.4.10.17.60.23=00_21_5a_7b_49_cd
> ip.35.1.4.260.1.4.10.17.60.52=18_03_73_b4_85_6c
> ip.35.1.4.260.1.4.10.17.60.53=d4_be_d9_1b_2a_b8
> ip.35.1.4.260.1.4.10.17^C.60.54=90_b1_1c_6e_ad_81
> ip.35.1.4.260.1.4.10.17.60.56=d4_be_d9_6b_47_59
> ip.35.1.4.260.1.4.10.17.60.58=18_03_73_cd_ca_05
> ip.35.1.4.260.1.4.10.17.60.61=90_b1_1c_62_06_40
> ip.35.1.4.260.1.4.10.17.60.68=40_6c_8f_22_cd_1d
> ip.35.1.4.260.1.4.10.17.60.71=b8_ca_3a_d0_97_c9
> ip.35.1.4.260.1.4.10.17.60.76=d0_27_88_bb_03_0c
> ip.35.1.4.260.1.4.10.17.60.78=00_1e_4f_b3_8e_50
> ip.35.1.4.260.1.4.10.17.60.80=00_15_99_87_13_70
> ip.35.1.4.260.1.4.10.17.60.81=d4_be_d9_a1_ac_c8
> ip.35.1.4.260.1.4.10.17.60.82=b8_ac_6f!
_38_6f_63 ip.35.1.4.260.1.4.10.17.60.83=d4_be_d9_a1_9c_02
>
> The CLIENT is an "Enterasys Networks, Inc. S4 Chassis".
>
> I checked the Netdot Redmine site but didn't see any issues that looked
> applicable. If there is no quick answer here
> I will open a new issue there.
What happens if you do snmpbulkwalk of the ip.35.1.4.260.1.4 table by
hand? Does it terminate? Does it report anything unusual?
\Anton.
--
Our society can survive even a large amount of irrational regulation.
-- John McCarthy
------------------------------
Message: 3
Date: Wed, 21 Jan 2015 11:24:22 -0600 (CST)
From: Patrick Landry <[email protected]>
Subject: Re: [Netdot-users] updatedevices.pl endless loop
To: netdot-users <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
----- Original Message -----
> What happens if you do snmpbulkwalk of the ip.35.1.4.260.1.4 table by
> hand? Does it terminate? Does it report anything unusual?
> \Anton.
> --
> Our society can survive even a large amount of irrational regulation.
> -- John McCarthy
Thanks Anton. Here is the output of snmpbulkwalk:
# snmpbulkwalk -v 2c -c COMM-STRING CLIENT-IP ip.35.1.4.260.1.4
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.1" = STRING:
20:b3:99:57:65:2f
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.2" = STRING:
d4:be:d9:6a:ae:1e
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.20" = STRING:
ec:f4:bb:2f:df:94
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.21" = STRING:
9c:93:4e:34:47:f
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.22" = STRING:
0:e:7f:db:9b:9
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.23" = STRING:
0:21:5a:7b:49:cd
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.52" = STRING:
18:3:73:b4:85:6c
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.53" = STRING:
d4:be:d9:1b:2a:b8
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.54" = STRING:
90:b1:1c:6e:ad:81
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.56" = STRING:
d4:be:d9:6b:47:59
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.58" = STRING:
18:3:73:cd:ca:5
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.61" = STRING:
90:b1:1c:62:6:40
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.68" = STRING:
40:6c:8f:22:cd:1d
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.71" = STRING:
b8:ca:3a:d0:97:c9
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.74" = STRING:
d4:be:d9:6b:47:62
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.76" = STRING:
d0:27:88:bb:3:c
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.78" = STRING:
0:1e:4f:b3:8e:50
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.80" = STRING:
0:15:99:87:13:70
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.81" = STRING:
d4:be:d9:a1:ac:c8
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.82" = STRING:
b8:ac:6f:38:6f:63
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.83" = STRING:
d4:be:d9:a1:9c:2
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.86" = STRING:
0:1e:4f:b3:88:29
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.88" = STRING:
f0:1f:af:6d:16:1c
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.89" = STRING:
f0:1f:af:6d:11:86
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.90" = STRING:
0:18:8b:2d:1e:ba
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.251" = STRING:
f8:bc:12:a0:fb:6d
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.253" = STRING:
0:1a:a0:d1:d9:dc
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."255.255.255.255" = STRING:
0:0:0:0:0:0
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.1" = STRING:
20:b3:99:57:65:2f
Error: OID not increasing:
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.82"
>= IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.1"
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.2" = STRING:
d4:be:d9:6a:ae:1e
Error: OID not increasing:
IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.82"
>= IP-MIB::ipNetToPhysicalPhysAddress.260.ipv4."10.17.60.2"
Does this indicate an error in the device's SNMP agent implementation?
--
Patrick Landry
Director, UCSS
University of Louisiana at Lafayette
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://osl.uoregon.edu/pipermail/netdot-users/attachments/20150121/27a752d0/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulfleur3.jpg
Type: image/jpeg
Size: 2228 bytes
Desc: not available
Url :
http://osl.uoregon.edu/pipermail/netdot-users/attachments/20150121/27a752d0/attachment.jpg
------------------------------
_______________________________________________
Netdot-users mailing list
[email protected]
https://osl.uoregon.edu/mailman/listinfo/netdot-users
End of Netdot-users Digest, Vol 74, Issue 6
*******************************************
