[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
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.R | Title | User | Personal Name | Date | Lines |
---|
2888.1 | not related... but maybe same cause? | CSOADM::ROTH | What, me worry? | Tue May 05 1992 14:57 | 11 |
| 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.2 | Some notes... | CHRISB::BRIENEN | DECmcc LAN and SNMP Stuff... | Wed May 06 1992 15:32 | 23 |
| 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
|