По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Не секрет, что на сегодняшний день Kubernetes стал одной из лучших оркестраторов контейнерных платформ. Более 80% организаций сегодня используют Kubernetes в тех или иных целях. Он просто автоматизирует конфигурирование и управление контейнерами.
Но помимо простоты, безопасность также является одной из наиболее важных частей любого контейнерного приложения. Вы должны знать, как обеспечить надежную безопасность приложений, работающих в кластере Kubernetes. Вопросы безопасности в последние несколько лет экспоненциально возрастают, поэтому каждая организация сосредотачивает внимание на этой области.
Если вы знакомы с Kubernetes, то вы знаете, что, по умолчанию, Kubernetes назначает IP-адрес каждому порту в кластере и обеспечивает безопасность на основе IP. Но он предоставляет только основные меры безопасности. Когда речь заходит о расширенном мониторинге безопасности и обеспечении соответствия нормативным требованиям, к сожалению, Kubernetes не обеспечивает нужного уровня безопасности. Но, к счастью, есть сторонние сканеры Kubernetes с открытым исходным кодом, которые могут помочь вам защитить ваши кластеры Kubernetes.
Вот несколько преимуществ использования сканеров Kubernetes:
Определение неправильных настроек и уязвимостей в кластере, контейнерах, модулях
Предоставляет решения для исправления неправильных настроек и устранения уязвимостей
Дает представление о состоянии кластера в реальном времени.
Дает больше уверенности команде DevOps в необходимости разработки и развертывания приложений в кластере Kubernetes
Помогает избежать сбоя кластера, выявляя проблему на ранней стадии.
Рассмотрим следующие инструменты, которые помогут найти уязвимость и неправильную конфигурацию системы безопасности для обеспечения безопасности контейнерных приложений.
1. Kube Hunter
Kube Hunter - это средство поиска уязвимостей от Aqua Security. Этот инструмент очень полезен для повышения уровня безопасности кластеров Kubernetes. Этот инструмент для выявления уязвимостей предлагает несколько стандартных вариантов сканирования, таких как удаленный, чересстрочный, сетевой.
Он содержит список активных и пассивных тестов, которые могут идентифицировать большинство уязвимостей, присутствующих в кластере Kubernetes.
Существует несколько различных вариантов использования этого инструмента.
Можно загрузить архив, извлечь его или использовать pip для непосредственной установки Kube Hunter на машину с сетевым доступом к кластеру Kubernetes. После установки можно начать сканирование кластера на наличие уязвимостей.
Второй способ использования Kube Hunter - в качестве контейнера Docker. Вы можете непосредственно установить Kube Hunter на машину в кластере, а затем проверить локальные сети для сканирования кластеров.
И третий способ - запустить Kube Hunter как под внутри Kubernetes кластера. Это помогает находить уязвимости в любых модулях приложений.
2. KubeBench
Kube Bench является одним из инструментов обеспечения безопасности с открытым исходным кодом, которые проверяют соответствие ваших приложений эталонному стандарту безопасности CIS (Center for Internet Security).
Он поддерживает тесты для нескольких версий Kubernetes. Кроме того, он также указывает на ошибки и помогает в их исправлении. Этот инструмент также проверяет настройки авторизации и аутентификации пользователей, а также уровень шифрования данных. Это гарантирует, что приложение соответствует требованиям CIS.
Возможности KubeBench:
Написано как приложение Go
Тест для мастеров и узлов Kubernetes
Доступно как контейнер
Тесты определены в YAML, что упрощает расширение и обновление
Поддержка выходных данных формата JSON
3. Checkov
Checkov - это средство безопасности, используемое для предотвращения неправильных настроек облака во время сборки Kubernetes, Terraform, Cloudformation, Serverless фреймворков и других сервисов типа Infrastructure-as-code-language. Он написан на языке Python и направлен на повышение эффективности внедрения безопасности и соответствия передовым практикам.
Можно выполнить сканирование с помощью Checkov для анализа сервисов типа Infrastructure-as-code-language
Функции Checkov:
Открытый и простой в использовании
Более 500 встроенных политики безопасности
Передовые практики обеспечения соответствия для AWS, Azure и Google Cloud
Поддержка нескольких форматов вывода - CLI, JUnit XML, JSON
Интеграция сканирований в конвейеры ci/cd
Выполняет сканирование входной папки, содержащей файлы Terraform & Cloudformation
4. MKIT
MKIT означает управляемый инструмент проверки Kubernetes. Этот инструмент помогает быстро выявлять ключевые угрозы безопасности кластеров Kubernetes и их ресурсов. Он имеет быстрые и простые методы для оценки неправильных настроек в кластере и рабочих нагрузках.
Инструмент поставляется с интерфейсом, который по умолчанию работает на http://localhost:8000. Инструмент дает представление о неуспешных и успешных проверках. В разделе «Затронутые ресурсы» вы получите подробные сведения о затронутых и не затронутых ресурсах.
Функции MKIT:
Создана с использованием всех библиотек и инструментов с открытым исходным кодом
Простота установки и использования
Поддержка нескольких поставщиков Kubernetes - AKS, EKS и GKE
Хранение конфиденциальных данных внутри контейнера
Предоставляет веб-интерфейс
5. Kubei
Kubei используется для оценки непосредственных рисков в кластере Kubernetes. Большая часть Kubei написана на языке программирования Go. Он охватывает все эталонные тесты CIS для Docker.
Он сканирует все образы, используемые кластером Kubernetes, прикладные и системные модули и т.д. Вы получаете несколько вариантов настройки сканирования с точки зрения уровня уязвимости, скорости сканирования, области сканирования и т.д. С помощью графического интерфейса можно просмотреть все уязвимости, обнаруженные в кластере, и способы их устранения.
Основные характеристики Kubei:
Сканер уязвимостей среды выполнения Kubernetes с открытым исходным кодом
Проверяет общедоступные образы, размещенные в реестре
Предоставляет состояние работоспособности кластера в режиме реального времени
Веб-интерфейс пользователя для визуализации сканирований
Предоставляет несколько пользовательских параметров для сканирования
6. Kube Scan
Kube Scan - это сканер контейнера, который сам поставляется как контейнер. Вы устанавливаете его в новый кластер, после чего он сканирует рабочие нагрузки, выполняющиеся в данный момент в кластере, и показывает оценку риска и сведения о рисках в удобном веб-интерфейсе. Риск оценивается от 0 до 10, 0 означает отсутствие риска, а 10 - высокий риск.
Формула и правила оценки, используемые Kube scan, основаны на KCCSS, общей системе оценки конфигурации Kubernetes, которая является фреймворком с открытым исходным кодом. Он аналогичен CVSS (Common Vulnerability Scoring System). Он использует более 30 параметров настройки безопасности, таких как политики, возможности Kubernetes, уровни привилегий и создает базовый уровень риска для оценки риска. Оценка риска также основана на простоте эксплуатации или уровне воздействия и масштабах эксплуатации.
Функции KubeScan:
Инструмент оценки рисков с открытым исходным кодом
Веб-интерфейс пользователя с оценкой рисков и подробностями оценки рисков
Выполняется как контейнер в кластере.
Регулярные сканирование кластера каждые 24 часа
7. Kubeaudit
Kubeaudit, как предполагает название, является инструментом кластерного аудита Kubernetes с открытым исходным кодом. Он находит неправильные настройки безопасности в ресурсах Kubernetes и подсказывает, как их устранить. Он написан на языке Go, что позволяет использовать его как пакет Go или средство командной строки. Его можно установить на компьютер с помощью команды brew.
Он предлагает различные решения вроде запуск приложений от имени пользователя без рут прав, предоставление доступа только для чтения к корневой файловой системе, избегание предоставления дополнительных привилегий приложениям в кластере для предотвращения общих проблем безопасности. Он содержит обширный список аудиторов, используемых для проверки проблем безопасности кластера Kubernetes, таких как SecurityContext модулей.
Особенности Kubeaudit:
Инструмент аудита Kubernetes с открытым исходным кодом
Предоставляет три различных режима - манифест, локальный, кластер, для аудита кластера
Дает результат аудита на трех уровнях серьезности - ошибка, предупреждение, информация
Использует несколько встроенных аудиторов для аудита контейнеров, модулей, пространств имен
8. Kubesec
Kubesec - это инструмент анализа рисков безопасности с открытым исходным кодом для ресурсов Kubernetes. Он проверяет конфигурацию и файлы манифестов, используемые для развертывания и операций кластера Kubernetes. Вы можете установить его в свою систему с помощью образа контейнера, двоичного пакета, контроллера допуска в Kubernetes или плагина kubectl.
Особенности Kubesec:
Инструмент анализа рисков с открытым исходным кодом
Он поставляется с объединенным HTTP-сервером, который по умолчанию работает в фоновом режиме и слушает порт 8080.
Может запускаться как Kubesec-as-a-Service через HTTPS по адресу v2.kubesec.io/scan
Может сканировать несколько документов YAML в одном входном файле.
Заключение
Указанные средства предназначены для обеспечения безопасности кластера Kubernetes и его ресурсов и затрудняют взлом хакерами приложений, работающих внутри кластера. Сканеры помогут более уверенно развертывать приложения на кластере.
Протокол связующего дерева (STP) был первоначально разработан Radia Perlman и впервые описан в 1985 году в Алгоритме распределенного вычисления связующего дерева в расширенной локальной сети.
1 STP уникален в списке рассматриваемых здесь плоскостей управления, поскольку изначально был разработан для поддержки коммутации, а не маршрутизации. Другими словами, STP был разработан для поддержки переадресации пакетов без времени жизни (TTL) и без подкачки заголовка per hop коммутационным устройством. Пакеты, коммутируемые на основе STP, передаются по сети без изменений.
Построение дерева без петель
Процесс построения дерева без петель выглядит следующим образом:
Каждое устройство переводит все порты в заблокированный режим, чтобы ни один порт не пересылал трафик, и начинает объявлять блоки данных протокола моста (Bridge Protocol Data Units -BPDU) для каждого порта. Этот BPDU содержит:
Идентификатор объявленного устройства, который является приоритетным в сочетании с локальным интерфейсом Media Access Control (MAC) адресом.
Идентификатор корневого моста-кандидата. Это мост с самым низким идентификатором, о котором знает локальное устройство. Если каждое устройство в сети запускается в один и тот же момент, то каждое устройство будет объявлять себя как корневой мост-кандидат, пока не узнает о других мостах с более низким идентификатором моста.
При получении BPDU на интерфейсе идентификатор корневого моста, содержащийся в BPDU, сравнивается с локально сохраненным наименьшим идентификатором корневого моста. Если идентификатор корневого моста, содержащийся в BPDU, меньше, то локально сохраненный идентификатор корневого моста заменяется вновь обнаруженным мостом с более низким идентификатором.
После нескольких раундов объявлений каждый мост должен был обнаружить мост с наименьшим идентификатором моста в сети и объявить этот мост корневым.
Это должно происходить, пока все порты на всех устройствах все еще заблокированы (не пересылают трафик).
Чтобы убедиться, что это действительно произойдет, пока все порты все еще заблокированы, таймер устанавливается на достаточно длительное время, позволяющий выбрать корневой мост.
После выбора корневого моста определяется кратчайший путь к корневому мосту.
Каждый BPDU также содержит метрику для достижения корневого моста. Этой метрикой может быть количество переходов, но стоимость каждого перехода также может варьироваться в зависимости от административных переменных, таких как пропускная способность канала.
Каждое устройство определяет порт, через который оно имеет самый дешевый путь к корневому мосту. Он отмечен как корневой порт.
Если существует более одного пути к корневому мосту с одинаковой стоимостью, используется прерыватель связи. Обычно это идентификатор порта.
Для любого звена, по которому соединены два моста:
Мост с наименьшей стоимостью пути к корневому мосту выбирается для пересылки трафика от канала к корневому мосту.
Порт, соединяющий выбранный сервер пересылки с каналом, помечается как назначенный порт.
Порты, отмеченные как корневые или как назначенные порты, могут пересылать трафик.
Результатом этого процесса является единое дерево, по которому доступны все пункты назначения в сети. На рисунке 1 показано, как STP работает в реальной топологии.
Предположим, что все устройства на рисунке 1 были включены в один и тот же момент. Существует ряд возможных вариаций времени, но процесс построения набора безцикловых путей через сеть будет выглядеть, с точки зрения F, примерно так:
Выберите корневой мост:
F объявляет BPDU E и D с идентификатором и корневым мостом кандидата 32768.0200.0000.6666.
D (при условии, что D не получил никаких BPDU) объявляет BDPU с идентификатором и корневым мостом кандидата 28672.0200.0000.4444.
E (при условии, что E не получил никаких BPDU) объявляет BPDU с идентификатором и корневым мостом-кандидатом 32768.0200.0000.5555.
На этом этапе F выберет D в качестве корневого моста и начнет объявлять BPDU со своим локальным идентификатором и корневым мостом-кандидатом, установленным на идентификатор D.
В какой-то момент D и E получат BPDU от C, имеющего идентификатор нижнего моста (24576.0200.0000.3333). Получив этот BPDU, они оба установят свой ID корневого моста кандидата на ID C и отправят новые BPDU в F.
Получив эти новые BPDU, F отметит, что новый идентификатор корневого моста кандидата ниже, чем его предыдущий идентификатор корневого моста кандидата, и затем выберет C в качестве корневого моста.
После нескольких циклов BDPU все мосты в сети выберут C в качестве корневого моста.
Отметьте корневые порты, найдя кратчайший путь к корню:
Предположим, что каждая линия связи стоит 1.
D получит BDPU от C с локальным идентификатором и идентификатором корневого моста 24576.0200.0000.3333 и стоимостью 0.
D добавит стоимость достижения C, одного перехода, объявляя, что он может достичь корневого моста со стоимостью от 1 до F.
E получит BDPU от C с локальным идентификатором и идентификатором корневого моста 24576.0200.0000.3333 и стоимостью 0.
E добавит стоимость достижения C, одного перехода, объявляя, что он может достичь корневого моста со стоимостью от 1 до F.
F теперь имеет два объявления о корневом мосте с равной стоимостью. Он должен разорвать связь между этими двумя доступными путями. Для этого F проверяет идентификаторы объявленных мостов. Идентификатор моста D меньше, чем E, поэтому F будет отмечать свой порт, направленный к D, как корневой порт.
Маркировка назначенных портов на каждом канале:
Единственный другой порт F направлен в сторону E. Должен ли быть заблокирован этот порт?
Чтобы определить это, F сравнивает свой локальный идентификатор моста с идентификатором моста E. Приоритеты одинаковы, поэтому для принятия решения необходимо сравнить адреса локальных портов. Локальный идентификатор F заканчивается на 6666, а у E - на 5555, поэтому E меньше.
F не отмечает интерфейс к E как назначенный порт; вместо этого он отмечает этот порт как заблокированный.
E выполняет то же сравнение и отмечает свой порт в направлении F как назначенный порт.
D сравнивает свою стоимость по отношению к корню со стоимостью F по отношению к корню.
Стоимость D ниже, поэтому он пометит свой порт в направлении D как назначенный порт.
На рисунке 2 показаны заблокированные, назначенные и корневые порты после завершения этих вычислений.
Порты на рисунке 2 помечены как bp для заблокированного порта, rp для корневого порта и dp для назначенного порта. Результатом процесса является дерево, которое может достигать любого сегмента сети, и, следовательно, хостов, подключенных к любому сегменту в сети. Один интересный момент, связанный с STP, заключается в том, что в результате получается единое дерево по всей топологии, закрепленное на корневом мосту. Если какой-либо хост, подключенный к E, отправляет пакет на хост, подключенный к B или F, пакет должен проходить через C, корневой мост, потому что один из двух портов на каналах [F, E] и [E, B] является заблокирован. Это не самое эффективное использование полосы пропускания, но оно предотвращает зацикливание пакетов во время нормальной пересылки.
Как обрабатывается обнаружение соседей в STP? Обнаружение соседей вообще не рассматривается с точки зрения надежной передачи информации по сети. Каждое устройство в сети строит свои собственные BPDU. Эти BPDU не проходят через какое-либо устройство, поэтому нет необходимости в сквозной надежной транспортировке в плоскости управления. Однако обнаружение соседей используется для выбора корневого моста и построения дерева без циклов по всей топологии с использованием BPDU. А как насчет отброшенных и потерянных пакетов? Любое устройство, на котором запущен протокол STP, периодически повторно передает свои BPDU по каждому каналу (в соответствии с таймером повторной передачи). Устройству, на котором запущен протокол STP, требуется несколько отброшенных пакетов (согласно таймеру отключения), чтобы предположить, что его соседи вышли из строя, и, следовательно, перезапустить вычисление состояний корневого моста и порта. В STP нет двусторонней проверки подключения ни для каждого соседа, ни на всем пути. Также не существует какой-либо проверки maximum Transmission Unit (MTU). STP изучает топологию, комбинируя BPDU с информацией о локальных каналах для каждого узла. Однако в сети нет ни одного узла с таблицей, описывающей всю топологию.
Изучение доступных пунктов назначения
Как STP разрешает пересылку? В частности, как устройства, на которых запущен протокол STP, узнают о доступных местах назначения? Рассмотрим рисунок 3.
На рис. 3 показано состояние сети с вычисленным связующим деревом и каждым портом, отмеченным как назначенный или корневой порт. В этой топологии нет заблокированных портов, потому что нет петель. Предположим, B, C и D не имеют информации о подключенных устройствах; A отправляет пакет в сторону E. Что происходит в этот момент?
A передает пакет по каналу [A, B]. Поскольку B имеет назначенный порт на этом канале, он примет пакет (коммутаторы принимают все пакеты на назначенных портах) и проверит адреса источника и назначения.
B может определить, что A доступен через этот назначенный порт, потому что он получил пакет от A на этом порту. Исходя из этого, B вставит MAC-адрес A как достижимый в свою таблицу пересылки через свой интерфейс на канале [A, B].
B не имеет информации о E, поэтому он будет рассылать этот пакет через каждый из своих незаблокированных портов. В этом случае единственный другой порт B - это его корневой порт, поэтому B пересылает этот пакет в C. Это лавинная рассылка называется Broadcast, Unknown, и Multicast (BUM) трафиком. BUM-трафик - это то, чем должна каким-то образом управлять каждая плоскость управления, которая изучает пункты назначения в процессе пересылки.
Когда C получает этот пакет, он проверяет адрес источника и обнаруживает, что A доступен через назначенный порт, подключенный к [B, C]. Он вставит эту информацию в свою локальную таблицу пересылки.
У C также нет информации о том, где E находится в сети, поэтому он просто лавинно рассылает пакет по всем незаблокированным портам. В этом случае единственный другой порт C - это канал [C, D].
D повторяет тот же процесс, которому следовали B и C, узнавая, что A доступен через его корневой порт по каналу [C, D], и лавинно направляет пакет по каналу [D, E].
Когда E получает пакет, он обрабатывает информацию и отправляет ответ обратно A.
Когда D получает этот ответный пакет от E, он проверяет адрес источника и обнаруживает, что E доступен через назначенный ему порт по каналу [D, E]. D действительно знает обратный путь к A, поскольку он обнаружил эту информацию при обработке первого пакета в потоке, идущем от A к E. Он будет искать A в своей таблице пересылки и передавать пакет по каналу [C, D].
C и B будут повторять процесс, который D и C использовали для определения местоположения E и перенаправления обратного трафика обратно в A.
Таким образом, узнавая адрес источника по входящим пакетам, а также путем лавинной рассылки или пересылки пакетов по исходящим каналам, каждое устройство в сети может узнать о каждом достижимом месте назначения. Поскольку протокол STP основан на изучении доступных адресатов в ответ на пакеты, передаваемые по сети, его классифицируют как реактивную плоскость управления. Обратите внимание, что этот процесс обучения происходит на уровне хоста; подсети и IP-адреса не изучаются, а скорее изучается физический адрес интерфейса хоста. Если один хост имеет два физических интерфейса на одном и том же канале, он будет отображаться как два разных хоста для плоскости управления STP.
Как удаляется информация из таблиц пересылки на каждом устройстве? Через процесс тайм-аута. Если запись пересылки не была использована в определенное время (таймер удержания), она удаляется из таблицы. Следовательно, STP полагается на кэшированную информацию пересылки.
Подведение итогов о протоколе связующего дерева
STP явно не является ни протоколом состояния канала, ни протоколом вектора пути. Это протокол вектора расстояния? Любая путаница в том, как классифицировать протокол, проистекает из первоначального выбора корневого моста перед вычислением кратчайших путей. Удалив этот первый шаг, проще классифицировать STP как протокол вектора расстояния, используя распределенную форму алгоритма Беллмана-Форда для расчета путей без петель по топологии. Что нужно сделать с первоначальным расчетом корневого моста? Эта часть процесса гарантирует, что во всей сети будет только одно дерево кратчайшего пути. Таким образом, STP можно классифицировать как протокол вектора расстояния, который использует алгоритм Беллмана-Форда для вычисления единого набора кратчайших путей для всех пунктов назначения во всей сети. Другими словами, STP вычисляет дерево кратчайшего пути по топологии, а не по адресатам.
Почему так важно, чтобы одно дерево вычислялось по всей сети? Это связано со способом, которым STP изучает информацию о доступности: STP - это реактивная плоскость управления, изучающая достижимость в ответ на фактические пакеты, проходящие через сеть. Если бы каждое устройство построило отдельное дерево с корнями в самом себе, этот реактивный процесс привел бы к несогласованному представлению топологии сети и, следовательно, к петлям пересылки.
STP и широковещательные штормы
Широковещательные рассылки - важная часть обнаружения служб в большинстве приложений. Например, как показано на рисунке 4, как A может обнаружить присутствие определенной службы на F?
Самое простое, что может сделать A в этой ситуации, - это отправить какой-то пакет, который будет доставлен на каждый хост, подключенный к сети, и дождаться ответа от хоста, на котором запущена данная служба. Таким образом, A отправляет широковещательную рассылку с вопросом о конкретной услуге или устройстве. Как B, C, D и E должны относиться к этой трансляции? Поскольку широковещательная рассылка не является «обучаемым» адресом (широковещательную рассылку должно принимать каждое устройство в каждом сегменте), лучше всего для коммутаторов пересылать пакет на каждый неблокированный порт.
Что произойдет, если А выполнит много рассылок? Что произойдет, если хост отправит достаточно широковещательных рассылок, чтобы отбросить BPDU? В этом случае сам STP запутается и, скорее всего, создаст цикл пересылки в топологии. Такой цикл пересылки будет, конечно, пересылать широковещательные пакеты постоянно, так как нет TTL для отбрасывания пакетов после того, как они пересекли сеть определенное количество раз. Каждая рассылка, передаваемая A, в этой ситуации останется в сети навсегда, петляя, возможно, между коммутаторами B, C, D и E. И каждая рассылка, добавленная к нагрузке сети, конечно же, предотвратит успешную передачу или прием BPDU, предотвращая схождение STP.
Следовательно, трафик в сети препятствует сходимости STP, а отсутствие сходимости увеличивает нагрузку трафика на саму сеть – возникает положительный цикл обратной связи, который вызывает хаос во всей сети. Эти события называются широковещательными штормами и достаточно распространены в сетях на основе STP, чтобы заставить мудрых проектировщиков и операторов сети ограничивать область действия любого домена STP. Существование широковещательных штормов также привело к ряду модификаций работы STP, таких как простая замена базового протокола плоскостью управления истинным состоянием канала.
Сразу к делу. На рисунке 1 показана базовая конфигурация STP (Spanning Tree Protocol).
Рис. 1 Базовая конфигурация STP
По умолчанию функция STP коммутатора включена. Если STP отключен, используйте команду stp enable в системном режиме, чтобы включить STP.
# На S1 установите режим работы связующего дерева на STP. Используйте режим stp {mstp | rstp | stp}, с помощью которой вы можете установить режим MSTP, RSTP или STP. По умолчанию установлен режим MSTP.
<Quidway> system-view
[Quidway] sysname S1
[S1] stp mode stp
# На S2 установите режим работы связующего дерева на STP.
<Quidway> system-view
[Quidway] sysname S2
[S2] stp mode stp
# На S3 установите режим работы связующего дерева на STP.
<Quidway> system-view
[Quidway] sysname S3
[S3] stp mode stp
# На S4 установите режим работы связующего дерева на STP.
<Quidway> system-view
[Quidway] sysname S4
[S4] stp mode stp
Даже если STP автоматически выберет корневой мост, мы сначала назначим коммутатор ближе к центру сети. Структура сети показана на рис. 1 простая: S1 и S2 подключены через Интернет, а основные коммутаторы, S3 и S4, являются коммутаторами доступа. Мы можем изменить приоритет моста S1, чтобы гарантировать, что S1 будет выбран в качестве корневого моста. Команда stp priority priority используется для установки приоритета моста устройства; значение приоритета колеблется от 0 до 61440 с шагом 4096. Значение по умолчанию-32 768. Чем меньше приоритет, тем больше вероятность того, что устройство будет выбрано в качестве корневого моста. Вы также можете использовать команду stp root primary для обозначения S1 в качестве корневого моста. После выполнения команды на устройстве значение приоритета моста устройства автоматически устанавливается равным 0. Приоритет моста устройства не может быть изменен после этого с помощью команды stp priority priority.
[S1] stp root primary
Затем мы назначим S2 вторичным корневым мостом, чтобы S2 заменил S1 в качестве нового корневого моста в случае сбоя. После запуска на устройстве команды stp root secondary значение приоритета моста устройства автоматически устанавливается на 4096 и не может быть изменено после этого с помощью команды stp priority priority.
[S2] stp root secondary
На этом базовая конфигурация STP сети завершена. Чтобы проверить состояние и статистику дерева SPT, вы можете запустить display stp [interface interface-type
interface-number] [brief]
На S1 используйте команду display stp brief для отображения основной информации STP.
В выводимых данных видно, что, поскольку S1 является корневым мостом, GE0 / 0/2 и GE0 / 0/1 S1 являются назначенными портами в состоянии normal forwarding.
Следующий вывод - это основная информация STP S4.
Интерфейс GE0/0/2 коммутатора S4 является корневым портом в состоянии normal forwarding. Однако его порт GE0/0/1 является альтернативным портом в состоянии блокировки.