Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!ncar!boulder!daemon
From: jnd@sms.com (Jose Nabielsky)
Newsgroups: comp.dcom.sys.cisco
Subject: FDDI Dual-Homing SAS Attachments
Message-ID: <29820@boulder.Colorado.EDU>
Date: 15 Nov 90 21:13:20 GMT
Sender: daemon@boulder.Colorado.EDU
Lines: 41



Do cisco FDDI Routers operate correctly as *dual-homed* SAS stations?
(Some people call this in "cleave" mode.)  (For "Why bother?," read on.)

We are dual-homing the FDDI routers to DAS concentrators, as follows:

	1.	The PHY_B interface connected to a PHY_M port off 
		a PRIMARY DAS concentrator.

	2.	The PHY_A interface connected to a PHY_M port off
		a SECONDARY DAS concentrator.  (This provides path redundancy.)

The behavior we *expect* from the dual-homed interface is as follows:

	1.	The PHY_B interface provides the default attachment to the
		FDDI backbone (through the PRIMARY DAS Concentrator).

	2.	The PHY_A interface provides a hot standby attachment
		(through the SECONDARY DAS Concentrator).
		
	3.	Upon detecting a hardware- or software-induced PHY_B
		disconnect, PHY_A automatically provides restoral attachment
		(through the SECONDARY DAS Concentrator).

	4.	When path continuity is restored to the PHY_B interface,
		the router reverts to its default PHY_B attachment.

(If you have not figured out this yet, our motivation is to avoid an
informal, physical-ring wiring topology, and implement instead a formal,
physical-star wiring topology on this FDDI Backbone.)

Not all routers need be dual-homed.  Those that are not, simply will
attach to the PRIMARY DAS Concentrator through the PHY_B interface, and
will shutdown the PHY_A interface (through the command interface).

Has any of you implemented the dual-homed attachment scheme with (or without)
cisco routers?  Does this scheme work TODAY under release 8.1(xx)? Any gotchas?

-Jose
 jnd@sms.com