Late collision on cisco router

[kumarpmt83]

Hi,

In my cisco 1841 router the below logs came contionously.

Can u anyone tell me the solution.

LOG:

*Aug 16 10:08:23.800 India: %GT96K_FE-5-LATECOLL: Late Collision on int  FastEth

ernet0/1

*Aug 16 10:08:24.048 India: %GT96K_FE-5-LATECOLL: Late Collision on int  FastEth

ernet0/1

*Aug 16 10:08:24.356 India: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed s

tate to up

*Aug 16 10:08:25.564 India: %GT96K_FE-5-LATECOLL: Late Collision on int  FastEth

ernet0/1

*Aug 16 10:08:26.644 India: %GT96K_FE-5-LATECOLL: Late Collision on int  FastEth

ernet0/1

*Aug 16 10:08:27.564 India: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed s

tate to up

*Aug 16 10:08:28.824 India: %GT96K_FE-5-LATECOLL: Late Collision on int  FastEth

ernet0/1

Fast ethernet 0/1 configuration:

interface FastEthernet0/1

description $ETH-WAN$

bandwidth 128

ip address 10.237.48.18 255.255.255.252

ip accounting output-packets

duplex auto

speed auto

[Leo Laohoo]

What is the remote device?

Can you post the output to the command "sh interface f0/1"?

[Roger De Couto]

Hello,

1. To what device is the fa0/1 plugged into on the other end?

2. Did you try swapping Ethernet cable?

This problem is usually the result of incorrect cabling, cabling faults, hubs in network...read this document for a better understanding.

http://www.cisco.com/en/US/products/hw/modules/ps2033/products_tech_note09186a008009446d.shtml

Goodluck,

Roger

[kumarpmt83]

631-AS-Guwahati-DSO#sh int fastEthernet 0/1

FastEthernet0/1 is up, line protocol is up

  Hardware is Gt96k FE, address is 0019.e87f.9aa5 (bia 0019.e87f.9aa5)

  Description: $ETH-WAN$

  Internet address is 10.237.48.18/30

  MTU 1500 bytes, BW 256 Kbit, DLY 1000 usec,

     reliability 253/255, txload 123/255, rxload 155/255

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Half-duplex, 10Mb/s, 100BaseTX/FX

  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 never

  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 413000 bits/sec, 44 packets/sec

  5 minute output rate 166000 bits/sec, 43 packets/sec

     186210 packets input, 219868484 bytes

     Received 168 broadcasts, 113 runts, 0 giants, 0 throttles

     2528 input errors, 2528 CRC, 0 frame, 0 overrun, 0 ignored

     0 watchdog

     0 input packets with dribble condition detected

     160072 packets output, 66947224 bytes, 0 underruns

     1634 output errors, 6737 collisions, 1638 interface resets

     0 babbles, 1656 late collision, 0 deferred

     0 lost carrier, 0 no carrier

     0 output buffer failures, 0 output buffers swapped out.

the other end cable  is connected to POE.

[Leo Laohoo]

The device on the other end must've hard-coded the speed and duplex setting.  Any way for you to get that changed?

[Roger De Couto]

Hi Dhineshkumar,

From the 'show int fa0/1' output, you will find that this interface is operating in 'Half-duplex, 10Mb/s' mode, and this is causing the collisions to occur.

And most importantly, notice the errors...

2528 input errors, 2528 CRC

1634 output errors, 6737 collisions, 1638 interface resets

1656 late collision

To avoid these collisions please follow the advise given by the other members here and investigate duplex settings on both devices (I suspect the duplex settings on the ethernet end on the POE device is the culprit).

Lock both ends to either 'auto-negotiate' or lock both ends to '100Mbps Full'. If this does not solve the problem, then use another working Cat5 Ethernet cable.

Let us know how you go.

[Lee Smitherman]

Hi,

How far (Cable Length) is the device at the other end?  Running half duplex, last collisions are normally a result of a cable being too long.

Lee.

[Alessio Andreoli]

Hi,

look, if you clear the ineterface and then you show again the statistics it would be a better in put for us. However, i would tell you to check the media transmission for intereferences and the tranceiver too.

test cable-diagnostics tdr

test cable-diagnostics tdr interface

try to check if these "hidden" commands are supported on your platform. The most indicative value anyway are the CRC

Check this too..

https://learningnetwork.cisco.com/thread/7146

you have some runts too..

Alessio

[yunus_turk18]

hi my problem 

sho int gigabitEthernet 1/0/14

GigabitEthernet1/0/14 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 64e9.50a6.fe8e (bia 64e9.50a6.fe8e)
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 10Mb/s, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters never
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 0 bits/sec, 0 packets/sec
5 minute output rate 9000 bits/sec, 16 packets/sec
886264 packets input, 56731825 bytes, 0 no buffer
Received 361 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
899402 packets output, 75765669 bytes, 0 underruns
0 output errors, 118 collisions, 1 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

test cable-diagnostics tdr interface gigabitEthernet 1/0/14
TDR test started on interface Gi1/0/14
A TDR test can take a few seconds to run on an interface
Use 'show cable-diagnostics tdr' to read the TDR results.

sho cable-diagnostics tdr interface gigabitEthernet 1/0/14
TDR test last run on: December 01 10:51:23

Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Gi1/0/14 10M Pair A 131 +/- 0 meters N/A Normal
Pair B 133 +/- 0 meters N/A Normal
Pair C 19 +/- 1 meters N/A Short
Pair D 12 +/- 1 meters N/A Open

can you help me ?

[Richard Burts]

You have showed your interface information but you have not told us clearly what problem you are having. Since you have attached to a very old discussion about late collision, should we assume that your problem is about late collisions? If not please tell us clearly what is your problem.

Your interface, like the one in the original post, is operating at half duplex. If the connected device is operating in full duplex then it does produce the symptom of late collisions. What is happening is that your device is in process of transmitting and the connected device also begins to transmit (which is fine in full duplex) and the incoming transmission while you are still transmitting creates the collision (or late collision) on your device.

The way to resolve the issue is to get both devices in the same mode. Either both in half duplex or both in full duplex. This mismatch is frequently the result of one device attempting to negotiate speed and duplex while the other device has hard coded speed and/or duplex. So you need to communicate with who ever administers the connected device and resolve the duplex mismatch.

HTH

Rick