3750 high drops on port facing WAN

[CSCO12052693]

I have been seeing drops on my port facing my WAN lately. We have a 50mbps pipe going out. I realize the port is set to 100 (hard set for ISP device) but I would think the drops spiking over 50mbps would be on the ISP's equipment. QOS is enabled on the switch but no special commands on the port it's self. Any ideas why I'm seeing this much dropped packets?

Switch#show interface fa1/0/24
FastEthernet1/0/24 is up, line protocol is up (connected)
  Hardware is Fast Ethernet, address is XXXXXXXXXXXXXXXXXXXXXX
  Description: connection to METRO_E
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 3/255, rxload 45/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, media type is 10/100BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input never, output 00:00:27, output hang never
  Last clearing of "show interface" counters 1d00h
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1166
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 17901000 bits/sec, 1813 packets/sec
  5 minute output rate 1339000 bits/sec, 1147 packets/sec
     92018499 packets input, 112419644354 bytes, 0 no buffer
     Received 252027 broadcasts (252027 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 252027 multicast, 0 pause input
     0 input packets with dribble condition detected
     58496196 packets output, 8453613152 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 PAUSE output
     0 output buffer failures, 0 output buffers swapped out
Switch#show run interface fa1/0/24
Building configuration...

Current configuration : 216 bytes
!
interface FastEthernet1/0/24
 description connection to METRO_E
 switchport access vlan 16
 switchport trunk encapsulation dot1q
 switchport mode trunk
 speed 100
 duplex full
end

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Generally, drops are bursts overflowing your queues.  Default QoS settings, divide queues equally between your 4 egress queues, but usually your traffic volume isn't also so equally divided.  I.e., you may need to tuner buffer reservations.

PS:

Considering your total drops vs. total output packets, there may be no real need to tune your buffers.

If you are seeing occasional drops with 100 Mbps, but your WAN's logical cap is 50 Mbps, you may want to determine exactly what you WAN provider does with over cap traffic.  If they police, you may want to "shape" for you 50 Mbps, so you can manage congestion.

The 3750X uplink ports are documented as having the same buffer resources as 24 edge ports, i.e. congested ports may benefit from using uplink ports.  (NB: buffer resource aren't also documented for other 3560/3750 series or models, but good change uplink ports have additional resources on those too.)

[CSCO12052693]

Yea, The traffic vs. drops may not be abnormal. When I first looked into shaping on the 3750 I read that shaping wasn't supported only queuing and congestion avoidance. (not sure the fine line between queuing and shaping).

I am looking into the uplink ports now. I know the 3750v2 has 4 SFP slots that may be considered uplinks. Do you know of any command to verify this?

Thanks for your response

[Joseph W. Doherty · Accepted solution]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

3750 series, support interface commands, per egress queue shaping (srr-queue bandwidth shape # # # #), and port "shaping" (srr-queue bandwidth limit #).  (For you, the latter command set to 50, might be worth trying.)

Yea, the SFP ports should be considered uplinks, but, again, the documentation I saw only explicitly identified the 3750X.  Don't know of any command to verify physical buffer resources per port, or ports.  Suppose if you ran an identical configuration on an edge port and SFP port, and saw less drops on the latter (for the same traffic), this would imply additional buffer resources.

[CSCO12052693]

I appreciate the help.  I'll probably do a combination of moving to the SFP ports and adding the SRR commands. We have them applied on ports to the end users but not on the Metro line it's self.