QoS class class-default

Unanswered Question
Nov 17th, 2008
User Badges:

Hello all,


in my WAN three classes of service exists, EF, AF41 and default.


On the ingress of all WAN routers I have the following config:

policy-map from-LAN

class real-time

set dscp ef

class mission-critical

set dscp af41

class class-default

set dscp default


But I still see other traffic classes leaving the WAN interface of that router e.g. AF31, CS6, CS3, CS2

The only one I understand is CS6, as those packets generated by the router itself and therefore not remarked at the ingress.


Also if I check the policy-map, I that not all packets associated with class class-default are remarked (not remarked around 1,5% of all packets).


Any ideas?


Best regards,

Andreas


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Joseph W. Doherty Mon, 11/17/2008 - 20:30
User Badges:
  • Super Bronze, 10000 points or more

You note the policy is configured for WAN ingress? The policy looks more suitable for either LAN ingress or WAN egress. If you don't mark packets on LAN ingress or WAN egress, this might explain why you're seeing more than 3 markings.

dancarrick Mon, 11/17/2008 - 22:58
User Badges:

Andreas,


Can you post the output of the following?


show policy-map interface




andreas.plaul Tue, 11/18/2008 - 01:19
User Badges:

Hello,


the policy-map is applied on the LAN ingress.


Below the output of the show policy-map interface:


FastEthernet0/0


Service-policy input: from-LAN


Class-map: real-time (match-any)

100581560 packets, 19738877717 bytes

5 minute offered rate 193000 bps, drop rate 0 bps

Match: protocol rtp

89632333 packets, 17383775517 bytes

5 minute rate 166000 bps

Match: access-group name VoIP-RTCP

10949228 packets, 2355102414 bytes

5 minute rate 18000 bps

QoS Set

dscp ef

Packets marked 100581565


Class-map: mission-critical (match-any)

18847230 packets, 4995470076 bytes

5 minute offered rate 6000 bps, drop rate 0 bps

Match: access-group name Voice-Control

8996464 packets, 707126788 bytes

5 minute rate 3000 bps

Match: access-group 120

9850767 packets, 4288343288 bytes

5 minute rate 2000 bps

QoS Set

dscp af41

Packets marked 18847236


Class-map: class-default (match-any)

429942156 packets, 346709971864 bytes

5 minute offered rate 7569000 bps, drop rate 0 bps

Match: any

QoS Set

dscp default

Packets marked 25175678


Best regards,

Andreas

Joseph W. Doherty Tue, 11/18/2008 - 04:24
User Badges:
  • Super Bronze, 10000 points or more

I misread your original post as marking at WAN (interface) ingress when you stated WAN router ingress.


What you're doing appears correct, at least for LAN ingress to one of your WAN routers, and as you note, WAN router sourced packets could be marked differently.


How are you monitoring the other packet markings they you believe have unexpected markings?

andreas.plaul Tue, 11/18/2008 - 17:03
User Badges:

Hello,


I am monitoring with Netflow the outgoing WAN traffic (with the markings set) and there I see packets marked with dscp values which are not generated by the router, so not only cs0, ef, af41, cs6(routing updates, but also traffic marked with af31, af11, cs2.


Regards,

Andreas

Joseph W. Doherty Tue, 11/18/2008 - 17:22
User Badges:
  • Super Bronze, 10000 points or more

I wonder if Netflow is providing you the packet's original markings.


You might also try an ingress service policy on a WAN interface and see what it records as being received for various DSCPs.


What type of WAN devices are you using and their IOS versions?

andreas.plaul Wed, 11/19/2008 - 00:26
User Badges:

Hello,


the routers are 3745, IOS Version 12.3(7)T and the Netflow is from Solarwinds. I mean, I have to trust the Netflow to provide the correct packet markings, otherwise it doesn't make sense.


Regards,

Andreas

Joseph W. Doherty Wed, 11/19/2008 - 03:39
User Badges:
  • Super Bronze, 10000 points or more

What you're seeing doesn't make sense (if all is as you've described).


As far as trusting Netflow, you may want to "trust but verify". This especially so since your running an early 12.3 "T" version. If you have maintenance, would suggest loading the latest 12.4.


If Netflow is providing original packet markings, Cisco might not even consider this a bug, it might be a "feature". It also might be documented somewhere in order of operation of various features.


I often use an inbound policy to check incoming DSCP markings. Provides a quick method to see inbound rates for the various DSCP markings.


Policy can be simple, something like:


class-map match-any someclass

match ip dscp ef

match ip dscp cs7

match ip dscp cs6

match ip dscp cs5

match ip dscp af41

match ip dscp af42

.

.

match ip dscp be


service-policy somename

class someclass


interface serial #

service policy input somepolicy

Actions

This Discussion