Solved

Cisco Router 3640 Seeing collisions and dropped packets...

Posted on 2004-10-15
14
415 Views
Last Modified: 2013-12-07
I posted yesterday regarding the same issue. With some help, I determined it was a duplexing issue. We have three switches in the mix, none of them are managed so it is hard to say exactly what is happening on the switch's end. LED readouts are not always honest with you.

I took the advice i received yesterday and set both ethernet interfaces to half duplex and I am seeing better performance then I was but I am still seeing collisions and dropped packets. I see a lot of spikes even when we are not experiencing any kind of a load.

Again the Router is a Cisco 3640
Three ethernet interfaces, only two being used, the other I have shut. Class C split up into two subnets. Each ether interface routing a single subnet.
Everything looks fine on the serial side.

It could still be a duplexing issue.

Any ideas?

Any help would be greatly appreciated.
0
Comment
Question by:coleresources
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 8
  • 6
14 Comments
 

Author Comment

by:coleresources
ID: 12320741
Lastnight, I tried to rule out each switch to make sure they weren't problematic. Didn't see much of a change taking them out of the mix. Collisions and spikes every which way.

To save anyone who might respond some time. I did replace patch cables, even elliminated all but maybe 3 machines on the network as far as a possibile points of collision.

Here are the two ether configs:

Ethernet1/0 is up, line protocol is up
  Hardware is AmdP2, address is 00b0.xxxx.e111 (bia 00b0.xxxx.e111)
  Internet address is 66.xxx.xxx.126/25
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
     reliability 255/255, txload 7/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:02, output 00:00:00, output hang never
  Last clearing of "show interface" counters 1d09h
  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 2000 bits/sec, 2 packets/sec
  5 minute output rate 309000 bits/sec, 300 packets/sec
     742033 packets input, 188881301 bytes, 0 no buffer
     Received 2730 broadcasts, 0 runts, 0 giants, 0 throttles
     28767 input errors, 28767 CRC, 14363 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     27154290 packets output, 3649239068 bytes, 0 underruns
     400 output errors, 7060 collisions, 2 interface resets
     0 babbles, 0 late collision, 4069 deferred
     400 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out


Ethernet2/0 is up, line protocol is up
  Hardware is AmdP2, address is 00b0.xxxx.e121 (bia 00b0.xxxx.e121)
  Internet address is 66.xxx.xxx.254/25
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
     reliability 255/255, txload 1/255, rxload 97/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 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 3835000 bits/sec, 369 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     7680296 packets input, 1122703180 bytes, 0 no buffer
     Received 2427 broadcasts, 0 runts, 0 giants, 0 throttles
     3 input errors, 1 CRC, 1 frame, 0 overrun, 2 ignored
     0 input packets with dribble condition detected
     222161 packets output, 49623925 bytes, 0 underruns
     4627 output errors, 73289 collisions, 3 interface resets
     0 babbles, 0 late collision, 14273 deferred
     4466 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

0
 
LVL 79

Expert Comment

by:lrmoore
ID: 12320778
>set both ethernet interfaces to half duplex
In any network using half-duplex, collisions, retransmits and dropped packets are all very expected behavior. These are all designed into the Collision Detection/Avoidance mechanisms of Ethernet.
The more traffic, the more collisions and dropped packets.
TCP/IP has mechanisms to recover from the dropped packets.

As long as you don't have a high percentage of collisions, then it appears that everything is working as designed.

Looking back at your previous post, it does not appear that you had a duplex-mismatch issue to start with:

  10013 input errors, 10013 CRC, 5043 frame, 0 overrun, 0 ignored  <== typically these point to layer 1 defects (bad cables)
     0 input packets with dribble condition detected
     9460395 packets output, 1225723073 bytes, 0 underruns
     94 output errors, 0 collisions, 0 interface resets   <=== collisions would normally increase if you had duplex issues

Did you replace the patch cables as JFrederick suggested?


0
 

Author Comment

by:coleresources
ID: 12320791
http://www.experts-exchange.com/Networking/Q_21168787.html

This is my prior post so you can view what was discussed.

Best Regards
0
Resolve Critical IT Incidents Fast

If your data, services or processes become compromised, your organization can suffer damage in just minutes and how fast you communicate during a major IT incident is everything. Learn how to immediately identify incidents & best practices to resolve them quickly and effectively.

 
LVL 79

Expert Comment

by:lrmoore
ID: 12320827
<8-}
I guess we posted at the same time!

You are suffering 32% collision rate  (73289 collisions / 222161 packets)
This is unacceptible..

plus --    4466 lost carrier, 0 no carrier

Highly suggest that you put the interface back to auto duplex...

Just another suggestion (unrelated to the error problem):
  > ip access-group 110 in
  > ip access-group 110 out

It is highly discouraged to use the same acl in both directions....

0
 

Author Comment

by:coleresources
ID: 12320998
>To save anyone who might respond some time. I did replace patch cables, even elliminated all but maybe 3 machines on the network as far as a possibile points of collision.

If you look at the ether configs I posted today, there are many more collisions then what was seen yesterday with those interfaces set to half duplex but a lot less dropped packets.

When set to full duplex (both ethernet interfaces), I don't see the collisions or CRC erros but I experience 60% loss on the second subnet (Ether2/0). When set to half duplex, I am seeing a lot less loss but am still experiencing enough of it that I have to take notice. We don't want to run at half duplex period but we were seeing so much loss at full duplex, this was a temporary solution. We have 6 T1's bonded right now, so until we figure out what is causing this, we are only going to see maybe 4megs of that bw which is going to throttle us. I did not know before yesterdays post that that so many collisions were to be expected in the current environment. I haven't seen nearly so many in others that I maintain so it did strike me as odd. I am still learning though.

I am not saying this is a duplexing issue, I was just stating what I was assuming after seeing it improve once setting it to half duplex yesterday.

I don't know what is wrong.
0
 

Author Comment

by:coleresources
ID: 12321005
I don't have an option to set to auto. I can set to half or full unless I am missing something.
0
 

Author Comment

by:coleresources
ID: 12321036
>Just another suggestion (unrelated to the error problem):
  > ip access-group 110 in
  > ip access-group 110 out

I am not at all arguing but can you tell me why?

I'd just like to know, probably a stupid question but I'll ask it anyway.

Thanks!
0
 
LVL 79

Accepted Solution

by:
lrmoore earned 500 total points
ID: 12321473
The correct syntax for auto mode:
  interface Eth1/0
    no full-duplex

By specifying neither full nor half-duplex, the interface is in auto mode.
Once you change the mode, bounce the interface (shut, then no shut),

Access-lists are created with <source> <destination> in mind.
 The souce and destination coming "in"to the interface are the exact opposite of the source/destination coming "out"of an interface. It just doesn't make sense.
Also, acls are typically created to serve a specific function, to control activity from <source> to <destination>, and you can use hit-counts to monitor. If you use the same acl for both in and out, you can't monitor the direction the traffic originated from.

Just my $.02 for what it's worth...

0
 

Author Comment

by:coleresources
ID: 12322133
Yeah, it makes sense what you had to say about the acl's. The way I have it configured defeats the purpose.

I did set it to auto duplex using the syntax your provided but I am still seeing collisions...Any other suggestions?

Thanks for your responses!

0
 
LVL 79

Expert Comment

by:lrmoore
ID: 12324294
>but I am still seeing collisions...
If you see collisions, then most likely the interfaces have negotiated to half-duplex. That's OK as long as the percentage is not as high as it was..
0
 

Author Comment

by:coleresources
ID: 12324408
Do you think installing a managed switch that I can force to full duplex, I will be able to run the router in full without the collisions?
0
 
LVL 79

Expert Comment

by:lrmoore
ID: 12324427
Absolutely!
0
 

Author Comment

by:coleresources
ID: 12324444
Thanks for your time. There may be more to it but I have learned something through this process and you have helped me to improve on it...So I will accept...

Thanks a lot man.
0
 
LVL 79

Expert Comment

by:lrmoore
ID: 12324508
Glad to help!
0

Featured Post

Resolve Critical IT Incidents Fast

If your data, services or processes become compromised, your organization can suffer damage in just minutes and how fast you communicate during a major IT incident is everything. Learn how to immediately identify incidents & best practices to resolve them quickly and effectively.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

When you try to share a printer , you may receive one of the following error messages. Error message when you use the Add Printer Wizard to share a printer: Windows could not share your printer. Operation could not be completed (Error 0x000006…
This article will inform Clients about common and important expectations from the freelancers (Experts) who are looking at your Gig.
Here's a very brief overview of the methods PRTG Network Monitor (https://www.paessler.com/prtg) offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're looking for how to monitor bandwidth using netflow or packet s…

726 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question