Mikrotik. QoS для дома / Хабр

Механизмы DiffServ

Что же собой являет DiffServ и почему он выигрывает у IntServ?Если очень просто, то трафик делится на классы. Пакет на входе в каждый узел классифицируется и к нему применяется набор инструментов, который по-разному обрабатывает пакеты разных классов, таким образом обеспечивая им разный уровень сервиса.

Но просто не будет.В основе DiffServ лежит идеологически выдержанная в традициях IP концепция PHB — Per-Hop Behavior. Каждый узел по пути трафика самостоятельно принимает решение о том, как вести себя относительно пришедшего пакета, на основе его заголовков.

Действия маршрутизатора с пакетом назовём моделью поведения (Behavior). Количество таких моделей детерминировано и ограничено. На разных устройствах модели поведения по отношению к одному и тому же трафику могут отличаться, поэтому они и per-hop.Понятия Behavior и PHB я буду использовать в статье как синонимы.

Тут есть лёгкая путаница. PHB — это с одной стороны общая концепция независимого поведения каждого узла, с другой — конкретная модель на конкретном узле. С этим мы ещё разберёмся.

Используя имеющиеся модели поведения, сеть может предоставлять различные классы сервиса (Class of Service).
То есть разные категории трафика могут получить разный уровень сервиса в сети путём применения к ним разных PHB.
Соответственно прежде всего нужно определить к какому классу сервиса относится трафик — классификация (Classification).
Каждый узел самостоятельно классифицирует поступающие пакеты. Metering) — сколько битов/байтов трафика данного класса пришло на маршрутизатор.
На основе результатов пакеты могут окрашиваться (Coloring): зелёный (в рамках установленного лимита), жёлтый (вне лимита), красный (совсем берега попутал). Policing) (уж простите за такую кальку, есть вариант лучше — пишите, я поменяю). Полисер на основе цвета пакета назначает действие по отношению к пакету — передать, отбросить или перемаркировать. Queuing). Для каждого класса сервиса выделена отдельная очередь, что и позволяет их дифференцировать, применяя разные PHB.
Но ещё до того, как пакет попадёт в очередь, он может быть отброшен (Dropper), если очередь заполнена.
Если он зелёный, то он пройдёт, если жёлтый, то его вполне вероятно, отбросят, если очередь полна, а если красный — это верный смертник. Условно, вероятность отбрасывания зависит от цвета пакета и наполненности очереди, куда он собирается попасть. Shaper), задача которого очень похожа на задачу полисера — ограничить трафик до заданного значения.
Можно настроить произвольные шейперы для отдельных очередей или даже внутри очередей.
Об отличии шейпера от полисера в главе Ограничение скорости.
Все очереди в итоге должны слиться в единый выходной интерфейс.
Вспомните ситуацию, когда на дороге 8 полос сливаются в 3. Без регулировщика это превращается в хаос. Разделение по очередям не имело бы смысла, если бы на выходе мы имели то же, что на входе.
Поэтому есть специальный диспетчер (Scheduler), который циклически вынимает пакеты из разных очередей и отправляет в интерфейс (Scheduling).
На самом деле связка набора очередей и диспетчера — самый главный механизм QoS, который позволяет применять разные правила к разным классам трафика, одним обеспечивая широкую полосу, другим низкие задержки, третьим отсутствие дропов.
Далее пакеты уже выходят на интерфейс, где происходит преобразование пакетов в поток битов — сериализация (Serialization) и далее сигнал среды.
Для этого, во-первых, на всех маршрутизаторах, настраиваются одинаковые классы и PHB для них, а во-вторых, используется маркировка (Marking) пакета — его принадлежность определённому классу записывается в заголовок (IP, MPLS, 802.1q).
И красота DiffServ в том, что следующий узел может довериться этой маркировке при классификации.
Такая зона доверия, в которой действуют одинаковые правила классификации трафика и одни модели поведения, называется домен DiffServ (DiffServ-Domain). Remark/Rewrite) его согласно правилам домена, и дальнейшие узлы будут доверять этой маркировке и не делать сложную классификацию.
То есть явной сигнализации в DiffServ нет, но узел может сообщить всем следующим, какой класс нужно обеспечить этому пакету, ожидая, что тот доверится.
На стыках между DiffServ-доменами нужно согласовывать политики QoS (или не нужно).
Целиком картина будет выглядеть примерно так:

Чтобы было понятно, приведу аналог из реальной жизни.
Перелёт на самолёте (не Победой).
Есть три класса сервиса (CoS): Эконом, Бизнес, Первый.
При покупке билета происходит классификация (Classification) — пассажир получает определённый класс сервиса на основе цены.
В аэропорту происходит маркировка (Remark) — выдаётся билет с указанием класса.
Есть две модели поведения (PHB): Best Effort и Premium.
Есть механизмы, реализующие модели поведения: Общий зал ожидания или VIP Lounge, микроавтобус или общий автобус, удобные большие сиденья или плотностоящие ряды, количество пассажиров на одну борт-проводницу, возможность заказать алкоголь.
В зависимости от класса назначаются модели поведения — эконому Best Effort, Бизнесу — Premium базовый, а Первому — Premium SUPER-POWER-NINJA-TURBO-NEO-ULTRA-HYPER-MEGA-MULTI-ALPHA-META-EXTRA-UBER-PREFIX! При этом два Premium отличаются тем что, в одном дают бокал полусладкого, а в другом безлимит Бакарди.
Далее по приезду в аэропорт все заходят через одни двери. Тех, кто попытался провезти с собой оружие или не имеет билета, не пускают (Drop). Бизнес и эконом попадают в разные залы ожидания и разный транспорт (Queuing). Сначала на борт пускают Первый класс, потом бизнес, потом эконом (Scheduling), однако потом они в пункт назначения все летят одним самолётом (интерфейс).
В этом же примере перелёт на самолёте — это задержка передачи (Propagation), посадка — задержка сериализации (Serialization), ожидание самолёта в залах — Queuing, а паспортный контроль — Processing. Заметьте, что и тут Processing Delay обычно пренебрежимо мал в масштабах общего времени.
Следующий аэропорт может обойтись с пассажирами совсем иначе — его PHB отличается. Но при этом если пассажир не меняет авиакомпанию, то, скорее всего, отношение к нему не поменяется, потому что одна компания — один DiffServ-domain.

Как вы могли уже заметить, DiffServ предельно (или беспредельно) сложен. Но всё описанное выше, мы разберём. При этом в статье я не буду вдаваться в нюансы физической реализации (они могут различаться даже на двух платах одного маршрутизатора), не буду рассказывать про HQoS и MPLS DS-TE.
Порог входа в круг инженеров, понимающих технологию, для QoS значительно выше, чем для протоколов маршрутизации, MPLS, или, прости меня Радья, STP.
И несмотря на это DiffServ заслужил признание и внедрение на сетях по всему миру, потому что, как говорится, хайли скэлэбл.
Всю дальнейшую часть статьи я буду разбирать только DiffServ.
Ниже мы разберём все инструменты и процессы, указанные на иллюстрации.

Dwrr — deficit weighted round robin

И вдруг, крайне любопытный подход в 1995-м году предложили M. Shreedhar and G. Varghese.
Каждая очередь имеет отдельную кредитную линию в битах.
При проходе из очереди выпускается столько пакетов, на сколько хватает кредита.
Из суммы кредита вычитается размер того пакета, что в голове очереди.
Если разность больше нуля, этот пакет изымается, и проверяется следующий. Так до тех пор, пока разность не окажется меньше нуля.
Если даже первому пакету не хватает кредита, что ж, увы-селявы, он остаётся в очереди.
Перед следующим проходом кредит каждой очереди увеличивается на определённую сумму, называемую квант.
Для разных очередей квант разный — чем большую полосу нужно дать, тем больше квант.
Таким образом все очереди получают гарантированную полосу, независимо от размера пакетов в ней.

С DWRR всё же остаётся вопрос с гарантией задержек и джиттера — вес его никак не решает.Теоретически, здесь можно поступить как и с CB-WFQ, добавив LLQ.Однако это лишь один из возможных сценариев набирающего сегодня популярность

Ipv4 tos

Поле QoS сопутствует нам ровно столько же, сколько и IP. Восьмибитовое поле TOS — Type Of Service — по задумке должно было нести приоритет пакета.
Ещё до появления DiffServ RFC 791 (INTERNET PROTOCOL) описывал поле так:
IP Precedence (IPP) DTR 00.
Последние два бита должны быть нулём.Чуть позже в RFC 1349 (Type of Service in the Internet Protocol Suite) поле TOS немного переопределили:
Вот как следовало читать единицы в этих битах TOS:

• D — «minimize delay»,
• T — «maximize throughput»,
• R — «maximize reliability»,
• C — «minimize cost».

Туманные описания не способствовали популярности этого подхода.
Системный подход к QoS на всём протяжении пути отсутствовал, чётких рекомендаций, как использовать поле приоритета тоже не было, описание битов Delay, Throughput и Reliability было крайне туманным.
Поэтому в контексте DiffServ поле TOS ещё раз переопределили в RFC 2474 (Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers): Differentiated Services Code Point, два правых бита не были использованы.
С этого момента именно поле DSCP должно было стать главной маркировкой DiffServ: в него записывается определённое значение (код), которое в пределах данного DS-домена характеризует конкретный класс сервиса, необходимый пакету и его приоритет отбрасывания. Это та самая цифра.
Все 6 бит DSCP администратор может использовать, как ему заблагорассудится, разделяя максимум до 64 классов сервиса.
Однако в угоду совместимости с IP Precedence за первыми тремя битами сохранили роль Class Selector.
То есть, как и в IPP, 3 бита Class Selector позволяют определить 8 классов.
Далее также замечу, что согласно рекомендациям IETF, чем выше значение, записанное в CS, тем требовательнее этот трафик к сервису.
Но и это не стоит воспринимать как неоспоримую истину.
Если первые три бита определяют класс трафика, то следующие три используются для указания приоритета отбрасывания пакета (Drop Precedence или Packet Loss Priority — PLP).

Восемь классов — это много или мало? На первый взгляд мало — ведь так много разного трафика ходит в сети, что так и хочется каждому протоколу выделить по классу. Однако оказывается, что восьми достаточно для всех возможных сценариев.
Для каждого класса нужно определять PHB, который будет обрабатывать его как-то отлично от других классов.
Да и при увеличении делителя, делимое (ресурс) не увеличивается.
Я намеренно не говорю о том, какие значения какой именно класс трафика описывают, поскольку здесь нет стандартов и формально их можно использовать по своему усмотрению. Ниже я расскажу, какие классы и соответствующие им значения рекомендованы.

Mikrotik. qos для дома

#Set bandwidth of the interface
:local interfaceBandwidth 100M

# address-lists
:for i from=1 to=10 do={/ip firewall address-list add list=WoT address=("login.p"."$i".".worldoftanks.net")}
#
/ip firewall mangle
# prio_1
    add chain=prerouting action=mark-packet new-packet-mark=prio_1 protocol=icmp
    add chain=prerouting action=mark-packet new-packet-mark=prio_1 protocol=tcp port=53
    add chain=prerouting action=mark-packet new-packet-mark=prio_1 protocol=udp port=53
    add chain=prerouting action=mark-packet new-packet-mark=prio_1 protocol=tcp tcp-flags=ack packet-size=0-123
# prio_2
    add chain=prerouting action=mark-packet new-packet-mark=prio_2 dscp=40                                     
    add chain=prerouting action=mark-packet new-packet-mark=prio_2 dscp=46
    add chain=prerouting action=mark-packet new-packet-mark=prio_2 protocol=udp port=5060,5061,10000-20000 src-address=192.168.100.110
    add chain=prerouting action=mark-packet new-packet-mark=prio_2 protocol=udp port=5060,5061,10000-20000 dst-address=192.168.100.110
# prio_3
    add chain=prerouting action=mark-packet new-packet-mark=prio_3 protocol=tcp port=22
    add chain=prerouting action=mark-packet new-packet-mark=prio_3 src-address-list=WoT
    add chain=prerouting action=mark-packet new-packet-mark=prio_3 dst-address-list=WoT
# prio_4
    add chain=prerouting action=mark-packet new-packet-mark=prio_4 protocol=tcp port=3389
    add chain=prerouting action=mark-packet new-packet-mark=prio_4 protocol=tcp port=80,443
Аккуратно уложим размеченный трафик в очередь:

<source>queue tree add max-limit=$interfaceBandwidth name=QoS_global parent=global priority=1
:for indexA from=1 to=4 do={
   /queue tree add  
      name=( "prio_" . "$indexA" ) 
      parent=QoS_global 
      priority=($indexA) 
      queue=ethernet-default 
      packet-mark=("prio_" . $indexA) 
      comment=("Priority " . $indexA . " traffic")
}
/queue tree add name="prio_5" parent=QoS_global priority=5 
    queue=ethernet-default packet-mark=no-mark comment="Priority 5 traffic"

/ip firewall mangle
# prio_1
    add chain=prerouting action=set-priority new-priority=7 protocol=icmp
    add chain=prerouting action=set-priority new-priority=7 protocol=tcp port=53
    add chain=prerouting action=set-priority new-priority=7 protocol=udp port=53
    add chain=prerouting action=set-priority new-priority=7 protocol=tcp tcp-flags=ack packet-size=0-123
# prio_2
    add chain=prerouting action=set-priority new-priority=6 dscp=40                                     
    add chain=prerouting action=set-priority new-priority=6 dscp=46
    add chain=prerouting action=set-priority new-priority=6 protocol=udp port=5060,5061,10000-20000 src-address=192.168.100.110
    add chain=prerouting action=set-priority new-priority=6 protocol=udp port=5060,5061,10000-20000 dst-address=192.168.100.110
# prio_3
    add chain=prerouting action=set-priority new-priority=5 protocol=tcp port=22
    add chain=prerouting action=mark-packet new-packet-mark=prio_3 src-address-list=WoT
    add chain=prerouting action=mark-packet new-packet-mark=prio_3 dst-address-list=WoT
# prio_4
    add chain=prerouting action=set-priority new-priority=3 protocol=tcp port=3389

:foreach i in=[/ip dns cache all find where (name~"youtube" || name~"facebook" || name~".googlevideo")]
    do={:put [/ip dns cache get $i address]}

:foreach i in=[/ip firewall nat find dynamic and comment~"Skype"]
    do={:put [/ip firewall nat get $i dst-port]}

Mpls traffic class

Концепция DiffServ была ориентирована на IP-сети с маршрутизацией на основе IP-заголовка. Вот только незадача — через 3 года опубликовали RFC 3031 (Multiprotocol Label Switching Architecture). И MPLS начал захватывать сети провайдеров.
DiffServ нельзя было не распространить на него.
По счастливой случайности в MPLS заложили трёхбитовое поле EXP на всякий экспериментальный случай. И несмотря на то, что уже давным-давно в RFC 5462 («EXP» Field Renamed to «Traffic Class» Field) официально стало полем Traffic Class, по инерции его называют ИЭксПи.
С ним есть одна проблема — его длина три бита, что ограничивает число возможных значений до 9. Это не просто мало, это на 3 двоичных порядка меньше, чем у DSCP. L-LSP. Использует комбинацию Traffic Class значение метки.

Вообще согласитесь, ситуация странная — MPLS разрабатывался как помощь IP для быстрого принятия решения — метка MPLS мгновенно обнаруживается в CAM по Full Match, вместо традиционного Longest Prefix Match. То есть и про IP знали, и в коммутации участие принимает, а нормальное поле приоритета не предусмотрели.

На самом деле выше мы уже увидели, что для определения класса трафика используется только первые три бита DSCP, а три другие — Drop Precedence (или PLP — Packet Loss Priority).Поэтому в плане классов сервиса всё же имеем соответствие 1:1, теряя только информацию о Drop Precedence.

В случае MPLS классификация так же как и в IP может быть на основе интерфейса, MF, значения DSCP IP или Traffic Class MPLS.Маркировка означает запись значения в поле Traffic Class заголовка MPLS.Пакет может содержать несколько заголовков MPLS.

1. Uniform Mode
2. Pipe Mode
3. Short-Pipe Mode

Single rate — two color marking

Пока не обращайте внимания на название =)
Имеем ведро, в которое падают монетки с постоянной скорость — 400 мегамонет в секунду, например.
Объём ведра — 600 миллионов монет. То есть наполняется оно за полторы секунды.
Рядом проходят две ленты конвейера: одна подвозит пакеты, вторая — увозит.
Чтобы попасть на отвозящий конвейер, пакет должен заплатить.
Монетки для этого он берёт из ведра в соответствии со своим размером. Грубо говоря — сколько битов — столько и монеток.
Если ведро уже полное, все новые монеты будут выбрасываться.
Если она стабильно ниже или равна 400 Мб в секунду, значит монет всегда будет хватать.
Если выше, то часть пакетов будет теряться.

Более конкретный пример с гифками, как мы все любим.

• Есть ведро ёмкостью 2500 байтов. На начальный момент времени в нём лежит 550 токенов. На конвейере три пакета по 1000 байтов, которые хотят быть отправлены в интерфейс. В каждый квант времени в ведро падает 500 байтов (500*8 = 4 000 бит/квант времени — ограничение полисера).
• На исходе первого кванта времени в ведро падает 500 токенов. И в это время подходит первый пакет. Его размер 1000 байтов, а в ведре 1050 токенов — хватает. Пакет красится в зелёный цвет и пропускается. 1000 токенов вынимается из ведра. В ведре остаётся 50 токенов.
• На исходе второго кванта времени в ведро падает ещё 500 токенов — итого 550. А размер пришедшего пакета — 1000 — не хватает. Пакет красится красным и отбрасывается, токены не вынимаются.
• На исходе третьего кванта в ведро падает ещё 500 токенов — снова 1050. Размер пришедшего пакета — 1000 — хватает. Пакет красится в зелёный и пропускается, токены вынимаются из ведра.

Объём ведра в 2500 байтов фактически означает, что через такой полисер ни при каких условиях не пройдёт пакет больше 2500 байтов — ему никогда не будет хватать токенов. Поэтому его объём должен быть не меньше MTU и вообще рекомендуется объём, равный количеству трафика на максимальной скорости, разрешённой полисером, за 1,5-2 секунды.
То есть формула следующая:
CBS = CIR (бит в секунду)*1,5 (секунды)/8 (бит в байте)
Если вернуться к практическому примеру по полисингу, где мы настраивали всплески (Bc), то станет понятно, что при большом значении (1 875 000 байтов) все всплески амортизируются хорошо. А при маленьком (10 000 байтов), несмотря на то, что оно заметно больше MTU, полисер упирается в постоянное заполнение ведра и отбрасывает большое количество пакетов.

Зачем ведру объём? Битовый поток не всегда равномерен, это очевидно. Ограничение в 400 Мб/с — это не асимптота — трафик может её пересекать. Объём хранящихся монет позволяет небольшим всплескам пролетать, не будучи отброшенными, однако среднюю скорость сохранить на уровне 400Мб/с.
Например, стабильный поток 399 Мб/с за 600 секунд позволит ведру наполниться до краёв.
Далее трафик может подняться до 1000Мб/с и держаться на этом уровне 1 секунду — 600 Мм (Мегамонет) запаса и 400 Мм/с гарантированной полосы.
Или же трафик может подняться до 410 Мб/с и держаться таким на протяжении 60 секунд.
Теперь к терминологии.
Скорость поступления монет в ведро — CIR — Committed Information Rate (Гарантированная средняя скорость). Измеряется в битах в секунду.
Количество монет, которые могут храниться в ведре — CBS — Committed Burst Size. Разрешённый максимальный размер всплесков. Измеряется в байтах. Иногда, как вы уже могли заметить, называется Bc. Tc — Количество монет (Token) в ведре C (CBS) в данный момент.

В статье я использую термин «Tc«, так же, как он использован в RFC 2697 (A Single Rate Three Color Marker).
Однако есть и другой Tc, который описывает интервал времени, когда в ведро ссыпается новая порция монет.
Здесь следует сделать отступление.
Невозможно подстроить скорость интерфейса, чтобы удовлетворить условиям полисера, поэтому и вводится система Token Bucket, реализующая по сути TDM (Time-Division Multiplexing) — она разрешает отправку трафика только в определённые моменты времени.
То есть монеты не льются в ведро непрерывным потоком — современный мир, увы, дискретен.
В первом приближении предлагается один раз в секунду насыпать CIR монет. Потом через секунду итд.
Это работает плохо, потому что всплеск — и секунда молчания, всплеск — и секунда молчания, всплеск — и секунда молчания.
Поэтому во втором приближении секунда делится на интервалы времени, в которые спускается определённое число монет.
Такой интервал времени тоже называется (как минимум в литературе Cisco) Tc, а количество падающих монет — Bc. При этом Bc = CIR*Tc.
То есть в начале каждого интервала Tc в ведро опускается Bc монет.

Это самый простой сценарий. Он называется Single Rate — Two Color.Single Rate означает, что есть только одна средняя разрешённая скорость, а Two Color — что можно покрасить трафик в один из двух цветов: зелёный или красный.

1. Если количество доступных монет (бит) в ведре C больше, чем количество бит, которые нужно пропустить в данный момент, пакет красится в зелёный цвет — низкая вероятность отбрасывания в дальнейшем. Монеты изымаются из ведра.
2. Иначе, пакет красится в красный — высокая вероятность дропа (либо, чаще, сиюминутное отбрасывание). Монеты при этом из ведра С не изымаются.

Используется для полисинга в PHB CS и EF, где превышения по скорости не ожидается, но если оно произошло, то лучше сразу отбросить.Дальше рассмотрим посложнее: Single Rate — Three Color.

Как определить приоритет трафика

После того, как вы включили Quality of Service, пришло время создать основные правила приоритизации трафика.

Некоторые новые маршрутизаторы имеют мертвые простые параметры QoS, где вы просто выбираете сервисы, которые вы хотите расставить по приоритетам (или перетаскивайте их в список). Вот, к примеру, это скриншот от нового маршрутизатора ASUS, который у нас есть:

Если это все, что вам нужно, и ваш маршрутизатор имеет эту функцию, попробуйте и посмотрите, что работает. Но если вам нужен более мелкий контроль, или у вас есть более старый маршрутизатор, у которого нет такой простой настройки, вот несколько более подробных инструкций по настройке QoS.

Приоритет службы

Если вы хотите, чтобы каждое устройство в вашей сети имело приоритетный доступ к определенному приложению или сервису, вы можете создать правило приоритета службы сети. Скажем, для примера, вы хотите убедиться, что Netflix получает приоритет за менее чувствительные к пропускной способности вещи, такие как общий просмотр веб-страниц. Сначала вы выберите услугу в раскрывающемся меню, как показано ниже, а затем нажмите «Добавить».

После того, как сервис указан, выберите приоритет, который вы хотите использовать для этого.

Приоритет по интерфейсу

В сетевом языке «интерфейс» — это метод, с помощью которого ваше устройство подключено к сети. Вы можете установить приоритеты в локальной сети Ethernet, вы можете назначить приоритеты беспроводным соединениям, или вы даже можете установить правила, которые делают сетевой трафик для гостей невысоким.

Давайте посмотрим, как мы можем сделать гостевой сетевой трафик низким приоритетом. В раскрывающемся меню мы выберем «wl0.1», который в сетевом сокращении будет виртуальной локальной сетью № 0. Виртуальная сеть 1. Нажмите «Добавить».

После того, как вы добавили интерфейс, вы можете указать максимальную скорость загрузки / скачивания и даже приоритизировать службы на конкретном соединении, как показано на скриншоте ниже.

Приоритет интерфейса заключается в том, что из-за необходимых знаний о схемах тайного сетевого наименования используется одна из наиболее сложных систем приоритета.

Приоритет устройства с IP-адресами

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

Скажем, например, что вы хотите, чтобы ваш домашний сервер, расположенный на статическом IP-адресе 10.0.0.200, имел доступ с наивысшим приоритетом к вашей сети. Вы должны ввести адрес в разделе «Приоритет сетевой маски» и добавить конец с 32, как показано ниже.

Элемент 32 — это сетевая маска. Подробное обсуждение использования netmask немного выходит за рамки этого руководства, но достаточно сказать, что маска / 32 — это сокращение сетевой маски для «только для разрешения этого единственного IP-адреса». Любое другое меньшее число позволит массе охватить большее количество адресов в данном блоке (например, 10.0.0.

200/24 ​​приведет к тому, что правило качества обслуживания будет применяться ко всем 254 потенциальным адресам в блоке 10.0.0. *) , Вы можете обратиться к этому краткому справочному руководству сетевой маски, чтобы выбрать номер, который работает для раздела и размера блока адресов, который вы хотите установить приоритет.

Если вы обнаружите, что сетевая маска немного запутана (это не совсем интуитивно понятно), лучше всего просто придерживаться / 32 и вводить вручную каждый IP-адрес.

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

Приоритет устройства с MAC-адресами

Если вы не используете статические IP-адреса в своей сети, вы все равно можете определить приоритеты для определенных компьютеров и устройств с их MAC-адресом. Он будет либо на физическом ярлыке, прикрепленном к устройству, либо где-нибудь в его настройках программного обеспечения.

С MAC-адресом в руке просто введите его в раздел приоритета MAC, нажмите «Добавить», а затем назначьте приоритет устройству, как это было в предыдущих разделах.

Теперь, независимо от того, какой IP-адрес назначает ваш маршрутизатор, скажем, вы можете обеспечить свой рабочий ноутбук, он всегда будет иметь приоритет.

Практика по mf классификации

Схема та же:
Это прекрасно внутри DS-домена, но неприемлемо в точке входа.
А давайте теперь не будем слепо доверять? На Linkmeup_R2 ICMP будем метить как EF (исключительно для примера), TCP как AF12, а всё остальное CS0.
Это будет MF (Multi-Field) классификация.

1. Процедура та же, но теперь матчить будем по ACL, которые выцепляют нужные категории трафика, поэтому сначала создаём их. На Linkmeup_R2:

   ip access-list extended TRISOLARANS_ICMP_ACL
   permit icmp any any
   ip access-list extended TRISOLARANS_TCP_ACL
   permit tcp any any
   ip access-list extended TRISOLARANS_OTHER_ACL
   permit ip any any

2. Далее определяем классификаторы:

   class-map match-all TRISOLARANS_TCP_CM
   match access-group name TRISOLARANS_TCP_ACL
   class-map match-all TRISOLARANS_OTHER_CM
   match access-group name TRISOLARANS_OTHER_ACL
   class-map match-all TRISOLARANS_ICMP_CM
   match access-group name TRISOLARANS_ICMP_ACL

3. А теперь определяем правила перемаркировки в политике:

   policy-map TRISOLARANS_ADMISSION_CONTROL
   class TRISOLARANS_ICMP_CM
   set ip dscp ef
   class TRISOLARANS_TCP_CM
   set ip dscp af11
   class TRISOLARANS_OTHER_CM
   set ip dscp default

4. И вешаем политику на интерфейс. На input, соответственно, потому что решение нужно принять на входе в сеть.

   interface Ethernet0/1
   service-policy input TRISOLARANS_ADMISSION_CONTROL

ICMP-тест с конечного хоста Trisolaran1. Никак сознательно не указываем класс — по умолчанию 0. Политику с Linkmeup_R1 я уже убрал, поэтому трафик приходит с маркировкой CS0, а не CS7.
Linkmeup_R1. E0/0.pcapng
Linkmeup_R2. E0/0.pcapng
Видно, что после классификаторов и перемаркировки на Linkmeup_R2 на ICMP-пакетах не только DSCP поменялся на EF, но и MPLS Traffic Class стал равным 5.
Аналогичный тест с telnet 172.16.2.2. 80 — так проверим TCP: Linkmeup_R1. E0/0.pcapng
Linkmeup_R2. E0/0.pcapng
ЧИТО — Что И Требовалось Ожидать. TCP передаётся как AF11.
Следующим тестом проверим UDP, который должен попасть в CS0 согласно нашим классификаторам. Для этого воспользуемся iperf (привезти его в Linux Tiny Core изи через Apps). На удалённой стороне iperf3 -s — запускаем сервер, на локальной iperf3 -c -u -t1 — клиент (-c), протокол UDP (-u), тест в течение 1 секунды (-t1). Linkmeup_R1. E0/0.pcapng
Linkmeup_R2. E0/0pcapng
С этого момента всё, что приходит в этот интерфейс, будет классифицировано согласно настроенным правилам.