QOS ASR 1K — асимметричная пропускная способность канала
-
Привет Вопрос о 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 С уважением -
«Я не могу управлять QOS на оборудовании на входе». А, понятно, я понимаю. Вы не можете полностью контролировать это, как если бы вы могли управлять QoS на входящем трафике. Вы можете «влиять» на вышестоящее оборудование, но это в значительной степени зависит от типа трафика, является неточным (по крайней мере, на типичных сетевых устройствах — специализированные устройства могут работать гораздо лучше) и может иметь некоторые нежелательные побочные эффекты. Если хотите, я могу рассказать подробнее, но поймите, с точки зрения QoS, это, возможно, лучше, чем ничего, но, возможно, и не намного лучше; опять же, побочные эффекты могут быть неприятными. (Это похоже на военную хирургию более ста лет назад: ваша жизнь или ваша рука/нога). «Вы имеете в виду, что в любом случае на этой платформе, если исходящая пропускная способность выше входящей, то перегрузка никогда не может произойти?» Верно, а также если пропускная способность (полезной нагрузки) одинакова. Если вы не уверены, попробуйте найти пример, когда это не так. Что касается Etherchannel, традиционно используется совокупная пропускная способность, поэтому, если предположить, что только входящий трафик также является исходящим, то ситуация с пропускной способностью остается той же. Однако, если вы используете функцию, с помощью которой можно указать, что некоторые членские ссылки должны использоваться для определенных подмножеств трафика, и распределение членских ссылок может различаться между двумя сторонами/концами, то да, может возникнуть перегрузка. По сути, возможность назначать членские ссылки — это аппаратная форма QoS, логически уступающая, поскольку очень легко создать непредвиденные ситуации.
-
Извините, я не понимаю вашу проблему. Переход от более медленной к более быстрой скорости не вызывает перегрузки, поэтому нет необходимости в QoS. Переход от более быстрой к более медленной скорости может вызвать перегрузку, и QoS может использоваться для управления такой перегрузкой. Возможно, в нисходящем направлении есть узкое место (от быстрого к медленному), где нельзя применить QoS. В таких случаях в восходящем направлении от этого узкого места можно сформировать нисходящее узкое место и управлять перегрузкой там, на формирователе. Ваши примеры — от более медленного к более быстрому, верно?
-
Все еще пытаюсь понять вашу проблему. Путь 1: от более медленного к более быстрому — проблема отсутствует. Путь 2 — от быстрого к медленному — можно применить QoS — нет необходимости в формировании. Путь 3 — от одинакового к одинаковому, нет необходимости в QoS.
-
Извините, но, насколько я понимаю, без формирования нет очередей и планирования. Так как же можно управлять приоритетами в случае перегрузки? Даже при одинаковой пропускной способности могут возникать перегрузки, и тогда приоритеты необходимы.
-
Привет, Джозеф Я не могу управлять QOS на оборудовании выше по потоку. В моем примере, если посмотреть на путь 1, да, это путь, где пропускная способность выходного интерфейса выше, чем пропускная способность входного интерфейса. Но поскольку в ASR1K нет очередей входа, как вы справляетесь с перегрузкой входа? Я думал, что очереди на выходе — это способ регулирования и на входе пути. Вы имеете в виду, что в любом случае на этой платформе, если пропускная способность исходящего интерфейса выше, чем входящего, то перегрузка никогда не может произойти? Не уверен в этом. Если это правда, то будет проще настроить QOS. Без сомнения. В любом случае, мой вопрос о влиянии на QOS при потере интерфейса, входящего в Etherchannel, по-прежнему остается открытым. С уважением
-
Во-первых, для эфирного канала обязательно применение одинакового QoS ко всем портам-членам. Во-вторых, в конечном итоге QoS будет видеть один виртуальный интерфейс, а не несколько, и, следовательно, QoS не будет действовать, если один из портов-участников выйдет из строя. MHM
-
Нет. Декларировать одинаковый 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 в большей степени касается разделения трафика на подинтерфейсы, чем обработки общего трафика агрегированной пропускной способности. -
QoS в PO Использование QoS в физическом или виртуальном интерфейсе зависит от типа и направления ![Screenshot (173).png]
-
Все эти устройства являются коммутаторами. OP — это маршрутизатор ASR1k. Маршрутизаторы обычно обладают более широкими возможностями в плане QoS, чем коммутаторы. Кроме того, это из презентации CiscoLive? Независимо от этого, дата источника?
-
для ASR IOS XE
вы можете видеть, что QoS может применяться к
A- члену,
B- основному интерфейсу PO,
C- подинтерфейсу PO Я делюсь с вами двумя слайдами, чтобы вы и другие могли понять, что существует направление QoS и тип, и
что это определяет, в каком интерфейсе вы можете настроить MHM ![Screenshot (174).png]
![Screenshot (175).png]
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти