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

[OBrien, Will]

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=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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp