The burst is there to allow traffic to behave nicely. In real life, it allows TCP some time to resize and adjust. If you just lop off traffic it gets a little ugly on performance. You *really* want to combine this with some sort of prioritizer like qos to make it behave the way you want.
On Mar 23, 2011, at 5:31 PM, Peter Kranz wrote: > Hi Will, > If I undertand correctly, this version handles a CIR with a certain > burst-size in terms of bits.. But doesn't handle the need to allow ongoing > bursts above 'bandwidth-limit' if the resources are available.. That > unfortunately is the gist of the problem that makes it more difficult to > solve.. > > Peter Kranz > www.UnwiredLtd.com > Desk: 510-868-1614 x100 > Mobile: 510-207-0000 > [email protected] > > > > -----Original Message----- > From: OBrien, Will [mailto:[email protected]] > Sent: Wednesday, March 23, 2011 3:26 PM > To: Peter Kranz > Cc: Pavel Lunin; [email protected] > Subject: Re: [j-nsp] Tower top switch/router recommendation.. > > 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:[email protected]> [email protected] >> >> From: Pavel Lunin [mailto:[email protected]] >> Sent: Wednesday, March 23, 2011 2:43 PM >> To: Peter Kranz >> Cc: Doug Hanks; [email protected] >> 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=672B7l6d7 >> V&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 [email protected] >> https://puck.nether.net/mailman/listinfo/juniper-nsp > > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
