Cisco WAN qos versus/and Packeteer shaper

[thomas.fayet]

Hello ALL .

I am troubleshooting an MPLS VPN qos issue for one of my customer and we are actually discussing on the integration of their packeteer packet shapers on each eadge of the Network . The topology is as follow :

Customer lan --------- customer packet shaper ---------- CE ---------- MPLS backbone ----------------CE -------------- customer PS ----------- customer LAN .

- The CE router has the following QOS implemented outbound towards the MPLS backbone

     - 3 data classes

     - 60% for d1 - 30% for d2  - 10% for d3 , this class being the default class

     - We mark and classify the traffic on the CE router lan interface with access-list for each class :

          - tcp traffic in d1

          - www in d2

          - permit ip any any in d3 as this is the default .

When doing a "show policy int <bla> output" on the CE wan interace I see the following

          - not much traffic in D1

          - not much traffic in D2

          - D3 class "full" with lots of tail drops in it ....... 

My questions are :

          - There is a tunnel between the 2 PS . If the customer is already marking it's traffic on the packet shapers shall we keep on (re) marking this               same traffic on the cisco router ? I would personaly say that I should just <match dscp <bla> on the router to comply and be consistent with             the client marking in case the PS goes down isnt' it ?

          - Now if the customer is not marking his traffic on his PS , shall I do it on the router , is the router able to "see" the packet being                             encapsulated by the PS ?

          - Now the qos mechanism itself : at T0 , if D1 and D2 are "empty" I think D3 is potentially able to take this bandwidth and use it for itself.

          If after that I still see tail drops in D3 it means the IPVPN bw for this particular site is just too small for the amount of traffic they sent isn't it ?

Well I am basically looking for guidelines on how to integrate a packet shaper with qos mechanism into an MPLS VPN .

Thanks in advance for your responses and let's the discussion begin !

Rgds

T.

[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

I haven't worked with a Packeteer shaper but I would have expected, if it shapes, and all traffic passes through it first, and it's active, that you shouldn't see or need any QoS on the router and this should all be managed on the Packeteer appliance.

You certainly could configure the router's QoS features to act as a backup for the Packeteer assuming the device goes off-line but allows traffic to continue to flow through it or if traffic has been "repatched" around it.  For such a QoS implementation, you might only mark packets (on CE ingress) not being tunneled by the Packeteer.  (I'm assuming you can recognize Packeteer tunneled packets.)  Then regardless of the source of the marking for the packets, you "trust" packet markings for CE egress as appropriate.

PS:

From your description, I assume the bulk of the D3 traffic is Packeteer tunnel traffic.  If true, why are you seeing any D1 or D2 class traffic?

Tail drops, of course, indicates queue exhaustion.  This could be becuase of "too much" traffic, always possible whenever bandwidth is oversubscribed (most often the case) but it could also be because queue depth is insufficient for transient bursts.

In cases of bandwidth oversubscription, drops are often "normal".  However, I thought a selling point of a Packeteer appliance was that it managed traffic such that drops shouldn't be happening.

Again, I haven't worked with a Packeteer appliance, but from what I've read of their features, perhaps these appliances are not properly configured.