Conference netcad::hub_mgnt

    >Also, if a DECswitch 900EF has been previously configured via hubwatch
    >what happens to that configuration if the DECswitch becomes defective?
    >Will the original configuration be retained when the defective
    >DECswitch is replaced?
          
    It depends on how the defective DECswitch behavior is viewed from
    the MAM's perspective. If the defective DECswitch behaved as if it
    had been unplugged or removed from the hub while the MAM was powered
    up then the config would probably be lost. If the defective DECswitch
    behaved such that some internal function to the DECswitch was broken,
    then possibly the MAM wouldn't see it, and the config might possibly
    be remembered by the MAM. For example if the DECswitch crashed, the
    config would probably be lost. If the DECswitch lost an unused port
    which happened not to be used by the config, the config would probably
    not be lost.
    
    Bob

Just a wording thing... HUBwatch does not maintain any sort of database.
Everything it displays it gets (at the time you ask for it) from the device
through SNMP.

As mentioned in earlier notes, a future version of HUBwatch will have a new
backup, restore, and copy facility.  This application will allow network
managers to do backups on their SNMP network devices, in much the same way
system managers do backups on their disks.  Look for this new feature sometime
this year, after V4.0.

Tom Hood
HUBwatch

In the next release of the MAM firmware, something we are calling auto healing
will be available.  What this does is to take a snapshot of devices connected to
all LAN segments in the hub.  The snapshots are taken automatically whenever
there is a change to any LAN connection (via HUBwatch, for example) or when the
operational state of a device changes.  In the event that a device is removed or
goes to sleep (i.e. becomes inactive for any number of reasons) the
configuration will be remembered so that when the device becomes operational
again or the device is replaced with a device of the same type and becomes
operational, all LAN connections to that device will be restored.  If a device
of a different type appears in that slot, any information about what was in that
slot is lost.

For FDDI LAN segments, the MAM will "patch around" the faulty/removed device (or
more accurately, the segment is "healed" so that other devices on that segment
continue to communicate to one another).  We are hoping to restore Ethernet
connections also, but our commitment right now is to get this working for FDDI
LAN segments only (rings and trees).

FYI, the ability to heal LAN segments will be selectable (that is, you will be
able to turn it on or off from a radio button on the HUBwatch LAN Interconnect
screen).

...Roger...

    THAT sounds like a winner - auto heal!!  Is that likely with V4.1 etc
    or V4.0?  (or V5?) (grin),
    
    ttfn,j
    

V4.0 of HUBwatch and the MAM firmware (both coming out shortly).

...Roger...

    Thanks for the respones. It is appreciated.
    
    Jim W

    
    I need to set some expectations for autohealing. It is by design a 
    recovery mechanism with a slow response time. If you have a requirement 
    for a response time of under 5 seconds, either suggest that they build
    a dual ring, or, call us for more details. 
    
    We expect to be documenting the new FDDI features in another
    configuration memo, sometime before we ship this wave. 

in a customer situation , we did try the following as they wanted 
to evaluate the dechub900 behaviour in case of wrapping  

  
A		  B
-- C1 -C2 -C3 - Switch -- DECHUB900
		  !
	          !
	      -------- PC /HUbwatch 


each decconcentrator900MX has its Ip address 

we pinged the C1 continuously from the PC 

we removed ( hot-swap ) the C2 , the ping ceased working --->
lots of timeout , and it took up to 30 seconds
to see again the C1 , as auto-healing had restored the backplane link 		

NB : there was NO connection between a and B ports outside the dechub900
( so that they wrap ) 
and the LIGO configuration was :
C1 : A front , B back
C2 : A back , B back
C3 : A back , B back 
Switch : A back , B front 


well , we were happily surprised as we werent sure it was going to heal 

now , what we did afterward , is re-insert the c2 module , then 
apply the A back , B back  LIGO , then connect to the FDDI backplane 

and now bad suprise : it took as much time for the PC to recover the ping to C1

is this normal behaviour , or is it going to be shorter to reinsert the fddi 
module after hot-swap ???

thanks for your answers 

PS : Tom  and Roger , your replies concerning backup/restore and auto-heal were
to my eyes like a Mozart concerto to my ears : pure delight ! 
thanks for keeping Hubwatch even better , and from a customer quote , 
"it s so easy and coherent to use ! one of the best tool i ve ever used "

	Pierre-Jean,

	I am sorry to enter a sour note, but the behavior you report
	is expected in this case and is not likely to change. The short
	answer is that when an auto-healing operation involves a switch
	you will see the switch's FDDI port go into pre-forwarding mode
	which takes 30 seconds. Traffic on the FDDI ring itself will not
	have to wait for this, just ethernet<->FDDI. The reason the 
	switch does this is that its interface has changed (it is no
	longer connected to the same neighbor).

	Although your diagram shows that C2 was in between C1 and C3 
	this is not how the backplane connections were actually made,
	assuming C1 = slot 1 C2 = slot 2 etc.

A		  B
-- C1 -C2 -C3 - Switch -- DECHUB900
		  !
	          !
	      -------- PC /HUbwatch 


	The actual backplane connections probably looked like this:
A		  B
-- C1 -C3 -C2 - Switch -- DECHUB900
		  !
	          !
	      -------- PC /HUbwatch 


	So when you removed C2, the MAM needed to connect the switch to
	C3; when its FDDI port connection was changed, the switch went
	into pre-forwarding. If you watched the front panel you will 
	see the interface LED for port #1 start flashing.

	The FDDI ring was restored within a few seconds, but you 
	have to wait for the ethernet<-->FDDI forwarding for your PC to 
	start seeing pings. If you had removed C3 from the original
	configuration, there wouldn't be the same delay since C3 was not
	connected to the switch. The only delay would be that of the 
	auto-healing connection changes, on the order of a few seconds.


>now , what we did afterward , is re-insert the c2 module , then 
>apply the A back , B back  LIGO , then connect to the FDDI backplane 
	
	This is what Roger is talking about: the new version
	will put the LIGO back and re-connect C2 into the ring automagically.

>and now bad suprise : it took as much time for the PC to recover the ping to C1
>is this normal behaviour , or is it going to be shorter to reinsert the fddi 
>module after hot-swap ???

	When you re-insert C2, it will be put back into the ring in
	the same place as before - next to the switch. So Yes, there will
	be the same 30 second delay when C2 is replaced and is re-connected to 
	the switch.


	-Mike

thanks a lot for your reply , Michael 

everything is as clear as EVIAN water 


PJ

Re .9:

>							.....The short
>	answer is that when an auto-healing operation involves a switch
>	you will see the switch's FDDI port go into pre-forwarding mode
>	which takes 30 seconds. Traffic on the FDDI ring itself will not
>	have to wait for this, just ethernet<->FDDI. The reason the 
>	switch does this is that its interface has changed (it is no
>	longer connected to the same neighbor).

Drat!

Some questions about the pre-forwarding on change of interface:

1. Does this same behavior apply to an interruption of a connection via one of
the front-panel A or B ports, in a dual-attached connection to a dual 
counter-rotating trunk?

2. Does it apply to an interruption of a connection via one of the front A or 
B ports in a dual-homed connection to an M port?

3. Why is this done?  (The drawbacks seem obvious; the benefit or necessity 
doesn't.)

I'd appreciate any help, because in a customer's network it seems to have been 
the cause of lost LAT and cluster connections on several occasions.  If the 
described behavior applies only to a 900-series switch's backplane FDDI links, 
we'll probably switch those connections in some cases to front-panel 
connections, and perhaps to dual-homed connections.


Malcolm

    
    If a bridge is dual homed it will not go out of the forwarding state
    when the backup connections kicks in. This is also true when a 
    wrap occurs. 
    
    If a single attach connection is out for approximately 5 seconds
    (I'm in the lab and just measured it) we will toggle the forwarding
    state, and the bridge will go through the pre-forwarding actions. 

Re: .12

Thanks for the quick reply.  It leads to a follow-up question.


    
>    If a bridge is dual homed it will not go out of the forwarding state
>   when the backup connections kicks in. This is also true when a 
>   wrap occurs. 
    
Does the bridge in question go through the pre-forwarding actions when a wrap 
condition is replaced by a new connection?


Malcolm

    If, what you mean is, when the wrap unwraps, the answer would be no,
    it does not go back to preforwarding.
    
    If you mean when a cable is pulled out, and then reinserted, it depends
    on how long the bridge port sees no connection to a PHY. It's about 
    4-5 seconds for it to leave the forwarding state when that happens. 
    

Where is the config for the HUB (backplane) stored?
Where is the config for the different modules stored?
What happens if a module breaks (i.e. crashes, loose contact with the hub etc.)
with the configuration. Is it preserved somewhere.

Could someone elaborate on this and be specific about what exactly happens?

I have a case now, and I need to know what to say about the preservation of the
configuration.

Bj�rn Olav Haugom

>Where is the config for the HUB (backplane) stored?
    In the Management Agent Module which is the internal hub management
    agent.
    
>Where is the config for the different modules stored?
    Hub-related configuration is stored in the MAM. Which ports are
    configured out-the-back, what lans they are connected to, what are the
    lan types and names, etc.
    
    There is some stuff stored in the module itself. If you give a module
    its own IP address, that is stored in the module. For PortSwitching
    repeaters, the port groupings are stored in the module.
    
>What happens if a module breaks (i.e. crashes, loose contact with the hub etc.)
>with the configuration. Is it preserved somewhere.
    
    The configuration is stored in non-volatile memory. When the module
    'wakes up' again, the backplane configuration is restored. If the
    module is removed from the hub while the hub is running, the configuration 
    for that module is deleted. Except for FDDI auto-healing. If you want
    to avoid having to re-do the configuration, you can do a module swap
    with the hub powered off. If the module is never removed from the hub
    the configuration will be retained no matter how many times the module
    is reset or crashed whatever.
    
    If FDDI auto-healing is enabled, those modules that are connected to an
    FDDI ring or tree will be re-connected back into the ring/tree when
    they are re-inserted into the hub. If there are ethernet ports on that
    FDDI module (e.g. DECswitch 900EF), they will be connected back to
    their corresponding lans.
    
    -Mike