Half-Duplex = high collisions. Full-Duplex = High CRC errors. help! 1

[GeneralDzur]

I'm looking at my Show Interfaces output, and on our internet-facing interface (e1/0) I see 1526 collisions after 6 minutes. If I manually switch to Full-Duplex, I start getting enormous amounts of CRC errors. What do I do? I've never seen this before.

- stephan

 

[valarian]

What kind of hardware are you using?
Putting an interface on full-duplex on one side without putting the other side to full-duplex, too, can have the effect you're witnessing (CRC errors).
Collisions can be due to high load on the link.

Could you give us the output of a "sh int e1/0"?
Best would be one output while on full-duplex, and another one during half-duplex operation. Please don't forget to reset counters... (clear counters e1/0).
That'll help me get a better picture of what is happening (load, other error counters...)

Mike

 

[GeneralDzur]

It's a Cisco 2620 (or 2621XM - can't remember) with two interfaces: An ethernet (e1/0) and a FastEthernet (fa0/0).

When I manually enter 'full-duplex' the CRC errors start happening - but it doesn't say 'full-duplex' in the Show Int e1/0 description, anywhere??? If I manually set it to half-duplex, it doesn't say that either, but the CRC errors stop, and the collisions start up again.

We're using WFQ on the internet-facing interface; could that affect anything?


- stephan


Internet-facing interface, using Half-Duplex
---------------------------
Ethernet1/0 is up, line protocol is up
Hardware is AmdP2, address is 0007.853b.7e50 (bia 0007.853b.7e50)
Description: Tachyon
Internet address is xx.xx.xx.162/30
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 13/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
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 00:02:46
Input queue: 1/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/11/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
5 minute input rate 545000 bits/sec, 66 packets/sec
5 minute output rate 51000 bits/sec, 52 packets/sec
8844 packets input, 7338278 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
7068 packets output, 866251 bytes, 0 underruns
0 output errors, 287 collisions, 0 interface resets
0 babbles, 0 late collision, 216 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

LAN-facing interface, Full-Duplex
-----------------------
FastEthernet0/0 is up, line protocol is up
Hardware is AmdFE, address is 0007.853b.7e40 (bia 0007.853b.7e40)
Description: Internal LAN
Internet address is 192.168.7.1/24
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)
Full-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 00:04:06
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 61000 bits/sec, 67 packets/sec
5 minute output rate 683000 bits/sec, 89 packets/sec
14117 packets input, 1679007 bytes
Received 191 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast
0 input packets with dribble condition detected
20021 packets output, 18495501 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 17 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

 

[valarian]

1) Full Duplex on E1/0 results in CRC errors
It's possible your Ethernet port or your IOS level do not support full-duplex operation on the E1/0 at all (though the CLI offers you this option in config-if mode - this doesn't necessarily mean it's supported on that specific port).
But even if this part works properly, the CRCs are due to the fact that you only changed YOUR side of the link to full duplex, while the device at the other end of the cable still is on half-duplex. What is E1/0 connected to?
This will only work if you set both side to full-duplex AND your hard- and software supports full-duplex at all. Otherwise you will receive frames that had a collision as "intact" frames, resulting in CRC errors.

2) Half-Duplex on E1/0 with many collisions
As can be seen from your "sh int" output, the collisions are almost 4 percent.
Following reasons are possible:
- Too long or faulty cables (try exchanging the cables in place)
- Malfunctioning receivers (are there any? Like AUI to RJ45?) If yes try exchanging those.
- Too many host in this collision domain (How many are there? What is E1/0 connected to? Switch/hub/router?)

Mike

 

[GeneralDzur]

Hey, thanks for the post - it's really informative. In answer to your questions:

The E1/0 (internet-facing) is using a 6-foot cable that connects straight into an IDU (Indoor Unit), or essentially a 'cable modem' for a satelite connection, which is what we're using. The IDU is essentially a computer, and it's our default route.

I can't imagine that the router (a 2621XM) doesn't support full-duplex operation, since nearly 100% of cisco's products support it, right? Just thinking out loud.

- stephan

 

[valarian]

Okay, so can't be the cable length and I also find it unlikely that the Cisco won't support full-duplex. (But there are some of the older routers and IOSses that do not supoort it, had this problem myself some years ago...)

Anyway, for the full-duplex to work, you will have to set the interface of the IDU to full-duplex, too. Even if it's on auto-negotiate, it possibly won't work out-of-the-box. It's always better to use fixed settings, where possible.

So things I'd try if I had this problem:
Exchange the cable to ensure it's okay (the collisions may be due to this).
If you want to go to full-duplex, ensure it's set to full on both the router and the IDU.

Mike

 

[GeneralDzur]

I'm going to try swapping out the cable, since it seems that's all I CAN do.

Thanks again for your help mike

- stephan

 

[jneiberger]

Collisions are NORMAL on half duplex Ethernet links. Don't even waste your time troubleshooting them unless you're really have a serious problem.

With half duplex Ethernet, a collision is *not* an indicator of a problem, it is expected by design.

 

[GeneralDzur]

Really? But then why aren't I seeing any collisions on the LAN-facing FastEthernet?

- stephan

 

[jneiberger]

Because it's running at full duplex. You don't have collisions in full duplex communication.

Think of it this way: half duplex is like trying to send two-way traffic on a one-lane road. If one cargo vehicle is headed one way and another cargo vehicle is headed the other...<bam>...collision.

If you switch to full duplex then you are effectively upgrading to a two-lane highway where traffic can move freely in either direction.

Trying to troubleshoot collisions with half duplex Ethernet traffic is like walking out into the rain and then trying to figure out why you're getting wet. ;-)

Collisions are not an indication of a problem, they are expected and designed behavior in half duplex Ethernet. Truly excessive collisions (which you're not seeing, by the way) may indicate a more serious problem but it may also just indicate you're trying to push too much data over the link.

Certain types of collisions, like late collisions, are a more serious problem and *are* indicative of an issue that needs to be resolved.

 

[GeneralDzur]

That explains it perfectly jneiberger, thanks for helping me out on this one. I was really worried that there was some problem with the link.

- stephan

 

[GSTEFANICK]

Agreed there isnt enough collision to be concerned with... however he moved e0 to full duplex. Why would he see collision in full dup...

Thanks

 

[jneiberger]

He didn't have collisions when he moved to full duplex, he saw CRC errors, and that's because he only changed the duplex on one side of th link. This caused a duplex mismatch, which causes CRC errors on the full duplex side and late collisions on the half duplex side.

 

[jneiberger]

I also meant to mention that you can't have collisions on a full duplex link. The transmit and receive functions are completely separated and the collision detection function is turned off. If you ever see collisions on a full duplex interface, it's a bug.

 

[valarian]

Collisions are normal on Half Duplex. That's agreed. But almost 4% is far to much colisions. There isn't even much traffic on this interface (5min inout average is 600kbps on a link that should be able to carry up to 4mpbs!). If we were talking about this interface carrying almost 4megs per second, I'd say that these collisions are normal.

Mike

 

[jneiberger]

That percentage isn't necessarily too many. It all depends on the nature of the traffic on the link. If there is a lot of two-way traffic then that increases the likelihood of collisions even at lower data rates.

You are right that you can generally expect 4 Mbps on average with half duplex Ethernet, but that is just an average. Looking at the collision counter is not sufficient to determine if a problem exists.

In this particular instance it appears that there is enough two-way traffic to cause a fair amount of collisions. However, I'd switch to full duplex long before I bothered trying to troubleshoot collision problems on a half duplex link.

Regards,
John