[incognito14]

Вопрос наверное банальный, но есть еще не уточненные моменты, по-этому прошу сильно не кидаться помидорами.

Есть коммутатор Juniper EX3300, в него включаются абоненты. Необходимо зарезать скорость на порту. Я делаю это двумя способами для разных направлений (вх./исх.):

1) при помощи shaping-rate - режет скорость отлично, сколько задашь таким значением и ограничивается.

2) и второй механизм policer, используя burst-size-limit - режет скорость "плохо" т.е. график получается рваный.

Отсюда есть вопросы:

а) как правильно резать скорость на порту juniper?

б) как правильно рассчитать burst-size-limit? Я использую такую формулу (4000000*0,5)/8, а в мануале рекомендуют использовать 0,005.

в) как правильно объяснить клиенту, что это у juniper такие механизмы ограничения скорости, а не наш косяк?

г) есть ли другие способы ограничения скорости?

[alibek]

в) как правильно объяснить клиенту, что это у juniper такие механизмы ограничения скорости, а не наш косяк?

Как правильно объяснить покупателю, что 40 минут на кассе — это такие особенности кассового терминала, а не наш косяк?

[pfexec]

б) как правильно рассчитать burst-size-limit? Я использую такую формулу (4000000*0,5)/8, а в мануале рекомендуют использовать 0,005.

на маленьких полосах до 10Mbps всегда будет жопа. попробуйте ставить бёрст больше. вы собираетесь ставить 0.05 байта для 4Мбпс ? поставьте побольше. ну там 500kB, например. Поэкспериментируйте.

ну и прочитайте как работает полисер и что такое бёрст-сайз.

[incognito14]

pfexec для расчета бёрст-сайз до 10Мб/с я использую параметр 0,5

 

alibek непонял - это вы про что?

Т.е. получается, что в таких дорогих железяках как juniper нет нормальных механизмов ограничения скорости?

[twh.mega]

Если хочется, чтобы графики выглядели красиво, то надо не полисер вешать, а, скажем, шейпить с (W)RED-ом.

[alibek]

alibek непонял - это вы про что?

Я про то, что если клиента не устраивает качество услуги (или качество шейпинга), то ему совершенно без разницы, по какой причине так происходит.

Экспериментируйте, подбирайте параметры берста, завышайте скорость. Объяснять клиенту, что это все Juniper виноват, не стоит.

 

Т.е. получается, что в таких дорогих железяках как juniper нет нормальных механизмов ограничения скорости?

Цена железки роли не играет.

Важно для чего она предназначена.

Управлять скоростью лучше получится у BRAS, чем у коммутатора доступа.

[pfexec]

pfexec для расчета бёрст-сайз до 10Мб/с я использую параметр 0,5

вы формулу выбросьте и сделайте что вам советуют.

Т.е. получается, что в таких дорогих железяках как juniper нет нормальных механизмов ограничения скорости?

полисер работает везде одинаково или почти одинаково. вы прочитайте сначало о чем речь и почему так.

Управлять скоростью лучше получится у BRAS, чем у коммутатора доступа.

если в сконфигурированный полисером бёрст не влазит трафик и начинает дропаться, то нет большой разницы брас это или свитч.

[agr]

1) при помощи shaping-rate - режет скорость отлично, сколько задашь таким значением и ограничивается.

2) и второй механизм policer, используя burst-size-limit - режет скорость "плохо" т.е. график получается рваный.

Это происходит из-за разных механизмов ограничения скорости. shaper управляет исходящей полосой путем задержки отправления исходящих пакетов, policer управляет входящей полосой путем дропа входящего трафика превышающего установленные объемы.

 

а) как правильно резать скорость на порту juniper?

б) как правильно рассчитать burst-size-limit? Я использую такую формулу (4000000*0,5)/8, а в мануале рекомендуют использовать 0,005.

 

Указанный juniper'ом нижний предел burst-time в 5 миллисекунд - это чрезвычайно малое значение. Значения burst выбирайте в интервале 0.2-1 секунд. Причем чем выше CIR, тем меньше должно быть время burst.

 

Также видимый эффект действия полисера зависит от количества работающих через "полисируемый" интерфейс TCP сессий - чем больше сессий, тем менее важен размер burst. Т.е. например, грубо говоря, на гигабитном полисере при ста tcp сессиях любой burst будет приемлем, но при одной tcp сессии никакой burts не обеспечит плавной загрузки полосы - в этом случае график загрузки будет всегдя иметь зигзагообразный вид.

 

в) как правильно объяснить клиенту, что это у juniper такие механизмы ограничения скорости, а не наш косяк?

Это косяк не juniper, а технологии в принципе, policer на cisco будет выглядеть так же. Можете рассказать клиенту про Token bucket алгоритм(именно по нему работает policer) и про протокол TCP, скорость передачи по которому варьируется в зависимости от потерь на канале. Также можете предложить клиенту замерить скорость утилитой iperf в UDP поток заданной ширины или в несколько(не меньще 5) параллельных TCP потоков.

 

ЗЫ: советую делать CIR процентов на 10 больше номинальной скорости, чтобы сгладить оверхед служебных заголовков, так у клиентов будет меньше вопросов возникать...

[DVM-Avgoor]

Т.е. получается, что в таких дорогих железяках как juniper нет нормальных механизмов ограничения скорости?

 

EX3300 свитч, почему в нем должен быть полноценный QoS и/или шейпинг? Вы не ту железку выбрали просто, вот и все.

[incognito14]

б) как правильно рассчитать burst-size-limit? Я использую такую формулу (4000000*0,5)/8, а в мануале рекомендуют использовать 0,005.

на маленьких полосах до 10Mbps всегда будет жопа. попробуйте ставить бёрст больше. вы собираетесь ставить 0.05 байта для 4Мбпс ? поставьте побольше. ну там 500kB, например. Поэкспериментируйте.

ну и прочитайте как работает полисер и что такое бёрст-сайз.

 

Как раз таки путем эксперимента и выяснил, что значение в мануале не подходит. На сколько нужно брать бОльшее значение (я использую 0,5 для скоростей ДО 10 Мб/с)?

А вот по поводу полисера и в частности бёрста я так до конца и не понял. Но если дадите сылочку, где это будит достаточно хорошо описано буду признателен.

 

вы формулу выбросьте и сделайте что вам советуют.

Что именно сделать?

 

agr Т.е. если использовать механизм policer то при проверке корректности его работы, например тем же jperf, нужно использовать либо UDP пакеты либо TCP но в несколько потоков?

[alibek]

На сколько нужно брать бОльшее значение (я использую 0,5 для скоростей ДО 10 Мб/с)?

Подбирать опытным путем.

Универсальной формулы нет, зависит от полосы, типа и характера трафика и других факторов.

[incognito14]

На сколько нужно брать бОльшее значение (я использую 0,5 для скоростей ДО 10 Мб/с)?

Подбирать опытным путем.

Универсальной формулы нет, зависит от полосы, типа и характера трафика и других факторов.

Ну это получается какой-то "неправильный" механизм. Как я могу определить какой тип трафика будит у клиента? Трафик же может быть и не однордным

[alibek]

А какой правильный?

Можно использовать два EX3300, на обоих резать исходящий канал с использованием шейпера.

[incognito14]

А какой правильный?

Можно использовать два EX3300, на обоих резать исходящий канал с использованием шейпера.

использование двух коммутаторов для ограничения скорости - это как-то неправильно, если учесть, что для подключения клиента используется один коммутатор.

Ну так вот и я хочу понять какой "правильный" метод ограничения скорости?

[agr]

agr Т.е. если использовать механизм policer то при проверке корректности его работы, например тем же jperf, нужно использовать либо UDP пакеты либо TCP но в несколько потоков?

Да.

А вот по поводу полисера и в частности бёрста я так до конца и не понял. Но если дадите сылочку, где это будит достаточно хорошо описано буду признателен.

гуглите по фразе "token bucket".

[pfexec]

Что именно сделать?

сделайте уже что-то вроде

if-exceeding {
   bandwidth-limit 4m;
   burst-size-limit 500k;
}
then discard;

посмотрите сами, покажите клиенту, попробуйте +-100k.

 

У вас проблема в том что бёрст заканчивается раньше чем успевает разогнаться tcp. Нужно просто экспериментальным путём его подогнать под желаемый эффект.

Как раз таки путем эксперимента и выяснил, что значение в мануале не подходит. На сколько нужно брать бОльшее значение (я использую 0,5 для скоростей ДО 10 Мб/с)?

эта формула не подходит для маленькой полосы пропускания или для tcp трафика при такой полосе, - как вам больше нравится.

Можно использовать два EX3300, на обоих резать исходящий канал с использованием шейпера.

это свитч, причем весьма скромный. шейпинг у него пер порт. предлагаете для каждого клиента делать петлю ?

EX3300 свитч, почему в нем должен быть полноценный QoS и/или шейпинг? Вы не ту железку выбрали просто, вот и все.

какую же железку надо выбрать чтобы там был "полноценный кос и/или шейпинк" ?

[alibek]

предлагаете для каждого клиента делать петлю ?

Зато график будет красивый.

[incognito14]

предлагаете для каждого клиента делать петлю ?

Зато график будет красивый.

так дело то не в графике, а в реальном ограничении, без проседания с скачков

[alibek]

так дело то не в графике, а в реальном ограничении, без проседания с скачков

Не бывает такого.

Если трафик превышает лимиты, то он дропается.

Если просто тупо дропать все, что превышает лимит, то качество будет совсем неприемлимым (т.к. микроберсты в сети есть всегда). Поэтому есть некий «буфер» и пока он не кончился, пакеты не дропаются; burst-size размером этого буфера и управляет.

Но если и этот буфер переполняется, то пакеты дропаются. И когда они дропается, то на TCP будет именно то, что описали.

[dmvy]

вы выбрали коммутатор, а не роутер. Одно из отличий - размер буфера. Он и определяет на сколько будет длинная очередьи как долго в нем может пролежать пакет. У коммутаторов он измеряется единицами Мб, когда у роутеров это число десятки или сотни Мб. Поэтому роутер может именно шейпить (класть пакет в буфер и, создавая задержку, притормаживать TCP-сессию).

 

Но с увеличением скоростей и на роутерах стали использовать policer вместо shaper, т.к. эффект схожий. Как и говорили это верно для скоростей свыше 10Мбит/с и грамотной настройке burst.

[DVM-Avgoor]

какую же железку надо выбрать чтобы там был "полноценный кос и/или шейпинк" ?

 

 

MX!

[twh.mega]

МХ очень удачная железка, подходящая в качестве ответа под довольно большое количество вопросов вида "а что бы мне поставить в качестве Х?". Но что-то мне подсказывает, что "шейпить 4мб/с канал" все же не для МХ задача :-) Ну, разве что этих 4мб/с каналов столько...

[DVM-Avgoor]

Ну дак на MX и бордер можно и шейп и блекджек с куртизанками, НАТ через модуль например. Он мультисервисный роутер, прям вот то что надо. А свитчи шейпят плохо, в большинстве случаев вообще никак.

[pfexec]

соль в том что на MX'е такой же полисер. Да, буферы жирнее, да полисеры могут быть иерархичным и много чего еще, но алгоритм работы тот же.

А свитчи шейпят плохо, в большинстве случаев вообще никак

у топик-стартера идеальная ситуация: тарифны план применяется на порту доступа с абонентом. я считаю это успех уже само по себе и куда ценнее любого бираса. :)

[dmvy]

соль в том что на MX'е такой же полисер. Да, буферы жирнее, да полисеры могут быть иерархичным и много чего еще, но алгоритм работы тот же.

А свитчи шейпят плохо, в большинстве случаев вообще никак

у топик-стартера идеальная ситуация: тарифны план применяется на порту доступа с абонентом. я считаю это успех уже само по себе и куда ценнее любого бираса. :)

в MX есть нормальный шейпер. Называется scheduler

http://www.juniper.net/techpubs/en_US/junos13.2/topics/usage-guidelines/cos-configuring-the-scheduler-buffer-size.html