[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

2440.0. "DB900 ARP and error code 200C" by KAOFS::R_RYAN (I used to be a coyote but Im ok nowoooo!) Wed Jun 28 1995 13:41

    I'm seeing a problem on a customer's site with the DB900. Every couple
    of hours the ability of nodes communicating via IP fails.
    The ability for TCPIP nodes to communicate through the network becomes
    impaired as the resolution of IP address to ethernet address stops
    functioning. On UNIX and VAX computers in the network an "arp -a"
    command returns an ethernet address of "incomplete". On the PCs the ARP
    -a doesnt list the address at all. If you force the address into the
    ARP table with "arp -s 156.44.216.15 08:00:2b:00:0a:30" it works fine
    until the ARP removes the entry because of automagic purge.
    Hubwatch 3.1.5 can access the bridges before the problem occurs and the
    address list returned by the bridges in this state look fine with about
    200-300 addresses. After the problem the bridge in question reports
    over 500 addresses, sometimes continuing to grow past 5000 addresses.
    Once the bridge reports that it has more than about 400 addresses the
    hubwatch software returns a file with no addresses in it when asking
    for the forwarding database contents.
    An error log dump reveals:
    
    Entry #				= 0
    Entry Status			= 0
    Entry Id				= 10
    Firmware Rev			= 1.4
    Reset Count				= 10
    Timestamp				= 0	1	212E
    Writecount				= 14
    FRU Mask				= 0
    Test ID				= DEAD
    Error Data = SR=2000 PC=00074966 ErrorCode=0000200C ProcCsr=7D6D
    
    The 200C error code is familiar. In fact, as I understand it, this 
    problem should be resolved by version 1.4.4 of the firmware. The
    customer swears that they installed the latest firmware that I sent to
    them v 1.4.4, however firmware rev in the error dump specifies 1.4.
    The firmware I sent to the customer was a version Bill Wade provided
    and therefore of the highest quality. 8-)
    
    I guess my questions are: 
    1) Does v 1.4.4 actually fix the problem mentioned above? 
    2) Can anyone verify the firmware version mentioned in the error dump 
    above as being correct?
    We will be reinstalling the firmware just to be sure and I have asked
    the customer to do a redirect to the module and show the version that
    way.
    
    Thanks and regards,
    Ron Ryan
       
T.RTitleUserPersonal
Name
DateLines
2440.1NPSS::WADENetwork Systems SupportWed Jun 28 1995 14:1215
    Ron,
    
    1.4.4 does in fact fix the 200C problem.  My guess is that you're
    looking at stale error log entries.  The firmware rev indicated in the
    error log entry was not updated to reflect 1.4.4 fw is running.
    
    The empty fwdb is caused by there being a 0-0-0-0-0-0 entry in the
    list.  This is fixed in the WAVE III release/HUBwatch 4.0.
    
    Let's communicate offline regarding the DEFBA ARP/IP problem.  I've heard
    similiar problems from 1-2 other customer sites and Iwe need to
    investigate this further.
    
    Bill