шейпинг на MX80

[rover-lt]

Товарищи,

есть конфиг

 

traffic-control-profiles {
   SHAPE-300 {
       scheduler-map SCHEDULER_1;
       shaping-rate 285m burst-size 356250;
   }
}
interfaces {
   ge-1/1/0 {
       output-traffic-control-profile SHAPE-300;
   }
}

 

который с указанным burst-size 356250 дропает примерно 0,5% пакетов. Если оставляю дефолтный burst size (рассчитывается из Tc=100мс), то дропать начинает ISP, так как у него Tc=10мс.

Есть предположение, что размер буфера (Delay Buffer) для хранения пакетов которые превышают Burst Size слишком маленький и может уменьшаться так, чтобы соответствовать Burst Size. То есть хранит только тот излишек, который может уйти в следующую итерацию.

Так ли это?

Edited February 24, 2016 by rover-lt

[dmvy]

на таких скоростях делайте полисер и бурст побольше... шейпинг на скоростях больше мегабита не несет существенных преимуществ перед полисером.

[orlik]

При таких скоростях и таком размере берста (356250) это равносильно тому что что берста нет вообще

[orlik]

И кстати а что у вас показывает show interfaces queue ge-1/1/0

[rover-lt]

на таких скоростях делайте полисер и бурст побольше... шейпинг на скоростях больше мегабита не несет существенных преимуществ перед полисером.

в моем случае шейпинг несет значительные преимущества. Зачем мне делать берст такой величины, что будет обрезан вышестоящим провайдером?

Весь цимус в том, чтобы "обрезаемую" часть берста забуферизовать. И в моем случае всплески трафика превышают установленный аплинком берст в 3-10 раз

 

И кстати а что у вас показывает show interfaces queue ge-1/1/0

показывает, что дропает примерно 0,5-3% пакетов в зависимости от микроберстов в день

Queue: 7, Forwarding classes: af41, ef
 Queued:
   Packets              :     		143261696           		656 pps
   Bytes                :   		50760870638       		2215072 bps
 Transmitted:
   Packets              :     		142870852           		656 pps
   Bytes                :   		50400474648       		2215072 bps
   Tail-dropped packets :             		0             		0 pps
   RL-dropped packets   :             		0             		0 pps
   RL-dropped bytes 	:             		0             		0 bps
   RED-dropped packets  :                390844             		0 pps
	Low         		:                390844             		0 pps
	Medium-low          :             		0             		0 pps
	Medium-high 		:             		0             		0 pps
	High                :             		0             		0 pps
   RED-dropped bytes    :     		360395990             		0 bps
	Low         		:     		360395990             		0 bps
	Medium-low          :             		0             		0 bps
	Medium-high 		:             		0             		0 bps
	High                :             		0             		0 bps

Микроберсты до гигабита высотой и длиной до 100мс

Если оставляю дефолтный burst size (рассчитывается из Tc=100мс), то дропать начинает ISP, так как у него Tc=10мс.

Вот примерный график с поминутным снятием статистики:

если посмотреть Wireshark'ом, с интервалом в 0.001 сек, то будут всплески до 600mbit.

 

что совсем не радует TCP и приложения которые его используют.

Edited February 25, 2016 by rover-lt

[rover-lt]

решилось путем установки q-pic-large-buffer, что разрешило ставить буфер передержки более чем на 10% от bandwidth и, соответственно, увеличением его до больших значений.

В Циске тупо ставишь размер буфера практически какой хочешь - и никаких перезагрузок.