home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / protocol / snmp / 566 < prev    next >
Encoding:
Text File  |  1992-08-17  |  3.6 KB  |  97 lines
  1. Newsgroups: comp.protocols.snmp
  2. Path: sparky!uunet!mcsun!Germany.EU.net!news.netmbx.de!zrz.tu-berlin.de!math.fu-berlin.de!informatik.tu-muenchen.de!LRZnews!cd1.lrz-muenchen.de!a2824as
  3. From: a2824as@cd1.lrz-muenchen.de (Michael Storz)
  4. Subject: Re: How can I fix a HP Open View's bug? (burst packets)
  5. Message-ID: <1992Aug17.173802.7473@news.lrz-muenchen.de>
  6. Sender: news@news.lrz-muenchen.de (Mr. News)
  7. Reply-To: Michael.Storz@lrz.lrz-muenchen.dbp.de
  8. Organization: Leibniz-Rechenzentrum Muenchen, Germany
  9. References:  <47443610@Vanadium.NTT.JP>
  10. Distribution: comp
  11. Date: Mon, 17 Aug 1992 17:38:02 GMT
  12. Lines: 83
  13.  
  14. In article <47443610@Vanadium.NTT.JP>, murakami@ntt-20.ntt.jp writes:
  15. |> Hello, SNMP Experts!
  16. |> 
  17. |> We have an Open View from HP and we are annoyed with the bug. YHP
  18. |> in Japan cannot fix the problem, although we gave them the
  19. |> following packet dump. So, we are compelled to ask you how to fix
  20. |> it. The problem is the burst packet. Open View suddenly generates
  21. |> a lot of packets to an node.  All these packets are SNMP set
  22. |> requests. Does anyone experienced the same problem?  Although
  23.  
  24. We have not seen this problem using the HP Open View Network Nodemanager
  25. (or Interconnect Manager based on the modules purchased) but we have not looked
  26. out carefully for set requests of the Nodemanager.
  27.  
  28. |> we tried to find the object ID internet.4.1.11.2.13.1.2.1.1, we
  29. |> could not find it in the standard MIB. What is this?
  30.  
  31. This is not in the standard MIB, it is
  32.  
  33. internet.private.enterprises.hp.nm.snmp.trap.trapDestinationTable
  34. .trapDestinationEntry
  35.  
  36. If the Nodemanager finds a HP maschine which it should manage, then
  37. it sets the above mentioned object of that maschine to the IP address of the
  38. Nodemanager.  
  39.  
  40. One time we saw that the Nodemanager tried also to set variables on a DEC
  41. maschine (the system administrator complaint about that, so we unmanaged the
  42. system).
  43.  
  44. In your case it seems that the Nodemanager tries to set this object in your 
  45. CISCO box with IP-address 129.60.57.9. This is naturally not possible because
  46. CISCO does not know about HP private MIBs and therefore a bug, which should be
  47. reported to HP. Maybe it is fixed in the next release 3.1 which we hope to 
  48. install next week.
  49.  
  50. BTW, there is no reverse mapping for 129.60.57.9 in the DNS.
  51.  
  52. |> 
  53. |> -Ken
  54. |> 
  55. |> Ken Murakami
  56. |> NTT Laboratories
  57. |> Tokyo, Japan
  58. |> 
  59. |> E-mail: murakami@ntt-20.ntt.jp
  60. |> Phone: +81 422 59 3589
  61. |> FAX:   +81 422 59 3589
  62. |> 
  63. |> 
  64. |> 
  65. |> ====
  66. |> 
  67. |> Sniffer Network Analyzer data from 28-May-92 at 15:17:00
  68. |> 
  69. |> - - - - - - - - - - - - - - - - Frame 1 - - - - - - - - - - - - - - - - -
  70. |> 
  71. |> SUMMARY  Delta T     Destination   Source        Summary
  72. |> M    1            Cisco 002E1D H-P   256358  SNMP Set internet.4.1.11.2.13.1.2.1.1.192.65.17.91 = [0.0.0.0]
  73. |> 
  74. |> SNMP: ----- Simple Network Management Protocol -----
  75. |> SNMP: 
  76. |> SNMP: Version = 0
  77. |> SNMP: Community = snmpd
  78. |> SNMP: Command = Set request
  79. |> SNMP: Request ID = 596004
  80. |> SNMP: Error status = 0 (No error)
  81. |> SNMP: Error index = 0
  82. |> SNMP: 
  83. |> SNMP: Object = {1.3.6.1.4.1.11.2.13.1.2.1.1.129.60.57.9} (internet.4.1.11.2.13.1.2.1.1.192.65.17.91)
  84. |> SNMP: Value  = [0.0.0.0]
  85. |> SNMP: 
  86.  
  87. -- 
  88.  
  89. Michael Storz
  90. ================================================================================
  91.                                       !   X.400 : G=michael;S=storz;OU1=lrz;
  92.    Leibniz-Rechenzentrum              !           P=lrz-muenchen;A=dbp;C=de
  93.    Barer Str. 21                      !   RFC822: storz@lrz.lrz-muenchen.dbp.de
  94.    8000 Muenchen 2                    !   Fax   : ++ 49 89 2809460
  95.    Germany                            !   Tel   : ++ 49 89 2105 7420
  96. ================================================================================
  97.