03-20-2009 06:41 AM - edited 03-04-2019 04:01 AM
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
03-20-2009 06:52 AM
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
03-20-2009 06:57 AM
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
03-20-2009 07:45 AM
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).
03-20-2009 07:49 AM
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
03-20-2009 09:11 AM
"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.
03-20-2009 10:46 AM
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?).
03-20-2009 07:54 AM
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.
03-20-2009 08:04 AM
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
03-20-2009 08:08 AM
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.
03-20-2009 08:10 AM
I'll attempt that and see what happens.
Thanks!
John
03-20-2009 08:08 AM
Oh, and once again the math is throwing me:
is "police 8000...."
is 8000 equivalent to 8k of bandwidth?
03-20-2009 08:10 AM
Yes, but in this case, you aren't policing the traffic to 8kbps. You are remarking everything that matches the class to AF31.
__
Edison.
03-20-2009 08:12 AM
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
03-20-2009 08:15 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide