Оборудование NATEKS / NetXpert

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

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

Важно: NATEKS выпускает несколько семейств оборудования с различающимися поколениями программного обеспечения и CLI. Приведенные ниже команды являются типовыми примерами. Перед массовым применением необходимо проверить синтаксис для конкретной модели и версии ПО.

Какое оборудование можно подключать

В линейке NATEKS представлены:

• коммутаторы доступа;
• коммутаторы агрегации;
• коммутаторы ядра;
• оборудование для ЦОД;
• промышленные коммутаторы;
• маршрутизаторы;
• мультисервисное и транспортное оборудование.

В частности, к семейству NetXpert относятся серии NX-34xx, NX-43xx, NX-51xx, NX-57xx, NX-95xx и промышленные NXI.

Многие платформы поддерживают стандартные механизмы управления:

CLI
SSH / Telnet
SNMP
Syslog
NTP
RMON

Наличие конкретных функций зависит от модели.

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

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

• физических интерфейсов;
• Link Up / Down;
• VLAN;
• STP/RSTP/MSTP;
• Link Aggregation / LACP;
• событий маршрутизации;
• RIP;
• OSPF;
• IS-IS;
• BGP на соответствующих моделях;
• MPLS;
• аппаратных компонентов;
• питания и температуры;
• перезагрузок;
• системных процессов;
• SSH и Telnet;
• AAA;
• RADIUS / TACACS+;
• действий пользователей;
• изменений конфигурации;
• ошибок и предупреждений;
• событий безопасности.

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

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

LOGG выступает удаленным Syslog-сервером:

NATEKS / NetXpert
       │
       │ Syslog
       ▼
      LOGG

Классическая схема использует:

UDP/514

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

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

Для оборудования NetXpert с Cisco-like CLI типовая конфигурация может выглядеть следующим образом:

enable
configure terminal

logging host 192.0.2.10
logging trap informational

end

Где:

• 192.0.2.10 — IP-адрес LOGG;
• informational — уровень передаваемых сообщений.

Если версия ПО позволяет явно определить facility:

logging facility local7

Получаем базовую политику:

configure terminal

logging host 192.0.2.10
logging trap informational
logging facility local7

end

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

Настройка порта

Стандартный порт Syslog:

UDP/514

На платформах, позволяющих явно задавать порт, конфигурация может иметь вид:

logging host 192.0.2.10 port 514

или в некоторых поколениях CLI:

logging server 192.0.2.10 514

Если LOGG настроен на альтернативный порт, например 1514, соответствующий порт необходимо указать и на оборудовании:

logging host 192.0.2.10 port 1514

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

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

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

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

logging trap informational

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

Например:

Interface Down
LACP member changed
STP topology changed
OSPF neighbor down
Administrator login
Configuration changed

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

Debugging

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

Например, при исследовании работы определенного сетевого протокола.

Постоянная передача debug-сообщений может сформировать значительный поток:

debug
   ↓
тысячи сообщений
   ↓
сеть управления
   ↓
LOGG

Поэтому для постоянной эксплуатации предпочтителен уровень informational, а debug включается временно.

Facility

Если конкретная платформа позволяет задавать Syslog facility, для сетевого оборудования удобно использовать:

local7

Например:

logging facility local7

В организации можно принять единую политику:

Network Equipment → local7 → LOGG

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

Стабильный адрес источника

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

Предпочтительно:

Loopback

или выделенный management-интерфейс.

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

logging source-interface Loopback0

Получается:

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

Это позволяет LOGG всегда идентифицировать устройство по одному IP-адресу независимо от текущего маршрута доставки.

Поддержку и синтаксис source-interface необходимо проверить для конкретной модели.

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

Для большого парка NATEKS рекомендуется использовать единую схему hostname.

Например:

DC1-NX-CORE-01
DC1-NX-CORE-02

DC1-NX-AGG-01
DC1-NX-AGG-02

DC1-NX-ACCESS-001
DC1-NX-ACCESS-002

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

Локальный журнал

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

На оборудовании с соответствующим CLI типовой пример:

logging buffered informational

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

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

LOGG при этом остается централизованным хранилищем долговременной истории.

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

Если конкретная платформа позволяет определить несколько Syslog-серверов:

logging host 192.0.2.10
logging host 192.0.2.11

можно построить схему:

                  ┌── LOGG-1
NATEKS / NetXpert ┤
                  └── LOGG-2

или:

                  ┌── LOGG
NATEKS / NetXpert ┤
                  └── SIEM

Это позволяет организовать резервирование или параллельную обработку событий.

События интерфейсов

Один из наиболее ценных источников журналов сетевого оборудования — изменение состояния интерфейсов.

Например:

10:21:14  Interface Ethernet1/1 changed state to DOWN

Само по себе сообщение говорит только о состоянии одного порта.

Но в LOGG оно может быть сопоставлено с последующими событиями:

10:21:14.102  CORE-01    Interface Down
10:21:14.318  CORE-01    LACP member removed
10:21:14.912  AGG-01     Uplink changed
10:21:15.347  AGG-01     STP topology changed
10:21:17.204  SERVER-01  Connection timeout

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

События маршрутизации

На L3-коммутаторах и маршрутизаторах особенно полезны журналы динамической маршрутизации.

Например:

Physical Interface Down
        ↓
OSPF Neighbor Down
        ↓
Route Removed
        ↓
Alternative Route Selected
        ↓
Traffic Path Changed

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

Действия администраторов

Для расследования инцидентов важно централизованно собирать:

• вход пользователей;
• ошибки авторизации;
• SSH/Telnet-сессии;
• изменения конфигурации;
• события AAA.

Это позволяет сопоставлять административную активность с изменениями состояния сети:

14:05:03  administrator login
14:07:14  configuration changed
14:07:17  interface changed
14:07:18  OSPF neighbor down
14:07:20  route changed

В результате становится понятно не только что произошло, но и что происходило непосредственно перед этим.

NTP

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

Оборудование NetXpert поддерживает NTP на ряде платформ.

Рекомендуется настроить единые корпоративные NTP-серверы и проверить:

• системное время;
• timezone;
• состояние синхронизации;
• доступность NTP.

Схема должна выглядеть так:

        NTP
         │
    ┌────┼────┐
    ▼    ▼    ▼
 CORE   AGG  ACCESS
    \    |    /
     \   |   /
        LOGG

Чем точнее синхронизировано время, тем надежнее LOGG восстанавливает последовательность событий.

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

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

На Cisco-like CLI могут использоваться команды вида:

show logging

и:

show running-config

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

show running-config | include logging

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

ping 192.0.2.10

Точные диагностические команды следует сверить с CLI конкретной серии.

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

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

Например:

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

После этого необходимо:

1. проверить локальный журнал;
2. найти сообщение в LOGG;
3. проверить hostname;
4. проверить source IP;
5. проверить timestamp;
6. проверить severity;
7. проверить facility.

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

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

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

1. Настроен ли удаленный Syslog host.
2. Правильно ли указан адрес LOGG.
3. Правильно ли указан порт.
4. Выбран ли необходимый severity.
5. Доступен ли LOGG с устройства.
6. Есть ли маршрут до сервера.
7. Не блокирует ли Syslog ACL.
8. Не блокирует ли трафик межсетевой экран.
9. Правильно ли выбран source interface.
10. Генерирует ли устройство сообщения локально.
11. Принимает ли LOGG UDP/514 или другой выбранный порт.
12. Синхронизировано ли время.

Для первичной диагностики:

show logging
show running-config
ping 192.0.2.10

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

Для NetXpert с соответствующим CLI базовая политика может выглядеть так:

configure terminal

logging host 192.0.2.10
logging trap informational
logging facility local7
logging source-interface Loopback0
logging buffered informational

end

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

Адрес LOGG, source interface, severity, facility и порт следует адаптировать к инфраструктуре организации.

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

NATEKS выпускает широкий набор сетевого оборудования, поэтому перед массовой автоматизацией рекомендуется классифицировать устройства:

Vendor
  └── NATEKS
       ├── NetXpert NX-34xx
       ├── NetXpert NX-43xx
       ├── NetXpert NX-51xx
       ├── NetXpert NX-57xx
       ├── NetXpert NX-95xx
       ├── NetXpert NXI
       └── NetXpert RT

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

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

• адрес LOGG;
• transport;
• port;
• severity;
• facility;
• source interface;
• hostname;
• NTP;
• локальное журналирование.

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

Что дает подключение NATEKS к LOGG

Отдельный коммутатор или маршрутизатор сообщает о собственных событиях:

Interface Down
LACP Changed
OSPF Neighbor Down
Route Changed

Но каждое устройство видит только свою часть происходящего.

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

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

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

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

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

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

Важно: оборудование NATEKS/NetXpert представлено несколькими программными платформами и поколениями CLI. Перед использованием приведенных CLI-примеров необходимо сверить команды с руководством конкретной модели и версии ПО. Для массового внедрения рекомендуется сначала проверить шаблон на одном устройстве каждого семейства.