QoS Selectors

Unanswered Question
Mar 20th, 2009
User Badges:
  • Purple, 4500 points or more

All,


I have a router with a basic policy-map:


policy-map VOIP

class VOIP

priority 768

class class-default

fair-queue

random-detect dscp-based



cs6 71855/4018548 0/0 0/0 32 40 1/10



When I do a "sh policy-map inter s0/0", I get matches on CS6 under the class-default. If I'm not marking the packet, is the device? Is this where remarking comes in if I want to change what it wants to report?


I think this is a video camera that has an embedded web server. I've been fighting with voip phones at this location, and this video system has traffic pegged at 100% when they're connected to it with high resolution. I haven't been able to convince anyone at the location to use low res yet. If I want to control the amount of traffic going from that device, should I shape that traffic or police it? The phones will stay the same at 768k, and this is on a T1 P2P circuit.


Thanks,

John

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (7 ratings)
Loading.
Jon Marshall Fri, 03/20/2009 - 06:52
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

John


CS6 is used by Cisco devices themselves for certain priority traffic so that is what you are probably seeing altho it could be traffic you want prioritized - difficult to say.


Is the video traffic from the phone traffic ?. If so shaping would probably be the preferred option altho bear in mind some latency sensitive traffic does not like shaping.


Jon

John Blakley Fri, 03/20/2009 - 06:57
User Badges:
  • Purple, 4500 points or more

The video is from a security camera on T1 Side A. A user on the T1 Side B, connects to the camera using special software (which is really web-base) and stays in it all day. I've asked the IT contact at that location to make sure that everyone is in low res because that user brings down their packetshaper when they're connected to it. This also destroys the phone quality in Side A.


Personally, the phone quality is more important to me than them being able to connect to the security camera and stay in it in high res all day long, but I'm not sure about the best way to fix it.


Thanks Jon,


John

Joseph W. Doherty Fri, 03/20/2009 - 07:45
User Badges:
  • Super Bronze, 10000 points or more

re: Phone quality


The video stream shouldn't impact your VoIP. Two items to check: 1) how's your voice signally being QoS'ed?, 2) what's the size of the hardware FIFO buffer?


re: video stream vs. non-VoIP


I would recommend you provide the video stream it's own dedicated class. You could shape or police it then, but perhaps just provide it a minimal bandwidth guarantee. This way you can say you're not doing anything to impede it, but if it has poor performance, there's just not enough bandwidth to support it (although there might be for a lower res stream). (NB: placing the video into a separate class might fix your voice issue.)


e.g.

policy-map VOIP


class VOIP

priority 768


class SecCam

!you'll need to define the class-map

bandwidth percent 1


class class-default

fair-queue

random-detect dscp-based


PS:

I would also recommend against using random-detect in class-default (for two reasons).

John Blakley Fri, 03/20/2009 - 07:49
User Badges:
  • Purple, 4500 points or more

Joseph,


"what's the size of the hardware FIFO buffer"


How can I find this out, and what's the recommended size? Also, is there a stipulation with FIFO size vs. available memory, i.e. 75% of Available memory is the max a FIFO buffer can be.


Why would you recommend the random-detect be taken out of class-default? Do you think that could be causing some of the issue?


Thanks!


John

Joseph W. Doherty Fri, 03/20/2009 - 09:11
User Badges:
  • Super Bronze, 10000 points or more

"How can I find this out, and what's the recommended size?"


I recall the setting can be seen with a show controllers command. (NB: For typical T1, it probably already defaulted to a small value, but can often be adjust with tx-ring-limit. For VoIP, you sometimes want to decrease the value.)


"Why would you recommend the random-detect be taken out of class-default"

Two reasons:

1) It really intended just for TCP

2) Since WFQ is active, I prefer to allow individual flow queue drops - WRED is more oriented for FIFO


"Do you think that could be causing some of the issue? "


Yes, but removing it alone, may not fix the issue. (It might, since you have lots of WRED drops shown in your another post.)


[edit]

Always hard to read the compressed whitespace posts. You may have many less drops then I thought.

[edit2]

Ah, only 78 total.

Joseph W. Doherty Fri, 03/20/2009 - 10:46
User Badges:
  • Super Bronze, 10000 points or more

If the above doesn't correct the issue, also try "tx-ring-limit 2" on your serial interface.


If the issue still exists, let us know.


PS:

If you prefer, you can also use the minimum absolute bandwidth value for the SecCam class (8?).

Edison Ortiz Fri, 03/20/2009 - 07:54
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

Hi John,


As Jon stated CS6 is used for routing protocols in Cisco IOS and I don't recommend having any other traffic using that marking.


It seems the appliance you are using, it uses that QoS marking and the switchport where is connected to is simply passing the marking all the way to the router.


I remember you have Dell switches (we need to get you some Cisco switches in there :)) so we can't help much on it but you can remark the traffic incoming on the router with a MQC matching on the src-ip/src-port and apply a police (not to limit but to remark that traffic).


For instance(from the top of my head, don't have any equipment at the moment):


ip access-list extended Video-Camera

permit [video-camera ip and src port]


class-map Video-Camera

match ip access-group name Video-Camera


policy-map Inbound-MQC

class Video-Camera

police 8000 1000 conform-action set dscp AF31 exceed-action set dscp AF31

class class-default

random-detect dscp-based


Then, outbound you need to determine what to do with the traffic. I say go for shaping but I don't know the nature of the traffic and if shaping can create problems but at least, you've taken that kind of traffic out of CS6 and place into AF31.


HTH,


__


Edison.

John Blakley Fri, 03/20/2009 - 08:04
User Badges:
  • Purple, 4500 points or more

Thanks Edison. That makes sense.


The policy on side A (video camera side) is applied outbound, and the policy on side b (user side) is applied outbound as well. If I'm shaping on side a, do I need to do anything on side b for inbound?


John

Edison Ortiz Fri, 03/20/2009 - 08:08
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

I'm assuming that's after you've remarked the traffic?


Yes, if you've decided to shape the traffic on side A, it will be controlled there.


Have you verified that shaping may be a solution? You can use bandwidth guarantee instead. I believe the reason the voice was being affected was due to having the marking on CS6.


Change the marking first before deploying shaping and see if the VoIP improves.


__


Edison.

John Blakley Fri, 03/20/2009 - 08:10
User Badges:
  • Purple, 4500 points or more

I'll attempt that and see what happens.


Thanks!

John

John Blakley Fri, 03/20/2009 - 08:08
User Badges:
  • Purple, 4500 points or more

Oh, and once again the math is throwing me:


is "police 8000...."


is 8000 equivalent to 8k of bandwidth?

Edison Ortiz Fri, 03/20/2009 - 08:10
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

Yes, but in this case, you aren't policing the traffic to 8kbps. You are remarking everything that matches the class to AF31.


__


Edison.

John Blakley Fri, 03/20/2009 - 08:12
User Badges:
  • Purple, 4500 points or more

So because I'm remarking, the police values (being that they're required) are arbitrary values that won't be used for dropping excessive traffic?


John

Edison Ortiz Fri, 03/20/2009 - 08:15
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

Correct, the transmit|exceed option on the police command are the key options on what to do with the traffic based on the [bandwidth value] assigned to the command itself.


If you noticed, in my transmit and exceed options, I'm not saying to drop the traffic. I'm instructing the router to forward it but to apply a marking of AF31.


Please be aware to check the syntax as I did the whole thing without any equipment.


__


Edison.

Edison Ortiz Fri, 03/20/2009 - 08:20
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

BTW, if policing confuses you there :) You can do the same with the following:


ip access-list extended Video-Camera

permit [video-camera ip and src port]


class-map Video-Camera

match ip access-group name Video-Camera


policy-map Inbound-MQC

class Video-Camera

set dscp AF31

class class-default

random-detect dscp-based


This is a more straightforward approach :)


With the police command, you have the ability to remark traffic that meets the bandwidth requirement and remark traffic with another marking that exceeds the bandwidth. Pretty useful tool.




John Blakley Fri, 03/20/2009 - 08:47
User Badges:
  • Purple, 4500 points or more

I started thinking about this. Because I'm seeing traffic matching on the VoIP class, is all of my other default traffic that's coming through the switch being marked as CS6?


Serial0/0


Service-policy output: VOIP


Class-map: VOIP (match-any)

21716081 packets, 1988364582 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group 110

21716080 packets, 1988364562 bytes

5 minute rate 0 bps

Queueing

Strict Priority

Output Queue: Conversation 264

Bandwidth 768 (kbps) Burst 19200 (Bytes)

(pkts matched/bytes matched) 1797007/175537353

(total drops/bytes drops) 0/0


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

22479678 packets, 16547729203 bytes

5 minute offered rate 5000 bps, drop rate 0 bps

Match: any

Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 256

(total queued/total drops/no-buffer drops) 0/78/0

exponential weight: 9


dscp Transmitted Random drop Tail drop Minimum Maximum Mark

pkts/bytes pkts/bytes pkts/bytes thresh thresh prob

af11 0/0 0/0 0/0 32 40 1/10

af12 0/0 0/0 0/0 28 40 1/10

af13 0/0 0/0 0/0 24 40 1/10

af21 0/0 0/0 0/0 32 40 1/10

af22 0/0 0/0 0/0 28 40 1/10

af23 0/0 0/0 0/0 24 40 1/10

af31 0/0 0/0 0/0 32 40 1/10

af32 0/0 0/0 0/0 28 40 1/10

af33 0/0 0/0 0/0 24 40 1/10

af41 0/0 0/0 0/0 32 40 1/10

af42 0/0 0/0 0/0 28 40 1/10

af43 0/0 0/0 0/0 24 40 1/10

cs1 0/0 0/0 0/0 22 40 1/10

cs2 0/0 0/0 0/0 24 40 1/10

cs3 0/0 0/0 0/0 26 40 1/10

cs4 0/0 0/0 0/0 28 40 1/10

cs5 0/0 0/0 0/0 30 40 1/10

cs6 72372/4055890 0/0 0/0 32 40 1/10

cs7 0/0 0/0 0/0 34 40 1/10

ef 0/0 0/0 0/0 36 40 1/10

rsvp 0/0 0/0 0/0 36 40 1/10

default 22407237/16543569726 78/106186 0/0 20 40 1/10


Also, I looked at the QoS mappings on the switch, and if I'm reading them right, it looks like CS6 is the same thing as DSCP 4 (I'm not sure though.)


Thanks!

John

Joseph W. Doherty Fri, 03/20/2009 - 09:19
User Badges:
  • Super Bronze, 10000 points or more

"it looks like CS6 is the same thing as DSCP 4 (I'm not sure though.) "


No, they're different.


Edison Ortiz Fri, 03/20/2009 - 09:21
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

No, you have CS6 and other traffic:


cs6 72372/4055890 0/0 0/0 32 40 1/10


default 22407237/16543569726 78/106186 0/0 20 40 1/10


__


CS6 = to DSCP 4? That mapping is bad. CS6 = Binary 110 000 = DSCP 48



John Blakley Fri, 03/20/2009 - 09:22
User Badges:
  • Purple, 4500 points or more

This is what the switch is showing me:


Dscp-queue map:

d1 : d2 0 1 2 3 4 5 6 7 8 9

-------------------------------------

0 : 01 01 01 01 01 01 01 01 01 01

1 : 01 01 01 01 01 01 02 02 02 02

2 : 02 02 02 02 02 02 02 02 02 02

3 : 02 02 03 03 03 03 03 03 03 03

4 : 03 03 03 03 03 03 03 03 04 04

5 : 04 04 04 04 04 04 04 04 04 04

6 : 04 04 04 04


Now you can see why I'm wondering what it's doing. This is the evil Dell switch :-)


John



Edison Ortiz Fri, 03/20/2009 - 09:31
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

That's a dscp to queue map and DSCP48 is placed in Queue 4 highlighted below:


Dscp-queue map:

d1 : d2 0 1 2 3 4 5 6 7 8 9

-------------------------------------

0 : 01 01 01 01 01 01 01 01 01 01

1 : 01 01 01 01 01 01 02 02 02 02

2 : 02 02 02 02 02 02 02 02 02 02

3 : 02 02 03 03 03 03 03 03 03 03

4 : 03 03 03 03 03 03 03 03 04 04

5 : 04 04 04 04 04 04 04 04 04 04

6 : 04 04 04 04


Edit: Misread the map, it looks like a dscp-cos map while it was a dscp-queue map.


Do you have any other maps?




John Blakley Fri, 03/20/2009 - 09:53
User Badges:
  • Purple, 4500 points or more

So, I take it that the switch may not be causing my problem with marking the traffic incorrectly?


Oh, I see how to read this chart:


DSCP 48 is d1(4) -> d2(8)....


I found a dscp-dscp mutation map that looks like this, but the numbers that this chart showed when compared to the dscp mutation map would show that it's going to send a packet received on an ingress port as dscp 04 which doesn't look right. Maybe I'm looking at it in reverse, and it receives dscp48 and sends out as CoS4?


Thanks,

John

Edison Ortiz Fri, 03/20/2009 - 09:59
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

Maybe I'm looking at it in reverse, and it receives dscp48 and sends out as CoS4?


We would need to see the mapping for that before coming to that conclusion. It's a Dell switch :)



Joseph W. Doherty Fri, 03/20/2009 - 10:31
User Badges:
  • Super Bronze, 10000 points or more

"Oh, I see how to read this chart:


DSCP 48 is d1(4) -> d2(8).... "


Correct.


"Maybe I'm looking at it in reverse, and it receives dscp48 and sends out as CoS4? "


Well, 1) map is labeled "Dscp-queue map:", 2) IEEE 802.1Q CoS values are 0..7; these are the reasons I believe "4" to be queue 4, not a CoS 4, but if you can find a manual for the device, it would likely indicate which.

John Blakley Fri, 03/20/2009 - 10:51
User Badges:
  • Purple, 4500 points or more

The only other map that I found was the cos-queue map:


Cos-queue map:

cos-qid

0 - 1

1 - 1

2 - 2

3 - 2

4 - 3

5 - 3

6 - 4

7 - 4


It looks like it *should* be going in queue 3, but I'm not sure how to tell what queue 3 is. All of the ports are to trust the dscp markings.


This is the only other map that I had. There's not much you can do with these switches.


John

Edison Ortiz Fri, 03/20/2009 - 10:58
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

Ok, fair enough. We are digressing here :)


The router is receiving CS6 and the switch isn't remarking the packet.


If you know the src-ip and src-port, create an ACL at the router - match that ACL on a class-map and remark it to AF31.


If you know how to remark packets in the Dell switch or have the ability to change the QoS config on the appliance itself - then that can be another option.


Right now, I can only help you how to do it at the router :)


__


Edison.

John Blakley Fri, 03/20/2009 - 11:00
User Badges:
  • Purple, 4500 points or more

I completely agree; I think we're beating a dead horse =)


I'm sure I'll have other questions about something else later, but for now we'll let this thread die. ;-)


Thanks!

John

Joseph W. Doherty Fri, 03/20/2009 - 09:37
User Badges:
  • Super Bronze, 10000 points or more

It looks like Dell maps DSCP values into one of 4 queues. CS6 is(?) mapping into Q4, and if that's a priority queue (or gets most of the bandwidth), that could explain some of your problem but only if the switch port is congested or Dell is doing some kind of shaping.


John Blakley Fri, 03/20/2009 - 10:41
User Badges:
  • Purple, 4500 points or more

Oh, and I'm not crazy about these Dell switches just to let you know :)

Actions

This Discussion