Fedia Jun 24 2009 at 18:03

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

11 min

187K

Cisco*

+28

Comments 24

dizabled Jun 24 2009 at 20:14

Защищаемся

pepelac Jun 24 2009 at 20:39

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

iZENfire Jun 24 2009 at 20:39

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

OlegD Jun 24 2009 at 21:04

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

iZENfire Jun 24 2009 at 23:26

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

Fedia Jun 24 2009 at 22:50

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

OlegD Jun 24 2009 at 20:59

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

Fedia Jun 24 2009 at 22:36

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

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

TimTim Jun 24 2009 at 21:38

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

Fedia Jun 24 2009 at 22:45

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

lena_sakhno Jun 25 2009 at 03:56

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

svk Jun 25 2009 at 05:45

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

Fedia Jun 25 2009 at 09:01

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

svk Jun 25 2009 at 23:11

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

dohlik Jun 25 2009 at 08:54

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

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 Jun 25 2009 at 09:02

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

kuten Jun 25 2009 at 11:36

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

Bolik Jun 29 2009 at 15:32

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

TiFFolk Jun 30 2009 at 23:13

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

Fedia Jul 2 2009 at 19:30

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

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

policy-map POLICY
class CLASS
set dcsp cs5

TiFFolk Jul 3 2009 at 03:48

Чтобы не быть голословным:
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 Sep 17 2009 at 10:38

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

Fedia Sep 17 2009 at 10:41

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

rapidspacerocket Dec 29 2013 at 18:22

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

Show the best of all time