Утилизация порта коммутатора что это

Обновлено: 04.07.2024

У коммутаторов Huawei S -серии имеется возможность просмотра используемых аппаратных ресурсов (в частности, утилизации tcam ) и перераспределения (для некоторых конфигураций модульных коммутаторов).

ACL

Ресурс ACL это в самом деле ресурс, используемый для traffic - policy (и прочих вариаций traffic -*) и, в некоторых случая, Selective QinQ (когда является особым traffic - policy ). Имеется три типа ресурсов ACL – rule (классикация трафика), counter (подсчёт трафика), meter (ограничение скорости)
В случае с S 9300 это выглядит следующим образом:

[Quidway]display acl resource slot 2

Vlan-ACL Inbound-ACL Outbound-ACL

Rule Used 10 373 6

Rule Free 2038 7819 1018

Rule Total 2048 8192 1024

Meter Used 0 78 2

Meter Free 0 8114 1022

Meter Total 0 8192 1024

Counter Used 0 96 2

Counter Free 0 8096 1022

Counter Total 0 8192 1024

Как видно из этой таблицы, ресурсы раздельны для traffic - policy по отношению к vlan , ingress ACL и egress ACL .

Применим следующую политику:

acl number 3456

rule 10 permit ip source 192.0.2.1 0

rule 20 permit ip source 192.0.2.3 0

traffic classifier c3456 operator or

if-match acl 3456

traffic behavior b3456

traffic policy p3456

classifier c3456 behavior b3456

traffic-policy p3456 inbound

И смотрим на изменившиеся значения ресурсов ACL :

Vlan-ACL Inbound-ACL Outbound-ACL

Rule Used 10 375 6

Counter Used 0 98 2

Как видно, использовано 2 единицы ресурса rule и 2 единицы counter (потому что 2 правила и по каждому нужно считать трафик( statistics enable в behavior )), meter не используется, т.к. скоростные политики не задействованы в этом traffic - policy .

Используя большие ACL или какой-либо функционал, генерирующий их динамически, нужно следить за исчерпанием этих ресурсов.

Selective QinQ

В зависимости от конкретной модели, selective QinQ может быть реализован по-разному (с точки зрения потреблени hw ресурсов). Раньше это вообще не выделялось в отдельную фичу и явным образом реализовывалось с помощью traffic - policy , суть которого “ match c - vlan -> add s - vlan ”( пример , архив )

В современном варианте, selective QinQ настраивается следующим образом (на S 9300):

В этой статье дается определение расхожего понятия «утилизация сети», а также рассказывается о методах ее измерения и корреляции между замедлением работы сети и перегрузкой канала связи
Итак, начнем с определения.

Утилизация канала связи сети — это процент времени, в течение которого канал связи передает сигналы, или иначе — доля пропускной способности канала связи, занимаемой кадрами, коллизиями и помехами.

Иными словами, параметр "утилизация канала связи" характеризует величину загруженности сети.
Канал связи сети является общим сетевым ресурсом, поэтому его загруженность влияет на время реакции прикладного программного обеспечения. Первоочередная задача состоит в определении наличия взаимозависимости между плохой работой прикладного программного обеспечения и утилизацией канала связи сети.

Предположим, что анализатор протоколов установлен в том домене сети (collision domain), где прикладное ПО работает медленно. Средняя утилизация канала связи составляет 19%, пиковая доходит до 82%. Можно ли на основании этих данных сделать достоверный вывод о том, что причиной медленной работы программ в сети является перегруженность канала связи? Вряд ли.
Часто можно слышать о стандарте де-факто, в соответствии с которым для удовлетворительной работы сети Ethernet утилизация канала связи "в тренде" (усредненное значение за 15 минут) не должна превышать 20%, а "в пике" (усредненное значение за 1 минуту) — 35-40%.

Приведенные значения объясняются тем, что в сети Ethernet при утилизации канала связи, превышающей 40%, существенно возрастает число коллизий и, соответственно, время реакции прикладного ПО. Несмотря на то, что такие рассуждения в общем случае верны, безусловное следование подобным рекомендациям может привести к неправильному выводу о причинах медленной работы программ в сети. Они не учитывают особенности конкретной сети, а именно: тип прикладного ПО, протяженность домена сети, число одновременно работающих станций.
Чтобы определить, какова же максимально допустимая утилизация канала связи в вашем конкретном случае, рекомендуется следовать приведенным ниже правилам.

Высокая утилизация канала связи сети только в том случае замедляет работу конкретного прикладного ПО, когда именно канал связи является "узким местом" для работы данного конкретного ПО.
Кроме канала связи узкие места в системе могут возникнуть из-за недостаточной производительности или неправильных параметров настройки сервера, низкой производительности рабочих станций, неэффективных алгоритмов работы самого прикладного ПО.
В какой мере канал связи ответственнен за недостаточную производительность системы, можно выяснить следующим образом. Выбрав наиболее массовую операцию данного прикладного ПО (например, для банковского ПО такой операцией может быть ввод платежного поручения), вам следует определить, как утилизация канала связи влияет на время выполнения такой операции.
Проще всего это сделать, воспользовавшись функцией генерации трафика, имеющейся в ряде анализаторов протоколов. С помощью этой функции интенсивность генерируемой нагрузки следует наращивать постепенно, и на ее фоне производить измерения времени выполнения операции. Фоновую нагрузку целесообразно увеличивать от 0 до 50-60% с шагом не более 10%.
Если время выполнения операции в широком интервале фоновых нагрузок не будет существенно изменяться, то узким местом системы является не канал связи.

Если же время выполнения операции будет существенно меняться в зависимости от величины фоновой нагрузки (например, при 10% и 20% утилизации канала связи время выполнения операции будет значительно различаться), то именно канал связи, скорее всего, ответственен за низкую производительность системы, и величина его загруженности критична для времени реакции прикладного ПО. Зная желаемое время реакции ПО, вы легко сможете определить, какой утилизации канала связи соответствует желаемое время реакции прикладного ПО.

В данном эксперименте фоновую нагрузку не следует задавать более 60-70%. Даже если канал связи не является узким местом, при таких нагрузках время выполнения операций может возрасти вследствие уменьшения эффективной пропускной способности сети.

Это правило справедливо для неккомутируемых сетей Ethernet, так что если вы уже изжили из своей системы эту допотопную технологию — можете пропустить этот абзац.
Максимально допустимая утилизация канала связи зависит от протяженности сети.
При увеличении протяженности домена сети допустимая утилизация уменьшается. Чем больше протяженность домена сети, тем позже будут обнаруживаться коллизии.

Если протяженность домена сети мала, то коллизии будут выявлены станциями еще в начале кадра, в момент передачи преамбулы. Если протяженность сети велика, то коллизии будут обнаружены позже — в момент передачи самого кадра. В результате накладные расходы на передачу пакета (IP или IPX) возрастают.

Чем позже выявлена коллизия, тем больше величина накладных расходов и большее время тратится на передачу пакета. В результате время реакции прикладного ПО, хотя и незначительно, но увеличивается.

Сетевые решения. Статья была опубликована в номере 11 за 2003 год в рубрике технологии

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

В данной лабораторной работе изучаются основные команды мониторинга работы коммутатора.

Цель: Изучить процесс мониторинга состояния коммутатора.

Оборудование:

Настройка DES-3200-28

Изучение команд просмотра утилизации (загрузки) портов и CPU коммутатора

Просмотрите загрузку CPU коммутатора

возможные атаки на коммутатор, неправильная настройка сети. Данная проблема может быть решена путем включения функции SafeGuard Engine;
неправильная настройка ACL или других функций коммутатора, влияющих на производительность и работу CPU;
некорректная работа ПО коммутатора при выполнении некоторых функций. Данная проблема может быть решена путем замены ПО коммутатора.

Просмотрите загрузку портов коммутатора

Примечание. С помощью данной команды можно посмотреть как загрузку (утилизацию) портов коммутатора, так и объем передаваемого трафика.

Изучение команд просмотра статистики/ошибок передаваемых пакетов на порте коммутатора

Просмотрите пакеты, передаваемые станцией ПК1, подключенной к порту 21

Примечание. Данная команда позволяет определять количественные характеристики передаваемых пакетов. В случае большого количества широковещательного трафика (более 15% от общего числа передаваемого трафика) необходимо провести анализ на наличие в сети DOS-атак или ее неисправности (широковещательный шторм).

Просмотрите статистику об ошибках пакетов, принимаемых и передаваемых через порт 21

Примечание. Данная команда позволяет определять ошибки передаваемых данных и локализовать проблемы в коммутируемой сети.

Очистите счетчики статистики на порте 21

Примечание. В случае устранения выявленных ошибок или проверки отчета загрузки портов можно обнулить устаревшие данные.

Изучение команд просмотра сессий подключенных к коммутатору пользователей и Log-файла коммутатора.

Проверьте сессии пользователей, подключенных к коммутатору

Просмотрите Log-файл коммутатора

Просмотрите Log-файл коммутатора, начиная с определенного индекса

Очистите Log-файл

Команда диагностики кабелей

Протестируйте состояние медных кабелей, подключенных к портам коммутатора

Примечание. Данная функция позволяет определить состояние пар подключенного к порту коммутатора медного кабеля, а также его длину. Функция определяет следующие повреждения кабеля: разомкнутая цепь (Open Circuit) и короткое замыкание (Short Circuit).

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!