• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1114
  • Last Modified:

Output drops on GE port

We have a Catalyst 4510R connected to a Catalyst 3750-48. We're pumping alot of traffic towards the 3750. We're getting some drops on both the interfaces. It looks to me to be about 1%. Looking for some input as far aswhat other folks have seen and what is acceptable dropped packet levels.

sdgwsw8#sh int g9/15
GigabitEthernet9/15 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet Port, address is 0012.4360.d90e (bia 0012.4360.d90e)
  Description: SDSW-SECOPS-DCC01 1/0/52
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 69/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, link type is auto, media type is 10/100/1000-TX
  input flow-control is off, output flow-control is off
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:13, output never, output hang never
  Last clearing of "show interface" counters 00:37:08
  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 75485
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 273617000 bits/sec, 183356 packets/sec
     155 packets input, 14456 bytes, 0 no buffer
     Received 155 broadcasts (155 multicast)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     390518362 packets output, 70251652150 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out
sdgwsw8#sh int g8/15
GigabitEthernet8/15 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet Port, address is 0012.4360.d7ee (bia 0012.4360.d7ee)
  Description: SDSW-SECOPS-DCC01 1/0/51
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 67/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, link type is auto, media type is 10/100/1000-TX
  input flow-control is off, output flow-control is off
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:19, output never, output hang never
  Last clearing of "show interface" counters 00:37:12
  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 882
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 266254000 bits/sec, 182971 packets/sec
     530 packets input, 55244 bytes, 0 no buffer
     Received 154 broadcasts (154 multicast)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     396019337 packets output, 69365622247 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped ou
0
vince_mele
Asked:
vince_mele
  • 2
1 Solution
 
mikebernhardtCommented:
Output drops are usually caused by congestion- the interface buffers fill up and drop the excess. The only solution is more bandwidth or QOS. More bandwidth would mean a port channel, but that will only help with diverse traffic. If it's all got the same source and dest it won't help.
0
 
Scotty_ciscoCommented:
these 2 ports are output what does the input look like?  The ports look fairly clean and I would say given the amount of traffic that you are well with in what is acceptable and I am sure that is what Cisco would tell you if you opened a case.

thanks
Scott
0
 
mikebernhardtCommented:
Now, given the number of packets per second you're pushing, the number of dropped packets is pretty small really. On the first interface, it's actually only .02%, not 1% (75K drops out of 390 million packets). So I wouldn't worry about it.
0
 
vince_meleAuthor Commented:
Thanks gentlemen
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now