Сети Для Самых Маленьких
  • Сети для самых маленьких
  • 0. Планирование
    • 0. Документация сети
    • 1. Схемы сети
    • 2. IP-план
    • 3. Список VLAN
    • 4. План подключения оборудования по портам
    • 5. Заключение
  • 1. Подключение к оборудованию cisco
    • 0. Среда
    • 1. Способы подключения
    • 2. Управление по консоли
    • 3. Первичная настройка
    • 4. Настройка доступа
    • 5. Сброс пароля
  • 2. Коммутация
    • Теория
      • СКС, ЛВС, LAN
      • IP-адресация
      • Широковещательный домен
      • OSI
      • Путь пакета
      • VLAN
      • FAQ
    • Практика
      • Порты доступа (access)
      • Транковые порты (trunk)
      • Сеть управления и первичная настройка
      • Резюме
  • 3. Статическая маршрутизация
    • InterVlan Routing
    • Планирование расширения
    • Принципы маршрутизации
    • Настройка
    • Дополнительно
    • Материалы выпуска
  • 4. STP
    • Широковещательный шторм
    • STP
    • RSTP
    • MSTP
    • Агрегация каналов
    • Port security
    • Практика
    • Материалы выпуска
  • 5. ACL и NAT
    • Access Control List
      • Практика
    • NAT
      • Практика
    • Материалы выпуска
    • Бонусы
    • Спасибы
  • 6. Динамическая маршрутизация
    • Теория протоколов динамической маршрутизации
    • OSPF
      • Теория
      • Теория-2
      • Практика OSPF
      • Задача 1
      • Практика. Продолжение
      • Задача 2
      • Задача 3
    • EIGRP
      • Теория
      • Практика
      • Задача 4
    • Настройка передачи маршрутов между различными протоколами
    • Задача 5
    • Маршрут по умолчанию
    • Задача 6
    • Полезные команды для траблшутинга
    • Задача 7
    • Материалы
    • Полезные ссылки
  • 7. VPN
    • Введение в VPN
    • GRE
      • Абстрактная топология
      • Настройка
      • Механизм работы протокола
      • Итого
    • IPSec
      • Теория
        • Security Association
        • Трансформ-сет
      • Режимы работы IPSec
        • Туннельный режим работы IPSec
        • Практика
          • Настройка на локальной стороне
          • Настройка на обратной стороне
          • Настройка. Завершение
        • Задача 1
        • Теория
        • Задача 2
        • Транспортный режим работы IPSec
        • Задача 3
    • GRE over IPSec
      • Практика
      • Теория
      • Задача 4
      • Задача 5
    • IPSec VTI
    • DMVPN
      • Теория и практика DMVPN
      • OSPF
        • Практика
        • Теория
      • IPSec
      • NAT-Traversal
      • Задача 6
    • TShoot IPSec
    • MTU
    • Материалы выпуска
    • Полезные ссылки
  • 8. BGP и IP SLA
    • Автономные системы
    • PI и PA адреса
    • BGP
      • Теория
      • Установление BGP-сессии и процедура обмена маршрутами
      • Настройка BGP и практика
        • Настройка BGP и практика
        • Задача 1
        • Full View и Default Route
        • Задача 2
        • Looking Glass и другие инструменты
        • Control Plane и Data Plane
        • Выбор маршрута
        • Задача 3
      • Управление маршрутами
        • AS-Path ACL
        • Prefix List
        • Route Map
        • Задача 4
      • Балансировка и распределение нагрузки
        • Балансировка нагрузки
        • Задача 5
        • Распределение нагрузки
          • Исходящий
          • Задача 6
          • Входящий
        • AS-Path Prepend
        • MED
        • Анонс разных префиксов через разных ISP
        • BGP Community
        • Задача 7
        • Общая таблица по видам балансировки и распределения нагрузки
    • PBR
      • Теория
      • PBR
      • Практика
      • Задача 8
    • IP SLA
      • Настройка
      • Задача 9
      • Задача 10
    • Полезные ссылки
  • 8.1 IBGP
    • IBGP
    • Различия IBGP и EBGP
    • Проблема Эн квадрат
      • Route Reflector
        • Правила работы RR
        • Практика RR
          • Проблема резервирования
      • Конфедерации
    • Атрибуты BGP
      • Хорошо известные обязательные (Well-known Mandatory)
      • Хорошо известные необязательные (Well-known Discretionary)
      • Опциональные передаваемые/транзитивные (Optional Transitive)
      • Опциональные непередаваемые/нетранзитивные (Optional Non-transitive)
      • Community
        • Теория Community
        • Задача 7
        • Практика Community
        • Задача 8
        • Задача 9
      • Задача 6
    • Материалы выпуска
    • Задача 1
    • Задача 2
    • Практика
      • EBGP
      • iBGP
      • iBGP
      • Задача 3
      • Настройка внутренней маршрутизации. OSPF
      • Настраиваем BGP
      • Задача 4
      • Что мы можем улучшить?
      • Задача 5
      • Задача 6
      • Задача 7
      • Задача 8
      • Задача 9
    • Послесловие
  • 9. Multicast
    • Общее понимание Multicast
      • Пример I
      • Пример II
    • IGMP
      • Теория IGMP
      • Querier
      • Ещё пара слов о других версиях IGMP
      • Повторим ещё раз
      • И ещё раз
    • PIM
      • PIM Dense Mode
      • PIM Sparse Mode
      • Чтобы разобраться с тем, что такое PIM, обратимся к сети гораздо более сложной
      • Разбор полётов
        • RP
        • Бритва Оккама или отключение ненужных ветвей
        • SPT Switchover — переключение RPT-SPT
        • Задача 1
        • Задача 2
      • DR, Assert, Forwarder
      • Выбор RP
      • Завершение
    • SSM
    • BIDIR PIM
    • Мультикаст на канальном уровне
      • Мультикастовые MAC-адреса
      • IGMP Snooping
      • Задача 3
      • IGMP Snooping Proxy
      • Multicast VLAN Replication
    • Заключение
  • 10. Базовый MPLS
    • Что не так с IP?
    • Заголовок MPLS
    • Пространство меток
    • Что такое MPLS
    • Передача трафика в сети MPLS
    • Терминология
    • Распространение меток
      • Методы распространение меток
        • DU против DoD
        • Ordered Control против Independent Control
        • Liberal Label Retention Mode против Conservative Label Retention Mode
        • PHP
      • Протоколы распространения меток
        • LDP
          • Практика
        • Применение чистого MPLS в связке с BGP
        • RSVP-TE
          • Практика
    • ВиО
    • Полезные ссылки
    • Спасибы
  • 11. MPLS L3VPN
    • VRF, VPN-Instance, Routing Instance
      • VRF-Lite
    • MPLS L3VPN
      • Data Plane или передача пользовательских данных
      • Роль меток MPLS
        • Транспортная метка
        • Сервисная метка
      • Терминология
      • Control Plane или передача служебной (маршрутной) информации
      • Протоколы маршрутизации
      • MBGP
        • Route Distinguisher
        • Route Target)
    • Практика
      • VRF-Lite
      • MPLS L3VPN
      • Взаимодействие между VPN
    • Трассировка в MPLS L3VPN
    • Доступ в Интернет
      • NAT на CE
        • Практика
        • Теория
        • Повторим шаги настройки
      • VRF Aware NAT
        • Практика
        • Теория
      • Common Services
    • ВиО
    • Полезные ссылки
  • 12. MPLS L2VPN
    • О технологиях L2VPN
    • VPWS
      • Data Plane
      • Control Plane
      • Практика
      • Теория
      • Виды VPWS
    • VPLS
      • Data Plane
      • Control Plane
      • VPLS Martini Mode (targeted LDP)
        • Практика
        • Теория
      • VPLS Kompella Mode (BGP)
        • Обнаружение соседей или Auto-Discovery
        • Передача префиксов
        • Распределение меток и механизм Label Block
        • Практика
        • Теория
      • Martini vs. Kompella
      • Иерархический VPLS (H-VPLS)
        • Практика H-VPLS
        • Теория
    • Проблемы VPLS
    • Полезные ссылки
    • Спасибы
  • 12.1. MPLS EVPN
    • Вспоминаем VPLS
    • Базовая часть технологии EVPN
    • Лаборатория для тестов и конфигурации
    • Маршруты EVPN
      • Маршрут типа 3 (Inclusive Multicast Ethernet Tag Route)
      • Маршрут типа 2 (MAC/IP Advertisement Route)
        • Изучение MAC-адресов
      • Маршрут типа 1 (Ethernet Auto-Discovery Route)
        • Автоматический поиск multihomed PE и ESI label
        • MAC Mass Withdrawal
        • Aliasing label
      • Маршрут типа 4 (Ethernet Segment Route)
        • Механизм выбора DF
    • L3-функционал в EVPN
      • IRB synchronisation
      • Маршрутизация между bridge-доменами
      • Выход в другие VRF и внешние сети
    • Зачем это всё-таки нужно?
    • Заключение
  • 12.2. EVPN Multihoming
    • Практический пример
    • Проблемы Multihoming-га.
    • Что такое DF и зачем он нужен?
    • Зачем нужен маршрут типа 1 per-ESI?
    • Зачем нам маршрут типа 1, сгенерированный per-EVI?
    • А нужен ли нам MC-LAG в EVPN?
    • Заключение
  • 13. MPLS Traffic Engineering
    • Предпосылки появления MPLS TE
    • Принципы работы MPLS Traffic Engineering
    • Способы направления трафика в TE-туннель
    • Способы управления туннелями
  • 14. Packet Life
    • 0. Коротко о судьбе и пути пакета
    • 1. Уровни и плоскости
      • Forwarding/Data Plane
      • Control Plane
      • Management Plane
      • Краткий итог
    • 2. История способов обработки трафика
      • Что с тобой не так, IP?!
      • О дивный новый мир
    • 3. Типов-чипов
      • CPU — Central Processing Unit
      • RAM — Random Access Memory
      • CAM — Content-Addressable Memory
      • TCAM — Ternary Content-Addressable Memory
      • ASIC — Application Specific Integrated Circuit
      • Programmable ASIC
      • FPGA — Field Programmable Gate Array
      • NP — Network Processor
    • 4. Аппаратная архитектура коммутирующего устройства
      • Общая шина
      • Управляющий модуль
      • Интерфейсный модуль или линейная карта
        • PIC — Physical Interface Card
        • FE — Forwarding Engine
        • QoS или TM — Traffic Management
        • SerDes — Serializer, Deserializer
        • Распределённая плоскость управления (Distributed Control Plane)
      • Фабрика коммутации
    • 5. Путешествие длиною в жизнь
      • Транзитные пакеты
      • Локальные пакеты
    • Заключение
    • Спасибы
  • 15. QoS
    • 0. Чем определяется QoS?
      • Потери
      • Задержки
      • Джиттер
      • Неупорядоченная доставка
      • Полоса пропускания
    • 1. Три модели обеспечения QoS
      • Best Effort (BE)
      • IntServ
      • DiffServ
    • 2. Механизмы DiffServ
    • 3. Классификация и маркировка
      • Behavior Aggregate
      • Interface-based
      • Multi-Field
      • Маркировка внутри устройства
      • Рекомендации IETF (категории трафика, классы сервиса и модели поведения)
      • Короткий итог по классификации
    • 4. Очереди
    • 5. Предотвращение перегрузок
      • Tail Drop и Head Drop
      • RED — Random Early Detection
      • WRED — Weighted Random Early Detection
    • 6. Управление перегрузками
      • FIFO — First In, First Out
      • PQ — Priority Queuing
      • FQ - Fair Queuing
      • RR — Round-Robin
      • Короткий итог про механизмы диспетчеризации
    • 7. Ограничение скорости
      • Traffic Policing
      • Traffic Shaping
      • Шейпинг против полисинга
      • Практика Полисинг и шейпинг
      • Механизмы Leaky Bucket и Token Bucket
        • Алгоритм Leaky bucket
        • Алгоритм Token Bucket
      • Короткий итог по ограничению скорости
    • 8. Аппаратная реализация QoS
    • Полезные ссылки
    • Спасибы
  • Инструкция для контрибьютеров
Powered by GitBook
On this page
  • IPv4 TOS
  • Практика по классификации DSCP
  • IPv6 Traffic Class
  • MPLS Traffic Class
  • Режимы работы
  • Практика классификации MPLS Traffic Class
  • Ethernet 802.1p
  1. 15. QoS
  2. 3. Классификация и маркировка

Behavior Aggregate

Previous3. Классификация и маркировкаNextInterface-based

Last updated 6 years ago

В BA используется очень простая классификация — вижу цифру — понимаю класс.

Так что же за цифра? И в какое поле она записывается?

  • IPv4 TOS/IPv6 Traffic Class

  • MPLS Traffic Class

  • Ethernet 802.1p

    В основном классификация происходит по коммутирующему заголовку. Коммутирующим я называю заголовок, на основе которого устройство определяет, куда отправить пакет, чтобы он стал ближе к получателю. То есть если на маршрутизатор пришёл IP-пакет, анализируется заголовок IP и поле DSCP. Если пришёл MPLS, анализируется — MPLS Traffic Class. Если на обычный L2-коммутатор пришёл пакет Ethernet+VLAN+MPLS+IP, то анализироваться будет 802.1p (хотя это можно и поменять).

IPv4 TOS

Поле QoS сопутствует нам ровно столько же, сколько и IP. Восьмибитовое поле TOS — Type Of Service — по задумке должно было нести приоритет пакета. Ещё до появления DiffServ (INTERNET PROTOCOL) описывал поле так:

IP Precedence (IPP) + DTR + 00.

То есть идёт приоритет пакета, далее биты требовательности к Delay, Throughput, Reliability (0 — без требований, 1 — с требованиями).

Последние два бита должны быть нулём.

Приоритет определял следующие значения

111 — Network Control 110 — Internetwork Control 101 — CRITIC/ECP 100 — Flash Override 011 — Flash 010 — Immediate 001 — Priority 000 — Routine

Левые три бита остались IP Precedence, четыре следующих превратились в TOS после добавления бита Cost.

Вот как следовало читать единицы в этих битах TOS:

  • D — «minimize delay»,

  • T — «maximize throughput»,

  • R — «maximize reliability»,

  • C — «minimize cost».

Туманные описания не способствовали популярности этого подхода.

Системный подход к QoS на всём протяжении пути отсутствовал, чётких рекомендаций, как использовать поле приоритета тоже не было, описание битов Delay, Throughput и Reliability было крайне туманным.

Вместо битов IPP и DTRC ввели шестибитовое поле DSCP — Differentiated Services Code Point, два правых бита не были использованы.

С этого момента именно поле DSCP должно было стать главной маркировкой DiffServ: в него записывается определённое значение (код), которое в пределах данного DS-домена характеризует конкретный класс сервиса, необходимый пакету и его приоритет отбрасывания. Это та самая цифра.

Все 6 бит DSCP администратор может использовать, как ему заблагорассудится, разделяя максимум до 64 классов сервиса. Однако в угоду совместимости с IP Precedence за первыми тремя битами сохранили роль Class Selector.

То есть, как и в IPP, 3 бита Class Selector позволяют определить 8 классов.

Однако это всё же не более, чем договорённость, которую в пределах своего DS-домена, администратор может легко игнорировать и использовать все 6 бит по усмотрению.

Но и это не стоит воспринимать как неоспоримую истину.

Если первые три бита определяют класс трафика, то следующие три используются для указания приоритета отбрасывания пакета (Drop Precedence или Packet Loss Priority - PLP).

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

Биты ECN…

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

Не помешает немного практики.

Схема та же.

Для начала просто отправим запрос ICMP:

Linkmeup_R1#ping ip 172.16.2.2 source 172.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.2, timeout is 2 seconds:
Packet sent with a source address of 172.16.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Linkmeup_R1. E0/0.

А теперь с установленным значением DSCP:

Linkmeup_R1#ping ip 172.16.2.2 source 172.16.1.1 tos 184
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.2, timeout is 2 seconds:
Packet sent with a source address of 172.16.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Значение 184 — это десятичное представление двоичного 10111000. Из них первые 6 бит — это 101110, то есть десятичные 46, а это класс EF.

Таблица стандартных значений TOS для удобных попингушек:

Ниже по тексту в главе Рекомендации IETF я расскажу, откуда взялись и эти цифры и названия.

Linkmeup_R2. E0/0

Любопытное замечание: адресат попингушек в ICMP Echo reply устанавливает такое же значение класса, как было в Echo Request. Это логично — если отправитель послал пакет с определённым уровнем важности, то, очевидно, он хочет получить его гарантировано назад.

Linkmeup_R2. E0/0

IPv6 Traffic Class

IPv6 мало чем в вопросе QoS отличается от IPv4. Восьмибитовое поле, называемое Traffic Class, также разбито на две части. Первые 6 бит — DSCP — играют ровно ту же роль. Да, появился Flow Label. Говорят, что его можно было бы использовать для дополнительной дифференциации классов. Но применения в жизни эта идея пока нигде не нашла.

MPLS Traffic Class

DiffServ нельзя было не распространить на него.

С ним есть одна проблема — его длина три бита, что ограничивает число возможных значений до 9. Это не просто мало, это на 3 двоичных порядка меньше, чем у DSCP.

Вообще согласитесь, ситуация странная — 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. Для целей DiffServ используется только верхний. Существуют три разных сценария перемаркировки при продвижении пакета из одного чистого IP-сегмента в другой через MPLS-домен:

  1. Uniform Mode

  2. Pipe Mode

  3. Short-Pipe Mode

Режимы работы

Uniform Mode

Pipe Mode

Short-Pipe Mode

Практика классификации MPLS Traffic Class

Схема та же:

В схеме сети linkmeup есть переход из IP в MPLS на Linkmeup_R2.

Посмотрим, что происходит с маркировкой при пинге ping ip 172.16.2.2 source 172.16.1.1 tos 184.

Linkmeup_R2. E0/0.

Итак, мы видим, что изначальная метка EF в IP DSCP трансформировалась в значение 5 поля EXP MPLS (оно же Traffic Class, помним это) как VPN-заголовка, так и транспортного.

Тут мы являемся свидетелями режима работы Uniform.

Ethernet 802.1p

Отсутствие поля приоритета в 802.3 (Ethernet) находит своё объяснение в том, что Ethernet изначально планировался исключительно как решение для LAN-сегмента. За скромные деньги можно получить избыточную пропускную способность, и узким местом всегда будет аплинк — не за чем беспокоиться о приоритизации.

Однако очень скоро стало ясно, что финансовая привлекательность Ethernet+IP выводит эту связку на уровень магистрали и WAN. Да и сожительство в одном LAN-сегменте торрентов и телефонии нужно разруливать. По счастью к этому моменту подоспел 802.1q (VLAN), в котором выделили 3-битовое (опять) поле под приоритеты. В плане DiffServ это поле позволяет определить те же 8 классов трафика.

При получении пакета сетевое устройство DS-домена в большинстве случаев берёт в рассмотрение тот заголовок, который оно использует для коммутации:

  • Ethernet-коммутатор — 802.1p

  • MPLS-узел — MPLS Traffic Class

  • IP-маршрутизатор — IP DSCP

    Хотя это поведение можно и изменить: Interface-Based и Multi-Field классификация. А можно иногда даже явно сказать, в поле CoS какого заголовка смотреть.

Чуть позже в (Type of Service in the Internet Protocol Suite) поле TOS немного переопределили:

Поэтому в контексте DiffServ поле TOS ещё раз переопределили в (Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers):

также замечу, что согласно рекомендациям IETF, чем выше значение, записанное в CS, тем требовательнее этот трафик к сервису.

Двухбитовое поле ECN появилось только в (Explicit Congestion Notification). Поле было определено с благой целью — сообщить конечным хостам в явном виде о том, что кто-то по пути испытывает перегрузку. Например, когда в очередях маршрутизатора задерживаются пакеты надолго и заполняют их, например, на 85%, он меняет значение ECN, сообщая конечному хосту, что нужно помедленнее — что-то вроде Pause Frames в Ethernet. В этом случае отправитель должен уменьшить скорость передачи и снизить нагрузку на страдающий узел.

При этом теоретически поддержка этого поля всеми транзитными узлами не обязательна. То есть использование ECN не ломает сеть без его поддержки. Цель благая, но прежде применения в жизни ECN особо не находил. В наше время мега- и гиперскейлов на эти два бита смотрят с .

ECN является одним из механизмов предотвращения перегрузок, о которых .

Концепция DiffServ была ориентирована на IP-сети с маршрутизацией на основе IP-заголовка. Вот только незадача — через 3 года опубликовали (Multiprotocol Label Switching Architecture). И MPLS начал захватывать сети провайдеров.

По счастливой случайности в MPLS заложили трёхбитовое поле EXP на всякий экспериментальный случай. И несмотря на то, что уже давным-давно в («EXP» Field Renamed to «Traffic Class» Field) официально стало полем Traffic Class, по инерции его называют ИЭксПи.

Учитывая, что часто MPLS Traffic Class наследуется из DSCP IP-пакета, имеем архивацию с потерей. Или же… Нет, вы не хотите этого знать… . Использует комбинацию Traffic Class + значение метки.

(это просто выдержка из ).

Это плоская модель End-to-End. На Ingress PE мы доверяем IP DSCP и копируем (строго говоря, отображаем, но для простоты будем говорить «копируем») его значение в MPLS EXP (как туннельный, так и VPN заголовки). На выходе с Ingress PE пакет уже обрабатывается в соответствии со значением поля EXP верхнего заголовка MPLS. Каждый транзитный P тоже обрабатывает пакеты на основе верхнего EXP. Но при этом он может его поменять, если того хочет оператор. Предпоследний узел снимает транспортную метку (PHP) и копирует значение EXP в VPN-заголовок. Не важно, что там стояло — в режиме Uniform, происходит копирование. Egress PE снимая метку VPN, тоже копирует значение EXP в IP DSCP, даже если там записано другое. То есть если где-то в середине значение метки EXP в туннельном заголовке изменилось, то это изменение будет унаследовано IP-пакетом.

Если же на Ingress PE мы решили не доверять значению DSCP, то в заголовки MPLS вставляется то значение EXP, которое пожелает оператор. Но допустимо и копировать те, что были в DSCP. Например, можно переопределять значения — копировать всё, вплоть до EF, а CS6 и CS7 маппировать в EF. Каждый транзитный P смотрит только на EXP верхнего MPLS-заголовка. Предпоследний узел снимает транспортную метку (PHP) и копирует значение EXP в заголовок VPN. Egress PE сначала производит обработку пакета, опираясь на поле EXP в заголовке MPLS, и только потом его снимает, при этом не копируетзначение в DSCP. То есть независимо от того, что происходило с полем EXP в заголовках MPLS, IP DSCP остаётся неизменным. Такой сценарий можно применять, когда у оператора свой домен Diff-Serv, и он не хочет, чтобы клиентский трафик как-то мог на него влиять.

Этот режим вы можете рассматривать вариацией Pipe-mode. Разница лишь в том, что на выходе из MPLS-сети пакет обрабатывается в соответствие с его полем IP DSCP, а не MPLS EXP. Это означает, что приоритет пакета на выходе определяется клиентом, а не оператором. Ingress PE не доверяет IP DSCP входящих пакетов Транзитные P смотрят в поле EXP верхнего заголовка. Предпоследний P снимает транспортную метку и копирует значение в VPN-метку. Egress PE сначала снимает метку MPLS, потом обрабатывает пакет в очередях. Объяснение от .

RFC 1349
RFC 2474
Далее
RFC 3168
новым интересом
ниже
pcapng
Подробнее
pcapng
Файл конфигурации DSCP классификации
RFC 3031
RFC 5462
L-LSP
статьи
Файл конфигурации тот же
pcapng
RFC 791
cisco