QOS ASR 1K — асимметричная пропускная способность канала
-
«Я не могу управлять 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]
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти