Simple (supposedly) QoS priority question on 2851 router

[will]

I want QoS in/out on an interface based on three priority levels, limiting (not by B/W or % Interface), but simply by service-levels if contention exists.
Say: if contention exists, P10 gets the first right of way, P20, gets the next right of way, and if we have anything left, P30 gets it! Dont care if any one of them uses the entire circuit if its free! Any ideas? Much thx in advance. Will

router version: c2800nm-advsecurityk9-mz.151-4.M3.bin

Here is my initial try at this configuration, but I am stuck on the priority command! there has to be a different way to do this:

class-map match-all CMAP_P10_VPN
description Highest Priority VPN traffic, Priority 10
match access-group name ACL_QOS_VPN <-both in.out directions
!
class-map match-all CMAP_P20_BIZ
description Medimu Priority Business traffic, Priority 20
match access-group name ACL_QOS_BIZ  <-both in.out directions
!
class-map match-all CMAP_P30_USR
description Lowest Priority User traffic, Priority 30
match access-group name ACL_QOS_USR <-need to match everything else

!

policy-map PMAP_QOS_IN
class CMAP_P10_VPN
    Priority 10   <-command confusing, how to configure?
class CMAP_P10_BIZ
    Priority 20   <-command confusing, how to configure?
class CMAP_P10_USR
    Priority 30   <-command confusing, how to configure?
!
ROUTER#(config-pmap-c)#priority ?
  <8-2000000>  Kilo Bits per second  <-I dont want these options, i want a strict 1,2,3... type priority
  percent      % of total bandwidth
  <cr>

policy-map PMAP_QOS_OUT
class CMAP_P10_VPN
    Priority 10
class CMAP_P20_BIZ
    Priority 20
class CMAP_P30_USR
    Priority 30

!

interface gig0/0
   bandwidth 20000000 !only 20 Mbits/sec  <-interface is CAR-ed by ISP to 20Mbits/second
   service-policy input PMAP_QOS_IN
   service-policy output PMAP_QOS_OUT

[Joseph W. Doherty]

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

To do exactly what you've described, for egress, you would need to use priority queuing (not priority within CBWFQ).

Since received traffic isn't queued, until resent, no way to prioritize it although you could police it.

That said, completely starving lower priority class of ALL bandwidth can break any applications running through those classes.

For a CBWFQ policy similar to what you've described, you could do:

policy-map PMAP_QOS_OUT

class CMAP_P10_VPN

    Priority percent 99

class CMAP_P10_BIZ

    bandwidth remaining percent 99

class CMAP_P10_USR

    bandwidth remaining percent 1

[will]

hey jospeh, thx for reply. I eventually worked my way around the maze to conclude ingress QoS wouldn't work. I am a bit new to QoS. I used this config:

policy-map PMAP_QOS_OUT

class CMAP_P80_VPN

    Priority percent 80

class CMAP_P15_BIZ

    Priority percent 15

class class-default

  fair-queue

I think applied the policy on both inside and outside router interfaces:

int gi0/1

descript outside

service-policy output PMAP_QOS_OUT

int gi0/0

descript inside

service-policy output PMAP_QOS_OUT

is there any hope that the inside egress policy will somehow manage traffic coming into the outside interface from the Internet? Or is this crazy? In ingress is what is really the important piece.

I am basically trying to stop a big user download (from one NAT IP) from clobbering VPN traffic (on another IP). This should be simple - but i guess not!

[Joseph W. Doherty]

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

Multiple priority classes all map into a single LLQ (i.e. same priority) although having them separate allows different implicit values.

Managing inbound traffic is exceedingly difficult with just a router; even dedicated traffic shaping appliances can have difficulty.  If you can recognize the big user download, either individually or as a class, you can police it inbound.  Unfortunately, this won't allow it to use any otherwise available bandwidth, and since policing is downstream, you only indirectly control its bandwidth consumption (if it's flow rate adaptive, it will slow when the policer drops packets).