| Title: | FDDI - The Next Generation |
| Moderator: | NETCAD::STEFANI |
| Created: | Thu Apr 27 1989 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2259 |
| Total number of notes: | 8590 |
We have observed a case where it seems that a DB610 stops
forwarding on one port. We have seen similar problems on
both a DB610 w/o FDDI, and with a FDDI port. It seems
this is triggered by excessive CRC errors on the ether
segment. The condition seems to be latching, i.e. a power
fail / reboot is required to clear the condition.
pse. reply if you have seen any similar sympthome, I'll
investigate further and assemble a proper bugreport.
also posted in ethernet notes file.
Gullik
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 944.1 | CRC errors are NOT normal in my experience | KEIKI::WHITE | the NAUGHTies 2001 - 2010 | Wed Apr 28 1993 19:29 | 8 |
Could someone speculate on why excessive CRC errors may be being
seen at all?? The ONLY time I have regularly seen CRC errors was when
sub-standard non shielded transceiver cables were being used. Other
than defective wiring causing BCC errors and shorted thinwires etc,
why would they be seeing excessive CRC errors?
Bill
| |||||
| 944.2 | I've seen things like that. | CGOS01::DMARLOWE | dsk dsk dsk (tsk tsk tsk) | Thu Apr 29 1993 09:28 | 9 |
You never know what hides on these networks. I observed a UB hub
with 10BaseT cards. The ports would autosegment correctly but
sometimes take hours to restore. I noted 22% CRC/FCS errors from
this hub. Fortunately the customers load was only 10%. Can you
imagine 22% errors on a 40% load?
Strange but true.
dave
| |||||
| 944.3 | Can modify ebrPortTestPassedThreshold | QUIVER::WALTER | Mon May 03 1993 14:09 | 21 | |
This issue has been discussed elsewhere in this file, but I couldn't
find the reference to it.
When errors on a port exceed a certain level, it causes the bridge to
stop forwarding on that port and perform a link confidence test. If the
test fails, the bridge will try again later (like 15 seconds?). The
bridge won't start forwarding again until the errors on that link go
down to an acceptable level.
The link confidence test actually performs N tests of the link, and it
must pass all N times, else it gives up and tries again later. The
default value of N is around 10, but it can be changed through the SNMP
mib variable ebrPortTestPassedThreshold. By lowering the value, the
test is more likely to pass.
Of course, that's just hiding the real problem, which is the excessive
errors on the line.
Dave
| |||||