Comments 24
Картиночек по shaping'у и полисингу не хватает.
Были симпатичнее, с отображением задержки, но нашёл только такую

Этими — не решается. В PF конечно есть поддержка CBQ и PQ, но это отнюдь не то что по вашей ссылке.
Насколько я вижу (я плохо разбираюсь в ФриБСД), там есть немного тэгирования. Но что то про выделение полосы, взвешивание, полисинг я не нашёл…
На самом деле фокус с изменением дефолтного резерва под CBWFQ в 75% с помощью задания bandwidth в class-default не пройдет. Для изменения резерва существует команда max-reserved-bandwidth на интерфейсе.
Да, Олег, спасибо!

Это я упустил. Писал в самолете: во Владик и из Владика, думалось тяжело. Добавлю.
«Защищамся » — Это такая опечатка, или какой то скрытый смысл?
Спасибо огромное за статью!!!
Это безусловно полезно и написано о сложном очень доступно =)
У меня только вопрос возник по служебному трафику (для роутинга и управления) — как его можно выделить, где помечать и какой лучше ставить приоритет?
Для служебного и управляющего принято ставить dscp 7 или 6
Если я правильно помню, это касается скорее поля IPP и CoS. И то это скорее рекомендации
Правильно помнишь)
> И то это скорее рекомендации
ну так я и сказал, что принято, но не обязательно. dscp7, насколько я помню, в железе идет отдельной очередью и он без труда делается реалтаймовым
Маркируем пакеты:

queue-list 1 protocol ip 1 list 101
queue-list 1 default 16
queue-list 1 queue 1 byte-count 10000
queue-list 1 queue 16 byte-count 1000

Теперь все пакеты, подходящие под access-list номер 101, попадут в очередь №1 и будут иметь приоритет перед остальными (по умолчанию в 16ую очередь). Т.е. за один цикл прохода по очередям первая получит 10 Кб, а 16я только 1Кб.
PS. Не забываем навесить queue-list на интерфейсы (команда custom-queue-list 1)
Хорошая добавка, но технология дюже старая. Её уже давно стараются не использовать.Это как раз способ задать несколько приоритетных очередей.
Я еще недочитал, но уже хочу поблагодарить за супер интересную статью)
Это круто.
Но я не нашел пример как метить траффик на основе политик.
Сегодня тыкал и не смотря на set dscp что-то не маркировались пакеты, хотя были должны. Буду пробовать еще.
Странно. Некоторое железо не позволяет на выход полисить. Но метить вроде все должны уметь. Имею ввиду L3 устройства.

формат простой:

policy-map POLICY
class CLASS
set dcsp cs5
Чтобы не быть голословным:
policy-map QoS
class qos_max_max_first
set precedence 7
class qos_max_max_iptv
set precedence 7
class qos_max_max_voip
set precedence 5
class qos_max_mid_gaming
set precedence 4
class qos_min_mid_db
set precedence 3
class qos_min_mid_http
set dscp cs3
class qos_min_mid_mail
set precedence 3
class qos_min_mid_vpn
set precedence 3
class class-default
set precedence 0

Вот пример класса:
class-map match-any qos_max_mid_gaming
match access-group name qos_max_mid_gaming
match ip precedence 4

Я и так и так пробовал. Возможно какие-тоо определенные команды на интерфейсе(влане) надо прописать?
mls qos vlan based как-то
Описание в статье WFQ неправильное. WFQ не поддерживает маркировку, при использовании данного метода нельзя определить для пакета очередь. Данный метод производит автоматическую классификацию трафика и разбивает его на потоки. При классификации вычисляется хэш функция, которая учитывает множество параметров, а не только ip-precedence — адреса и порты источника, назначения + tos. Пакеты с разными хэшами попадают в разные очереди. Для каждого значения хэша создаётся автоматически отдельная очередь. Количество очередей ограничено, поэтому при генерации 4096 очередей следующие потоки попадают в уже существующие очереди. Вы говорите, что пакет попадает в ту или иную очередь в зависимости от TOS, но это не так. Два пакета с одинаковым TOS но с разными ip-адресами попадут в разные очереди. WFQ практически неуправляем, единственное воздействие — это TOS. Задавая больший ip-precedence мы уменьшаем у пакетов SQ, это приводит, во-первых, к увеличению доли полосы пропускания для данного потока, во-вторых, уменьшает вероятность дропа пакетов данной очереди при её переполнении. Кроме этого, SQ обратно пропорционален размеру пакета, поэтому, вероятность у маленького пакета быть дропнутым меньше, чем у большого.
Only those users with full accounts are able to leave comments. Log in, please.