Казалось бы вещи, вынесенные в заголовок, достаточно тривиальны и описаны во множестве мест глобальной сети, но это только на первый взгляд. Опробовав наиболее часто встречающиеся советы я обнаружил несколько «подводных камней», глыб и даже скальных образований.

Но это все слова, ближе к делу.
Достаточно распространенная ситуация — Asterisk внутри ЛКС, за маршрутизатором MikroTik.
Дабы выделить трафик сервера, где установлена PBX, администратор отрезает часть канала провайдера выделяя его исключительно для конкретного IP.
Или другая реализация, когда нужный трафик определяется не только по IP-адресу PBX, но и по размеру пакетов и протоколу.
Попробовали — работает. Можно забыть? А вот и нет.

Что если администратору захочется слить что-то из Интернет находясь в консольке сервера, или наоборот отправить куда-либо в Интернет большое количество траффика? Правильно — он приоритезируется на MikroTik так же как и полезный трафик от PBX, что в итоге приведет к проблемам с IP-телефонией.

Решение здесь старо как сам IPv4 — метить трафик на сервере с Asterisk генерируемый только ею, и так, чтобы MikroTik это мог «увидеть», отматчить(простите за столь грубый англицизм) и приоритезировать только его.

Следующим пунктом у нас идет резервирование каналов от двух интернет-провайдеров.
Думаю что каждому системному администратору, использующему в своем хозяйстве маршрутизаторы MikroTik, знаком скрипт из wiki — wiki.mikrotik.com/wiki/Failover_Scripting
Он всем хорош, но как и в предыдущей ситуации есть ряд «но».
Наиболее весомому из них имя «Connection tracking» и заключается оно вот в чем:
когда наш основной ISP изволит отдохнуть от трудов праведных, траффик переключается на резервного.

Все вроде бы довольны, ютуб работает, яп тоже, но сколько бы мы не кричали экспекто потронум

sip reload

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

core restart now

SIP-регистрации не поднимаются.

А дело в том, что в механизме «Connection tracking» остались висеть записи от «старого»(основного) интернет-канала и их нужно удалить, после чего регистрации успешно поднимутся и звонки начнут проходить.

Если вам интересно как доказать MikroTik'у кто все-таки верблюд, а так же как автоматизировать в скрипте сброс «старых» соединений, то вам прямо под кат.

А что бы вы со своей стороны могли предложить?
— Да что тут предлагать… А то пишут, пишут… конгресс, немцы какие-то… Голова пухнет. Взять все, да и поделить.
— Так я и думал, — воскликнул Филипп Филиппович, шлепнув ладонью по скатерти, — именно так и полагал.
М. Булгаков, «Собачье сердце»

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