По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Протокол связующего дерева (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, таких как простая замена базового протокола плоскостью управления истинным состоянием канала.
Что такое логи Linux? Все системы Linux создают и хранят файлы логов информации для процессов загрузки, приложений и других событий. Эти файлы могут быть полезным ресурсом для устранения неполадок системы.
Большинство файлов логов Linux хранятся в простом текстовом файле ASCII и находятся в каталоге и подкаталоге /var/log. Логи создаются системным демоном логов Linux, syslogd или rsyslogd.
В этом руководстве вы узнаете, как находить и читать файлы логов Linux, а также настраивать демон ведения системных логов.
Как просматривать логи Linux
1. Сначала откройте терминал Linux как пользователь root. Это позволит получить root-права.
2. Используйте следующую команду для просмотра папки где находятся файлов логов:
cd /var/log
3. Чтобы просмотреть логи, введите следующую команду:
ls
Команда отображает все файлы логов Linux, такие как kern.log и boot.log. Эти файлы содержат необходимую информацию для правильного функционирования операционной системы.
Доступ к файлам логов осуществляется с использованием привилегий root. По определению, root - это учетная запись по умолчанию, которая имеет доступ ко всем файлам Linux.
Используйте следующий пример строковой команды для доступа к соответствующему файлу:
sudo less [log name here].log
Эта команда отображает временную шкалу всей информации, относящейся к этой операции.
Обратите внимание, что файлы логов хранятся в виде обычного текста, поэтому их можно просматривать с помощью следующих стандартных команд:
zcat - Отображает все содержимое logfile.gz
zmore - Просмотр файла по страницам, не распаковывая файлы
zgrep - Поиск внутри сжатого файла
grep - Найти все вхождения поискового запроса в файле или отфильтровать файл логов
tail - Выводит последние несколько строк файлов
head - Просмотр самого начала текстовых файлов
vim - Просмотр при помощи текстового редактора vim
nano - Просмотр при помощи текстового редактора nano
Важные системные логи Linux
Логи могут многое рассказать о работе системы. Хорошее понимание каждого типа файла поможет различать соответствующие логи.
Большинство каталогов можно сгруппировать в одну из четырех категорий:
Системные логи (System Logs)
Логи событий (Event Logs)
Логи приложений (Application Logs)
Логи обслуживания (Service Logs)
Многие из этих логов могут быть расположены в подкаталоге var/log.
Системные логи
Файлы логов необходимы для работы Linux. Они содержат значительный объем информации о функциональности системы. Наиболее распространенные файлы логов:
/var/log/syslog: глобальный системный журнал (может быть в /var/log/messages)
/var/log/boot.log: лог загрузки системы, где хранится вся информация, относящаяся к операциям загрузки
/var/log/auth.log: логи аутентификации, который хранит все логи аутентификации, включая успешные и неудачные попытки (может быть в /var/log/secure)
/var/log/httpd/: логи доступа и ошибок Apache
/var/log/mysqld.log: файл логов сервера базы данных MySQL
/var/log/debug: логи отладки, который хранит подробные сообщения, связанные с отладкой, и полезен для устранения неполадок определенных системных операций
/var/log/daemon.log: логи демона, который содержит информацию о событиях, связанных с запуском операции Linux
/var/log/maillog: логи почтового сервера, где хранится информация, относящаяся к почтовым серверам и архивированию писем
/var/log/kern.log: логи ядра, где хранится информация из ядра Linux
/var/log/yum.log: логи команд Yum
/var/log/dmesg: логи драйверов
/var/log/boot.log: логи загрузки
/var/log/cron: логи службы crond
Демон системных логов
Логирование осуществляется при помощи демона syslogd
Программы отправляют свои записи журнала в syslogd, который обращается к конфигурационному файлу /etc/syslogd.conf или /etc/syslog и при обнаружении совпадения записывает сообщение журнала в нужный файл журнала. Каждый файл состоит из селектора и поля ввода действия. Демон syslogd также может пересылать сообщения журнала. Это может быть полезно для отладки. Этот файл выглядит приерно так:
Dec 19 15:12:42 backup.main.merionet.ru sbatchd[495]: sbatchd/main: ls_info() failed: LIM is down; try later; trying ...
Dec 19 15:14:28 system.main.merionet.ru pop-proxy[27283]: Connection from 186.115.198.84
Dec 19 15:14:30 control.main.merionet.ru pingem[271] : office.main.merionet.ru has not answered 42 times
Dec 19 15:15:05 service.main.merionet.ru vmunix: Multiple softerrors: Seen 100Corrected Softerrors from SIMM J0201
Dec 19 15:15:16 backup.main.merionet.ru PAM_unix[17405]: (sshd) session closed 'for user trent
Логи приложений
Логи приложений хранят информацию, относящуюся к любому запускаемому приложению. Это может включать сообщения об ошибках, признаки взлома системы и строку идентификации браузера.
Файлы логов, которые попадают в эту категорию, включают логи системы печати CUPS, лог Rootkit Hunter, логи HTTP-сервера Apache, логи SMB-сервера Samba и лог сервера X11.
Логи не в удобочитаемом формате
Не все логи созданы в удобочитаемом формате. Некоторые предназначены только для чтения системными приложениями. Такие файлы часто связаны с информацией для входа. Они включают логи сбоев входа в систему, логи последних входов в систему и записи входа в систему.
Существуют инструменты и программное обеспечение для чтения файлов логов Linux. Они не нужны для чтения файлов, так как большинство из них можно прочитать непосредственно с терминала Linux.
Графические интерфейсы для просмотра файлов логов Linux
System Log Viewer - это графический интерфейс, который можно использовать для отслеживания системных логов.
Интерфейс предоставляет несколько функций для управления логами, включая отображение статистики лога. Это удобный графический интерфейс для мониторинга логов.
В качестве альтернативы можно использовать Xlogmaster, который может отслеживать значительное количество файлов логов.
Xlogmaster полезен для повышения безопасности. Он переводит все данные для выделения и скрытия строк и отображает эту информацию для выполнения действий, запрошенных пользователем.
Как настроить файлы логов в Ubuntu и CentOS
Начнем с примера CentOS. Чтобы просмотреть пользователей, которые в настоящее время вошли на сервер Linux, введите команду who от имени пользователя root:
Здесь также отображается история входа в систему пользователей. Для просмотра истории входа системного администратора введите следующую команду:
last reboot
Чтобы просмотреть информацию о последнем входе в систему, введите:
lastlog
Выполнить ротацию лога
Файлы логов, в конце которых добавлены нули, являются повернутыми файлами. Это означает, что имена файлов логов были автоматически изменены в системе.
Целью ротации логов является сжатие устаревших логов, занимающих место. Ротацию лога можно выполнить с помощью команды logrotate. Эта команда вращает, сжимает и отправляет системные логи по почте.
logrotate обрабатывает системы, которые создают значительные объемы файлов логов. Эта команда используется планировщиком cron и считывает файл конфигурации logrotate /etc/logrotate.conf. Он также используется для чтения файлов в каталоге конфигурации logrotate.
Чтобы включить дополнительные функции для logrotate, начните с ввода следующей команды:
var/log/log name here].log {
Missingok
Notifempty
Compress
Size 20k
Daily
Create 0600 root root
}
Он сжимает и изменяет размер желаемого файла логов.
Команды выполняют следующие действия:
missingok - сообщает logrotate не выводить ошибку, если файл логов отсутствует.
notifempty - не выполняет ротацию файла логов, если он пуст. Уменьшает размер файла лога с помощью gzip
size - гарантирует, что файл логов не превышает указанный размер, и поворачивает его в противном случае
daily - меняет файлы журналов по ежедневному расписанию. Это также можно делать по недельному или ежемесячному расписанию.
create - создает файл логов, в котором владелец и группа являются пользователем root
Итоги
Тщательное понимание того, как просматривать и читать логи Linux, необходимо для устранения неполадок в системе Linux. Использование правильных команд и инструментов может упростить этот процесс.
Redis - это решение с открытым исходным кодом для хранения структур данных. Он в основном используется как хранилище значений ключей, что позволяет ему работать как база данных, кеш-хранилище и брокер сообщений.
В этом руководстве мы рассмотрим различные способы удаления этих пар "ключ-значение" (ключей) и очистки кеша Redis.
Очистить кеш Redis с помощью команды redis-cli
Самый простой способ очистить кеш Redis - использовать команду redis-cli.
Базы данных в Redis хранятся индивидуально. Использование команды redis-cli позволяет удалить ключи либо из всех баз данных, либо только из одной указанной базы данных.
Синтаксис команды redis-cli
Команда redis-cli использует следующий синтаксис:
redis-cli [номер базы данных] [опция]
Где:
[опция] - позволяет выбрать между очисткой всех баз данных или одной конкретной базы данных по вашему выбору.
[номер базы данных] - позволяет указать, какую базу данных вы хотите очистить.
Примечание. После удаления ключей из базы данных их невозможно будет восстановить.
Удаление всех ключей
Чтобы удалить ключи из всех баз данных Redis, используйте следующую команду:
Redis-Cli Flushall
Начиная с версии 4.0.0, Redis может очищать ключи в фоновом режиме, не блокируя ваш сервер. Для этого используйте команду flushall с параметром async:
Redis-cli flushall async
Удаление ключей из определенной базы данных
Используйте следующую команду, чтобы очистить только определенную базу данных:
Redis-cli flushdb
Использование команды flushdb без каких-либо параметров очищает текущую выбранную базу данных. Используйте параметр -n с номером базы данных, чтобы выбрать конкретную базу данных, которую вы хотите очистить:
redis-cli -n [номер базы данных] flushdb
Вы также можете использовать параметр async при очистке ключей из отдельных баз данных:
redis-cli -n [номер базы данных] flushdb async
Автоматическая очистка кеша с помощью Ansible
Если у вас работает большое количество серверов Redis, очистка кеша для каждого из них вручную требует времени.
Чтобы ускорить этот процесс, используйте такой инструмент, как Ansible, чтобы очистить кеш на всех ваших серверах Redis одновременно:
ansible all -m command -a '/usr/bin/redis-cli flushall '
Выполнение этой команды применяет команду flushall к каждому серверу в вашем файле инвентаризации Ansible:
all - позволяет выбрать все удаленные хосты в файле инвентаризации Ansible.
-m - позволяет выбрать модуль для выполнения.
-a - Предоставляет аргумент для модуля. В этом случае командный модуль запускает команду flushall с помощью redis-cli.