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

Conference netcad::hub_mgnt

Title:DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:NETCAD::COLELLADT
Created:Wed Nov 13 1991
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4455
Total number of notes:16761

2116.0. "DECbridge 900MX hangs" by KAOFS::R_RYAN (I used to be a coyote but Im ok nowoooo!) Fri Mar 17 1995 16:57

Hello all,
    
I just inherited the following problem and have developed an action plan for 
gathering some information as well as doing some troubleshooting. The problem
is, this one is quite hot and I need a little help. The customer has a
DECbridge 900MX that is hanging every 15 minutes or so during heavy network
utilization. An NTAS server was added to the network prior to this problem 
cropping up.

Problem:

A DECbridge 900MX in a DECHUB 1 configuration freezes/hangs after 15 minutes 
of heavy network activity. 

The DECbridge 900 MX is one of three stations in a DUAL ring. The upstream 
neighbor is a DEC concentrator 500. The Downstream nighbor is a DECbridge 620.
Supposedly, this problem began when an NTAS server was installed on the 
DEC concentrator 500. Heavy traffic and large frames from the server precede 
the failure. How much traffic and what size of frames is unknown or at least
not passed on to myself.

Has anyone seen a problem similar to this? I understand there have been a
number of problems with the DECbridge 900MX crashing but this problem appears
to be somewhat different in that there is no dump available for the module.
All we see are resets. Is 1.4 the latest version of firmware for the bridge?

Are there any issues with the DECconcentrator 500 that might account for the
failure of the bridge? ie: fragmentation issues? 
The DECbridge 900MX should be able to handle/filter 460K pps. I can't see 
it having a problem with the ammount of traffic on the FDDI. 
I thought that each of the ethernet ports on the bridge were able to handle 
maximum throughput of an ethernet so this should not be an issue.

This call was escalated to me and I was asked to escalate to engineering 
immediately. The call is that hot. I have not done so based on the lack
information and that more troubleshooting is required.
  

Some notes:

At time of failure the snmp agent does not respond to pings.

The console port on the hub 1 is still working

Before the bridge goes into the freezed state, we receive a SNMP trap message 
that says the trafic is too high, some packets will be dropped
	
Network monitoring software:

The customer is using HP OPTIVITY to manage this bridge.


Bridge:
                           Enter selection : 3

DECbridge 900MX
==============================================================================

DECbridge 900MX, 6-Ethernet/FDDI Bridge, HW=v0/2,RO=v0.2,SW=v1.4.0
SysUpTime                                 : 18:15:28   7 resets
SNMP Read/Write Community                 : public
SNMP Trap Addresses                       : 142.41.51.254
Status of Last Downline Upgrade           : No Status
In-Band Interface Hardware Address        : 08-00-2B-A6-6E-A8
In-Band Interface IP Address              : 142.41.51.231
In-Band Interface Default Gateway Address : Not Configured
Out-of-Band (OBM) Interface IP Address    : Not Configured
Out-of-Band (OBM) Management Port Speed   : 9600
Port 4 using front panel UTP port

==============================================================================

==============================================================================

                           Enter selection : 7



DECbridge 900MX
==============================================================================

                                DUMP ERROR LOG
                            Current Reset Count: 7

==============================================================================


==============================================================================

No more Error Log entries.


T.RTitleUserPersonal
Name
DateLines
2116.1Gone to EngineeringKAOFS::R_RYANI used to be a coyote but Im ok nowoooo!Tue Mar 21 1995 15:1911
    This call was escalated to engineering with some further definition
    added. It seems that the 900 bridge will stop forwarding IP and NETBEUI
    frames with only four PCs connected to a NT server, performing XCOPY
    operations. DECnet and LAT continue to flow through the bridge. 
    Oddly enough the fans in the 900 MX speed up at the time of the failure.
    Explain that one to me. Supposedly a new release of firmware for the
    bridge is expected to be available sometime this week.
    
    Regards,
    Ron Ryan
    Western Canada Support 
2116.2Same problem here!WRAFLC::WOODALLMACRO is the best.Tue Mar 21 1995 16:1319
    Ron,
    
    	I have seen similar symptoms at the customer site here (Robins AFB,
    GA.)  At least 10 times now IP traffic has been interrupted across the
    DB900-MX in a ONEHUB.  Not all IP traffic is affected, just certain
    address ranges.  Like you mentioned, LAT and DECNET are not affected at
    all.  That traffic keeps flowing.
    
    	One thing that I did discover!  Using HUBwatch, when the IP traffic
    goes south, the bridge cannot be accessed anymore via HUBwatch.  You
    can't even ping it!  HOWEVER, if I manually place an entry in the ARP
    table for the IP to MAC translation for the bridge, then I can once
    again access it!!!!!!!!!!!! 
    
    I am very interested in hearing about anything you learn. 
    
    
    Frank
    dtn 360-4358
2116.3Sounds similarKAOFS::R_RYANI used to be a coyote but Im ok nowoooo!Wed Mar 22 1995 15:128
    Frank,
    Your problem sounds very similar. We aren't able to ping the hub
    either. We are able to use OBM to connect to the hub. Supposedly, there
    is a new version of firmware ready to go or close to it that may help
    with this issue. I'll let you know how things proceed.
    Regards,
    Ron Ryan                                                
    Western Canada Support
2116.4CRONIC::LEMONSAnd we thank you for your support.Fri Jun 09 1995 13:513
Was this problem ever reproduced, and solved?

tl