image

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

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

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

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

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

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

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

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

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

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

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

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


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

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

Изменения


Основной принцип на данном этапе можно выразить формулой «не навреди».
Поэтому, даже если вы не вполне согласны с дизайном, и выбранной реализацией (конфигурацией), то не всегда целесообразно делать изменения. Разумным подходом является ранжирование всех выявленных проблем по двум параметрам:

  • насколько легко эта проблема может быть исправлена
  • насколько большой риск она несет

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

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

Комментарии (5)


  1. chemtech
    29.12.2018 09:45

    Спасибо за статью. Смотрели ли вы средства автоматической инвентаризации сетевой инфраструктуры?


    1. nihole Автор
      30.12.2018 20:44

      Смотрели какие-то решения лет 10 назад. Но сейчас не вижу в них особого смысла. Но нужно сказать что последние лет 8 инвентаризация не находилась в моей зоне ответственности.
      Инвентаризация — это совместная задача бухгалтерии, дата-центр инженеров и helpdesk. И как мне кажется разумно делать ее вручную, потому что вряд ли автоматическая система, например, поймет в каком дата-центре, в какой комнате и стойке стоит оборудование, но может я чего-то уже не знаю, все-таки информация почти 10-летней давности. Если есть опыт и знаете какой-то интересный продукт, напишите — интересно.


  1. alex_kag
    29.12.2018 14:50

    Спасибо, интересно почитать. а как на счет примеров схем сети? Как это оформляется "правильно"?


    1. nihole Автор
      30.12.2018 20:39

      Сейчас под рукой только «боевые» схемы. Они достаточно сложные для примера, да и «светить» их нельзя. Но вот нашел статью на хабре с «правильными» схемами в том числе.
      habr.com/post/230439
      Понятно, что у интеграторов могут существовать довольно жесткие требования к тому, как должна быть нарисована картинка, какие символы использовать… Это полезно в принципе.
      Но если по существу и если для себя (а не на продажу), то ИМХО, если ваша схема позволяет вам (и любому другому инженеру) во-первых понять как ходит трафик и во-вторых легко изменяема (если например это рисунок на бумажке, то не так легко изменить), то эта схема «хорошая». Ну и конечно должна быть схема физической коммутации.


      1. Protos
        30.12.2018 04:09

        Жалко что не во всех компаниях ИТ к такому приходит. У нас никогда не было таких схем и не хотя делать, мне как безопаснику модели нарушителя просто не реально строить