Conference irocz::common_brouters

866.0. "VNswitch900EF - Crashes after 8 minutes or so with dmesv out of range forward table index" by GIDDAY::STANISLAUS () Thu Apr 17 1997 22:05

Cross Posted - Note 4363 in HUB_MGNT conference.
------------------------------------------------

Customer bought several - 2 dozen VNSwitches 900EFs with loads of hubs and
Portswitch 900 TPs, etc.

	This is in continuation of note 4356 of HUB_MGMT conference, but since
the fault has taken a total new shape, I have decided to post a new entry.

This fault is happeneing on multiple units - I have tried atleast 3 units.
This is a new installation of Hubs with VNSwitches.

	MIB DATA NOT AVAILABLE happend when using MCM and this time I just
happened to be standing in front of the HUB. I noticed that the module was
doing a RESET. It was during this time that MCM was loosing contact with the
VNSwitch 900EF and hence the MIB DATA NOT AVAILABLE message during the reset
time. So I was chasing my tail on the symptom rather than the cause of the
problem. 

	So why is the VNSwitch 900EF  resetting itself. I did a bit more
troubleshooting with the switch in DH900 and in standalone and various
connections and configurations. Finally, I could make it reset even standalone,
not in a DEChub 900. This happens on 3 different VNSwitch 900EFs I tried. What I
did was I connected the front port of a STANDALONE VNSwitch 900EF to the
customers network and kept looking at the Uptime of the switch continously.
Approximately around the 8 minute uptime, the VNSwitch 900EF resets itself. Why
around 8 minutes I don't know. This happens even in the simplest configuration 
with the VNSwitch 900EF in a Standalone power supply and connected via front
port to customer's network. If I disconnect the front port from the customer's
network and see uptime using the console port, the sitch remains UP for ever.
When I look at the CRASH and DIAGNOSTIC log, I see a lot of these entries as
follows:

dmesv dmesv_getProtHandle out of range forward table index. I think dmesv is the
module name in which the crash occurs. So what is dmesv. This customer's network
is very very complex. It is more complex when it leaves this site via a
DECbrouter 90T1 to the central site and in turn will reach various other remote
sites. They have over 95 DECbrouters in this network bridging LAT to several 100
sites. There could easily be 1000s of MAC addresses on the entire network. A
very very heavy LAT user and hence a lot of bridging. Is it possible that the
VNSwitch learns a certain number of MAC addresses and then crashes after it
reaches a certain value "N". PROBABLY (but not sure) this customer may have over
800 0 MAC addresses. Even then - why reset.

	F/W rev is 1.5-001.

	I brought one VNSwitch 900 to the office and put it on our network and
it never crashed. I looked at the Forward Database entries after 20 minutes and
saw there were 1650 entries and still didn't crash. I will go back to site and
see the number of entries. I must admit that I did not note that down.

	Next step I will disconnect the DECbrouter 90T1 WAN link and see what
happens to the VNSwitch 900EF.


Alphonse 

********************************************************************************

	
	Look at HUB_MGNT notes conference note number 4363.2 for a good reply
by Steve Henderson
.

            <<< NETCAD::KALI$USER3:[NOTES$LIBRARY]HUB_MGNT.NOTE;1 >>>
                   -< DEChub/HUBwatch/PROBEwatch CONFERENCE >-
================================================================================
Note 4363.2  VNswitch 900EF - resets after 8 minutes Crash Reason is dme  2 of 2
NETCAD::HENDERSON                                    28 lines  17-APR-1997 11:18
                                -< some ideas >-
--------------------------------------------------------------------------------
    re .0
    
    I don't normally read this conference but was made aware of this note.
    dmesv is the short form name for the layer of code in the vnswitch 
    products - dme services. Its the code responsible for setting up the
    dme's tables at run time ( and also at init time ) in response to
    network events - learning, aging, user supplied address filters and
    protocol filters etc. 
    
    I wrote this code.
    
    The bughlt message you refer to arises when dme services consults the
    dme's hash tables to figure out if it already knows about a protocol.
    In this case it believes it does, but the forwarding table index
    its given is outside the expected range.
    
    I don't think it has anything to do with how many mac addresses are in
    the forwarding table. You should be able to learn about 8000 mac
    addresses. If you reach the limit, we just stop learning until some
    entries age out, we certainly don't crash.
    
    I think what's going on here is that the user is trying to add a
    protocol filter. Could you try to observe what operation has just been
    attempted on the module when it crashes, and then we have a chance to
    reproduce it. I have not heard of this problem before.
    
    Steve
    

    We figured this one out. 
    It seems that it's possible for a hash collision to occur between an
    address and a protocol. Dme services thought it had a known protocol,
    but the index generated was actually for an address. It appears that
    the set of addresses and protocols this particular customer was using
    caused this to happen, and they were also such that we passed some
    other validations which normally stop this from happening.
    Anyway, I fixed it.
    The fix will be available when the next V1.5 maintenance baselevel
    build is released.
    
    Steve
    
    

This call has been IPMT'ed

Alphonse