Conference 7.286::fddi

	The PHY will transtion to FAILED every 50 secs and then back
	to WATCH if in stand by.

	There is no problem with this.  It's normal.

	Luc

    For those of you who saw the previous .2 forget it.  I just did some
    testing and .1 is correct, although he doesn't need me to say that to
    know that he is.
    
    Some comments:
    
    The transition through FAILED is very fast.  I had DECmcc alarms setup
    to poll ever 30 sec for days looking for a phy port state change on
    both phy port 1 and 2 while dual homed and the alarm never triggered.  
    
    I just completed a test with DECmcc and a dual homed 620 with 
    a command file containing ~500 lines with this command:   
    
    	"show bridge bridge.site2-620 phy port 1 phy port state"
                        
    
    I got one FAILED returned and all the rest WATCHING.
    

Thanks for the fast response. It seems the customer is in fact testing the wrong
states in MCC. That was all I wanted to know.

The reason he is seeing the problem intermittantly is the rule he has generated
triggers every 5 minutes and tests for anything NOT EQUAL to the WATCHING state.
When this time corresponds to the time the transition from "watch" to "failed"
takes place MCC sets the ICON map to alert of the failed status.

In fact he should be testing for the BROKEN state. I believe the customer (and
I will verify this) is trying to insure the ring to fail over to is functional
in case failover is required, rather than testing the functional (B) port in use.



I would in fact still like to get some documentation on how this works if you
would be kind enough to point me in the right direction for resources. I see
there is some information in the specification John Tobin has and also some
information on the ability in the Digital Technical Journal. Not much detail
there though. Any help would be appreciated.

Thanks Again.

Ralph Blackmer  IISG Netsupport

This sounds ugly.  FAILED should mean what it says; if the PHY goes through
an internally similar or equivalent state as a side-effect of being in
WATCH, that's fine, but such an artifact should not be exposed to the
network manager.

	paul

I agree. The "FAILED" state should mean failed. I am not sure that when the code
was developed, this configuration was considered "with the use of MCC and the
rules the customer base might generate".

On the other hand there must be a way of monitoring the standby port for changes
in status and MCC sees the "WATCHING" transition to "FAILED" and with the rule
this customer has in place, the ICON map triggers and event.

This is why I was after additional information on the functionality. If this
configuration will be used much in the future, and my guess is it will be for
obvious redendancy reasons, there should be a means of monitoring the ability
of the standby port for proper failover if necessary. I would imagine this might
require a change in MCC rather than the code for the concentrators or bridges.

That is up to the development people though.

I will pass the info along to DOW Chemical and once again thanks for the
direction.

Ralph Blackmer  IISG Netsupport

The standby port is continuously monitored: it's being subjected to a 50-second
link confidence test.  (That's where the 50 second cycle time come from.)
If that test fails, I'd very definitely expect to see a "failed" state.
My objection was only on the transient state that occurs in this 50 second
cycle under normal (healthy link) conditions.

	paul

    
    It looks like the customer could alarm on a change in reject reason as
    that remains at "standby" whether the state shows "watching" or
    "failed" while in the dual homing config -
    
    
show bridge bridge.site2-620 phy port 1 ALL STATUS

Bridge LOCAL_NS:.bridge.site2-620 PHY Port 1 
AT  7-JAN-1993 22:37:40 Status

Examination of attributes shows:
                       Break State Flag = False
                         Phy Port State = Watching
                 Neighbor Phy Port Type = Master
                          Reject Reason = Standby
              Estimated Link Error Rate = 10
    
show bridge bridge.site2-620 phy port 1 ALL STATUS

Bridge LOCAL_NS:.bridge.site2-620 PHY Port 1 
AT  7-JAN-1993 22:37:40 Status

Examination of attributes shows:
                       Break State Flag = False
                         Phy Port State = Failed
                 Neighbor Phy Port Type = Master
                          Reject Reason = Standby
              Estimated Link Error Rate = 10
    
    

    Hi,
    
    Just to wake this note up again. Is it possible to stop this alarm
    under DECelms V1.1 ? Is it possible to modify the alarm as in the
    previous mnote ?
    
    Sorry about this but I have only the  V1.0 documentation and the
    customer has v1.1. Any hints are greatly appreciated.
    
    Thanks,
    
    Alan.

    Answered this myself. 
    
    DECelms can only turn on or off the recepit of alarm messages for the
    device, line 1, line 2 and the physical ports. V1.1 documentation is
    identical to V1.0.
    
    Alan.