Conference netcad::hub_mgnt

    
    What are you trying to protect against? 
    
    If it is a power failure of the entire hub, then connection of the OBR
    to either of the end concentrators will work just fine. If it is
    failure of a module alone, the hub may wrap around the failure, and the 
    OBR would not be needed. 
    
    Can you supply some more detail as to the type of fault you want to 
    protect against? 

 in the case of more than one  hub failing , there could be split of the ring 
into several rings that cannot see each other : 

this is exactly what the customer wants to avoid , so the reason each
hub ( there should be 13 with each with 3 fddi modules ) is going to 
be connected to an optical bypass relay ,

so they can maintain the whole ring in operation ( this is the primary 
goal of the customer : all active hubs should always see the other active hubs,
there should be no disruption of operation of traffic , there should be 
no splitting in multiple rings , they want to achieve 24/24 hours availability ) 


  as far as i know from the last Network university , we support at the 
moment only the dual-ring configuration inside a Dechub with fddi modules : 
so in this case , we have  this scheme :   a-1-2-3-B   for each hub ;

( 1-2-3 are the 3 fddi modules in the hub ) 

if we connect 1 to the OBR :    if the hub fails , so all the modules fail 
				and the OBR is activated : OK for us 


			       if module 1 fails , the OBR should activate
	its relay function , but B is going to wrap :   is this authorised
	configuration ????

				if module 3 fails , the OBR is not going 
	to activate , and A is going to wrap  :  this is normal 


	thanks for enlightening us about this kind of configuration 
	it is of the upmost importance for the customer ;

	regards 	PJ

    
    The use of the OBR across the entire hub will not do what your customer 
    wants it to do. Let me explain it this way: If the OBR was not there,
    and module 1 fails, module 2 will wrap, and modules 2 and 3 
    will remain connected to the rest of the ring. When the OBR is added
    module 2 still wraps, but the toggling of the OBR means that the entire
    hub will be bypassed. Modules 2 and 3 will be connected together in the 
    backplane, but they will only be talking to themselves. 
    (I think you already understand this, but I want to be sure). 
    
    The only other case I would add to your list is that if module 2
    fails, the ring will wrap at both A and B. This has nothing to do with
    the OBR, I'm just being complete. 
    

	your explanation is very clear about using an OBR with the 
dual-ring configuration inside the hub .

	now can i justly guess that if we configure a tree inside
the dechub with the next release of firmware we will have the following
behaviour with the OBR ?

	A - B - 1 - 2 - 3 

with 1 being the root of the tree , and being attached to the dual-ring :


	I - if either 2 or 3 fails the dual-ring will be unaffected 

	J - if 1 fails , the OBR will activate , and 2 and 3 are a separate 
	ring

	K - if the whole hub fails , the OBR will activate 


from what i understand from FDDI operation , the advantage of this tree
configuration is that there should be no risk of splitting the global
ring into multiple rings , I.E. from hubs to hubs , and so , with the OBR ,
 the global ring will always be operating ;

 of course the penalty is that in case of J 
there is going to be a separate ring inside the hub .
now the customer intends to do first-level maintenance , so he will change
the failed FDDI module very quickly .

	thanks again for your support ; 

	regards 	PJ

    
    Yes, your guesses are correct!
    
    
    
    

    
    	Does somebody could help me to configure an optical bypass or tell 
    me where can I find information about it ?
    
    	
    
    						thanks ...