Conference 7.286::fddi

1058.0. "Ultrix port in halt state after saturation." by BSS::C_OUIMETTE (Don't just do something, sit there!) Wed Aug 11 1993 17:32

(Cross-Posted in FDDI & ULTRIX notesfiles)

	Hello all,

Customer has ~40 DS5000/240's on DECconcentrator 500's. There are also 2 3COM
brouters as DAS's on the main ring. Per the customer, the ring has been running
without problems for the last 3 months.

3 weeks ago, they hooked up a W&G DA30 LAN analyzer, and started "stress
testing" the ring. Per the customer, it ran to 98% saturation with no problems.
At "some later point", when "nothing was happening", 22 of the 40 DECstations,
on various concentrators, reported "fddi port in halt state after h/w fault" 
errors in their uerf errorlog, the remaining stations reported receiver 
overruns, and per the customer, all 40 stations had to be rebooted in order 
    to get bind/hesiod/yp working again.

The customer is going to try to recreate the problem this friday, with the W&G
blasting frames. They also have a TEKELEC, and will be monitoring the ring with
both the tekelec & the W&G while the error occurs, if it can be made to happen
again. We will have more data then.

The customer has DECmcc/ultrix onsite, and they can query the Concentrators via
snmp. I have requested that they gather the following info during the test. I'm
not that familiar with the concentrator's snmp reporting capabilities, I'm more
familiar with ELMS, so let me know if I'm way off base:

1. Known Phyport status
2. Known phyport counters
3. Concentrator counters, uptime, resets
4. Concentrator ring re-inits

	I've also requested that the customer get the FDDI interface f/w
version #'s, and the DECconcentrator 500 f/w version #'s.

QUESTIONS: Has anyone seen this error before (Ultrix 4.3)? What exactly could
cause multiple concentrator ports on multiple concentrators to go to such a
state as to cause the Ultrix systems to believe that their fddi ports are 
in a halt state? Any other troubleshooting approaches, counters/states to _try_
to monitor from MCC?

					Thanks for any ideas,

				Chuck Ouimette CSC/CS NETsupport

    It sounds the DEFZA's halted due to a firmware fault.  Have you tried
    doing a uerf -R -o full looking for defza errors?

    	Matt,
    
    Uerf is where the "port in halt state" message came from. This is a
    secure site, so there's no dialin to pull the exact message. If it's
    critical, I may be be to have the customer fax or read the FULL error
    over the phone.
    
    Is there a particular part of the entry that should be looked for?
    
						thanks,
    
    							chuck
    

    That does make it challenging.  Make sure they use -o full or the
    report will be truncated.  Did they get any unsolicited events or
    other things in the error log around that time?

    	Matt,
    
    Thanks for the pointers; I'm working this 2nd hand, so I'll pose the
    questions to the customer & post more when they get back to us. Thanks
    again.
    
    						chuck