Solved: OSPf link bouncing due to input and crc errors

mahesh18 · ‎09-05-2010

Hi all,

We have lan connection by opsf

here is log on device

%PHY-4-EXCESSIVE_ERRORS: Excessive FCS, data, or idle word errors found on interface Gi1/0/6

here is int gi1/06 info

Full-duplex, 100Mb/s, media type is 10/100/1000BaseTX*********************************this is copper connection right?
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 1y4w
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 3000 bits/sec, 3 packets/sec
5 minute output rate 177000 bits/sec, 36 packets/sec
     155243613 packets input, 23701387417 bytes, 0 no buffer
     Received 6663011 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     5 input errors, 5 CRC, 0 frame, 0 overrun, 0 ignored*******************************
     0 watchdog, 6662959 multicast, 0 pause input
     0 input packets with dribble condition detected
     1866096602 packets output, 691938925955 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 PAUSE output
     0 output buffer failures, 0 output buffers swapped out

i check the other end of interface there are input and crc errors.it is point to pint ospf conenction

other end is also 100 fill and same medi type.

My question is is there issue with cabling?

Jon Marshall · ‎09-05-2010

Mahesh

Yes, as Peter said, it is a copper connection.

You could try another cable and if possible a different physical interface on the switch/router. Note only try one at a time or you won't know which sorted your problem if indeed it does.

Jon

View solution in original post

Peter Paluch · ‎09-05-2010

Hello Mahesh,

Yes, this is a copper interface. As far as I know, all Ethernet variants having T in their name are referring to a copper (Twisted pair) cabling (10Base-T, 100Base-TX, 100Base-T2, 100Base-T4, 1000Base-T, 1000Base-TX, 10Gbase-T).

Best regards,

Peter

View solution in original post

Giuseppe Larosa · ‎09-05-2010

Hello Mahesh,

>> 155243613 packets input, 23701387417 bytes, 0 no buffer

Received 6663011 broadcasts (0 IP multicasts)

0 runts, 0 giants, 0 throttles

5 input errors, 5 CRC, 0 frame, 0 overrun, 0 ignored***********************

you had 5 errors out of 155243613, the error ratio is only 3,22 10^(-8) this is negligible and it cannot cause OSPF to bounce as OSPF neighborship fails after missing 4 hellos in a row with default settings. OSPF can have fallen down only once in one year

>> Last clearing of "show interface" counters 1y4w

You may change the cable but I can tell that the message:

>> %PHY-4-EXCESSIVE_ERRORS: Excessive FCS, data, or idle word errors found on interface Gi1/0/6

is quite common on low end LAN switches and it can be ignored most of the times as it does not cause serious issues.

I see it in HP OVO messages and when I go to check the port I see the port working.

if OSPF is not stable on the link the root cause is probably another one not what we see on this side. The other side may have worse error counters.

Hope to help

Giuseppe

View solution in original post

Peter Paluch · ‎09-05-2010

Hello,

Yes, this is a copper medium.

First please check whether the speed and duplex settings are negotiated automatically or whether they are set statically on appropriate interfaces. In most cases, the best choice is to leave both speed and duplex settings to be autonegotiated on both sides of the link. If the speed and/or duplex must be statically configured then it is very important to set both speed and duplex statically to identical settings on both ends of the link - otherwise, duplex mismatches may result. A duplex mismatch is often seen as a CRC error on a full-duplex port.

If the speed and settings are correct on both sides of the link then the most probable cause of your problems is indeed the cabling. It would be best to use a certification tester to thoroughly verify the cable transmission characteristics and ascertain whether it performs to Cat5e or Cat6 requirements. Are you using a shielded cable? The shielding must also be connected properly on both sides of the cable.

Best regards,

Peter

mahesh18 · ‎09-05-2010

hi Peter,

thanks for reply.

both sides are auto neogiating 100 full.so this rules out duplex mismatch.

both sides have 10/100/1000BaseTX under media type

is this connection copper ?

thanks

mahesh

Jon Marshall · ‎09-05-2010

Mahesh

Yes, as Peter said, it is a copper connection.

You could try another cable and if possible a different physical interface on the switch/router. Note only try one at a time or you won't know which sorted your problem if indeed it does.

Jon

Peter Paluch · ‎09-05-2010

Hello Mahesh,

Yes, this is a copper interface. As far as I know, all Ethernet variants having T in their name are referring to a copper (Twisted pair) cabling (10Base-T, 100Base-TX, 100Base-T2, 100Base-T4, 1000Base-T, 1000Base-TX, 10Gbase-T).

Best regards,

Peter

Giuseppe Larosa · ‎09-05-2010

Hello Mahesh,

>> 155243613 packets input, 23701387417 bytes, 0 no buffer

Received 6663011 broadcasts (0 IP multicasts)

0 runts, 0 giants, 0 throttles

5 input errors, 5 CRC, 0 frame, 0 overrun, 0 ignored***********************

you had 5 errors out of 155243613, the error ratio is only 3,22 10^(-8) this is negligible and it cannot cause OSPF to bounce as OSPF neighborship fails after missing 4 hellos in a row with default settings. OSPF can have fallen down only once in one year

>> Last clearing of "show interface" counters 1y4w

You may change the cable but I can tell that the message:

>> %PHY-4-EXCESSIVE_ERRORS: Excessive FCS, data, or idle word errors found on interface Gi1/0/6

is quite common on low end LAN switches and it can be ignored most of the times as it does not cause serious issues.

I see it in HP OVO messages and when I go to check the port I see the port working.

if OSPF is not stable on the link the root cause is probably another one not what we see on this side. The other side may have worse error counters.

Hope to help

Giuseppe

mahesh18 · ‎09-05-2010

Hi guislar,

yes you are right it is 3750 switch and other side has 97 crc errors.

i clear the counters now so far errors are not incrementing.

Many thanks

mahesh