[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::fddi

Title:FDDI - The Next Generation
Moderator:NETCAD::STEFANI
Created:Thu Apr 27 1989
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2259
Total number of notes:8590

1208.0. "no Standby state for dual homing?" by ZUR01::HOTZ (Gregor; MCS, NaC Support, Schweiz) Thu Jan 13 1994 12:21

      I've two customers who would like to positivly identify and
      monitor the passive link in a dualhomed configuration by
      monitoring a single attribute with DECmcc. (MDF-Cluster)

      (Attribute descriptions below from Polycenter Extended LAN Manager
      AM for VMS, Concentrator AM Use, Appendix A. On CD)

      Monitoring Phy Port State = Watching (as discussed in previous
      entries) doesn't work because it goes to Failed every 50 seconds
      for a second or so and then back to Watching. The Watching state
      also has other meanings then Standby, (e.g. LCT failure, LEM
      exceeded, illegal topology) and the manual also says, it has
      failed at least once!

      Why, with a clean standby link?

      Ok (no, not really), so monitor Reject Reason = Standby. But now,
      if the active port failes, the standby link becomes Reject Reason
      = No Reason. This means, "the physical port is inizializing. This
      value is cleared when the physical port enters the In Use state."
      However, this attribute is never cleared.

      So, this must me a bug. But, how could the value of a cleard value
      be checked anyway? 

      Whats missing is a stable attribute: Phy Port State = Standby.

      or am I missing something? 

      Mist!   greg.
T.RTitleUserPersonal
Name		DateLines
1208.1KONING::KONINGPaul Koning, B-16504Thu Jan 13 1994 15:195
The FDDI protocol does not make it possible to have a stable state = standby.
But the reject reason should work.  If it does not work reliably, that sounds
like a bug.

	paul
1208.2NPSS::WADENetwork Systems SupportThu Jan 13 1994 16:4921
    
    I assume you're talking about the DEFCN-DEFEB connection and you have
    the DEFEB dual-homed to two DEFCNs.  
    
    If the customer wants to know when the active link has failed why not use 
    the change of rule (*,* or "in use", *) on the active link phy port state
    attribute?  This should  have changed from "in use" to a failed state.
     
    If they want to know that the backup link is still "ready and able" they 
    can use the change of rule (*,* or "standby",*) on the backup phy port 
    reject reason  attribute.  
    
    Hope this helps, Bill
1208.3NPSS::WADENetwork Systems SupportThu Jan 13 1994 16:553
    And, from DECmcc I've always seen reject reason = "no reason" on an
    active port.  If this is a bug you'll most likely have to live with it
    given that there are no engineers supporting the DECmcc ELM product.
1208.4dualhoming => illegal topology, state => reject reason :-)) => :-((ZUR01::HOTZGregor; MCS, NaC Support, SchweizTue Jan 18 1994 12:1745
re .1, 

Monitoring an M port with a loopback connector (M to M is illegal), the
Reject Reason is Topology Rules, and the Phy Port State also goes from
Watching to Failed and back, once in a while, as a Standby port does. So
it seems that Dualhoming is an allowed case of an Illegal Topology?
Would an LCT failure or LEM threshold exceeded do the same? I can't
simulate that.



re .2

in a network with many concentrators and bridges (28 ports, 2 ports
standby and more to come), you don't want do have one rule for every
port. Too much load on the management station, too complicated, and if a
link gets connected to another port, the rules must get changed. Every
half day, some rule fires due to watching / failed / watching
transitions. We wildcard on the phy ports and the phy port state on 6
concentrators and 2 bridges. 

CHANGE_OF (conc floor1 PHY PORT * PHY PORT STATE, *,*), at every = 00:00:57) 

OK, so we'll monitor the Reject Reason.



re .3

it's not only MCC who sees Reject Reason = No Reason on a In Use port. If you
look at it through the OBM menu, you see the same. So, it's a firmware issue.
But, maybe the firmware is right, and the description in the MCC manual is
wrong?

MCC Access Module Use(r Manual): Appendix A.

No Reason - the physical port is initializing. This value is cleared
            when the physical port enters the In Use state.

Maybe: Reject Reason = Initializing, later Reject Reason = In Use?
(cleard = "", or , or "cleared", or ???)

greg.

p.s, will the DEChub 900 FDDI modules behave the same way?
1208.5KONING::KONINGPaul Koning, B-16504Tue Jan 18 1994 13:5325
I'd expect new products to behave the same way.

The reason you see the state cycling every 50 seconds is that the FDDI protocol
does not provide any way to avoid this.  More precisely, the only steady states
are Off and Active.  A rejected or standby connection obviously cannot go
Active.  We don't want it to go Off either, because then we would have no way
to tell that the problem has been fixed (in the case of a rejection) and we
would not be monitoring the quality of the standby link (in the case of standby).
Neither is acceptable.  Therefore we put the link in what amounts to an extended
link test, but that test is limited by the standard to (by default) 50 seconds.
That's where the cycling comes from.

Therefore, any rule that triggers on this state cycling is not valid in 
practice.

As for the description of Reject Reason, it sounds like the MCC book is wrong.
The FDDI architecture (which is the defining document) states:

	Reject Reason: the reason why the PHY port is in the Failed or
		Watch state.  Not meaningful when the PHY Port is in some
		other state.

and indeed what the firmware implements conforms to that rule.

	paul