Наша цель на данном этапе — наведение порядка в документации и конфигурации.
На выходе этого процесса у вас должен быть необходимый комплект документов и сеть, сконфигурированная в соответствии с ними.
Сейчас мы не будем говорить об аудите безопасности – этому будет посвящена третья часть.
Сложность выполнения поставленной на этом этапе задачи, конечно, сильно варьируется от компании к компании.
Идеальная ситуация – это когда
- ваша сеть была создана в соответствии с проектом и вы имеете полный комплект документов
- в вашей компании был внедрен процесс контроля и управления изменениями для сети
- в соответствии с этим процессом вы располагаете документами (в том числе и всеми необходимыми схемами), предоставляющими полную информацию об актуальном положении вещей
В этом случае ваша задача довольно проста. Вы должны изучить документы и просмотреть все те изменения, которые были сделаны.
В худшем варианте у вас будет
- сеть, созданная без проекта, без плана, без согласования, инженерами, не обладающими достаточным уровнем квалификации,
- с хаотичными, не задокументированными изменениями, с большим количеством «мусора» и неоптимальных решений
Понятно, что ваша ситуация где-то между, но, к сожалению, на этой шкале лучше – хуже с большой вероятностью, вы будете находиться ближе к худшему концу.
В этом случае, от вас потребуется в том числе и умение читать мысли, потому что вам придется научиться понимать, а что же хотели сделать “дизайнеры”, восстанавливать их логику, доделывать то, что не было закончено и удалять «мусор».
И, конечно, вам нужно будет купировать их ошибки, менять (на этом этапе по возможности минимально) дизайн и изменять или создавать заново схемы.
Данная статья ни в коей мере не претендует на полноту. Здесь я опишу лишь общие принципы и остановлюсь на некоторых распространенных проблемах, которые приходится решать.
Набор документов
Начнем с примера.
Ниже приведены некоторые документы, которые принято создавать в компании Cisco Systems при проектировании.
CR – Сustomer Requirements, требования клиента (тех. задание).
Создается совместно с заказчиком и определяет требования к сети.HLD – High Level Design, высокоуровневый дизайн на основе требований к сети (CR). Документ объясняет и обосновывает принятые архитектурные решения (топология, протоколы, выбор оборудования,...). HLD не содержит деталей дизайна, например, об используемых интерфейсах и IP-адресах. Так же здесь не обсуждается конкретная конфигурация оборудования. Этот документ скорее предназначен для объяснения техническому менеджменту заказчика ключевых концепции дизайна.
LLD – Low Level Design, низкоуровневый дизайн на основе высокоуровневого (HLD).
Он должен содержать все детали, необходимые для реализации проекта, такие как, информация о том, как подключить и настроить оборудование. Это полное руководство по реализации дизайна. Этот документ должен предоставлять достаточную информацию для его реализации даже не очень квалифицированным персоналом.Что-то, например, IP-адреса, номера AS, схема физической коммутации (cabling), может быть «вынесено» в отдельные документы, такие как NIP (Network Implementation Plan).
Построение сети начинается после создания этих документов и происходит в строгом соответствии с ними и затем проверяется заказчиком (тесты) на соответствие с дизайном.
Конечно, у разных интеграторов, у разных клиентов, в разных странах требования к проектной документации могут быть разные. Но хотелось бы избежать формальностей и рассмотреть вопрос по существу. Этот этап — не о проектировании, а о наведении порядка и нам нужен достаточный для выполнения наших задач набор документов (схем, таблиц, описаний …).
И на мой взгляд, существует некий абсолютный минимум, без которого невозможно эффективно контролировать сеть.
Это следующие документы:
- схема (журнал) физической коммутации (cabling)
- схема или схемы сети с существенной L2/L3 информацией
Схема физической коммутации
В некоторых небольших компаниях работы, связанные с установкой оборудования и физической коммутацией (cabling) находятся в зоне ответственности сетевых инженеров.
В этом случае задача отчасти решается следующим подходом.
- используйте дескрипцию на интерфейсе для описания того что к нему подключено
- административно выключите (shutdown) все неподключенные порты сетевого оборудования
Это даст вам возможность, даже в случае проблемы с линком (когда на этом интерфейсе не работает cdp или lldp), быстро определить, что подключено к этому порту.
Так же вы легко сможете увидеть какие порты у вас заняты, а какие свободны, что необходимо для планирования подключений нового сетевого оборудования, серверов или рабочих станций.
Но понятно, что если вы потеряете доступ к оборудованию, то вы потеряете и доступ к этой информации. К тому же таким образом вы не сможете запротоколировать такую важную информацию как что за оборудование, с какой потребляемой мощностью, с каким количеством портов, в какой стойке находится, какие там патч-панели и куда (в какую стойку/патч-панель) они скоммутированы. Поэтому все же дополнительное документирование (не только дескрипции на оборудовании) очень полезно.
Идеальным вариантом является использование приложений, созданных для работы с подобного рода информацией. Но можно ограничиться и простыми таблицами (например, в Excel) или отобразить информацию, которую вы считаете необходимой в L1/L2 схемах.
Важно!
Сетевой инженер, конечно, может достаточно хорошо знать тонкости и стандарты СКС, типы стоек, типы источников бесперебойного питания, что такое холодный и горячий коридор, делать правильное заземление ,… так же как в принципе он может знать физику элементарных частиц или C++. Но надо понимать все же, что все это не является его областью знания.
Поэтому хорошей практикой является для решения задач связанных с установкой, подключением, поддержкой работоспособности оборудования, а так же физической коммутацией иметь или выделенные отделы или выделенных людей. Обычно для дата-центров это дата-центр инженеры, а для офиса — help-desk.
Если такие подразделения предусмотрены в вашей компании, то вопросы ведения журнала физической коммутации не являются вашей задачей, и вы можете ограничиться только дескрипцией на интерфейсе и административным выключением не используемых портов.
Схемы сети
Нет универсального подхода к рисованию схем.
Самое важное — схемы должны давать понимание того, как будет ходить трафик, через какие логические и физические элементы вашей сети.
Под физическими элементами мы подразумеваем
- активное оборудование
- интерфейсы/порты активного оборудования
Под логическими —
- логические устройства (N7K VDC, Palo Alto VSYS, …)
- VRF
- виланы
- сабинтерфейсы
- туннели
- зоны
- …
Так же, если ваша сеть не является совсем элементарной, она будет состоять из разных сегментов.
Например
- дата-центр
- интернет
- WAN
- удаленный доступ
- офисная LAN
- DMZ
- …
Разумно будет иметь несколько схем, дающих как общую картину (как трафик ходит между всеми этими сегментами), так и подробное пояснение каждого отдельного сегмента.
Т. к. в современных сетях может быть много логических уровней, то возможно, хорошим (но не обязательным) подходом является делать различные схемы для различных уровней, например, в случае оверлейного подхода это могут бы следующие схемы:
- overlay
- L1/L2 underlay
- L3 underlay
Конечно, самой важной схемой, без которой невозможно понять идею вашего дизайна является схема маршрутизации.
Схема маршрутизации
Как минимум на этой схеме должно быть отражено
- какие протоколы маршрутизации и где используются
- основная информация о настройках протокола маршрутизации (area/AS number/router-id/…)
- на каких устройствах происходит редистрибуция
- где происходит фильтрация и агрегация маршрутов
- информация о дефолтном маршруте
Так же, часто полезной является L2 схема (OSI).
L2 схема (OSI)
На этой схеме может быть отражена следующая информация:
- какие VLAN
- какие порты являются trunk портами
- какие порты агрегированы в ether-channel (port channel), virtual port channel
- какие STP протоколы и на каких устройствах используются
- основные настройки STP: root/root backup, STP cost, port priority
- дополнительные настройки STP: BPDU guard/filter, root guard...
Характерные ошибки при проектировании
Пример плохого подхода к построению сети.
Давайте возьмем простой пример построения простой офисной локальной сети.
Имея опыт преподавания телекома студентам, могу сказать, что фактически любой студент к середине второго семестра обладает необходимым знанием (в рамках курса, который вел я) для того чтобы настроить простую офисную LAN.
Что сложного в том, чтобы подключить друг к другу коммутаторы, настроить VLAN, SVI интерфейсы (в случае L3 коммутаторов) и прописать статический роутинг?
Все будет работать.
Но при этом остаются в стороне вопросы, связанные с
- безопасностью
- резервированием
- масштабированием сети
- производительностью
- пропускной способностью
- надежностью
- …
Временами я слышу утверждение, что офисная LAN — это что-то очень простое и слышу это обычно от инженеров (и менеджеров), которые занимаются всем чем угодно, но только не сетями, и говорят они это настолько уверенно, что не удивляйтесь, если LAN будет сделана людьми с недостаточной практикой и знаниями и будет сделана приблизительно с теми ошибками, которые я опишу чуть ниже.
Характерные ошибки дизайна уровня L1 (OSI)
- Если все же вы отвечаете в том числе и за СКС, то одним из самых неприятных наследий, которое вам может достаться – это небрежная и не продуманная коммутация.
Так же к типу L1 я бы отнес ошибки, связанные с ресурсами используемого оборудования, например,
- недостаточная полоса пропускания
- недостаточный TCAM на оборудовании (или неэффективное его использование)
- недостаточная производительность (часто относится к фаерволам)
Характерные ошибки дизайна уровня L2 (OSI)
Часто, когда нет хорошего понимания, как работает STP, какие потенциальные проблемы он несет с собой, коммутаторы подключаются хаотично, с настройками по умолчанию, без дополнительного тюнинга STP.
В результате часто имеем следующее
- большой STP диаметр сети, что может приводить к бродкастным штормам
- STP root будут определен случайно (на основе mac адреса) и путь трафика будет неоптимальным
- порты, подключаемые к хостам, не будут настроены как edge (portfast), что приведет к пересчету STP при включении/выключении конечных станций
- сеть не будет сегментирована на уровне L1/L2, в результате чего проблемы с любым коммутатором (например, перегрузка по питанию) будет приводить к пересчету STP топологии и остановке трафика во всех VLAN на всех коммутаторах (в том числе и в критичном с точки зрения непрерывности сервиса сегменте)
Примеры ошибок в проектировании L3 (OSI)
Несколько характерных ошибок начинающих сетевиков:
- частое использование (или использование только) статического роутинга
- использование неоптимальных для данного дизайна протоколов маршрутизации
- неоптимальная логическая сегментация сети
- неоптимальное использование адресного пространства, что не позволяет производить агрегирование маршрутов
- отсутствие резервных маршрутов
- отсутствие резервирования для default gateway
- ассиметричный роутинг при перестроении маршрутов (может быть критичным в случае NAT/PAT, statefull firewalls)
- проблемы с MTU
- при перестройке маршрутов трафик идет через другие security зоны или даже другие фаерволы, что приводит к тому, что этот трафик дропается
- плохая масштабируемость топологии
Критерии оценки качества дизайна
Когда мы говорим про оптимальность/не оптимальность, мы должны понимать с точки зрения каких критериев мы можем оценить это. Вот с моей точки зрения наиболее существенные (но не все) критерии (и расшифровка применительно к протоколам маршрутизации):
- масштабируемость ( scalability)
Например, вы решили добавить еще один дата-центр. Насколько легко вы это можете сделать. - удобство в управлении (managability)
Насколько легко и безопасно делаются операционные изменения, например, анонсирование новой сетки или фильтрация маршрутов - доступность (availability)
Какой процент времени ваша система предоставляет требуемый уровень сервиса - безопасность (security)
Насколько защищены передаваемые данные - цена
Изменения
Основной принцип на данном этапе можно выразить формулой «не навреди».
Поэтому, даже если вы не вполне согласны с дизайном, и выбранной реализацией (конфигурацией), то не всегда целесообразно делать изменения. Разумным подходом является ранжирование всех выявленных проблем по двум параметрам:
- насколько легко эта проблема может быть исправлена
- насколько большой риск она несет
Прежде всего нужно устранить то, что в настоящем времени снижает уровень предоставляемого сервиса ниже допустимого, например, проблемы, приводящие к потерям пакетов. Затем устраняйте то, что легче всего и безопасней устранить в порядке уменьшения серьезности риска (от проблем в дизайне или конфигурации, несущих большие риски в сторону меньших).
Перфекционизм на данном этапе может быть вреден. Приведите дизайн к удовлетворительному состоянию и синхронизируйте конфигурацию сети в соответствии с ним.
Автор: nihole
