[j-nsp] Tower top switch/router recommendation..

Wed Mar 23 18:31:08 EDT 2011

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