Cisco с нуля 21. Мониторинг: SNMPv3, syslog, NTP, IP SLA

Устройство, за которым никто не наблюдает, сообщает о проблеме последним: когда пользователи уже звонят в поддержку. В этой статье мы настроим на R1 (и, где применимо, на SW1) четыре механизма, из которых складывается базовый мониторинг: единое точное время (NTP), журнал событий на отдельном сервере (syslog), опрос и уведомления по SNMPv3 и активную проверку канала (IP SLA). В конце свяжем проверку канала с маршрутом по умолчанию (или с приоритетом HSRP), чтобы при отказе провайдера трафик переключался сам.

В результате у вас будет: часы, синхронизированные с проверкой подлинности источника; события, которые уходят на сервер 192.0.2.20 с точными метками времени; SNMPv3-доступ для системы мониторинга 192.0.2.40 с шифрованием и ограничением по адресу; и автоматическая реакция на потерю выхода в Интернет.

Что понадобится

• Статьи, которые желательно прочитать: 02. Первичная настройка и SSH (часы, базовые ntp и logging), 06. Статическая маршрутизация и 08. Списки доступа ACL. Для раздела про IP SLA полезна статья «Два провайдера».
• Состояние сети: R1 доступен по SSH (не по Telnet), у него работает GigabitEthernet0/0/0 с адресом 203.0.113.2/30, и с него доступны серверы 192.0.2.20 (syslog), 192.0.2.40 (система мониторинга) и 192.0.2.123 (NTP). Если у вас иное оборудование, подставьте свои интерфейсы.

• Для шага 4 с резервным маршрутом: второй канал 198.51.100.2/30 со шлюзом 198.51.100.1 и узел за «провайдером», отвечающий на ping. Порт второго провайдера зависит от стенда:

  Стенд	Порт второго провайдера
  Статьи 15 и 16	GigabitEthernet0/0/2
  Часть 1 (статья 06): Gi0/0/2 занят стыком с R2, второй провайдер на Gi0/0/3, там же резервный маршрут ip route 0.0.0.0 0.0.0.0 198.51.100.1 200	GigabitEthernet0/0/3

  Везде, где дальше упомянут порт второго провайдера, берите свой из таблицы. Прежний резервный маршрут с дистанцией 200 блок шага 4 заменит сам.

• Для варианта HSRP в шаге 4: стенд из статьи 13. После неё у R1 реальный адрес .2 в каждой VLAN, а адрес SW1 в VLAN 99 — 192.168.99.4.
• Серверы: syslog-сервер, NTP-сервер с настроенным ключом аутентификации и система мониторинга (NMS, Network Management System) с поддержкой SNMPv3. Как их ставить, мы не разбираем. Адреса 192.0.2.x в примерах должны быть достижимы с устройства: в учебной схеме это внешние узлы за WAN R1, и обращения к ним идут через провайдера и NAT; при другой схеме подойдёт любой защищённый канал до серверной сети (VPN здесь не разбирается).
• Что с SW1. Адрес SW1 (192.168.99.4) приватный, и в учебной схеме он выходит наружу только через NAT. Поэтому исходящие службы SW1 (syslog, NTP, ловушки) работают так же, как на R1, а вот SNMP-опрос SW1 с 192.0.2.40 не пройдёт: у NMS нет маршрута в 192.168.99.0/24. Чтобы опрашивать SW1, разместите NMS внутри сети управления или постройте туннель (статья 17, 18). Иначе ограничьтесь на SW1 NTP, syslog и ловушками.
• Минимальный стенд. Для шагов 1–3 достаточно R1 (или SW1) и одной Linux-машины с NTP-сервером, syslog и инструментами net-snmp. Для шага 4 нужен ещё узел, отвечающий на ping, и второй канал. Собрать всё можно в эмуляторе (GNS3, EVE-NG, Cisco Modeling Labs; Packet Tracer поддерживает не все команды). Не пробуйте статью впервые на боевом оборудовании: ошибка в шаге 4 способна оставить сеть без выхода в Интернет.
• Резервная копия и страховка. Перед началом выполните copy running-config startup-config и copy running-config flash:pre-monitoring.cfg. Страховка reload in возвращает устройство к сохранённой конфигурации, поэтому несохранённые результаты предыдущих статей пропадут. Держите наготове консольный доступ: в статье есть места, где ошибка может отрезать вас от устройства.
• Номера объектов. В примерах используются ip sla 1, track 1 и track 2. Если номера заняты (в статье 13 есть track 10), выберите свободные и подставьте везде: повторный ввод занятого номера не создаст новый объект, а изменит существующий.

Что такое мониторинг и из чего он состоит

Мониторинг отвечает на три вопроса: что происходит сейчас, что произошло раньше и что скоро сломается. У каждого вопроса свой инструмент:

Инструмент	Что даёт	Кто инициатор
SNMP-опрос	текущие значения: загрузка процессора, память, счётчики интерфейсов, температура	сервер мониторинга спрашивает устройство
SNMP-ловушки (traps) и informs	мгновенное уведомление о событии: порт упал, изменена конфигурация	устройство сообщает серверу само
Syslog	текстовый журнал событий с метками времени	устройство отправляет сообщения на сервер
IP SLA	активная проверка: «доступен ли узел, какая задержка»	само устройство проверяет, а результат смотрят вы или его использует маршрутизация
NetFlow	кто с кем и сколько общается	устройство экспортирует статистику потоков

Системы мониторинга, которые собирают данные по SNMP, — это, например, Zabbix, LibreNMS и PRTG. Все они сторонние, настраиваются каждая по-своему и в статье не рассматриваются: для них важно лишь то, что вы настроите на устройстве (версию SNMP, имя пользователя и пароли).

Начнём с времени, потому что от него зависит ценность всех остальных данных.

Шаг 1. Единое время: NTP с аутентификацией

Если часы на R1 и SW1 расходятся, сообщения в журнале невозможно сопоставить между устройствами. Базовая настройка ntp server описана в статье 02; здесь добавим проверку подлинности источника. Без неё злоумышленник в сети, подделав ответы NTP, может сдвинуть часы устройства.

Как это устроено

• ntp authenticate включает проверку подлинности. После этого устройство синхронизируется только с теми источниками, ключ которых отмечен как доверенный.
• ntp authentication-key задаёт номер ключа, алгоритм и сам ключ.
• ntp trusted-key объявляет ключ доверенным.
• ntp server ... key N привязывает ключ к конкретному серверу.

Допустимые алгоритмы ключа зависят от версии:

Платформа	Алгоритмы в ntp authentication-key
IOS XE 17.x	md5, cmac-aes-128, hmac-sha1, hmac-sha2-256; начиная с 17.4 ещё sha1 и sha2 (для совместимости с открытыми реализациями, такими как chrony и ntpd)
Классическая IOS 15.x	только md5

Ключ на устройстве и на сервере должен совпадать и по номеру, и по значению, и по типу. В основном блоке ниже используется hmac-sha2-256; если ваш NTP-сервер (например, ntpd) его не поддерживает, подойдёт sha1. Алгоритм md5 слабее и нужен только как единственный вариант на IOS 15.x и для старых серверов.

Настройка

Сначала удаляем прежнюю запись сервера без ключа (если вы делали статью 02), затем добавляем всё с ключом. Вместо <КЛЮЧ_NTP> подставьте свой ключ (для hmac-sha2-256 — от 1 до 32 байт). Строка clock timezone MSK 3 задаёт часовой пояс для меток времени (UTC+3); если пояс уже настроен, пропустите её. Если прежней записи ntp server не было, команда no ntp server просто сообщит об этом.

enable
configure terminal
clock timezone MSK 3
ntp authenticate
ntp authentication-key 42 hmac-sha2-256 <КЛЮЧ_NTP>
ntp trusted-key 42
no ntp server 192.0.2.123
ntp server 192.0.2.123 key 42
ntp source GigabitEthernet0/0/0
end

Команда ntp source задаёт интерфейс, адрес которого будет отправителем NTP-пакетов. Для SW1 используйте ntp source Vlan99, а сам сервер и ключ — те же.

Обратите внимание: в отличие от паролей SNMPv3, ключ NTP остаётся в конфигурации, а вид его хранения зависит от версии и настроек. Проверьте, как он показан в show running-config на вашей версии, не считайте его защищённым, не публикуйте конфигурацию целиком и храните резервные копии как секретные. Команда service password-encryption лишь маскирует часть паролей обратимым способом (type 7) и не заменяет защиту копий.

На классической IOS 15.x (и для старых серверов) вместо hmac-sha2-256 используйте md5. Этот блок заменяет основной целиком, поэтому его можно вставлять на чистом устройстве вместо предыдущего:

enable
configure terminal
clock timezone MSK 3
ntp authenticate
ntp authentication-key 42 md5 <КЛЮЧ_NTP>
ntp trusted-key 42
no ntp server 192.0.2.123
ntp server 192.0.2.123 key 42
ntp source GigabitEthernet0/0/0
end

Как проверить

Синхронизация устанавливается не сразу: обычно требуется от нескольких секунд до нескольких минут.

enable
show ntp status
show ntp associations
show ntp associations detail

Пример вывода show ntp associations (формат зависит от версии; в столбце ref clock показан источник самого сервера, здесь условно эталонные часы .GPS.):

R1#show ntp associations

      address         ref clock       st   when   poll reach  delay  offset   disp
 *~192.0.2.123    .GPS.               1     32    128   377    7.9   11.18    3.6

Звёздочка перед адресом означает, что источник выбран основным (синхронизация идёт с него), а тильда — что он настроен вручную. В show ntp status ищите фразу Clock is synchronized. А признак того, что аутентификация работает, — слово authenticated в первой строке show ntp associations detail (пример вывода; поля и названия могут отличаться на вашей версии):

192.0.2.123 configured, ipv4, authenticated, our_master, sane, valid, stratum 1

В версии 17.x в этой строке также может быть показан тип ключа (например, authtype (cmac-aes-128)); на классической IOS формат вывода отличается, и ориентироваться лучше на Clock is synchronized в show ntp status. Если слова authenticated нет, а в reach нули, проверьте номер и значение ключа на обеих сторонах и список доверенных ключей.

Когда синхронизация подтверждена, сохраните конфигурацию:

enable
copy running-config startup-config

Шаг 2. Syslog: журнал событий на сервере

Устройство хранит события в небольшом буфере в памяти, который обнуляется при перезагрузке, а как раз после перезагрузки журнал нужнее всего. Поэтому сообщения отправляют на внешний сервер. Базовые logging buffered, logging trap и logging host уже были в статье 02; здесь мы повторяем их для полноты и добавляем то, чего там не было: номера сообщений, источник адреса и местное время в метках.

Формат сообщения и уровни важности

Общая схема сообщения: номер: метка времени: %подсистема-уровень-МНЕМОНИКА: описание. Пример вывода (часы синхронизированы по NTP):

000019: Oct 13 14:31:07.123 MSK: %SYS-5-CONFIG_I: Configured from console by admin-lab on vty0 (<адрес_вашего_компьютера>)

Часть после by зависит от способа подключения: при входе по SSH там будут имя пользователя, линия vty и адрес компьютера, при работе с консоли — только пользователь или слово console.

Число между подсистемой и мнемоникой (5 в примере) — уровень важности. Их восемь, от 0 до 7:

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

Когда вы указываете уровень (например, logging trap warnings), отправляются сообщения этого уровня и всех числовых меньших, то есть более серьёзных. Ключевое слово и число равноценны: informational — это то же, что 6 в статье 02. Для сервера по умолчанию используется informational: это разумный выбор для начала. Уровень debugging на сервер без особой нужды не отправляйте: он создаёт большой поток.

Что включить

• service timestamps log datetime msec localtime show-timezone — метки времени: дата, миллисекунды, местное время, название пояса. Эта команда заменяет вариант из статьи 02 (без localtime: там метки показывались по UTC с указанием пояса). По умолчанию метки отключены, и событие невозможно привязать ко времени.
• service sequence-numbers — порядковый номер в начале каждого сообщения. Он помогает заметить потерянные сообщения: syslog передаётся по UDP без подтверждения.
• logging source-interface — интерфейс, адрес которого будет адресом отправителя. Сервер и его фильтры обычно опознают устройство по адресу отправителя, поэтому этот адрес не должен меняться при смене пути до сервера.
• logging on — главный выключатель; по умолчанию включён, команда нужна, только чтобы вернуть его после no logging on. Отключать его не нужно: журнал будет попадать лишь на консоль, а работа маршрутизатора может заметно замедлиться.

Настройка

Первые строки блока про буфер, сервер и уровень повторяют статью 02: если вы её делали, они ничего не изменят.

enable
configure terminal
service timestamps log datetime msec localtime show-timezone
service sequence-numbers
logging on
logging buffered 16384 informational
logging source-interface GigabitEthernet0/0/0
logging host 192.0.2.20
logging trap informational
end

Для SW1 замените интерфейс-источник на Vlan99. Размер буфера 16384 байт выбран для примера: большие буферы расходуют память, поэтому не задавайте его без нужды очень большим.

Как проверить

enable
show logging

Команда показывает состояние журнала (включён ли syslog, сколько сообщений отброшено, куда отправляются сообщения) и содержимое буфера. Внесите безопасное изменение (например, войдите в режим конфигурации и выйдите), и в буфере появится сообщение %SYS-5-CONFIG_I, а на сервере 192.0.2.20 — та же запись. Если на сервере сообщений нет, проверьте, что маршрут до сервера есть и что ACL не режет UDP-порт 514 (стандартный порт syslog). Убедившись, что записи приходят, сохраните конфигурацию (copy running-config startup-config).

Шаг 3. SNMPv3: опрос и уведомления

SNMP (Simple Network Management Protocol) — протокол, по которому система мониторинга задаёт устройству вопросы («какая загрузка процессора?», «сколько байт прошло через порт?») и получает ответы. Устройство может и само сообщить о событии отправкой уведомления. Устройство слушает запросы на UDP-порту 161, а уведомления отправляет на порт 162 сервера.

Версии SNMP

Версия	Безопасность	Комментарий
SNMPv1	строка community	это по сути пароль, который передаётся по сети открытым текстом; не поддерживает informs
SNMPv2c	строка community	по безопасности то же самое, но добавляет informs (подтверждаемые уведомления), массовый опрос GetBulk и 64-битные счётчики; часто встречается до сих пор
SNMPv3	пользователь, проверка подлинности и шифрование	единственный вариант, который стоит использовать за пределами изолированной лаборатории

В SNMPv3 безопасность задаётся уровнем:

• noauth — только имя пользователя, без проверки и шифрования;
• auth — проверка подлинности (пароль), без шифрования;
• priv — проверка подлинности и шифрование. Его мы и настроим.

Community-строка public или private в v1/v2c видна любому, кто может перехватить трафик, а private с правом записи позволяет менять настройки устройства. Поэтому в статье мы community не настраиваем.

Три сущности SNMPv3

Настройка состоит из цепочки:

1. View (представление) — какая часть дерева MIB доступна. Дерево MIB (Management Information Base, база управляющей информации) — это иерархия параметров устройства, у каждого есть числовой идентификатор (OID).
2. Group (группа) — уровень безопасности, представление для чтения и необязательно ACL.
3. User (пользователь) — имя, группа, алгоритмы и пароли.

Доступ дополнительно ограничим стандартным ACL: запросы принимаются только от менеджера 192.0.2.40. Для SNMP поддерживаются только стандартные ACL (именованные или нумерованные), расширенные не поддерживаются. В конце любого ACL есть неявный запрет, так что отдельная строка deny не нужна.

Настройка

В примере пароли заменены заглушками. Подставьте свои пароли: Cisco рекомендует длину не менее 8 символов (минимум по синтаксису — один символ) и сочетание букв и цифр.

enable
configure terminal
ip access-list standard SNMP-MANAGERS
 permit 192.0.2.40
exit
snmp-server view LAB-VIEW mib-2 included
snmp-server group LAB-RO v3 priv read LAB-VIEW access SNMP-MANAGERS
snmp-server user snmp-lab LAB-RO v3 auth sha <ПАРОЛЬ_SNMP_AUTH> priv aes 128 <ПАРОЛЬ_SNMP_PRIV>
snmp-server contact admin-lab@lab.example
snmp-server location Server room
end

Блок намеренно не сохраняет конфигурацию: сохраните её после проверки (см. ниже).

Что здесь происходит:

• snmp-server view LAB-VIEW mib-2 included включает в представление только стандартную ветку mib-2 (интерфейсы, система, IP и т. д.), то есть отдаём не всё дерево, а минимум. Права записи не выдаются вообще: в группе указан только read. Некоторым системам мониторинга нужны и данные производителя (загрузка процессора, память, температура): добавьте вторую строку snmp-server view LAB-VIEW 1.3.6.1.4.1.9 included (ветка Cisco, задаётся числовым OID). Если данных не хватает, расширяйте представление; крайний вариант iso included открывает всё дерево, включая таблицы ARP и маршрутов, и подходит только для изолированной лаборатории.
• snmp-server group LAB-RO v3 priv read LAB-VIEW access SNMP-MANAGERS создаёт группу для SNMPv3 с шифрованием, которой доступно только чтение выбранного представления и только с адреса из ACL.
• snmp-server user snmp-lab LAB-RO v3 auth sha ... priv aes 128 ... — пользователь в этой группе, который проверяется по SHA и шифрует трафик по AES-128. У команды есть и необязательный параметр access <ACL> (ограничение прямо на пользователе), но группового ограничения достаточно, поэтому мы его не используем. Учтите, что в справочнике команд IOS XE он указан в конце команды, а в руководстве для Catalyst 9000 (17.12) записан до auth; если решите его применять, уточните порядок подсказкой ?.
• Отдельной команды «включить SNMP» нет: по руководствам Cisco агент включается первой же командой snmp-server (например, snmp-server host, user или community) и начинает использовать UDP-порты 161 и 162. Пока ни одной такой команды нет, SNMP на устройстве выключен.

enable
configure terminal
ip access-list extended OUTSIDE-IN
 7 permit udp host 192.0.2.40 any eq 161
 8 deny udp any any eq 161
end

Если никакого входящего ACL на внешнем интерфейсе нет, минимальный вариант, не затрагивающий остальной трафик, такой (применяйте под страховкой reload in 15). Не применяйте его, если OUTSIDE-IN уже существует: ip access-group на интерфейсе заменит прежний список.

enable
configure terminal
ip access-list extended SNMP-WAN-IN
 permit udp host 192.0.2.40 any eq 161
 deny udp any any eq 161
 permit ip any any
exit
interface GigabitEthernet0/0/0
 ip access-group SNMP-WAN-IN in
end

Строка permit ip any any оставляет остальной трафик без фильтрации: это только заготовка для SNMP, а не защита внешнего канала. Полноценную защиту строят на зонном межсетевом экране из статьи 23.

Ключи пользователя привязаны к идентификатору SNMP-движка устройства (engine ID). Если вы позже смените snmp-server engineID local, пользователей придётся создавать заново. В руководстве по Catalyst 9300 Cisco советует задать engine ID вручную до создания пользователей, чтобы избежать сбоев аутентификации (это особенно важно на стеках коммутаторов).

Как проверить

enable
show snmp user
show snmp group
show snmp view
show snmp

Пример вывода show snmp user (поля и порядок зависят от версии; идентификатор вымышленный):

R1#show snmp user

User name: snmp-lab
Engine ID: 800000090300AAAABBBBCC01
storage-type: nonvolatile        active
Authentication Protocol: SHA
Privacy Protocol: AES128
Group-name: LAB-RO

Пример вывода show snmp group (поля и названия могут отличаться на вашей версии):

R1#show snmp group

groupname: LAB-RO                security model:v3 priv
readview : LAB-VIEW              writeview: <no writeview specified>
notifyview: <no notifyview specified>
row status: active               access-list: SNMP-MANAGERS

В выводе должны быть: пользователь с протоколами SHA и AES128 в нужной группе, группа с уровнем priv, представлением для чтения и ACL. Счётчики show snmp покажут, поступают ли запросы: рост числа входящих пакетов означает, что менеджер до устройства дошёл.

Проверка с менеджера: snmpwalk

Теперь проверим работу SNMP с самой системы мониторинга. Это команда для Linux-сервера 192.0.2.40, а не для Cisco: пакет net-snmp (сторонний инструмент, к документации Cisco отношения не имеющий; синтаксис см. в его справке man snmpwalk). Команда на сервере мониторинга (Linux):

snmpwalk -v3 -l authPriv -u snmp-lab -a SHA -A '<ПАРОЛЬ_SNMP_AUTH>' -x AES -X '<ПАРОЛЬ_SNMP_PRIV>' 203.0.113.2 1.3.6.1.2.1.1

Здесь -l authPriv соответствует уровню priv на устройстве, -a SHA и -x AES — алгоритмам (AES в net-snmp означает AES-128), а 1.3.6.1.2.1.1 — ветка system дерева MIB (название, описание, время работы устройства). Адрес 203.0.113.2 — тот адрес R1, на который менеджер реально ходит; при необходимости замените его на свой (например, управляющий адрес или Loopback). Если всё настроено верно, вы получите несколько строк вида iso.3.6.1.2.1.1.1.0 = STRING: "Cisco IOS ...". Не оставляйте пароли в истории командной строки: после проверки очистите её либо задайте параметры в файле настроек net-snmp, как описано в его руководстве.

Если ответа нет, посмотрите раздел «Типичные ошибки» ниже. Когда проверка пройдена, отмените страховочную перезагрузку (если запускали её) и сохраните конфигурацию:

enable
reload cancel
copy running-config startup-config

Ловушки: устройство само сообщает о событиях

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

enable
configure terminal
snmp-server source-interface traps GigabitEthernet0/0/0
snmp-server enable traps snmp linkdown linkup
snmp-server enable traps config
snmp-server host 192.0.2.40 version 3 priv snmp-lab
end

• snmp-server enable traps snmp linkdown linkup включает уведомления о падении и подъёме интерфейсов; config — об изменении конфигурации. Без указания типа команда включает все поддерживаемые типы, и это может создать лишний шум. Типы зависят от платформы: полный список смотрите по snmp-server enable traps ?.
• snmp-server host 192.0.2.40 version 3 priv snmp-lab задаёт получателя. Обратите внимание: в v3 на месте поля community-string указывается имя пользователя SNMPv3 (snmp-lab).
• snmp-server source-interface traps определяет адрес отправителя ловушек.

Ловушки (traps) отправляются без подтверждения. Для надёжности существуют informs: приёмник подтверждает получение, и устройство при потере повторяет отправку. Это альтернатива ловушкам, а не дополнение: записи traps и informs для одного хоста существуют независимо (повторная команда перезаписывает только запись того же типа), поэтому, выбрав informs, удалите запись для traps, иначе получатель будет получать оба уведомления. Для SNMPv3 informs нужно сначала указать идентификатор SNMP-движка приёмника и создать на устройстве пользователя для этого приёмника (remote):

enable
configure terminal
no snmp-server host 192.0.2.40 version 3 priv snmp-lab
snmp-server source-interface informs GigabitEthernet0/0/0
snmp-server engineID remote 192.0.2.40 <ENGINE_ID_ПРИЁМНИКА>
snmp-server user snmp-lab LAB-RO remote 192.0.2.40 v3 auth sha <ПАРОЛЬ_SNMP_AUTH> priv aes 128 <ПАРОЛЬ_SNMP_PRIV>
snmp-server host 192.0.2.40 informs version 3 priv snmp-lab
end

Руководство Cisco требует, чтобы для informs на устройстве был доступен и включён SNMP-менеджер (snmp-server manager); в примере Cisco для SNMPv3 informs эта команда не используется, но если подтверждения не проходят, сверьтесь с руководством для вашей платформы.

Подтверждение informs приходит от менеджера с его UDP-порта 162. Если на внешнем интерфейсе стоит OUTSIDE-IN из статьи 08 (он заканчивается на deny ip any any), эти ответы будут отброшены: informs не подтвердятся и станут повторяться, хотя обычные traps работают. Добавьте разрешение с номером ещё ниже финального deny (выберите свободный, как и выше):

enable
configure terminal
ip access-list extended OUTSIDE-IN
 9 permit udp host 192.0.2.40 eq 162 any
end

Без предварительно заданного engine ID приёмника команда для пользователя remote будет отклонена. Engine ID приёмника берут из его собственных настроек; как его узнать, зависит от системы мониторинга. Для обычных traps системе мониторинга, как правило, нужен engine ID самого устройства: его покажет show snmp engineID.

Как проверить ловушки

enable
show snmp host

Пример вывода для варианта с traps (поля зависят от версии; при informs в строке будет type: inform):

R1#show snmp host
Notification host: 192.0.2.40   udp-port: 162   type: trap
user: snmp-lab   security model: v3 priv

Ловушку отправляет то устройство, на котором произошло событие, а SNMP мы настроили только на R1. Поэтому проверяйте на R1: либо внесите безобидное изменение конфигурации (например, задайте описание интерфейса командой description TEST, а потом уберите его), чтобы сработала ловушка config, либо отключите и включите (shutdown, затем no shutdown) неиспользуемый, но подключённый интерфейс R1. Не трогайте WAN-интерфейс и trunk к SW1: это оборвёт вашу связь с устройством. Если хотите проверить порт SW1, сначала повторите на нём блок с SNMP и ловушками, указав источник Vlan99: ловушки от SW1 дойдут до сервера через NAT, а вот опрос SW1 потребует маршрута от NMS в сеть управления (см. «Что понадобится»). На сервере должно появиться уведомление. Команда show snmp покажет счётчики отправленных ловушек. После успешной проверки сохраните конфигурацию командой copy running-config startup-config.

Шаг 4. IP SLA: активная проверка и автоматическое резервирование

IP SLA (Service Level Agreement) — функция самого устройства: оно периодически отправляет проверочные пакеты и запоминает результат. Самая простая проверка — icmp-echo, то есть обычный ping. Для неё на целевом узле ничего настраивать не нужно.

Одного пинга «шлюз провайдера доступен» недостаточно: провайдер может отвечать, а Интернета за ним нет. Поэтому проверяют узел «подальше», а результат используют для управления маршрутами или приоритетом HSRP.

Устройство проверки

enable
configure terminal
ip sla 1
 icmp-echo 192.0.2.99 source-interface GigabitEthernet0/0/0
 frequency 10
 timeout 2000
exit
ip sla schedule 1 life forever start-time now
end

• ip sla 1 — номер проверки; icmp-echo — тип; source-interface — какой интерфейс считать источником.
• frequency 10 — интервал в секундах (по умолчанию 60); timeout 2000 — сколько миллисекунд ждать ответ.
• ip sla schedule 1 life forever start-time now запускает проверку сейчас и навсегда. Без schedule проверка создана, но не работает; если не указать life, она остановится через час (3600 секунд).

Адрес 192.0.2.99 в примере — условный внешний узел, отвечающий на ping. Не берите для проверки адрес, которым пользуются клиенты (например, DNS-сервер 192.0.2.53 из выдачи DHCP): host-маршрут ниже действует для всех пакетов к этому адресу, а не только для проб, и при аварии основного канала запросы клиентов к такому узлу продолжили бы уходить в мёртвый канал. В реальной сети подставьте устойчивый узел за пределами вашей сети, который отвечает на ping и нужен только для проверки. Один проверяемый узел в боевой сети даёт ложные переключения, когда недоступен именно он: для надёжности проверяют несколько узлов и объединяют объекты track в список (track list boolean or); подробности ищите в руководстве Cisco по Enhanced Object Tracking.

Как проверить:

enable
show ip sla statistics
show ip sla configuration 1

Пример вывода show ip sla statistics (набор полей зависит от типа проверки и версии):

R1#show ip sla statistics

IPSLAs Latest Operation Statistics

IPSLA operation id: 1
        Type of operation: icmp-echo
        Latest RTT: 12 milliseconds
Latest operation start time: 14:35:10.000 MSK Tue Oct 13 2026
Latest operation return code: OK
Number of successes: 120
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active

Вывод сокращён; если часы не синхронизированы, время запуска начинается со звёздочки. Код Latest operation return code: OK — проверка успешна, счётчик Number of successes растёт. При потере связи появляются отказы (Number of failures) и код Timeout.

Связка с track и плавающим маршрутом

Объект track превращает результат IP SLA в «включено/выключено», которое можно привязать к статическому маршруту. Логика такая: основной маршрут по умолчанию действует, пока проверка успешна. Когда проверка проваливается, маршрут снимается, и вступает в силу резервный, у которого больше административная дистанция (AD, приоритет источника маршрута: чем она больше, тем ниже доверие; подробнее в статье 06). Саму схему двух провайдеров с NAT мы здесь не повторяем: её разбирает «Два провайдера»; новое здесь — привязка к IP SLA и требования к проверочным пакетам.

Важный нюанс описан в руководстве Cisco: проверочные пакеты должны уходить только через основной канал. Если при его отказе пакет пойдёт по резервному маршруту, проверка «успешно» пройдёт и основной маршрут вернётся, хотя канал мёртв. Простой способ добиться этого — отдельный маршрут к проверяемому узлу строго через основного провайдера (Cisco в своём примере для этого использует политику маршрутизации для локального трафика, к которой мы вернёмся в статье 16).

enable
configure terminal
no ip route 0.0.0.0 0.0.0.0 203.0.113.1
ip route 192.0.2.99 255.255.255.255 203.0.113.1
track 1 ip sla 1 reachability
 delay up 20 down 10
exit
ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1
no ip route 0.0.0.0 0.0.0.0 198.51.100.1 200
ip route 0.0.0.0 0.0.0.0 198.51.100.1 250
end

Что делает каждая строка:

• no ip route 0.0.0.0 0.0.0.0 203.0.113.1 убирает прежний маршрут по умолчанию без привязки к проверке (если его нет, устройство просто сообщит об этом).
• ip route 192.0.2.99 255.255.255.255 203.0.113.1 — «привязка» проверяемого узла к основному провайдеру.
• track 1 ip sla 1 reachability — объект отслеживания: в состоянии Up он находится, пока проверка успешна. Режим reachability считает успешными и OK, и OverThreshold; режим state — только OK.
• delay up 20 down 10 — задержки: объект уходит в Down через 10 секунд после начала сбоя и возвращается в Up через 20 секунд после восстановления. Это защищает от «дрожания» маршрута.
• ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1 — основной маршрут установлен, пока объект Up.
• no ip route 0.0.0.0 0.0.0.0 198.51.100.1 200 убирает резервный маршрут из статьи 06, если вы его делали (иначе у одного шлюза окажутся два маршрута с разной дистанцией; если его нет, устройство просто сообщит об этом).
• ip route 0.0.0.0 0.0.0.0 198.51.100.1 250 — резервный, с высокой AD (250); он попадёт в таблицу маршрутизации только когда основной исчезнет.

Объект track создают после того, как проверка IP SLA настроена и запущена; порядок блоков выше это учитывает. Сразу после ввода блока объект может ещё не быть в состоянии Up (из-за delay up 20 до 20 секунд), и маршрут через провайдера 1 в это время отсутствует (прежний мы удалили первой строкой): трафик пойдёт по резервному маршруту, если он уже действует, или пропадёт. Поэтому выполняйте блок в удобное для сети время и под страховкой reload in 15. Перед отменой перезагрузки проверьте show track 1 и show ip route 0.0.0.0 (ниже).

Как проверить

enable
show track 1
show ip route 0.0.0.0
show ip route track-table

Пример вывода show track 1 (вывод сокращён: ниже обычно идёт блок Tracked by: со списком потребителей объекта; поля и названия зависят от версии):

R1#show track 1
Track 1
  IP SLA 1 reachability
  Reachability is Up
    1 change, last change 00:05:12
  Latest operation return code: OK
  Latest RTT (millisecs) 12
  Delay up 20 secs, down 10 secs

Reachability is Up, а show ip route 0.0.0.0 показывает шлюз 203.0.113.1. Теперь смоделируйте отказ: например, на тестовом стенде заблокируйте ответы на проверяемый адрес на стороне провайдера. Примерно через frequency + delay down секунд объект станет Down, и в таблице маршрутизации появится шлюз 198.51.100.1. После устранения сбоя основной маршрут вернётся самостоятельно. show ip route track-table покажет привязанные к объектам маршруты, например ip route 0.0.0.0 0.0.0.0 203.0.113.1 track-object 1 state is [up]. Когда всё проверено, отмените страховочную перезагрузку и сохраните конфигурацию:

enable
reload cancel
copy running-config startup-config

В версиях Cisco IOS XE 17.x команда выглядит именно как track 1 ip sla 1 reachability. В старых описаниях встречается track 1 rtr 1 reachability: это устаревшая запись.

Как вернуть прежнюю схему

Если схема не подошла, верните один маршрут по умолчанию без привязки к проверке (сама проверка IP SLA остаётся и продолжает давать статистику):

enable
configure terminal
no ip route 0.0.0.0 0.0.0.0 203.0.113.1 track 1
no ip route 0.0.0.0 0.0.0.0 198.51.100.1 250
no ip route 192.0.2.99 255.255.255.255 203.0.113.1
no track 1
ip route 0.0.0.0 0.0.0.0 203.0.113.1
end

Если вы делали статью 06 и хотите вернуть и её резервный маршрут, добавьте ip route 0.0.0.0 0.0.0.0 198.51.100.1 200. Пока не сохранили конфигурацию, откат даёт и сама страховка reload in 15; если вы уже сохранили, вернуться к состоянию до статьи можно из копии flash:pre-monitoring.cfg по статье 12 (configure replace).

Вариант для HSRP: понижать приоритет, когда нет Интернета

В статье 13 приоритет R1 падает, когда пропадает линия порта GigabitEthernet0/0/0. Если порт up, а выхода в Интернет нет, R1 останется активным шлюзом без Интернета. Исправить это можно, привязав приоритет HSRP к той же проверке IP SLA. Здесь нет плавающего маршрута (второй провайдер подключён к R3), поэтому блок track 1 с маршрутами выше выполнять не нужно: достаточно проверки из раздела «Устройство проверки» и объекта track 2.

enable
configure terminal
track 2 ip sla 1 reachability
 delay up 20 down 10
exit
interface GigabitEthernet0/0/1.10
 standby 10 track 2 decrement 20
interface GigabitEthernet0/0/1.20
 standby 20 track 2 decrement 20
interface GigabitEthernet0/0/1.99
 standby 99 track 2 decrement 20
end

Синтаксис standby [группа] track номер-объекта [decrement значение] описан в руководстве по HSRP: объект может быть любым объектом track, не только интерфейсом. Значение decrement должно быть достаточным, чтобы приоритет R1 опустился ниже приоритета R3 (см. расчёт в статье 13), а на R3 должен быть включён preempt. Проверьте результат командами show track 2 и show standby brief, затем сохраните конфигурацию после проверки. Чтобы убрать привязку, на каждом подинтерфейсе введите no standby <ГРУППА> track 2 (например, no standby 10 track 2 на GigabitEthernet0/0/1.10), затем no track 2.

NetFlow и Flexible NetFlow: что это

Все предыдущие инструменты отвечают на вопрос «что с устройством». Если нужно знать, кто и сколько общается (какой узел забил канал, какие приложения используют трафик), используют NetFlow: устройство группирует пакеты в потоки и экспортирует статистику на коллектор по UDP. Современная версия — Flexible NetFlow. Конфигурация состоит из четырёх частей: flow record (какие поля учитывать), flow exporter (куда отправлять), flow monitor (связывает запись и экспортёр, назначается интерфейсу) и flow sampler (выборка для снижения нагрузки). Состав команд и поддержка зависят от платформы (ISR и Catalyst 9000 различаются), поэтому настраивайте её по руководству Cisco для вашей модели: раздел «Flexible NetFlow Overview» в Network Services Configuration Guide для IOS XE 17.x и соответствующие главы руководства по вашему Catalyst. Коллекторами служат, например, ntopng, Elastic, PRTG и многие другие сторонние системы; в статье мы их не настраиваем.

Типичные ошибки

1. Менеджер не получает ответ на SNMP-запрос. Проверьте, что ACL SNMP-MANAGERS разрешает именно адрес, с которого приходит запрос (а не адрес NAT), и что ни один ACL на интерфейсах (в том числе внешний для входящего трафика) не режет UDP 161 (запросы) и 162 (ловушки). Помните о неявном запрете в конце ACL.
2. Неверный пароль, несовпадение алгоритмов или устаревший алгоритм. Менеджер выдаёт ошибки вроде Authentication failure или Decryption error. Уровень (authPriv), алгоритмы (SHA, AES) и оба пароля должны совпасть на обеих сторонах. На IOS XE 17.11.1a и новее пользователи, созданные с MD5, DES или 3DES, отключаются: пересоздайте их с sha и aes. Посмотреть пароль нельзя, при сомнении пересоздайте пользователя: no snmp-server user snmp-lab LAB-RO v3, затем создайте его заново.
3. Не совпадает engine ID при ловушках и informs. SNMPv3 привязывает ключи к идентификатору движка. Для informs нужен snmp-server engineID remote с точным значением приёмника, а для ловушек приёмнику нужен engine ID устройства. После смены snmp-server engineID local пользователей на устройстве придётся создать заново.
4. Часы не синхронизированы. В журнале события из разных устройств не сходятся по времени, а метка начинается со звёздочки (время недостоверно). Проверьте show ntp associations detail: слово authenticated, нужный ключ, доступность сервера. Включённый ntp authenticate без доверенного ключа блокирует синхронизацию.
5. Сообщения не доходят до syslog-сервера. Проверьте маршрут до 192.0.2.20, ACL на пути и уровень в logging trap: если там warnings, сообщения уровня informational не пойдут. Не забывайте, что syslog по UDP не гарантирует доставку.
6. Резервный маршрут (или смена активного HSRP-шлюза) не срабатывает либо срабатывает ложно. ip sla schedule не выполнен (проверка не работает); проверочные пакеты уходят в обход основного канала, и они «успешны» всегда; в track указан state вместо reachability или наоборот; номер track или ip sla совпал с уже занятым и прежний объект был заменён. Смотрите show ip sla statistics и show track.

Что дальше

• Cisco с нуля 20. AAA: RADIUS и TACACS+ для входа на устройства — кто и когда входит на устройство: это дополняет журналы и ловушки.
• Cisco с нуля 16. Prefix-list, route-map, редистрибуция и PBR — как жёстко направить проверочный трафик через нужный канал политикой маршрутизации и как настроить NAT для двух каналов.
• Cisco с нуля 24. EEM и первые шаги автоматизации — реакция устройства на события из журнала (например, письмо или команда при сообщении %LINK-3-UPDOWN).