09-14-2008 09:31 PM - edited 03-03-2019 11:32 PM
Dear Sir,
I have a query on video/data traffic. I have a head office and two branch office .The two branch offices were connected to head office through leased line. In branch office we are having CC cameras (not Cisco), for monitoring the staff .As the monitoring is done at head office my data traffic is going down. I came to know that QOS will help me in this issue .Please help me to resolve this issue.
Please find the attached doc.please give me configuration example also...
Regards,
satya.
09-15-2008 02:51 AM
Hello Satya,
first of all I would look at the cameras configuration because using a lower definition for the video stream will allow to use less bandwidth.
Once that there is some space for traffic you can use modular QoS to provide some resources to data traffic.
You need to define traffic classes with the class-map object
Let's suppose that the video stream use RTP realtime transport protocol
access-list 125 permit udp any any eq 16232 range 16232
class-map video_traffic
match ip address 125
policy-map scheduler-2mbps
class-map video
bandwidth 768
class-map class-default
fair-queue
on interface outgoing the branch router
int ser0/0
service-policy output scheduler-2Mbps
we had similar issues and we had to use a lower definition so that the video stream had a lower bit rate.
in other words: if the camera is sending 3,5 Mbps of traffic over a 2Mbps link the QoS can help to allow other traffic to pass but the the video stream will be unusable with high drop percentages.
Hope to help
Giuseppe
09-15-2008 04:10 AM
Giuseppe makes a great point about whether the video cameras can adjust their bandwidth demand! If there are various camera picture quality and/or picture size settings, it's often helpful to use those that demand the least amount of bandwidth yet still meets your viewing requirements.
You do want to know what the expected bandwidth demand for the video stream will be, and as a rough rule, you'll likely not want to use use a video stream that consumes more than 1/4 to 1/2 the link's bandwidth. This both to allow bandwidth for your data and to also allow some video bandwidth headroom since many video stream's actual bandwidth demand, at any instant, can be much higher than its average demand.
Giuseppe's example is good, but if this is all new to you, here are thoughts to hopefully further clarify his example.
First, Giuseppe's example appears to be assuming a E1 least line with a 768 Kbps video stream. Whether you have an E1 or T1, fractional variant of either, or even other WAN technology, the intent is really the same. Namely to insure your video steam obtains the bandwidth it requires. I.e. the principle is what's important, not the name of the policy with "-2mbp" or "bandwidth 768".
Second, Giuseppe's example assumes the video stream is running across RTP. What's important is that the video stream is correctly identified. Giuseppe's example of using RTP might work just fine, but there are often other methods to match the video traffic. Another method might be to match source and/or destination IP addresses.
There is one possible problem with Giuseppe's example, and that is, using FQ within class-default while placing video into its own non-LLQ class.
Giuseppe's example is 100% correct, from a text book perspective, but my reading of other Cisco documention has led me to believe class-default FQ, on many Cisco platforms, can keep the other defined classes from obtaining the bandwidth specified for them. If this is indeed a problem, Giuseppe's example could be amended one of two ways:
policy-map scheduler-2mbps
class-map video
bandwidth 768 (or bandwidth percent ##)
class-map class-default
no fair-queue
or
policy-map scheduler-2mbps
class-map video
priority 768 (or priority percent ##)
class-map class-default
fair-queue
PS:
BTW:
Depending on your overall traffic, and what bandwith the video stream needs to work well, just FQ, alone, might work for you. This could be done as:
interface serial#
fair-queue (normally the default on E1 and slower - if default, might not show in config - you don't want to see "no fair-queue" in the config)
or
policy-map yourPolicyname
class class-default
fair-queue
interface serial#
service-policy output yourPolicyname
09-15-2008 05:56 AM
Giuseppe great add this is 5 point :)
just about the rtp range u were mean:
range 16384 32767 right ?
09-15-2008 09:31 AM
Hello Marwan,
thanks for your good remarks.
We had the same problems some mounths ago and the three cameras were consuming more then 10 Mbps together with default setting, after tuning they used 3 Mbps allowing space for data traffic.
I was meaning the range of RTP udp ports but I didn't check with a working configuration so I can remenber wrong both the command syntax details and the port range.
I also think that Joseph added value to the config the priority queue should be a much better choice.
Best Regards
Giuseppe
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