[c-nsp] How to apply individual QoS policies to on an ingress Interface?
Andy Saykao
andy.saykao at staff.netspace.net.au
Thu May 7 01:17:32 EDT 2009
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.
More information about the cisco-nsp
mailing list