[j-nsp] Tower top switch/router recommendation..
OBrien, Will
ObrienH at missouri.edu
Wed Mar 23 18:41:49 EDT 2011
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
> pkranz at unwiredltd.com
>
>
>
> -----Original Message-----
> From: OBrien, Will [mailto:ObrienH at missouri.edu]
> Sent: Wednesday, March 23, 2011 3:26 PM
> To: Peter Kranz
> Cc: Pavel Lunin; juniper-nsp at puck.nether.net
> 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:pkranz at unwiredltd.com> pkranz at unwiredltd.com
>>
>> From: Pavel Lunin [mailto:plunin at senetsy.ru]
>> Sent: Wednesday, March 23, 2011 2:43 PM
>> To: Peter Kranz
>> Cc: Doug Hanks; juniper-nsp at 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=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 juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
More information about the juniper-nsp
mailing list