Best option to throttle particular subnet/source traffic?

[CiscoBrownBelt]

So if you want to reduce how much bandwidth can be used from certain hosts/subnets destined to one particular subnet, it would be best configure Layer 3 QOS correct?

If let's say VRFs on a L2/3 switch are used for just the particular source subnets, destination traffic is just pointing to a layer 3 connection IP or tunnel, best place would be to implement QOS on that corresponding source VRF or actual interface the traffic enters (police or shape, single rate, etc.)?

[Joseph W. Doherty]

Laugh - yes, what you're asking is a bit confusing.

However, when your target is a particular source or destination, generally there's often particular points, in the topology, where that traffic will transit.  If so, that's often where you would implement QoS for those flows.  This is generally more possible for something like policing which can be applied either on an interface's ingress or egress (as least on a router).

[CiscoBrownBelt]

Ok let's say I just want to Police - I don't care I just want to drop any traffic (e.g. CustA to Site1) above whatever Mbps threshold/CIR rate I set.

To Reach Site1, CustA or any traffic trying to reach Site1 is directed to a let's say VTI/IPSEC tunnel at a router. Would it be simpler to just apply QOS policies (pre-classify) on the VTI tunnel? So basically any other customer who would need to be throttled, can just apply another  Class-map under the same Policy on the VTI? What would be best way to keep track of how much traffic each customer is even generating (to see how close to Thresholds are being reached) say if you don't have any other monitoring tool or something - for comparison or keeping track of metrics or something? This is why I was asking if maybe separate sub-interfaces or something are created on the Router for each customer, then traffic is directed to the VTI from there. Hope this sounds less confusing LOL

Also how many class-maps are supported under on Policy on Cisco routers or switches? I can't seem to find the answer.

[Joseph W. Doherty]

"Would it be simpler to just apply QOS policies (pre-classify) on the VTI tunnel?"

Possibly, yes.  Pre-classify would allow you to "look" at pre-encapsulation IP packet fields.

"So basically any other customer who would need to be throttled, can just apply another Class-map under the same Policy on the VTI?"

Correct.

"What would be best way to keep track of how much traffic each customer is even generating (to see how close to Thresholds are being reached) say if you don't have any other monitoring tool or something - for comparison or keeping track of metrics or something?"

Possibly using a class-map w/o a policer.  I recall (?) a class-map will show current bandwidth rate using it.

"Also how many class-maps are supported under on Policy on Cisco routers or switches?"

On routers, varies per IOS version.  Early/original versions, I recall (?), only supported 64.  The next CBWFQ version, I recall (?), increased number of classes to 256.  Don't recall if number of classes allowed increased again later.

On switches, class number often limited by number of queues supported in hardware, which is much more limited, so you might find only 8 or so classes supported.

[CiscoBrownBelt]

"Possibly using a class-map w/o a policer.  I recall (?) a class-map will show current bandwidth rate using it."

If not configuring with police, should I use the bandwidth parameter or something?

[Joseph W. Doherty]

Possibly, a policy map's class might not require any configuration statements, but if it does, the basic bandwidth statement, alone, should suffice.  (NB: do keep in mind, the bandwidth statement will determine a class's dequeuing weight relative to all the other bandwidth classes.)

[CiscoBrownBelt]

How about applying QOS right at the edge ingress interface of the infrastructure to throttle the external customer source so they don't utilize anymore bandwidth anywhere else in the infrastructure such as between that switch and a firewall (which will check this traffic) or the router which this traffic is destined in order to reach its tunnel destination?

[Joseph W. Doherty · Accepted solution]

Sure.  In fact, for a policer that's being used to maintain some form of contracted bandwidth, like an ACL, as close to the "source" would be more "efficient", as it keeps the excess traffic out of the rest of subsequent network topology.

[CiscoBrownBelt]

Thanks again Joseph!

Yes that was what I was thinking. That traffic would still flow through other paths within the infrastructure where a link speed may not be that great either.

[CiscoBrownBelt]

Also, can you apply QOS to a VTI IPSEC tunnel interface (so QOS before that traffic goes through tunnel or encrypted) with the  qos pre-classify on ISR or ASR routers?

[Joseph W. Doherty · Accepted solution]

Yes, on routers, you can generally apply QoS on tunnels.

Whether qos pre-classify is needed or not depends on whether your tunnel's QoS is using packet information not copied to the tunnel's external packet header.  If you use the IP packet's ToS, for processing, that's generally copied from the original packet to the tunnel's packet.

[CiscoBrownBelt]

not sure if I understand correctly. So in general, QOS is applied before traffic is encrypted or sent to tunnel correcct? If so then it would be the original packet header I would say sent from Customer A, B, etc.

You think it would be good idea to create let's say sub-interfaces for each customer want to throttle traffic on the router, apply the QOS to each sub-interface, then direct traffic to the tunnel if I want to manage QOS better and or reference how much traffic each customer is doing?

[Joseph W. Doherty]

"So in general, QOS is applied before traffic is encrypted or sent to tunnel correct?"

In general, no.  QoS, depending on what you're doing, might be applied before tunneling, after tunneling, or both.

"You think it would be good idea to create let's say sub-interfaces for each customer want to throttle traffic on the router, apply the QOS to each sub-interface, then direct traffic to the tunnel if I want to manage QOS better and or reference how much traffic each customer is doing?"

Probably not because a single CBWFQ policy, on a router, can have lots of classes, so you might have one per customer (at least until you run out of CBWFQ policy map classes).

[Georg Pauwen · Accepted solution]

Hello,

Joseph makes a good point about microflow policing.

I recall configuring the user based rate limiting microflow policing feature (which applies a policer to each flow) on the 6500.

There are several policy feature cards around, so yours (which one do you have ?) might or might not support UBRL but if it does, below is a sample config:

Outbound traffic would be rate limited to 100Mbps (with a burst of 260Mbps), and inbound to 150Mbps (with a burst of 260Mbps):

access-list 101 permit ip 192.168.1.0 0.0.0.255 any
access-list 102 permit ip any 192.168.1.0 0.0.0.255
!
class-map OUT_CM
match access-group 101
class-map IN_CM
match access-group 102
!
policy-map UBRL_PM
class OUT_CM
police flow mask src-only 100000000 65000 conform-action transmit exceed-action drop
class IN_CM
police flow mask dest-only 150000000 65000 conform-action transmit exceed-action drop
!
interface vlan 10
ip flow ingress
ip flow egress
service-policy input UBRL_PM

[CiscoBrownBelt]

Kind of confusing reading doc on burstrate but the burst numbers you are referencing default (how do you set it)?

Would you suggest applying the policy on the egress interface right where the traffic I want to throttle comes in or at the SVI where it must hit to route?

I will have to check the SUP and get back to you

[CiscoBrownBelt]

What about from a mgmt standpoint. Let's say more users/subnets want to go to same particular destination that QOS policy will be throttleing, and that destination is reachable via a Tunnel on a router connected to switch referenced here for instance. If customers enter infrastructure via different interfaces (so not particular layer 2 interface described in previous post but lets say other layer two interaces), I would have to configure QOS on all those different applicable interfaces. 

Would it be  better to create policies on the corresponding tunnel I described for each different subnet that may need to be throttled, or even create additional tunnels to that same destination for each individual customer that must be throttled (e.g. Tunnel Customer A to Site1, another tunnel for Customer B to Site1, Customer C to Site1, etc. on the router)? Let me know if I sound confusing with what I am asking