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 [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
