home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / protocol / snmp / 568 < prev    next >
Encoding:
Internet Message Format  |  1992-08-18  |  3.5 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!sh.wide!wnoc-tyo-news!ccut!wsclark!lab!murakami.V
  2. From: murakami@ntt-20.ntt.jp
  3. Newsgroups: comp.protocols.snmp
  4. Subject: Re: How can I fix a HP Open View's bug? (burst packets)
  5. Message-ID: <47485020@Vanadium.NTT.JP>
  6. Date: 18 Aug 92 15:41:46 GMT
  7. References: <47443610@Vanadium.NTT.JP> <1992Aug17.173802.7473@news.lrz-muenchen.de>
  8. Sender: news@lab.ntt.jp
  9. Reply-To: murakami@ntt-20.ntt.jp
  10. Distribution: comp
  11. Organization: NTT Basic Research Laboratories NUE Group
  12. Lines: 81
  13. In-Reply-To: a2824as@cd1.lrz-muenchen.de's message of 17 Aug 92 17:38:02 GMT
  14. Posting-Front-End: TAO/ELIS Znews, Version 0.13, 9-May-91; Vanadium.NTT.JP
  15.  
  16. Michael,
  17.  
  18. >|> we tried to find the object ID internet.4.1.11.2.13.1.2.1.1, we
  19. >|> could not find it in the standard MIB. What is this?
  20. >
  21. >This is not in the standard MIB, it is
  22. >
  23. >internet.private.enterprises.hp.nm.snmp.trap.trapDestinationTable
  24. >.trapDestinationEntry
  25.  
  26. Yes. I FTPed the HP MIB. (FYI, venera.isi.edu is the anon FTP
  27. host.) Two other guys kindly send me the following mails;
  28.  
  29.     From: duggan@somnet.sandia.gov (David P Duggan)
  30.  
  31. >    We have been benchmarking HP Openview here and have run into the
  32. >    same problem.  It occurs when Openview is setting the SNMP trap
  33. >    address on another HP UNIX Workstation.  We put a sniffer on the
  34. >    network to find out the destination machine and decoded the packet
  35. >    to find out all the information.  We told HP about it and never
  36. >    received anything back from them either.
  37.  
  38.  
  39.     From: watanabe@elec.nkk.co.jp (Watanabe)
  40.  
  41.     (He sent me a mail in Japanese. Here is what he indicated.)
  42.  
  43.     >    internet.4            private
  44.     >    internet.4.1            enterprises
  45.     >    internet.4.1.11            HP
  46.     >    internet.4.1.11.2        nm
  47.     >    internet.4.1.11.2.13        hpsnmp
  48.     >    internet.4.1.11.2.13.1        hptrap
  49.     >    internet.4.1.11.2.13.1.2    trapDestinationTable
  50.     >    internet.4.1.11.2.13.1.2.1    trapDestinationEntry
  51.     >    internet.4.1.11.2.13.1.2.1.1    trapDestination
  52.  
  53.     (He also explained the mechanism in details.)
  54.  
  55. >If the Nodemanager finds a HP maschine which it should manage, 
  56. >then it sets the above mentioned object of that maschine to the IP
  57. >address of the Nodemanager.  
  58.  
  59. They, watanabe@elec.nkk.co.jp and duggan@somnet.sandia.gov (David P Duggan),
  60. also told me this besic mechanism.
  61.  
  62. >One time we saw that the Nodemanager tried also to set variables on a DEC
  63. >maschine (the system administrator complaint about that, so we unmanaged the
  64. >system).
  65.  
  66. The serious point is that HP generates the packet burstly. (about
  67. every 0.057 second, I remember.) This results in overloaded
  68. ethernet segment.
  69.  
  70. >In your case it seems that the Nodemanager tries to set this object in your 
  71. >CISCO box with IP-address 129.60.57.9. This is naturally not possible because
  72. >CISCO does not know about HP private MIBs and therefore a bug, which should be
  73. >reported to HP. Maybe it is fixed in the next release 3.1 which we hope to 
  74. >install next week.
  75.  
  76. The same problem was reported in US (by Dave) and Japan(We, NTT). 
  77. If you have reported HP about this problem, HP would know that the
  78. problem occured in US, Asia, and Europe, that is, all over the
  79. world. Unfortunately, we have not received any clear answer from
  80. HP. It seems the only way is to configure Open View not to set the
  81. trap vector. 
  82.  
  83. >BTW, there is no reverse mapping for 129.60.57.9 in the DNS.
  84.  
  85. Sorry. I modified the IP address randomly, since we can not
  86. make it open. Your DNS resolver is corrent.
  87.  
  88.  
  89. Anyway, I understand why it occues. Thank you very much, Michael, 
  90. Watanabe-san, and Dave. 
  91.  
  92. -Ken
  93.  
  94. Ken Murakami
  95. NTT Basic Research Labs
  96. Tokyo, Japan
  97.