| 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 |
Hi fellows, I have been waiting for about one year for the new MCC 1.4 release to fix a customer problem. This is an old problem reported by me on july last year in topic 6044. We have set some rules for IPREACHABILITY on some hosts in the network and monitoring the evaluations with IRIS, it shows that no matters how many seconds I specify (set mcc 0 tcpip_am [icmp|udp] [timeout|ret] n) MCC seems to be taken them from who knows where. (As a matter of fact, it happens primarily over the hosts in the WAN) I have set timeouts = 30 seconds and retries = 3, and found using Iris that sometimes the packets are being sent (I meant all of them = 4) in ms (miliseconds) between them (including the retries). I changed the rules in topic 6044 wanting to be notified in case the IPREACHABILITY change to down every 2 or 3 minutes (only one rule per hosts), and I tested them with just 4 nodes with same behavior. would we have a problem between MCC and UCX ? And again, Customer doesn't want to use the IP Poller, they claim it should work this way. I'm not a MCC expert, so I might be doing something wrong here, so I would appreciate receiving some help. I've thought that maybe changing the priority of some processes or something. ( I have increased the number of tcp/ip sockets, no success). Any Idea ? Thanks in advance, Richard Gonzalez PS: I have an open call on this, but ...... more details in topic 6044
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 6358.1 | We are working on a sinilar problem | AZUR::DURIF | Fri Aug 11 1995 10:22 | 23 | |
Bonjour Richard, >PS: I have an open call on this, but ...... Can you post here the number of the call. As MCC Maintenance is based on IPMT it may be a number looking like CFS.nnnnn or CLD.nnnnn with nnnnn beeing a five digits number. We do not know about specific CSC numbers. In MCC V1.4 timeout and retries parameters are handled correctly. The problem is somewhere else. I can provide you a TEST module. It contains traces displayed on the output. Just put here the IPMT case number. Put the results of the tests in IPMT. File is on node TAEC in directory MCC$PUBLIC:[MCC_V140_PATCHES.SNMP.TRACE_FOR_CFS10590] name is MCC_TCPIP_AM.EXE Hope this helps, Benoit | |||||
| 6358.2 | CSC32::MACGREGOR | Colorado: the TRUE mid-west | Fri Aug 11 1995 19:23 | 8 | |
CFS.15883 appears to be closed. However, this was the case number
that the problem occured. A new one will be created shortly.
Marc MacGregor
Digital Equipment Corporation
Network Support Team
| |||||
| 6358.3 | Traces results | VNZV01::GONZALEZ | Mon Aug 14 1995 19:08 | 34 | |
Hi, Thanks for the prompt response in .1. I replace the module, but I have some problems enrolling it. Finally after rebooting, It seems to be working (I think the boot process replaces the old image MCC_TCPIP_AM.EXE) Q: is this procedure correct ? If I type the command : MCC> SHOW MCC 0 TCPIP_AM ALL ATTRIB I Get V1.4-3 wich I think is the right one. As a summary I got a lot of messages like this. MCC_TCPIP_AM_PING\ICMP_Echo_Rec\550 Incorrect hosts address : expected 126.1.0.XX, received 126.1.0.YY I compared the UCX hosts definition with those in MCC and they are all the same. I hope it can help us to fix the problem whatever it is. BTW, UCX V3.1, OpenVMS V5.5-2 Regards, Richard | |||||
| 6358.4 | IPMT case is now created, please get added to the contact list. | AZUR::DURIF | Wed Aug 16 1995 10:44 | 5 | |
Hi Richard, Case CFS.31347 is now created we go on in IPMT. Benoit | |||||