[j-nsp] policers on LAG
Pavel Lunin
plunin at senetsy.ru
Thu Apr 7 18:03:56 EDT 2011
> PS: those observations were done on older M320 and I-chip based
> MX-series. Do not have Trio-based devices, so may be I'm wrong here.
> Still do not believe that intrachip communications were introduced
> to aid exact policing anyway.
>
Thanks. Actually I figured out myself with help from the local SE team, that
this is normal. BTW it's absolutely same for Trio, with an exception you can
have several 10GE links per PFE on Trio, when for the i-chip case 10GE LAG
is always cross-PFE.
> > Too many things get broken in my mind, if this assumption is correct.
> > Please, tell me it's wrong )
>
> It's absolutely normal :(
>
>
What I could not figure out, writing the initial message (and what I
actually have figured out :), is how traffic is supposed to be policed on
customer-facing units of a multi-PFE LAG, facing the distribution network
head-tail switch/cluster. The problem is that you can't just divide the rate
by the number of links in the LAG, or the customers will never reach the
rate they paid for within a single, say, TCP session (one file download),
since the balancing is per-flow. The right answer is to use 1:1
active/passive link-protection mode LAG without balancing :) Or put all
members to the same PFE.
Although for the aggregation-to-access links the balancing might not be a
very big need (until you're ready for congestion in case of a failure),
AFAIR, it's possible to use 'manual' balancing for this case making
different lag members primary for different interface units.
--
Regards,
Pavel
More information about the juniper-nsp
mailing list