Restrict Bandwidth on Router interface?

[CiscoPurpleBelt]

There lots of different ways to setup QOS and I am trying to determine the best and/or effective way to limit bandwidth for an incoming let's say IP address or source traffic on an interface. Something like the below a good way?

class-map match-all 1
match access-group 1
class-map match-all TEST_QMAP
match access-group 1
match input-interface GigabitEthernet2
!
policy-map Single_Rate_Two_Color
class TEST_QMAP
policy-map TEST_PM
policy-map polmap
class 1
bandwidth 2

interface GigabitEthernet2

service-policy output polmap

[Muhammad Awais Khan]

Hi,

In your sample config, your match input-interface GigabitEthernet2 and service-policy output interface is same, this qos will be ineffective on this interface.

There are multiple ways to apply QOS in effective way. I personally do following to enforce QOS on WAN link ( non-encrypted , without any tunnel ):

1) classify the interesting traffic with help of ACL, it can be specific session from one source subnet to destination or just match source only

access-list 100 extended permit ip x.x.x.0 0.0.0.255 any

class-map match-any C-QOS

 match access-group 100

2) create policy map

policy-map P-QOS

 class C-QOS

  bandwidth 1000

3) Apply policy map on the WAN interface in outbound direction 

interface gi0/0

 service-policy output P-QOS

[CiscoPurpleBelt]

Awesome!
What about if traffic in encrypted?

[CiscoPurpleBelt]

Ok great yest what Muhammed basically did above. Limiting encrypted traffic or tunnel traffic ingressing a network and/or edge router, etc. is something I am looking into. Its possible to do that with QOS as well correct?

[Joseph W. Doherty]

Yes, you can "do" QoS with tunnel and/or encrypted traffic too. An issue with encrypted traffic, you cannot "examine" the original packet's contents while it's encrypted (crossing the physical interface) unless its encrypted on the device, it's egress and you use a special config command to have a "shadow" copy of the original packet's IP header.

[Muhammad Awais Khan]

Yes, you can do that with encrypted traffic if encryption is going to happen on the sam Router. 

You can take advantage of TOS fields. 

From Cisco IOS Software Release 11.3T introduced support for IPSec
and along with it the ToS byte preservation feature. With this feature, the router automatically copies the ToS header value from the original IP packet to the encapsulating IP header when the IPSec in tunnel mode is used

Refer to below document:

https://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-packet-marking/18667-crypto-qos.pdf

Sample config:

Input Policy
access-list 150 permit ip x.x.x.0 0.0.0.255 y.y.y.0 0.0.0.255

!

! Above access list define your traffic that will be encrypted 

class-map match-any ingress-QOS
match access-group 150

policy-map setToS
class ingress-QOS
set ip precedence 1
!
interface gi 0/1
service-policy in setToS

Output Policy

class-map match-any egress-QOS
match ip precedence 1

!
policy-map wan1-shape
class egress-QOS

 priority 5000 28000
...
interface gi0/0
service-policy output wan1-shape

!

! where gi0/0 is the outside interface where you applied your crypto for VPN and gi0/1 is the lan facing interface

[Joseph W. Doherty]

No it's not because the bandwidth statement (in your CBWFQ policy-map) sets a minimum egress bandwidth guarantee. What you want to use is either a police statement (which can be used ingress or egress) or a shape statement (egress only).

As to matching, you're on the correct track by using class-maps and corresponding policy-map classes. You might have a policy-map being used as an ingress policy on an interface (more limited to what statements can be used) and/or a policy-map being used as an egress policy on an interface. You can have both an ingress and egress policy on the same interface and/or an ingress policy on one interface used logically in conjunction with an egress policy on another interface (much, in concept, similar to using ACLs on interfaces).