Solved

Cisco Router 3640 Seeing collisions and dropped packets...

Posted on 2004-10-15
14
408 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
  • 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
 
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
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 
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

Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

Network ports are the threads that hold network communication together. They are an essential part of networking that can be easily ignore or misunderstood, my goals is to show those who don't have a strong network foundation how network ports opera…
Load balancing is the method of dividing the total amount of work performed by one computer between two or more computers. Its aim is to get more work done in the same amount of time, ensuring that all the users get served faster.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…

746 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

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now