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

Conference npss::gigaswitch

Title:GIGAswitch
Notice:GIGAswitch/FDDI Jan 97 BL3.1 914.0 documentation 412.1ion 412.1
Moderator:NPSS::MDLYONS
Created:Wed Jul 29 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:995
Total number of notes:4519

919.0. "Dual-homing failover to same GIGAswitch" by SCASS1::DAVIES (Mark, NPB Sales, Dallas,TX) Wed Jan 29 1997 21:37

    I have looked thru other notes for this scenario, so I will enter here
    for an answer.
    
    My customer wants to dual-home his Alpha's (via DEC PCI FDDI DAS
    adapters) to different FGL-4 cards in a GIGAswitch.
    
    If one of the FGL-4 fails, how long will it take for the transition 
    to occur to the other link?
    
    Will this take 30-45 seconds because of spanning tree?
    
    Or will it take less time?
    
    Thanks,
    
    Mark
    
T.RTitleUserPersonal
Name
DateLines
919.1Depends on which port its connected to...NPSS::RLEBLANCThu Jan 30 1997 11:5512
    
    If the Ports on the FGL4's are just SAS then yes it will take 30 - 45
    seconds. If the ports are changed via snmp to M-ports then it should
    take a couple of seconds. The M-port setup to take a couple of seconds
    depends how many nodes are learned to the entire GIGAswitch/FDDI system. 
    
    Also if you have V3.10 of FGL2 or FGL4 firmware its a little quicker
    for GIGAswitchen with learned addresses greater than 2,000.
    
    
    							Rene'
    
919.2AMCFAC::RABAHYdtn 471-5160, outside 1-810-347-5160Thu Jan 30 1997 13:389
Change the ports to M or it isn't proper dual homing.  S-AB-S is a wrapped ring
and they won't get full duplex.  Also, the S-AB-S configuration, with both S
ports on the GIGAswitch/FDDI means spanning tree will detect a loop and put a
connection into standby.  If the standby connection fails then there will be no
delay.  On the other hand, if the active connection fails then the spanning tree
will be recalculated with attendent delays.

If this is a VMScluster interconnect then raise the values of RECNXINTERVAL and
SHADOW_MBR_TMO and maybe SHADOW_SYS_TMO appropriately.
919.3AMCFAC::RABAHYdtn 471-5160, outside 1-810-347-5160Thu Jan 30 1997 13:5423
Also, sell 'em another GIGAswitch/FDDI as they seem especially interested in
high availability.  One GIGAswitch/FDDI is a single point of failure for the
following reasons;

	1 CBS (might want to check with MCS for local spare availability)
	1 CLK (check for local spare availability)
	1 backplane (unlikely to fail but still ...)
	1 environment (if disaster tolerance is important to them otherwise 	
		might be ok if disaster recovery is good enough)
	1 firmware upgrade requires planned downtime (might be ok if they aren't
			true continuous computing)

They have configured in the redundant power/fans and SCP, yes?

Have they uplifted and extented the hardware support contract to 7x24
multi-year?  Don't forget to do extend the software support contract too. 
They'll also need to get onto the software update service.

They have considered how to manage it, yes?  ClearVision multichassi manager is
the state of the art.  However, it does nothing as far as alarming goes. 
POLYCENTER Console Manager might be a good idea for the OBM async port.  Also, a
good strategy for recording utilitization and then forecasting to stay ahead of
need is required.
919.4NPSS::MDLYONSMichael D. Lyons DTN 226-6943Thu Jan 30 1997 14:264
    ...see the keyword failover-configurations or note 868.7 for
    information.
    
    MDL