Interface resets and Late Collisions

[ksas025]

I have an older Cisco 7200 router with a fastEthernet port directly connected to a PIX 515E firewall via a crossover cable. Lately, I have been noticing slowing the usual network performance. I doubled checked the speed and duplex settings of the interface on both ends (router and PIX) and both were at 100full. When I check the interface statistics on the router, there were many errors as well as many "Late Collisions". What can be causing this?

I was thinkg maybe I should reset my PIX or Router but these are production systems, and if I dont have to I would rather not. Has anyone experienced faulty Cisco hardware before? Can the faulty hardware sometimes be corrected by a power cycle?


Here are the router statistics:

FastEthernet2/0 is up, line protocol is up
Hardware is AmdFE, address is <** MAC edited **> Description: Connects to the switch (Office-Sw-toCorp-RTR, 10.8.14.4) in the DMZ bet
Internet address is 10.8.14.2/24
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 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 07:40:27
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 1/75, 0 drops
5 minute input rate 129000 bits/sec, 50 packets/sec
5 minute output rate 17000 bits/sec, 33 packets/sec
2226476 packets input, 1629412950 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 abort
0 watchdog, 0 multicast
0 input packets with dribble condition detected
1821237 packets output, 404591932 bytes, 0 underruns
3778 output errors, 5852 collisions, 3666 interface resets
0 babbles, 3778 late collision, 3231 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out



Here is the Pix interface stats:


interface ethernet1 "inside" is up, line protocol is up
Hardware is i82559 ethernet, address is <** MAC edited **>
IP address 10.8.14.1, subnet mask 255.255.255.0
MTU 1500 bytes, BW 100000 Kbit full duplex
4626701 packets input, 871039779 bytes, 0 no buffer
Received 0 broadcasts, 3633 runts, 0 giants
7011 input errors, 3665 CRC, 3346 frame, 0 overrun, 3665 ignored, 0 abort
5871214 packets output, 3759576555 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collisions, 0 deferred
0 lost carrier, 0 no carrier
input queue (curr/max blocks): hardware (128/128) software (0/20)
output queue (curr/max blocks): hardware (2/13) software (0/7)


Any Ideas what could be causing all those errors on my router interface?

 

[JOAMON]

Make sure all interfaces are set to full duplex. Looks to be a duplex mismatch problem or a cable issue.

 

[jneiberger]

Actually, set both sides to AUTO and your problem should go away. It may seem counterintuitive, but give it a try. I'll bet you a Coke that it will work after that.

John

 

[plshlpme]

in my time i have found that setting the duplex to AUTO is the enemy...

to many times they have not negotiated properly and you end up with nothing but headaches... in all cases its better to hard code the duplex and bandwidth settings.

 

[jneiberger]

This is absolutely not true! AUTO is no longer the enemy, althought it used to be a few years ago. With NICs and switches made in the last 3-4 years, however, auto is absolutely, without question, the preferred setting.

The key is that auto needs to be set on both sides. Many people think that hard-setting one side while leaving the other side on auto is a good thing--it is not.

I've even had this discussion with Cisco and I got them to alter their documentation. They now agree that auto is the preferred setting on your devices. Only use manual settings if you run into an older device that doesn't behave according to the standard or if you must force a particular link to 10 Mbps, for example, because the cabling can't handle 100 Mbps.

Let me know if you want a more detailed explanation of my stance. You can probably find it on Google because I've had this discussion many times. Just search for "neiberger autonegotiate" and you'll probably find plenty to read.

John

 

[plshlpme]

well the problem on my end is that i do not have access to the customers routers and sometimes they set the duplex and sometimes they didn't... we just had to many instances where the auto negotiation did not work.

it will depend on your scenario i guess.
we use all 2651XM and 2650XM routers with a 12.3 IOS..
hard setting them all was the only solution.
we are setting them to 10m full duplex.

 

[jneiberger]

If you don't have access to both ends of the link they you just have to work within that restriction. In that case, auto may not be an option. However, in cases where you control both ends of the link, auto is definitely the best way to go.

Regards,
John

 

[lambent]

Not always true if you are using devices from different vendors, e.g. Cisco vs Extreme, and you'll be extremely frustrated.

Auto-Auto is absolutely good between clients and access switches as you are absolutely sure that you don't want to hardcode every PCs in your company.

Sometimes in Sun's RISC server or even the OSA in mainframe, you'll also need to hardcode to 100Full. Upgrading the NIC drivers may also work sometimes, but not always.

 

[jneiberger]

lambent has a point. We've had to hard-code our mainframe OSA connections as well as a few of our Sun servers. Let's be sure to place the blame where it lies, though, and that's with Sun and IBM. If a NIC doesn't autonegotiate correctly then it isn't behaving according to the Fast Ethernet standard.

 

[ksas025]

Sorry to break up the conversation here but I just thought I would post what I had to do to correct my problem.

It seems that my interface with the late collisions, FA2/0, was bad. after trying every duplex and speed (and auto) setting combination I could think of, I finally fell back to restarting the router in hopes it would clear something. When it came back up nothing had changed. Errors were coming in even faster than before. Desperate, and out of ideas, I took a shot in the dark and tried to replace the cable between the router and firewall. When I did this, the interface would not come back up. It said interface was up, but link status was always down. I did a no shut command and still no change. Link lights existed on both the interface fa2/0 and the PIX on the other end. Every command I gave I could not get the link status to come up.

So I put the old cable back in service (the one we know is good enough to give connectivity) and the link status would still not come up! Even more confusing is that on the other end of the cable, the PIX, the link status was fine and according to it, connectivity was present.

Luckily, I had another open FA interface on the same card so I moved the connection over to that one and everything came right up. The errors are still present but at a less alarming rate. After this episode, I am beginning to think that maybe that NIM (network interface module) could be to blame. Maybe bad hardware? I hope to sometime in the future replace that NIM to satisfy my curiosity but that will have to wait till later.

Thanks to all who replied.

 

[lambent]

So you said you still experienced errors in the new port on the same module. Did you try to use a new cable on this new port?

Are you using patch panel or direct connection between 7200 and PIX?

On the first problematic FE port, are some of the copper pins inside the port distorted or bent?

 

[ksas025]

Yup. Tried new Cable and interface would not even come up. Link lights present on both devices but the 7200 reported "link status down" when sh int was given.

The connection to the PIX from the 7200 is a direct cross-over cable. I had a small 8port switch in between them before, but took that out during my troubleshooting trials.

Th Copper Pins dont seem to be bent. Even if they were bent on FA2/0, should I stil be seening erros on FA2/1?

Thanks