01-04-2016 09:14 PM
Hello,
We have ESR10008 router.
We have 4 /24s which we need to apply rate limiting for each IP addresses to UPLink interface.
No limiting will be applied to other interfaces.
Creating and managing a huge number of ACL would be difficult and it is not possible to set more than 64 class per service-policy.
Can anyone suggest what we could do to achieve such setup?
Please, advise and thank you!
Best Regards
Solved! Go to Solution.
01-06-2016 11:34 PM
I don't understand the problem. I have already shown how you can use RADIUS to push per user per session rate-limits. Sample attributes below.
lcp:interface-config=rate-limit input qos-group 1 496000 64500 64500 conform-action transmit exceed-action drop
lcp:interface-config=rate-limit output qos-group 1 496000 64500 64500 conform-action transmit exceed-action drop
Every connection from a user in, even if they land on the same Virtual-Template, will create unique Virtual-Access(x) interfaces.
Lets say there is a user1, and they buy two services from you. It is easier if you give them unique user names for each service, but you can tell the RADIUS server to also match on the service type and return different rate limits based on that.
01-05-2016 11:37 PM
Do by chance the users use Virtual-Template / Virtual-Access interfaces (aka PPPoE, PPPoA, ...)?
Put the rate limit on the Virtual-Template interface with no access-list.
01-05-2016 11:47 PM
Hello,
Actually yes! Users do use Virtual-Template, but then shouldn't the rate-limit every IP address to one limit? I am trying to put rate limiting on the UPLink interface for each individual IP address. So, every single IP address would have their own rate limiting.
If, not then I will definitely give this method a try!
01-05-2016 11:59 PM
When a user "connects" the Virtual-Template is copied to a Virtual-Access interface. There is a 1:1 mapping between users and Virtual-Access interfaces. So each user will be individually limited using this approach.
Note that Virtual-Access interfaces can be pre-cloned for performance (like caching) so when testing it make sure you are getting a new Virtual-Access interface, or remove the pre-cloned ones for inactive users.
01-06-2016 12:08 AM
If you want to get super-tricky, you can create more than one Virtual-Template with different rate-limits, and make sure users on different plans get appropriately mapped, to provide different service levels (aka, users who pay more can get more).
Another "old" approach is to use pools, silver, gold, platinum. You can put a QoS DSCP marker on the users traffic (perhaps at the Virtual-Access level - I have also seen ISPs user specific pools of IP address to separate users, which means you can vary the routing as well based on the user pool).
Then on the upstream link you can then guarantee a minimum bandwidth level for each pool. So the platinum pool might be guaranteed a minimum of 50% of the upstream, gold 25%, and silver gets what left.
QoS only kicks in when a link is congested, so what the customer is paying for here is how badly their link will degrade when you are under 100% load.
01-06-2016 12:19 AM
Thanks it does rate-limit individually. I must ask:
1. Does it apply to only one interface?
This is the current configuration
interface Virtual-Template1
mtu 1492
ip unnumbered GigabitEthernet0/1
rate-limit input 496000 64500 64500 conform-action transmit exceed-action drop
rate-limit output 496000 64500 64500 conform-action transmit exceed-action drop
2. What if I want to apply different rate limiting to two different computer?
How can I assign which Virtual-Template can go with the desired user?
01-06-2016 05:54 PM
01-06-2016 06:58 PM
The user sessions terminate on the ESR, correct?
What device does the Global Internet terminate on? The ESR or something else?
01-06-2016 07:19 PM
I have the following connection
User -> GE3/0/0 - ESR10008 - GE1/0/0.101-> Global internet
|
Radius Server
GE1/0/0.101 is using BGP to connect to global internet
01-06-2016 07:37 PM
This bit is important. On GE1/0/0.101 to the global internet do you learn a default route (or a full routing table) via BGP - or do you use a simple static default route?
01-06-2016 07:43 PM
Have nothing fancy just this:
ip route XXX.XXX.48.0 255.255.248.0 Null0
Router BGP
neighbor XXX.XXX.XXX.185 remote-as XX204
01-06-2016 09:41 PM
Excellent, this makes things much easier!
Basically follow this guide.
http://www.ciscopress.com/articles/article.asp?p=169556&seqNum=5
First lets mark the route(s) from your upstream (aka Internet) that you want speed limited with a qos-group. Something like:
router BGP xxx
neighbor XXX.XXX.XXX.185 remote-as XX204
neighbor XXX.XXX.XXX.185 route-map internet-in in
route-map internet-in permit 10
set ip qos-group 1
This will simply make every route from the global Internet upstream belong to qos-group 1. Being a route map you can make this as complicated as you like for route marking.
Do a soft reset of the peer. If you display the default route we should see it now belongs to a QoS group. This has no impact on anything at the moment, because nothing is using the QoS groups. I'm guessing it will look something like:
#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0
Known via "bgp xx", distance xx, metric 0, qos-group 1, type external
Make sure the routing table displays this, as everything depends on it.
Now on the virtual-template we'll do something like:
interface Virtual-Template1
rate-limit input qos-group 1 496000 64500 64500 conform-action transmit exceed-action drop
rate-limit output qos-group 1 496000 64500 64500 conform-action transmit exceed-action drop
bgp-policy source ip-qos-map
bgp-policy destination ip-qos-map
So this causes any traffic coming in from or going out to a route belong to qos-group 1 to be rate-limited. All other traffic will pass at full speed.
You can of course apply more qos-groups to other peers and create more rate-limits to control the share of each pipe that users have.
01-06-2016 09:41 PM
pps. If you think I have substantially answered your question it would be great if you could give it a rating and mark it as correct. :-)
01-06-2016 10:56 PM
This is gold!
I just have one issue with it. It would have been perfect if we used the same rate-limit for every single customer, but there will be users with several different services connected to one virtual-template.
01-06-2016 11:34 PM
I don't understand the problem. I have already shown how you can use RADIUS to push per user per session rate-limits. Sample attributes below.
lcp:interface-config=rate-limit input qos-group 1 496000 64500 64500 conform-action transmit exceed-action drop
lcp:interface-config=rate-limit output qos-group 1 496000 64500 64500 conform-action transmit exceed-action drop
Every connection from a user in, even if they land on the same Virtual-Template, will create unique Virtual-Access(x) interfaces.
Lets say there is a user1, and they buy two services from you. It is easier if you give them unique user names for each service, but you can tell the RADIUS server to also match on the service type and return different rate limits based on that.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide