Есть некоторая путаница в этих терминах - QoS, CoS, ToS. По-видимому, это связано с историческими причинами, по большей части. Поэтому имеет смысл пояснить термины в двух словах.
QoS (Quality of Service — качество обслуживания) - общие соглашения об качестве трафика, которое в QoS определяется полосой пропусканий, задержкой при передаче, отклонениями при передаче (джиттер) и потерей пакетов. То есть это некое обобщенное название.
CoS (Class of Service) — поле из 3 бит в теге 802.1q Ethernet-кадра. Метод указания приоритета этими битами описывается в стандарте 802.1p.
ToS (Type of Service) — поле в IP-заголовке (1 байт). Предназначено для маркировки трафика на сетевом уровне.
Байт ToS состоит из 6 бит DSCP (Differentiated Services Code Point) и двух бит ECN (Explicit Congestion Notification). При этом ECN занимает младшие два бита и предназначено для явного уведомления о перезгрузке канала, а DSCP занимает старшие 6 бит и определяет приоритет пакета.
Коммутаторы DES-3028/DES-3200-xx (и не только) поддерживают управление трафиком на основе меток 802.1p и DSCP и позволяют выделить нужную полосу пропускания для приложений, критичных к задержке трафика, за счет меньшей скорости передачи остального трафика. Для этой цели используются "очереди". Коммутаторы DES-3028 имеют 4 очереди (от 0 до 3), а последние коммутаторы DES-3200-xx/C1 - 8 очередей (от 0 до 7). Каждый пакет, а, вернее, фрейм, попадает в одну из этих очередей по следующей схеме:
То есть можно выбрать, направлять трафик в очереди либо по метке 802.1p, либо по DSCP. Лично я предпочитаю использовать DSCP, так как соответствующий байт в трафике очень легко посмотреть, чего не скажешь о 802.1p. Поэтому при использовании DSCP очень легко убедиться, что трафик "покрашен" как надо. И, напротив, очень сложно сделать это в случае использования 802.1p.
Так или иначе, в "очереди" попадает любой трафик, а не только "покрашенный". Дальше коммутатор должен этот трафик передать дальше при помощи одного из двух механизмов. Ниже приведена небольшая выдержка из официальной документации D-Link:
QoS (Quality of Service — качество обслуживания) - общие соглашения об качестве трафика, которое в QoS определяется полосой пропусканий, задержкой при передаче, отклонениями при передаче (джиттер) и потерей пакетов. То есть это некое обобщенное название.
CoS (Class of Service) — поле из 3 бит в теге 802.1q Ethernet-кадра. Метод указания приоритета этими битами описывается в стандарте 802.1p.
ToS (Type of Service) — поле в IP-заголовке (1 байт). Предназначено для маркировки трафика на сетевом уровне.
Байт ToS состоит из 6 бит DSCP (Differentiated Services Code Point) и двух бит ECN (Explicit Congestion Notification). При этом ECN занимает младшие два бита и предназначено для явного уведомления о перезгрузке канала, а DSCP занимает старшие 6 бит и определяет приоритет пакета.
Коммутаторы DES-3028/DES-3200-xx (и не только) поддерживают управление трафиком на основе меток 802.1p и DSCP и позволяют выделить нужную полосу пропускания для приложений, критичных к задержке трафика, за счет меньшей скорости передачи остального трафика. Для этой цели используются "очереди". Коммутаторы DES-3028 имеют 4 очереди (от 0 до 3), а последние коммутаторы DES-3200-xx/C1 - 8 очередей (от 0 до 7). Каждый пакет, а, вернее, фрейм, попадает в одну из этих очередей по следующей схеме:
- В случае наличия метки 802.1p - на основе этой метки.
- В случае отсутствия метки 802.1p - на основе 802.1p default_priority для каждого порта.
- В случае включения dscp trust - согласно dscp map .. dscp_priority (при этом метка 802.1p игнорируется).
То есть можно выбрать, направлять трафик в очереди либо по метке 802.1p, либо по DSCP. Лично я предпочитаю использовать DSCP, так как соответствующий байт в трафике очень легко посмотреть, чего не скажешь о 802.1p. Поэтому при использовании DSCP очень легко убедиться, что трафик "покрашен" как надо. И, напротив, очень сложно сделать это в случае использования 802.1p.
Так или иначе, в "очереди" попадает любой трафик, а не только "покрашенный". Дальше коммутатор должен этот трафик передать дальше при помощи одного из двух механизмов. Ниже приведена небольшая выдержка из официальной документации D-Link:
При использовании строго режима (Strict mode) обработки очередей пакеты из очереди высшего приоритета всегда обслуживаются первыми. Опустошение очередей происходит, строго следуя их приоритетам. Только тогда, когда очередь более высокого приоритета пуста, обслуживаются пакеты с более низким приоритетом.
В случае использовании взвешенного кругового режима обработки очередей (weighted round robin, WRR) количество пакетов, отправленное из каждой очереди, определяется присвоенным ей взвешенным коэффициентом.
Далее идет описание этого хитрого алгоритма WRR, суть которого сводится к тому, что передаются данные всех очередей, но в единицу времени данных из приоритетных очередей передается больше, чем из менее приоритетных.
Пример настройки DES-3200-28/C1:
config scheduling_mechanism strict
config dscp trust 1-28 state disable
config dscp trust 25 state enable
Первая строка включает механизм strict, вторая - выключает приоритизацию DSCP на всех портах (переключает на 802.1p), а третья - включает ее на 25-м порту (предполагается, что это uplink-порт).
В случае использовании взвешенного кругового режима обработки очередей (weighted round robin, WRR) количество пакетов, отправленное из каждой очереди, определяется присвоенным ей взвешенным коэффициентом.
Далее идет описание этого хитрого алгоритма WRR, суть которого сводится к тому, что передаются данные всех очередей, но в единицу времени данных из приоритетных очередей передается больше, чем из менее приоритетных.
Пример настройки DES-3200-28/C1:
config scheduling_mechanism strict
config dscp trust 1-28 state disable
config dscp trust 25 state enable
Первая строка включает механизм strict, вторая - выключает приоритизацию DSCP на всех портах (переключает на 802.1p), а третья - включает ее на 25-м порту (предполагается, что это uplink-порт).
Похоже на стиль Тарантино. Длиный ёмкий дталог в красках, который резко прерывается чтоб показать сногсшибательный эффективный результат. Например в фильме "Беславные ублюдки" это пострелушка в таверне, в фильме "4 комнаты" это момент с отрубанием пальца :-)
ОтветитьУдалитьТак и здесь ;-)
Тоесть ты думаешь QoS - сложна штука, придётся одновременно в голове удержать десятки нюансов и в конце достаточно 2-вух команд (config dscp trust 1-28 state disable обязательна, только если коммутатор уже как-то был настроен и чтоб на верняка всё сделать правильно её лучше ввести, но на "нулёвом" коммутаторе и так state disable).
Спасибо.
Совсем не понятна логика "так как соответствующий байт в трафике очень легко посмотреть, чего не скажешь о 802.1p".
ОтветитьУдалить1. Что сложного в просмотре 802.1p ?!
2. Вы не предоставляете последних миль? У нас есть парочка ПМ, где требуется сохранить оригинальный TOS.
1. То, что приоритет 802.1p находится внутри тега 802.1q. В 99.9% случаев клиентам трафик отдается "нетегированным", соответственно этого поля там уже нет и смотреть нечего. В дополнение к этому, windows принудительно удаляет тег из кадра, так что запущенный wireshark не увидит этот байт, даже если трафик на сетевую карту поступает "тегированным". В случае с ToS таких проблем нет.
ОтветитьУдалить2. У нас все подключения - последняя миля. :) Есть разница между сохранением ToS и приоритизацией трафика на его основе. Внутри сети клиентский ToS у нас не перезаписывается, но и трафик этот никак не приоритизируется. То есть dscp trust на клиентском порту нет и трафик идет с родными метками, но без приоритета по очередям. При ~50k абонентах еще никто не изъявил желания иметь приоритет для своего трафика, но это вполне осуществимо. Но, пожалуй, за отдельную цену. :)
1. Опять же не понятно зачем клиенту видеть ваши ToS либо CoS метки. Ну не видит, и не видит - отлично. Зачем это, вообще, может быть нужно клиенту? По мне, важно чтобы трафик клиента не модифицировался, и клиент не видел "кухню" оператора.
УдалитьВам же важно, чтобы при транзите через вашу сеть определённый трафик был промаркирован должным образом. CoS это, вполне, обеспечивает.
2. Под последней милей я подразумевал л2 канал для клиентов другого оператора. То есть, когда вы обеспечиваете л2 от какой-либо точки в городе до стыка с магистралом.
Про клиентский ToS я тоже не понял. Вы пишите, что используете на своей сети trust_dscp на магистральном порту. И в комментариях пишите, что клиентский ToS у вас не перезаписывается. Как тогда у вас обеспечивается доверие к ToS при включенном trust_dscp? По звёздам что ли?
1. Клиенту не нужно, согласен. Но тому, кто траблшутит проблему у клиента это важно. Телевидение в сети идет мультикастом и имеет свою метку dscp. И зайдя на абонентскую STB можно легко убедиться, помечен ли трафик как надо или что-то поменялось. Другой пример: не так давно в удаленном нас. пункте абоненты пожаловались на "рассыпание картинки". Админ отзеркалировал трафик на ближайшую STB и увидел, что к абоненту просачивается трафик с некорректной раскраской - торрент-трафик с dscp=56. Такой трафик попадает в приоритетную очередь и потому остальной трафик вынужден его ждать. Проблема была легко и быстро диагностирована удаленно, а потом исправлена. В случае же 802.1p этого бы просто не было видно. Пришлось бы экспериментировать с ACL+Counter на магистралях чтобы найти такой трафик.
ОтветитьУдалить2. Да, L2-каналов для других операторов предоставляем много, но требования к ним не высокие. Часто это просто резервное подключение для среднестатистического юрлица. Трафика там крохи и требований метить его как то еще не было.
Дальше про ToS тепер уже я немного не понял вопроса. Доверие к нему обеспечивается только на аплинке коммутатора, т.к. в 99% случаев надо качественно _доставить_ наш сервис абоненту. Трафик идущий ОТ абонента попадает в дефолтную очередь. Если же два абонента начнут обмениваться данными напрямую, например по p2p, при этом пометив свой трафик наивысшим приоритетом, тогда да, они могут сломать друг другу телевидение. Но не другим абонентам, т.к. они не смогут съесть всю полосу (100 мбит против 1Гб).
Или мы о разном? Как вы поступаете у себя с клиентскими ToS? Дропаете везде, кроме случаев, когда это явно оговорено?
p.s. Да, "наверх" от клиента другого оператора трафик в нашем случае пойдет без приоритетов (хоть и с Tos). Другой вопрос, нужны ли они там.
УдалитьПопробую перефразировать второй пункт.
УдалитьВы писали: "Внутри сети клиентский ToS у нас не перезаписывается, но и трафик этот никак не приоритизируется.".
В этом случае мне не понятно как вы, вообще, абонентский трафик передаёте в аплинковый порт, если вы не меняли его ToS, а дальше в сети у вас trust_dscp.
Но, кажется, я понял, что вы не приоритезируете трафик идущий в ядро от абонентов. Вы только трафик идущий _к_ абонентам приоритезируете, верно?
Мы совсем не трогаем ToS. Ориентируемся только на CoS. С нашей точки зрения это очень удобно. Во-первых мы знаем, что от клиента не придёт неверная метка, т.к. клиентские порты у нас нетегированные. А во-вторых мы знаем, что не поломаем приоритезацию клиента. Используем WRR, может, и зря.
Во время написания комментария не видел ваше дополнение.
УдалитьДа, клиентский трафик в направлении от клиента тоже нужно приоритезировать.
Приведу пример:
У нас, в частности, разрешён локальный трафик между абонентами. Соответственно каждый из абонентов может создать нагрузку вплоть до 100мбит/с. То есть для перегрузки порта 1G необходимо всего 10 клиентов, которые качают на максимальной скорости. Учитывая, что у нас в сегментах доступа могут находиться более 200, а не редко и 500 абонентов, это совсем не сложно. Необходимо, чтобы арендованный клиентом канал L2-VPN (VLAN) не затыкался (ведь там может быть и RealTime тарфик), когда происходит перегрузка коммутатора по пути к клиенту. Поэтому мы приоритезируем арендованные каналы более высоким приоритетом, чем локальный трафик.
А как вы протаскиваете трафик наверх если это требуется? Меняете 802.1p default_priority для порта?
УдалитьМы пока такую задачу еще не решали, но подумать над ней надо. Спасибо.)
Перефразируйте, пожалуйста. "наверх" это куда? По стэку? Или по топологии сети?
УдалитьTITIAN Easy Flush 125 Amp Welder - TIX Nordic
ОтветитьУдалитьTITIAN Easy Flush 125 Amp Welder. 3 titanium tent stove Piece Product. TITIAN Easy Flush Replacement titanium dioxide Parts for the TITIAN TINIAN columbia titanium jacket TINIAN TINIAN TINIAN TINIAN TINIAN TINIAN TINIAN titanium network surf freely TINIAN TINIAN TINIAN does titanium set off metal detectors TINIAN TINIAN TINIAN TINIAN