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

Сейчас мы не будем говорить об аудите безопасности – этому будет посвящена третья часть.

Сложность выполнения поставленной на этом этапе задачи, конечно, сильно варьируется от компании к компании.

Идеальная ситуация – это когда

• ваша сеть была создана в соответствии с проектом и вы имеете полный комплект документов
• в вашей компании был внедрен процесс контроля и управления изменениями ^[1] для сети
• в соответствии с этим процессом вы располагаете документами (в том числе и всеми необходимыми схемами), предоставляющими полную информацию об актуальном положении вещей

В этом случае ваша задача довольно проста. Вы должны изучить документы и просмотреть все те изменения, которые были сделаны.

В худшем варианте у вас будет

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

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

В этом случае, от вас потребуется в том числе и умение читать мысли, потому что вам придется научиться понимать, а что же хотели сделать “дизайнеры”, восстанавливать их логику, доделывать то, что не было закончено и удалять «мусор».
И, конечно, вам нужно будет купировать их ошибки, менять (на этом этапе по возможности минимально) дизайн и изменять или создавать заново схемы.

Данная статья ни в коей мере не претендует на полноту. Здесь я опишу лишь общие принципы и остановлюсь на некоторых распространенных проблемах, которые приходится решать.

Набор документов

Начнем с примера.

Ниже приведены некоторые документы, которые принято создавать в компании 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

Источник ^[2]