Привет Вопрос о QOS в серии ASR1K. Он поддерживает только выходную очередь. Поэтому политики обслуживания, связанные с формированием, можно использовать только на выходе. В конструкции с асимметричной пропускной способностью между интерфейсами (например, от 1 Гбит до 10 Гбит или от 10 Гбит до LAG 2x10 Гбит), как справиться с разницей, не ограничиваясь более низкой пропускной способностью? Например, предположим, что ASR имеет: - одним интерфейсом ge-0/0/0 1G для поставщика услуг - одним Etherchannel Po1 2x1G к основной сети с подинтерфейсами 802.1Q Po1.10 / Po1.20 / Po.30 Существует как минимум три основных пути передачи данных: Путь 1) ge-0/0/0 к Po1 = 1G к 2x1G. Путь 2) Po1 к ge-0/0/0 = 2x1G к 1G Путь 3) Po1.x к Po1.y = 2x1G (фактически кратное 1G к 1G из-за балансировки нагрузки на LAG) На пути 1 можно формировать около 1G для обработки входящей пропускной способности ge-0/0/0. На пути 2 можно сформировать около 1G, чтобы справиться с исходящей пропускной способностью ge-0/0/0. На пути 3 можно сформировать около 2G для обработки исходящей пропускной способности Po1, но по умолчанию политика обслуживания, применяемая на выходе, не учитывает входной интерфейс. Таким образом, формирование около 1G, применяемое для пути 1, мы также применим к пути 3, и это ограничит общую пропускную способность Etherchannel. У меня есть два вопроса: - Требуется ли и возможно ли разделить две политики обслуживания на выходе для интерфейса Port-channel? Одна из них будет учитывать входной интерфейс, чтобы сформировать пропускную способность ниже входной пропускной способности более медленного пути, а другая - общую пропускную способность Etherchannel. - что касается интерфейсов Etherchannel, в документации указано, что мы можем применять политику обслуживания MQC к самому Etherchannel. Хорошо, но если мы разрабатываем политику с учетом общей пропускной способности, что произойдет, если Etherchannel потеряет интерфейс-член? В моем примере мы не сможем обеспечить 1 Гбит/с доступной пропускной способности, но с политикой 2 Гбит/с. Так будет ли более точным применять агрегированный QOS старого типа к физическим интерфейсам-членам? Агрегированный Etherchannel OQS (последняя версия):
https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/qos/b-quality-of-service/m_aggregate_etherchannel_quality_of_service.html Старый Etherchannel QOS:
https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/qos/b-quality-of-service/m_qos-eth-int-1.html#GUID-95630B2A-986E-4063-848B-BC0AB7456C44 С уважением

]]>https://sla247.ru/forum/topic/1042/qos-asr-1k-асимметричная-пропускная-способность-каналаRSS for NodeFri, 15 May 2026 03:17:33 GMTSat, 14 Feb 2026 22:10:57 GMT60для ASR IOS XE
вы можете видеть, что QoS может применяться к
A- члену,
B- основному интерфейсу PO,
C- подинтерфейсу PO Я делюсь с вами двумя слайдами, чтобы вы и другие могли понять, что существует направление QoS и тип, и
что это определяет, в каком интерфейсе вы можете настроить MHM ![Screenshot (174).png]
![Screenshot (175).png]

]]>https://sla247.ru/forum/post/7395https://sla247.ru/forum/post/7395Sat, 14 Feb 2026 22:11:07 GMTВсе эти устройства являются коммутаторами. OP — это маршрутизатор ASR1k. Маршрутизаторы обычно обладают более широкими возможностями в плане QoS, чем коммутаторы. Кроме того, это из презентации CiscoLive? Независимо от этого, дата источника?

]]>https://sla247.ru/forum/post/7394https://sla247.ru/forum/post/7394Sat, 14 Feb 2026 22:11:06 GMTQoS в PO Использование QoS в физическом или виртуальном интерфейсе зависит от типа и направления ![Screenshot (173).png]

]]>https://sla247.ru/forum/post/7393https://sla247.ru/forum/post/7393Sat, 14 Feb 2026 22:11:05 GMTНет. Декларировать одинаковый QOS больше не нужно на члене порта. Вы можете установить его на уровне Etherchannel. См. «Агрегированный Etherchannel QOS»:
https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/qos/b-quality-of-service/m_aggregate_etherchannel_quality_of_service.html Хорошо, вы подтвердили то, о чем я думал. С агрегированным QOS Etherchannel, если вы потеряете один интерфейс-член, QOS больше не сможет применяться, за исключением случаев, когда вы формируете скорость ниже физической пропускной способности члена. Думаю, я вижу конечный вариант использования. QOS на Etherchannel в большей степени касается разделения трафика на подинтерфейсы, чем обработки общего трафика агрегированной пропускной способности.

]]>https://sla247.ru/forum/post/7392https://sla247.ru/forum/post/7392Sat, 14 Feb 2026 22:11:04 GMTВо-первых, для эфирного канала обязательно применение одинакового QoS ко всем портам-членам. Во-вторых, в конечном итоге QoS будет видеть один виртуальный интерфейс, а не несколько, и, следовательно, QoS не будет действовать, если один из портов-участников выйдет из строя. MHM

]]>https://sla247.ru/forum/post/7391https://sla247.ru/forum/post/7391Sat, 14 Feb 2026 22:11:03 GMTПривет, Джозеф Я не могу управлять QOS на оборудовании выше по потоку. В моем примере, если посмотреть на путь 1, да, это путь, где пропускная способность выходного интерфейса выше, чем пропускная способность входного интерфейса. Но поскольку в ASR1K нет очередей входа, как вы справляетесь с перегрузкой входа? Я думал, что очереди на выходе — это способ регулирования и на входе пути. Вы имеете в виду, что в любом случае на этой платформе, если пропускная способность исходящего интерфейса выше, чем входящего, то перегрузка никогда не может произойти? Не уверен в этом. Если это правда, то будет проще настроить QOS. Без сомнения. В любом случае, мой вопрос о влиянии на QOS при потере интерфейса, входящего в Etherchannel, по-прежнему остается открытым. С уважением

]]>https://sla247.ru/forum/post/7390https://sla247.ru/forum/post/7390Sat, 14 Feb 2026 22:11:02 GMTИзвините, но, насколько я понимаю, без формирования нет очередей и планирования. Так как же можно управлять приоритетами в случае перегрузки? Даже при одинаковой пропускной способности могут возникать перегрузки, и тогда приоритеты необходимы.

]]>https://sla247.ru/forum/post/7389https://sla247.ru/forum/post/7389Sat, 14 Feb 2026 22:11:01 GMTВсе еще пытаюсь понять вашу проблему. Путь 1: от более медленного к более быстрому — проблема отсутствует. Путь 2 — от быстрого к медленному — можно применить QoS — нет необходимости в формировании. Путь 3 — от одинакового к одинаковому, нет необходимости в QoS.

]]>https://sla247.ru/forum/post/7388https://sla247.ru/forum/post/7388Sat, 14 Feb 2026 22:11:00 GMTИзвините, я не понимаю вашу проблему. Переход от более медленной к более быстрой скорости не вызывает перегрузки, поэтому нет необходимости в QoS. Переход от более быстрой к более медленной скорости может вызвать перегрузку, и QoS может использоваться для управления такой перегрузкой. Возможно, в нисходящем направлении есть узкое место (от быстрого к медленному), где нельзя применить QoS. В таких случаях в восходящем направлении от этого узкого места можно сформировать нисходящее узкое место и управлять перегрузкой там, на формирователе. Ваши примеры — от более медленного к более быстрому, верно?

]]>https://sla247.ru/forum/post/7387https://sla247.ru/forum/post/7387Sat, 14 Feb 2026 22:10:59 GMT«Я не могу управлять QOS на оборудовании на входе». А, понятно, я понимаю. Вы не можете полностью контролировать это, как если бы вы могли управлять QoS на входящем трафике. Вы можете «влиять» на вышестоящее оборудование, но это в значительной степени зависит от типа трафика, является неточным (по крайней мере, на типичных сетевых устройствах — специализированные устройства могут работать гораздо лучше) и может иметь некоторые нежелательные побочные эффекты. Если хотите, я могу рассказать подробнее, но поймите, с точки зрения QoS, это, возможно, лучше, чем ничего, но, возможно, и не намного лучше; опять же, побочные эффекты могут быть неприятными. (Это похоже на военную хирургию более ста лет назад: ваша жизнь или ваша рука/нога). «Вы имеете в виду, что в любом случае на этой платформе, если исходящая пропускная способность выше входящей, то перегрузка никогда не может произойти?» Верно, а также если пропускная способность (полезной нагрузки) одинакова. Если вы не уверены, попробуйте найти пример, когда это не так. Что касается Etherchannel, традиционно используется совокупная пропускная способность, поэтому, если предположить, что только входящий трафик также является исходящим, то ситуация с пропускной способностью остается той же. Однако, если вы используете функцию, с помощью которой можно указать, что некоторые членские ссылки должны использоваться для определенных подмножеств трафика, и распределение членских ссылок может различаться между двумя сторонами/концами, то да, может возникнуть перегрузка. По сути, возможность назначать членские ссылки — это аппаратная форма QoS, логически уступающая, поскольку очень легко создать непредвиденные ситуации.

]]>https://sla247.ru/forum/post/7386https://sla247.ru/forum/post/7386Sat, 14 Feb 2026 22:10:58 GMT