+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

QOS для VoIP — подтверждение

QOS для VoIP — подтверждение, RouterOS

Gautier

Guest

18.01.2018 09:18:00

Всем привет! Я пытаюсь настроить QoS, чтобы голосовые пакеты имели приоритет в моей сети для одного конкретного приложения. Не уверен, что делаю всё в правильном порядке, но вот что у меня получилось. Как думаете, всё ли правильно или что-то лишнее или наоборот не хватает?

В общем, у меня есть список из 6 IP-адресов (здесь я привёл только один в качестве примера). Потом создаю правила mangle: одно для TCP-протокола (используется только для сигнализации вызовов в приложении) и одно для UDP-протокола (используется во время звонков). Затем создаю очередь.

Предположим, у меня 22 Мб/с на загрузку и выгрузку, я вычитаю 10% для запаса и выделяю 25% от полосы пропускания этим пакетам. Получается 5 Мб/с для этого приложения (из которых 4 Мб/с идут на UDP и 1 Мб/с на TCP, хотя, скорее всего, для TCP можно взять и меньше) и 15 Мб/с — для остального трафика. Подключение идёт через порт ether0.

Вот что я делаю:

/ip firewall address-list
Add address=xx.xxx.xxx.xxx/xx list=List_IP

/ip firewall mangle
add chain=forward dst-address-list=List_IP protocol=tcp port=5060,5061,5063,5080 action=mark-connection new-connection-mark=Voice-c
add chain=forward src-address-list=List_IP protocol=tcp port=5060,5061,5063,5080 action=mark-connection new-connection-mark=Voice-c
add chain=forward dst-address-list=List_IP protocol=udp port=10000-20000 action=mark-connection new-connection-mark=Voice
add chain=forward src-address-list=List_IP protocol=udp port=10000-20000 action=mark-connection new-connection-mark=Voice
add chain=forward connection-mark=Voice-SIP action=mark-packet new-packet-mark=Voice_c
add chain=forward connection-mark=Voice action=mark-packet new-packet-mark=Voice_P

/queue tree
add limit-at=20Mb max-limit=20Mb name=Up parent=ether0 queue=default
add limit-at=4Mb max-limit=4Mb name=Voice_Up packet-mark=Voice_P parent=Up priority=1 queue=default
add limit-at=1Mb max-limit=1Mb name=Voice_Up packet-mark=Voice_c parent=Up priority=1 queue=default
add name=Rest_Up parent=Up priority=8 queue=default

add limit-at=20Mb max-limit=20Mb name=Down parent=ether0 queue=default
add limit-at=4Mb max-limit=4Mb name=Aircall_Down packet-mark=Voice_P parent=Down priority=1 queue=default
add limit-at=1Mb max-limit=1Mb name=Aircall_Down packet-mark=Voice_c parent=Down priority=1 queue=default
add name=Rest_Down parent=Down priority=8 queue=default

Кажется, теперь у меня часть канала выделена на это конкретное приложение. Как думаете, так правильно? Одно из моих главных непониманий — это выбор цепочки. Я выбрал forward, но не уверен. На чём должен базироваться мой выбор?

У меня только этот один роутер, все компьютеры подключены через ethernet. Кстати, знаю, что все пакеты, приходящие и уходящие из этого приложения, автоматически помечены тегом DSCP 46. Мог ли я сделать что-то проще, опираясь на это?

Большое спасибо за помощь, ребята! Cheers!

Gautier

Guest

01.02.2018 17:44:00

Спасибо за ваши ответы, теперь всё стало понятнее! Поскольку пакеты уже несут тег DSCP 46, и если я не хочу делить полосу пропускания, а просто полагаюсь на приоритеты, то будет достаточно такого настроя. Правильно ли я понимаю?

/ip firewall mangle
add connection-mark=no-mark chain=postrouting dscp=46 action=mark-packet new-packet-mark=Voice passthrough=no

/queue tree
add max-limit=[90% Download max ligne] name=Down parent=[Connection entrance] queue=default
add name=Voice_D parent=Down priority=1 packet-mark=Voice queue=default
add name=Rest_Down parent=Down priority=8 queue=default

add max-limit=[90% Upload max ligne] name=Up parent=[Connection entrance] queue=default
add name=Voice_U parent=Up priority=1 packet-mark=Voice queue=default
add name=Rest_Up parent=Up priority=8 queue=default

Не лучше ли в дереве очередей явно указать, что приоритет 8 даётся пакетам без маркировки, чтобы разделялось не только между пакетами с тегом DSCP 46 и остальными, а чтобы не возникало перекрытий? Ещё раз спасибо за помощь!

sebastia

Guest

01.02.2018 20:08:00

Это действительно самый минимальный вариант. Просто проверь, что пакеты, приходящие из интернета, имеют тег 46. Это легко проверить по счётчикам: если они растут для Download-Voice — значит, всё в порядке. Обязательно назначь «no-mark» какой-то очереди, например Rest_xx, иначе они будут обходить очередь! Также рекомендую использовать SFQ или PCQ в качестве типа очереди для «Rest».

Gautier Guest	#4 0 02.02.2018 10:04:00 Отлично, большое спасибо за помощь, Себасти!

pe1chl

Guest

02.02.2018 10:09:00

Это правильный способ сделать это, но, пожалуйста, поймите, что приоритет трафика на загрузку установить практически невозможно. Для направления на отправку этот метод работает идеально, а на загрузке вы полностью зависите от вашего провайдера. Если поставить очередь на внутреннем интерфейсе, вы просто ограничите скорость, с которой они получают трафик на загрузку, но это достигается за счёт сброса пакетов, которые вы уже получили через интернет-линию, то есть в самом начале канала у провайдера уже возникла перегрузка. Насколько она серьёзна, зависит от оборудования и настроек провайдера. Если не повезло, они оптимизировали всё под speedtest и у них на линии большой FIFO-буфер. Если повезёт, буфер маленький, и они используют «fair queue» или даже реагируют на DSCP, чтобы улучшить качество VoIP так же, как и на отправке.

Gautier

Guest

02.02.2018 12:51:00

Спасибо за уточнение, pe1chl. Просто хочу прояснить: по твоему мнению, лучше ничего не делать с трафиком загрузки? Есть ли риск, что установка очереди в этом направлении даст обратный эффект, то есть вызовет задержки вместо улучшения именно этого голосового трафика?

pe1chl

Guest

02.02.2018 13:32:00

Да, если вы работаете только с VoIP и другим трафиком без дальнейшей классификации на высокоприоритетный и обычный с низкими лимитами, то ограничение входящего трафика вряд ли принесёт какую-то пользу, но зато снизит общий доступный канал. Это скорее не обратный эффект, а просто отсутствия улучшений. Сначала попробуйте отключить эти правила. Если начнутся проблемы со звуком при загрузке, тогда стоит снова разобраться. А вот для отдачи такая настройка действительно работает и значительно улучшает ситуацию!

Gautier Guest	#8 0 02.02.2018 13:38:00 Отлично, ещё раз спасибо за помощь, pe1chl! Теперь всё намного понятнее!

sebastia

Guest

02.02.2018 14:35:00

Я не согласен с этим утверждением по следующей причине: большая часть трафика в интернете и из интернета основана на TCP. TCP использует окно передачи для управления пропускной способностью соединения и имеет встроенный алгоритм, который автоматически регулирует размер окна для достижения наилучших результатов, что можно упростить так: если всё приходит без ошибок — увеличиваем окно, если возникают ошибки — уменьшаем. При наличии очереди на «приёмном» интерфейсе этот второй шаг позволяет любому TCP-соединению адаптировать свою пропускную способность в рамках заданных границ. Ограничивая общую пропускную способность до определённого значения, можно сохранять резерв для приоритетных данных или для внезапных всплесков трафика. Когда пропускная способность всегда доступна, на стороне провайдера не накапливается буферизация, и можно гарантировать низкую задержку для таких сервисов, как VOIP. Таким образом, за счёт уменьшения используемой пропускной способности мы получаем низкую задержку. Это и есть преимущество.

pe1chl

Guest

#10

02.02.2018 14:46:00

На практике это работает не очень хорошо, потому что современные реализации TCP не ориентированы на контроль пропускной способности, а оптимизированы на максимальную скорость передачи с использованием огромных окон. Потеря одиночных пакетов вызывает быстрое повторное отправление. Именно такое поведение приводит к сбоям, когда пакеты приходят не по порядку. Кроме того, если пакеты сбрасываются не у провайдера, а дальше по цепочке, это заставляет передавать одни и те же данные по и без того перегруженной линии несколько раз. Было бы лучше, если бы очередь могла влиять на размер TCP-окна (рекламируя меньший размер вверх по потоку, изменяя ACK-пакеты), но я не думаю, что RouterOS это умеет. Лучшие результаты достигаются при правильных настройках у провайдера: справедливое распределение очередей, маленькая очередь и, желательно, приоритет для пакетов с DSCP=46.

sebastia

Guest

#11

02.02.2018 15:17:00

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

16again Guest	#12 0 04.02.2018 13:49:00 @pe1chl Кто вообще сказал про потерю пакетов? В очереди на скачивание мы регулируем трафик, то есть задерживаем, а не теряем пакеты. По моему мнению, это эффективный способ контролировать общий TCP-пропуск, оставляя место для VOIP-трафика.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры