Мониторинг сетевых устройств включает в себя сбор системных сообщений, контроль доступности, телеметрию сетевого устройства, а также оповещение инженера об изменениях в сети. На многих устройствах, в том числе выпускаемых Cisco, в качестве системных служат сообщения syslog. Сбор телеметрических данных производится с использованием протокола SNMP. Для передачи оповещения о происходящих изменениях на сетевом оборудовании должны быть настроены средства рассылки уведомлений. Мониторинг каналов связи организуется по протоколу Netflow или с помощью его аналогов. Далее рассмотрим каждый этап более подробно.
Cообщения syslog и их анализ. Журналы событий фиксируют процесс работы сетевого устройства и отражают его состояние. Любое выполненное системой действие отражается в соответствующем системном сообщении — записи в журнале (логе). Системные сообщения могут иметь различные уровни детализации, и в зависимости от этого в журнале событий выделяются различные уровни протоколирования (логирования). Для оборудования Cisco Systems предусмотрено восемь уровней: от уровня 0 (Emergencies — сообщения о неработоспособности системы) до уровня 7 (Debugging — отладочные сообщения).
Данное оборудование предоставляет следующие возможности по выводу сообщений: на консоль устройства (console logging), в локальный буфер устройства (buffer logging), в терминальную линию (monitor logging) и на внешний сетевой накопитель — выделенный сервер syslog. В роли последнего может выступать централизованная система мониторинга.
При включении протоколирования нужно быть крайне внимательным, поскольку игнорирование некоторых нюансов может привести к отказу устройства и/или необходимости его перезапуска.
Первая особенность касается вывода на консоль или терминальную линию сообщений с высоким уровнем детализации, в частности уровня 7. Прежде всего речь идет о ситуации, когда инженер активирует дополнительную трассировку какого-либо сервиса командой debug. Поскольку сетевое устройство может генерировать слишком большое количество сообщений за единицу времени, все ресурсы процессора будут направлены на вывод этих сообщений на экран. В результате устройство может «зависнуть» и перестать выполнять свою главную функцию — маршрутизировать и коммутировать сетевой трафик. Таким образом, при необходимости просмотра сообщений высокого уровня детализации мы рекомендуем выводить их в локальный буфер.
Второй нюанс касается вывода сообщений в локальный буфер, который на сетевых устройствах Cisco выделяется из общего пула оперативной памяти. Если для буфера сообщений будет запрошен слишком большой объем памяти, это также может привести к «зависанию» устройства и незапланированной перезагрузке.
Отдельно стоит выделить настройку протоколирования на межсетевых экранах Cisco ASA. Распределение сообщений по уровням для многих случаев не является оптимальным. В частности, сообщения, связанные с работой списков доступа (ACL) или с правилами трансляции IP-адресов (NAT), могут соответствовать уровням 2–6. Например, если трафик подпадает под действие списка доступа, то в этом случае может генерироваться следующее сообщение:
Error Message %ASA-2-106006: Deny inbound UDP from outside_address/outside_port to inside_address/inside_port on interface interface_name.
Таким образом, даже при работе устройства в нормальном режиме не исключено появление сообщений высокого уровня критичности. С учетом этого в операционной системе межсетевого экрана Cisco ASA предусмотрены широкие возможности по настройке и оптимизации протоколирования на устройстве. В частности, инженер может менять уровень любого сообщения, а также создавать списки системных сообщений, объединяя интересующие его события в группы. Например, для отладки и мониторинга работы сервиса VPN формируется список, в который будут попадать только те сообщения, которые связаны с работой данного сервиса, а на выделенный сервер Syslog будет передаваться настроенный список. Кроме того, устройство Cisco ASA может отправлять списки сообщений по электронной почте.
Для любого сетевого устройства системные сообщения являются главным, а в некоторых случаях и единственно доступным инструментом поиска проблем и неисправностей. Выполняя диагностику сетевой проблемы, сразу после проверки корректности конфигурации инженер должен посмотреть журналы событий сетевых устройств. Вероятность выявления причины при анализе системного журнала крайне велика.
Системные сообщения незаменимы при расследовании непредсказуемых сетевых проблем. Вот простой пример. Сетевой администратор периодически получает от пользователей жалобы на то, что в течение рабочего дня три-четыре раза пропадает связь между центральным офисом и удаленным. Что делать в такой ситуации?
В первую очередь надо уточнить, когда именно это происходило, и посмотреть журналы событий сетевых устройств в интересующие временные интервалы. Предположим, из записей видно, что на всем сетевом оборудовании центрального офиса исчезает маршрут в удаленный офис. Анализ журналов оборудования этого офиса показывает, что как раз в интересующие нас интервалы времени на маршрутизаторе, к которому подключен канал до центрального офиса, появлялось критическое сообщение о нехватке оперативной памяти на устройстве и затем производилась перезагрузка.
Таким образом, по записям в журнале мы смогли локализовать проблему и понять причину ее появления.
Помимо решения сетевых проблем, хотелось бы отметить еще одну область применения системных сообщений. Их можно использовать совместно со встроенным в операционную систему устройств Cisco редактором автоматических сценариев Cisco Embedded Event Manager (EEM). Данная функциональность позволяет создавать сценарии для автоматического изменения конфигураций устройств. Сообщение о событии может выступать триггером запуска сценария.
Сбор данных по протоколу SNMP. Простой протокол управления сетью (Simple Network Management Protocol, SNMP) является стандартом для обмена управляющей информацией между сетевыми устройствами и системой управления сетью (Network Management System, NMS). С точки зрения мониторинга сети протокол SNMP служит незаменимым средством сбора телеметрической информации с сетевых устройств.
Телеметрическая информация позволяет находить узкие места в сетевой топологии, предотвращать возможные отказы, отслеживать причины возникновения проблем, определять рабочие уровни (baseline) для показателей используемых устройств, выявлять аномалии в функционировании сети.
Среди этих показателей наиболее важными являются загрузка процессора устройства, загрузка оперативной памяти, параметры систем питания и охлаждения, температура устройства. Эти данные рекомендуется отслеживать на любом сетевом устройстве. Кроме того, в зависимости от возложенного функционала рекомендуется включать мониторинг дополнительных параметров. Так, для устройств, терминирующих VPN-подключения, нужен опрос соответствующих SNMP OID.
Для многих сетевых устройств важно знать текущий уровень загрузки их интерфейсов. Эта информация поможет достаточно точно оценить загруженность каналов передачи данных. Пример графика загрузки процессора коммутатора Cisco, полученный благодаря опросу устройства по SNMP, представлен на Рисунке 1, а пример графика загрузки сетевого интерфейса коммутатора Cisco — на Рисунке 2.
|
| Рисунок 1. График загрузки процессора коммутатора Cisco. |
|
| Рисунок 2. График загрузки сетевого интерфейса коммутатора Cisco. |
Для ряда сетевых проблем поиск причин и их устранение неосуществимы без наличия телеметрической информации от сетевых устройств, собранной по протоколу SNMP. К их числу относятся ситуации, когда связь пропадает не полностью, но ее качество становится неприемлемым для определенных сетевых приложений. В большинстве случаев при возникновении подобных проблем сетевой инженер не может получить нужной ему информации посредством проверки конфигураций сетевых устройств или просмотра записей в журнале событий. В результате таких первичных проверок создается впечатление, что вся сетевая инфраструктура работает корректно и безотказно. Однако от конечных пользователей продолжают поступать жалобы на то, что «видео не грузится», «телефония работает плохо и качество голоса неприемлемо».
Наиболее вероятной причиной возникновения подобных проблем является возросшая нагрузка на сетевые устройства и/или на каналы передачи данных. С помощью NMS, собирающей телеметрическую информацию по SNMP, легко оценить динамику изменения нагрузки на сетевые устройства. Вполне вероятно, что на пути следования проблемного потока данных находится одно или несколько сетевых устройств, загруженных сверх меры. После выявления таких устройств инженер сможет сделать вывод, являются ли эти узлы узким местом сетевой топологии либо данные устройства подвержены какому-то аномальному нежелательному влиянию (вирусная активность, нелегитимный трафик больших объемов и т. д.). Если устройство оказалось недостаточно производительным (узкое место), придется поднять вопрос о замене оборудования на более производительную модель. Если высокая загрузка является аномалией, потребуется дальнейшее расследование.
Например, с помощью данных, полученных по SNMP, можно локализовать «паразитный трафик», загружающий сетевое оборудование. Средства SNMP позволяют опрашивать OID устройств, отвечающих за загрузку сетевых интерфейсов. Если перегруженным устройством является коммутатор, велика вероятность того, что на паре его интерфейсов будет обнаружен аномально высокий уровень загрузки. Во многих случаях подобные рассуждения актуальны и для маршрутизаторов. После выявления пары интерфейсов инженер может уточнить, какие устройства подключены к данным портам. Возможно, для подтверждения выдвинутой гипотезы потребуется отключить эти интерфейсы на некоторое время, чтобы посмотреть, снизится ли загрузка сетевого устройства и улучшится ли в конечном итоге качество связи. Таким образом, сбор информации по SNMP помогает выявить причину проблемы, расследовать которую другими средствами не представляется возможным.
Необходимо отметить, что качество связи может ухудшаться не только вследствие чрезмерной загрузки сетевого оборудования, но и из-за высокого уровня утилизации каналов связи. И в этом случае опрос по SNMP OID устройства, содержащего информацию о загрузке сетевых интерфейсов, помогает выявить и косвенно определить загрузку подключенных к интерфейсам каналов. Вот простейший пример. К интерфейсу высокопроизводительного маршрутизатора Cisco подключен WAN-канал, пропускная способность которого, согласно договору с провайдером, составляет 10 Мбит/с, но пользователи периодически испытывают проблемы с качеством связи. С помощью сбора информации по SNMP удается определить, что на протяжении всего времени использования канала загрузка соответствующего интерфейса маршрутизатора не превышала 3 Мбит/с, но с некоторого момента она составляет 10–12 Мбит/с, что превышает пропускную способность канала.
Конечно, производительность подавляющего большинства моделей маршрутизаторов Cisco позволяет «прокачивать» трафик в 10–12 Мбит/с. Тем не менее очевидно, что проблема заключается в чрезмерном уровне утилизации WAN-канала. В данной ситуации дальнейшее расследование проблемы средствами SNMP затруднительно — нужно определить качественный состав трафика в канале, то есть IP-адреса отправителей/получателей, протоколы и используемые порты. Описанная задача решается с помощью протокола NetFlow, особенности которого более подробно рассматриваются ниже.
Сбор данных по протоколу NetFlow. Протокол NetFlow разработан компанией Cisco Systems. В контексте задачи управления сетью он является незаменимым инструментом для мониторинга загрузки каналов передачи данных.
Конечно, протокол NetFlow не может извлекать информацию непосредственно из канала (витой пары или оптической линии) — данные снимаются с устройств, подключенных к интересующему сегменту. NetFlow поддерживается многими сетевыми устройствами: по этому протоколу могут отправлять информацию маршрутизаторы, коммутаторы и межсетевые экраны Cisco. NetFlow является проприетарным протоколом Cisco Systems, но существует и его открытый аналог — sFlow. Последний реализован в современных моделях сетевых устройств многих производителей сетевого оборудования — HP, ZyXEL и других.
Архитектура NetFlow крайне проста и состоит из двух компонентов: сетевого устройства, отправляющего информацию о проходящем через него трафике, и коллектора NetFlow. Последний собирает и анализирует информацию, передаваемую по протоколу NetFlow.
Принцип действия протокола заключается в следующем. При открытии очередного сеанса передачи данных на сетевом оборудовании формируется информация о данном сеансе, называемая поток (flow). Сведения о потоке включают количество передаваемых байтов, входной и выходной интерфейсы для сеанса, IP-адреса отправителя/получателя, порты отправителя/получателя, номер протокола IP, параметры QoS и т. д. Сведения о потоках аккумулируются на сетевом устройстве и отправляются коллектору NetFlow в датаграммах UDP.
Коллектор NetFlow агрегирует полученную информацию, проводит анализ и формирует удобные для восприятия отчеты и графики. Один из популярных коллекторов NetFlow — NetFlow Analyzer, но существуют коллекторы и других производителей.
Протокол NetFlow позволяет получить полную картину трафика в каналах. Инженер может просмотреть качественный состав трафика (IP-адреса, порты, приложения) в любом сегменте сети, а также оценить, какую долю пропускной способности канала (в процентном отношении) занимает тот или иной поток. Пример информации о сетевом трафике, собранной с помощью протокола NetFlow на коллектор NetFlow Analyzer, представлен на Рисунке 3.
|
| Рисунок 3. Пример информации о сетевом трафике, собранной с помощью протокола NetFlow на коллекторе NetFlow Analyzer. |
Основные области применения NetFlow: мониторинг утилизации каналов передачи данных, учет трафика, проведение аудитов сетевой инфраструктуры. Учитывать трафик приходится прежде всего компаниям — провайдерам связи. При проведении аудита NetFlow помогает собирать детальную информацию о реальном трафике, передаваемом по сети.
Чтобы понять, каким образом NetFlow может помочь сетевому инженеру в управлении сетью, вернемся к рассмотрению примера с периодически ухудшающимся качеством связи (см. подраздел «Сбор данных по протоколу SNMP»). Итак, от пользователей периодически поступают жалобы на то, что сеть «тормозит» и телефония «глючит». С помощью протокола SNMP удалось определить, что загрузка всех сетевых устройств на маршруте следования трафика находится в допустимых пределах. Однако на устройстве, к которому подключен канал WAN, предоставляемый провайдером, загрузка интерфейсов необычно высока для данного участка. Счетчики интерфейсов показывают, что количество переданного/принятого трафика канала превышает гарантированную провайдером пропускную способность.
В данной ситуации протокол NetFlow поможет понять, что конкретно происходит в проблемном канале. Инженер может увидеть, какое приложение чрезмерно загружает канал и, главное, между какими парами IP-адресов происходит передача данных. Вполне вероятно, эти IP-адреса позволят выявить конечных пользователей, генерирующих избыточный трафик. Далее дело остается за малым. Инженер может уточнить, насколько необходимо пользователю столь неэкономное приложение. Если острой потребности в нем нет, подобный трафик можно запретить с помощью списка доступа на сетевом оборудовании для предотвращения повторных проявлений проблемы. Если же пользователь настаивает на критичности данного сервиса для бизнеса в целом, сетевой инженер должен поднять вопрос о расширении пропускной способности канала или приобретении новых дополнительных каналов. На время разрешения проблемы политики QoS настраиваются таким образом, чтобы трафик спорного приложения не занимал весь канал, оставляя достаточно ресурсов для передачи как минимум голосовых сообщений.
Стоит отметить, что сбор информации по протоколу NetFlow создает дополнительную нагрузку на сетевое оборудование, поэтому не стоит снимать данные посредством NetFlow со всех узлов сетевой инфраструктуры. Рекомендуется запрашивать только действительно необходимую информацию о сегментах сети. К таким участкам в первую очередь относятся точки подключения внешних линий связи: выделенных линий, WAN-каналов и каналов для подключения к Интернету.
Уведомления. Все существующие комплексные системы мониторинга сетевых устройств позволяют настраивать уведомления о событиях, происходящих на устройствах. Уведомления можно отправлять на основании прерываний SNMP (SNMP trap) либо записей syslog в виде сообщений электронной почты или через шлюз sms. Следует настроить их корреляцию, чтобы отправлять именно критичные сообщения, на которые необходимо оперативно реагировать, а также распределить ответственность между группами (тип оборудования, уровень ошибок, расположение и т. п.) и отправлять информацию администраторам из конкретной группы.
Даже при отсутствии выделенного сервера системы мониторинга с необходимым функционалом рассылки уведомлений, отправку сообщения на электронную почту при наступлении определенных событий (syslog, SNMP) можно организовать средствами маршрутизатора. В маршрутизаторах Cisco функционал Embedded Event Manager (EEM) позволяет отправить такое сообщение. Триггером может служить, например, сообщение syslog о том, что трек ip sla недоступен. Иными словами, при отказе сети основного провайдера и переключении на резервный канал, на почту администратора придет соответствующее письмо. Эта возможность очень удобна для небольших сетей.