10-26-2008 09:51 PM - edited 03-04-2019 12:04 AM
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?
Solved! Go to Solution.
10-26-2008 11:58 PM
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.
-Sai.
10-27-2008 06:20 PM
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
10-26-2008 11:58 PM
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.
-Sai.
10-27-2008 05:14 AM
"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.
10-27-2008 06:20 PM
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
10-28-2008 08:09 PM
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?
10-29-2008 04:51 AM
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?
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