I create my policers per subnet for convenience. You can do them per IP by simply using /32 but if each customer has a dedicated cider block, it'll be pretty straight forward.
Here's how I do it: on an interface, (this is from a MX, but similar context on a srx) unit 201 { family inet { filter { input InboundPolicer; output Outbound Policer; } address blahblah; } Then... firewall family inet filter InboundPolicer term CustomerX { from { address { 192.168.10.0/24; } } then prefix-action limitCustomer10Mbit; } Then... firewall family inet prefix-action imitCustomer10Mbit policer 10MbitPolicer; subnet-prefix-length 24; destination-prefix-length 32; ## this says from the /24, limit based on traffic to a particular /32. I use this to limit bandwidth to each user on my campus. Adjust as needed. /24 would consider the entire block. Then: firewall policer limitCustomer10Mbit{ if-exceeding { bandwidth-limit 10000000; burst-size-limit 1250000; //There's a complex formula for this, but it works out to about 1/8th of the bandwith you want. } then discard; Got it? Starting with this, I'd take a look at the example QoS configs and combine the two to create some filters for your needs. I'm not terribly familiar with J series, but they will likely do this as the older M series would. (MX does it without even trying hard) and I think it's doable with the SRX, but I'd build a lab version first and try it. Will On Mar 23, 2011, at 4:52 PM, Peter Kranz wrote: > Hi Pavel, > > Each customer is on a separate non-overlapping subnet, but > NOT on a different VLAN generally.. So filtering at the subnet level is > easy.. does this change your response at all? > > > > Peter Kranz > www.UnwiredLtd.com <http://www.unwiredltd.com/> > Desk: 510-868-1614 x100 > Mobile: 510-207-0000 > <mailto:pkr...@unwiredltd.com> pkr...@unwiredltd.com > > From: Pavel Lunin [mailto:plu...@senetsy.ru] > Sent: Wednesday, March 23, 2011 2:43 PM > To: Peter Kranz > Cc: Doug Hanks; juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] Tower top switch/router recommendation.. > > > > > > Seems like filters+policers allows you to specify bandwidth-limit > and burst-size.. > > I.e. if you had a pool of 10 mbps.. you could carve it into individual > customer chunks at their... But no way to allow the customer to burst above > that bandwidth-limit to some specified higher BW, only allowed to specify > burst in terms of burst-size.. > > I need a way to ensure a customer gets their CIR at all times, and if > adequate extra BW available, they can burst to a higher (but limited to a > specified MIR) bandwidth.. > > > > Peter, what you talk about looks like a policer/shaper per VLAN. If I didn't > miss something, of course. > > EX series won't help you since it only supports policers for incoming (not > outgoing) traffic and only 8 queues (and consequently 8 different shaper > instances) per physical port. Of course you can try to do policing on > ingress, but you'll need to write and maintain a hell of filters to > distinguish the customers. This means you need to know something other than > a VLAN to demux them: e. g. their IPs, but this means you have to know it, > customers can't use overlapping space, etc. Not flexible at all and too much > of manual work. > > So in order to do what you want, some sort of aggregation router is needed, > which would support either policers or shapers per outgoing vlan. In case of > <1Gbps. well, maybe the higher J-series or SRX650 in packet mode (or even > together with the stateful stuff, why not). > > Than you can configure something like this: > http://books.google.com/books?id=EGi0zUwhB4QC > <http://books.google.com/books?id=EGi0zUwhB4QC&lpg=PA256&ots=672B7l6d7V&dq=j > unos%20policer%20out-of-profile&hl=ru&pg=PA256#v=onepage&q&f=false> > &lpg=PA256&ots=672B7l6d7V&dq=junos%20policer%20out-of-profile&hl=ru&pg=PA256 > #v=onepage&q&f=false > > Nothing personal about the book name :) > > Two policers, first is for higher bw (say, 10M), which drops exceeding > traffic, than, if it didn't, the next one (say, 5M), which somehow lowers > the packets' priority: sets the fw-class, which is than mapped to an > appropriate low-priority queue, sets the loss-priority, marks them as > out-of-profile (AFAIR only supported on J/SRX but it's actually more or less > the same as mapping to a class, which is bound to a lower-priority que,) or > something else. > > > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp