Simple Queue. Приоритезация RDP трафика.

[AndrK189100]

Прошу совета, как грамотно дать RDP трафику высший приоритет. Может я сделал не грамотно
Преамбула.
Есть ЛВС 40 ПК(Unutu + RDP клиент Remmina), канал передачи данный 50 Мбит. Шлюз Mikrotik RB3011UiAS. Часть ПК находятся в складском корпусе, который соединен с административным выделенным каналом 100 Мбит. Основная работа происходит на удаленном RDP сервере. Так же между офисом и сервером поднят PPTP туннель через который подключены офисные и складские принтеры. Т. к. Linux + Remmina + проброс принтеров по RDP - это боль.
Особенно в разрезе того, что печатают, ну очень много. 3-4 тысячи страниц за рабочий день. А часто больше.

Длительное время наблюдалась следующая картина: Регулярные внезапные обрывы RDP сессии. Причем, в складском корпусе это происходило чаще, чем в "офисе". И с каждым годом ситуация ухудшалась. Т. е. если 3 года назад RDP на складе рвалось 2-4 раза в день. То на октябрь 2023 15-20 раз. Пользователи "завыли". Понять их можно... Короче, партия сказала разобраться, комсомол ответил есть.

Для начала был проверен выделенный канал, т. к. первое, что пришло в голову, проблемы с ним. Но, нет. Скорость соответствует заявленной, потерь нет.
Позвонил провайдеру. Само собой говорящая голова из тех. поддержки начала меня уверять, что все просто отлично, они лично контролируют каждый пакет, составляют акт с печатью и т. д. Но, я таки продавил и меня перевели на уровень, где обитают профессионалы).
Пообщавшись с инженером, ситуация начала прояснятся. В течение рабочего дня очень часто полностью выбирается ширина канала, в работу вступает шейпер провайдера и начинает дропать пакеты. А т. к. RDP чувствителен к потере пакетов, сервер тупо разрывает соединение...
Ну, а, поскольку, объем передаваемой информации из года в год растет, проблема прогрессирует вслед за ним. Обрывы сессии на складе происходят чаще, т. к. раундтрип складских пакетов больше и их потери чаще.

Амбула.
Решил построить систему ограничения траффика на простых очередях(Simple Queue), т. к. деревья в данном случае, совершенно избыточны.
Что сделал.
Создал 2 правила в цепочке mange для маркировки RDP Трафика(ip address + port). Первое маркирует соединение, второе пакеты этого соединения.

Создал родительскую очередь(main) с типом PFIFO и размером 100 пакетов. Ограничение скорости 47500 Kbit(5% от ширины канала).

Для приоритезации RDP траффика.
Создал очередь потомка main (RDP) - Max. Limit 47500 Kbit, Limit At 0, Priority 1, Queue Type PCQ, размер очереди 100 пакетов. Общий размер 5000Kib.

Все остальное.
Создал очередь потомка main (ALL) - Max. Limit 47500Kibt, Limit At 4Mbit, Priority 2, Queue Type PCQ, размер очереди 50 пакетов. Общий размер 2500Kib.

Идея всего этого заключается в следующем. Пакеты не должны дропаться "моим" шейпером. Путь лучше будет задержка, чем потери. Для этого увеличил размер основной очереди и очереди RDP. На остальной трафик "пофиг". Выбирать трусы на ягодках можно и так...
Смущают следующие моменты, в следствие того, что я, таки не профессиональный сетевой инженер.

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

Далее пакет попадает в очередь RDP и если он правильно помечен, обрабатывается в ней по алгоритму PCQ с высшим приоритетом. Если очередь забита, пакет отбрасывается.

Если пометки нет. Пакет попадает в ALL и обрабатывается уже там.

Вопросы такие. Насколько правильно выбран тип очередей?
Насколько правильно выбраны размеры очередей?
Насколько адекватно все то, что я понаписали сделал?

[Chupaka]

Тип родительской очереди ни на что не влияет, от неё берутся только всякие max-limit.
Limit At - это скорость, ниже которой пакеты ни в какие очереди попадать не будут и будут пролетать насквозь, если позволяет физический интерфейс. Так что я бы для RDP выставил что-нибудь побольше, а на ALL поставил 0.
Когда достигнут Limit At, Priority показывает, как распределяется ресурс родительской очереди между дочерними очередями. Т.е. чем меньше цифра Priority, тем больше вероятность у дочерней очереди достигнуть своего Max Limit.

Настройки PCQ у вас какие? Classifier, вот это вот всё...

[AndrK189100]

Настройки PCQ просто скопировал из дефолта и увеличил размер очереди.

pcq.png

Меня смущает, что в родителе ничего не происходит, пакеты дропаются в потомках.
И такой момент. Limit-At не "жестко" занимает ширину канала? Ну, т. е. если трафика попадающего в правило нет, другой может его занять?

А так, ситуация с текущими настройками улучшилась кардинально. Сегодня на складе, со слов пользователей, соединение обрывалось на двух ПК. В одном случае 2 раза, во втором 1... Что в, принципе, можно списать на другие факторы). Правда, рабочий день не полноценный(праздники). Завтра будет понятно, помогло или нет.

[Chupaka]

Настройки PCQ просто скопировал из дефолта и увеличил размер очереди.

Т.е. в обе стороны (upload/download) одна и та же очередь, с Classifier: Dst Address? Если зачем-то да - то я бы для upload всё же сделал Src

Меня смущает, что в родителе ничего не происходит, пакеты дропаются в потомках.

А в родительские очереди трафик и не попадает. Они нужны лишь для "координации". Например, чтобы при достижении суммарного трафика в Max Limit родительской дочерние договаривались, чья очередь дропать пакеты

И такой момент. Limit-At не "жестко" занимает ширину канала? Ну, т. е. если трафика попадающего в правило нет, другой может его занять?

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

[AndrK189100]

в обе стороны (upload/download) одна и та же очередь

Для каждого правила две очереди. Различаются только Classifier. Dst - для download, Src - Для upload.
Очередь для правила обслуживающего RDP траффик - длина 100 пакетов, общий размер 5000 кибибайт.
Для остального траффика 50 пакетов, 2500 кибибайт.
Сделал так исходя из понимания(своего), что при увеличении размера очереди уменьшается потеря пакетов, но, растет задержка.
В маршрутизаторе оперативной памяти гиг. Можно и больше накрутить. Но, вроде бы, хватает. В rdp дропов нет.

Спасибо большое. Читал официальные мануалы, статьи, как наши, так и зарубежные. Но в них такие тонкие моменты не рассматриваются.
Теперь картинка сложилась, более-менее.

[AndrK189100]

Еще один вопрос появился.
В мануале написано, что приоритет работает только в дочерних очередях. Если у родителя есть, хотя бы один потомок, приоритет не работает.
Что будет в случае, когда есть общая родительская очередь с потомками у которых тоже есть дочерние очереди?
Например:

queues.jpg

Насколько понял из документации. Приоритет CHILD2 будет игнорироваться. Боротьба будет только между CHILD-1, CHILD 2-1 и CHILD 2-2,
У кого PRIORITY меньше, тот и победит...

[Chupaka]

Да, Priority работает только у дочерних очередей, у родительских он не несёт никакой смысловой нагрузки. Родители нужны только для того, чтобы настроить Max Limit для группы очередей.
Нет, Priority - это не строгий критерий. То, что Priority у кого-то меньше, не значит, что эта очередь будет выгребать весь трафик в первую очередь. Как я писал выше,

Когда достигнут Limit At, Priority показывает, как распределяется ресурс родительской очереди между дочерними очередями. Т.е. чем меньше цифра Priority, тем больше вероятность у дочерней очереди достигнуть своего Max Limit.

Меньше число Priority - больше пакетов этой очереди смогут "занять" часть полосы пропускания у родительской очереди, или типа того. Как помню, сотрудник MikroTik на официальном форуме описывал характер действия Priority именно как вероятностный.

[AndrK189100]

Еще раз спасибо!