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

Pavel Lunin plunin at senetsy.ru
Wed Mar 23 17:42:56 EDT 2011


>        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&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.


More information about the juniper-nsp mailing list