По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В статье рассматриваются примеры протоколов, обеспечивающих Interlayer Discovery и назначение адресов. Первую часть статьи про Interlayer Discovery можно прочитать тут.
Domain Name System
DNS сопоставляет между собой человекочитаемые символьные строки, такие как имя service1. exemple, используемый на рисунке 1, для IP-адресов. На рисунке 3 показана основная работа системы DNS.
На рисунке 3, предполагая, что нет никаких кэшей любого вида (таким образом, весь процесс проиллюстрирован):
Хост A пытается подключиться к www.service1.example. Операционная система хоста проверяет свою локальную конфигурацию на предмет адреса DNS-сервера, который она должна запросить, чтобы определить, где расположена эта служба, и находит адрес рекурсивного сервера. Приложение DNS операционной системы хоста отправляет DNS-запрос на этот адрес.
Рекурсивный сервер получает этот запрос и - при отсутствии кешей - проверяет доменное имя, для которого запрашивается адрес. Рекурсивный сервер отмечает, что правая часть имени домена именуется example, поэтому он спрашивает корневой сервер, где найти информацию о домене example.
Корневой сервер возвращает адрес сервера, содержащий информацию о домене верхнего уровня (TLD) example.
Рекурсивный сервер теперь запрашивает информацию о том, с каким сервером следует связаться по поводу service1.example. Рекурсивный сервер проходит через доменное имя по одному разделу за раз, используя информацию, обнаруженную в разделе имени справа, чтобы определить, какой сервер следует запросить об информации слева. Этот процесс называется рекурсией через доменное имя; следовательно, сервер называется рекурсивным сервером.
Сервер TLD возвращает адрес полномочного сервера для service1.example. Если информация о местонахождении службы была кэширована из предыдущего запроса, она возвращается как неавторизованный ответ; если фактический сервер настроен для хранения информации об ответах домена, его ответ является авторитетным.
Рекурсивный сервер запрашивает информацию о www.service1.example у полномочного сервера.
Авторитетный сервер отвечает IP-адресом сервера B.
Рекурсивный сервер теперь отвечает хосту A, сообщая правильную информацию для доступа к запрошенной службе.
Хост A связывается с сервером, на котором работает www.service1.example, по IP-адресу 2001:db8:3e8:100::1.
Этот процесс может показаться очень затяжным; например, почему бы просто не сохранить всю информацию на корневом сервере, чтобы сократить количество шагов? Однако это нарушит основную идею DNS, которая заключается в том, чтобы держать информацию о каждом домене под контролем владельца домена в максимально возможной степени. Кроме того, это сделало бы создание и обслуживание корневых серверов очень дорогими, поскольку они должны были бы иметь возможность хранить миллионы записей и отвечать на сотни миллионов запросов информации DNS каждый день. Разделение информации позволяет каждому владельцу контролировать свои данные и позволяет масштабировать систему DNS.
Обычно информация, возвращаемая в процессе запроса DNS, кэшируется каждым сервером на этом пути, поэтому сопоставление не нужно запрашивать каждый раз, когда хосту необходимо достичь нового сервера.
Как обслуживаются эти таблицы DNS? Обычно это ручная работа владельцев доменов и доменов верхнего уровня, а также пограничных провайдеров по всему миру. DNS не определяет автоматически имя каждого объекта, подключенного к сети, и адрес каждого из них.
DNS объединяет базу данных, обслуживаемую вручную, с распределением работы между людьми, с протоколом, используемым для запроса базы данных; следовательно, DNS попадает в базу данных сопоставления с классом протоколов решений. Как хост узнает, какой DNS-сервер запрашивать? Эта информация либо настраивается вручную, либо изучается с помощью протокола обнаружения, такого как IPv6 ND или DHCP.
DHCP
Когда хост (или какое-либо другое устройство) впервые подключается к сети, как он узнает, какой IPv6-адрес (или набор IPv6-адресов) назначить локальному интерфейсу? Одним из решений этой проблемы является отправка хостом запроса в какую-либо базу данных, чтобы определить, какие адреса он должен использовать, например DHCPv6. Чтобы понять DHCPv6, важно начать с концепции link local address в IPv6. При обсуждении размера адресного пространства IPv6, fe80:: / 10 был назван зарезервированным для link local address. Чтобы сформировать link local address, устройство с IPv6 объединяет префикс fe80:: с MAC (или физическим) адресом, который часто форматируется как адрес EUI-48, а иногда как адрес EUI-64. Например:
Устройство имеет интерфейс с адресом EUI-48 01-23-45-67-89-ab.
Этот интерфейс подключен к сети IPv6.
Устройство может назначить fe80 :: 123: 4567: 89ab в качестве link local address и использовать этот адрес для связи с другими устройствами только в этом сегменте.
Это пример вычисления одного идентификатора из другого. После того, как link local address сформирован, DHCP6 является одним из методов, который можно использовать для получения уникального адреса в сети (или глобально, в зависимости от конфигурации сети). DHCPv6 использует User Datagram Protocol (UDP) на транспортном уровне. Рисунок 4 иллюстрирует это.
Хост, который только что подключился к сети, A, отправляет сообщение с запросом. Это сообщение поступает с link local address и отправляется на multicast address ff02 :: 1: 2, порты UDP 547 (для сервера) и 546 (для клиента), поэтому каждое устройство, подключенное к одному и тому же физическому проводу, получит сообщение. Это сообщение будет включать уникальный идентификатор DHCP (DUID), который формирует клиент и использует сервер, чтобы обеспечить постоянную связь с одним и тем же устройством.
B и C, оба из которых настроены для работы в качестве серверов DHCPv6, отвечают рекламным сообщением. Это сообщение является одноадресным пакетом, направленным самому A с использованием link local address, из которого A отправляет запрашиваемое сообщение.
Хост A выбирает один из двух серверов, с которого запрашивать адрес. Хост отправляет запрос на multicast address ff02 :: 1: 2, прося B предоставить ему адрес (или пул адресов), информацию о том, какой DNS-сервер использовать, и т. д.
Сервер, работающий на B, затем отвечает ответом на изначально сформированный link local address A; это подтверждает, что B выделил ресурсы из своего локального пула, и позволяет A начать их использование.
Что произойдет, если ни одно устройство в сегменте не настроено как сервер DHCPv6? Например, на рисунке 4, что, если D - единственный доступный сервер DHCPv6, потому что DHCPv6 не работает на B или C? В этом случае маршрутизатор (или даже какой-либо другой хост или устройство) может действовать как ретранслятор DHCPv6. Пакеты DHCPv6, которые передает A, будут приняты ретранслятором, инкапсулированы и переданы на сервер DHCPv6 для обработки.
Примечание. Описанный здесь процесс называется DHCP с отслеживанием состояния и обычно запускается, когда в объявлении маршрутизатора установлен бит Managed. DHCPv6 может также работать с SLAAC, для предоставления информации, которую SLAAC не предоставляет в режиме DHCPv6 без сохранения состояния. Этот режим обычно используется, когда в объявлении маршрутизатора установлен бит Other. В тех случаях, когда сетевой администратор знает, что все адреса IPv6 будут настроены через DHCPv6, и только один сервер DHCPv6 будет доступен в каждом сегменте, сообщения с объявлением и запросом можно пропустить, включив быстрое принятие DHCPv6.
А теперь почитайте про Address Resolution Protocol - протокол разрешения IPv4-адресов
Классический стандарт связующего дерева работает нормально, но в настоящее время для современных сетей он слишком медленный 🐌
В настоящее время мы наблюдаем в наших сетях все больше и больше маршрутизации. Протоколы маршрутизации, такие как OSPF и EIGRP, намного быстрее адаптируются к изменениям в сети, чем spanning-tree. Чтобы не отставать от скорости этих протоколов маршрутизации, была создана еще одна разновидность связующего дерева... (rapid spanning tree) быстрое связующее дерево.
Rapid spanning tree - это не революция spanning tree, а его эволюция. Некоторые вещи были изменены для того, что бы ускорить процесс, но с точки зрения конфигурации - это то же самое, что классический spanning tree . Я называю оригинальное spanning tree "классическим spanning tree".
Азы Rapid spanning tree
Помните состояние портов spanning tree? У нас есть блокирующее, прослушивающее, обучающее и пересылающее состояние порта. Это первое различие между spanning tree и rapid spanning tree. Rapid spanning tree имеет только три состояния портов:
Отбрасывание;
Обучение;
Пересылка.
Вы уже знакомы с состоянием порта в режиме обучения и пересылки, но отбрасывание - это новое состояние порта. В основном он объединяет в себе блокировку и прослушивание состояния порта.
Вот хороший обзор с различными состояниями портов для spanning tree и rapid spanning tree. В таблице отображено состояние портов: активны ли они и узнают ли они MAC-адреса или нет.
Помните ли вы все остальные роли портов, которые есть у spanning tree? Давайте сделаем небольшой обзор, и будет показано отличие от rapid spanning tree.
Коммутатор с лучшим ID моста (priority + MAC -адрес) становится корневым мостом. Другие коммутаторы (non-root) должны найти кратчайший путь стоимости к корневому мосту. Это корневой порт. Здесь нет ничего нового, все это работает аналогично и в rapid spanning tree.
На каждом сегменте может быть только один назначенный порт, иначе мы получим петлю. Порт станет назначенным портом, если он сможет отправить лучший BPDU. Коммутатор А, как корневой мост, всегда будет иметь лучшие порты, поэтому все интерфейсы будут назначены. Интерфейс fa0/16 на коммутаторе B будет назначенным портом в моем примере, потому что он имеет лучший идентификатор моста, чем коммутатор C. Здесь все еще нет ничего нового по сравнению с классическим связующим деревом.
Коммутатор C получает лучшие BPDU на своем интерфейсе fa0/16 от коммутатора B, и таким образом он будет заблокирован. Это альтернативный порт, и это все еще то же самое, что и для rapid spanning tree.
Вот вам новый порт, взгляните на интерфейс fa0/17 коммутатора B. Он называется резервным портом и является новым для rapid spanning tree. Однако вы вряд ли увидите этот порт в производственной сети. Между коммутатором B и коммутатором C был добавлен хаб. Обычно (без промежуточного концентратора) оба fa0/16 и fa0/17 будут назначены портами. Из-за хаба интерфейсы fa0/16 и fa0/17 коммутатора B теперь находятся в одном домене коллизий. Fa0/16 будет выбран в качестве назначенного порта, а fa0/17 станет резервным портом для интерфейса fa0/16. Причина, по которой коммутатор B видит интерфейс fa0/17 в качестве резервного порта, заключается в том, что он получает свои собственные BPDU на интерфейсах fa0/16 и fa0/17 и понимает, что у него есть два соединения с одним и тем же сегментом. Если вы удалите хаб, то fa0/16 и fa0/17 будут назначены портами точно так же, как classic spanning tree.
BPDU отличается для rapid spanning tree. В classic spanning tree поле flags использовало только два бита:
Topology change.;
Topology change acknowledgment.;
Теперь используются все биты поля flags. Роль порта, который создает BPDU, будет добавлена с помощью поля port role, оно имеет следующие параметры:
Unknown;
Alternate / Backup port;
Root port;
Designated port.
Эта BPDU называется BPDUv2. Коммутаторы, работающие со старой версией spanning tree, проигнорируют эту новую версию BPDU. Если вам интересно ... rapid spanning tree и старое spanning tree совместимы! Rapid spanning tree способно работать с коммутаторами, работающими под управлением более старой версии spanning tree.
Что поменялось
BPDU теперь отправляются каждый hello time. Только корневой мост генерирует BPDU в classic spanning tree, и они ретранслировались non-root, если они получали его на свой корневой порт. Rapid spanning tree работает по-разному...все коммутаторы генерируют BPDU каждые две секунды (hello time). Это hello timeпо умолчанию, но вы можете его изменить.
classic spanning tree использует максимального время жизни (20 секунд) для BPDU, прежде чем они будут отброшены. Rapid spanning работает по-другому! BPDU теперь используются в качестве механизма поддержания активности, аналогичного тому, что используют протоколы маршрутизации, такие как OSPF или EIGRP. Если коммутатор пропускает три BPDU от соседнего коммутатора, он будет считать, что подключение к этому коммутатору было потеряно, и он немедленно удалит все MAC-адреса.
Rapid spanning tree будет принимать низшие BPDU. Classic spanning tree игнорирует их. Скорость перехода (время сходимости) является наиболее важной характеристикой rapid spanning tree. Classic spanning tree должно было пройти через состояние прослушивания и обучения, прежде чем оно переведет интерфейс в forwarding состояние, это занимает 30 секунд (таймер по умолчанию). Classic spanning было основано на таймерах.
Rapid spanning не использует таймеры, чтобы решить, может ли интерфейс перейти в forwarding состояние или нет. Для этого он будет использовать переговорный (negotiation) механизм. Чуть позже я покажу вам, как это работает.
Помните ли вы понятие portfast? Если мы включим portfast во время запуска classic spanning tree, оно пропустит состояние прослушивания и обучения и сразу же переведет интерфейс в forwarding состояние. Помимо перевода интерфейса в forwarding состояние, он также не будет генерировать изменения топологии, когда интерфейс переходит в состояние UP или DOWN. Мы все еще используем portfast для rapid spanning tree, но теперь он называется пограничным портом (edge port).
Rapid spanning tree может только очень быстро переводить интерфейсы в forwarding состояние на edge ports (portfast) или интерфейсы типа point-to-point. Он будет смотреть на link type, и есть только два ink types:
Point-to-point (full duplex);
Shared (half duplex).
Обычно мы используем коммутаторы, и все наши интерфейсы настроены как full duplex, rapid spanning tree видит эти интерфейсы как point-to-point. Если мы введем концентратор в нашу сеть, то у нас будет half duplex, который рассматривается как shared interface к rapid spanning-tree.
Позвольте мне описать механизм быстрой синхронизации spanning tree, используя рисунок выше. Коммутатор А сверху - это корневой мост. Коммутатор B, C и D- некорневые мосты (non-root).
Как только появится связь между коммутатором А и коммутатором B, их интерфейсы будут находиться в режиме блокировки. Коммутатор B получит BPDU от коммутатора A, и теперь будет происходить согласование, называемое синхронизацией.
После того, как коммутатор B получил BPDU от корневого моста, он немедленно блокирует все свои порты, не обозначенные в списке non-edge. Non-edge порты - это интерфейсы для подключения к другим коммутаторам, пока edge порты- интерфейсы, настроены как portfast. Как только коммутатор B блокирует свои non-edge порты, связь между коммутатором A и коммутатором B переходит в forwarding состояние.
Коммутатор B также выполнит операцию синхронизации как с коммутатором C, так и с коммутатором D, чтобы они могли быстро перейти в forwarding состояние.
Главное, что следует усвоить здесь, заключается в том, что rapid spanning tree использует этот механизм синхронизации вместо механизма "таймера", который использует classic spanning tree (прослушивание → обучение → forwarding).
Давайте увеличим масштаб механизма синхронизации rapid spanning tree, подробно рассмотрев коммутатор A и коммутатор B. Сначала интерфейсы будут заблокированы до тех пор, пока они не получат BPDU друг от друга. В этот момент коммутатор B поймет, что коммутатор A является корневым мостом, потому что он имеет лучшую информацию BPDU. Механизм синхронизации начнется, потому что коммутатор А установит proposal bit в поле flag BPDU.
Коммутатор B получает предложение от коммутатора A и понимает, что он должен что-то сделать. Он заблокирует все свои non-edge интерфейсы и запустит синхронизацию в направлении коммутатора C и коммутатора D.
Как только коммутатор B перевед свои интерфейсы в режим синхронизации, это позволит коммутатору А узнать об этом, отправив соответствующее соглашение.
Это соглашение является копией proposal BPDU, где proposal bit, был switched off, а agreement bit - switched on. Интерфейс fa0/14 на коммутаторе B теперь перейдет в режим forwarding.
Как только коммутатор A получит соглашение от коммутатора B, он немедленно переведет свой интерфейс fa0/14 в режим пересылки. А как насчет интерфейса fa0 / 16 и fa0 / 19 на коммутаторе B?
Точно такой же механизм синхронизации будет иметь место и сейчас на этих интерфейсах. Коммутатор B направит предложение по своим интерфейсам fa0/16 и fa0/19 в сторону коммутатора C и коммутатора D.
Коммутатор C и коммутатор D не имеют никаких других интерфейсов, поэтому они отправят соглашение обратно на коммутатор B.
Коммутатор B переведет свои интерфейсы fa0/16 и fa0/19 в режим forwarding, и на этом мы закончим. Этот механизм синхронизации - всего лишь пара сообщений, летающих туда-сюда, и очень быстро, это намного быстрее, чем механизм на основе таймера classic spanning tree!
Что еще нового в rapid spanning tree?
Есть еще три вещи:
UplinkFast;
Механизм изменения топологии;
Совместимость с классическим связующим деревом.
Когда вы настраиваете classic spanning tree, вы должны включить UplinkFast самостоятельно. Rapid spanning tree использует UpLinkFast по умолчанию, вам не нужно настраивать его самостоятельно. Когда коммутатор теряет свой корневой порт, он немедленно переводит свой альтернативный порт в forwarding.
Разница заключается в том, что classic spanning tree нуждалось в multicast кадрах для обновления таблиц MAC-адресов всех коммутаторов.
Нам это больше не нужно, потому что механизм изменения топологии для rapid spanning tree отличается. Так что же изменилось в механизме изменения топологии?
С classic spanning tree сбой связи вызвал бы изменение топологии. При использовании rapid spanning tree сбой связи не влияет на изменение топологии. Только non-edge интерфейсы (ведущие к другим коммутаторам), которые переходят в forwarding состояние, рассматриваются как изменение топологии. Как только коммутатор обнаружит изменение топологии это произойдет:
Он начнет изменение топологии при значении таймера, которое в два раза превышает hello time. Это будет сделано для всех назначенных non-edge и корневых портов.;
Он будет очищать MAC-адреса, которые изучаются на этих портах.;
До тех пор, пока происходит изменение топологии, во время активности таймера, он будет устанавливать бит изменения топологии в BPDU, которые отправляются из этих портов. BPDU также будет отправлен из своего корневого порта.;
Когда соседний коммутатор получит этот BPDU с установленным битом изменения топологии, произойдет следующее:
Он очистит все свои MAC-адреса на всех интерфейсах, кроме того, на котором он получил BPDU с включенным изменением топологии.;
Он запустит изменение топологии во время самого таймера и отправит BPDU на все назначенные порты и корневой порт, установив бит изменения топологии.;
Вместо того, чтобы отправлять изменения топологии вплоть до корневого моста, как это делает classic spanning tree, изменение топологии теперь быстро распространяется по всей сети.
И последнее, но не менее важное, давайте поговорим о совместимости. Rapid spanning tree и classic spanning tree совместимы. Однако, когда коммутатор, на котором работает Rapid spanning tree, связывается с коммутатором, на котором работает classic spanning tree, все функции скоростной передачи данных не будут работать!
В приведенном выше примере у меня есть три коммутатора. Между коммутатором A и коммутатором B мы запустим rapid spanning tree. Между коммутатором B и коммутатором C мы вернемся к classic spanning tree.
QoS это возможность сети обеспечить специальный уровень обслуживания для конкретных пользователей или приложений без ущерба остальному трафику. Главная цель QoS это обеспечение более предсказуемого поведения сети передачи данных при работе с тем, или иным типом трафика, путем обеспечения необходимой полосы пропускания, контролем над задержкой и джиттером и улучшением характеристик при потере пакетов. Алгоритмы QoS достигают этих целей путем ограничения трафика, более эффективным использованием каналов передачи, и назначением тех или иных политик к трафику. QoS обеспечивает интеллектуальную передачу поверх корпоративной сети, и, при правильной настройке, улучшает показатели производительности.
Политики QoS
Тип трафика
QoS
Безопасность
Когда?
Голос
Задержка меньше 150 мс в одну сторону
Шифрование на уровне передаче голоса
Понедельник - Пятница
Система планирования ресурсов предприятия
Обеспечение доступной полосы пропускания минимум 512 кб/с
Зашифрован
24 часа в сутки, 7 дней в неделю, 365 дней в году
Трафик, создаваемый программным обеспечением станков и оборудования
Обеспечение доступной полосы пропускания минимум 256 кб/с
В открытом виде
Понедельник - Пятница
Трафик от использования интернет ресурсов HTTP/HTTPS
Негарантированная доставка по принципу Best Effort
HTTP прокси сервер
Понедельник – Пятница, с 8 утра до 9 вечера.
Осуществление QoS в сетях унифицированных коммуникаций
Условно, процесс осуществления QoS в сетях Unified Communications (унифицированных коммуникаций), можно разделить на 3 этапа:
Определение типа трафика в сети и его требований. На данном этапе необходимо научить сеть определять типы трафика чтобы применять к ним те или иные QoS алгоритмы;
Сгруппировать трафик в классы с одинаковыми требованиями QoS. Например, можно определить 4 типа трафика: голос, высоко – приоритетный трафик, низко – приоритетный трафик и трафик от пользования браузером для просмотра WEB страниц;
Назначить политики QoS, применяемые к классам, определенным в п.2.
В современных корпоративных сетях, голосовой трафик всегда требует минимальную задержку. Трафик, который генерируют критически важные для бизнеса приложения требует маленькой задержки (например, информация, относящаяся к банковскому обслуживанию). Другие типы информации могут быть не так чувствительны к задержкам, например, передача файлов или электронная почта. Обычное использование интернета в личных целях на работе может быть так же ограничено или даже запрещено.
Согласно указанным принципам, можно условно выделить три QoS политики:
Без задержки: Присваивается в голосовому трафику;
Лучшее обслуживание: Присваивается к трафику с наивысшим приоритетом;
Остальное: Присваивается к низко – приоритетному и трафику web – браузеров;
Шаг 1: Определение типа трафика
Первым шагом на пути к осуществлению QoS является идентификация типов трафика в сети и определение конкретных требований каждого из типов. Перед осуществлением QoS, настоятельно рекомендуется провести аудит сети, чтобы полностью понимать как и какие приложения работают в корпоративной сети. Если осуществить политики QoS не имея полного понимания корпоративного сегмента сети, то результаты могут быть плачевными.
Далее, необходимо определить проблемы пользователей при работе с теми или иными сетевыми приложениями: например, приложение медленно работает из-за чего имеет плохую производительности работы. Необходимо измерить сетевой трафик в часы наибольшей нагрузки, используя специальные утилиты. Для понимания процессов в сети, необходимым шагом является измерение загрузки процессора каждого из единиц активного сетевого оборудования в период наибольшей загруженности, чтобы четко знать, где потенциально могут возникать проблемы.
После этого, необходимо определить бизнес цели и модели работы и составить список бизнес – требований. По итогам этих действий, каждый из пунктов списка можно сопоставить с тем или иным классом трафика.
В конце, необходимо определить уровни обслуживания которые требуются для различного вида трафика в зависимости от требуемой доступности и быстродействия.
Шаг 2: Сгруппировать трафик в классы
После идентификации сетевого трафика, необходимо использовать список бизнес требований, составленный на первом этапе, чтобы определить классы трафика.
Голосовой трафик всегда определяется отдельным классом. Компания Cisco имеет разработанные механизмы QoS для голосового трафика, например, Low latency queuing (LLQ) , цель которого заключается в контроле за тем, чтобы голос получал преимущество в обслуживании. После того как определены наиболее критичные приложения, необходимо определить классы трафика использую список бизнес требований.
Не каждое приложение имеет свой собственный класс обслуживания. Довольно много приложений с похожими требованиями к QoS группируются вместе в единый класс.
Пример классификации трафика
Типичный корпоративный ландшафт определяет 5 классов трафика:
Голос: Наивысший приоритет для трафика VoIP;
Критически важные: Небольшой набор критически важных для бизнеса приложений;
Транзакции: В данном классе присутствуют сервисы баз данных, интерактивный трафик и привилегированный сетевой трафик ;
Негарантированная доставка: Работает по принципу Best Effort, что дословно переводится как «лучшее усилие». В данный класс можно отнести интернет трафик и e-mail.
Шаг 3: Сгруппировать трафик в классы
Третьим шагом необходимо описать политики QoS для каждого из классов трафика, которые включают следующие действия:
Назначить минимальный размер гарантированной полосы пропускания;
Назначить максимальный размер полосы пропускания;
Назначить приоритеты для каждого из классов;
Использовать QoS технологии, такие как алгоритмы контроля очередей для управления перегрузками.
Рассмотрим на текущем примере определение политик QoS для каждого из классов:
Голос: Доступна полоса пропускания – 1мбит/с. Использовать метку Differentiated Services Code Poin (DSCP) со значением EF [7]. Метка EF (Expedited Forwarding) означает то, что пакеты с таким маркером получают приоритет в очереди согласно принципу наименьшей задержки. Дополнительно используется алгорит LLQ;
Критически важные: Минимальная полоса пропускания – 1мбит/с. Использовать метку Differentiated Services Code Poin (DSCP) со значением AF31 (метка в поле DSCP 011010), что обеспечивает наименьшую вероятность отбрасывания пакета. Параллельное использование алгоритма CBWFQ гарантирует необходимую полосу пропускания для маркированного трафика;
Негарантированная доставка: Максимальная полоса пропускания – 500кбит/с. Использовать метку Differentiated Services Code Poin (DSCP) со значением Default (метка в поле DSCP 000000), что обеспечивает обслуживание по умолчанию. Алгоритм CBWFQ обеспечивает «доставку по возможности», которая ниже по приоритету классов «Голос» и «Критически важные».