🚀 go-pugleaf

In article <1992Nov12.184036.16534@octel.com> pfloyd@octel.com (Michael
Barnett) writes:
>
>I'm having some trouble with a wrapped ring that goes down for
>exactly 10 seconds occassionaly.  Actually, one station out of
>3 sees the ring go down for 10 seconds.  We're using the AMD
>supernet chip set and synernetics SMT.  Is there any test that
>the SMT may be running that is causing the ring to go down? (e.g.
>trace function, path test, etc.)  I've looked through the specs
>but can't find anything that has this long of a time frame.
>I suspect that it may have something to do with the LEM since
>we're getting alot of lost frame hits due to a bug within the
>chipset.  Any help would be GREATLY appreciated.
>
>
>                        - Mike
>-- 
>--
>pfloyd@octel.com
>

A little more topology information would have been helpful. I assume that 
this ring is as shown below. With stations A and C in WRAP.

+-----+ pri +-----+     +-----+
|     |---->|     |---->|     |
|  A  | sec |  B  |     |  C  |
|     |<----|     |<----|     |
+-----+     +-----+     +-----+

If only one of the three stations is losing ring operational for an 
extended time, then it is possible that it is an LEM condition. To verify 
this you need to examine CF-State. 

Look at the problem and neighbor station to see if configurations are 
changing. For example if the problem station is C then C would be changing 
from WRAP A to ISOLATED and the neighbor station (B) would be going from 
THRU to WRAP A. If the problem station is B then it would be going from 
THRU to WRAP A or WRAP B and the corresponding neighbor would go from WRAP 
to ISOLATED.

If the problem station is connected to a concentrator instead of as 
illustrated above then it would go from WRAP to ISOLATED and the 
concentrator is staying in the same CF-State though is still reported 
(e.g., THRU to THRU) as the master port is included and excluded from the 
ring.

Exactly ten seconds is unusual because it is closer to the trace timeout 
(defaults produce timeouts of 9 seconds) than to the link confidence test 
time (default 5 seconds after LEM reject). But in the trace situation, the 
ring would be non operational for all three stations for for at least the
timeout times. In LEM reject, the bad link would be removed from the ring, 
and included after passing LCT. Perhaps in your samples of the problem, it 
passed LCT on its second attempt or LCT_long was set to 10 seconds.

It's tough to debug a problem with as little information as you have given. 
I hope this will be helpful.


Bob Grow  (bob@xlnt.com)

XLNT Designs, Inc., 15050 Avenue of Science, STE 106, San Diego, CA 92128
Voice: 619-487-9320    Fax: 619-487-9768

A little more background on the problem I'm chasing:
I've seen this error happen only twice in the past 2 months and
I didn't have much code to log what was happening.  I've since
added some additional logging and am waiting for the darned
thing to go out to lunch again.
The setup I'm using is as follows:

    +-------+               +-------+               +-------+
    |       |---------------|       |---------------|       |
    |  A    |               |  B    |               |  C    |
    | WRAP  |---------------| THRU  |---------------| WRAP  |
    +-------+               +-------+               +-------+


Station A is the one having problems (i.e. sees the ring go
down for exactly 10 seconds).  Stations B and C both claim.
Station B wraps.
I think the LER_CUTOFF is being exceeded.  Other test setups
I've been using have been seeing LER rates of around 10E-7
under certain traffic conditions (I know this is due to the
AMD chipset bug).  When I first found out about the bug, I
lowered the LER_ALARM and LER_CUTOFF thresholds to 10E-7
and 10E-4 respectively.  When raising the CUTOFF on a
station to 10E-7, that station sees the ring go down for 10
seconds.  Is the LCT doing tests twice??? (2*LCT_LONG)?
Has anyone seen the AMD bug cause LER rates to go to 10E-4?

Thanks for all the help so far folks!



                    - Mike
-- 
--
pfloyd@octel.com