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

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

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.


source: http://ciscotips.ru/network-documentation