| >Does such TRAP-TYPE mib definition available on the Net, and where?
I doubt it.
>(ie. I'm looking for
> FDDI Concentrator specific Port Trap with variable list an Status syntaxe :
> -Specific trap 1
> - variable :fddimibPORTEntry.fddimibPORTConnectState.1.6 (Integer): 2
> where state seems to be disabled(1),
> connecting(2),
> standby(3),
> active(4)
decConcentratorPortTrap TRAP-TYPE
ENTERPRISE { elanext }
VARIABLES { fddimibPORTConnectState }
DESCRIPTION
""
::= 1
This trap is strange in that it is an enterprise specific trap which
references an object in the fddi mib (rfc1512). I'm not sure how
Netview et. al. deals with this. Maybe you could let me know.
This issue is what's keeping the TRAP-TYPE definition from being included
in the elan vendor MIB.
Attached is info which might help to understand the DESCRIPTION clause.
-Shawn
One trap - the DECconcentrator900 PortTrap which is denoted "enterprise
specific 1" is used to indicate that a port state change occurred. Inside
the trap is a variable, and the value of that variable.
The variable is always "fddimibPORTConnectState". This variable is "instanced"
by the fddimibPORTSMTIndex and fddimibPORTIndex. The fddimibPORTSMTIndex is
always 1 in our implementation. The fddimibPORTIndex portion of the instance
indicates the number of the port that underwent the state change. So, for
example, a trap might contain the variable fddimibPORTConnectState.1.5, where
fddimibPORTSMTIndex is 1 and fddimibPORTIndex is 5. This indicates that
port 5 underwent a state change.
The value is the current value of fddimibPORTConnectState. It can have the
values disabled(1), connecting(2), standby(3), or active(4). You can refer
to the FDDI MIB for more detail, but two important state changes are:
active to connecting, and
connecting to active.
When you plug insert a station onto the FDDI ring (plug in) the connect state
goes from 'connecting' to 'active'. When you remove the station from the
ring (unplug) the state goes from 'active' to 'connecting'. (The term
'connecting' means 'trying to connect'. I think it's misleading, buy hey,
I didn't write the standard.)
Two other state changes are:
standby to connecting to active,
and active to standby.
When a dual-home failover occurs, the state goes from standby to connecting,
and then to active. (Actually, I'm not sure how long it stays in the
connecting state.) I'd expect to see a trap for both of these state changes.
Likewise, a trap is issued when going from active back to standby.
I'd have to do a little research to find out what happens when the ring
wraps. I don't think fddimibPORTConnectState reflects wrapping. Let me
know if you'd like me to look into it.
So, in summary, from the portTrap you can deduce:
- when a port state change occurs,
- the port which is undergoing the state change, and
- the new connect state of the port.
|