Solved: Basic question on QoS Classification and Marking.

news2010a · ‎10-26-2008

UsersA--[fa0 RouterA S0]--WAN--[S0 RouterB fa0]--UsersB

I need to make sure that Autocad (lets say, port range is 6666-6667)applications receive high priority and applications such as a http

receive priority two when transferred over the WAN.

Is the below configuration correct?

begin====

I enable nbar in the fa0, LAN interface:

RouterA(config-if)#ip nbar protocol-discovery

then I create a class-map to match the respective port range for my Autocad application:

!

class-map priority1

match access-group 100

!

access-list 100 permit tcp any any lt 6666

access-list 100 permit tcp any any lt 6667

!

class-map priority2

access-list 101 permit tcp any any lt 80

!

!Then I set the respective DSCP's:

policy-map SetDSCP

class priority1

set ip dscp ef

class priority2

set ip dscp af21

!

Finally, I apply them to the s0/0 interface on RouterA:

int s0/0

service-policy output priority1

service-policy output priority2

!

end

=========================

Is the above correct to accomplish my goal?

saimbt · ‎10-26-2008

While attaching the Service Policy to an Interface, the syntax is

service-policy {input | output} policy-map-name

In ur case it would be, service-policy output SetDSCP

Moreover if Autocad is a business critical application, instead of only setting it to EF, it is recommended you use LLQ and priortise Autocad traffic by assigning some bandwidth to it.

http://www.cisco.com/en/US/products/sw/iosswrel/ps5014/products_feature_guide_chapter09186a008008813a.html

-Sai.

View solution in original post

Joseph W. Doherty · ‎10-27-2008

For starters, it's unclear just how you want to treat AutoCAD, HTTP and everything else. That is what priority one and priority two mean to you.

It's possible to give AutoCAD priority over all other traffic and HTTP next priority over all other traffic, but I would recommend against doing that (i.e. absolute priorities). Even relative priorities, for something like AutoCAD, might bear further consideration.

I'm going to assume your serial interface is connected to something like a dedicated T-1 (if not let me know).

What I would first suggest, is insure WFQ is active on your serial interface (interface command is fair-queue). Traffic with the same IP Precedence will get equal treatment. Traffic with better IP Precedence markings, get a larger proportion of the bandwidth.

First start by leaving the IP Precedence marking alone, where for most traffic it's likely to be zero. If the link is congested, and you want to increase AutoCAD's proportion, try marking its packets with an IP Precedence (or DSCP CS#) of 2, 3 or 4. If both AutoCAD and HTTP, you might try 4 for AutoCAD, 2 for HTTP. (Again, though, I worry about this choice of traffic priorization.)

The markings can be accomplished several ways. I would recommend an inbound service policy on your LAN facing interface. Actual syntax depends on your device and IOS level. (Tell me what you're using, and I should be able to give you further example of config code.)

e.g. (without classes defined, again that depends much on device, IOS version; syntax I'm providing might be incorrect)

policy-map classify

class AutoCAD

set ip precedence 4 (or set DHCP CS4)

class HTTP

set ip precedence 2 (or set DHCP CS2)

class class-default

set ip precedence 0 (or set DHCP BE)

interface FastEthernet0

service-policy inbound classify

interface serial0

fair-queue

or if you also want to use CBWFQ for output:

policy-map CBWFQ

class class-default

fair-queue

interface serial0

service-policy output CBWFQ

If performance still isn't what you want, we can try changing the prior IP Precedence values or we can get into very granular class based WFQ classes (what you're trying to config now, from your post).

What you have to always keep in mind, with QoS we manage bandwidth, we don't (normally) make bandwidth.

By this I mean, if AutoCAD is sluggish, even giving it absolute priority (effectively the whole link's bandwidth) might be insufficient for perceived performance, and if you do so, everything else is starved of the bandwidth you've given to AutoCAD.

AutoCAD, I thought, is the type of application that opens and loads (or saves) files. If true, this is the type of application we often de-prioritize or prioritize other applications so as to not be impacted by such a bandwidth hogging application. (This is one of the reasons, I suggest trying WFQ with equal marking.)

I'm guessing this is all new to you, but if you need more help, respond to this post.

PS:

Some notes on your post:

Shouldn't need nbar discovery

Your ACLs are matching for ports less than the port used by the application?

For AutoCAD, believe there's a range option for port numbers, i.e. may not need to define multiple ACLs since ports are consecutive.

Later IOS support custom NBAR application definitions (perhaps somewhat easier to understand than ACL).

NBAR has predefined protocol for HTTP.

Your policy marks traffic, but unless something downstream uses the marking, no need (for what you've shown).

Your policy doesn't explictly deal with congestion, it's only marking.

For your example, you would:

int s0/0

service-policy output SetDSCP

View solution in original post

saimbt · ‎10-26-2008

While attaching the Service Policy to an Interface, the syntax is

service-policy {input | output} policy-map-name

In ur case it would be, service-policy output SetDSCP

Moreover if Autocad is a business critical application, instead of only setting it to EF, it is recommended you use LLQ and priortise Autocad traffic by assigning some bandwidth to it.

http://www.cisco.com/en/US/products/sw/iosswrel/ps5014/products_feature_guide_chapter09186a008008813a.html

-Sai.

Joseph W. Doherty · ‎10-27-2008

"Is the above correct to accomplish my goal?"

No, but I'm pressed for time at the moment. If other posters don't provide the information you need, I'll try to explain at length either this evening or tomorrow.

Joseph W. Doherty · ‎10-27-2008

For starters, it's unclear just how you want to treat AutoCAD, HTTP and everything else. That is what priority one and priority two mean to you.

It's possible to give AutoCAD priority over all other traffic and HTTP next priority over all other traffic, but I would recommend against doing that (i.e. absolute priorities). Even relative priorities, for something like AutoCAD, might bear further consideration.

I'm going to assume your serial interface is connected to something like a dedicated T-1 (if not let me know).

What I would first suggest, is insure WFQ is active on your serial interface (interface command is fair-queue). Traffic with the same IP Precedence will get equal treatment. Traffic with better IP Precedence markings, get a larger proportion of the bandwidth.

First start by leaving the IP Precedence marking alone, where for most traffic it's likely to be zero. If the link is congested, and you want to increase AutoCAD's proportion, try marking its packets with an IP Precedence (or DSCP CS#) of 2, 3 or 4. If both AutoCAD and HTTP, you might try 4 for AutoCAD, 2 for HTTP. (Again, though, I worry about this choice of traffic priorization.)

The markings can be accomplished several ways. I would recommend an inbound service policy on your LAN facing interface. Actual syntax depends on your device and IOS level. (Tell me what you're using, and I should be able to give you further example of config code.)

e.g. (without classes defined, again that depends much on device, IOS version; syntax I'm providing might be incorrect)

policy-map classify

class AutoCAD

set ip precedence 4 (or set DHCP CS4)

class HTTP

set ip precedence 2 (or set DHCP CS2)

class class-default

set ip precedence 0 (or set DHCP BE)

interface FastEthernet0

service-policy inbound classify

interface serial0

fair-queue

or if you also want to use CBWFQ for output:

policy-map CBWFQ

class class-default

fair-queue

interface serial0

service-policy output CBWFQ

If performance still isn't what you want, we can try changing the prior IP Precedence values or we can get into very granular class based WFQ classes (what you're trying to config now, from your post).

What you have to always keep in mind, with QoS we manage bandwidth, we don't (normally) make bandwidth.

By this I mean, if AutoCAD is sluggish, even giving it absolute priority (effectively the whole link's bandwidth) might be insufficient for perceived performance, and if you do so, everything else is starved of the bandwidth you've given to AutoCAD.

AutoCAD, I thought, is the type of application that opens and loads (or saves) files. If true, this is the type of application we often de-prioritize or prioritize other applications so as to not be impacted by such a bandwidth hogging application. (This is one of the reasons, I suggest trying WFQ with equal marking.)

I'm guessing this is all new to you, but if you need more help, respond to this post.

PS:

Some notes on your post:

Shouldn't need nbar discovery

Your ACLs are matching for ports less than the port used by the application?

For AutoCAD, believe there's a range option for port numbers, i.e. may not need to define multiple ACLs since ports are consecutive.

Later IOS support custom NBAR application definitions (perhaps somewhat easier to understand than ACL).

NBAR has predefined protocol for HTTP.

Your policy marks traffic, but unless something downstream uses the marking, no need (for what you've shown).

Your policy doesn't explictly deal with congestion, it's only marking.

For your example, you would:

int s0/0

service-policy output SetDSCP

news2010a · ‎10-28-2008

Your answer makes lots of sense.

One question:

Imagine I have:

Users---3750 accesslayer---Core 6509---WAN routers to branches

Then I do the marking in the 3750 accesslayer switches and map qos - DSCP at that point.

I understand I should try to mark as close as possible to the source, so that my approach above is a good idea, right?

Joseph W. Doherty · ‎10-29-2008

The "book answer" is mark as close to the source as possible. But on LAN, because of the usual high amount of available bandwidth, QoS, and marking for it, isn't often worth the effort except perhaps for real-time traffic like VoIP or video conferencing. Plus, many of Cisco's highspeed multilayer switches, such as the 3750 or even the 6500 without sup32-PISA or special WAN line cards, are weaker in marking packet analysis than some of the smallest software based routers. (NBAR support would be an example.) So, I often defer detailed traffic analysis until the WAN router.

There are "book" reasons for marking as soon as possible, but the "book" often overlooks the network engineer's maintenance cost. Another reason I defer using QoS features unless they're really of benefit. With something like AutoQoS, however, you might use it for edge and other LAN QoS. Of course, how well it might work in your environment, for your purposes, is the question. (For example, it's unlikely to single out your AutoCad for different treatment.)

Oh, and if it's not clear, the real purpose of marking at all is to save later devices from having to re-analyze a packet. Markings themselves might not have any impact on how your devices treat traffic, except for a few defaults (e.g. WFQ usually treats IP Precedence markings differently).

The best possible marking, close to the source, is the source itself marking. Some sources indeed do, such as many IP phones. Of course, this now raises the issue, do you trust the source?