Управление сетью передачи данных. Часть 2

Управление сетью передачи данных требует комплексного подхода и охватывает организацию доступа для управления сетевыми устройствами, мониторинг, замену оборудования и обновление программного обеспечения, резервное копирование, а также документирование сетевой инфраструктуры. В первой части нашей статьи, опубликованной в предыдущем номере «Журнала сетевых решений/LAN», были кратко рассмотрены все перечисленные задачи, а детально обсуждалось обеспечение доступа к сетевому оборудованию.

МОНИТОРИНГ СЕТЕВОЙ ИНФРАСТРУКТУРЫ

Мониторинг сетевых устройств включает в себя сбор системных сообщений, контроль доступности, телеметрию сетевого устройства, а также оповещение инженера об изменениях в сети. На многих устройствах, в том числе выпускаемых 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 недоступен. Иными словами, при отказе сети основного провайдера и переключении на резервный канал, на почту администратора придет соответствующее письмо. Эта возможность очень удобна для небольших сетей.

ДОКУМЕНТИРОВАНИЕ СЕТЕВОЙ ИНФРАСТРУКТУРЫ

Хорошая документация — залог того, что, если в сети что-то сломается или потребуется внести какие-то изменения, все необходимые действия можно будет провести вне зависимости от внешних условий. Многие компании пренебрегают документированием до того момента, пока не уволится сотрудник, обслуживающий сеть. При этом создание документации и поддержание ее в актуальном состоянии, что намного сложнее, чаще всего выполняются вручную, поскольку автоматизировать эти процессы можно лишь частично.

Глубина проработки документации может зависеть как от степени сложности самой сети, так и от ее предназначения. Например, для сетей со сложной топологией должен быть продуман план по восстановлению работоспособности в случае серьезного сбоя. Если в компании есть дежурные администраторы, для них могут быть подготовлены инструкции по решению типовых проблем или задач. В состав документации, на наш взгляд, обязательно должны входить следующие разделы: доступ к оборудованию (имена/пароли, интерфейсы управления, ограничения доступа), физическая и логическая топологии сети, краткое описание работы основных узлов. Вся документация должна храниться в защищенном месте, так как она содержит ключ ко всей сети.

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

Где же взять данные о текущей топологии? Сбор сведений о физической топологии сети путем осмотра и инвентаризации непосредственно на месте мы уже обсуждали. Однако этот очевидный путь зачастую сложен, трудоемок и вносит дополнительные риски, ведь для проверки некоторых каналов, вероятно, потребуется их отключить. Все ли оборудование будет работать, как и прежде, после такой инвентаризации? Кроме того, помимо физической топологии, необходимо внести информацию о соединениях и протоколах на канальном и сетевом уровнях. Для этого можно использовать как специализированные протоколы (CDP, LLDP), предоставляющие сведения о соседних устройствах, так и общепринятые служебные протоколы и таблицы. Наиболее полезными являются таблицы маршрутизации (соседние маршрутизаторы/коммутаторы, движение трафика), таблица MAC-адресов (соседние устройства), STP (состояние портов), VTP (VLAN), ICMP и ARP (доступность устройства).

Визуализировать топологию можно и вручную — в одном из специализированных пакетов (MS Visio). Однако в этом случае оперативно отслеживать изменения в сети не удастся, поскольку любое изменение надо вносить вручную. Особенно сложно контролировать изменения при большом количестве оборудования и отсутствии жестких регламентов и требований к внесению изменений как в его конфигурацию, так и в документацию.

Автоматическое (полное или частичное) составление топологии сети, как правило, входит в функционал системы мониторинга. Конечно, при использовании этого метода сетевое оборудование придется подготовить для корректного сбора информации и составления топологии, однако он позволяет связать с топологией все функции системы мониторинга: отображение состояния соединений в режиме онлайн, состояние устройств и их доступность, текущие ошибки на устройствах и многое другое.

Отдельное внимание стоит уделить топологии беспроводной сети. Для оперативного мониторинга при составлении ее топологии необходимо указать расположение точек доступа на плане. Не менее важна карта покрытия сети. С помощью системы мониторинга можно посмотреть «стандартные» параметры устройства (клиенты, диапазон, ошибки), а при необходимости — отслеживать положение устройств. Можно осуществлять мониторинг не только легитимных клиентов сети (беспроводных клиентов, RFID-меток и другого беспроводного оборудования), но и устройств, создающих помехи в работе сети, а также угрозы безопасности.

КОМПЛЕКСНЫЕ СИСТЕМЫ МОНИТОРИНГА СЕТЕВОЙ ИНФРАСТРУКТУРЫ

Список систем мониторинга сетевых устройств огромен, но действительно комплексных не так много. Такие системы имеют обширный функционал по мониторингу, настройке сетевых устройств и аудиту всей сети. Они способны собирать и анализировать множество протоколов (SNMP, syslog, NetFlow, CDP и др.) и предоставлять детальную информацию о работе сети. Из наиболее распространенных можно выделить продукты компаний SolarWinds, ManageEngine, Paessler, Cisco. Стоит также отметить продукты с открытым кодом, например Nagios и Zabbix.

Nagios предоставляет огромный спектр функций по мониторингу сетевого оборудования и по сути является стандартом де-факто для мониторинга рабочей ИТ-инфраструктуры в мире открытых систем. Недостаток этой системы — настройка мониторинга в ручном режиме либо с предварительной установкой дополнительных графических интерфейсов. Отличительной особенностью Zabbix, по сравнению с Nagios, является наличие удобного графического интерфейса «из коробки».

Будучи партнерами Cisco, чаще всего мы имеем дело с оборудованием именно этого производителя, поэтому в качестве примера рассмотрим систему Cisco Prime Infrastructure (PI). Эта комплексная система мониторинга оснащена множеством функций, но их описание достойно отдельной статьи. Здесь же приведем несколько ситуаций, когда система мониторинга пригодилась на практике, что, вероятно, в той или иной мере актуально и для других аналогичных продуктов.

Ситуация 1. Заказчик настроил новый функционал на маршрутизаторе. Все работает, однако возникли проблемы с использовавшимися ранее сервисами.

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

Ситуация 2. Наблюдается нестабильная работа протокола DMVPN в одном из новых офисов компании. Конфигурация типовая, развернута с помощью системы шаблонов на PI.

Решение. При инвентаризации устройства и сравнении с остальными выявлено, что была установлена нестабильная версия ПО. Запланировано автоматическое обновление в нерабочее время.

Ситуация 3. Пользователь радиотелефона жалуется на периодические проблемы со связью, но на момент обращения все работает хорошо.

Решение. Отчет об уровне сигнала в течение дня показал, что действительно наблюдаются периоды резкого ухудшения сигнала. После выявления проблемных участков был проведен дополнительный мониторинг работы БЛВС, до повторного проявления проблемы.

Ситуация 4. Сотрудник принес в офис устройство 3G и раздает Wi-Fi коллегам без ограничений. Чтобы не вызывать подозрений, он использует корпоративный SSID.

Решение. Система анализа «посторонних» устройств в беспроводной сети обнаружила угрозу по сигнатуре «использование корпоративного SSID». Администратору отправлено уведомление. По топологии сети с позиционированием устройств определено примерное местоположение нелегитимной точки доступа. Точка локализована и выключена.

Ситуация 5. Удаленный сотрудник подключился по VPN и скачивает большие объемы данных из корпоративной сети, создавая нагрузку на маршрутизатор (шифрование, трафик).

Решение. Отчет по протоколу NetFlow выявил резкое увеличение трафика, поступающего с одного из серверов корпоративной сети на хост в удаленной сети по протоколу smb/cifs. Настроено ограничение пропускной способности.

Эти простые примеры использования системы мониторинга в сети показывают, как ее возможности позволяют существенно ускорить решение проблемы и предотвратить появление новых. Конечно, внедрение такой системы, скорее всего, не будет целесообразным, если в сети всего 10 устройств. Однако при установке в достаточно крупной сети (в том числе распределенной) этот продукт позволит существенно улучшить качество ее работы и уменьшить расходы на обслуживание.

Хотелось бы добавить, что одним из самых распространенных заблуждений является подмена понятий: упрощение обслуживания при использовании системы не означает простоты самой системы. Иными словами, устанавливая систему, заказчик зачастую надеется, что уже сам факт установки и подключения устройств к системе устранит большинство проблем. Как правило, комплексная система — это сложный механизм, требующий тонкой настройки и наличия у специалистов навыков по конфигурированию и пониманию всего цикла работы оборудования.

ЗАКЛЮЧЕНИЕ

В данной статье мы попытались раскрыть понятие «управление сетью» и определить, какие задачи приходится решать сетевым инженерам для поддержания работоспособности сетевой инфраструктуры на надлежащем уровне, а также привели реальные примеры проблем и варианты их устранения.

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

Основная задача мониторинга сети — собрать необходимую и достаточную информацию о работе сетевой инфраструктуры. Рассматривая эти вопросы в статье, мы опирались на опыт инженеров нашей компании. Выполнение перечисленных в статье действий позволяет сетевому инженеру постоянно иметь под рукой исчерпывающую информацию для решения любой задачи. При этом отказ от того или иного процесса мониторинга, как правило, приводит к нехватке данных для поиска причины и устранения сетевой проблемы.

Без внимания не были оставлены организация корректного отказоустойчивого и безопасного доступа к сетевым устройствам для их управления и мониторинга, а также документирование сети. Мы поделились своими взглядами на способы решения этих задач.

Надеемся, что предложенные нами описания существующих систем мониторинга и примеры из реальной практики убедили читателей в полезности применения таких инструментов. Итак, перефразируя известную рекламу, предупреждаем: если в вашей сети все еще нет сервера Syslog или не настроен мониторинг по SNMP, мы идем к вам!

Сергей Калашников — технический директор компании «Компьютерные бизнес системы» (CBS), CCIE. С ним можно связаться по адресу: ksg@cbs.ru. Семен Моховиков — ведущий системный инженер компании «Компьютерные бизнес системы» (CBS). С ним можно связаться по адресу: msn@cbs.ru. Борис Усков — системный инженер компании «Компьютерные бизнес системы» (CBS). С ним можно связаться по адресу: uskov@cbs.ru.