| > If a connexion failed , does it send a trap to netview ?
It can if enabled. You have to enable port traps from the DECconcentrator's
console or though Netview SNMP commands to the DECconcentrator's private
ELAN Vendor MIB. (And, of course, you'll also have to enter the IP address
of the Netview station into the DECconcentrator using the setup port.)
> If a DECconcentrator failed , does the other concentrator
> send a trap to netview about link status changement?
Yes, see attachments.
> Where can i find a complete documentation about traps sent by our
> network equipments ?
By looking at the complete set of documentation for out network equipment. ;-)
(Actually, I think documentation on the DECconcentrator's port trap is pretty
hard to find. A description will be put into the next versio of the ELAN
Vendor MIB.)
-Shawn
---- excerpt from a private mail message ----
---- mail headers removed ----
>According to your notes 3502.3, the enterprise specific trap is 1 (i.e.
>portTrap) does it mean, DC900MX only reports there is a port state change, but
>cannot tell whether the port becomes active or standby, or even wraped..
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.
>Reason is customer will implment Polycenter Netivew (Digital Unix) to monitor
>their FDDI network (using DC900MX as the 'core' component), they have dual-home
>devices and SAS device, they would like to be alerted when there is a failover
>from from standby port to active port. Since DC900MX only reports link up/down
>generic trap which cannot help us to report the state change of each devices
>attached to the M-ports of the DC900MX.
I think the portTrap does what they want.
>Will this 'portTrap' report traps variables so that we can identify whether it is
>a active->standby, or standby->active ?
Yes, as explained above (hopefully ;-)
Hope this helps. This feature really should have made it into the products
documentation. I don't know why it's not in there.
Feel free to let know if there's anything else I can help you with on this.
I'm no FDDI expert, but I can find people who are.
Regards,
-Shawn
|