Как стать автором
Обновить

Комментарии 15

Начиная с шестерки в ros есть одна неприятная грабля:
Пакет проходит через фаервол только 1 раз.
Что это значит:
Допустим у нас роутер и две сети (192.168.3.0/24 и 192.168.4.0/24 например), которые общаются с внешним миром и друг с другом через микротик. Ограничение на вход/выход у первой сети — 10Мб/с, у второй — 5Мб/с. Идут пакеты с первой сети во вторую.
Отработает шейпер первой сети (т.е. вход будет ограничен до 10Мб/с), но шейпер воторой сети уже не отработает. Т.е. хоть у нас там и стоит ограничение на 5Мб/с все равно туда будет отправлятсья со скоростью 10Мб/с
Да, все верно говорите. Межабонентский трафик можно контролировать только в одном направлении. Либо входящий, либо исходящий, т.к. такой трафик будет попадать сразу под несколько правил. Промаркировать и прошейпить дважды в шестой версии увы не получится. И это камень в огород разработчиков ROS.
для этого и сделали «pass true» в фаерволе. поставьте галочку или passtrue= enable и будет отрабатывать не одно правило, а все что подходят под пакет.
Не совсем понял смысла вашего комментария. Вы пост читали? Если да, то что вы имеете ввиду?

В правилах есть параметр «passthrough» и по умолчанию он включен — если не указано иначе.

В моем посте все правила: passthrough=yes;
Данный параметр отвечает за возврат пакета в цепочку, после выполнения действия над ним, в данном случае действием было назначение packet-mark пакету который попал под критерии правила.

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

Теперь объясните мне на реальной конструкции с примером, как данная функция вообще применима к обсуждаемой проблеме и как она поможет промаркировать трафик в одном направлении, прогнать через QueueTree который находится в конце postrouting, потом каким то чудом вернуть данный пакет из HTB-Interface в цепочку Forward, промаркировать в обратном направлении и снова пропустить через QueueTree.

ufm все правильно написал и в посте про это тоже неоднократно сказано. Так о чем речь?
Хороший плюс за разжевывание в начале статьи по трафику.
PS для тех кто имеет начальное знание микротиков и хочет ограничить скорость — пожалуйста не пользуйтесь этим мануалом. Делай простые очереди с родителем и потомками. Не нужно делать никаких маркировок
Спасибо, но немного уточню некоторые моменты.

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

Простые очереди актуальны для домашнего использования и для небольших сетей. В сети субпровайдера с несколькими аплинками, простые очереди приводят к проблемам с производительностью, масштабированием в будущем и неполной выдаче скорости после 300-400 абонентов. Поэтому неважно какие у вас знания, важно какие цели вы преследуете. Поэтому, если в планах сеть с более чем в 200 потребителей, то не нужно ленится, вам все равно придется научится использовать QueueTree рано или поздно, т.к правильный подход все делать качественно и основательно с самого начала, а не переделывать реализацию одного и того же по несколько раз.

И данные умозаключения сделаны на основе большого опыта и практики. Разница между Simple Queue и Queue Tree в больших сетях очень существенна и по мнению тех людей кто перешел с простых очередей на дерево: «Как небо и земля».
Владельцы небольших сетей разницы даже не заметят, в их случае простые очереди и Queue Tree дадут одинаковый результат, просто с Queue Tree будет больше заморочек с настройкой.
Монументально, спасибо! Много стало ясно для меня, займусь делами на своем домашнем роутуре.
год назад пробовал настроить Burst с целью компфортного серфинга — в итоге поимел проблем с торрентами. Как оказалось — уторрент жимкает канал на всю ширину. Победить не смог, сделал простые очереди с родителями.
год назад для ROS это очень давно :) Сама система не отличается постоянством качества. Тем более новые линейки.
Но на сегодня можно сказать что шестая линейка только-только приблизилась к нормальной работоспособности.
Так же возможно параметр pcq-burst-threshold был сильно близко к pcq-rate что давало возможность торренту постоянно использовать burst.
Вот тоже пытаюсь победить torrent в Queue Tree, кажется, все сделал правильно, а результат не тот.
Собственно чего хотел добиться: на домашний интернет раскидать трафик по типу, каждому задав приоритет.
Для теста сделал так: весь входящий (по ip назначения) трафик в forward маркирую как download, затем из всего трафика с меткой download выделяю Web трафик (порты источника 80,443).
Дерево построил тоже простое, родитель download (у него родитель global), с двумя потомками Web и Default.
Проверяю закачку (попадание трафика в соответствующие очереди), все хорошо, и Web и Default прекрасно разбегаются по местам. Использую очереди pcq, которые уже есть по умолчанию. Далее, ставлю приоритет у Web трафика повыше (7), и начинаю качать и Web и torrent. И torrent отбирает всю полосу почти без остатка. А ставить жесткий лимит не хочется, хочу иметь возможность полного использования канала…
Вдумчивое тестирование показало следующие: на малых лимитах (10Мбит), все работает как задумывалось, но как только ставлю скорость в максимум (у моего тарифа 60Мбит), начинается непонятка. Индикатор загрузки CPU (графический), не показывал нагрузки совсем. Вот именно он и привел к «проблеме». Если открыть панель системных ресурсов, то там нагрузка на CPU почти 100% (при работе torrent). В итоге, как я понял, при достижении придела по CPU, часть функционала очередей перестает работать (в угоду сохранности данных). Таким образом, на RouterBOARD 952Ui-5ac2nD, максимальная скорость при использовании очередей, находится в районе 55Мбит (надо еще поэкспериментировать).
По загрузке процессора тоже все верно, чем мельче пакеты — тем их больше… Тем выше нагрузка на камень… То что у вас получилось 55 мегабит — еще довольно неплохой результат. Ищите методы оптимизации, каждое лишнее правило в системе равняется дополнительной нагрузке.
Приветствую, вы не внимательно читали пост, там ясно написано, что без указания лимитов будут работать только ограничения pcq-rate — если таковые имеются. Все остальные фишки будут работать только при достижении Max-Limit в вашей Download очереди, который должен быть чуть меньше реальной скорости которую может выдать аплинк. Если скорость на канале нестабильная и сильно плавает — нужны будут дополнительные костыли которые решают проблему лишь частично. Так что как бы грустно не звучало — лимит ставить все же придется. Но если скорость стабильная, от канала мало потеряете, порядка 5-10%.
Это я проверил первым делом. Без всяких ограничений нагрузил канал (torrent и параллельные закачки), получил скорость в 59-61Мбит. Выставил лимит у канала в 58Мбит. И система даже частично не работает. Очередь с torrent отнимает всю полосу (средняя не привышает установленный лимит родительской очереди). Но, когда лимит стоит ниже (57Мбит оказался рабочим), тогда приоритет отрабатывает корректно (при этом, CPU нагружен на 92-97%). Если проц перегружен, то приоритеты перестают работать.
Вопрос по параметру Bucket Size
Я использую pcq-очереди для ограничения трафика. Установлен Rate 3M bits/s, параметры Limit At, Max Limit, Burst — не установлены. Если исходить из формулы:
bucket-capacity = bucket-size * max-limit
то получается, что при не установленном параметре Max Limit (подразумеваю, равен 0) — установка размера «ведра» Bucket-size ни на что не влияет.
Я правильно понимаю?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории