Where should I shape my traffic

phoeneous

Long story short, I need to shape traffic at one of my mpls sites. Remote office, 12 users, 1.5M t1. Recent changes with our provider is causing issues with this site to suffer massive packet loss when the serial link is saturated. I've had the same qos setup on my CE router for a year and the link has seen occasional saturation for that long as well, never experienced this much packet loss until now. But I digress.

Should I:

a) Shape outbound on the switch trunk port to gateway
b) Shape inbound on gateway port from switch
c) Shape outbound on serial interface

Any suggestions are appreciated.

This is my qos policy. Class-default is what is getting dropped.


class-map match-any CALL_SIGNALING
match dscp cs3
match dscp af31
class-map match-any DROP
match protocol bittorrent
match protocol edonkey
match protocol gnutella
match protocol kazaa2
match protocol irc
match protocol vdolive
class-map match-any CRITICAL_DATA
match dscp cs2
match dscp cs6
match dscp af21
match dscp af22
match dscp af23
class-map match-any VOICE
match dscp ef
!
!
policy-map WAN_QOS
class VOICE
priority percent 33
class CALL_SIGNALING
bandwidth percent 5
class CRITICAL_DATA
bandwidth percent 5
class DROP
drop
class class-default
fair-queue
random-detect

NetworkVeteran

b) Shape inbound on gateway port from switch

Without reading over the details of the scenario, I can rule that one out! "Shaping implies the existence of a queue and of sufficient memory to buffer delayed packets, while policing does not. Queueing is an outbound concept; packets going out an interface get queued and can be shaped. Only policing can be applied to inbound traffic on an interface."

Comparing Traffic Policing and Traffic Shaping for Bandwidth Limiting* [QoS Policing] - Cisco Systems

NetworkVeteran

After reading over the scenario, but not the configuration, I would opt for--

c) Shape outbound on serial interface

In the absence of a compelling reason to do otherwise, shape as close to the problem link as possible.

phoeneous

The issue is pointing to the provider side. I think they changed qos policies somewhere because traffic never used to be policed this much before.