По загрузке процессора тоже все верно, чем мельче пакеты — тем их больше… Тем выше нагрузка на камень… То что у вас получилось 55 мегабит — еще довольно неплохой результат. Ищите методы оптимизации, каждое лишнее правило в системе равняется дополнительной нагрузке.
Приветствую, вы не внимательно читали пост, там ясно написано, что без указания лимитов будут работать только ограничения pcq-rate — если таковые имеются. Все остальные фишки будут работать только при достижении Max-Limit в вашей Download очереди, который должен быть чуть меньше реальной скорости которую может выдать аплинк. Если скорость на канале нестабильная и сильно плавает — нужны будут дополнительные костыли которые решают проблему лишь частично. Так что как бы грустно не звучало — лимит ставить все же придется. Но если скорость стабильная, от канала мало потеряете, порядка 5-10%.
год назад для ROS это очень давно :) Сама система не отличается постоянством качества. Тем более новые линейки.
Но на сегодня можно сказать что шестая линейка только-только приблизилась к нормальной работоспособности.
Так же возможно параметр pcq-burst-threshold был сильно близко к pcq-rate что давало возможность торренту постоянно использовать burst.
Не совсем понял смысла вашего комментария. Вы пост читали? Если да, то что вы имеете ввиду?
В правилах есть параметр «passthrough» и по умолчанию он включен — если не указано иначе.
В моем посте все правила: passthrough=yes;
Данный параметр отвечает за возврат пакета в цепочку, после выполнения действия над ним, в данном случае действием было назначение packet-mark пакету который попал под критерии правила.
Отключение данного параметра исключает помеченный пакет из дальнейшей обработки в текущей цепочке, что является очень плохим тоном при создании какой либо конструкции и применяется только в самых крайних случаях. Так-как помимо назначения маркировки для шейпера впоследствии может потребоваться еще назначение маркировки роутинга, если пакет исключили из цепочки — данное действие станет невозможным.
Теперь объясните мне на реальной конструкции с примером, как данная функция вообще применима к обсуждаемой проблеме и как она поможет промаркировать трафик в одном направлении, прогнать через QueueTree который находится в конце postrouting, потом каким то чудом вернуть данный пакет из HTB-Interface в цепочку Forward, промаркировать в обратном направлении и снова пропустить через QueueTree.
ufm все правильно написал и в посте про это тоже неоднократно сказано. Так о чем речь?
Многое зависит от области применения, данный материал в основном предназначен для будущих субпровайдеров и администраторов корпоративных сетей средних размеров.
Простые очереди актуальны для домашнего использования и для небольших сетей. В сети субпровайдера с несколькими аплинками, простые очереди приводят к проблемам с производительностью, масштабированием в будущем и неполной выдаче скорости после 300-400 абонентов. Поэтому неважно какие у вас знания, важно какие цели вы преследуете. Поэтому, если в планах сеть с более чем в 200 потребителей, то не нужно ленится, вам все равно придется научится использовать QueueTree рано или поздно, т.к правильный подход все делать качественно и основательно с самого начала, а не переделывать реализацию одного и того же по несколько раз.
И данные умозаключения сделаны на основе большого опыта и практики. Разница между Simple Queue и Queue Tree в больших сетях очень существенна и по мнению тех людей кто перешел с простых очередей на дерево: «Как небо и земля».
Владельцы небольших сетей разницы даже не заметят, в их случае простые очереди и Queue Tree дадут одинаковый результат, просто с Queue Tree будет больше заморочек с настройкой.
Да, все верно говорите. Межабонентский трафик можно контролировать только в одном направлении. Либо входящий, либо исходящий, т.к. такой трафик будет попадать сразу под несколько правил. Промаркировать и прошейпить дважды в шестой версии увы не получится. И это камень в огород разработчиков ROS.
Нет не запутался, я уже как то привык к конфигам этой ОС и по большей части тут копипаст :)
Тем более когда что то придумываешь уже сразу знаешь что и как будет выглядеть
А не при таком раскладе в некоторых организациях могут сорваться сделки на 5 лямов и потом админа на че нить натянуть, за отсутствие отказоустоичивости.
Улавливайте основную мысль! Остальное все мелочи, любой параметр можно подкорректировать на любой системе и ничего, никуда не уйдет.
Нет, не выдает, можно пускать часть трафика через основной канал, в любом случае схема проверена и спокойно отработала 2 года без претензий со стороны провайдера.
Куда проще отловить «физика» красиво смотрится на выходе трафик с разными цепочками TTL и Id пакетов… а если еще снифануть, что провайдер не имеет права делать, то может увидеть 50 асек, 60 ящиков и еще всего вкусного. Так что лучше брать инет от другого провайдера, либо лепить vpn куда нить подальше :)
Извиняюсь за грубость, но вы видимо невнимательно читали пост. В посте явно сказано что адреса у провайдера динамические. И я думаю что многие специалисты согласятся со мной, что в большинстве случаев провайдеры выдают динамические адреса, причем не только адреса, но и маршруты средствами DHCP серверов, и как показывает практика, таких сетей значительно больше, просто потому, что если провайдер захочет изменить размеры подсетей, либо добавить еще пару маршрутов, не придется тревожить своих абонентов и заставлять вкалывать техническую поддержку.
Когда сеть упадет из за повисшего коммутатора и поменяются ip адреса, что будете делать? Поедете в другой конец города конфигурировать роутер? Ну или как вариант с серверным скриптом получите ip роутера и будете ручками набивать новый ip сервера? А если адреса будут меняться по 5 раз в день?
Задача данных скриптов полностью автоматизировать процесс и в случае внештатных ситуаций автоматически исправить свойства соединения без вашего внимания и участия.
Что касается третьего пункта, забудте о прокси, никакой банальной секурности в нем нет, и скорее всего вас не столько хакнут, сколько вас запалит провайдер и резко скажет вам досвидос.
Все зависит от провайдера, у нас по данной схеме работают три организации. Ежемесячный трафик одной организации приблизительно 30-80 гигабайт.
Понятно что это не подойдет тем, у кого лимиты на месяц.
У меня лично на домашней машине которой пользуюсь только я, ежемесячный входящий трафик от 350 гигабайт, а исходящий за счет торрентов около 1 тб.
Все будет зависеть от потребностей по передаче. Сколько мегабит планируете прокачивать через девайс?
Если железка слабая и нужно много прокачивать, начинайте изучать линукс.
Если железка будет мощной или поток небольшой, можно обойтись микротиком. Даже возможно на базе routerboard.
Что касается хардварных решений то были бы деньги а Cisco или ZyWall найдется. :)
В принципе про QoS на микротике уже довольно много сказано на просторах всея интернета.
Ссылка на сайт с данными статьями есть в моем профиле.
Писать обязательно буду. В голове крутятся пара идей. Так же будет вторая версия данного поста после окончательного тестирования.
Не могу адекватно ответить на ваш вопрос, обычный линукс еще нужно немного знать, наверно для тех кто хорошо шарит в линуксе скорее всего проще и быстрее.
А для тех кто не шарит, и особо не хочет учится новому, проще и быстрее будет на микротике.
У каждого способа реализации есть свои плюсы и минусы, минус микротика можно наблюдать выше в качестве построения заборов, грабель и костылей.
Тем более что микротик это не только x86, но и routerboard и хочешь, не хочешь, а железка лежит и ее надо как то настроить.
Да, я понимаю о чем вы, но к сожалению это действительно не решает поставленной задачи.
В теории конечно же все красиво и правильно при параметре pcq-rate=0, но на практике это выглядит приблизительно так:
Клиент 1 активно закачивает файл или торрент, и занимает всю полосу пропускания.
Клиент 2 пытается так же поставить на закачку что то тяжелое, тут возникает первая маленькая проблема, скорость разделения полосы путем удаления пакетов из очереди происходит не так быстро как хотелось бы, в итоге получаем небольшую потерю пакетов на втором клиенте которая проходит через 5-15 сек. А так же резкое увеличение времени пинга на первом клиенте. Частично эта проблема решаема с помощью Burst.
Далее канал начнет делится на двух пользователей, и если внимательно мониторить клиентов и очереди, можно увидеть нехорошую картину:
Для примера ширина канала 5 мегабит.
Первому пользователю, будет отведена скорость приблизительно 2,1-2,3 мегабита.
Второму пользователю, который только что подключился, будет выдано 2,7-2,9 мегабита.
Нечестно!
Данные скорости уравняются до честных пределов только через 5-10 минут! И это при довольно шустрой конфигурации.
В конфигурациях с 10 и более пользователями все выглядит еще более печально, особенно если к качкам добавить серферов и геймеров, последние первыми забьют тревогу при узком канале. Разработчики Router OS об этом прекрасно знают еще с версии 2.х но по прежнему ничего нового не могут, или не хотят делать. Но самое удивительное что правила с жестко заданными Max limit работают как часы, никаких висяков и провалов по скорости.
Я понимаю что мое решение не верх гениальности, т.к. с плюсами приходят и минусы в виде расточительного использования системных ресурсов, но альтернативного варианта, я к сожалению пока не нашел, или плохо искал :) На днях буду проверять RC7 возможно в этой версии будет что то более похожее на правильную реализацию pcq.
Но на сегодня можно сказать что шестая линейка только-только приблизилась к нормальной работоспособности.
Так же возможно параметр pcq-burst-threshold был сильно близко к pcq-rate что давало возможность торренту постоянно использовать burst.
В правилах есть параметр «passthrough» и по умолчанию он включен — если не указано иначе.
В моем посте все правила: passthrough=yes;
Данный параметр отвечает за возврат пакета в цепочку, после выполнения действия над ним, в данном случае действием было назначение packet-mark пакету который попал под критерии правила.
Отключение данного параметра исключает помеченный пакет из дальнейшей обработки в текущей цепочке, что является очень плохим тоном при создании какой либо конструкции и применяется только в самых крайних случаях. Так-как помимо назначения маркировки для шейпера впоследствии может потребоваться еще назначение маркировки роутинга, если пакет исключили из цепочки — данное действие станет невозможным.
Теперь объясните мне на реальной конструкции с примером, как данная функция вообще применима к обсуждаемой проблеме и как она поможет промаркировать трафик в одном направлении, прогнать через QueueTree который находится в конце postrouting, потом каким то чудом вернуть данный пакет из HTB-Interface в цепочку Forward, промаркировать в обратном направлении и снова пропустить через QueueTree.
ufm все правильно написал и в посте про это тоже неоднократно сказано. Так о чем речь?
Многое зависит от области применения, данный материал в основном предназначен для будущих субпровайдеров и администраторов корпоративных сетей средних размеров.
Простые очереди актуальны для домашнего использования и для небольших сетей. В сети субпровайдера с несколькими аплинками, простые очереди приводят к проблемам с производительностью, масштабированием в будущем и неполной выдаче скорости после 300-400 абонентов. Поэтому неважно какие у вас знания, важно какие цели вы преследуете. Поэтому, если в планах сеть с более чем в 200 потребителей, то не нужно ленится, вам все равно придется научится использовать QueueTree рано или поздно, т.к правильный подход все делать качественно и основательно с самого начала, а не переделывать реализацию одного и того же по несколько раз.
И данные умозаключения сделаны на основе большого опыта и практики. Разница между Simple Queue и Queue Tree в больших сетях очень существенна и по мнению тех людей кто перешел с простых очередей на дерево: «Как небо и земля».
Владельцы небольших сетей разницы даже не заметят, в их случае простые очереди и Queue Tree дадут одинаковый результат, просто с Queue Tree будет больше заморочек с настройкой.
2. В режиме роутинга с SRC-NAT
Тем более когда что то придумываешь уже сразу знаешь что и как будет выглядеть
Улавливайте основную мысль! Остальное все мелочи, любой параметр можно подкорректировать на любой системе и ничего, никуда не уйдет.
Куда проще отловить «физика» красиво смотрится на выходе трафик с разными цепочками TTL и Id пакетов… а если еще снифануть, что провайдер не имеет права делать, то может увидеть 50 асек, 60 ящиков и еще всего вкусного. Так что лучше брать инет от другого провайдера, либо лепить vpn куда нить подальше :)
Задача данных скриптов полностью автоматизировать процесс и в случае внештатных ситуаций автоматически исправить свойства соединения без вашего внимания и участия.
Что касается третьего пункта, забудте о прокси, никакой банальной секурности в нем нет, и скорее всего вас не столько хакнут, сколько вас запалит провайдер и резко скажет вам досвидос.
Понятно что это не подойдет тем, у кого лимиты на месяц.
У меня лично на домашней машине которой пользуюсь только я, ежемесячный входящий трафик от 350 гигабайт, а исходящий за счет торрентов около 1 тб.
Если железка слабая и нужно много прокачивать, начинайте изучать линукс.
Если железка будет мощной или поток небольшой, можно обойтись микротиком. Даже возможно на базе routerboard.
Что касается хардварных решений то были бы деньги а Cisco или ZyWall найдется. :)
Ссылка на сайт с данными статьями есть в моем профиле.
Писать обязательно буду. В голове крутятся пара идей. Так же будет вторая версия данного поста после окончательного тестирования.
А для тех кто не шарит, и особо не хочет учится новому, проще и быстрее будет на микротике.
У каждого способа реализации есть свои плюсы и минусы, минус микротика можно наблюдать выше в качестве построения заборов, грабель и костылей.
Тем более что микротик это не только x86, но и routerboard и хочешь, не хочешь, а железка лежит и ее надо как то настроить.
В теории конечно же все красиво и правильно при параметре pcq-rate=0, но на практике это выглядит приблизительно так:
Клиент 1 активно закачивает файл или торрент, и занимает всю полосу пропускания.
Клиент 2 пытается так же поставить на закачку что то тяжелое, тут возникает первая маленькая проблема, скорость разделения полосы путем удаления пакетов из очереди происходит не так быстро как хотелось бы, в итоге получаем небольшую потерю пакетов на втором клиенте которая проходит через 5-15 сек. А так же резкое увеличение времени пинга на первом клиенте. Частично эта проблема решаема с помощью Burst.
Далее канал начнет делится на двух пользователей, и если внимательно мониторить клиентов и очереди, можно увидеть нехорошую картину:
Для примера ширина канала 5 мегабит.
Первому пользователю, будет отведена скорость приблизительно 2,1-2,3 мегабита.
Второму пользователю, который только что подключился, будет выдано 2,7-2,9 мегабита.
Нечестно!
Данные скорости уравняются до честных пределов только через 5-10 минут! И это при довольно шустрой конфигурации.
В конфигурациях с 10 и более пользователями все выглядит еще более печально, особенно если к качкам добавить серферов и геймеров, последние первыми забьют тревогу при узком канале. Разработчики Router OS об этом прекрасно знают еще с версии 2.х но по прежнему ничего нового не могут, или не хотят делать. Но самое удивительное что правила с жестко заданными Max limit работают как часы, никаких висяков и провалов по скорости.
Я понимаю что мое решение не верх гениальности, т.к. с плюсами приходят и минусы в виде расточительного использования системных ресурсов, но альтернативного варианта, я к сожалению пока не нашел, или плохо искал :) На днях буду проверять RC7 возможно в этой версии будет что то более похожее на правильную реализацию pcq.