поведение QoS при перегрузке

Reply to поведение QoS при перегрузке on Sat, 14 Feb 2026 22:10:37 GMT

Ramblin Tech — Sat, 14 Feb 2026 22:10:37 GMT

«
Иными словами, настроенная приоритезация трафика, постановка в очередь и т. д. не срабатывают, пока не возникнет перегрузка, верно?
» Рискуя углубиться в детали... рассмотрим коммутатор/маршрутизатор с NPU, который применяет все политики QoS на выходе на входе. То есть на входном интерфейсе NPU пропускает заголовок пакета через политику QoS на входе, ищет следующий прыжок и выходной интерфейс, а затем классифицирует пакет в соответствии с политикой на выходе и помещает его в соответствующую аппаратную очередь VOQ для его класса. Все это происходит без
априорного
знания текущего состояния перегрузки интерфейса выхода. Затем планировщик NPU сериализует для передачи все пакеты во всех VOQ для этого интерфейса. Если перегрузки нет, то планировщик работает по принципу FIFO. Если перегрузка есть, то планировщик сериализует в соответствии с политикой очередей QoS на выходе. В любом случае пакеты по-прежнему классифицируются и помещаются в очередь для приоритезации планировщиком, независимо от перегрузки интерфейса на выходе. Отказ от ответственности: я давно работаю в CSCO. Неправильные ответы — моя собственная вина, так как они не генерируются ИИ.

Reply to поведение QoS при перегрузке on Sat, 14 Feb 2026 22:10:36 GMT

Joseph W. Doherty — Sat, 14 Feb 2026 22:10:36 GMT

«Я
раньше не видел тег спойлера на этих форумах. Это вы его добавили?» Я не первый, кто его использует. На самом деле, я «открыл» для себя эту функцию, увидев ее в другом посте (она находится в дополнительных элементах в верхней части поля для ответа [хотя она не отображается в браузере моего телефона]). «Если да, то очередь будет очень короткой, поэтому нет необходимости в приоритезации, так как такая очередь будет длиться микросекунды, не так ли?» Обычно нет, но если ситуация требует чего-то вроде переключения, что также относится к сфере экономии микросекунд, то, возможно, это может быть необходимо.

Reply to поведение QoS при перегрузке on Sat, 14 Feb 2026 22:10:35 GMT

Mitrixsen — Sat, 14 Feb 2026 22:10:35 GMT

Это очень хорошо сформулированный ответ, большое спасибо. Я раньше не видел тег «спойлер» на этих форумах. Это вы его добавили? ![Mitrixsen_0-1733663326508.png] Если да, то очередь будет очень короткой, поэтому нет необходимости в приоритезации, так как такая очередь будет длиться микросекунды, не так ли?

Reply to поведение QoS при перегрузке on Sat, 14 Feb 2026 22:10:34 GMT

stephan.l.martin1 — Sat, 14 Feb 2026 22:10:34 GMT

Кроме того, при работе с QoS и попытках обеспечить действительный результат QoS необходимо помнить, что определенные потоки трафика более интенсивны в одном направлении, чем в другом, а также когда и где необходимо контролировать или формировать трафик. Веб-трафик обычно составляет 20/80 (TX/RX), причем большая часть данных возвращается из относительно небольшого запроса, в то время как голосовые/видеопотоки, как правило, стандартизированы и симметричны.

Reply to поведение QoS при перегрузке on Sat, 14 Feb 2026 22:10:33 GMT

M02@rt37 — Sat, 14 Feb 2026 22:10:33 GMT

Здравствуйте
[, @Mitrixsen] Вы правы в том, что механизмы QoS, такие как CBWFQ и LLQ, действуют только в периоды перегрузки... Когда пропускная способность достаточна для всего трафика, пакеты пересылаются с использованием механизма FIFO по умолчанию, при котором пакеты обрабатываются в порядке их поступления. Это связано с тем, что при отсутствии перегрузки нет необходимости приоритезировать или ставить в очередь трафик; все пакеты могут передаваться сразу по мере их поступления. Приоритезация QoS гарантирует, что критически важный трафик, такой как голос или видео, обрабатывается в первоочередном порядке только в случае перегрузки канала, что позволяет поддерживать качество обслуживания для чувствительных приложений при высокой загрузке. Что касается пороговых значений перегрузки, вы также правы. Перегрузка определяется не только пропускной способностью канала. Хотя канал 1 Гбит/с теоретически поддерживает трафик до 1 Гбит/с, фактический порог перегрузки может зависеть от производительности устройств, подключенных к каналу. Например, если устройство имеет пропускную способность или емкость очереди только 250 Мбит/с, перегрузка произойдет, когда трафик превысит этот предел, даже если само соединение может обрабатывать больше. Это демонстрирует важность учета
как
пропускной способности соединения, так и характеристик производительности сетевых устройств при проектировании и управлении сетью. С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените .ı|ı.ı|ı.

Reply to поведение QoS при перегрузке on Sat, 14 Feb 2026 22:10:32 GMT

Joseph W. Doherty — Sat, 14 Feb 2026 22:10:32 GMT

«
Если кто-то настраивает классы QoS и устанавливает приоритеты для различных типов трафика, например, настраивает CBWFQ для любых данных, кроме голосовых, и LLQ для голосовых данных, то эти настройки не должны вступать в силу, пока объем трафика не превысит пропускную способность канала или устройства, верно?
» Это зависит от политики QoS и архитектуры устройства. Например, в политике CBWFQ со встроенными полисерами пакеты могут отбрасываться даже при наличии достаточной пропускной способности. Встроенные формирователи могут ставить трафик в очередь, опять же, даже при наличии достаточной физической пропускной способности. Внутренняя обработка и пропускная способность устройства — это отдельная проблема. «Тогда правильно сказать, что если нет перегрузки, устройства будут пересылать полученный трафик, используя механизм FIFO, верно?
» Ну, да и нет. И CBWFQ, и FIFO ставят трафик в очередь, если нет перегрузки, то нет очередей, но трафик, возможно, проходит через ту же логику (например, статистика CBWFQ все равно должна считать пакеты, которые логически прошли через класс, даже если такой трафик никогда не ставился в очередь). «
Таким образом, в каком бы порядке ни поступали пакеты, в том же порядке они и пересылаются. Ведь если для всех есть доступная пропускная способность, почему кому-то должно предоставляться преимущественное обращение?
» Ну, может быть, а может и нет, зависит от политики. Допустим, у вас есть два класса с активным трафиком, один с формирователем и достаточной пропускной способностью для всего активного трафика, но один класс находится в очереди из-за формирователя, поэтому трафик другого класса может быть передан раньше, чем ранее полученный сформированный трафик. Кстати, QoS — это не только «преференциальное отношение», это обеспечение определенных уровней обслуживания, т. е. качество обслуживания. Например, возможно, мы хотим гарантировать двум хостам половину доступной пропускной способности, является ли это «преференциальным»? «
Даже если канал связи имеет пропускную способность 1000 Мбит, перегрузка может произойти раньше, если производительность устройства может обрабатывать, скажем, только 250 Мбит, верно?
» Да, это будет перегрузка, но часто устройства практически не поддерживают QoS для таких перегрузок. Рассмотрим маршрутизатор, скорость PPS которого не может поддерживать скорость входящего трафика по отношению к скорости исходящего трафика, например, гигабитный входящий трафик, гигабитный исходящий трафик, 500 Мбит/с входящего трафика и скорость PPS, которая поддерживает только 400 Мбит/с. Что же происходит? Возможно, входящий интерфейс начинает отбрасывать полученные входящие кадры, поскольку они не удаляются достаточно часто. Или аппаратное обеспечение устройства может буферизовать входящий трафик до переполнения буфера. Но что, если этот трафик представлял собой набор FTP с чередующимся VoIP? (Помните, что совокупная скорость входящего трафика составляет всего 500 Мбит/с на гигабитном интерфейсе.) Как VoIP защищается от переполнения NIC и/или потери входящего буфера? (Кстати, некоторые устройства могут выполнять некоторое «встроенное» управление входящей очередью, причем некоторые из них имеют очень ограниченные возможности настройки.) Кстати, традиционно перегрузка рассматривается как фактор QoS в двух случаях. Во-первых, более быстрый входящий интерфейс (например, гигабитный) к более медленному исходящему интерфейсу (например, FE). Во-вторых, несколько входящих интерфейсов, суммарная пропускная способность которых (например, 2 FE) превышает исходящую пропускную способность (например, 1 FE). Вы затронули еще одну проблему, когда устройство не может удовлетворить потребности своих интерфейсов в производительности. Обычно это решается путем обеспечения адекватности оборудования потребностям, но это, безусловно, является фактором QoS. Аналогичным образом, еще один аспект QoS, который можно упустить из виду, поскольку он встречается редко, но подумайте, может ли 5 интерфейсов входа FE быть проблемой, когда есть гигабитный выход и устройство может легко обрабатывать гигабитную скорость? Да, может, потому что... [Спойлер]
(Выделите, чтобы прочитать)
что произойдет, если все 5 интерфейсов FE доставят кадр одновременно? Только 1 может быть передан немедленно, остальные 4 должны будут (на очень короткое время) встать в очередь. Должна ли быть какая-либо приоритезация между 5 кадрами?
Что, если все 5 интерфейсов FE передают кадр одновременно? Только 1 может быть передан немедленно, остальные 4 должны быть (на очень короткое время) поставлены в очередь. Должна ли быть какая-либо приоритезация между 5 кадрами?