Minimum bandwidth guarantee

Answered Question
May 17th, 2011

Hello everyone,

I'm a bit new to QoS.
I have a Cisco 2801 router with IOS version 12.4(3e).
The F0/0 interface is connected to the LAN (inside network) and the F0/1 interface is connected to the outside WAN, which is a symmetrical 2 Mbps line.

We have 3 projects, each requiring a minimum guarantee of 512 kbps (for the moment) in both directions, ie, upload & download.
Following is an excerpt of my router config:

class-map match-any CMAP-MATCH-PROJECT2
match ip precedence 4
class-map match-any CMAP-MATCH-PROJECT3
match ip precedence 5
class-map match-any CMAP-MATCH-PROJECT1
match ip precedence 3
class-map match-all cmapProject3
match access-group name aclProject3
class-map match-all cmapProject2
match access-group name aclProject2
class-map match-all cmapProject1
match access-group name aclProject1
!
!
policy-map PMAP-WAN-OUT
class CMAP-MATCH-PROJECT1
  bandwidth 512
class CMAP-MATCH-PROJECT2
  bandwidth 512
class CMAP-MATCH-PROJECT3
  bandwidth 512
class class-default
  fair-queue
policy-map PMAP-WAN-OUT-PARENT
class class-default
  shape average 2000000
  service-policy PMAP-WAN-OUT
policy-map PMAP-LAN-IN
class cmapProject2
  set ip precedence 4
class cmapProject1
  set ip precedence 3
class cmapProject3
  set ip precedence 5
class class-default
  set ip precedence 1
!
interface FastEthernet0/0
description $ETH-LAN$$FW_INSIDE$
ip address 10.0.0.1 255.255.0.0
ip access-group aclFE0/0-In in
ip nat inside
ip inspect fwInternet-Out in
service-policy input PMAP-LAN-IN
!
interface FastEthernet0/1
ip address 192.168.7.2 255.255.255.252
ip access-group aclIncoming in
ip nat outside
ip inspect fwInternet-In in
crypto map mapVPN
service-policy output PMAP-WAN-OUT-PARENT
!


My questions are:
1. As far as guaranteeing a minimum bandwidth in the outgoing (upload) direction, is the config OK?
2. The FastEthernet is a 100 Mbps link, while the WAN connection is a 2 Mbps link. Is it the "shape average 2000000" command that makes the QoS become active?
3. Do I need to apply the command "fair-queue" on both FastEthernet interfaces, F0/0, F/1 or none?
4. Do I also need to apply the "bandwidth 2000" command on the F0/1 interface?
5. Is it possible to guarantee a minimum bandwidth in the incoming (download) direction for each project? If yes, is the following config OK?

class-map match-all cmapProject3Rev
match access-group name aclProject3Rev
class-map match-all cmapProject2Rev
match access-group name aclProject2Rev
class-map match-all cmapProject1Rev
match access-group name aclProject1Rev

policy-map PMAP-WAN-IN
class cmapProject2Rev
  set ip precedence 4
class cmapProject1Rev
  set ip precedence 3
class cmapProject3Rev
  set ip precedence 5
class class-default
  set ip precedence 1

policy-map PMAP-LAN-OUT
class CMAP-MATCH-PROJECT1
  bandwidth 512
class CMAP-MATCH-PROJECT2
  bandwidth 512
class CMAP-MATCH-PROJECT3
  bandwidth 512
class class-default
  fair-queue

policy-map PMAP-LAN-OUT-PARENT
class class-default
  shape average 2000000
  service-policy PMAP-LAN-OUT

!
interface FastEthernet0/0
description $ETH-LAN$$FW_INSIDE$
ip address 10.0.0.1 255.255.0.0
ip access-group aclFE0/0-In in
ip nat inside
ip inspect fwInternet-Out in
service-policy input PMAP-LAN-IN
service-policy output PMAP-LAN-OUT-PARENT
!
interface FastEthernet0/1
ip address 192.168.7.2 255.255.255.252
ip access-group aclIncoming in
ip nat outside
ip inspect fwInternet-In in
crypto map mapVPN
service-policy input PMAP-WAN-IN
service-policy output PMAP-WAN-OUT-PARENT
!

Thanks for any help or suggestion.

I have this problem too.
0 votes
Correct Answer by Joseph W. Doherty about 4 years 4 days ago

Disclaimer

The   Author of this  posting offers the information contained within this   posting without  consideration and with the reader's understanding that   there's no  implied or expressed suitability or fitness for any   purpose.   Information provided is for informational purposes only and   should not  be construed as rendering professional advice of any kind.    Usage of  this posting's information is solely at reader's own risk.

Liability Disclaimer

In    no event shall Author be liable for any damages whatsoever  (including,   without limitation, damages for loss of use, data or  profit) arising  out  of the use or inability to use the posting's  information even if  Author  has been advised of the possibility of such  damage.

Posting

However, being new to QoS, I still need some help regarding question #1.

(a) Should I remove the following 2 lines from policy-map PMAP-WAN-OUT?

     class class-default
      fair-queue

(b) Should I replace them with the following 2 lines?

     class class-default
      no fair-queue

Alas, it's a "it depends" answer.  If you have few flows that will fall into class default, especially if they don't try to use all the bandwidth, and/or you really don't need to provide your defined classes the mininum bandwidth defined in the CBWFQ policy, a) shouldn't be a problem.  Otherwise, go with option b).

(c) Should I ensure that the FastEthernet interfaces use FIFO instead of FQ?

Generally, you never want to use classical WFQ on Ethernet interfaces.  I.e. so yes, use FIFO, CBWFQ will override it.

Any other advice is welcome.

With your variant of IOS, would recommend you just shape for about 1.8 Mbps.  Believe your version of a shaper will also implement WFQ.

Also assuming WFQ active, if WFQ alone isn't sufficient, trying marking your "special" traffic with an IP Prec of 2, 3, 4 (or DSCP CS2, CS3, CS4).  (All special traffic should get same marking, higher values will increase bandwidth proportions.)  Other traffic IP Prec 0 or DSCP BE.

If that's still not enough, upgrade to an IOS version that supports HQF.  Then either define individual class for each project's traffic, similar to your original post, or place all project traffic in one defined class.  Use FQ on all defined non-LLQ classes.  BTW, the later CBWFQ classes also support bandwidth percentages, sometimes an advantage as it automatically adjusts to overall bandwidth.

Correct Answer by Florin Barhala about 4 years 1 week ago

Nice answer, still I just to point out one thing: fair-queue enable WFQ on the interface while no fair-queue enables the default queueing method: FIFO.

Correct Answer by Joseph W. Doherty about 4 years 1 week ago

Disclaimer

The  Author of this  posting offers the information contained within this  posting without  consideration and with the reader's understanding that  there's no  implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not  be construed as rendering professional advice of any kind.   Usage of  this posting's information is solely at reader's own risk

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

netsyspro wrote:

Thanks for your reply.

1. Can you briefly tell me how FQ in class-default will distort the defined bandwidth reservations in the other classes?

Do you suggest removing the "fair-queue" command in the class-default section?

Should I replace it with something else, maybe somewhere else?

3. Should I leave it as the default FIFO then?

4. I have applied the "bandwidth 2000" command on the F0/1 interface, as per your recommendation.

5. Could you elaborate on that?

#1 On most Cisco router platforms using an IOS pre-HQF CBWFQ, defined classes each get one queue and egress scheduling weight, FQ, in class-default, generates dynamic queues (up to some limit), each too with an egress scheduling weight.  Depending on number of active flows, each flow's actual egress scheduling will vary.  If you're trying to guarantee a precise amount of bandwidth for defined class queues, setting class-default queuing to FIFO avoids this.  (NB: There's a Cisco whitepaper on this, but I usually have trouble finding it, and I'm pressed for time this morning.)

#5 For inbound traffic, if you can not manage the other side's egress, you can not fully control bandwidth allocations as utilized inbound.  For example, assume you have two steams inbound that you want to allocate 50/50 bandwidth.  If each is UDP and one stream is sending at 75%, and the other 50%, you could police the 75% inbound, but the sender (usually) won't slow even though you're dropping a third of its packets.  With TCP traffic, the sender should respond to your policing and drops by reducing its send window, but it will ramp up past your policing setting until it sees the drops again (not too bad while it's in congestion avoidance mode, but slow start can burst beyond your bandwidth allocations).  (Also if only two flows, policing would be somewhat effective, but for mulitple flows this becomes more of an issue.)

For #5, this is assuming a "stock" router.  There are appliances that can do a much better job managing inbound bandwidth allocation for some traffic, such as TCP traffic, by spoofing receiver's RWIN and/or metering TCP ACKs.

In situations where we're trying to "guarantee" some level of performance, but using Internet, it can work fairly well as long as you don't share a site-to-site VPN router and link with general Internet traffic.  Having general Internet traffic on a different router and link allows you to manage bandwidth on the site-to-site path.  Of course the Internet itself shouldn't honor your ToS settings, but since the common congestion point is usually VPN/Internet ingress/egress, if you can control that, your performance might meet your SLA goals.

Correct Answer by Joseph W. Doherty about 4 years 1 week ago

Disclaimer

The  Author of this  posting offers the information contained within this  posting without  consideration and with the reader's understanding that  there's no  implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not  be construed as rendering professional advice of any kind.   Usage of  this posting's information is solely at reader's own risk

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

netsyspro wrote:

Yes, the router is doing NAT, so I agree that we cannot use only the access lists to match the packets.

There are also 2 site-to-site IPSEC VPN, which I omitted from the posted config for the sake of simplicity.

I have added the "qos pre-classify" command as follows:

crypto map mapVPN 10 ipsec-isakmp
set peer ipFrance
set security-association lifetime seconds 43200
set transform-set TS_esp-3des-sha
set pfs group2
match address aclFrance
qos pre-classify

Normally, qos pre-classify is only necessary when using classification on the encrypted traffic (so that the pre-encryption packet header information is availaible for classification).  Since your inbound classifcation policy is marking traffic with IP Prec, that's normally copied to the encryped packet header's ToS.  (At least I believe that's the way it should work - won't make any promises, though - laugh.)

Correct Answer by Joseph W. Doherty about 4 years 1 week ago

Disclaimer

The  Author of this  posting offers the information contained within this  posting without  consideration and with the reader's understanding that  there's no  implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not  be construed as rendering professional advice of any kind.   Usage of  this posting's information is solely at reader's own risk

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

jeye wrote:

PS: BTW, if you're using input policy to classify and mark IP Prec for outbound policy, it's unnecessary.  Your outbound policy should, I believe, be able to use the ACL based class maps.

Not true, traffics need to be classified at ingress since NAT is involved in the configuration. Queuing is the last step for NAT order of operation.

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml

Regards,

jerry

Yes, you're quite correct when NAT is involved.  Thanks for catching my mistaken belief.

Correct Answer by Jerry Ye about 4 years 1 week ago

PS: BTW, if you're using input policy to classify and mark IP Prec for outbound policy, it's unnecessary.  Your outbound policy should, I believe, be able to use the ACL based class maps.

Not true, traffics need to be classified at ingress since NAT is involved in the configuration. Queuing is the last step for NAT order of operation.

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml

Regards,

jerry

Correct Answer by Joseph W. Doherty about 4 years 1 week ago

Disclaimer

The Author of this  posting offers the information contained within this posting without  consideration and with the reader's understanding that there's no  implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind.  Usage of  this posting's information is solely at reader's own risk

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

My questions are:

1. As far as guaranteeing a minimum bandwidth in the outgoing (upload) direction, is the config OK?
2. The FastEthernet is a 100 Mbps link, while the WAN connection is a 2 Mbps link. Is it the "shape average 2000000" command that makes the QoS become active?
3. Do I need to apply the command "fair-queue" on both FastEthernet interfaces, F0/0, F/1 or none?
4. Do I also need to apply the "bandwidth 2000" command on the F0/1 interface?
5. Is it possible to guarantee a minimum bandwidth in the incoming (download) direction for each project? If yes, is the following config OK?

#1 No. FQ in class default, for your platform/IOS, can distort your defined class bandwidth reservations.

#2, Yes, although believe this platform's shaper doesn't account for L2 overhead, i.e. you might want to shape at 10 to 15% less.

#3, FQ only used on outbound policies.  You may want to avoid using FQ, see answer #1.

#4 I don't believe so, but I believe it good practice.  Can be used by other control plane stuff, such as dynamic routing metric or CBWFQ using percentages (I believe).

#5 Not effectively.

PS: BTW, if you're using input policy to classify and mark IP Prec for outbound policy, it's unnecessary.  Your outbound policy should, I believe, be able to use the ACL based class maps.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (8 ratings)
Correct Answer
Joseph W. Doherty Tue, 05/17/2011 - 17:40

Disclaimer

The Author of this  posting offers the information contained within this posting without  consideration and with the reader's understanding that there's no  implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind.  Usage of  this posting's information is solely at reader's own risk

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

My questions are:

1. As far as guaranteeing a minimum bandwidth in the outgoing (upload) direction, is the config OK?
2. The FastEthernet is a 100 Mbps link, while the WAN connection is a 2 Mbps link. Is it the "shape average 2000000" command that makes the QoS become active?
3. Do I need to apply the command "fair-queue" on both FastEthernet interfaces, F0/0, F/1 or none?
4. Do I also need to apply the "bandwidth 2000" command on the F0/1 interface?
5. Is it possible to guarantee a minimum bandwidth in the incoming (download) direction for each project? If yes, is the following config OK?

#1 No. FQ in class default, for your platform/IOS, can distort your defined class bandwidth reservations.

#2, Yes, although believe this platform's shaper doesn't account for L2 overhead, i.e. you might want to shape at 10 to 15% less.

#3, FQ only used on outbound policies.  You may want to avoid using FQ, see answer #1.

#4 I don't believe so, but I believe it good practice.  Can be used by other control plane stuff, such as dynamic routing metric or CBWFQ using percentages (I believe).

#5 Not effectively.

PS: BTW, if you're using input policy to classify and mark IP Prec for outbound policy, it's unnecessary.  Your outbound policy should, I believe, be able to use the ACL based class maps.

Correct Answer
Jerry Ye Tue, 05/17/2011 - 20:25

PS: BTW, if you're using input policy to classify and mark IP Prec for outbound policy, it's unnecessary.  Your outbound policy should, I believe, be able to use the ACL based class maps.

Not true, traffics need to be classified at ingress since NAT is involved in the configuration. Queuing is the last step for NAT order of operation.

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml

Regards,

jerry

netsyspro Tue, 05/17/2011 - 23:36

Yes, the router is doing NAT, so I agree that we cannot use only the access lists to match the packets.

There are also 2 site-to-site IPSEC VPN, which I omitted from the posted config for the sake of simplicity.

I have added the "qos pre-classify" command as follows:

crypto map mapVPN 10 ipsec-isakmp
set peer ipFrance
set security-association lifetime seconds 43200
set transform-set TS_esp-3des-sha
set pfs group2
match address aclFrance
qos pre-classify

Correct Answer
Joseph W. Doherty Wed, 05/18/2011 - 02:38

Disclaimer

The  Author of this  posting offers the information contained within this  posting without  consideration and with the reader's understanding that  there's no  implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not  be construed as rendering professional advice of any kind.   Usage of  this posting's information is solely at reader's own risk

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

netsyspro wrote:

Yes, the router is doing NAT, so I agree that we cannot use only the access lists to match the packets.

There are also 2 site-to-site IPSEC VPN, which I omitted from the posted config for the sake of simplicity.

I have added the "qos pre-classify" command as follows:

crypto map mapVPN 10 ipsec-isakmp
set peer ipFrance
set security-association lifetime seconds 43200
set transform-set TS_esp-3des-sha
set pfs group2
match address aclFrance
qos pre-classify

Normally, qos pre-classify is only necessary when using classification on the encrypted traffic (so that the pre-encryption packet header information is availaible for classification).  Since your inbound classifcation policy is marking traffic with IP Prec, that's normally copied to the encryped packet header's ToS.  (At least I believe that's the way it should work - won't make any promises, though - laugh.)

Correct Answer
Joseph W. Doherty Wed, 05/18/2011 - 02:29

Disclaimer

The  Author of this  posting offers the information contained within this  posting without  consideration and with the reader's understanding that  there's no  implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not  be construed as rendering professional advice of any kind.   Usage of  this posting's information is solely at reader's own risk

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

jeye wrote:

PS: BTW, if you're using input policy to classify and mark IP Prec for outbound policy, it's unnecessary.  Your outbound policy should, I believe, be able to use the ACL based class maps.

Not true, traffics need to be classified at ingress since NAT is involved in the configuration. Queuing is the last step for NAT order of operation.

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml

Regards,

jerry

Yes, you're quite correct when NAT is involved.  Thanks for catching my mistaken belief.

netsyspro Tue, 05/17/2011 - 23:56

Thanks for your reply.

1. Can you briefly tell me how FQ in class-default will distort the defined bandwidth reservations in the other classes?

Do you suggest removing the "fair-queue" command in the class-default section?

Should I replace it with something else, maybe somewhere else?

3. Should I leave it as the default FIFO then?

4. I have applied the "bandwidth 2000" command on the F0/1 interface, as per your recommendation.

5. Could you elaborate on that?

Correct Answer
Joseph W. Doherty Wed, 05/18/2011 - 03:11

Disclaimer

The  Author of this  posting offers the information contained within this  posting without  consideration and with the reader's understanding that  there's no  implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not  be construed as rendering professional advice of any kind.   Usage of  this posting's information is solely at reader's own risk

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

netsyspro wrote:

Thanks for your reply.

1. Can you briefly tell me how FQ in class-default will distort the defined bandwidth reservations in the other classes?

Do you suggest removing the "fair-queue" command in the class-default section?

Should I replace it with something else, maybe somewhere else?

3. Should I leave it as the default FIFO then?

4. I have applied the "bandwidth 2000" command on the F0/1 interface, as per your recommendation.

5. Could you elaborate on that?

#1 On most Cisco router platforms using an IOS pre-HQF CBWFQ, defined classes each get one queue and egress scheduling weight, FQ, in class-default, generates dynamic queues (up to some limit), each too with an egress scheduling weight.  Depending on number of active flows, each flow's actual egress scheduling will vary.  If you're trying to guarantee a precise amount of bandwidth for defined class queues, setting class-default queuing to FIFO avoids this.  (NB: There's a Cisco whitepaper on this, but I usually have trouble finding it, and I'm pressed for time this morning.)

#5 For inbound traffic, if you can not manage the other side's egress, you can not fully control bandwidth allocations as utilized inbound.  For example, assume you have two steams inbound that you want to allocate 50/50 bandwidth.  If each is UDP and one stream is sending at 75%, and the other 50%, you could police the 75% inbound, but the sender (usually) won't slow even though you're dropping a third of its packets.  With TCP traffic, the sender should respond to your policing and drops by reducing its send window, but it will ramp up past your policing setting until it sees the drops again (not too bad while it's in congestion avoidance mode, but slow start can burst beyond your bandwidth allocations).  (Also if only two flows, policing would be somewhat effective, but for mulitple flows this becomes more of an issue.)

For #5, this is assuming a "stock" router.  There are appliances that can do a much better job managing inbound bandwidth allocation for some traffic, such as TCP traffic, by spoofing receiver's RWIN and/or metering TCP ACKs.

In situations where we're trying to "guarantee" some level of performance, but using Internet, it can work fairly well as long as you don't share a site-to-site VPN router and link with general Internet traffic.  Having general Internet traffic on a different router and link allows you to manage bandwidth on the site-to-site path.  Of course the Internet itself shouldn't honor your ToS settings, but since the common congestion point is usually VPN/Internet ingress/egress, if you can control that, your performance might meet your SLA goals.

Correct Answer
Florin Barhala Wed, 05/18/2011 - 09:20

Nice answer, still I just to point out one thing: fair-queue enable WFQ on the interface while no fair-queue enables the default queueing method: FIFO.

netsyspro Mon, 05/23/2011 - 03:24

Thanks a lot for your explanations.

However, being new to QoS, I still need some help regarding question #1.

(a) Should I remove the following 2 lines from policy-map PMAP-WAN-OUT?

     class class-default
      fair-queue

(b) Should I replace them with the following 2 lines?

     class class-default
      no fair-queue

(c) Should I ensure that the FastEthernet interfaces use FIFO instead of FQ?

Any other advice is welcome.

Correct Answer
Joseph W. Doherty Mon, 05/23/2011 - 16:58

Disclaimer

The   Author of this  posting offers the information contained within this   posting without  consideration and with the reader's understanding that   there's no  implied or expressed suitability or fitness for any   purpose.   Information provided is for informational purposes only and   should not  be construed as rendering professional advice of any kind.    Usage of  this posting's information is solely at reader's own risk.

Liability Disclaimer

In    no event shall Author be liable for any damages whatsoever  (including,   without limitation, damages for loss of use, data or  profit) arising  out  of the use or inability to use the posting's  information even if  Author  has been advised of the possibility of such  damage.

Posting

However, being new to QoS, I still need some help regarding question #1.

(a) Should I remove the following 2 lines from policy-map PMAP-WAN-OUT?

     class class-default
      fair-queue

(b) Should I replace them with the following 2 lines?

     class class-default
      no fair-queue

Alas, it's a "it depends" answer.  If you have few flows that will fall into class default, especially if they don't try to use all the bandwidth, and/or you really don't need to provide your defined classes the mininum bandwidth defined in the CBWFQ policy, a) shouldn't be a problem.  Otherwise, go with option b).

(c) Should I ensure that the FastEthernet interfaces use FIFO instead of FQ?

Generally, you never want to use classical WFQ on Ethernet interfaces.  I.e. so yes, use FIFO, CBWFQ will override it.

Any other advice is welcome.

With your variant of IOS, would recommend you just shape for about 1.8 Mbps.  Believe your version of a shaper will also implement WFQ.

Also assuming WFQ active, if WFQ alone isn't sufficient, trying marking your "special" traffic with an IP Prec of 2, 3, 4 (or DSCP CS2, CS3, CS4).  (All special traffic should get same marking, higher values will increase bandwidth proportions.)  Other traffic IP Prec 0 or DSCP BE.

If that's still not enough, upgrade to an IOS version that supports HQF.  Then either define individual class for each project's traffic, similar to your original post, or place all project traffic in one defined class.  Use FQ on all defined non-LLQ classes.  BTW, the later CBWFQ classes also support bandwidth percentages, sometimes an advantage as it automatically adjusts to overall bandwidth.

netsyspro Fri, 05/27/2011 - 04:13

Joseph, I thank you for all the detailed explanations to my queries.

Jerry, thanks to you as well for pointing out the necessity for traffic classification.

Florin, thanks to you as well.

Actions

Login or Register to take actions

This Discussion

Posted May 17, 2011 at 4:29 PM
Stats:
Replies:11 Overall Rating:5
Views:1484 Votes:0
Shares:0
Tags: No tags.