sample QOS for video , voice , Data , ATM Traffic

[Marc du]

Hi Guys

Kindly , Post here sample QOS for video , voice , Data , ATM Traffic , dedicated Link Bandwidth is 8 Mbps

Thanks

[Georg Pauwen]

Hello,

what do you mean with ATM traffic ? Which platform is this on ?

Here is a generic policy for Voice, Video, and a default class for the rest (including data):

class-map match-any VOICE
 match dscp cs3
 match ip dscp ef
class-map match-any VIDEO
 match dscp cs4
 match dscp af41

policy-map QOS_OUT
 class VOICE
  priority percent 30
 class VIDEO
  priority percent 30
 class class-default
  fair-queue
  random-detect

interface FastEthernet4
 service-policy QOS_OUT out

[Joseph W. Doherty]

Some commentary on Georg's generic policy . . .

class-map match-any VOICE
 match dscp cs3
 match ip dscp ef
class-map match-any VIDEO
 match dscp cs4
 match dscp af41

The above classes expect DSCP tagging to correspond to the the traffic of that class type.

The VOICE class match statements have different syntax, both are effectively the same, but which is used depends on the platform and IOS version.  (One is a "newer" syntax, although I forget, off the top of my head, which is the newer.)

Match statement with tags often support up to 4 tags per statement.  Which sometimes can be handy if you want an additional "and" condition, for example:

class-map match-all VOICE
 match dscp ef cs3
 match <some other criteria, e.g. a subnet>

Also match statements are processed in sequence, which may have implications for efficiency.

Also for efficiency, if you're willing to match AF42 and AF43 as part of Video, you might:

class-map match-any VIDEO
 match ipprec 4

policy-map QOS_OUT
 class VOICE
  priority percent 30
 class VIDEO
  priority percent 30
 class class-default
  fair-queue
  random-detect

In the above, VIDEO is using LLQ.  It and VOICE use 60%.  Cisco recommends not to exceed 1/3 for LLQ.  I would recommend using care exceeding 1/3 and not to exceed 1/2.

I would also note, video comes in two major flavors, steaming/buffered video and live/real-time video.  The former shouldn't ever need LLQ.  The latter might not need it either, but if not using it, you do often need to provide priority close to LLQ.  (The reason you want to, if possible, avoid mixing VoIP and real-time video in LLQ, the usual larger packet sizes of the latter can impact VoIP's jitter.

Lastly, for class-default, if the CBWFQ supports it, declare a bandwidth percentage.  Also, I highly recommend not using WRED unless you really, really understand the technology, and especially don't use it with FQ (unless it's the FRED variant).

[jmcgrady1]

---

@Joseph W. Doherty wrote:

In the above, VIDEO is using LLQ.  It and VOICE use 60%.  Cisco recommends not to exceed 1/3 for LLQ. 

video comes in two major flavors, steaming/buffered video and live/real-time video.  The former shouldn't ever need LLQ.  The latter might not need it either, but if not using it, you do often need to provide priority close to LLQ.  (The reason you want to, if possible, avoid mixing VoIP and real-time video in LLQ, the usual larger packet sizes of the latter can impact VoIP's jitter.

---

Could you give an example config of what would be a better approach? ie; a class map for LLQ, then (whatever is best) for voice, video, general traffic?

[Joseph W. Doherty]

@jmcgrady1 just now I see your two year later follow up question.  I don't recall getting any notification (as I also didn't for @CISCO171346 recent posting), but his I caught just in the recent postings list.

If you still need a sample, please let me know.

[CISCO171346]

Is there any tool like Wireshark or else through which I can verify the 30% priority is implemented on that particular class? How can I verify it?

[Joseph W. Doherty]

Well, unless you've bumped into a Cisco bug, Cisco QoS allocations work (correctly) as configured.

Otherwise, to verify Cisco QoS is working as it should, I use a traffic generator to flood the link at 100% (or sometimes slightly more), in this case, also run the priority class loaded at 30% and look for drops in that class (shouldn't be any if not exceeding 30%) and run some pings through that class (should see very little change in ping times).

You can also use Wireshark for some of this verification, by I find the just described, macro level results (of drops and/or pings) tells me the LLQ class is behaving as expected.

[CISCO171346]

Thanks, Joseph for giving the idea of Traffic Generator. I hope I will find the good one which would help me. Two more things:

1. What is the sample which you were talking about in the earlier comment that you can provide us? Kindly share it

2. Do you have any idea that if for the "Videophones traffic" I made the classification on the basis of "match protocol" in Routers, and not on the basis of "match dscp", I use RTP or RTP video in the match protocol and then make the policy-map to "set it as xx dscp value" then it does not change when I monitor it on Wireshark. When I do it for "simple cisco voice phones" it works absolutely fine.

[Joseph W. Doherty]

#1

policy-map GenericRouter
class real-time
priority percent 35
class foreground
bandwidth remaining percent 81
fair-queue
class background
bandwidth remaining percent 1
fair-queue
class class-default
bandwidth remaining percent 9
fair-queue

The above policy might need some "tweaking" based on actual traffic's service needs, but it probably does pretty well 99% of the time.  The two keys to this policy are: first, FQ usage in all but the LLQ class, and second, directing traffic to its "proper" class (which usually, excluding real-time traffic, starts with all traffic in class-default - foreground is only used when really, really needed, perhaps, for example, real-time video [NB: later CBWFQ implementations may have a two tier LLQ/PQ option, useful for things like RT video], and background only used when traffic is known to be satisfied with available bandwidth).

NB: Again, the above non-LLQ classes often work very well when FQ is supported - totally different situation when it isn't.

#2

Actually the whole point of the ToS byte is to allow subsequent devices to quickly determine the level of service for a packet.  I.e. you only, when felt needed, do time consuming classification (e.g. match protocol), once.

In other words, assuming I correctly understand #2, what you're doing is pretty much best practice.

[CISCO171346]

Thanks a lot, Joseph

[Joseph W. Doherty]

As Georg already asked, we would need to know the platform, as QoS features, and often syntax, vary between platforms and sometimes even IOS versions.

Also as Georg asked, please clarify the meaning of "ATM Traffic"?

If the physical interface also 8 Mbps?  If not, you would need a shaper.

What kind of video, real-time or streaming?