Защищаемся маршрутизатором: QoS

[dizabled]

Защищаемся

[pepelac]

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

[iZENfire]

А вот как та же задача решается бесплатными средствами — PF: Packet Tagging (Policy Filtering).

[OlegD]

Этими — не решается. В PF конечно есть поддержка CBQ и PQ, но это отнюдь не то что по вашей ссылке.

[iZENfire]

Вот хороший пример тэгирования и шейпинга протегированного трафика с помощью PF: OpenBSD pf and Voice over IP.

[Fedia]

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

[OlegD]

На самом деле фокус с изменением дефолтного резерва под CBWFQ в 75% с помощью задания bandwidth в class-default не пройдет. Для изменения резерва существует команда max-reserved-bandwidth на интерфейсе.

[Fedia]

Да, Олег, спасибо!

Это я упустил. Писал в самолете: во Владик и из Владика, думалось тяжело. Добавлю.

[TimTim]

«Защищамся » — Это такая опечатка, или какой то скрытый смысл?

[Fedia]

Не надо искать смысла там, где его нет :) Поправил.

[lena_sakhno]

Спасибо огромное за статью!!!
Это безусловно полезно и написано о сложном очень доступно =)
У меня только вопрос возник по служебному трафику (для роутинга и управления) — как его можно выделить, где помечать и какой лучше ставить приоритет?

[svk]

Для служебного и управляющего принято ставить dscp 7 или 6

[Fedia]

Если я правильно помню, это касается скорее поля IPP и CoS. И то это скорее рекомендации

[svk]

Правильно помнишь)
> И то это скорее рекомендации
ну так я и сказал, что принято, но не обязательно. dscp7, насколько я помню, в железе идет отдельной очередью и он без труда делается реалтаймовым

[dohlik]

Маркируем пакеты:

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)

[Fedia]

Хорошая добавка, но технология дюже старая. Её уже давно стараются не использовать.Это как раз способ задать несколько приоритетных очередей.

[kuten]

Я еще недочитал, но уже хочу поблагодарить за супер интересную статью)

[Bolik]

спасибо, завтра прочту еще разок.

[TiFFolk]

Это круто.
Но я не нашел пример как метить траффик на основе политик.
Сегодня тыкал и не смотря на set dscp что-то не маркировались пакеты, хотя были должны. Буду пробовать еще.

[Fedia]

Странно. Некоторое железо не позволяет на выход полисить. Но метить вроде все должны уметь. Имею ввиду L3 устройства.

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

policy-map POLICY
class CLASS
set dcsp cs5

[TiFFolk]

Чтобы не быть голословным:
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 как-то

[Fedia]

Операционка какая? И чем проверял?

[Fedia]

Пакеты то в классы попадают?

[rapidspacerocket]

Описание в статье WFQ неправильное. WFQ не поддерживает маркировку, при использовании данного метода нельзя определить для пакета очередь. Данный метод производит автоматическую классификацию трафика и разбивает его на потоки. При классификации вычисляется хэш функция, которая учитывает множество параметров, а не только ip-precedence — адреса и порты источника, назначения + tos. Пакеты с разными хэшами попадают в разные очереди. Для каждого значения хэша создаётся автоматически отдельная очередь. Количество очередей ограничено, поэтому при генерации 4096 очередей следующие потоки попадают в уже существующие очереди. Вы говорите, что пакет попадает в ту или иную очередь в зависимости от TOS, но это не так. Два пакета с одинаковым TOS но с разными ip-адресами попадут в разные очереди. WFQ практически неуправляем, единственное воздействие — это TOS. Задавая больший ip-precedence мы уменьшаем у пакетов SQ, это приводит, во-первых, к увеличению доли полосы пропускания для данного потока, во-вторых, уменьшает вероятность дропа пакетов данной очереди при её переполнении. Кроме этого, SQ обратно пропорционален размеру пакета, поэтому, вероятность у маленького пакета быть дропнутым меньше, чем у большого.