Нужна помощь в настройке QoS на Микротике

[devd1]

Нужен специалист, который "собаку съел" на ОС микротик.

Требуется настроить приоритезацию и шейпинг трафика.

Здесь хорошо описана модель http://habrahabr.ru/blogs/sysadm/131295/, но у меня она работает не так как нужно и мне нужно помочь (не бесплатно) разобраться где грабли в моей сети.

Кто готов помочь, можно в асю 319341212

[Saab95]

Зачем вам нужны вообще эти сложные приоритеты? Когда достаточно резать весь траффкик с портами менее 1000 в высокий приоритет, с портами 1000-30000 в средний, а 30001-65535 в низкий.

 

Сколько не баловался приоритетами - никогда зарезка более подробная не давала ничего положительного, кроме загрузки процессора роутера.

[nur16]

На больших объемах, когда кол-во шейпов в Queue Tree больше 1000,

выставление сложных приоритетов уже ощутимо дает эффект.

 

Топикстартеру вопрос, вы учли момент с "SRC-NAT"? Может из-за него не работает?

[Saab95]

Ощутимый эффект дает правильная политика тарифов и своевременное расширение каналов. А давить клиентов шейперами путь в никуда.

[martini]

2 Saab95 - торрентов хватает и с портами 1000-30000 , так что не вариант

[Saab95]

Я у себя только ограничение по количеству пакетов оставил и настроил на равное деление трафика между всеми - никто не жалуется, просто у всех проседает скорость в момент перегруза, но такое бывает всего 2-3 часа раза 3 в неделю.

 

 

[devd1]

Абоны жаловались на скорость вечером. При этом торренты и шареманы выедают всё по тарифу, а у сёрферов подтормаживает веб. Видео с ютубе и т.п. вечером вообще еле ворочается. Снифер у абона показывает, что при загрузке видео очень много tcp-retransmission, которые появляются из-за потери пакетов.

После запуска именно той модели, что я указал, ОЩУТИМО ускорилась загрузка страниц

Топикстартеру вопрос, вы учли момент с "SRC-NAT"? Может из-за него не работает?

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

Вечером полная белиберда, в 2-х словах и не скажешь.

Резюмируя, QoS нужен. Своими силами не получается. Нужно продать нам свою реализацию QoS или разобраться, где грабли в нашей.

[Saab95]

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

 

Вы выполнили сделующие требования при создании шейперов:

 

1.Ограничили скорость канала на 90% от максимальной? Не падает ли пропускная способность канала в момент максимальных нагрузок?

2.Сделали шейпер на Download на стороне вашего локального интерфейса, а Upload на стороне внешнего интерфеса?

3.Не попадают ли у вас одни и те же данные в разные правила, правильно ли поставлены галочки Passtrough в метках пакетов?

 

 

 

[devd1]

1.Ограничили скорость канала на 90% от максимальной?

Ответ - да. аплинк 100мбит, родитель-доаунлоад макс.лимит=90мбит

2.Сделали шейпер на Download на стороне вашего локального интерфейса, а Upload на стороне внешнего интерфеса?

Ответ: в статье, на которую я ссылался описано, что Download работает на Global-out (у меня один локальный интерфейс, поэтому без разнницы global-out или local. Нюанс в том, что локальный интерфейс для аб.трафика- во влане физического локального интерфейса). Upload, опять же, согласно статье, не на внешний интерфейс, а на Global-total, т.к аплинков несколько. Сразу оговорюсь, что проблема начинается даже, когда был 1 аплинк. Остальные аплинки включаю для разгрузки первого, главная проблема не в них.

3.Не попадают ли у вас одни и те же данные в разные правила, правильно ли поставлены галочки Passtrough в метках пакетов?

Ответ: все правила сквозные, так и было задумано, трафик перемаркируется в зависимости от его типа. Наблюдения показывают, что нужный трафик в нужном классе, но частную проблему с видео это не решает.

Предполагаю (но очень не уверен), что проблема не в очередях, а в файрволе (НАТ, access/drop правила файрвола)

Так предоставили бы давно уже реквизиты для доступа на ваш роутер, мы бы посмотрели где может быть косяк

Ответ: ну не выложу же я параметры доступа на форуме... Я полностью готов поговорить в привате с профессионалом.

[Saab95]

Ответ: в статье, на которую я ссылался описано, что Download работает на Global-out (у меня один локальный интерфейс, поэтому без разнницы global-out или local. Нюанс в том, что локальный интерфейс для аб.трафика- во влане физического локального интерфейса). Upload, опять же, согласно статье, не на внешний интерфейс, а на Global-total, т.к аплинков несколько. Сразу оговорюсь, что проблема начинается даже, когда был 1 аплинк. Остальные аплинки включаю для разгрузки первого, главная проблема не в них.

 

Тут вы не правы.

 

Если у вас локальный интерфейс во влане - то и Download должен быть на нем. А Upload должен быть на ОДНОМ внешнем интерфейсе. А если вы пытаетесь рулить Global-out и Global-in то ничего толкового не получится. Т.к. В этом случае за Download посчитается весь входящий траффик на всех интерфейсах и правило не будет нормально ограничивать скорость, а за Upload весь исходящий.

 

 

Вот например у меня сделано - пару правил, выход в интернет через влан, а локалка в локальном сетевом интерфейсе. Все работает исправно в любое время.

 

[devd1]

В этом случае за Download посчитается весь входящий траффик на всех интерфейсах

я думал, что трафик"считается" = "маркируется в firewall mangle". А Global-total, -out - это "ссылка" на поток данных. Ведь в очередях указывается интерфейс или global-out как родитель, т.е то, куда отправлять отшейпенные данные. или я не прав?

P.S. Поменял в download global-out на локальный интерфейс (влан). Посмотрим, что получится

Edited March 15, 2012 by devd1

[Saab95]

В Mangle вы только маркируете трафик, при чем лучше маркировать пакеты, а не соединения.

 

Далее в Queue Tree микротик смотрит сколько данных передаются на интерфейсе указанного направления, если данных становится более определенного значения - правило начинает буферизовать пакеты и отбрасывать низкоприоритетные. Естественно буфер пакетов должен быть установлен PCQ размером в 100000 а лучше более байт. В этом случае трафик клиентов не будет отброшен, а просто появится большая задержка на пути следования, тем самым приложение, генерящее трафик само сбавит скорость, а не будет слать кучу переповторов отброшенным шефпером пакетов.

 

 

[devd1]

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

Что тогда понимать под global-total? (больше риторический вопрос). В указанной выше статье объясняется, почему при SRC-NAT нельзя для upload указывать Global-out.

У меня total-limit в pcq = 20000 (пакетов, т.е грубо 20000*1500=30Мбайт)для группы, где до 400 абов онлайн.

Как можно отловить, кто именно дропает пакеты? Когда вечером у менее приоритетной группы (С) очередь горит красным, а у более приоритетной (В) - зеленым, абон в (В) получает видео со скоростью меньше мегабита (тариф 8мбит), в снифере всё пестрит ретрансмиссией tcp, а пинг на гугль, ютубе дает до 10% потерь

Edited March 15, 2012 by devd1

[Saab95]

Вот какие должны быть типы буферов для каждого направления:

 

 

Видите какие большие буфера - никаких дропов нет. Приложения сами сбрасывают скорость из-за того, что увеличивать окно TCP уже некуда.

[devd1]

УАУ!

Открываете мне глаза! А сколько абонов входит в группу, для которой такие параметры queue type?

... Подумал тут 3млн пакетов - это до 4Гбайт оперативки чтоли? (если пакет ~1500байт)

и еще? длина очереди 20k. Не будут ли тормозить онлайн игры?

Edited March 15, 2012 by devd1

[Saab95]

УАУ!

Открываете мне глаза! А сколько абонов входит в группу, для которой такие параметры queue type?

... Подумал тут 3млн пакетов - это до 4Гбайт оперативки чтоли? (если пакет ~1500байт)

и еще? длина очереди 20k. Не будут ли тормозить онлайн игры?

 

Ну как бы это максимальный размер буфера пакетов, средний размер пакета 500 байт, так что все нормально влезает в 2гб оперативки, поддерживаемой микротиком. Онлайн игры тормозить с чего бы будут? Если клиент хочет играть в онлайн игру - пусть выключает свои закачки и играет. А играть и качать торренты слишком круто.

 

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

 

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

 

Тут правильнее подходить к решению вопроса с другой стороны - кто режет скорость на канале интернета? Если провайдер режет на уровне 100мбит, а потока к вам идет на 120мбит, то как вы уже у себя будете резать не важно, т.к. на стороне провайдера 20мбит уже отброшены, причем без всякого шейпера и к вам идут разрозненные данные, вы их дорезаете на скорости 90мбит - в итоге получается ерунда. Скорость вы ограничели, а приоритезацию пакетов на прием делать не можете толком.

 

Правильнее было бы подключиться к провайдеру гигабитным интерфейсом, купить у него полосу 130мбит а у себя ограничение поставить на 90мбит. В этом случае к вам идет поток около 120мбит и вы его своим шейпером обрабатываете. Тогда все будет работать исправно.

[devd1]

В общем поднял pcq-limit до 2к, total-limit до 800000. Согласно теории http://mikrotik.axiom-pro.ru/library/megisrus.pdf учитываетя размер буфера под пакет = 2200 байт, итого при 800000 пакетов может быть задействовано до 1,7 ГБайт памяти. Делю это на 400 (человек онлайн с этой группы). итого размер очереди = 2к больше не могу)

Вечером - таже фигня, видео на скорости 1-2 мбит, независимо от тарифа и приоритета группы, причем аплинк занят был всего на 70-80%. Для эксперимента выключил все правила в queue tree - загрузка канала не упала, не поднялась, т.е от моего QoS толку НОЛЬ!!!

Братья старшие, профессионалы, откликнитесь, помогите настроить! Будет Вам большое человеческое спасибо... и финансовое тоже!

[Saab95]

А вам не приходит в голову что проблема может быть не у вас, а где-то в интернете. Ведь если правила все отключены - значит и работать все должно без проблем.

 

У меня например сейчас наблюдаются проблемы с ютубом, рамблером, форумом нага, еще парочкой мест, может еще но никто не жаловался еще на другие ресурсы.

 

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

[devd1]

Резюмирую. QoS заработал лучше после совета Saab95 об увеличении очереди pcq.

Проблема низкой скорости загрузки видео с ютубе оказалась действительно вне моей компетенции. Вот какое письмо я написал вышестоящему провайдеру:

 

Имеет место следующая некритическая проблема:

 

В вечернее время видео с серверов ютубе выгружается на низкой скорости (около 1-2мбит), не зависимо от загрузки нашего аплинка до Ростелеком и от загрузки нашей локальной сети. Причем видео погружается с серверов ip 208.117..., 208.65... и близких им. И пинг на них с внешнего интерфейса нашего пограничного роутера

 

...

 

208.65.155.208 1500 56 115ms

208.65.155.208 1500 56 114ms

208.65.155.208 1500 56 113ms

208.65.155.208 timeout

208.65.155.208 1500 56 114ms

208.65.155.208 1500 56 113ms

208.65.155.208 1500 56 113ms

208.65.155.208 1500 56 114ms

sent=4980 received=4659 packet-loss=6% min-rtt=112ms avg-rtt=115ms

max-rtt=165ms

 

 

 

Одновременно "GEPON-абонент" Ростелеком тот же самый ролик подгружает с ip 74.125.168.245, скорость в вечернее время около 6 Мбит. Пинг на этот сервер с внешнего интерфейса нашего пограничного роутера

 

...

 

74.125.168.244 1500 58 39ms

 

74.125.168.244 1500 58 43ms

 

74.125.168.244 1500 58 39ms

 

74.125.168.244 1500 58 40ms

 

74.125.168.244 1500 58 40ms

 

74.125.168.244 1500 58 39ms

 

74.125.168.244 1500 58 39ms

 

sent=5000 received=4986 packet-loss=0% min-rtt=39ms avg-rtt=39ms

max-rtt=52ms

 

Трейс в случае нашего абонента:

 

Трассировка маршрута к 208.117.226.85 с максимальным числом прыжков 30

 

...

3 14 ms 13 ms 13 ms 90.150.2.42

4 25 ms 12 ms 13 ms 90.150.2.42

5 12 ms 14 ms 13 ms 188.128.90.137

6 105 ms 105 ms 107 ms 95.167.92.66

7 105 ms 105 ms 106 ms 62.208.252.25

8 111 ms 96 ms 122 ms xe-1-3-0-xcr1.fra.cw.net [195.2.21.113]

9 98 ms 98 ms 98 ms xe-11-1-1-xcr1.fix.cw.net [195.2.28.218]

10 108 ms 106 ms 106 ms 62.208.252.6

11 100 ms 100 ms 102 ms 208.117.247.179

12 98 ms 99 ms 101 ms 208.117.226.85

 

Трассировка завершена.

 

 

 

Трейс в случае абонента Ростелеком:

 

Трассировка маршрута к 74.125.168.245 с максимальным числом прыжков 30

 

1 <1 мс <1 мс <1 мс 192.168.122.3

2 14 ms 13 ms 14 ms 195.54.1.225

3 15 ms 14 ms 13 ms 212.57.167.209

4 16 ms 14 ms 14 ms 90.150.2.42

5 14 ms 16 ms 14 ms 188.128.90.137

6 40 ms 41 ms 39 ms 95.167.95.103

7 47 ms 83 ms 40 ms 79.133.94.86

8 51 ms 41 ms 40 ms 209.85.243.239

9 45 ms 41 ms 42 ms 74.125.168.245

 

Трассировка завершена.

 

Выделенный жирным маршрутизатор отправляет пакеты наших подсетей по маршруту, отличному от маршрута пакетов абонентов Ростелеком (физ.лиц), и эта политика явно ухудшает сервис для нас

 

Прошу рассмотреть возможность изменить политику для нашего трафика, чтобы загрузка с видео-серверов была быстрее.