Как взять сетевую инфраструктуру под свой контроль. Глава вторая. Чистка и документирование

    Эта статья является второй в цикле статей «Как взять сетевую инфраструктуру под свой контроль». Содержание всех статей цикла и ссылки можно найти здесь.

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

    Изменения


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

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

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

    Перфекционизм на данном этапе может быть вреден. Приведите дизайн к удовлетворительному состоянию и синхронизируйте конфигурацию сети в соответствии с ним.
    • +11
    • 10,1k
    • 7
    Поделиться публикацией

    Комментарии 7

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

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

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

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое