Документирование сети

В данной статье речь пойдёт о создании такой сети, которую в случае возникновения проблем легко восстанавливать и анализировать. Залогом такой сети является грамотное планирование и документирование. Что должно быть у вас под рукой, когда начнутся проблемы:

  1. Конфигурационные файлы всех коммутаторов и маршрутизаторов должны аккуратно лежать на отдельном сервере. Ситуация, когда единственная копия конфига лежит на самом устройстве, на котором он применяется – неприемлема.
  2. Физическая и логическая диаграмма сети. Когда у вас упала сеть, и телефон начинает разрываться от звонков – не самое лучшее время вспоминать: «А к чему же был подключен этот свитч?».
  3. Данные по производительности устройств в обычных условиях (baseline). Чтобы в процессе поиска неисправностей не возникало вопросов вроде: «Интересно, процессор на этой циске всегда так загружен, или сейчас с ним происходит какая-то аномалия?».

Что касается конфигурационных файлов, то проще всего завести в административном сегменте сети, куда нет доступа извне специальный tftp сервер, на который и сливать все конфигурационные файлы. Бэкап файлов можно автоматизировать, например, с помощью скрипта, который будет с некоторой периодичностью обращаться к оборудованию по протоколу SNMP и «просить» его записать свой конфиг на tftp сервер. Или с помощью планировщика на самом устройстве cisco.

Помимо собственно конфигурационных файлов, надо иметь сохранённую копию образа IOS с каждого устройства и табличку, содержащую:

  1. Тип устройства, название модели;
  2. Имя файла образа IOS;
  3. Имя устройства (hostname);
  4. Физическое расположение устройства (адрес, помещение, комната, стойка);
  5. Если устройство модульное, то перечень имеющихся модулей;
  6. Адреса второго уровня (например, MAC);
  7. Адреса третьего уровня (например, IP);
  8. Дополнительная важная информация о физических особенностях устройства.

Необходимо так же вести учёт конечных устройств:

  1. Имя устройства;
  2. Версию операционной системы;
  3. Адреса (IPv4 и IPv6);
  4. Маски подсети;
  5. Шлюзы и DNS-ы, настроенные на устройстве;
  6. Основные сетевые приложения и сервисы, работающие на устройстве.

Что касается второго пункта – диаграмм сети, должны быть две диаграммы, отражающие физическую и логическую топологию. Под физической диаграммой физической топологии подразумевается схема, на которой все сетевые и часть конечных (сервера) устройств изображены с указанием типа, модели и производителя, версии ОС, типом кабелей и коннекторов, указанием физического расположения устройства, стоек и разъёмов на патч-панелях, к которым эти устройства подключены. Логическая топология — это схема, так же содержащая в себе сетевые промежуточные устройства и часть конечных (сервера). Но на этой схеме должны быть отражены другие данные: Имена устройств, IP адреса и маски, идентификаторы интерфейсов, типы подключений (использующиеся протоколы), номера DLCI (для Frame Relay), информация о VPN соединениях, использующиеся протоколы маршрутизации, статические маршруты, использованные технологии WAN.

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

  1. Что именно мы хотим собирать? Стандартный перечень может состоять из загрузки памяти и CPU, загрузки интерфейсов, содержимого таблиц маршрутизации, ARP, таблицы MAC адресов, списка соседей по CDP, содержимое таблиц ip dhcp snooping и др.);
  2. Какие устройства и порты нас интересуют? Необходимо определить сетеве устройства и ключевые конечные устройства, информацию с которых мы будем собирать;
  3. Продолжительность и периодичность замер. Следует определить, планируете ли вы вести постоянный мониторинг, или разовые замеры. Практика показывает, что в целях упрощения процесса поиска неисправностей в сети, лучше иметь данные постоянного мониторинга параметров.

После ответа на приведённые три вопроса следует приступить к реализации замеров. Самый простой способ – единоразовые замеры вручную, когда вы самостоятельно заходите на устройства, выводите необходимую информацию с помощью команды show и сохраняете её в текстовые файлы. Следующая ступень оптимизации – написание скриптов, которые делают то же самое, заходя на устройства по telnet или ssh. Если хочется автоматизировать процесс ещё сильнее, то можно наладить периодический запуск таких скриптов. Другой путь – установка готового коммерческого или бесплатного ПО для мониторинга. Как правило, такое ПО собирает статистику по SNMP. Например, неплохо себя зарекомендовало бесплатное ПО для мониторинга состояния устройств – Zabbix. Это приложение обладает множеством настроек, поддерживает возможность написания своих скриптов, позволяет собирать множество информации от устройств cisco и других устройств, как с помощью агентов, так и по протоколу SNMP.

Комментарии

надо иметь сохранённую копию образа IOS с каждого устройства
Очень хотелось бы узнать как это сделать... Крайне необходимо иной раз иметь копию образа IOS.

Аватар пользователя bacek
IOS не так часто меняется, в отличии от конфигурации, поэтому эту часть не автоматизируют. Хотя, через SNMP можно это сделать, а вот конфигурация должна сохраняться каждый раз при изменении.
То есть, если устройств не много, до достаточно поднять TFTP сервер и на каждом типе устройств один раз запустить copy flash: tftp:
Что касается автоматического сохранения конфига на TFTP - то это обязательно надо автоматизировать:
archive
log config
logging enable
hidekeys
path ftp://логин:пароль@IP-TFTP-сервера/папка
write-memory
Эта команда каждый раз при сохранении copy run start будет сохранять копию конфига на тфтп сервер. Надо бы написать на эту тему отдельную статью.
 

Добавить комментарий