[c-nsp] How to apply individual QoS policies to on an ingressInterface?

Thu May 7 03:38:40 EDT 2009

Andy,

Reading quickly through your email, I think you need to look at a more
advanced QOS solution.
Cisco has the SCE devices implementing per-subscriber QOS policies.

You can read about it a bit here:
http://www.cisco.com/en/US/products/ps6135/index.html
http://www.cisco.com/en/US/products/ps6151/index.html

This solution would enable you to identify subscribers by their IP
address (either dynamically or statically), and apply an advanced QOS
policy (including things like P2P, and other L7 apps and things like
quota) per subscriber. 

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Andy Saykao
Sent: Thursday, May 07, 2009 08:18
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] How to apply individual QoS policies to on an
ingressInterface?

Hi All,

I know you can only have one service-policy in/out on an interface - but
what if you need to rate limit mulitple IP's that transit through the
interface???

A bit of background first...

We have several customers  (100's of them) who we handle the IP/Internet
side of things for and we use another Provider to provide the physical
side of things (layer 2 hand off).

Physical topology looks like this:

Customer #1 to #100 --- (10Mb) --> Provider A --- (400Mb) --> Netspace
---> Internet

Provider A currently provides the customer with a 10Mb/sec connection
and we would like to rate limit some of these customers to 2Mb, and
others to 4Mb at our ingress, etc.. Is this possible without needing a
class-map and policy-map for each customer???

The config on our border router that peers with Provide A looks like
this:

interface GigabitEthernet0/1.120
 description Interconnect with Provider A
 bandwidth 400000
 encapsulation dot1Q 120
 ip address 203.17.98.x 255.255.255.252
 service-policy input POLICY-RATE-LIMIT
 service-policy output POLICY-RATE-LIMIT

We currently route the customer's IP through that interface and apply a
policy-map on the interface.

ip route 202.45.102.248 255.255.255.248 203.17.98.y
ip route 202.45.118.132 255.255.255.252 203.17.98.y

Each customer IP is then placed into an ACL for each class of service
(eg: IP's that receive 2Mb go into ACL-TEST-2MB, etc). 

ip access-list extended ACL-TEST-2MB
 remark Customer #1
 permit ip any host 202.45.118.134
 permit ip host 202.45.118.134 any
 remark Customer #2
 permit ip any host 202.45.102.250
 permit ip host 202.45.102.250 any
!
class-map match-all RATE-LIMIT-2MB
  match access-group name ACL-TEST-2MB
!
policy-map POLICY-RATE-LIMIT
  class RATE-LIMIT-2MB
   police 2000000 375000 750000    conform-action transmit
exceed-action transmit     violate-action drop

However, when I went to lab this up, each customer IP did not receive
their full bandwidth allocation but were instead using the shared
bandwidth with all the other customer IP's in the same ACL. My lab
demonstrated that Customer #1 and #2 were both sharing the allotted 2Mb
bandwidth whilst both were doing a download (eg: Customer #1 50-70KB/sec
and Customer #2 150-175KB/sec). When I cancelled the download of
Customer #2, Customer #1's transfer rate increased to used the entire
2Mb and vice versa if I had cancelled Customer #1's download. Iff my
understanding is correct, all the IP's in the ACL end up sharing the 2Mb
bandwidth as if was just one big pipe (or bucket) rather than each
customer IP having it's on little 2Mb bucket (which is what I want to
see happen).

I think to get around this, each customer needs their own class-map and
policy-map like so:

class-map match-all CUSTOMER1-2MB
 match access-group name ACL-CUSTOMER1
class-map match-all CUSTOMER2-2MB
 match access-group name ACL-CUSTOMER2
!
policy-map POLICY-RATE-LIMIT
  class RATE-LIMIT-CUSTOMER1-2MB
   police 2000000 375000 750000    conform-action transmit
exceed-action transmit     violate-action drop
  class RATE-LIMIT-CUSTOMER2-2MB
   police 2000000 375000 750000    conform-action transmit
exceed-action transmit     violate-action drop
!
ip access-list extended ACL-CUSTOMER1

 permit ip any host 202.45.118.134
 permit ip host 202.45.118.134 any
ip access-list extended ACL-CUSTOMER2
 permit ip any host 202.45.102.250
 permit ip host 202.45.102.250 any

The policy-map applied to the interface remains the same.

interface GigabitEthernet0/1.120
 service-policy input POLICY-RATE-LIMIT
 service-policy output POLICY-RATE-LIMIT

So my question really is, do we need a class-map and policy-map for each
customer or is there a more elegant solution. Can't imagine having to
configure 100's of class-maps, policy-maps and ACL's for each customer
or the impact to the CPU if it has to go through 100's of classes to
find a match :)

Thanks.

Andy

This email and any files transmitted with it are confidential and
intended
 solely for the use of the individual or entity to whom they are
addressed. 
Please notify the sender immediately by email if you have received this 
email by mistake and delete this email from your system. Please note
that
 any views or opinions presented in this email are solely those of the
 author and do not necessarily represent those of the organisation. 
Finally, the recipient should check this email and any attachments for 
the presence of viruses. The organisation accepts no liability for any 
damage caused by any virus transmitted by this email.

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/