MikroTik QoS — развенчание мифов

Перед тем, как настраивать роутер (не важно — офисный аппаратный роутер за 50 долларов или программный роутер на базе сервера с двумя 4-х ядерными процессорами) — важно понимать, как пакеты двигаются по цепочкам (изучить в онлайн документации Диаграммы движения пакетов — Packet Flow Diagrams).
Невозможно должным образом управлять и поддерживать сложные конфигурации без понимания того — что, где, когда и почему происходит.

В случае бриджинга трафика (Layer 2 (MAC)) — роутинг представлен ввиде черного серого «ящика» Layer3,






в случае роутинга трафика (Layer 3 (IP)) — бриджинг представлен ввиде серого «ящика» bridging,


Сокращенная диаграмма:



Здесь и далее под QoS в MikroTik ROS — подразумевается шейпинг.
Shaping — «изменять форму».
Т.е. изменяем форму графиков загрузки интерфейсов — управляем пропускной способностью, устанавливая ограничения (limit) либо по типу трафика, либо по «юзерам» или «сервисам» (по их IP адресам, портам и прочим критериям).
В разных контекстах для различного оборудования или ПО такие понятия как QoS (качество обслуживания), шейпинг, полисинг, приоритезация — может иметь другой «оттенок смысла». Существует множество концепций, реализаций, алгоритмов.

Вся реализация управления пропускной способностью в RouterOS основана на иерархии — Hierarchical Token Bucket (HTB).



HTB позволяет вам создавать иерархические (древовидные) структуры очередей и определять отношения между ними.



RouterOS 5.x поддерживает 3 виртуальных HTBs (global-in, global-total, global-out) и еще один прямо перед каждым выходным интерфейсом:


Важно понимать, что через роутер проходит несколько потоков.
Здесь не имеется ввиду сессии TCP/UDP.
Например, в самом простом случае имеем один физический интерфейс роутера — Public,
и второй физический интерфейс — Local.
Итого — имеем два потока пакетов, проходящих через роутер — назовем условно Download и Upload потоки.
Для Download трафика входным интерфейсом будет Public, выходным интерфейсом будет Local.
И, наоборот, для Upload трафика входным интерфейсом будет Local, выходным интерфейсом будет Public.
При этом диаграмма движения пакетов и логика обработки потоков будет будет абсолютно одинаковой для обоих потоков.
Другими словами — для роутера не имеет значения роль интерфейса — т.е. разделение на Public и Local — условно.

Download поток


Upload поток


_______________________________________________________________________________

Существует заблуждение, что в ROS не работает шейпинг + NAT + PCQ тип очереди.
Таки работает замечательно.
Я гарантирую это.

Указывайте Global-out в качестве родителя дерева Queue Tree (а не физические выходные интерфейсы) — как для Upload, так и для Download трафика. Об этом сказано в документации.
Маркируйте пакеты, например в Mangle Forward — отдельно для Upload и Download трафика, и используйте на здоровье PCQ тип очереди, где указываются ограничения скорости. Этот план для нарезки скоростей юзерам — работает в любом случае — вне зависимости от наличия/отсутствия NAT, pppoe/l2tp/pptp, IpoE, Hotspot.

Simple Queue:
Не используйте Simple Queue в версиях ROS до 5-ой включительно, если у Вас большое к-во пользователей — сильно падает производительность.

Простые очереди идут по порядку — как правила фаервола.
Пакеты 999-ой очереди будут проверены на соответствие с каждой из 998-и предыдущих очередей.

Каждая простая очередь может стоять в 3 раздельных очередях:
One in Global-in (“direct” part)
One in Global-out (“reverse” part)
One in Global-total (“total” part)

Используйте Дерево очередей queue tree.



Когда пакеты проходят сквозь роутер, они проходят все 4 HTB дерева.

Когда пакеты приходят на роутер, они проходят только global-in и global-total HTB.

Когда пакеты уходят с роутера, они проходят только global-out, global-total и inerface HTB.

Если очередь имеет по крайней мере одного потомка – она является родительской очередью.

Все очереди-потомки (не имеет значения сколько уровней родителей они имеют), находятся на том же нижнем уровне HTB.

Потомки создают реальное потребление трафика, родители отвечают только за распределение трафика.

Потомки получат сначала предел трафика limit-at, а остальной трафик будет распределен родителями.

HTB имеет два предела cкорости:
— CIR (гарантированная скорость передачи данных) — (limit-at в RouterOS): при худшем сценарии поток получит это количество трафика, несмотря ни на что (при условии, что мы можем на самом деле отправить так много данных).

— MIR (максимальная скорость передачи данных) — (max-limit в RouterOS): при лучшем сценарии, скорость потока может быть повышена, если родительская очередь имеет запас полосы пропускания.

Первым делом HTB будет стараться удовлетворить каждого потомка скоростью limit-at — и только затем будет пытаться достичь max-limit.

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

MIR (родитель) ≥ CIR(потомок_1) +...+ CIR(потомок_N).

Максимальная скорость любого потомка должна меньше или равна максимальной скорости родителя.

MIR (родитель) ≥ MIR(потомок_1)
MIR (родитель) ≥ MIR(потомок_2)
MIR (родитель) ≥ MIR(потомок_N)

Приоритет работает только для потомков (нет смысла менять приоритет у родителей)
1 – высший приоритет
8 – низший приоритет

Очередь с более высоким приоритетом получает возможность получить максимальную скорость (max-limit) раньше очередей с более низким приоритетом.

Фактическая приоритезация трафика будет работать, только если заданы лимиты. Очередь без лимитов не будет “приоритезироваться”.

Burst:
Функция QoS «Burst» является одним из лучших способов улучшить качество веб-сёрфинга для клиентов.

Burst позволяет обеспечивать более высокие скорости передачи данных на короткий период времени.

Если средняя скорость передачи данных меньше чем Burst порог (burst-threshold), burst может быть использован (фактическая скорость передачи данных может достигать лимита burst-limit).

Средняя скорость передачи данных рассчитывается от последних burst-time секунд.

Средняя скорость передачи данных вычисляется следующим образом:

— burst-time делится на 16 отрезков;

— роутер рассчитывает среднюю скорость передачи данных каждого класса на этих маленьких отрезках;

Обратите внимание, что фактический отрезок времени burst — это не тоже самое что burst-time. Он может быть в несколько раз меньше, чем burst-time, в зависимости от max-limit, burst-limit, burst-threshold и фактической истории скорости передачи данных.





Использовать Burst имеет смысл либо только дома или в маленьком офисе. Либо у относительно небольшого провайдера с «маленькими» тарифами — например 256k, 512k, 1024k. Т.к. тарифы от 2 мегабит и выше уже в любом случае достаточно комфортны для веб серфинга — поэтому эффект от бёрст будет малозаметен.
При большом количестве юзеров и современных тарифах использовать burst может быть нецелесообразно с точки зрения производительности программного роутера (но решать Вам).

Размер очереди:
Размер очереди оказывает непосредственное влияние на производительность очереди — это выбор между потерей пакетов и увеличением латентности (задержки).

В RoutesOS размер очереди является общим для одного типа очереди (т.е. очередей одного типа может быть много — но размер очереди будет одинаковый — и поэтому задается в Queue Types).

Разрушение легенд:
Вот как всё на самом деле РАБОТАЕТ:

‣ HTB приоритезация не меняет последовательность пакетов — не переставляет одни пакеты раньше других;

‣ В HTB — приоритезация является инструментом, который помогает решить — какие пакеты будут проходить дальше, а какие будут отброшены.

‣ Решение дропать пакет основывается на лимитах — таким образом, если пределы скоростей не установлены, то приоритеты не имеют никакого эффекта.

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

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

‣ На диаграмме движения пакетов видно, что HTB global-in находится после входного интерфейса, где регистрируется к-во пришедшего на роутер трафика.

‣ При этом эффект снижения трафика, скорее всего, является эффектом поведения протокола TCP.

‣ Единственный способ увидеть QoS в действии является мониторинг передачи данных (TX) противоположного интерфейса.

Другими словами — Вы никак не можете повлиять с помощью своего QoS на тот реальный входящий трафик, что уже фактически пришел на любой из интерфейсов роутера – ведь ни ваши юзеры, ни “мир” — ничего не знают про ваш QoS.
!!! Но это не значит – что QoS не работает.
Вы же можете манипулировать трафиком всех потоков (как Download так и Upload) внутри роутера — решая — как, сколько и какой трафик уйдет с роутера (пройдет сквозь роутер далее).

‣ QoS не может знать, какова фактическая пропускная способность доступна.

‣ Драйвер выходного интерфейса является первым, кто может знать, какую пропускную способность вы фактически имеете. Но в диаграмме движения пакетов видно, что выходной интерфейс находится уже после всех HTB.

‣ Драйвер интерфейса знает лишь максимальное аппаратное ограничение интерфейса, но если фактическое ограничение меньше — единственный способ обеспечить алгоритм QoS информацией о реальной пропускной способности — указать вручную явно все пределы.
(Причем некоторые администраторы сети рекомендуют указать 80-90% от максимальной суммарной пропускной способности канала — чтобы гарантировать создание очереди у себя, т.е. создать запас пропускной способности, а иначе «лишний» трафик зря дропнется у вашего вышестоящего провайдера, который тоже режет скорость вам — согласно купленных билетов оплаченной полосы.
Конечно — речь идет о гарантированном канале со стороны вышестоящего провайдера, либо негарантированном, но стабильном — по факту — большую часть суток.

Я лично не практикую это, т.к. выполняю следующее правило — «вовремя расширять внешний канал с небольшим запасом фактической утилизации в ЧНН». Благо — нет технических/экономических ограничений (но не у всех такая же ситуация).

Много споров о том, возможен ли двойной QoS (Double QoS) в Mikrotik Router OS.

Ответ — возможен.

Под двойным QoS подразумевается — одновременно шейпить по типу трафика (например, поджать суммарный p2p и дать приоритет web трафику в часы наивысшей нагрузки (ЧНН), и при этом нарезать скорость отдельно каждому юзеру (по тарифу).

Например вот так:
1. шейпинг по типу трафика:
— маркировка трафика в мангл прероутинг — шейпинг в глобал-ин

2. нарезка полосы по юзерам:
— маркировка трафика в мангл форвард — шейпинг в глобал-аут

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

Я не практикую шейпинг по типу трафика — по следующим причинам:
— нет проблем с расширением канала
— не имею право решать за пользователей — какой тип трафика хуже или лучше другого (например — с какого перепугу я имею право торренты подрезать)
— количество пользователей, а значит сервисов, протоколов и типов трафика столько много — что постоянно следить за этим не представляется возможным.
— именно из-за большого количества юзеров (тысячи их) — идентификация трафика по его типам — займет очень много ресурсов программного роутера. Эту работу должна делать специализированная железка операторского уровня (такие штуки, например, ставят операторы сотовой связи — тобишь ОПСОСы — иначе вы убъете торрентами весьма ограниченный частотный ресурс)

Я просто нарезаю клиентам скорости по тарифам и забываю про существования серверов/роутеров/коммутаторов на очень долго.

Важное замечание — когда мы говорим о шейпинге по типу трафика — то речь идет о суммарном трафике всего роутера, а не о приоритезации по типу трафика внутри полосы каждого пользователя. Хотя это тоже возможно — но требует огромной вычеслительной мощности (будет очень много прафил Firewall для каждого юзера), и если речь идет о сотнях/тысячах пользователей, то не следует этого делать — это работа для аппаратных железок, которые стоят порядка сотни тысяч долларов.

Если речь идет о доме или маленьком офисе — тогда это вполне реально сделать, чтобы ваш брат, качая торренты, не ухудшал себе веб серфинг, и совсем никак не мешал сестре и маме. Для этого папа должен настроить QoS и сжечь пароль от роутера. А если старший брат скинул роутер в дефолтные настройки — чтобы обнулить/сменить пароль — то он получает п***ей лишается карманных денег и получает домашний арест на неделю и должен прочитать и перерассказать роман «Война и мир».

Еще одно важное замечание — некоторые вещи, сказанные выше — относятся только для версий MikroTik ROS 4 и 5.
6-ая версия имеет существенные отличия. Например — там полностью переработаны Simple Queue и изменена диаграмма движения пакетов.

Об этом в переводе презентации:
Что нового в 6-ой версии MikroTik RouterOS

Очень подробно с примерами разных тарифов про настройку шейпера можно найти в моей статье на xgu.ru:
xgu.ru/wiki/Биллинг_Ideco_АСР_%2B_MikroTik_ROS.

Вся эта информация и даже более и плюс картинки можно найти в моих переводах официальных презентаций там:
wiki.mikrotik.com/wiki/Russian/QoS
и
wiki.mikrotik.com/wiki/Russian/QoS2011

P.S. Итог:
!!! QoS работает.

Просто надо понимать как и для каких задач использовать механизмы управления трафиком и уметь это «готовить»
(иметь мозг).
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 36

    0
    Еще бы для большей наглядности привели свой стандартный пример! И Хотелось бы увидеть отличия в ROS 6-й версии!
      +1
      Про важные отличия в 6-ой версии напишу чуть позже.
      (а они действительно важные — ребята из микротик корпорейшн переколбасили все чуть более, чем наполовину).
      Т.е. конфиг от 5-ой версии тупо может не заработать на 6-ой.

      Мои конкретные примеры есть подробно по ссылке на xgu.ru в конце статьи (вплоть до консольных команд)
        +1
        >Про важные отличия в 6-ой версии напишу чуть позже

        Очень бы хотелось почитать, надеюсь не пропущу!
        0
        не «может не заработать» а «не заработает»
        в 6ой версии они вкорне изменили систему очередей на одном даже не самом мощном роутере можно создать тысячи очередей.
        включая новый поток данных: New Packet flow diagram
        также убраны глабальные паренты global-in/out/total
        В очереди стало обязательным указывать «Target» сеть/адрес.
        Также стала возможна двойная маркировка и шейпинг пакетов на одном девайсе.
        Тоесть грубо говоря сделано так что в интерфейсе Queue кроме вкладки Simple Queue больше ничего не нужно, и то сами разрабы говорят что это название просто осталось с прошлого. Конечно в определенных случаях Queue Tree/HTB использовать выгоднее нежели Simple queue интерфейс. хотя я этот вопрос за не надобностью подробно не расматривал. в симпл кваях принимаются теже пакет марки, и указываются теже квай типы (аля PCQ)
          0
          Также стала возможна двойная маркировка и шейпинг пакетов на одном девайсе.

          это возможно и в пятой версии.
          не «может не заработать» а «не заработает»

          Как раз если использовать QueueTree — то достаточно в конфиге поментять global-out на global — и конфиг работает в 6-ой версии «на ура».
          Конечно в определенных случаях Queue Tree/HTB использовать выгоднее нежели Simple queue интерфейс. хотя я этот вопрос за не надобностью подробно не расматривал

          Я как раз использую только Queue Tree — мне так «выгодней» — это тысячи юзеров и с десяток тарифов.
          Хотя таки да — на 6-ой версии можно или даже нужно сделать на simple queue (они действительно сильно переработали «простые очереди» и оставили от них название чисто в исторических целях)

            0
            Ошибся термином не двояная маркировка, а возможность Double QoS появилась первый раз именно в 6ой версии.

            Ну если углубится то любой конфиг в котором поменялось только одно А на Б, можно заменить строчку на правильную и все будет работать. Только это уже не значит что «все будет работать из коробки». Особенно когда новички не обратят на это нужного внимания, ломая голову над тем почему ихний экспорт не импортится.

            Я сам юзаю Queue Tree — так как мне это тоже «выгодно» и нет смысла менять схему даже после перехода на RoS v6

            Кстати буквально час назад вышел релиз RoS v6.2. Так что поспешим получать очередную порцию глюков, особенно на линейке ССRов.
              0
              Ошибся термином не двояная маркировка, а возможность Double QoS появилась первый раз именно в 6ой версии.

              Я настаиваю, что дабл кос возможен и на пятой версии.
              wiki.mikrotik.com/images/8/8d/QoS_Megis_(Russian_translate_by_white_crow_rev.2).pdf
              5-я страница «Двойной Qos» (Double QoS)
                0
                Я не буду спорить. может у вас конфигурация другая которая позволяет делать даблкос и на пятой версии.
                этот документ «от мегиса» я за 4 года наизучить зазубрил. )
                но до 6ой версии на мой системе делать дабл кос было не возможно.
                так как пакет маркировался на аутпуте и где я его должен был ловить еще раз?
                а сейчас после того как они оставили только один парент GLOBAL это стало возможным.
                и не просто так сам суппорт микротика поднял тему что в 6ой версии стал возможен дабл кос. с обсуждением целесообразности существования вкладки «квай три»
                  0
                  Я не буду спорить. может у вас конфигурация другая которая позволяет делать даблкос и на пятой версии.
                  этот документ «от мегиса» я за 4 года наизучить зазубрил. )
                  но до 6ой версии на мой системе делать дабл кос было не возможно.
                  так как пакет маркировался на аутпуте и где я его должен был ловить еще раз?

                  если вы прочитали эту презентацию мегиса — то там написаны варинаты двойного кос на 5-ой версии,
                  Например вот так:
                  1. шейпинг по типу трафика:
                  — маркировка трафика в мангл прероутинг — шейпинг в глобал-ин
                  2. нарезка полосы по юзерам:
                  — маркировка трафика в мангл форвард — шейпинг в глобал-аут
                  и не просто так сам суппорт микротика поднял тему что в 6ой версии стал возможен дабл кос. с обсуждением целесообразности существования вкладки «квай три»

                  Если бы почитали внимательно форум микротика — то заметили бы, что это юзеры подняли вой, что дабл кос в 6-ой версии «поломали» и все там сцали кипятком.
                  Потому что убрали все глобал ин/аут/тотал и оставили только один глобал.
                  и потом, вроде с версии 6RC4 (release candidate) запилили такую возможность и в 6ой версии
                  Thanks to your feedback in v6.0RC3 we will have some changes in QoS features.
                  We made simple queues completely independent from «Global» queue tree. Now simple queues will happen after «Global» queue tree:

                  вот пруф
                  forum.mikrotik.com/viewtopic.php?f=1&t=67037
                  там normis как бы всем намекает — как делать дабл кос в 6-ой версии
                  So there is no more need to remember who will get traffic first — simple queues or queues in «Global» queue tree. Now traffic can be captured by both separately and independently. This also give you possibility to implement Double QoS AGAIN.
                  1) mark traffic by type in mangle, and apply limitations by traffic type in «Global» queue tree
                  2) use dynamic simple queues from ppp servers or RADIUS or create simple queues manually and use PCQ for limiting traffic per user, «target» and «dst» options should allow us to make per-user-limitation without any problems

                  Жирным выделенное — смысл такой — что Вы снова, друзья мои, можете делать дабл кос )

                  такие вот дела, ребята
                    0
                    Убедительно.
                    Я не буду вдаваться в подробности своей схемы которая не позволяла осуществить ни единой схемы дабл коса.
                    На самом деле даже сейчас я не могу осуществить его из за одного юнита сети. Но если бы не он, в отличии от прошлой версии я с удовольствием воспользовался бы возможностями 6ой версии.
                      0
                      Я понимаю, что прошло два года. Но вдруг.
                      Столкнулся я с интересной засадой (а так как Вы упоминаете что у вас куча абонентов через микротик ходили в тот момент — я думаю вы должны были с этим столкнуться и как-то порешать).
                      Засада такая:
                      Если два абонента сидящие на одном устройстве решили обмениваться данными между собой, то получается, что трафик ходит только через одну очередь. Что в simple queue, что в queue tree. И решить эту проблему можно только используя одновременно оба типа очередей (например гонять исходящий траффик через simple queue, а входящий через queue tree), что, как по мне, как-то дико.
                      Как вы подобную засаду решали?
        • UFO just landed and posted this here
            0
            Не знаю, что там геморройного. Все весьма логично.
            Пользуюсь им уже лет 7, первый месяц ушел на понимание азов, а потом пошло поехало.
              0
              Чистый линукс — это, конечно, хорошо, но иногда мне удобно не писюки или серверы использовать, а «железные» роутеры — от маленьких коробочек на маленьком офисе или дома, до больших коробок на крупной конторе. Там ROS вшит жёстко.
              • UFO just landed and posted this here
                  0
                  это бессмысленный спор.
                  В любом случае — на любой системе нужно разбираться. А когда уже разобрался — то уже быстро настроишь в следующий раз.
                  Еще зависит — что начал первым изучать — потому что мозг привыкает к одной концепции и синтаксису, а потом ему тяжело и лень переучиваться.
                  Я настрою шейпинг на Тике за пару движений мышки.
                  На цыске первый раз тоже было сложно — пришлось попотеть, чтобы вьехать — но когда уже понял — все гибко и логично.
                  Потом еще пришлось на zyxel нарезать скорость по разным критериям — вообще мозг поломался — синтаксис ни на что не похожий.
                  Потом тоже привык — и сейчас кажется тоже все легко и логично.
                  так что можно этот спор не продолжать.
              0
              Это спорный вопрос.
              Я настрою с нуля за 10 минут шейпер для десяти тарифов.
              Но тут самое главное правило — играй музыку на том инструменте, на котором умеешь.
              Или когда речь идет о выборе дистрибутива и связанных с этим жутких холиваров:
              Вопрос новичка:
              — Какой дистрибутив Linux мне выбрать для реализации программного роутера:
              Ответ опытных админов:
              — Тот, который знаешь (если не знаешь никакой — пробуй разные — что понравится — то и «готовь»)
                0
                Совсем-совсем опытный админ еще посоветует учесть, как долго ты собираешься работать там, где ты настраиваешь этот роутер, кто потенциально будет работать после тебя или лучше так — кого сможет найти эта контора, исходя из реалий местности и времени вместо тебя, если ты уйдешь. И если подставить людей ты не хочешь, то может лучше потрудиться и изучить что-то более стандартное или легко обслуживаемое, чем то, что ты волею судеб уже умеешь «готовить». Или наоборот, что-то потяжеловесней, но не потому, что просто оно круче, а потому что потом проживет дольше и меньше создаст людям проблем вида — и кто теперь во всем этом после него разберется?!
                  0
                  изучить что-то более стандартное

                  Стандартное — это что? Windows? )
                  Фрибзд?
                  Какой-то из сотен дистрибутивов линукс?
                  Цыска? (какая из тысячи продуктов разных поколений?)
                  Прочие производители сетевого железа?

                  Мы живем в реальном мире — который очень разнообразен, а не черно-белый.
                  Так что для каждого понятие «стандарт» — своё.

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

                  Так что думать о том — кто будет после тебя (не зная заранее в чем шарит «будущий одмин» — это напрасное гадание на кофейной гуще.)
                  И вообще — утопия это — никто не думает — что будет после тебя — каждый делает что умеет и знает.
                    0
                    Вы щас с каким теэзисом спорите, не понял.

                    Ваше утверждение — делай на чем умеешь.
                    Мое утверждение — подумай, прежде чем так делать.

                    Если не понятно — вот вам пример.
                    Я могу сделать, допустим, на фре или слаке. Тонко, надежно, используя годами наработанный материал (скрипты, какие-то связки опенсорсного софта, возможно даже свои патчи). Но пораскинув мозгами я понимаю, что после меня с этим никто или почти никто не разберется. Поэтому я вздыхаю, покупаю микротик и начинаю с ним разбираться именно потому что сообщество и прочая-прочая. Или, взглянув повнимательней на фирму и ее задачи я им говорю — ребята, вот вам керио на рабочую станцию и уймитесь уже.
                      0
                      С вашим тезисом «подумай, прежде чем так делать» — нет смысла спорить.
                      Было бы отлично, если бы так все и делали — мы бы жили в идеальной мире, где не падают шатлы и ракеты…
                      Но в реальной жизни… все «немножко» не так.
                      Ваш пример — когда одмин хорошо знает (на 8 из 10 баллов) — и слаку, и фряху и венду с керио, и цыску — и понимает для каких ниш подходит каждый инструмент — это исключение из правил (сферический одмин в вакууме).
                      В реальности, дай бох — чтобы одмин имел реальный качественный боевой опыт хотя бы одной системы.
                      Если новый админ приходит на работу — ему придется разобраться в неизвестной ему текущей системе, подружиться с бывшим одмином, взять его контакты — и некоторое время не стесняться спрашивать у него.
                      Либо… искать другую работу…

                      P.S.
                      Я ни в коем случае не рекламирую продукцию компании микротик.
                      Я не имею никакого профита от продаж продукции микротик (как и от продаж любых других товаров и услуг).
                      Я осознаю тот факт — что продукция микротик — далеко не идеальна и имеет недостатки.

                +1
                статью немного перепилил, добавил пару несмешных шуток, немного изменил некоторые формулировки, добавил картинок.
                  +2
                  mark_pezdez_down/up на скриншоте это пять :)
                    0
                    да. я тоже так щитаю )))))))
                      0
                      Burst, говорите, не нужная штука на каналах шире 2 мегабит?
                      Берем p2p трафик. По-умолчанию у пользователя будут большие задержки на работу других типов трафика т.к. суммарно пакетов p2p будет больше. Поэтому burst тут очень и очень полезен.
                      Я так вообще сделал PCQ очереди на юзеров чтобы p2p трафик считался одним (ну или несколькими, но не так много как без PCQ) потоками. Тогда балансировка трафика для юзера становится гораздо более комфортной для него же (юзера).

                      Раздел с мифами не понятен. Вы имеете в виду, что это именно мифы? А то в начале было написано — миф — на самом деле нет и объяснение. А здесь такого нет.
                        0
                        По-поводу burst — каждый админ сам решает — нужно или не нужно использовать эту фишку.
                        Если у меня тарифы 10, 20, 50 и даже 100 метров — я решаю, что не нужно.
                        В рамках своей полосы каждый пользователь сам решает — чем и как ее утилизировать.

                        По-поводу мифов — сейчас подправлю формулировку, чтобы было ясно — что все те тезисы — это утверждение — КАК именно РАБОТАЕТ.
                        Т.е. — там уже не мифы, а развенчание мифов )
                          +1
                          Админ не должен это решать. Это должны решать требования пользователей к каналу.
                          У меня было три пользователя на 4 мегабита и всем были нужны торренты. Но все хотели нормальный браузинг.
                          Поэтому работал (да и сейчас на 100 мегабитном канале работает) буст + PCQ + балансировка канала (а не жесткий шейпинг).

                          И даже когда ты 1 работаешь, то это ОЧЕНЬ неприятно, когда торрент не дает нормально работать остальным сервисам.
                          Зачем вообще об этом париться на локальных машинах если можно все сделать на маршрутизаторе?
                          Я вообще сейчас дома использую микротик для своего компьютера, компьютера брата, + планшета + телефонов.
                          И если бы не буст + приоритезация сервисов — даже мои 100 мегабит оптического ethernet канала мне не очень-то помогали.
                            0
                            Совершенно верно — дома, в офисе и в небольшой сетке — да, оправданно юзать бёрст,
                            В домашней сети с тысячами людей или на каком-нибудь заводе/большом предприятии — это под большим вопросом.
                            (качаешь торренты на работе и у тебя некомфортный браузинг? — нефиг качать торренты на работе) (скорее всего админ завода просто заблочит торрент-трекеры, зарежет к-во одновременных сессий на одного юзера)
                            Вот тебе тариф — юзай свою полосу как хочешь.
                            Хочешь — сам ставь дома домашний роутер и сам делай себе бёрст и/или приоритезацию. (что вы и сделали)
                            Другое дело — аппаратные шейперы операторского уровня, но это совсем другая история.
                            Кстати, у кого из хабраюзеров — есть провайдер, который сделал бёрст фишку для вас на своем оборудовании?

                        +1
                        white_crow, сделайте пожалуйста превью статьи поменьше, а то из-за картинок очень много места занимает. Спасибо.
                          0
                          понял, сейчас откорректирую.
                          0
                          Я что-то не понимаю, или все же правильно будет написать что это QoS линуксового ядра? Чем это ROS от линукса отличается?
                            0
                            Совершенно верно — под капотом Mikrotik ROS — Linux.
                            Но есть много реализаций и алгоритмов «шейпинга».
                            И важно как все «обёрнуто», как названы сущности и как настраивать.
                            Вот вам доказательство, что просто Linux и Микротик ROS — не одно и тоже ).
                            Один из постов выше:

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


                            такие дела )
                              0
                              Как сейчас обстоят дела с большими каналами 25-50-100мбит? Работали с 4 и ранней 5-той версией в симплах при большом количестве правилах наблюдались жесткие задержки ( HP DL140 g3 и порядка 300-400 абонтов в основном с пакетами в 50Мбит ) на деревьях же не могли получить стабильной отдачи она почему-то не поднималась выше 10-15Мбит, в результате перешли на фряху, но не хватает возможностей простого мониторинга к которому быстро привыкаешь с микротиками. Возможно где-то наши косяки с настройками были? Хотя на каналах до 10Мбит все правила работали на ура…
                                0
                                Режит ровно любые скорости в 5.x (QueueTree+PCQ)
                                Но фряха, при грамотном тюнинге, на том же железе прожует гораздо больше pps.
                                (и юзать рациональные алгоритмы)

                                Ибо маркировка трафика и шейпинг — отжирает львиную долю производительности в Микротик.
                                Пока 6-ую версию не тестил на серьезных нагрузках — сыровата она — надо подождать стабилизации.

                                Only users with full accounts can post comments. Log in, please.