Как задать приоритет трафика в локальной сети на OpenWRT?

Question

[Vitaliy Ivanov]

Хотел бы задать приоритет трафика в локальной сети одному/двум конкретным устройствам, чтобы остальные устройства ждали, пока канал освободится
Приоритет хотел бы сделать и для TCP, и для UDP

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

Вроде бы можно сделать на роутерах Микротик

Хотя в другом вопросе сообщают, что приоритет задать нельзя

Роутеры Микротик в магазине стоят недёшево, а у более дешёвых моделей аппаратные характеристики никчёмные, например, порты 100 Мегабит или только WiFi 2.4 ГГц

Хотел бы по возможности обойтись имеющимся роутером на OpenWRT 19 (хотя он и слабоват)
1. Возможно ли реализовать это на openWRT, не покупая дополнительные роутеры Микротик? Да и разбираться в нём придётся немало
2. Воможно, я ищу не там? Какие ещё подходы могут быть?

Схема сети

spoiler

Comments

[SunTechnik]

Сколько устройств в вашей сети? Они все подключены в этот роутер или ещё есть коммутаторы? Проводом или через wifi?

[Vitaliy Ivanov]

SunTechnik, вот два обычных + пара иногда работает (и нагрузка от них как раз непостоянная, непредсказуемая и низкоприоритетная). Подключены все устройства к этому роутеру, но все по-разному: и по проводу напрямую, и через доп.свитч, и по WiFi

[SunTechnik]

Vitalya Ivanov, Перечитал, но ничего не понял ...
"вот два обычных + пара иногда работает (и нагрузка от них как раз непостоянная, непредсказуемая и низкоприоритетная)" Это вообще про кого ?

Если два устройства подключены через switch, то их траффик вообще через роутер не ходит. Соответственно настройки QoS на роутере на этот траффик влияния не оказывают.

Работа WiFi зависит от кучи внешних факторов.

Вам скорость между кем или куда надо гарантировать ? Эти устройства подключены непосредственно в роутер или через промежуточные коммутаторы ?

В вопросе - речь про локальные устройства, в примере ответов - речь про канал провайдера...
( И даже в канале - речь может идти о входящем и исходящем траффике).

[Vitaliy Ivanov]

SunTechnik, действительно, надо было сразу схему зарисовать. Вот приложил в вопросе. В общем-то, жёлтые устройства занимают весь канал. Нужен абсолютный приоритет зелёных устройств

[Zerg89]

Если низко приоритетных пк всего два насторйте им на адаптерах 10мб/с полосу и все

[GavriKos]

Vitalya Ivanov, канал чего? Сети? Или к провайдеру?
Какая ширина канала?

[Vitaliy Ivanov]

GavriKos, да, общий канал к провайдеру, который 100 Мегабит

[Vitaliy Ivanov]

Zerg89, хотелось бы, чтобы они могли делать обмен только когда основные устройства не имеют активности, а если с основных устройств идёт работа, то они освобождали канал

[Zerg89]

Vitalya Ivanov,

Хотя в другом вопросе сообщают, что приоритет задать нельзя

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

[Vitaliy Ivanov]

Zerg89, спасибо, понял так, что и нет смысла пытаться настраивать, только хуже можно сделать. Тем более стабильность скорости меняется от случая к случаю

Answer 1

[Вячеслав Васильев]

НАчните все же с QpS он в общем то работает и нормально.
Убедитесь, что он поддерживается во всех местах прохождения трафика в вашей сети и вышестоящего провайдера, т.к. самое узкое место может быть именно там.
Если нет, то вариантов не так много.
Создавайте аксес-листы и шейпите их по скорости, как то так.
Можно по разным виланам раскидать и шейпить уже виланы...
Это уже от роутера и архитектуры сети зависит, но в этом случае Вы должны быть уверены, что далее у провайдера все хорошо и нет узких мест.
Если все же выяснится, что узкое место действительно у провайдера и QoS не помогает, то придется поднимать випиэн где то в широком месте и уже там делить правильно канал и шейпить его части.

Comments

[Vitaliy Ivanov]

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

Чисто эмпирически только установил - надо уменьшить количество соединений, видимо, ограничение именно какого-то объёма, что-то вроде количество соединений * скорость
Да и то всё меняется день ото дня, буквально случайное поведение

[Вячеслав Васильев]

Это не гвозди миркоскопом.
Шейпить скорость по аксес листам или по виланам это обычное дело.
Более того, когда еще не было повсеместной поддержки QOS, в девяностых все провайдеры так делали. Приоритет под электронную почту, потом обычный хттп траф, а фтп душили и т.д.
Вам просто нужно понять, кто или что у Вас эрет больше всего траффика?
Это обычно бывают либо скачиваемые торренты, либо вредоносный код.
Проверьте, если торренты, то именно их в отдельную группу и шейп по ним максимум в пол пропускной способности канала, а то и того меньше.
Если вредоносный код, например боты установил зловредный код у кого-то или сделал из какого то компа випиэн или прокси... Это надо найти и удалить.
Если это будет на торрент, а что то другое, говорите, помогу конкретнее, что и где прописать нужно.

[Vitaliy Ivanov]

Вячеслав Васильев, я посмотрел теорию, а то с этим дело я не имел на практике
Вредоносного точно нет
В общем-то как раз проблема, что эти настройки статичные, вот так же предлагается установить постоянный битрейт
Насколько я понимаю, openwrt может работать только на низких уровнях, типа tcp/udp и по IP, да и то наверняка много ресурсов потратится. Какой-нибудь bittorrent не отсеит, но появилась мысль отсеивать по udp + IP, например

openwrt

В общем, спасибо за предложение, но до реализации пока руки не дошли, да и неизвестно, когда ещё дойдут)

Answer 2

[Vitaliy Ivanov]

Действительно, самое простое решение было использовать встроенный QoS на оригинальной прошивке TP-LINK. Приоритет задаётся только исходящему трафику, но этого оказалось достаточно для повышения стабильности. Больше не было отвалов при нагрузке upload