Два провайдера: отказоустойчивость и распределение нагрузки

[podarok66]

Понял уже, прости, затупил
А галки Add defaul route снимать надо?

[Barvinok]

Естественно.

[Barvinok]

Настройка роутера с нуля.
Этим разделом восполню скудность прикладной части.
Согласно названию темы я настраиваю роутер именно на двух провайдеров. Модель роутера я подразумеваю RB7xx series.
Источники:
Обзор и настройка Mikrotik RB751U-2HnD в режиме беспроводного роутера с подключением к сети Интернет.
Сергей Лаговский: MikroTik - Начальная настройка

Источники читать обязательно. Я не будут писать руководство "Микротик для домохозяек", типа "возьмите кабель в правую руку...". Здесь я обозначу лишь вехи, ступени. А как именно это делать - в вышеозначенных источниках.
Я пользуюсь командной строкой терминала через Winbox и все примеры буду приводить именно в таком виде.
1. Сбрасываем начальные настройки:

Код: Выделить всё

/system reset-configuration

2. Скачиваем Upgrade package и мышкой перетаскиваем в Winbox.
Либо даём распоряжение:

Код: Выделить всё

/system package update upgrade

Далее:

Код: Выделить всё

/system reboot

и после перезагрузки

Код: Выделить всё

/system routerboard upgrade

3. Создаю мост из последних трёх портов:

Код: Выделить всё

/interface bridge
add name=Local_Net

/interface bridge port
add bridge=Local_Net interface=ether3
add bridge=Local_Net interface=ether4
add bridge=Local_Net interface=ether5

Либо создаю свитч:

Код: Выделить всё

/interface ethernet>
set ether4 master-port=ether3
set ether5 master-port=ether3

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

4. Назначаю этому мосту IP-адрес:

Код: Выделить всё

/ip address add address=192.168.1.1/24 interface=Local_Net

В случае со свичём адрес назначается мастер-порту.

5. Настраиваем на нём же DHCP-сервер:

/ip dhcp-server setup

В качестве DNS-сервера пусть выдаёт адрес самого Микротика: 192.168.1.1. Чуть позже поясню, почему так.

6. Разрешаем роутеру отвечать на запросы DNS:

Код: Выделить всё

/ip dns set allow-remote-requests=yes

Переведём дух: теперь мы добились коробочной функциональности D-Link :)

7. По совету Сергея Лаговского я всегда меняю имя суперпользователя:

Код: Выделить всё

/user add name=supername password=superpass group=full
/quit

Заходим под новым пользователем и отключаем старого:

Код: Выделить всё

/user disable admin

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

Код: Выделить всё

/system identity set name=new_name

8. Назначаем сервер времени и часовой пояс:

Код: Выделить всё

/system ntp client set enabled=yes mode=unicast primary-ntp=89.109.251.22 secondary-ntp=89.109.251.23
/system clock set time-zone-name=Europe/Moscow

9. Настраиваем интернет-подключения.
Я возьму сложный случай двух неравнозначных провайдеров:

• Первый провайдер даёт интернет через PPPoE по ADSL: 8Мбит входящий/0,8 Мбит исходящий. IP-адрес и прочие сетевые настройки выдаются провайдером динамически.
• Второй - очень качественный, но дорогой по оптике: симметричный канал 1 Мбит. IP-адрес и настройки статические (постоянные)

Значица нам нужно основной поток пользователей запустить через ADSL, а избранные сервисы реального времени (VoIP) - по оптике.

9.1. Настраиваем первого провайдера.
Переводим наш ADSL-модем в режим моста (Bridge). Втыкаем кабель в первый порт (ether1).
Создаём и настраиваем интерфейс PPPoE:

Код: Выделить всё

/interface pppoe-client add name=UTK user=ppp_user password=ppp_pasw use-peer-dns=yes interface=ether1

Если бы провайдер был единственный, можно было бы добавить "add-default-route=yes". Но у нас другая задача.
"use-peer-dns" означает, что мы будем использовать DNS-сервера, назначенные провайдером при этом подключении.

Код: Выделить всё

/ip address print
/ping mail.ru

что бы убедиться, что соединение работает.

9.2. Настраиваем второго провайдера.
Втыкаем кабель из конвертера среды во второй порт и вводим настройки вручную:

Код: Выделить всё

/ip address add address=80.45.21.34/30 interface=ether2

Если провайдер даёт свои DNS-сервера, можно их явно задать:

Код: Выделить всё

/ip dns set servers=ip_server1,ip_server2

А можем назначить любые общедоступные, вроде гугловских: 8.8.8.8,8.8.4.4.

Напомню, что благодаря п.6 наш маршрутизатор является DNS-сервером для локальной сети. Но сам он, как ласковое теля - двух маток сосёт, произвольно обращаясь к DNS-серверам любого провайдера.

10. Включаем трансляцию адресов.
Для провайдера 1:

Код: Выделить всё

/ip firewall nat add chain=srcnat action=masquerade out-interface=UTK

Можно так же поступить и для второго, но мы поэстетствуем. Поскольку адрес у нас постоянный, используем не masquerade, а SNAT:

Код: Выделить всё

/ip firewall nat add chain=srcnat action=src-nat protocol=tcp src-address=192.168.1.0/24 to-addresses=80.45.21.34 out-interface=ether2

Если бы наши провайдеры были равнозначны, то можно было бы сделать так:

Код: Выделить всё

/ip route add dst-address=0.0.0.0/0 gateway=UTK,ether2 check-gateway=ping

Мы сразу получаем отказоустойчивость и равномерное распределение нагрузки (равноценные пути). Советую для пробы так сделать и поиграться с компьютеров локалки в "tracert mail.ru", отключая то один, то другой внешний интерфейс - просто, что б проверить.
Если провайдеры не равны лишь толщиной канала, можно поступить так:

Код: Выделить всё

/ip route add dst-address=0.0.0.0/0 gateway=UTK,UTK,ether2 check-gateway=ping

Теперь через первого провайдера пойдёт вдвое больше потоков, чем через второго.

Но наша задача чуть сложнее, поскольку провайдеры не равны не только количественно, но и качественно.
11. Поэтому мы отдельно назначим им маршруты и дадим разные предпочтения (distance).
Для первого провайдера проще всего сделать так:

Код: Выделить всё

/interface pppoe-client set 0 add-default-route=yes

Хотя мы могли это сделать и в п.9.1, но я решил выделить для порядка.
Для второго провайдера - так:

Код: Выделить всё

/ip route add dst-address=0.0.0.0/0 gateway=80.45.21.34 distance=2 check-gateway=ping

Теперь вся наша сеть ходит через провайдера 1, а если он падает - через провайдера 2.

12. Выделим важные потоки (Skype, SIP), которые нужно отправлять в сеть через провайдера 2.

Здесь я сделаю отступление, посвящённое маркировке (отметке) пакетов и соединений, поскольку эта тема достаточно любопытна.

[Barvinok]

Отступление 4
Маркировка
Источники:
Manual:IP/Firewall/Mangle на Mikrotik Wiki.

Используется для установки меток для определенных пакетов. Это действие может выполняться только в пределах таблицы mangle. Установка меток обычно используется для нужд маршрутизации пакетов по различным маршрутам, для ограничения трафика и т.п.. За дополнительной информацией вы можете обратиться к Linux Advanced Routing and Traffic Control HOW-TO. Не забывайте, что "метка" пакета существует только в период времени пока пакет не покинул брандмауэр, т.е. метка не передается по сети. Если необходимо как-то пометить пакеты, чтобы использовать маркировку на другой машине, то можете попробовать манипулировать битами поля TOS.

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

Второе, что нужно понимать: при "маркировке пакетов" никаких изменений в самом пакете не производится! Пометка делается в журнале учёта нашего маршрутизатора и эта запись удаляется, как только пакет покидает пределы IPTables.
Единственные изменения в самом пакете, которые мы можем произвести в таблице mangle - изменить поля TOS и TTL в заголовке.

Рассмотрим два правила из статьи о PCC:

Код: Выделить всё

add action=mark-connection chain=prerouting dst-address-type=!local in-interface=ether2 new-connection-mark=l2tp-out1_conn passthrough=yes per-connection-classifier=src-address:2/0 src-address=172.16.0.0/16
add action=mark-connection chain=prerouting dst-address-type=!local in-interface=ether2 new-connection-mark=l2tp-out2_conn passthrough=yes per-connection-classifier=src-address:2/1 src-address=172.16.0.0/16

add action=mark-routing chain=prerouting connection-mark=l2tp-out1_conn in-interface=ether2 new-routing-mark=to_l2tp-out1 passthrough=yes
add action=mark-routing chain=prerouting connection-mark=l2tp-out2_conn in-interface=ether2 new-routing-mark=to_l2tp-out2 passthrough=yes

В первом правиле мы указываем какое действие в какой цепочке мы будем производить (action=mark-connection chain=prerouting). Далее следуют признаки, по которым мы определяем соединение, должное быть помеченным: вид адреса назначения - любой, кроме адреса самого маршрутизатора (dst-address-type=!local), входящий интерфейс - ether2 (in-interface=ether2), адрес источника - любой компьютер из подсети 172.16.0.0/16. Далее следует чудная команда: per-connection-classifier=src-address:2/0. Так мы разбиваем поток пакетов, соответствующих этим признакам, надвое.
После чего - собственно действие: одной части потока назначаем метку l2tp-out1_conn, а второй l2tp-out2_conn.
Passthrough переводится как "насквозь". Вообще-то каждый пакет последовательно проверяется на соответствие каждому правилу до первого совпадения. Как только совпало - он тут же передаётся в следующую таблицу (в данном случае - DNAT) или уничтожается, если действие DROP. Но если указано passthrough=yes, пакет передаётся следующему по списку правилу в этой же таблице.

Следующим правилом мы ставим отметку о предпочтительном пути дальнейшего следования (action=mark-routing). Все соединения, отмеченные l2tp-out1_conn (connection-mark) мы вдобавок клеймим меткой to_l2tp-out1 (new-routing-mark). А потом и со второй половиной потока поступаем соответственно.

В чем глубинный смысл этого последовательного клеймения и почему нельзя сразу ставить new-routing-mark, я пока что не понял. Но в официальном руководстве на Микротик Wiki делается так же.
Может кто-то объяснит?

Вообще, существует три действия со сходным названием, в которых не мешало бы разобраться:

• mark-connection
• mark-packet
• mark-routing

Начнём с простого.

mark-routing - place a mark specified by the new-routing-mark parameter on a packet. This kind of marks is used for policy routing purposes only

Это действие ставит метку, которая используется исключительно при выборе пути дальнейшей пересылки. К примеру:

Код: Выделить всё

/ ip route
add dst-address=0.0.0.0/0 gateway=10.111.0.1 routing-mark=to_ISP1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.112.0.1 routing-mark=to_ISP2 check-gateway=ping

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

Код: Выделить всё

add dst-address=0.0.0.0/0 gateway=10.111.0.1 distance=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.112.0.1 distance=2 check-gateway=ping

А вот чем отличаются mark-packet от mark-connection?
Очевидно, тем же, чем отличается пакет от соединения.
Читаем:

Marking each packet is quite resource expensive especially if rule has to match against many parameters from IP header or address list containing hundreds of entries

Клеймить каждый пакет очень дорогое удовольствие, особенно, если правило содержит много признаков для сравнения из заголовка IP-пакета или адресного листа, содержащего сотни записей.
Дальше говорится о непосильном труде маршрутизаторов, обременённых сложными правилами проверки каждого пакета в 100-мегабитных сетях. Вычислительная нагрузка на процессор стремительно растёт, что, по сути, приводит к невозможности использования этого способа маркировки при управлении большими потоками данных.

Fortunately if connection tracking is enabled, we can use connection marks to optimize our setup.

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

Код: Выделить всё

/ip firewall mangle
  add chain=forward protocol=tcp port=!80 dst-address-list=first connection-state=new action=mark-connection \ 
new-connection-mark=first
  add chain=forward connection-mark=first action=mark-packet new-packet-mark=first passthrough=no

  add chain=forward protocol=udp dst-address-list=second connection-state=new action=mark-connection \ 
new-connection-mark=second
  add chain=forward connection-mark=second action=mark-packet new-packet-mark=second passthrough=no

Now first rule will try to match data from IP header only from first packet of new connection and add connection mark. Next rule will no longer check IP header for each packet, it will just compare connection marks resulting in lower CPU consumption. Additionally passthrough=no was added that helps to reduce CPU consumption even more.

Значица, первое правило проверяет данные лишь в заголовке первого пакета нового соединения, считая, что в пределах этого соединения все прочие будут с ним совпадать. Следующее правило, вместо того, что бы проверять заголовок каждого пакета смотрит только на метку соединения, что значительно снижает нагрузку на CPU. В добавок правило "passthrough=no" сразу прерывает прохождение пакетов по этой таблице переводя в следующую, что так же разгружает CPU!

Ооу... Хитрый приём! Теперь понятно, почему в примере с PCC мы сначала помечали соединение, а потом на основании этой метки ставили второю - о маршрутизации.
Но возникают вопросы.
Первый: а как можно понять, что пакет принадлежит тому или иному соединению не заглянув в его заголовок? Очевидно - никак. Значит каждый пакет в любом случае обрабатывается отдельно, но происходит это за пределами IPTables и это не вызывает особой нагрузки на центральный процессор, в отличии от обработки по списку правил внутри IPTables.

И второй вопрос: как можно пометить соединение?
Если с пакетом всё относительно понятно: у него есть заголовок, в который мы вносим изменения, то что является вещественным выражением понятия "соединение", с которым мы можем хоть как-то работать? Что мы помечаем?

[Barvinok]

Отступление 5
Механизм определения состояния (state machine)
Полезные ссылки:
State
Механизм определения состояний

Механизм определения состояния (state machine) является отдельной частью iptables и в действительности не должен бы так называться, поскольку фактически является механизмом трассировки соединений. Однако значительному количеству людей он известен именно как "механизм определения состояния" (state machine). В данной главе эти названия будут использоваться как синонимы. Трассировщик соединений создан для того, чтобы netfilter мог постоянно иметь информацию о состоянии каждого конкретного соединения. Наличие трассировщика позволяет создавать более надежные наборы правил по сравнению с брандмауэрами, которые не имеют поддержки такого механизма.
В пределах iptables, соединение может иметь одно из 4-х базовых состояний: NEW, ESTABLISHED, RELATED и INVALID.
...
Трассировка соединений производится в цепочке PREROUTING, исключая случаи, когда пакеты создаются локальными процессами на брандмауэре, в этом случае трассировка производится в цепочке OUTPUT. Это означает, что iptables производит все вычисления, связанные с определением состояния, в пределах этих цепочек. Когда локальный процесс на брандмауэре отправляет первый пакет из потока, то в цепочке OUTPUT ему присваивается состояние NEW, а когда возвращается пакет ответа, то состояние соединения в цепочке PREROUTING изменяется на ESTABLISHED, и так далее. Если же соединение устанавливается извне, то состояние NEW присваивается первому пакету из потока в цепочке PREROUTING. Таким образом, определение состояния пакетов производится в пределах цепочек PREROUTING и OUTPUT таблицы nat.

Здесь автор или переводчик допустили неточность: состояние NEW присваивается не пакету, а соединению, разумеется. А при прохождении ответного пакета состояние соединения меняется на ESTABLISHED (т.е. установлено) - всё верно.
Вторая неясность - что это за таблица NAT в цепочке OUTPUT. Там же есть только Mangle и Filter.

Но это не так уж важно.
Понятно главное: мы помечаем не само соединение (что невозможно), а делаем пометку в цепочке PREROUTING или OUTPUT, дескать пошёл первый пакет (SYN), значит создадим в нашей картотеке новое соединение за нумером энцать, определим его состояние как новое (NEW) и будем ждать ответного пакета (SYN/ACK).
Пришёл ответ? Значит нас слышат и соединение можно считать установленным (ESTABLISHED).
После прохождения нескольких пакетов через это соединение, к нему добавится флаг [ASSURED] (уверенное).

Переписывать здесь весь раздел руководства не буду, тем более что в целом картина ясна. Не так уж и страшен этот State Machine.

[Barvinok]

Отступление 6
Пометка голосового трафика.
Источники:
VoIP на wiki.mikrotik.com
UPnP на wiki.mikrotik.com
Traffic Priortization, RouterOS QoS Implemetation
NetworkPro on Quality of Service
Basic traffic shaping based on layer-7 protocols

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

Код: Выделить всё

/ip firewall mangle
add chain=forward src-address=a.a.a.0/24 action=mark-packet new-packet-mark=VoIP\
    passthrough=no comment="VoIP" disabled=no

add chain=forward dst-address=a.a.a.0/24 action=mark-packet new-packet-mark=VoIP\
    passthrough=no comment="VoIP" disabled=no

Это кое-как работает для SIP, но не для Skype.

Если вы не очень разбираетесь в файерволлах или портах, попросите системного администратора или технически грамотных друзей помочь вам. Как минимум для работы Skype нужны неограниченные исходящие подключения на все порты больше 1024 или порты 80 и 443 (первый вариант предпочтительней). Если вы не сделаете одно из этих действий Skype вообще может не заработать. Качество связи и другие аспекты работы Skype можно значительно улучшить если вы откроете также исходящие UDP соединения для портов больше 1024 и позволите UDP запросам возвращаться.

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

Случайный выбор портов улучшает пропускную способность NAT для случаев, когда несколько пользователей пользуются одним NAT; если все они будут использовать одни и те же порты, большинство NAT могут ухудшить качество связи Skype.

В скайпе нет предопределённых портов, на которые можно уверенно опереться.

Можно попробовать использовать TOS (DSCP):

Код: Выделить всё

/ip firewall mangle
add chain=forward tos=xxx action=mark-packet new-packet-mark=VoIP passthrough=no \
    comment="voip tos xxx" disabled=no

Но кто знает, какой TOS указывает Skype во всех своих разнообразных соединениях? Надо разбираться...

Можно использовать седьмой уровень - но это для отчаянных. Я пока тщу себя надеждой. Но чую, что путь мой лежит в поля качества обслуживания и очередей...

[Barvinok]

Отступление 7
Качество обслуживание и дерево очередей
Источники:
DSCP based QoS with HTB
Семинар QoS Лучшая практика
Задание уровней качества связи
Руководства:Очередь (Queue)
Руководство по iptables. Критерий TOS.

Земную жизнь пройдя до половины,
Я очутился в сумрачном лесу,
Утратив правый путь во тьме долины

Каков он был, о, как произнесу,
Тот дикий лес, дремучий и грозящий,
Чей давний ужас в памяти несу!

Так горек он, что смерть едва ль не слаще.
Но, благо в нем обретши навсегда,
Скажу про все, что видел в этой чаще...

Hierarchical Token Bucket
Вся реализация управления пропускной способностью в
RouterOS основана на иерархии - Hierarchical Token Bucket
(HTB)
HTB позволяет вам создавать иерархические структуры
очередей и определять отношения между очередями
RouterOS поддерживает 3 виртуальных HTB (global-in,
global-total, global-out) и еще один прямо перед каждым
выходным интерфейсом.

Вам всё понятно? Нет? Тогда обратимся к статье Александра Кузьмицкого Задание уровней качества связи.

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

Золотые слова! Очевидно, сейчас это досадное упущение будет исправлено и начинающие системные администраторы смогут насладиться русскоязычной документацией!

Для начала рассмотрим несколько понятий, которыми мы будем пользоваться в дальнейшем.
Технология, которая позволяет ограничивать скорость и качество доступа в Интернет, называется шейпинг (от англ. Shape - форма). Образно говоря - это технология придания некой формы графику загрузки канала.

Вот так, переведя с английского на латынь, Александр посчитал что документация стала доступной для русскоязычных пользователей.
Вообще-то, латинское слово forma, наиболее точно переводится на русский как "вид". И если уж мы говорим образно, то - чего стесняться! - вид мы придаём не графику, а самому каналу.

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

Алгоритм - это последовательность действий.
Ничего не понимаю. Шейпер, судя по названию, является средством изменения вида канала. Единственное, как я могу себе это представить: делая канал то шире то уже, мы управляем проходящим через него потоком.
А описывается, как средство переупорядочивания пакетов внутри потока и даже отбрасывания их на манер фильтра! Неожиданно...

Существует ещё один тип алгоритмов, используемых для управления движением пакетов внутри шейпера Schedulers. Их задача состоит только в формировании очередей согласно приоритетам пакетов, адресу источника, получателя и другим параметрам. К этому типу алгоритмов относятся PFIFO, BFIFO,SFQ, PCQ, RED.

Не понял, в чём разница в сравнении с предыдущим алгоритмом. Снова мы выстраиваем пакеты в очереди по определённым признакам. К тому же снова упомянут PCQ, который вроде бы принадлежит к совершенно другому "типу".

Под-очередь - очередь, сформированная из пакетов по тому или иному признаку.
Queuing discipline (qdisc - дисциплина очереди) - алгоритм, который захватывает пакеты и точно определяет в каком порядке и каким образом они будут двигаться.

Только мне кажется, что Александр четыре раза сказал одно и то же? К слову сказать, "дисциплина" - есть "совокупность твердо установленных правил". Что сильно смахивает на "алгоритм". Но так же "Строгое и безусловное чинопочитание во всей армии, повиновение старшему, соблюдение всех правил службы". Так-так! Вырисовываются уровни подчинения, т.е. та самая "иерархия", с которой мы начали!
ИЕРАРХИЯ (греч. hierarchia, от hieros - священный, и archo - управляю). 1. Чиноначалие, преемственность старшинства. 2. Порядок подчинения низших элементов (чинов, должностей, званий, явлений и т.п.) высшим.
По русски это называется строй или устроение. Если вдаваться в языковые подробности, то мы имеем чин (корень таких слов, как почин, починок, зачин (зачатие), начинание (начало)), который распадается на две противоположности: муж-чина и жен-чина.
Так появляется троица из которой всё и строится ;). Значит, любое устроение подразумевает некие уровни преемственности (наследования) и подчинения.

HTB
В основе шейпинга, используемого в Mikrotik, лежит дисциплина очереди HTB, реализованная во многих Linux-системах. Ее изучение является достаточно сложной, однако необходимой задачей для новичка, потому как без этих знаний дальше неудачных попыток и копирования правил из документации мало кто заходит.
Список основных возможностей по управлению трафиком в Mikrotik выглядит следующим образом:
ограничение скорости по IP-адресам, подсетям, протоколам, портам, времени суток и другим параметрам;
ограничение P2P-трафика (BitTorrent, eMule);приоритизация одних потоков пакетов над другими;
использование пиковых скоростей для быстрого WEB-браузинга;
разделение канала между пользователями поровну или в других пропорциях;
возможность задания гарантированной скорости.

Это больше, чем я хотел узнать. Но раз уж влез - придётся идти до конца.

Ключевым понятием для HTB является класс. Приставка Hierarhical в аббревиатуре HTB означает, что дисциплина позволяет строить иерархию классов.

Что такое иерархия мы разобрались. "Класс" происходит от лат. classis - порядок.
Для пущей путаницы Александр предлагает называть классы "правилами".
Короче, HTB - есть многоуровневый набор правил управления... чем? Очевидно, потоками данных. И делает это с помощью "token bucket". Что является устойчивым выражением и часто переводится как "Алгоритм текущего ведра".

Алгоритм текущего (или дырявого) ведра называется так по аналогии с протекающим ведром. Скорость втекания жидкости в ведро определяет согласованную скорость передачи, а скорость вытекания — реальную среднюю скорость передачи. Если дырка в ведре настолько большая, что вся жидкость, втекающая в ведро, сразу из него вытекает, скорость вытекания не может быть больше скорости втекания. То есть реальная средняя скорость передачи никогда не превысит заданной согласованной скорости.

Задача алгоритма — принять решение: передать пакет или отбросить. Параметрами алгоритма являются скорость поступления маркеров в «ведро» (бит/c) и объём «ведра» или «вёдер» (если в алгоритме используется два «ведра»). Один маркер может соответствовать одному биту передаваемой информации. Скорость поступления маркеров определяет среднюю согласованную скорость передачи информации (CIR — commited information rate). Данная скорость гарантируется при передаче информации. Объём «ведра» определяет согласованную величину всплеска (committed burst size (CBS) или exceed burst size (EBS), если в алгоритме используется два «ведра»).

Друзья! Просто два дырявых ведра. Вот и всё, что представляет из себя великий и ужасный Hierarchical Token Bucket!
Разберёмся на примере:

Рассмотрим пример с устройством, на котором работает алгоритм текущего ведра. Пусть размер «ведра» равен 10 кбайт, а согласованная скорость равна 3 кбайт/c. Допустим, что в момент времени t1 «ведро» содержит 3500 маркеров. Пришедший в этот же момент времени пакет размером 1500 байт будет отправлен с исходящего интерфейса, поскольку его размер меньше числа маркеров в «ведре» (1500<3500). При этом из ведра удалится 1500 маркеров и останется — 2000 маркеров. В момент времени t2=t1+100 мс в «ведро» добавится 300 маркеров (3000 м/с * 0,1 с = 300 м) и на входящий интерфейс поступит новый пакет (1500 байт). Данный пакет также будет передан с исходящего интерфейса, так как 1500<2000+300. Ещё через 100 мс (t3) в «ведре» будет 2300—1500+300=1100 маркеров. Пришедший в данный момент пакет будет отброшен (1500>1100). Все пакеты, которые поступят на устройство между t3 и t4=t3+400 мс, тоже будут отброшены, поскольку в «ведре» в течение этого промежутка будет недостаточно маркеров для их передачи. Если усреднить число переданных пакетов по времени, то мы получим среднюю согласованную скорость CIR=3 кбайта/c. Если пакетов не было длительное время («ведро» успело наполниться), то допускается передача всплеска, то есть пачки пакетов. Размер всплеска определяется количеством маркеров в «ведре». Максимальный размер всплеска определяется объёмом «ведра». Однако средняя скорость передачи не превышает CIR. Пакеты не удовлетворяющие согласованной скорости могут не отбрасываться, а буферизироваться. То есть перед алгоритмом трафик ставится в очередь и на вход алгоритма пакеты будут поступать из начала очереди.

Компьютерную науку без всякой натяжки можно назвать тайноведением. Не в том смысле, что из неё делают тайну, а в том смысле, что повествует о вещах не явленных, скрытых. О тонких образах, которые правят явленным миром.
И самое главное здесь - прозреть этот истинный исходный образ сквозь муть непонятных слов и знаков.
Если образ удалось увидеть верно - мы сможем точно предугадывать что произойдёт в том или ином случае и управлять этими случаями.
Не зря сисадминов называют шаманами, а неизменным атрибутом их является бубен (кудес).
Помните анекдот, как у компьютерщика спрашивают:
- За что тебе платить 50 баксов - ты всего лишь одну кнопку нажал!
- Доллар за то, что нажал, а 49 за то, что знал, что нажимать!

Есть другой - про колдуна.
Сидит мужик на дереве пилит сук, на котором сидит.
Мимо проходит другой и говорит:
- Мужик, ты чего делаешь - ведь свалишься щас!
- Иди, иди. Не мешай!
Через минуту естественно, обрушается вместе с суком.
- Ууу, колдун!

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

Сначала я думал, что речь идёт о задачке, навроде бассейна, где в одну трубу втекает - в другую вытекает.
Но это не так. Точнее, этот образ хорош для понимания планировщиков очередей (Schedulers), которые "предшествуют шейперу и представляет ему уже подготовленные очереди пакетов, к которым следует применять ограничения".
Но сам шейпер (он же HTB) - совсем другое...
Шейпер не работает с пакетами! Вот это открытие.
Шейпер отмеряет меру каждой очереди. А чем он отмеряет - жетонами в ведре, зерном на чаше весов или песком в песочных часах - совершенно не важно. Это лишь выражение понятия "мера". Но каждый маркер, каждая песчинка или зёрнышко имеет соответствие тому, что отмеряет: количество наших сил, время жизни или биты данных.
Мы всегда знаем, что "вот на это дело сил у нас хватить, а прежде чем браться за другое - нужно передохнуть, набраться сил".
Значит, отдыхая, мы копим силу, которая течёт к нам постоянно тонкой струйкой. Накопив её побольше мы становимся способны на Большие Дела! Но мера от этого не меняется: совершив подвиг нам снова нужно отдыхать и набираться сил.

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

Подобрать точный образ из жизни - вот что самое главное.
Раз уж мы начали с образа дорог и перекрёстков, почему бы не продолжить.
На перекрёстках, как мы договорились, стоят пересылки (наши маршрутизаторы).
Но теперь к их внутреннему устройству (рис.1) добавим службу, отвечающую за управление потоком.
Управление - это всегда создание препятствия, помехи. Вдумайтесь сами: вот мы врезаем вентиль в водопроводную трубу. Разве может вентиль усилить напор? Самое большее, что он может - не мешать, как будто его нет!
Или катаясь на санках мы, тормозим то одно то другой ногой что бы повернуть - так управляем!

Значит задача по управлению трафиком сводится к созданию препятствий для некоторых маловажных потоков (P2P), что бы расчистить канал более важным (VoIP).

В этом случае, наиболее точным образом будет контрольно-пропускной пункт со шлагбаумом. Ну или обычное почтовое отделение, куда вы пришли отправлять бандероль.
А там, естественно, очередь. Знакомо?
Так вот: это называется "FIFO".
FIFO (First In, First Out) — «первым пришёл — первым ушёл».
Акроним! - не хрен собачий!

Единственный параметр, используемый для конфигурирования данного алгоритма, - это pfifo-limit (bfifo-limit). Он указывает на количество байт, которые могут храниться в выходном буфере. Не попавшие в буфер пакеты будут разрушаться.

Представьте себя руководителем почтамта.
Задача руководителя - наладить предприятие так, что бы с наименьшими временными и трудозатратами обслуживать потоки клиентов, удовлетворяя все их обращения.
В частности, вы определяете, какой длины может быть очередь.
Но так же вам дана власть определять, каких клиентов обслужить сперва, а какие могут ещё перетоптаться.
В зависимости от своих соображений, вы выбираете алгоритм планировщика очереди: FIFO, SFQ, PCQ или RED.
Напомню, что "HTB позволяет вам создавать иерархические структуры очередей и определять отношения между очередями".
Иерархическое - значит, многоуровневое устройство очередей, что подразумевает очереди, которые объединяются в большие очереди, которые объединяются в ещё большие очереди и так далее.
Изначально у нас всего один входящий поток - тот который приходит в цепочку Prerouting нашей IPTables.
Далее с помощью Mangle мы по некоторым признакам метим (окрашиваем) - и тем самым выделяем этого потока - несколько струй.
Обращу внимание: пока что с самими пакетами или соединениями нечего не делалось! Мы просто создали заметку в некоем поле таблицы о том, что вот этому потоку (если действие mark-connection) или пакету (в случае mark-packet) присвоено такое-то имя. Так что это разделение лишь на уровне осознавания: теперь мы видим не один поток, а несколько струй, его составляющих.
Которые, в свою очередь, состоят из разноцветных пакетиков.

А вот дальше мы можем пустить их по разным руслам. И здесь уже судьба каждого пакетика может разительно отличаться: избранные пойдут вперёд всех, а остальные будут уничтожены за неимением места в очереди.
А может, напротив - всех уравняют в правах.
К примеру, вы можете отправить поток в очередь PCQ.

PCQ (Per Connection Queuing) является частным случаем SFQ за тем исключением, что формирование потоков в под-очереди будет происходить в соответствии с неким правилом. Это может быть адрес источника/получателя и порт источника/получателя. Таким образом можно равномерно распределить скорость между участниками вне зависимости от количества открытых подключений.

Тут ведь какое дело. Если мы с помощью Mark уже разделил потоки по признакам адреса отправителя/получателя, то смысла в PCQ нет и можно использовать SFQ. Но если мы грубо выделили весь входящий трафик лишь для того, что бы отправить его в очередь (никак иначе ведь этого не сделать) - то можно деление на потоки по адресу источника/получателя и порту источника/получателя отдать на откуп PCQ.
Пройдя через чистилище очередей пакеты заново выстраиваются в один поток перед вратами к Вёдрам Судьбы (HTB).

[Barvinok]

Отступление 7 (Продолжение)
Качество обслуживание и дерево очередей: Hierarchical Token Bucket.
Источники:
Руководства:HTB
Итак мы имеем исходный образ в виде пирамиды вёдер, которые заполняются марками (жетонами, токенами) начиная с верхнего. Видели, как в бане бывает делают пирамиду из шаек? В верхнюю льётся вода из крана, а потом через края вода начинает стекать и заполнять нижние. Нашем случае вода перетекает не через края, а через крантики в доньях.

Кроме того, мы имеем два описания работы это образа:
одно общее в виде статьи в Википедии, второе - как описание воплощения этих механизмов в RouterOS.
Поехали!

Алгоритм маркерной корзины (англ. Token Bucket Algorithm) — алгоритм, позволяющий ограничить полосу пропускания канала и в то же время гарантировать некоторую скорость передачи данных (кадров или пакетов). Поскольку скорость передачи пакета по каналу всегда равна скорости передачи битового потока по среде передачи (или скорости модуляции), то для ограничения, или другими словами, уменьшения средней скорости передачи нужно увеличить временные интервалы между пакетами. Ограничение скорости достигается отбрасыванием некоторых пакетов, передача которых ведёт к превышению согласованной скорости.

Мы не можем управлять скоростью потока. Мы можем лишь отбрасывать, уничтожать пакеты, которые не в силах обработать (т.е. переслать получателю). И мы можем спокойно и без опаски это делать, поскольку опираемся на механизм работы TCP:

Protocols such as TCP/IP have a back-off mechanism - when lost packets are not acknowledged by the receiver - the sender starts sending less data. From the point of view of Internet Applications and protocols, packet loss is considered normal and informative.

Протоколы, такие как TCP / IP имеют механизм избыточной надёжности - в случае потери пакетов или не признания их получателем, отправитель начинает посылать меньше данных. С точки зрения интернет-приложений и протоколов, потери пакетов считается обычным делом и вполне ожидаемы.

Но отбрасываются лишь те пакеты, которым не нашлось места в очереди. А очередь выстраивается к HTB - нашим Вёдрам Судьбы.
Почему я их так назвал? Дело в том, что они подобны Мойрам древнегреческой мифологии: одна прядёт нить человеческой жизни, вторая отмеряет её длину, третья перерезает её по отметке.
Но эта нить - лишь мера жизни, а не сама жизнь.
Точно так же, потоки марок, текущие в наших вёдрах - не есть поток пакетов с данными. Но каждая марка соответствует и является мерой некоему биту данных этого потока.
В примере с почтамтом - это марки, которые наклеиваются на каждый отправляемый пакет. Нет марок - ничего не отправляется: ведь письмо без марки не отправишь, верно? Так мы можем управлять потоком пакетов опосредованно - через поток подаваемых марок.

Особенность вёдер (в отличие от потоков) заключается в их способности накапливать марки, когда пакеты для пересылки отсутствуют или их поток меньше потока марок. Благодаря этому возможны всплески: быстрая прокачка большого объёма трафика. Но размер этого всплеска определяется объёмом ведра с марками. Закончился запас марок в ведре - скорость передачи пакетов становится равна скорости поступления марок.
Но возможен случай с двумя вёдрами: при иссушении первого мы начинаем черпать марки из второго, жёлтого ведра. И лишь когда марки закончатся и там, некоторые пакеты перестанут помещаться в очередь и начнут уничтожаться.
В RouterOS мы можем задавать объёмы вёдер и размеры дырок, через которые перетекают потоки марок.
Но описываются эти обыденные и привычные нам понятия достаточно неочевидным способом. С чем я и постараюсь сейчас разобраться.

Алгоритм текущего (или дырявого) ведра называется так по аналогии с протекающим ведром. Скорость втекания жидкости в ведро определяет согласованную скорость передачи, а скорость вытекания — реальную среднюю скорость передачи. Если дырка в ведре настолько большая, что вся жидкость, втекающая в ведро, сразу из него вытекает, скорость вытекания не может быть больше скорости втекания. То есть реальная средняя скорость передачи никогда не превысит заданной согласованной скорости.

Скорость втекания марок в зелёное ведро, она же "заданная согласованная скорость" определяется ключём limit-at.
Объём же нашего ведра описывается через среднюю скорость за некий отрезок времени:

burst-limit - скорость, которая будет доступна сразу при подключении;
burst-threshold – средняя скорость за последние burst-time секунд;
burst-time - время для подсчета burst-threshold.
Момент, когда клиенту или классу нужно выдать максимальную скорость, определяется следующим образом. Раз в 1/16 времени burst-time вычисляется загрузка канала на указанное число секунд. Если средняя загрузка составила менее burst-threshold, то клиенту или классу выделяется указанная в burst-limit скорость до тех пор, пока она не превысит burst-threshold

Это ещё нужно понять.
Зададим burst-time=20 секунд.
Предположим, очередь, подключенная к нашему ведру, какое-то время (равное и превышающее burst-time) простаивала: мы просто читали какой-то сайт и ничего в это время не подгружали. Значит, действительная средняя скорость за эти 20 секунд составит 0 кб/с.
Допустимая средняя скорость (burst-threshold) у нас равна 100 кбит/с.
А предел всплеска (что соответствует сечению крана, через который вытекают марки из нашего ведра) укажем 500 кбит/с.
Значение burst-limit всегда нужно делать значительно больше, чем сечение крана на входящем в ведро потоке (limit-at): иначе никакого всплеска не получится и вся наша пирамида из вёдер теряет смысл!
Так вот. Мы кликаем по некой ссылке отправляя запрос на получение следующей страницы на некий сервер. И, поскольку сервер стоит на магистральном канале в дата-центре провайдера, он нам отдаёт эту страницу с огромной скоростью (пусть 10Мбит/с).
А сама страница при этом весит 2000 кбит (я сразу привёл размер в битах, а не в байтах, что бы не путаться в размерностях).
Страница помещается в очередь на маршрутизаторе и передаётся нам за 4 секунды со скоростью 500 кбит/сек.
При этом средняя скорость за 20 секунд составит (500+500+500+500+0+0+0+....+0)/20=100кбит/с
Как раз наша пороговая (средняя допустимая) скорость! Как вы уже поняли - 2000 кбит и есть объём нашего ведра.
Но что произойдёт, если страница весит 3000 кбит?
В случае с одни ведром первые 2000 кбит мы так же получим быстро - со скоростью 500кбит/с. Потом скорость упадёт до значения ключа limit-at и пакеты будут тянуться к нам со скоростью поступления марок в ведро (100кбит/с).
И так до тех пор, пока средняя загрузка канала не станет меньше burst-threshold, а значит марки начнут накапливаться в ведре и всплеск снова станет возможным.

RFC 2697 (single rate three color marker) описывает механизм односкоростного трёхцветного маркера. Задача маркера — «покрасить» трафик (пакеты) в три цвета: зелёный, жёлтый и красный. А что делать с этими пакетами разного цвета определяет администратор, управляющий устройством. Зелёные пакеты — это те, для которых хватает маркеров из первого «ведра». Жёлтые — для которых не хватает маркеров из первого «ведра», но хватает из второго. Красные — для которых не хватает маркеров ни из первого, ни из второго «вёдер». Например, зелёные пакеты могут передаваться без изменений, жёлтые — с пониженным приоритетом, красные — отбрасываться.

Класс может находиться в одном из трех состояний:
Зеленый - пропускная способность правила не превышает параметр limit-at. В этом случае пакеты не двигаются вверх по иерархии, а перемещаются сразу в выходной поток своего уровня согласно приоритетам.
Желтый - пропускная способность правила больше limit-at, но меньше max-limit. В этом случае класс отключается от выходного потока своего уровня и подключается к родительскому классу.
Красный - пропускная способность правила больше max-limit. В этом состоянии класс отключается от родительского и подключается к локальной очереди.

Мы можем подключить нашу очередь через второй крантик напрямую к жёлтой трубе одновременно продолжая получать их через зелёную (тут у Александра некоторое расхождение с описанием из Википедии, к которому я склоняюсь). Совокупная скорость двух потоков определяется ключём max-limit.

HTB_small.png

Так же нужно очень отчётливо понимать, что очередь не ограничивает трафик. Самое большее - очередь вида SFQ, PCQ или RED меняет последовательность пакетов, подаваемых к нашим вёдрам с марками (HTB). Второе назначение очереди - буферизация. Т.е. очередь имеет некое пространство (объём), где пакеты могут дожидаться билетика (марку) на отправку. Короче, очередь - такая очередь...

Теперь про HTB. Марки беспристрастно сыпятся ровным потоком. Если они не используются полностью, то могут накапливаться в вёдре. Но если пакетов много, то марок на всех нехватает. Поэтому мы выбираем такой вид очереди и так её настраиваем, что бы сначала к вёдрам подавались наиболее важные пакеты (DNS, ICMP, HTTP requests), если таковых нет, то идут следующие по важности (Online game, VoIP) и т.д. по нисходящей. В конце - наименее важные (FTP, P2P). И если на них марок не хватит - они в лучшем случае будут помещены в буфер очереди, а в худшем (если буфер уже полон) - будут уничтожены.
Что будет подсовываться первее определяется ключём "priority=1...8" (1-наибольшая важность, 8-наименьшая).

Очередей шесть видов: bfifo, mq-pfifo, pcq, pfifo, red, sfq. Но так же

Начиная с v5.8, появился новый тип none и новый тип очереди по умолчанию only-hardware-queue. У всех RouterBOARD данный новый тип очереди будет установлен в качестве умолчательной очереди интерфейса

Что выбрать - вы решаете сами в зависимости от задачи.

Такие ключи как, limit-at, max-limit, burst-limit, burst-time, burst-threshold описывают наше затейливое сооружение для подачи марок. Все остальные описывают очередь.
Ну и если быть совсем въедливым, то в случае с простой очередью (simple queue) никакого HTB (в смысле "иерархии") нет. Есть очередь и есть одно единственное ведро (или просто труба) с марками, к которому она выстраивается.
Иерархия появляется когда мы создаём дерево очередей (queue tree) - выстраиваем их пирамидкой одно над другим! Так корневой (главный родительский) поток марок разбивается на струи (дочерние очереди). И этих дочерних очередей может быть несколько колен. Но в конце концов поток марок столкнётся с потоком пакетов, что бы пометить их! Такое "поколение, достигшее цели" называется конечная очередь или leaf (что переводится как "лист"). А все промежуточные колена, которые называются внутренними (inner), занимаются лишь перекачкой и распределением марок. Столкновения с пакетами в них не происходит, поэтому те части правил, которые относятся к описанию потока пакетов (в частности, priority или queue) в них не работают!
Не поленюсь ещё раз подчеркнуть важность ясного понимания того, какая часть правила описывает поток пакетов, а какая - поток марок!
При создании дерева очередей очень важно держать перед собой образ этих двух потоков, которые сначала как-то выстраиваются и разделяются на струи, но в конечном итоге пересекаются, что бы свершилось таинство маркировки!

Очень простое и красивое устройство, без нужды изуродованное и усложнённое косноязычными толкователями и переводчиками. Я, пожалуй, вернусь к нему ещё раз чуть позже - в прикладной работе.

Для каждой очереди мы можем задать два ограничения скорости передачи:
CIR (Committed Information Rate, гарантированная полоса пропускания) – (limit-at в RouterOS) даже при наихудшем варианте развития событий (общая полоса пропускания забита до отказа - прим. переводчика) потоку будет обеспечена данная скорость передачи трафика независимо от других потоков трафика. В любой момент времени ширина полосы пропускания не сможет упасть ниже данной фиксированной скорости передачи.
MIR (Maximum Information Rate, максимальная полоса пропускания) – (max-limit в RouterOS) максимально возможная скорость передачи данных в потоке в случае наилучшего развития событий, если доступна какая-либо свободная часть полосы пропускания.

Как видите, параметр EBS (exceed burst size) отсутствует, поскольку в RouterOS используется алгоритм с одним ведром. В итоге наш чертёж смахивает на одноногого Сильвера.
В случае с двумя вёдрами я бы нарисовал рядышком с зелёным второе, жёлтое ведро.
Подача марок происходит через трубу с пропускной способностью max-limit марок в секунду. На подходе к маркировочному блоку труба раздваивается. Одна часть имеет пропускную способность limit-at и те марки, что подаются через неё окрашивают пакеты в зелёный цвет.
Если зелёных марок нехватает, марки начинают подтягиваться из второй трубы. Но эти марки окрашивают пакеты в жёлтый цвет. Такие пакеты могут быть и уничтожены в дальнейшем, если для них не хватит ширины канала.

Собственно, даже зелёного ведра может не быть, если все три параметра, описывающие его (burst-limit, burst-time, burst-threshold) будут равны нулю.


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


Всё это, конечно, очень благородно, но вопрос о пометке голосового трафика никак не снимает. Трафик уже должен быть помечен при поступлении в дерево очередей.
Статья "MikroTik RouterOS. Семинар QoS. Лучшая практика." полностью посвящена вопросу приоритезации трафика. Там всё очень хорошо и подробно расписано. Кроме одного: как выделить голосовой трафик:


Пока что я никуда не продвинулся. Откуда начал - туда и пришёл.

Земную жизнь пройдя до половины,
Я очутился в сумрачном лесу,
Утратив правый путь во тьме долины...



Любопытно, кому-нибудь нужно то, что я здесь пишу?

[podarok66]

Мне нужно однозначно. Я всегда ЗА чему-нить поучиться, тем более у человека, который в вопросе хорошо ориентируется. А коменты не сыплю, чтобы лишнего флуда не было.
Ну вот, опять нафлудил

[Barvinok]

А я не очень хорошо ориентируюсь. Это живое исследование. Я по ходу дела разбираюсь что к чему придерживаясь правила, которое озвучил в самом начале: каждое слово должно указывать на совершенно определённое понятие. Но это так же значит, что понятия должны быть определены.
Сначала привожу всё к единому знаменателю, т.е. перевожу на один язык, что бы не собирать из лоскутов. А дальше уже язык сам подсказывает. Это же единая ткань, где все слова увязаны друг с другом в целостное описание мира. Тут главное - соблюсти строгость и последовательность рассуждения и выстроить целостный, внутренне непротиворечивый образ.
Рад, если кому то пригодится. Замечания и пожелания пишите в личку.

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

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