| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 932.1 | time for new hardware | COMICS::WOODWARD | Smile! | Fri Apr 16 1993 06:12 | 7 |
| Hardware fault in one of the bridges. The elasticity buffer errors imply a
serious timing problem between the two stations, but unfortunately you can't
tell which station has gone wrong.
Time to get some spares parts...
Steve
|
| 932.2 | Which one I wonder? | BUSSTP::JHANNAH | Jim Hannah, Telecoms & Nets, AYO | Fri Apr 16 1993 09:22 | 7 |
| Does it mean that there is a problem in one of these two bridges which
have their ports in the wait state, or could the problem be in any of
the four bridges but just showing up on the counters on this one?
Regards,
Jim.
|
| 932.3 | | COMICS::WOODWARD | Smile! | Fri Apr 16 1993 09:44 | 38 |
| Jim,
Sorry I should have been a bit more specific. The problem lies in one of the
2 bridges whose ports are in the wait state. FDDI (unlike 802.5) uses distributed
clocking, so every station has its own elasticity buffer to allow for clock
differences between it and its neighbours. Elasticity buffer errrors at one
station mean a problem between that station and the one it's directly connected
to on the port which is showing the errors.
You can't really tell which station is at fault because, as they are each using
their own clocking, either clock being out of spec will cause errors eg
Take this part of a ring:
Station 1 Station 2
--------- ---------
====! A !===============! B !=== (ie A port to B port, but it
--------- --------- is just as true for M-S etc)
Station 2 port uses internal clock to transmit data to Station 1 on primary ring.
Station 1 clocks data into its elasticity buffer using clock recovered from bit
stream
Station 1 transmits data on down ring (out of elasticity buffer) using internal
clock.
IF Station 2 clock is too fast OR Station 1 clock is too slow, the elasticity
buffer will overflow.
IF Station 2 clock is too slow OR Station 1 clock is too fast the elasticity
buffer could 'empty' in the middle of a frame.
Any of the 4 faults lead to elasticity buffer errors being logged in station 1.
Hope this helps,
Steve
|
| 932.4 | | KONING::KONING | Paul Koning, A-13683 | Fri Apr 16 1993 15:02 | 37 |
| Well, those counters are obviously nonsense.
More specifically, they are 8-byte values with the byte order wrong. I can't
tell who did it wrong, the management agent or the management director, but
one of them is broken.
Some quick arithmetic says that the real counters are:
Counter Creation Time = 1992-09-24-16:47:07.125
LEM Rejects = 5
LEM Link Errors = 102
LCT Rejects = 2
Connection Completed = 32
TNE Expired Rejects = 0
Elasticity Buffer Errors = 2
MCC> show bridge mainbp phy port 2 all counter
Bridge LOCAL_NS:.mainbp PHY Port 2
AT 1993-04-16-08:38:11.133 Counters
Counter Creation Time = 1992-11-22-14:34:53.133
LEM Rejects = 0
LEM Link Errors = 0
LCT Rejects = 1
Connection Completed = 4
TNE Expired Rejects = 0
Elasticity Buffer Errors = 0
Given the 100 link errors, I'd say you have a bad link. May be a bad
transceiver on either end, or a cabling problem. It's possible the Ebuf
errors are a consequence of the link errors rather than a real problem;
see if they go away once you fix the LEM problem.
paul
|