cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8963
Views
0
Helpful
20
Replies

Late Collision on WAN Link Interface

Hi All,

I have been facing on one of my Router WAN MPLS Link Connected Interface, FE. In logs, I am getting below logs continuously and have done below troubleshooting.

  1. Router Model - Cisco 1841, IOS (C1841-ADVIPSERVICESK9-M), Version 12.4(19b).
  2. Interface Fa0/1 - connected to MPLS Link, Its going ISP. On this interface I am getting logs and its Interface is configured Speed/Duplex Auto but its auto-negotiating to Half/100Mbps. At the other end (ISP), its confirmed that they have configured Full/100Mbps.
  3. We tried changing the settings but each time we lost the connectivity to the router after that change and had to revert to auto settings.
  4. Checked cable type. It was Straight-Through and changed the same to Cross-Over.
  5. Cable is of good quality and its Cat 6A. Length 3m only.
  6. Device CPU utilization is being fine.

Please let me know:

  1. What could be the possible reason for this and how can I resolve it?
  2. What would be the impact on router and the traffic flow? So far I haven't received any issues and ping response for this link seems normal (as what is expected).

Apr  3 14:42:38 CEST: %GT96K_FE-5-LATECOLL: Late Collision on int  FastEthernet0/1
Apr  3 14:42:40 CEST: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
Apr  3 14:42:46 CEST: %GT96K_FE-5-LATECOLL: Late Collision on int  FastEthernet0/1
Apr  3 14:42:46 CEST: %GT96K_FE-5-LATECOLL: Late Collision on int  FastEthernet0/1
Apr  3 14:42:48 CEST: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
Apr  3 14:43:11 CEST: %GT96K_FE-5-LATECOLL: Late Collision on int  FastEthernet0/1
Apr  3 14:43:13 CEST: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
Apr  3 14:43:42 CEST: %GT96K_FE-5-LATECOLL: Late Collision on int  FastEthernet0/1
Apr  3 14:43:44 CEST: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up

RTR01#sh int f0/1
FastEthernet0/1 is up, line protocol is up
  Hardware is Gt96k FE, address is 001c.5846.e8a5 (bia 001c.5846.e8a5)
  Description: **MPLS link connected to AUROHYD_RTR 192.168.83.2**
  Internet address is 192.168.83.42/30
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Half-duplex, 100Mb/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 8000 bits/sec, 5 packets/sec
  5 minute output rate 9000 bits/sec, 4 packets/sec
     12648229 packets input, 2616311911 bytes
     Received 2 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog
     0 input packets with dribble condition detected
     10879116 packets output, 1842349659 bytes, 0 underruns
     5308 output errors, 19560 collisions, 5296 interface resets
     0 unknown protocol drops
     0 babbles, 5333 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

RTR01#sh run int f0/1
Building configuration...

Current configuration : 165 bytes
!
interface FastEthernet0/1
 description **MPLS link connected to ISP**
 ip address 192.168.83.42 255.255.255.252
 duplex auto
 speed auto

end

 

 

Can anybody help me out and share your details thoughts on this, please. Thanks!

 

Regards,

Yaseen

1 Accepted Solution

Accepted Solutions

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

"Will auto-auto at both end work?"

It should, but then 100/full should normally work on your side if other side is configured 100/full.

You'll only know for certain if you try it.

How the other side's port is actually configured would be helpful to know, along with the actual device and its software version.

Until you get both sides to agree on speed and duplex, not only will you see errors, but your throughput is usually very much degraded.  100/half to 100/half would work much better than the duplex mismatch.

View solution in original post

20 Replies 20

Leo Laohoo
Hall of Fame
Hall of Fame
  1. Interface Fa0/1 - connected to MPLS Link, Its going ISP. On this interface I am getting logs and its Interface is configured Speed/Duplex Auto but its auto-negotiating to Half/100Mbps. At the other end (ISP), its confirmed that they have configured Full/100Mbps.

Look at your line errors.  It's found in the "output" section.  This means the CRC errors are generated by your Fa0/1 interface and it's due to the possibility that the ISP has hard-coded the speed/duplex settings on their side. 

 

Ask them to configure their port to auto/auto and see what happens.  

Dear Leo,

 

Thanks for your reply!

 

As I mentioned, ISP has hard-corded to Full/100Mbps. We are not observing any CRC/Input/Output Drops errors too in the sh int output.

 

Let me know what could be the issue with these errors and detail about Late Collision.

Please let me know:

  1. What could be the possible reason for this and how can I resolve it?
  2. What would be the impact on router and the traffic flow? So far I haven't received any issues and ping response for this link seems normal (as what is expected).

Thanks, Yaseen 

Hello

I have had a similar issue in the past which went on for about a month ago so. I changed the cable to a cross over and the issue was solved. 
When autonegotiation is set, the autocrossover feature is also set .. Please try this...

Hi Jatinder,

I tried changing the cable to cross-over after reading same tip from Cisco SupportForums but it did not work to me.

 

Appreciate any other options!

5308 output errors, 19560 collisions, 5296 interface resets
     0 babbles, 5333 late collision, 0 deferred

And what do you think these are, Monte Carlo Casino chips?  

 

These are COLLISIONS.  They are duplex errors.  The fact that you see in your outbound packet counters means a lot.  If your ISP says they see nothing, then I call them liars.  If they know what they are doing they should also see collisions.

Yep, Output Errors are there... my bad :( 

 

But no output drops... ;)

I'll check for any collision if they are seeing at their end.

 

Can you please let me know what is the probable service interruption with this (late collision) in detail since I am not facing any issue, we are observing link always up with normal latency to reach this site.

Regards,

Yaseen

But no output drops... ;)

Output drops is another kind of "monster" you don't want in your kitchen.  Output drops simply mean the downstream client is sending back (to your router or switch interface) a PAUSE frame because the downstream device cannot process the amount of traffic your router/switch is pushing.  So traffic backs up in your router/switch's buffer until the buffer gets full and the packets are dropped.  This is when the Output Drops counter starts to increment.  

Can you please let me know what is the probable service interruption with this (late collision) in detail since I am not facing any issue, we are observing link always up with normal latency to reach this site.

Wait until you fix this duplex mismatch errors and you'll see the performance of your link DOUBLE!

 

Collisions will ALWAYS be observed in the transmit side of a network interface.  On the receive side of the network interface, you won't see collisions but you will always see either FCS or CRC errors (or both).  

 

No sane network administrator will take speed/duplex mismatch error sitting down.  I will always make it a point to fix it when I see it.

Thanks for making me understand on Output Drops!

Ok, we are seeing duplex mismatch and I am checking with my ISP to auto-negotiate at their end.

Wont there be any issue keeping auto-auto at both ends, ISP and ours?

 

Why I am seeing here Late Collisions whereas I already have changed cable to new/working Cross-Over Cat6A?

Please suggest. Thanks!

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

"Wont there be any issue keeping auto-auto at both ends, ISP and ours?"

With modern equipment, usually not.  If fact, today most vendors, recommend auto/auto as best practices.  Hard coding stems from old habits, created when auto/auto didn't work too well.

"Why I am seeing here Late Collisions whereas I already have changed cable to new/working Cross-Over Cat6A?"

Because it's unrelated to the cable, it's related to the duplex mismatch.

Late collisions should only appear in half duplex mode, and even then (if both sides configured for half-duplex), it would still indicate an error.

Ok, we are seeing duplex mismatch and I am checking with my ISP to auto-negotiate at their end.

Depends.  There is a Cisco interface command which forces the port to auto-negotiate to a lower speed.  The command is "speed auto 10 100".  But not a lot of people know this command so it'll depend entirely on the network admin.

Why I am seeing here Late Collisions whereas I already have changed cable to new/working Cross-Over Cat6A?

Joe is right.  Cables have NOTHING to do with collisions.   As I've mentioned above, the incoming/receiving interface will always see collisions when possible.  Receiving/transmitting interface will never see collisions.

 

Joseph W. Doherty
Hall of Fame
Hall of Fame

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

"2. Interface Fa0/1 - connected to MPLS Link, Its going ISP. On this interface I am getting logs and its Interface is configured Speed/Duplex Auto but its auto-negotiating to Half/100Mbps. At the other end (ISP), its confirmed that they have configured Full/100Mbps."

You cannot mix auto/auto with full/100.  Your results are as expected.

You either need to configure full/100 on your side, or you need provider to change to auto/auto.

"3. We tried changing the settings but each time we lost the connectivity to the router after that change and had to revert to auto settings.

4. Checked cable type. It was Straight-Through and changed the same to Cross-Over."

Auto/auto also often supports auto-MDI/MDIX.  Did you try cross-over cable and your side 100/full?

Hi Joseph,

Thanks for your reply!

I tried cross-over cable but no luck! Still cross-over is connected and observing same issue (late collision and half-duplex on Interface end).

While trying changing interface at my end to 100/Full, I am losing the connection and have to revert.

Will auto-auto at both end work?

BR, Yaseen

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

"Will auto-auto at both end work?"

It should, but then 100/full should normally work on your side if other side is configured 100/full.

You'll only know for certain if you try it.

How the other side's port is actually configured would be helpful to know, along with the actual device and its software version.

Until you get both sides to agree on speed and duplex, not only will you see errors, but your throughput is usually very much degraded.  100/half to 100/half would work much better than the duplex mismatch.

100/full on both end is not working.

Attached ISP end interface output. Checking with ISP for Device and IOS details. After these details, we will plan for auto-auto on both end.

My link is of 2Mbps, can we get it cross-checked with this interface output?

 

Review Cisco Networking for a $25 gift card