home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / dcom / lans / fddi / 792 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  3.0 KB
  1. Path: sparky!uunet!ogicse!network.ucsd.edu!sdcrsi!xlnt!bob
  2. From: bob (Bob Grow)
  3. Newsgroups: comp.dcom.lans.fddi
  4. Subject: Re: SMT operation that can bring ring down
  5. Message-ID: <1249@xlnt.COM>
  6. Date: 16 Nov 92 20:23:11 GMT
  7. Article-I.D.: xlnt.1249
  8. References: <1992Nov12.184036.16534@octel.com>
  9. Sender: postmaster@xlnt.COM
  10. Organization: xdi
  11. Lines: 63
  12.  
  13. In article <1992Nov12.184036.16534@octel.com> pfloyd@octel.com (Michael
  14. Barnett) writes:
  15. >
  16. >I'm having some trouble with a wrapped ring that goes down for
  17. >exactly 10 seconds occassionaly.  Actually, one station out of
  18. >3 sees the ring go down for 10 seconds.  We're using the AMD
  19. >supernet chip set and synernetics SMT.  Is there any test that
  20. >the SMT may be running that is causing the ring to go down? (e.g.
  21. >trace function, path test, etc.)  I've looked through the specs
  22. >but can't find anything that has this long of a time frame.
  23. >I suspect that it may have something to do with the LEM since
  24. >we're getting alot of lost frame hits due to a bug within the
  25. >chipset.  Any help would be GREATLY appreciated.
  26. >
  27. >
  28. >                        - Mike
  29. >-- 
  30. >--
  31. >pfloyd@octel.com
  32. >
  33.  
  34. A little more topology information would have been helpful. I assume that 
  35. this ring is as shown below. With stations A and C in WRAP.
  36.  
  37. +-----+ pri +-----+     +-----+
  38. |     |---->|     |---->|     |
  39. |  A  | sec |  B  |     |  C  |
  40. |     |<----|     |<----|     |
  41. +-----+     +-----+     +-----+
  42.  
  43. If only one of the three stations is losing ring operational for an 
  44. extended time, then it is possible that it is an LEM condition. To verify 
  45. this you need to examine CF-State. 
  46.  
  47. Look at the problem and neighbor station to see if configurations are 
  48. changing. For example if the problem station is C then C would be changing 
  49. from WRAP A to ISOLATED and the neighbor station (B) would be going from 
  50. THRU to WRAP A. If the problem station is B then it would be going from 
  51. THRU to WRAP A or WRAP B and the corresponding neighbor would go from WRAP 
  52. to ISOLATED.
  53.  
  54. If the problem station is connected to a concentrator instead of as 
  55. illustrated above then it would go from WRAP to ISOLATED and the 
  56. concentrator is staying in the same CF-State though is still reported 
  57. (e.g., THRU to THRU) as the master port is included and excluded from the 
  58. ring.
  59.  
  60. Exactly ten seconds is unusual because it is closer to the trace timeout 
  61. (defaults produce timeouts of 9 seconds) than to the link confidence test 
  62. time (default 5 seconds after LEM reject). But in the trace situation, the 
  63. ring would be non operational for all three stations for for at least the
  64. timeout times. In LEM reject, the bad link would be removed from the ring, 
  65. and included after passing LCT. Perhaps in your samples of the problem, it 
  66. passed LCT on its second attempt or LCT_long was set to 10 seconds.
  67.  
  68. It's tough to debug a problem with as little information as you have given. 
  69. I hope this will be helpful.
  70.  
  71.  
  72. Bob Grow  (bob@xlnt.com)
  73.  
  74. XLNT Designs, Inc., 15050 Avenue of Science, STE 106, San Diego, CA 92128
  75. Voice: 619-487-9320    Fax: 619-487-9768
  76.