Оборудование «Булат»

Сетевое оборудование «Булат» генерирует системные сообщения о состоянии интерфейсов, сетевых протоколов, аппаратных компонентов, действиях администраторов, изменениях конфигурации, ошибках и других событиях.

Современные коммутаторы «Булат», включая серию BS7600-b, работают под управлением собственной операционной системы BulatOS. Оборудование поддерживает Syslog и может передавать системные события на централизованный сервер журналирования.

Подключение оборудования к LOGG позволяет хранить историю работы сети, искать события сразу по множеству устройств, восстанавливать их последовательность и сопоставлять сетевые журналы с событиями серверов, приложений и другой технологической инфраструктуры.

Важно: линейка «Булат» включает несколько поколений оборудования и программного обеспечения. Синтаксис CLI может различаться между сериями и версиями BulatOS. Перед массовым применением конфигурации необходимо сверить команды с руководством для конкретной модели и версии ПО.

Что можно собирать

В LOGG могут передаваться события:

физических и логических интерфейсов;
LAG / LACP;
MC-LAG;
VLAN;
STP/RSTP/MSTP;
LLDP;
маршрутизации;
OSPF;
BGP;
VRRP;
EVPN/VXLAN на соответствующих моделях;
аппаратных компонентов;
питания, вентиляторов и температуры;
перезагрузок оборудования;
системных процессов;
SSH и административного доступа;
действий пользователей;
изменений конфигурации;
ошибок и предупреждений;
событий безопасности.

Конкретный набор сообщений зависит от модели оборудования, версии BulatOS и настроенной политики журналирования.

Типовая схема подключения

Для централизованного сбора используется Syslog:

text

Оборудование «Булат»
        │
        │ Syslog
        ▼
       LOGG

В классической конфигурации используется UDP/514.

LOGG должен быть доступен из сети управления оборудованием.

Базовая настройка

На оборудовании с CLI, использующим синтаксис logging host, типовая конфигурация выглядит следующим образом:

text

configure terminal

logging host 192.0.2.10 port 514 severity informational facility local7
logging buffered informational

exit

Где:

192.0.2.10 — IP-адрес LOGG;
514 — стандартный UDP-порт Syslog;
informational — уровень журналирования;
local7 — Syslog facility.

Для конкретной версии BulatOS следует проверить точный формат команды logging host.

Уровни журналирования

Syslog использует стандартные уровни severity:

Уровень	Название	Назначение
0	emergencies	система неработоспособна
1	alerts	требуется немедленное вмешательство
2	critical	критическая ошибка
3	errors	ошибка
4	warnings	предупреждение
5	notifications	важное штатное событие
6	informational	информационное сообщение
7	debugging	отладочная информация

Для централизованного эксплуатационного мониторинга рекомендуется начинать с:

text

severity informational

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

Например:

text

Interface Down
LAG member changed
STP topology changed
BGP neighbor down
Administrator login
Configuration changed

Именно такие сообщения часто позволяют восстановить реальную последовательность развития аварии.

Уровень debugging рекомендуется использовать только временно для диагностики конкретной проблемы.

Facility

Если версия ПО поддерживает выбор facility, для сетевого оборудования удобно использовать единое значение:

text

facility local7

Например, внутри инфраструктуры можно принять соглашение:

text

Network Equipment → local7 → LOGG

Это упрощает классификацию сообщений и построение правил их обработки.

Локальный буфер

Помимо отправки сообщений в LOGG рекомендуется сохранять оперативный журнал непосредственно на устройстве.

Типовая команда для оборудования с соответствующим CLI:

text

logging buffered informational

Локальный журнал полезен:

при временной недоступности LOGG;
при потере management-сети;
при диагностике самого устройства;
для проверки генерации события.

При этом LOGG используется как основное долговременное централизованное хранилище.

Журналирование CLI-команд

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

Если эта возможность поддерживается используемой версией ПО, она может включаться командой вида:

text

logging cli-commands

После этого в централизованном журнале можно сопоставлять административные действия с последующими изменениями инфраструктуры.

Например:

text

14:05:02  administrator login
14:06:17  CLI command
14:06:35  configuration changed
14:06:37  interface down
14:06:38  BGP neighbor down
14:06:41  route changed

Для LOGG это особенно ценный сценарий: становится видна не только сама авария, но и события, непосредственно ей предшествовавшие.

Стабильная идентификация устройства

При наличии нескольких сетевых интерфейсов желательно использовать стабильный IP-адрес источника Syslog.

Предпочтительно использовать:

Loopback;
management interface;
другой постоянный адрес устройства.

Логика выглядит следующим образом:

text

BS-CORE-01
Loopback0: 10.10.10.1
      │
      │ Syslog
      ▼
     LOGG

Если используемая версия BulatOS предоставляет настройку source-interface для Syslog, рекомендуется использовать именно ее.

Точный синтаксис необходимо проверить для конкретной версии ПО.

Имена оборудования

Все устройства рекомендуется снабдить уникальными и понятными hostname.

Например:

text

DC1-BULAT-CORE-01
DC1-BULAT-CORE-02

DC1-BULAT-AGG-01
DC1-BULAT-AGG-02

DC1-BULAT-ACCESS-001

При наличии сотен устройств это существенно упрощает работу с журналами по сравнению с идентификацией исключительно по IP-адресам.

Несколько серверов

Если конкретная версия ПО позволяет определить несколько Syslog hosts, можно использовать схему:

text

                   ┌── LOGG-1
Оборудование ──────┤
                   └── LOGG-2

или:

text

                   ┌── LOGG
Оборудование ──────┤
                   └── SIEM

Такой подход позволяет организовать:

резервирование;
параллельную обработку;
интеграцию с SIEM;
миграцию между системами журналирования.

Время и NTP

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

Оборудование «Булат» поддерживает NTP.

Все устройства и LOGG желательно синхронизировать с согласованными источниками времени.

Необходимо контролировать:

дату;
время;
временную зону;
состояние NTP;
доступность серверов времени.

После этого LOGG сможет корректно построить последовательность:

text

10:21:14.102  CORE-01    Interface Down
10:21:14.315  CORE-01    LAG member Down
10:21:14.827  AGG-02     STP topology changed
10:21:15.201  CORE-02    BGP route changed
10:21:17.648  APP-01     Connection timeout

Без единого времени такие сообщения остаются набором отдельных фактов.

События ядра и агрегации

Для коммутаторов «Булат», используемых на уровне ядра и агрегации, особенно важны события:

text

Physical Interface
        ↓
LAG / MC-LAG
        ↓
Routing
        ↓
Network Path
        ↓
Service

Например:

text

100G interface down
        ↓
LAG member lost
        ↓
routing adjacency changed
        ↓
routes changed
        ↓
traffic moved to alternate path

LOGG позволяет собрать сообщения нескольких устройств и увидеть эту последовательность как единое событие инфраструктуры.

EVPN/VXLAN

Современные серии «Булат», включая BS7600-b, ориентированы в том числе на применение в ЦОД и поддерживают EVPN/VXLAN.

Для такой инфраструктуры централизованный журнал особенно важен.

События могут развиваться по цепочке:

text

Physical Link
      ↓
Underlay Routing
      ↓
BGP
      ↓
EVPN
      ↓
VXLAN
      ↓
Service

Отдельное устройство показывает только собственную часть происходящего.

LOGG позволяет сопоставить сообщения Leaf, Spine, серверов и приложений в общей временной шкале.

Фильтрация

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

Минимальный механизм управления объемом — выбор severity:

text

severity informational

Для отдельных групп оборудования можно применять разные политики.

Например:

text

CORE        → informational
AGGREGATION → informational
ACCESS      → notifications

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

Однако на первом этапе рекомендуется не фильтровать поток слишком агрессивно.

Практический подход:

собрать → измерить → классифицировать → фильтровать.

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

Проверка настройки

После настройки необходимо проверить конфигурацию журналирования.

На CLI с соответствующим синтаксисом полезно проверить конфигурацию командой вида:

text

show running-config

и состояние журналирования:

text

show logging

Также необходимо проверить доступность LOGG:

text

ping 192.0.2.10

После этого следует убедиться, что устройство появилось среди источников LOGG.

Проверка с помощью тестового события

После настройки желательно создать безопасное контролируемое событие.

Например:

выполнить административный вход;
создать штатное изменение состояния;
выполнить действие, которое гарантированно фиксируется системным журналом.

Затем необходимо:

найти сообщение в локальном журнале;
найти то же сообщение в LOGG;
проверить hostname;
проверить source IP;
проверить timestamp;
проверить severity;
проверить facility.

Только после успешного теста шаблон рекомендуется распространять на другие устройства той же модели и версии ПО.

Если сообщения не поступают

Последовательно проверьте:

Включено ли журналирование.
Настроен ли удаленный Syslog host.
Правильно ли указан IP-адрес LOGG.
Правильно ли указан порт.
Доступен ли LOGG с устройства.
Есть ли маршрут до сервера.
Не блокируется ли UDP/514 ACL или межсетевым экраном.
Правильно ли выбран severity.
Правильно ли определен source interface.
Генерируются ли события в локальном журнале.
Принимает ли LOGG сообщения на соответствующем интерфейсе и порту.
Синхронизировано ли время устройства.

Для первичной диагностики используются команды соответствующей версии BulatOS:

text

show logging
show running-config
ping 192.0.2.10

Массовая настройка

При наличии десятков или сотен устройств Syslog следует рассматривать не как настройку отдельного коммутатора, а как единую политику журналирования сети.

Политика должна определять:

серверы LOGG;
транспорт и порт;
severity;
facility;
source address;
hostname;
NTP;
локальное журналирование;
журналирование административных действий;
правила фильтрации.

Парк оборудования сначала рекомендуется классифицировать:

text

BulatOS version
      │
      ├── BS7600-b
      ├── BS7500
      ├── BS5100 / BS5120
      └── другие серии

Для каждой группы формируется и проверяется собственный шаблон CLI.

Это позволяет централизованно подключить к LOGG большое количество оборудования без риска применения несовместимых команд.

Что дает подключение оборудования «Булат» к LOGG

Отдельный коммутатор может сообщить:

text

Interface Down
LAG Changed
BGP Neighbor Down
Route Changed

Но это только локальные симптомы.

LOGG объединяет журналы оборудования ядра, агрегации и доступа с событиями маршрутизаторов, серверов, операционных систем и приложений.

Вместо набора сообщений появляется последовательность:

физический интерфейс потерян → агрегированный канал изменился → соседство маршрутизации разорвано → маршруты перестроились → сервис испытал деградацию.

Так журналы превращаются из архива сообщений в историю поведения инфраструктуры.

Множество устройств — единая картина событий.

LOGG: события, связи, влияние.

Оборудование «Булат» ​

Что можно собирать ​

Типовая схема подключения ​

Базовая настройка ​

Уровни журналирования ​

Facility ​

Локальный буфер ​

Журналирование CLI-команд ​

Стабильная идентификация устройства ​

Имена оборудования ​

Несколько серверов ​

Время и NTP ​

События ядра и агрегации ​

EVPN/VXLAN ​

Фильтрация ​

Проверка настройки ​

Проверка с помощью тестового события ​

Если сообщения не поступают ​

Рекомендуемый шаблон ​

Массовая настройка ​

Что дает подключение оборудования «Булат» к LOGG ​

Оборудование «Булат»

Что можно собирать

Типовая схема подключения

Базовая настройка

Уровни журналирования

Facility

Локальный буфер

Журналирование CLI-команд

Стабильная идентификация устройства

Имена оборудования

Несколько серверов

Время и NTP

События ядра и агрегации

EVPN/VXLAN

Фильтрация

Проверка настройки

Проверка с помощью тестового события

Если сообщения не поступают

Рекомендуемый шаблон

Массовая настройка

Что дает подключение оборудования «Булат» к LOGG