Куда по умолчанию маршрутизаторы и коммутаторы Cisco отправляют сообщения о важных событиях журнала
Обновлено: 21.11.2024
Привет! Похоже, у вас отключен JavaScript. Пожалуйста, включите его, чтобы вы могли видеть и взаимодействовать со всем на нашем сайте.
Системный журнал — это хорошо. Это стандартный сетевой протокол ведения журнала, который работает на самых разных типах устройств и приложений, позволяя им бесплатно отправлять сообщения журнала в текстовом формате на центральный сервер.
Практически каждое устройство в вашей сети — будь то хранилище или сервер, коммутатор или брандмауэр — скорее всего, имеет агент системного журнала, который вы можете использовать для отправки сообщений в общее центральное расположение.
Когда используется системный журнал?
Люди, знакомые с SNMP, могут немного запутаться. Зачем нам системный журнал, если у нас уже есть ловушки SNMP? Конечно, они оба предоставляют схожие функции.
Они оба используются для отправки предупреждений и сообщений на центральный сервер без необходимости опроса. Как только происходит событие, сообщение можно отправить, не дожидаясь, пока сервер запросит статус.
Самое большое отличие состоит в том, что ловушки SNMP имеют специальный предопределенный формат, который содержится в файле MIB. Если интерфейс на коммутаторе выходит из строя, файл MIB определяет сообщение-ловушку «ifDown», которое включает полезную информацию, такую как конкретный интерфейс. Это здорово, если вы заранее знаете, какую именно информацию будет содержать сообщение. Но иногда нет.
Есть два действительно важных случая, когда нецелесообразно иметь файл MIB с предопределенными типами сообщений. Первый — это тот, для которого изначально был изобретен системный журнал: оповещение приложений.
Предположим, вы написали собственное приложение, которое выполняет какую-то бизнес-функцию. Такие приложения, как правило, имеют огромное количество журнальных сообщений, и каждый новый выпуск программного обеспечения может содержать кучу новых сообщений. Просто нецелесообразно создавать новый файл MIB для каждого из этих сообщений и загружать его на центральный сервер регистрации для каждого выпуска программного обеспечения. Файл MIB всегда будет отставать на одну-две версии, и центральный сервер не сможет анализировать новые типы сообщений.
Второй важный случай – сообщения журналов для устройств безопасности, таких как IDS (системы обнаружения вторжений). Эти системы постоянно пополняются новыми сигнатурами. В информации, обнаруживаемой этими сигнатурами, может быть так много различий, что практически невозможно стандартизировать сообщения о событиях. Кроме того, многие коммерческие системы IDS подписываются на услуги, которые ежедневно загружают новые сигнатуры.
Поэтому ловушки SNMP используются для четко определенных событий, таких как сброс интерфейса, особенно на сетевых устройствах, а события системного журнала лучше всего подходят для событий, которые носят более общий характер и которые труднее предсказать.
Свободная форма сообщений системного журнала — это самая большая сила системного журнала, но также и самая большая проблема системного журнала. Очень сложно анализировать журнал, включая события из десятков разных систем от разных поставщиков, и одновременно понимать их. Какие сообщения представляют какие функции? И какие из них представляют собой критические события, а какие просто информационные сообщения?
Чтобы ответить на эти вопросы, протокол системного журнала (который определен в RFC 5424) предоставляет этим сообщениям в произвольной форме специальные поля, называемые "объект" и "серьезность".
(Обратите внимание, что RFC 5424 является стандартом для системного журнала, но не все реализации системного журнала соответствуют RFC 5424. Протокол системного журнала существует уже очень давно, и до сих пор используются некоторые предстандартные реализации.)< /p>
Что такое коды серьезности и объекта?
Значение серьезности легко понять. Он включает одно число от 0 до 7, которое указывает, насколько важно сообщение.
| Цифровой код | Серьезность | Значение |
| 0 | Аварийная ситуация | Система недоступна |
| 1 | Предупреждение | < td>Действия должны быть предприняты немедленно|
| 2 | Критические | Критические условия |
| 3 | Ошибка | Состояния ошибки |
| 4 | Предупреждение | Предупреждающие условия |
| 5 | Уведомление | Нормальное, но важное условие |
| 6 | Информационные | Информационные сообщения |
| 7 | Отладка | Отладка сообщения уровня |
На практике вы обычно не видите сообщений экстренного уровня, потому что, если система настолько сильно повреждена, она, вероятно, не сможет отправить сообщение. И вы, вероятно, не хотите видеть сообщения об отладке в своем журнале, потому что их будет слишком много, и они редко важны для операционных целей.Таким образом, в типичных производственных системах обычно устанавливается уровень ведения журнала 5 или 6. Отправляющая система может хранить локальную копию менее серьезных сообщений, но не будет отправлять их на центральный сервер.
Код объекта требует дополнительных пояснений. Ранние реализации программного обеспечения сервера syslog обычно просто сохраняли входящие сообщения в один или несколько файлов журнала. Серверная система использовала код объекта для сортировки связанных сообщений в один и тот же файл. Современные реализации системного журнала просто сбрасывают все сообщения в общую базу данных и используют код объекта просто как один из многих возможных ключей поиска.
Коды объектов также являются числовыми значениями, которые перечислены в следующей таблице. Обратите внимание, что многие из них очень специфичны для систем, которые во многих случаях больше не используются. Это коды объектов, определенные в RFC 5424, которые несколько отличаются от тех, что используются в BSD Unix. Различия в основном представляют собой исторический курьез и на самом деле не так уж важны для большинства целей.
| Цифровой код | Название объекта | Использование |
| 0 | Сообщения ядра | Ядро Unix |
| 1 | Сообщения уровня пользователя< /td> | Оповещения приложений пользователя |
| 2 | Почтовая система | Почта Unix |
| 3 | Системные демоны | Системные процессы Unix |
| 4 | Безопасность/ сообщения авторизации | Сообщения аутентификации/авторизации Unix |
| 5 | Сообщения, генерируемые внутри syslogd | Процесс системного журнала сама |
| 6 | подсистема построчного принтера | построчный принтер Unix |
| 7 | Подсистема сетевых новостей | Система новостей Unix |
| 8 | Подсистема UUCP | Протокол копирования Unix-to-Unix |
| 9 | Демон часов | |
| 10 | Сообщения безопасности/авторизации | |
| 11 | Демон FTP | |
| 12 | Подсистема NTP | |
| 13 | Аудит журнала | 14 | Оповещение журнала |
| 15 | Демон часов | |
| 16 (local0) | Местное использование 0 | |
| 17 (local1) | Местное использование 1 | < /tr>|
| 18 (local2) | Местное использование 2 | |
| 19 (local3) | Местное использование 3 | |
| 20 (local4) | Местное использование 4 | |
| 21 (local5) | Местное использование 5 | |
| 22 (local6) | Местное использование 6 | |
| 23 (local7) | Местное использование 7 |
Обратите внимание, что многие из этих кодов объектов относятся к устаревшим устаревшим системам Unix. Например, никто больше не использует UUCP. Это был асинхронный способ автоматического копирования файлов между серверами, которые могли обмениваться данными только посредством аналогового коммутируемого доступа.
Коды объекта и серьезности появляются в начале каждого сообщения системного журнала и заключаются в угловые скобки. Например, « » будет означать сообщение службы «local0» серьезности 6.
В наши дни большинство сетевых устройств используют один из «локальных» кодов для сообщений системного журнала. По умолчанию брандмауэры Cisco ASA будут использовать код объекта 20 (local4), в то время как большинство коммутаторов и маршрутизаторов Cisco будут использовать код 23 (local7). Эти коды существуют исключительно для удобства сервера системного журнала для сортировки входящих сообщений по полезным категориям. Большинству людей не нужно их менять, потому что, как отмечалось ранее, в современных реализациях системного журнала код объекта — это лишь одно из многих возможных значений ключа, которые используются для поиска в базе данных сообщений.
Как транспортируется системный журнал?
Существует два распространенных способа отправки сообщений системного журнала. Хотя RFC 5424 требует, чтобы все реализации системных журналов поддерживали зашифрованный сетевой транспорт TLS через TCP, большинство сообщений системных журналов по-прежнему доставляются с использованием старого метода UDP.
В версии UDP сообщения просто помещаются в часть данных пакета UDP и отправляются на сервер через порт UDP 514. Каждое сообщение обычно помещается в один пакет. UDP не имеет состояния и сеанса, поэтому подтверждения нет. Пакеты просто отправляются в сеть. Это имеет очевидную проблему, заключающуюся в том, что любая сетевая проблема может помешать доставке пакета, и в этом случае вы можете не знать, что сеть не работает, потому что она не может вам об этом сказать. Это также означает, что иногда важные пакеты могут быть потеряны или повреждены при передаче.
Еще одна важная вещь, которую следует помнить о транспорте системного журнала UDP, заключается в том, что он не зашифрован. Таким образом, пакеты могут быть перехвачены и прочитаны, и их можно даже относительно легко подделать.Поэтому никогда не рекомендуется отправлять пакеты системного журнала UDP через общедоступный Интернет, если они также не туннелируются в какой-либо зашифрованной VPN.
Поскольку TCP основан на сеансе, удаленные устройства откроют сеанс TCP с сервером и, как правило, будут поддерживать его активным при доставке всех сообщений в очереди. В случае таких устройств, как брандмауэры, которые отправляют огромное количество сообщений системного журнала, это может означать непрерывное подключение в течение длительного периода времени.
У этого метода есть несколько ключевых преимуществ. Во-первых, поскольку сессия зашифрована, их невозможно прочитать в полете. Во-вторых, поскольку каждое устройство имеет уникальный сертификат, сервер может подтвердить, что устройство действительно является тем, за кого себя выдает, что предотвращает подделку поддельных сообщений. В-третьих, поскольку сеанс основан на протоколе TCP, гарантируется доставка каждого сообщения, при этом ни одно сообщение не будет потеряно, и их можно будет передать повторно, если они будут потеряны или повреждены при передаче.
Но у него есть и недостатки. Если центральный сервер принимает сообщения от большого количества устройств, он может страдать от проблем с ресурсами из-за количества одновременных TCP-соединений. Его также сложнее настроить.
Теперь мы рассмотрели основы системного журнала. В моей следующей статье я покажу вам, как включить версии системного журнала UDP и TLS на устройстве Cisco.
О Кевине Дули
Кевин имеет более чем 15-летний опыт работы сетевым инженером. Он спроектировал и реализовал несколько самых крупных и сложных корпоративных сетей передачи данных в Канаде и написал несколько высоко оцененных книг по сетевым технологиям для O'Reilly and Associates, в том числе Designing Large-Scale LANs и Cisco IOS Cookbook. Кевин имеет докторскую степень. по теоретической физике и многочисленные отраслевые сертификаты.
4 комментария к теме «Что такое системный журнал и как он работает?»
Теперь ключевой вопрос…. Как мы можем позволить Auvik использовать данные системного журнала? Настраиваем ли мы собственный сервер системного журнала или можем направить наши устройства на общий IP-адрес Auvik?
Привет, Алан! Есть ли какое-нибудь руководство по переносу журнала OpenShift в Syslog? Я имею в виду руководство по настройке. Если это так, вы можете попытаться указать мне.
Райан Лафламм говорит:
Привет, Скайлэб. В настоящее время у нас нет руководств по OpenShift, но мы об этом подумаем! Спасибо за вопрос!
Даже если вы никогда раньше не слышали о системном журнале, вы, вероятно, видели его, когда работали с маршрутизатором или коммутатором. Взгляните на следующие строки:
Всякий раз, когда на маршрутизаторе или коммутаторе происходит что-то интересное, Cisco IOS информирует нас в режиме реального времени. Это делается системным журналом.
По умолчанию эти сообщения системного журнала выводятся только на консоль. Это связано с тем, что команда консоли ведения журнала включена по умолчанию. Если вы войдете через telnet или SSH, вы не увидите никаких сообщений системного журнала. Вы можете включить это с помощью команды монитора терминала.
Сохранение сообщений системного журнала
Местная история
Вход в консоль или telnet/SSH полезен, если вы рядом, но что, если вас нет или если вы хотите просмотреть старые сообщения? К счастью для нас, Cisco IOS хранит историю сообщений системного журнала. Мы можем увидеть это с помощью команды show logging:
Выше мы можем видеть некоторые сообщения системного журнала в нашей истории, он будет хранить до 8192 байт сообщений системного журнала в своей оперативной памяти. Когда вы перезагрузите маршрутизатор или коммутатор, история исчезнет. Можно увеличить размер буфера протоколирования. Например:
Сервер системного журнала
Локальная история — это хорошо, но она хранится в оперативной памяти. Если вы перезагрузите маршрутизатор или коммутатор, он исчезнет. Что делать, если маршрутизатор вышел из строя, и вы хотите посмотреть, записывал ли он что-либо до того, как он вышел из строя? Если у вас есть десятки маршрутизаторов и коммутаторов, вход на каждое устройство по одному для поиска сообщений системного журнала также не лучший способ тратить время.
В рабочих сетях мы используем центральный сервер, называемый сервером системного журнала. Системный журнал — это протокол, стандарт, и вы можете настроить свои маршрутизаторы и коммутаторы для пересылки сообщений системного журнала на сервер системного журнала следующим образом:
Вот скриншот сервера системного журнала:
Выше вы можете видеть некоторые сообщения системного журнала от 192.168.1.1 (мой маршрутизатор). Вы также можете использовать фильтры для поиска определенных сообщений системного журнала и многого другого.
Формат сообщения системного журнала
Давайте подробнее рассмотрим одно из сообщений системного журнала:
Выше мы видим, что линейный протокол интерфейса GigabitEthernet0/1 вырос, но информации немного больше. Позвольте мне объяснить, как Cisco IOS форматирует эти сообщения журнала:
- Временная метка: 14 февраля 0:40:10.326
- объект: %LINEPROTO
- уровень серьезности: 5
- мнемоника: UPDOWN
- описание: линейный протокол на интерфейсе GigabitEthernet0/1, изменено состояние на рабочее
Отметка времени говорит сама за себя, без нее вы никогда не узнаете, когда произошло событие. Его можно отключить и/или заменить порядковыми номерами. Вот краткий пример:
Вот как включить порядковые номера:
Системный журнал — это, по сути, процесс, создавший сообщение системного журнала. Если вы посмотрите на некоторые сообщения системного журнала выше, вы увидите %LINEPROTO, который отслеживает линейные протоколы, %SYS для общих системных сообщений и %LINK для интерфейсов, которые активировались или отключались.
Уровень серьезности очень важен, он говорит нам, насколько важно сообщение. Не все, что происходит на вашем маршрутизаторе или коммутаторе, одинаково важно. Я вернусь к этому чуть позже.
Мнемоника — это короткий код сообщения. Например, «UPDOWN» для интерфейсов, которые поднимаются или опускаются. «ИЗМЕНЕНО» при изменении состояния интерфейса и т. д. Это может быть полезно, если вы просматриваете некоторые сообщения системного журнала в поисках определенных типов сообщений.
Уровни серьезности системного журнала
Давайте подробнее рассмотрим уровни серьезности. Существуют различные уровни серьезности для регистрируемой информации. Интерфейс, который выходит из строя, вероятно, важнее знать, чем сообщение о том, что мы вышли из глобальной конфигурации. Всего существует 8 уровней серьезности:
<р>0. Чрезвычайная ситуация1. Предупреждение
2. Критический
3. Ошибка
4. Предупреждение
5. Обратите внимание
6. Информационная
7. Отладка
чем меньше число, тем важнее сообщение системного журнала. Оповещения и экстренные ситуации используются, когда происходит что-то плохое, например, когда у вашего маршрутизатора заканчивается память и происходит сбой процесса. Критические сообщения, сообщения об ошибках и предупреждения используются для важных событий, таких как отказ интерфейсов. Вот пример:
Выше вы можете увидеть 5 для интерфейса, который был отключен администратором. Вот резервная копия интерфейса:
Это событие считается важным событием с уровнем серьезности 3.
Если вы отлаживаете что-то на маршрутизаторе, вы, вероятно, хотите видеть свои сообщения об отладке на своей консоли, но, возможно, вы не хотите отправлять те же самые сообщения на сервер системного журнала или в локальную историю системного журнала маршрутизатора. Cisco IOS позволяет вам определить, какие сообщения системного журнала вы хотите видеть, сохранять или отправлять на сервер системного журнала. Например:
С помощью команды logging console я могу решить, какие уровни серьезности я хочу видеть в консоли. По умолчанию отображается все, вплоть до отладочных сообщений, что нормально:
Я могу сделать то же самое для сообщений системного журнала, когда вы вошли в систему через telnet или SSH:
Поскольку локальное хранилище маршрутизатора или коммутатора ограничено, возможно, вы захотите хранить только предупреждения и более высокие уровни серьезности:
Вы можете проверить это с помощью следующей команды:
И на наш сервер системных журналов отправим все, кроме отладочных сообщений:
Syslog – это способ, с помощью которого сетевые устройства отправляют сообщения о событиях на сервер регистрации, обычно называемый сервером Syslog.
Протокол Syslog поддерживается широким спектром устройств и может использоваться для регистрации различных типов событий. Например, маршрутизатор может отправлять сообщения о входе пользователей в сеансы консоли, а веб-сервер может регистрировать события отказа в доступе.
Большинство сетевого оборудования, например маршрутизаторы и коммутаторы, могут отправлять сообщения Syslog.
Кроме того, серверы *nix также могут генерировать данные Syslog, как и большинство брандмауэров, некоторые принтеры и даже веб-серверы, такие как Apache.
Серверы на базе Windows изначально не поддерживают Syslog, но большое количество сторонних инструментов позволяет легко собирать журнал событий Windows или данные IIS и пересылать их на сервер Syslog.
В отличие от SNMP, Syslog нельзя использовать для «опроса» устройств для сбора информации.
Например, SNMP имеет сложную иерархическую структуру, которая позволяет станции управления запрашивать у устройства информацию о таких вещах, как данные о температуре или доступном месте на диске.
С системным журналом это невозможно — он просто отправляет сообщения в центральное место при возникновении определенных событий.
Серверы системного журнала
Системный журнал – это отличный способ объединить журналы из нескольких источников в одном месте. Как правило, большинство серверов Syslog имеют несколько компонентов, делающих это возможным.
Сообщения системного журнала
Мы не будем подробно останавливаться на сообщениях Syslog, но есть несколько важных вещей, которые нужно знать.
Сообщения системного журнала обычно содержат информацию, помогающую определить основную информацию о том, куда, когда и почему был отправлен журнал: IP-адрес, отметку времени и фактическое сообщение журнала.
Сообщения иногда имеют описательный, удобочитаемый формат, но не всегда!
Syslog использует концепцию под названием "средство" для определения источника сообщения на любом заданном компьютере. Например, средство «0» будет сообщением ядра, а средство «11» будет сообщением FTP.
Это восходит к корням Syslog в UNIX. Большинство сетевого оборудования Cisco использует коды доступа «Local6» или «Local7».
Сообщения системного журнала также имеют поле уровня серьезности. Уровень серьезности показывает, насколько важным считается сообщение.
Серьезность "0" – это чрезвычайная ситуация, "1" – предупреждение, требующее немедленных действий, а шкала продолжается вплоть до "6" и "7" – информационные и отладочные сообщения.
Недостатки системного журнала
У Syslog есть несколько недостатков.
Во-первых, проблема согласованности.
Протокол Syslog не определяет стандартный способ форматирования содержимого сообщения, а способов форматирования сообщения столько же, сколько разработчиков.
Некоторые сообщения могут быть удобочитаемыми для человека, а некоторые нет. Системному журналу все равно — он просто предоставляет способ передачи сообщения.
Есть также некоторые проблемы, возникающие из-за того, как Syslog использует UDP в качестве транспорта. UDP не требует установления соединения и не гарантируется, поэтому сообщения журнала могут быть потеряны из-за перегрузки сети или потери пакетов.
Наконец, есть некоторые проблемы с безопасностью системного журнала.
В сообщениях системного журнала нет проверки подлинности, поэтому один компьютер может выдавать себя за другой компьютер и отправлять поддельные события журнала. Он также подвержен повторным атакам.
Несмотря на это, многие администраторы считают системный журнал ценным инструментом, а его недостатки относительно незначительны.
Обзор
Как видите, системный журнал может быть мощным инструментом, упрощающим администраторам управление сложными сетями.
Одна из самых больших проблем с системным журналом — это объем данных. Программное обеспечение сервера журналов должно упростить управление журналами и помочь администраторам фильтровать сообщения и сосредоточиться на действительно важных сообщениях.
В следующем посте мы покажем вам некоторые инструменты, которые вы можете использовать, чтобы получить максимальную отдачу от Syslog, а пока вы можете загрузить бесплатную версию Kiwi Syslog, чтобы начать работу в Windows с ниже!
А пока ознакомьтесь с нашими обзорами систем управления сетью, которые также поддерживают функции Syslog, например OpManager от ManageEngine, SolarWinds Orion NPM или OpenNMS.
Сообщение системного журнала — это системное сообщение, создаваемое маршрутизаторами и коммутаторами, которое используется для информирования сетевых администраторов о полезной информации о работоспособности и состоянии устройства, а также о сетевых событиях и инцидентах, произошедших в данный момент времени. Ведение журналов системного журнала является важной частью нашей сетевой системы, поскольку упрощает устранение неполадок и повышает безопасность, обеспечивая видимость журналов всех наших инфраструктурных устройств и оборудования, которыми мы управляем. Ниже мы обсудим различные места ведения журнала Cisco и настройку ведения журнала системного журнала в этих местах.
ПРИМЕЧАНИЕ
По умолчанию устройства Cisco IOS отправляют сообщения Syslog на линию консоли и в буфер регистрации. Однако вы также можете настроить отправку сообщений Syslog на терминальные линии, ловушки SNMP и серверы Syslog.
Места регистрации Cisco
Сообщения системного журнала могут записываться в различные места. Вот четыре способа и места, где мы можем хранить и отображать сообщения на наших устройствах Cisco:
- Буфер ведения журнала — события сохраняются в оперативной памяти маршрутизатора или коммутатора. Буфер имеет фиксированный размер, чтобы гарантировать, что сообщения журнала не будут занимать ценную системную память. Он включен по умолчанию.
- Консольная строка — события будут отображаться в интерфейсе командной строки, когда вы входите в систему через консольное соединение. Он включен по умолчанию.
- Терминальные линии — сообщения журнала будут отображаться в интерфейсе командной строки при входе в систему через сеанс Telnet или SSH. По умолчанию он отключен.
- Syslog Server — сообщения журнала сохраняются на сервере Syslog.
Конфигурация ведения журнала системного журнала
Теперь мы увидим различные конфигурации системного журнала, которые вы можете выполнять на своих сетевых устройствах в зависимости от местоположения, предпочтений и потребностей.
Конфигурация буфера регистрации
Первое, что мы собираемся настроить, — это буфер ведения журнала с помощью команды конфигурации logging buffered. Мы также установим размер его буфера и уровни серьезности ведения журнала.
ПРИМЕЧАНИЕ.
Устройства Cisco IOS по умолчанию имеют размер буфера журнала 4096, но вы можете изменить его в зависимости от ваших предпочтений.
Конфигурация линии консоли
Конфигурация системного журнала в строке консоли включена по умолчанию. Однако, если вы хотите отключить ведение журнала в консольной строке, используйте команду «без ведения журнала»:
ПРИМЕЧАНИЕ
Когда вы выполняете синхронное ведение журнала в режиме глобальной конфигурации, сообщения журнала, отправляемые в строку консоли, не будут прерывать ввод команды, и команда будет перемещена на новую строку.
Конфигурация линии терминала
Вы также можете настроить Syslog для отправки сообщений в линии терминала VTY с помощью команды «terminal monitor»:
ПРИМЕЧАНИЕ
Причина, по которой терминальные линии отключены по умолчанию в Cisco IOS, заключается в том, что это может привести к перегрузке ваших терминальных подключений VTY из-за большого количества сообщений журнала, отправляемых в линии, когда они неправильно настроены.
Конфигурация сервера системного журнала
Важно добавить в нашу сеть внешний сервер системного журнала, поскольку он обеспечивает централизованное хранение и управление. Это гарантирует, что все сообщения о сетевых событиях и инцидентах записываются и регистрируются на сервере. Это значительно упрощает работу с журналами, поскольку сообщения могут храниться на жестком диске сервера Syslog, а не на самом маршрутизаторе, что освобождает память маршрутизатора. По умолчанию эти сообщения отправляются на узел регистрации через UDP-порт 514.
Чтобы включить это, сначала мы настроим IP-адрес сервера Syslog, который будет использоваться, введя команду «logging». Затем мы указываем тип сообщения, которое мы хотим отправить на сервер системного журнала.
Далее мы указываем локальную метку времени для использования с сообщениями Syslog, которые будут отправляться на сервер Syslog, поскольку он не включен по умолчанию.
Давайте посмотрим и проверим настроенное нами ведение журнала системного журнала и выходные данные журнала в разных местах с помощью команды «show logging».
Как видно из выходных данных, буфер журналирования включен с размером выходных данных 1000 байт и уровнем серьезности «отладка». Ведение журнала линии консоли отключено, как мы его настроили, но линия терминала включена. Наконец, вы можете видеть, что R1 использует сервер системного журнала с IP-адресом 10.0.0.100 и уровнем серьезности «отладка».
Информация о безопасности и управление событиями (SIEM)
Систему SIEM можно рассматривать как централизованный сервер журналов, поскольку он обеспечивает централизованное размещение всех сообщений журналов. Как правило, он обеспечивает расширенный анализ и корреляцию событий. Он в основном используется для администрирования безопасности и аудита.
Загрузите наше бесплатное учебное пособие CCNA в формате PDF, чтобы получить полные заметки по всем темам экзамена CCNA 200–301 в одной книге.
Мы рекомендуем Cisco CCNA Gold Bootcamp в качестве основного учебного курса CCNA. Это онлайн-курс Cisco с самым высоким рейтингом со средней оценкой 4,8 из более чем 30 000 общедоступных обзоров и золотой стандарт в обучении CCNA:
Читайте также: