QoS, how can I setup bandwidth limit for each and every single IP

[rhienwei2010]

Say, got 100 staff in an office, and I want to setup a Policing policy to set up a bandwidth usage limit for any and each single IP, not matter sip, dip, or type of traffic, not to exceed a certain number, like 10M or 50%.  So no one would jam the entire office internet, no matter what.

How should I do that?

Thanks a lot.

[Mark Malone]

Theres a few ways here is 1 basic example below  use a class-map and match against and extended access-list that can use port numbers , you can specify to shape or police and drop the traffic as well in the class/policy and apply it to the L3 interface

example

policy-map TEST
  class TEST1
    bandwidth 100000

class-map match-all TEST1
  match access-group name TEST1

ip access-list extended TEST1
 permit tcp host 10.1.1.1 any eq ftp

[rhienwei2010]

that's just for one IP, I got about 200 IPs are in use, and total 500 IPs in DHCP scopes.  Any better way than doing an access-list of 500 entries, listing each and every single IPs?

[Tagir Temirgaliyev]

usual cisco can not solve your question.

I am not shure but look at competitors. Palo-alto juniper fortinet. ask representatives. or try to use proxi server as sqid 

[rhienwei2010]

what I need, is not a policing policy for all office traffic, but a policy that limits individuals.  like for any given single IP, limits its traffic to internet to like 10M, and traffic from multiple office IPs is not subject to that policy.  And I don't want to do that by doing 500 policy-maps for each IP individually.

[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 wha2tsoever (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

You could, but setting it up will be a bit tedious.  For aggregate interfaces, you'll want an ACL per IP, and a class-map per IP, e.g.

ip access-list user#

 permit ip host x.x.x.x any

 permit ip any host x.x.x.x

class-map match-any user#

 match access-group name user#

policy-map Sample

class user#

 police . . .

(Repeat ACLs, and class-maps, one per user.)

If you're able to apply user edge port ingress policies, the policy could just simply police all ingress traffic, and not need to match an IP.

NB: Some traffic is very sensitive to policing, so you might want to limit your policing to specific traffic types.

BTW, policing ingress Internet traffic, isn't always as effective as desired, because it's downstream of the congested link.

[rhienwei2010]

now I am thinking WFQ(weighted fair Q), it is flow-based, so can create Q for each traffic flow. So if I can setup each Q size like 10M, it should meet my request, so no single conversation would starve my office internet .  Can I do that?  

Also, it's said WFQ is for low bandwidth link, like <2M, can I use it on my 4510 core switch or 3925 router, on a 1G egress interface?

[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 wha2tsoever (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

I don't believe the 4500 supports any form of WFQ.  The 3925 should, including for high speed interfaces using CBWFQ, but it's not usually one queue per flow, multiple flows are spread across a fixed number of flow queues, which you may, or may not, be able to configure.  Also queuing would be very ineffective in controlling bandwidth from the Internet.

[dirkventer]

I realise this is a three year old thread, but none of the provided answers is optimal. Also, this question seems to have attracted disparaging remarks from an individual concerning Cisco products.

WFQ is not an effective solution, but it does provide a clue as to how you need to approach this - at a flow-based level.

So if you want granular - effective - user or IP-based bandwidth policing the device must support microflow policing. This is a Cisco switch feature, and it will allow per-port based policing. There are different ways to set it up depending on the capabilities of the device.

Microflow and netflow do not play well together since both are flow-based technologies. Netflow allows you to do detailed traffic inspection, consider using SNMP instead of netflow, as a bonus you will get your data real time.

[Joseph W. Doherty]

Ah, but remember, MicroFlow is policing per flow, not per user. Users might have multiple concurrent flows.

User aggregate policing can sometimes be supported by policing a user's edge port.

[cweinhold]

Microflow policing is a Cat6K feature. I've read that some form is also on Cat4K and ASR 9K/NCS 5K, but it is not supported on Cat3K, Cat9K, IOS, or IOS-XE. Other acronyms for similar technology are user-based rate-limiting (UBRL) or source-based rate-limiting (SBRL). WiFi controllers have user bandwidth policies which do exactly what you're trying to do, and should be used if your users are on WiFi.

On an IOS router, you're stuck with class-maps linked to access-lists, with no way to dynamically learn and match distinct source IPs. One approximation is to configure the access-list wildcard masks to group multiple source IPs into a smaller number of buckets which are then shaped.

For example, the access-list wildcard mask of 0.0.0.31 would create buckets for all IPs with the same least five bits of the fourth octet.  So 10.1.2.3 and 10.1.2.4 and 99.99.99.99 would go to different buckets, but 10.1.2.3, 10.1.2.35, 10.1.2.67, and 192.168.99.131 would all fall in the same bucket. Each bucket is then shaped, say to 1 Mbps.

You'd want to figure out a wildcard mask to minimize the number of times multiple source IPs collide in the same bucket. The attached config uses two bits from the third octet and three from the fourth. You can use at most eight bits total, since a policy-map can only have 256 classes.

This approach is not perfect, but it gets the job done by ensuring that each source IP can consume no more than X bandwidth.