|
The variables you have mentioned are very low level in the FDDI.
I suspect that you would prefer more high level info, but I don't
want to type it in until I am sure what you would like!
Could you dexribe the types of problems that the user will want to
see, and then we can spend some time on the specifics. For instance,
I assume that you will want to know if the ring wraps, or if a
port goes down. Do you have any other idea of what things you'd
like to see?
If you really want to go done into the bowels of the FDDI we can
do that, but my suspicion is that you don't need or want that much
detail.
|
| Well, in this case the customer has few, or I would say none, specific
requirements. The questions are:
- Which are the most usual and important problems to monitor (you
know, those 5% that happen 95% of the times) ?
- How do they map to MIB variables ?
My suggestions (probably incomplete):
- The ring is not working at all or there is a loss of connectivity
between concentrators
- There is connectivity in the ring but a potentially serious failure:
- The ring wraps
- ???
- One of the nodes, or a bridge connected to a concentrator port has
lost connectivity
- One of the nodes, or a bridge connected to a concentrator port is not
working properly, or has a bad comms performance
- ???
All they want is to be sure that the operators will NOTICE that
something is wrong, as quickly as possible, and in the simplest
possible way, so they can report it somebody knowledgeable.
As an example, for DECnet nodes they are alarming on loss of
connectivity, send failures in the ethernet lines, area connectivity
and changes of state of WAN circuit and lines.
Regards
Luis
|