Conference 7.286::fddi

    I don't recognize SNMP terminology, which unfortunately seems to have
    no connection to FDDI standard terminology.  In any case, if "linkdown"
    means MAC down, the clearly you can't send it since there's nothing to
    send it with.  (This assumes no out of band management.  As soon as out
    of band management is added, that argument goes away.)  On the other
    hand, if "linkdown" means PHY down, then on any station other than a
    SAS this does NOT mean communication is down, and therefore such an
    event SHOULD be implemented and should be sent.
    
    So which of these two is "linkdown"?  Or hasn't SNMP recognized that
    there are two things that can  go down separately?
    
    	paul

There are a few issues here:

Using Traps for Network Management
-----------------------------------
    Traps are frowned upon by the snmp community.  It's felt that
    one can't base effective network management on an unreliable service.
    (Traps are not guaranteed to be delivered.)  The preferred method is
    polling.  You can poll the fddi mib object snmpFddiPortConnectState to
    detect ports going up and down.

    (Traps bad.  Polling good.  ;-)

If You Don't Believe This and Want to Use Traps Anyway
------------------------------------------------------
    One of our bigger customer came to the same conclusion as you.
    NASA wanted to know when fddi ports went up and down.  They didn't
    care about the fact the traps are unreliable, and they have money.
    We will support enterprise specific port traps in the 3.2 release
    level of the concentrator.  I'll attached part of the release notes 
    in the next reply.

    (The people who brought you the fddi mib could have defined port
    traps in the mib.  They purposely didn't.  See above about
    "unreliable service".  ;-)

Using linkUp/linkDown Traps for FDDI Ports 
------------------------------------------
    A link is associated with an interface.  If you have an interface, then
    you must support the mib-ii interface group.  This group contains objects
    like physical address, octets received, octets transmitted, and a slew of
    other like these.  

    An fddi port has no mac.  Therefore, it is not an interface.  Therefore,
    it is not a link.  Therefore, since a port is not a link, no linkUp/
    linkDown trap should be supported when a port goes up or down.

    linkUp/linkDown traps are not appropriate for ports.

						-Shawn

>                 DECconcentrator 500 Operational Firmware V3.2 
>                               Release Notes
>
>
>This release of DECconcentrator 500 firmware contains the following
>functionality which is new from V3.1.
>
> o  Support for SNMP FDDI "port traps" have been added.
>    SNMP Port traps are implemented as an enterprise specific trap 1.
>
>    A "port trap" is sent whenever the SMT state changes provided there is
>    at least one trap address in the table. The value of the RFC 1285 
>    MIB Object snmpFddiPortConnectState is sent along with the trap.  This
>    value can be:
>       disabled(1),
>       connecting(2),
>       standby(3),
>       active(4) 
>    For more information about this object please refer to the MIB (RFC 1285)
>    and the SMT spec.
>        

Note:  The snmpFddiPortConnectState object is returned in the var-bind-list
       (aka 'interesting info') of the trap message.

Thanks for your replies.

Re .2

The major limitation with polling is that for it to be effective you have to 
poll frequently - if you poll every 15mins, and something crashes 1min after the
last poll, then it is 14mins before you detect it - and the telephone has rung
long before then!! If you decrease the polling interval then you get the problem
of either generating excessive network traffic just to poll your network, or the
problem of your network mangement station grinding to a halt. Even with a small
FDDI ring you can easily have 18 ports to poll (I would like to poll unused 
ports to detect anyone connecting to the ring). MCC would soon grind to a halt 
if it has to poll large numbers of ports, plus all the other phaseIV/V, SNMP and
LAN management that it is doing. Our DECnet network is monitored purely by 
events - and these are just as 'unreliable' as SNMP traps yet we don't have many
problems with missed events. The ideal solution is to rely on traps/events for 
real-time events, and to poll every 30mins/1hour as a sanity measure to make 
sure you didn't miss anything.

Re .3

When is V3.2 available?

Thanks

Ian

3.2 will FRS in December.

You probably know this, but just in case,  polling all of the ports on a 
concentrator can be done in a single SNMP message.

						-Shawn

    
    An additional note about port traps...these (or any traps) will NOT
    be sent without a management card.  
    
    Pam