[j-nsp] Juniper CoS question?

Harry Reynolds harry at juniper.net
Fri Sep 28 15:24:34 EDT 2012

In-line with <<<<

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of tim tiriche
Sent: Friday, September 28, 2012 11:50 AM
To: juniper-nsp at puck.nether.net
Subject: [j-nsp] Juniper CoS question?

4 fwd classes defined (transmit/buffer size percentages and priority) on 10G interface EF (5% strict-high) AF(80% - high), BE(10%-low), NC(5%-low)

case1: if i send 80% traffic on BE and no other traffic - should the traffic be dropped if it is out of profile but bandwidth available?

<<< It will be serviced, though mostly in the excess region. This assume you have no shaping/rate-limit set, and that you have not blocked excess region usage with (the above shaping/rate limiting), or via excess-none.

case2: if i send 10% traffic on AF (inprofile) and BE 70% out of profile.  would BE (out of profile) be dropped? even though port is not congested or will all be serviced?
or will the BE queue be congested and start buffering?

<<< 10% AF is serviced first, priority based scheduling. Then the 70% BE, 10% of which is in profile, the other 60% as excess. There should be no congestion as 10% + 70% is < 100% (which is whatever the IFD is shaped to).

if in case2, BE drops: is there a way to service all traffic as long as there is capacity but service the high priorities one?

<< this is the default. Trio/MPC uses strict priority queuing. SH/H, Medium, Low, then excess region with excess high and excess low. Higher priorities can starve lesser ones. So, for example, I would set NC to high, to ensure that SHH/H cannot starve, and make sure you rate limit the EF (which is at SH and therefore not subject to a tx rate (unless you add shaper/Rl)), else it can get 100% of bandwidth and starve all non-high schedulers.

Hardware MX MPC - MAD not supported.

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