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

Conference azur::mcc

Title:	DECmcc user notes file. Does not replace IPMT.
Notice:	Use IPMT for problems. Newsletter location in note 6187
Moderator:	TAEC::BEROUD

Created:	Mon Aug 21 1989
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	6497
Total number of notes:	27359

6157.0. "SNMP traps not received to V1.3 on VMS V6.1" by DECPRG::PAVLUP () Wed Nov 02 1994 07:06

A customer who is running the POLYCENTER Network Manageer 400 is 
experiencing serious problems when trying to work with SNMP events (traps).

The environment is as follows:

VAXstation 4000/90
OpenVMS V6.1
DECnet Phase IV
UCX V3.1
MCC V1.3.0

The management station is not capable of receiving any SNMP trap from devices in 
the network.

When doing

MCC> GETEVENT SNMP * ANY CONFIGURATION EVENT

the command just hangs and nothing is hapenning though traps are comming to the 
station (forever). 
The immediate reason is that the process MCC_TCPIP_SINK that is expected to be 
invoked by this command is not existing. MCC_TCPIP_SINK.ERR file is empty.

An attempt to look at the TCPIP_AM SINK entity is not succesfull. Another 
attempt was made to investigate the process' behaviour: the sink was run from 
the DCL ($ MC MCC_TCPIP_SINK) and from another window the command

MCC> SHOW MCC 0 TCPIP_AM SINK

was issued. The SHOW commands hangs forever, while the sink image run from the 
DCL prompt exits immediately after the SHOW command is issued.

As a result, the MCC station is incapable to receive any SNMP event. The 
MCC_IP_POLLER however runs successfully.

The problem cannot be bound to the UCX software. This is because there is 
HUBwatch V3.0 installed at the station too, and its alarm facilities 
successfully and reliably accept all expected SNMP traps.

The problem is rather critical for the customer, as he purchased a bunch of UPS 
boxes with SNMP management whose signalling is via SNMP traps. Until the station 
is capable to accept the traps and initiate appropriate actions related to the 
UPS status, they can't use the UPS boxes for reliable backing their systems 
(including controlled shutdowns etc.).

Help, help,...

We have QARed the problem, but may be someone has already come across it!
The 6.1 happened to be preinstalled at the new machine and it was probably 
unfortunate that it remained there but it is the situation on site. 

Any hint, comment, recommendation welcome. The situation gets difficult in
front of customer's claims that "Any stupidest SNMP station can do this..."

Regards Petr.

T.R	Title	User	Personal Name	Date	Lines
6157.1		DPDMAI::GALVIN	Baggins' Rings, payment in advance!	`Wed Nov 02 1994 09:25`	24
	Petr, I don't have a resolution for your problems; I just wanted to pose a question to you... You've stated you're running V6.1? Are you seeing any problems when you run the FCL? How did you install the software on your VAXstation? Did you install DECmcc on a V6.1 system, or did you install VMS, upgrade to V6.1 with MCC already installed? Have you seen any problems with the CMA libraries? There was a problem way back when V6.0 was installed that was fixed by using the MCC CMA libraries... Have you performed any such magic? Please send me a note as quickly as possible. I have a large telecom here in the States and we are quite close to closing a deal using a clustered VAX4000 model 705A. The minimum configuration is V6.1 and so far I've had no luck with BMS V1.3 on a V6.1 VMS platform... thanks, Mic DPD05::GALVIN
6157.2	I'll send info. Anyone else ????	DECPRG::PAVLUP		`Thu Nov 03 1994 03:04`	15
	In response to .1: I'll poste your request to my colleague who actually did "the magic" of installing all the stuff over V6.1. It has not been easy but it has been done (unfortunately - as I see it now...?). He is Jaromir Pilar @CHK (DECPRG::PILAR). Anyone else has read this note and could possibly help me with making SNMP traps up and running? The customer is wandering around with his UPS boxes, and wants the MCC station watch the traps from them... Thanks for any hint in advance! Petr.
6157.3	VMS 6.1/MCC 1.3 ok for me	PRSSOS::BONNAFE	Guy BONNAFE - CSC France	`Thu Nov 03 1994 03:27`	56
	RE .0 .1 I have upgraded from VMS 5.5-2/UCX 2.0E to VMS 6.1/UCX 3.1 some weeks ago and everything seems to work. Traps are successfully received and handled by MCC_TCPIP_SINK process. MCC> GETEVENT SNMP * ANY CONFIGURATION EVENT SNMP LOCAL_NS:.ultema AT 3-NOV-1994 08:52:01 CONFIGURATION EVENTS Successfully received event: Event: coldStart A coldStart trap was received: enterprise = "1.3.6.1.4.1.36.1" agent-addr = 16.189.144.38 generic-trap = coldStart specific-trap = 0 time-stamp = 247367400 MCC> and from another window : MCC> SHOW MCC 0 TCPIP_AM SINK ALL ATTRIBUTES MCC 0 TCPIP_AM SINK AT 3-NOV-1994 08:49:15 All Attributes Sink State = Running Time when Sink Started = 3-NOV-1994 08:47:23.45 Time of Last Event = "not applicable" Type of Last Event = not applicable Current Clients = 1 coldStart Traps Received = 0 warmStart Traps Received = 0 linkDown Traps Received = 0 linkUp Traps Received = 0 authenticationFailure Traps Received = 0 egpNeighborLoss Traps Received = 0 enterpriseSpecific Traps Received = 0 Total Traps Received = 0 Counter Creation Time = 3-NOV-1994 08:47:23.45 Component Version = V1.3.0 Component Identification = "DECmcc TCP/IP SNMP AM EVENT SINK" Sink Start Retries = 10 Sink Start Wait Timer = 2 MCC> I have to say that I'm running new Kernel and MTS images. Feel free to copy them from TOOK::NSM_CLD:[DECMCC.CSC_3] and check if they are of any help. As far as I remember, they were built to support VMS 6.0 And don't forget that VMS 6.1 will be officially supported only with the soon coming MCC V1.4 Guy.
6157.4	I'll try this...thanks	DECPRG::PAVLUP		`Thu Nov 03 1994 08:37`	7
	Hi Gyu, thanks for the hint. I'm going to make some tests to see if it is the right thing. Regards Petr.
6157.5	Two apps trying to receive traps?	BIKINI::KRAUSE	CSC Network Management/Hubs	`Wed Nov 09 1994 04:57`	11
	>The problem cannot be bound to the UCX software. This is because there is >HUBwatch V3.0 installed at the station too, and its alarm facilities >successfully and reliably accept all expected SNMP traps. This might be it! You can NOT run HUBwatch alarms and the MCC TCPIP event sink on the same machine! Both will try to connect to UDP port 162 the first application will succeed and the second will get an error return. MCC is obviously not checking the return status and this could explain the hang. Stop the HUBwatch processes and try MCC again. *Robert