Где я могу использовать группу QoS?

[Mitrixsen]

Здравствуйте, все. Я понимаю, что такое группы QoS. Идея заключается в том, что вы можете классифицировать что-либо в карте политик ввода, а затем применить группу QoS к этому пакету, чтобы при маршрутизации из выходного интерфейса карта политик выхода применила свою собственную политику к этой группе QoS. Хотя я не совсем понимаю, когда я буду это использовать. Зачем применять группу QoS к чему-то, когда можно просто классифицировать это снова с помощью соответствующей CLASS-MAP и применить политику таким образом? У кого-нибудь есть практический пример или конфигурация для этого? Потому что, если вы рассмотрите мой пример class-map match-all PING match protocol ping policy-map GROUP class PING set qos-group 1 interface GigabitEthernet1 service-policy input GROUP class-map match-all PING-EF match qos-group 1 policy-map GROUP-EF class PING-EF set ip dscp ef interface GigabitEthernet2 service-policy output GROUP-EF я настроил карту политики вывода так, чтобы помечать все, что имеет группу QoS 1, с помощью
EF
. Но я мог бы достичь того же самого, если бы просто сделал так, или нет? class-map match-all PING match protocol ping policy-map GROUP-EF class PING set ip dscp ef interface GigabitEthernet2 service-policy output GROUP-EF Я мог бы просто снова сопоставить на основе карты классов PING в карте политик вывода без группы QoS. Так где же эти группы становятся полезными? Возможно, мой пример слишком прост для этого. Спасибо. Дэвид

[Joseph W. Doherty]

Вы правы, этот пример Cisco можно заменить вашей второй политикой. Представьте, что у вас есть несколько входных интерфейсов, обеспечивающих FTP, помеченных DSCP BE, но только один из интерфейсов имеет часть FTP-трафика, который вы хотите обрабатывать по-другому (возможно, с другим приоритетом отбрасывания), но вы не хотите менять его DSCP-пометку. Можно ли это сделать в политике исходящего трафика? Можно, подвергнув ВЕСЬ исходящий трафик сопоставлению протоколов и другим критериям выбора, кроме ToS. Однако на этом одном интерфейсе вы можете ограничить критерии сопоставления только трафиком этого интерфейса, и, поскольку вы не хотите изменять его ToS, вы можете помечать его только на этом устройстве, используя тег qos-group. Вышеописанное снижает потребность в обработке. Я мог бы расширить сложность сопоставления до определенных условий, при которых мы ограничиваем такое уникальное сопоставление необходимыми интерфейсами. Тогда выход просто сопоставляется с qos-qroup (что может быть даже более эффективным, чем проверка ToS). На высоком уровне мы часто не задумываемся о том, как что-то делается, если конечный результат остается тем же. Но часто имеет значение и то, как быстро что-то выполняется. Подумайте, когда кто-то хочет Jumbo Ethernet, почему? Те же данные могут быть доставлены с использованием пакетов минимального размера, вплоть до некоторого максимального Jumbo, верно? Вы ответили на мой предыдущий вопрос «более простая классификация», если вы имели в виду более простую (требующую меньше ресурсов) на устройстве, верно! Кстати, я не предлагаю всегда отдавать первоочередное значение тому, чтобы сделать что-то максимально эффективным, многое зависит от общей ситуации. Мы также могли бы рассмотреть случаи, когда нам может понадобиться больше, чем 8 основных классов трафика, предоставляемых DSCP, или 8 уровней, предоставляемых IPPrec или приоритетом тегов VLAN. Я полагаю, что qos-qroup имеет 32 значения (не проверял, когда была предоставлена эта функция, по сравнению с DSCP, но это также может быть частью ее основы).

[Joseph W. Doherty]

Во-первых, зачем нужен тег ToS/CoS? Этот ответ также применим к групповому тегированию QoS, но он также дает преимущество в том, что пакеты или кадры не нужно изменять.

[Joseph W. Doherty]

О, я не привел реальный пример, потому что мне это никогда не было нужно, но это не значит, что это бесполезно, просто, возможно, редко нужно.

[Mitrixsen]

«Во-первых, зачем нужен тег ToS/CoS?» Теги можно использовать для классификации трафика, а затем к классифицированному трафику можно применять различные политики. Таким образом, вместо того, чтобы настраивать ACL или NBAR повсеместно, мы можем поручить эту задачу пограничным устройствам, а затем установить значение маркировки в заголовке IP-пакета или заголовке 802.1q, которое можно использовать для упрощения классификации. Проблема, которую я вижу в группах QoS, заключается в том, что если рассмотреть такой пример от Cisco class-map telepresence-video match protocol telepresence-media
class-map jabber-video match protocol cisco-jabber-video
class-map egress-video-traffic *** match qos-group 4 ***
!
policy-map mark-qos-group class telepresence-video set qos-group 4 class jabber-video set qos-group 4
!
policy-map egress-queuing class egress-video-traffic bandwidth remaining percent 50
!
interface gig 1/0/0 service-policy in mark-qos-group
!
interface serial1/1/0 service-policy out egress-queuing Нельзя ли было бы сделать то же самое, если бы мы просто сделали это (без каких-либо групп QoS)? class-map telepresence-video match protocol telepresence-media
class-map jabber-video match protocol cisco-jabber-video policy-map egress-queuing class telepresence-video bandwidth xxx class jabber-video bandwidth xxx
!
interface serial1/1/0 service-policy out egress-queuing

[Devaa]

Привет
[, @Mitrixsen] Это функция, использовать ее или нет — решать вам. Обычно группы или шаблоны используются для упрощения, когда ваша конфигурация сложная. Вы можете обойтись без них, если считаете, что добавление групп усложняет вашу конфигурацию. Если у вас есть несколько классов (скажем, 10, 20 или более), вам просто нужно изменить BW с 20 на 30, представьте, сколько строк нужно обновить в конфигурации. Это можно свести к минимуму, используя группы. Надеюсь, это имеет смысл!

[Ramblin Tech]

Большая часть критериев QoS, которые можно сопоставить в политиках входящего и исходящего трафика, в значительной степени зависит от платформы (PD), особенно в случае функций QoS, реализованных в аппаратном обеспечении. При преобразовании глобальной архитектуры QoS в фактические реализации в каждом элементе сети необходимо учитывать эти ограничения PD, чтобы создать конфигурации, которые максимально приближены к определенному вами «идеальному» режиму QoS. Как это связано с qos-group? Некоторые платформы поддерживают различные критерии сопоставления в политиках входящего трафика и в политиках исходящего трафика. Например, некоторые платформы позволяют сопоставлять группы доступа ACL на входе, но не на выходе. Такие платформы часто позволяют сопоставлять ACL на входе, а затем устанавливать значение qos-group. Политика исходящего трафика может затем сопоставляться с qos-group для выполнения надлежащей функции очереди/планирования. Вывод: изучите возможности сопоставления и настройки, поддерживаемые в политиках входящего
и
исходящего трафика для всех платформ в вашей сети, так как вы не сможете выполнить прямое сопоставление по целевым критериям на каждом прыжке исходящего трафика. Если все можно сопоставить напрямую на выходе, тем лучше. Если нет, определите, поддерживает ли данная платформа какое-либо промежуточное значение (например, qos-group, discard-class и т. д.), которое можно установить на входе для сопоставления в политике выхода этой платформы. Отказ от ответственности: я давно работаю в CSCO. Неправильные ответы — моя вина, так как они не генерируются искусственным интеллектом.

[Joseph W. Doherty]

Джим совершенно прав, когда говорит, что функции QoS в значительной степени зависят от платформы и иногда различаются между функциями входящего и исходящего трафика. Например, я помню, что модели 2960/3560/3750 вообще не поддерживали политику исходящего трафика, и даже сегодня коммутаторы часто не поддерживают сопоставление протоколов или поддерживают только часть того, что поддерживает маршрутизатор. Джим также прав в том, что лучше всего иметь высокоуровневую архитектуру QoS, в которой вы работаете с каждым устройством, чтобы максимально приблизиться к его поддержке.