| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 6162.1 | Help Please........ | SNOTTY::BARRY | Ploppy Sir, Son of Ploppy | Tue Nov 08 1994 04:40 | 5 |
| Anyone's help greatly appreciated.........
This is a problem with an MCC platform monitoring a CUSTOMER network !!
Barry
|
| 6162.2 | maybe a ucx pb ? | PRSSOS::BONNAFE | Guy BONNAFE - CSC France | Tue Nov 08 1994 09:11 | 11 |
|
It looks like a UCX pb. "%SYSTEM-F-IVADDR, invalid media address"
is most of the time due to a dupplicate address on the network. Is your
UCX ok ? are you able to ftp or telnet somewhere ? Can you ping your
DECmcc station from somewhere ?
What do you mean by :
>>> I have noticed that the BIND database server and its associated entries
>>> have disappeared from UCX ???
Are you still able to communicate with your bind server ? Ping it ?
Guy.
|
| 6162.3 | Further questions | SNOTTY::BARRY | Ploppy Sir, Son of Ploppy | Wed Nov 09 1994 10:25 | 22 |
| Hi Guy,
What I meant by that statement was that the bind database that was previously
present in UCX is now no longer there........
This is because I am now not able to ping the bind server and in fact, I cannot
ping anything !!
It is apparent now that there is a combination of problems with this box,
mostly coming back to fact that no TCPIP communication is being allowed(
probably a UCX config problem).
What I really need to know is how this TCPIP_SINK is actually started,
does it get started by the MCC_STARTUP_BMS procedure or is it a special
case ??
If I know this then when I have solved the IP communication problem, I
will be able to assess whether I have an MCC related problem aswell.
Thanks in advance
Barry
|
| 6162.4 | | PRSSOS::BONNAFE | Guy BONNAFE - CSC France | Wed Nov 09 1994 12:16 | 19 |
|
The MCC_TCPIP_SINK process is created when a GETEVENT command is
issued ( on SNMP entities ). You can generate a GETEVENT directive
either automatically by creating/enabling an alarm rule or a notify
request, or manually by issuing a getevent command through the FCL
interface.
In the second case, the process disappears as soon as the getevent
command is completed ( receipt of an snmp trap for example ). In the
first case, ALARMS FM or NOTIFICATION FM post a new getevent
directive in such a way that a data structure is always available
for the next event. This way, the MCC_TCPIP_SINK process looks like
a permanent process.
This is fully ( and better ) documented in the TCP/IP SNMP AM
documentation.
Guy.
|
| 6162.5 | Cheers..... | SNOTTY::BARRY | Ploppy Sir, Son of Ploppy | Thu Nov 10 1994 05:13 | 13 |
| Guy,
Thanks for that, it makes it a lot clearer......
My next question is, presuming that I have got a UCX problem in that this
platform cannot talk to anything using IP, could this affect the integrity
of the TCPIP SINK ??
Would this UCX problem mean that the TCPIP SINK cannot run and therefore
the process would never be present.........OR would the TCPIP SINK run
but just never work properly ??
Barry
|
| 6162.6 | | PRSSOS::BONNAFE | Guy BONNAFE - CSC France | Mon Nov 14 1994 04:55 | 11 |
|
Don't know. When the tcpip sink starts, it tries to open 2 sockets
on the ucx driver ( check with $ucx show device_socket command ).
If for one reason ucx doesn't work properly and these sockets cannot
be created, I assume that the process just exits ( or exits when
it tries to actually use its sockets ). Should be answered by
someone owning the code.
By the way, my advice is to have ip/snmp up and running first, and
then to test mcc features. Even this way it won't be so easy ...
Guy.
|
| 6162.7 | Good News | SNOTTY::BARRY | Ploppy Sir, Son of Ploppy | Mon Nov 14 1994 05:50 | 10 |
| The problem is solved.
UCX had been "tampered" with and was not working at all. Once
I configured UCX properly I managed to talk using IP and then
, miraculously, the TCPIP SINK sprung into life. Looks like
all the problems were caused by the UCX configuration settings !!
Thanks for your help and advice.
Barry Howard
|