[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference netcad::hub_mgnt

Title:	DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:	Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:	NETCAD::COLELLADT

Created:	Wed Nov 13 1991
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4455
Total number of notes:	16761

2668.0. "DECswitch 900EF stops responding to HUBwatch??" by DECPRG::PAVLUP () Wed Aug 23 1995 17:35

My customer has reported the following problem with DECswithes 900EF in
his network. It seems that some of the bridges do not respond properly to 
SNMP management.

First the configuration. The network is a hub900-based network with an FDDI
backbone. In total, there are 7 DECswitches 900EF, all installed in hubs.
The hubs are HW=F,RO=V1.1.6,SW=V3.1.0, the DS900EFs are 
HW=v0/1,RO=v0.2,SW=v1.4.0. The management is by HUBwatch V3.1 on a VMS
workstation with VMS V6.1, MCC V1.3, and UCX V3.1.

Recently they have found that 3 out of the total 7 switches exhibit
the following behaviour: when double-clicking on the switch front view
(either in a hub view through hub manager, or in the "standalone" view
through the 900EF's agent), the error saying

DB900: SNMP error, No data received, sum_u group

appears and the detailed window of switch does not get up. We have them
make traces of the conversations for us, and I show the parts of the SNMP
traces below. The full traces can be made available. It seems that 
the SNMP conversation ends with the switch not responding to the GET-NEXT
packet...?

Could anyone give me any hint, suggestion, opinion? Might this be any of 
known problems? Might this be due to short timeouts...? For the
completeness' sake: the network has been working O.K. (including the
management of all modules) for more than a year.

Thanks for any response.

Regards Petr.


-------------------------
The final part of conversation between HUBwatch and hub (run against
the hub manager):
-------------------------

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> XMT: [GET-NEXT] to 16.193.128.211 [?], community= public-7
>>      Status = NO_ERROR, Id = 809145345, Errindex= 0, Varbinds = 16
>>>   vb(1) [pcomLedProgram.2]
>>>   vb(2) [pcomLedProgram.3]
>>>   vb(3) [pcomLedProgram.4]
>>>   vb(4) [pcomLedProgram.5]
>>>   vb(5) [pcomLedProgram.6]
>>>   vb(6) [pcomLedProgram.7]
>>>   vb(7) [pcomLedProgram.8]
>>>   vb(8) [pcomLedProgram.9]
>>>   vb(9) [pcomLedProgram.10]
>>>   vb(10) [pcomLedProgram.11]
>>>   vb(11) [pcomLedProgram.12]
>>>   vb(12) [pcomLedProgram.13]
>>>   vb(13) [pcomLedProgram.14]
>>>   vb(14) [pcomLedProgram.15]
>>>   vb(15) [pcomLedProgram.16]
>>>   vb(16) [pcomLedProgram.17]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  << RCV: [GET-RESPONSE] from 16.193.128.211 [?], community= public-7
  <<      Status = NO_ERROR, Id = 809145345, Errindex= 0, Varbinds = 16
  <<<   vb(1) OCTET_STRING: [pcomLedProgram.3] = [04:ff]
  <<<   vb(2) OCTET_STRING: [pcomLedProgram.4] = [00:ff]
  <<<   vb(3) OCTET_STRING: [pcomLedProgram.5] = [04:ff]
  <<<   vb(4) OCTET_STRING: [pcomLedProgram.6] = [04:ff]
  <<<   vb(5) OCTET_STRING: [pcomLedProgram.7] = [04:ff]
  <<<   vb(6) OCTET_STRING: [pcomLedProgram.8] = [03:ff]
  <<<   vb(7) OCTET_STRING: [pcomLedProgram.9] = [04:ff]
  <<<   vb(8) OCTET_STRING: [pcomLedProgram.10] = [03:ff]
  <<<   vb(9) OCTET_STRING: [pcomLedProgram.11] = [04:ff]
  <<<   vb(10) OCTET_STRING: [pcomLedProgram.12] = [03:ff]
  <<<   vb(11) OCTET_STRING: [pcomLedProgram.13] = [00:ff]
  <<<   vb(12) OCTET_STRING: [pcomLedProgram.14] = [00:ff]
  <<<   vb(13) OCTET_STRING: [pcomLedProgram.15] = [04:ff]
  <<<   vb(14) OCTET_STRING: [pcomLedProgram.16] = [04:ff]
  <<<   vb(15) OCTET_STRING: [pcomLedProgram.17] = [04:ff]
  <<<   vb(16) OCTET_STRING: [pcomLedProgram.18] = [03:ff]
  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> XMT: [GET-NEXT] to 16.193.128.211 [?], community= public-7
>>      Status = NO_ERROR, Id = 809145346, Errindex= 0, Varbinds = 1
>>>   vb(1) [pcomLedProgram.1]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  << RCV: [GET-RESPONSE] from 16.193.128.211 [?], community= public-7
  <<      Status = NO_ERROR, Id = 809145346, Errindex= 0, Varbinds = 1
  <<<   vb(1) OCTET_STRING: [pcomLedProgram.2] = [04:ff]
  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> XMT: [GET-NEXT] to 16.193.128.211 [?], community= public-7
>>      Status = NO_ERROR, Id = 809145347, Errindex= 0, Varbinds = 3
>>>   vb(1) [dot1dBaseNumPorts]
>>>   vb(2) [sysUpTime]
>>>   vb(3) [ebrMgmtHeardPort]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

============================================================================
And now the full conversation of HUBwatch with the DS900EF's agent:
------------------------


HUBwatch for OpenVMS, Revision V3.1.3
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> XMT: [GET-NEXT] to 16.193.128.223 [prk223], community= public
>>      Status = NO_ERROR, Id = 809145469, Errindex= 0, Varbinds = 1
>>>   vb(1) [sysObjectID]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  << RCV: [GET-RESPONSE] from 16.193.128.223 [prk223], community= public
  <<      Status = NO_ERROR, Id = 809145469, Errindex= 0, Varbinds = 1
  <<<   vb(1) OBJECT_ID: [sysObjectID.0] = [1.3.6.1.4.1.36.2.15.3.7.1]
  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> XMT: [GET-NEXT] to 16.193.128.223 [prk223], community= public
>>      Status = NO_ERROR, Id = 809145470, Errindex= 0, Varbinds = 16
>>>   vb(1) [pcomLedProgram.2]
>>>   vb(2) [pcomLedProgram.3]
>>>   vb(3) [pcomLedProgram.4]
>>>   vb(4) [pcomLedProgram.5]
>>>   vb(5) [pcomLedProgram.6]
>>>   vb(6) [pcomLedProgram.7]
>>>   vb(7) [pcomLedProgram.8]
>>>   vb(8) [pcomLedProgram.9]
>>>   vb(9) [pcomLedProgram.10]
>>>   vb(10) [pcomLedProgram.11]
>>>   vb(11) [pcomLedProgram.12]
>>>   vb(12) [pcomLedProgram.13]
>>>   vb(13) [pcomLedProgram.14]
>>>   vb(14) [pcomLedProgram.15]
>>>   vb(15) [pcomLedProgram.16]
>>>   vb(16) [pcomLedProgram.17]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  << RCV: [GET-RESPONSE] from 16.193.128.223 [prk223], community= public
  <<      Status = NO_ERROR, Id = 809145470, Errindex= 0, Varbinds = 16
  <<<   vb(1) OCTET_STRING: [pcomLedProgram.3] = [04:ff]
  <<<   vb(2) OCTET_STRING: [pcomLedProgram.4] = [00:ff]
  <<<   vb(3) OCTET_STRING: [pcomLedProgram.5] = [04:ff]
  <<<   vb(4) OCTET_STRING: [pcomLedProgram.6] = [04:ff]
  <<<   vb(5) OCTET_STRING: [pcomLedProgram.7] = [04:ff]
  <<<   vb(6) OCTET_STRING: [pcomLedProgram.8] = [03:ff]
  <<<   vb(7) OCTET_STRING: [pcomLedProgram.9] = [04:ff]
  <<<   vb(8) OCTET_STRING: [pcomLedProgram.10] = [03:ff]
  <<<   vb(9) OCTET_STRING: [pcomLedProgram.11] = [04:ff]
  <<<   vb(10) OCTET_STRING: [pcomLedProgram.12] = [03:ff]
  <<<   vb(11) OCTET_STRING: [pcomLedProgram.13] = [00:ff]
  <<<   vb(12) OCTET_STRING: [pcomLedProgram.14] = [00:ff]
  <<<   vb(13) OCTET_STRING: [pcomLedProgram.15] = [04:ff]
  <<<   vb(14) OCTET_STRING: [pcomLedProgram.16] = [04:ff]
  <<<   vb(15) OCTET_STRING: [pcomLedProgram.17] = [04:ff]
  <<<   vb(16) OCTET_STRING: [pcomLedProgram.18] = [03:ff]
  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> XMT: [GET-NEXT] to 16.193.128.223 [prk223], community= public
>>      Status = NO_ERROR, Id = 809145471, Errindex= 0, Varbinds = 1
>>>   vb(1) [pcomLedProgram.1]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  << RCV: [GET-RESPONSE] from 16.193.128.223 [prk223], community= public
  <<      Status = NO_ERROR, Id = 809145471, Errindex= 0, Varbinds = 1
  <<<   vb(1) OCTET_STRING: [pcomLedProgram.2] = [04:ff]
  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> XMT: [GET-NEXT] to 16.193.128.223 [prk223], community= public
>>      Status = NO_ERROR, Id = 809145472, Errindex= 0, Varbinds = 3
>>>   vb(1) [dot1dBaseNumPorts]
>>>   vb(2) [sysUpTime]
>>>   vb(3) [ebrMgmtHeardPort]
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

T.R	Title	User	Personal Name	Date	Lines
2668.1		NPSS::WADE	Network Systems Support	`Wed Aug 23 1995 18:02`	9
	Can you ping the bridge when this happens? Does the bridge reset, any error log entries? Please supply the error logs for the bridges. I'd suggest that you get up to the latest EF and MAM code but HUBwatch for VMS 4.x isn't shipping yet. Bill
2668.2	IP and bridging O.K., we'll get logs	DECPRG::PAVLUP		`Thu Aug 24 1995 12:36`	12
	Hi Bill, it is possible to ping the bridge - immediately after the unsuccessful attempt to manage it. So IP seems to work O.K. The bridge also bridges correctly all the time (the network is all up and running). We will pull out the error log entries from the bridge(s). As soon as I have them, I'll post them here. The upgrade to V4 FW set is not possible - as you say - there is VMS HUBwatch. Regards Petr.