[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

2888.0. "False Alarms...!?" by MEHR::MEHR () Wed Apr 29 1992 19:30


My customer has faxed me the following problem definition:

"We are seeing false alarms from DECservers, DECbridges and Emulex 
servers. So it is not product-specific. Note that the alarms we are seeing 
are "exceptions," rather than alarms. ("Cannot communicate with target" or 
"No counters in the counter field")

Frequency: False alarms occur at all times of the date. Exact frequency 
varies, but in general we see between 3-5 every hour.


We used a Sniffer on the Corp-LAN. This is the DECmcc Ethernet segment. 
For the terminal servers we looked at MOP requests.
There were a couple of cases where there were 2 requests but 1 response 
from the server. In another case there was 1 request and 1 response. 
It appears that the request is reaching the end device and response is then 
coming back at least as far as the segment MCC is attached to. Either MCC 
is not reading the response off the line or is processing the response 
incorrectly. The data I saw from the Sniffer on three false alarms:


Orgn/Dest	TIME	

MCC to TSVM07 	15:26:29.5398	MOP RC Request ID Receipt=41
		15:26:30.6247	MOP RC Request ID Receipt=41
TSVM07 to MCC 	15:26:30.6430	MOP RC System ID Receipt=41
				(Console Response Size = 255)

MCC to TSVM23 	15:31:39.1329	MOP RC Request ID Receipt=123
		15:26:29.6455	MOP RC Request ID Receipt=123
TSVM23 to MCC 	15:31:39.6551	MOP RC System ID Receipt=123
				(Console Response Size = 255)

MCC to TSVM04 	31:20:51.9259	MOP RC Request ID Receipt=131
TSVM04 to MCC 	13:20:51.9680	MOP RC System ID Receipt=131
				(Console Response Size = 255) ."



Some more information that I know of their environment includes:

. They are running MCC V1.1, VMS 5.4

. They alarms are typically set for every 5 minutes

. They have several LANs that are either connected together with DECbridges, 
  Vitalink bridges, or Wellfleet routers.


Any suggestions as to what could be the cause of the problem??
And what could be done about it?

Thanks,
Mahnaz
T.RTitleUserPersonal
Name
DateLines
2888.1not related... but maybe same cause?CSOADM::ROTHWhat, me worry?Tue May 05 1992 14:5711
Are the managed servers on the other side of Vitalinks/Wellfleets?

I'm currently troubleshooting a Cisco problem right now(VMS print queues
pausing) that is related to multicasts being thrown away somewhere by the
Cisco. 

When traffic conditions are busy the Vitalinks will discard multicast packets
(like MOP packets) in favor of singlecast packets. Are the Vitalink bridges
spitting out any messages on their consoles?

Lee Roth
2888.2Some notes...CHRISB::BRIENENDECmcc LAN and SNMP Stuff...Wed May 06 1992 15:3223
Issues around the base note were discussed with Mahnaz over the phone (it
sounded like she was to visiting the customer this week).
Some miscellaneous notes:

- It would appear from the traces/symptoms that the MCC_EA routines
  (or Ethernet Station AM) are occasionally dropping responses.

- The "Cannot Communicate with Target" message is returned by Ethernet AM
  V1.1 for a multitude of problems (better messages were added for V1.2)
  "No counters in the counter field" would indicate bad data from the
  target station. A dump of the failing packets would help here.

- Q: Is the No Counters message being generated for just the Emulex Servers?

- There were some reliability problems found in the MCC_EA routines that
  have been addressed for the upcoming V1.2 release.

- RE: Multiple MOP requests yielding a single response - there's nothing
  that says a management station will reliably respond to every MOP
  request sent in its direction (which is why a retry mechanism is built
  into the MCC_EA routines).

						Chris