Добрый день, друзья! Сегодня я продолжу цикл, посвященный коммутаторам Extreme статьей по проектированию сети Enterprise.

В статье я постараюсь по возможности кратко:

• описать модульный подход к проектированию сети Etnterprise
• рассмотреть виды построения одного из важнейших модулей сети предприятия — опорной сети (ip-campus)
• описать достоинства и недостатки вариантов резервирования критичных узлов сети
• на абстрактном примере спроектировать/обновить небольшую сеть Enterprise
• выбрать коммутаторы Extreme для реализации спроектированной сети
• поработать с волокнами и IP адресацией

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

В любом случае, заинтересовавшихся прошу под кат.

Модульный подход проектирования сети

Начну я свою статью с довольно популярного модульного подхода при проектировании сети, который позволяет собрать паззл из кусочков сети в 1 цельную картину.

Сначала немного абстракции — я очень часто представляю этот подход как zoom на гео-картах, когда в первом приближении видна страна, во втором регионы, в третьем города и т.д.

Как пример рассмотрим такой пример:

• 1-е приближение — вся сеть предприятия представляет из себя набор различных уровней:
  
  • опорная сеть или campus
  • граничный уровень
  • уровень операторов связи
  • удаленные зоны
  
  
• 2-е приближение — каждый из этих уровней детализируются на отдельные модули
  
  • опорная сеть или campus состоит из:
    
    • 3-х или 2-х уровнего модуля, описывающего сеть предприятия и ее уровни — доступ, распределение и/или ядро
    • модуля описывающего ЦОД — центр обработки данных (по сути серверную часть инфраструктуры)
    
    
  • граничный уровень в свою очередь состоит из:
    
    • модуля подключения к интернету
    • модуля WAN и MAN, который отвечает за подключение географически распределенных объектов предприятия
    • модуль для построения VPN туннелей и Remote-Access доступа
    • зачастую у многих небольших предприятий несколько этих модулей или даже все из них, оказываются совмещены в одном
    
    
  • уровень провайдеров:
    
    • в данный уровень входят связи «во внешний мир» — темные оптоволокна (аренда волокон у операторов), каналы связи (Ethernet, G.703 и т.д.), доступ в Интернет.
    
    
  • удаленный уровень:
    
    • по большей части это филиалы предприятия, которые распределены в рамках города, области, страны или даже континентов.
    • также к этой зоне могут относиться резервный ЦОД, который дублируют работу основного
    • ну и конечно набирающие в последнее время популярность — teleworkers (удаленные рабочие места)
    
    
  
  
• 3-е приближение — каждый из модулей дробится на более мелкие модули или уровни. Например в campus-сети:
  
  • 3-х уровневая сеть делится на:
    
    • уровень доступа
    • уровень распределения
    • уровень ядра
    
    
  • ЦОД в более сложных случаях может делиться на:
    
    • 2-х или 3-х уровневую сетевую часть
    • серверную часть
    
    
  
  Все вышеописанное я постараюсь отобразить в следующем упрощенном рисунке:
  
  
  
  Как видно из рисунка выше — модульный подход помогает детализировать и структурировать общую картину на составные элементы, с которыми в дальнейшем уже можно работать.
  
  В рамках данной статьи я остановлюсь на уровне Campus Enterprise и опишу его поподробнее.
  
  

  Виды IP-CAMPUS сетей

  
  В бытность работы в провайдере и особенно позднее — в работе интегратора, я сталкивался с разной «зрелостью» сетей заказчика. Я не даром применяю термин зрелость, так как довольно часто встречаются случаи, когда структура сети растет с ростом самой компании и это в принципе закономерно.
  
  В небольшой компании, располагающейся в пределах одного здания, сеть предприятия может состоять всего-лишь из 1 граничного маршрутизатора, выполняющего роль межсетевого экрана, нескольких коммутаторов доступа и пары-тройки серверов.
  
  Я называю такую сеть для себя «одноуровневой» сетью — в ней абсолютно отсутствует явный уровень ядра сети, уровень распределения смещен на граничный маршрутизатор (с функциями firewall, VPN и возможно proxy), а коммутаторы доступа обслуживают как компьютеры сотрудников, так и сервера.
  
  
  
  В случае роста предприятия — увеличения количества сотрудников, сервисов и серверов, зачастую приходится:
  
  
  • увеличивать количество коммутаторов в сети и портов доступа
  • увеличивать серверные мощности
  • бороться с широковещательными доменами — внедрять сегментирование сети и маршрутизацию между сегментами
  • бороться со сбоями в работе сети, из-за которых возникают простои у сотрудников, так как это влечет за собой дополнительные финансовые траты для руководства (сотрудник простаивает, зар. плата платится, а работа не делается)
  • в процессе борьбы со сбоями, задумываться о резервировании критически важных узлов сети — маршрутизаторов, коммутаторов, серверов и сервисов
  • ужесточать политику безопасности, так как могут возникать коммерческие риски и опять же — для более стабильной работы сети
  
  Все это приводит к тому, что инженер (администратор сети) рано или поздно задумывается о правильном построении сети и приходит уже к 2-х уровневой модели.
  
  Эта модель уже явно выделяет из себя 2 уровня — уровень доступа и уровень распределения, который по совместительству является и уровнем ядра (collapsed-core).
  
  Совмещенный уровень распределения и ядра выполняет следующие функции:
  
  
  • агрегирует в себе линки от коммутаторов доступа
  • вводит маршрутизацию сегментов сети — пользователей и устройств становится так много, что в одну сеть /24 они не помещаются, а если помещаются, то broadcast-штормы вызывают постоянные сбои (особенно, если пользователи помогают им создавая петли)
  • обеспечивает связь между соседними сегментами коммутаторов (по более скоростным линкам)
  • обеспечивает связь между пользователями и их устройствами и серверной фермой, которая тоже к этому времени начинает выделяться в отдельный сегмент сети — ЦОД.
  • начинает обеспечивать совместно с коммутаторами доступа, в той или иной мере, политику безопасности, которая начинает появляться у предприятия к этому времени. Компания растет, коммерческие риски также растут (здесь я подразумеваю не только положения о коммерческой тайне, разграничение политик доступа и т.д., но и об элементарных простоях сети и сотрудников).
  
  Таким образом сеть рано или поздно вырастает до 2-х уровневой модели:
  
  
  
  В этой модели появляются особые требования как к коммутаторам уровня доступа, которые агрегируют в себе линки от пользователей и устройств сети (принтеры, точки доступа, VoIP устройства, IP-телефонов, IP-камер и т.д.) так и к коммутаторам уровня распределения и ядра.
  
  Коммутаторы доступа должны быть уже более интеллектуальны и функциональны, чтобы удовлетворять требованиям производительности, безопасности и гибкости сети, и должны:
  
  
  • иметь различные виды портов доступа и магистральных портов — желательно с возможностью запаса по росту трафика, так и по количеству портов
  • иметь достаточную коммутационную емкость и пропускную способность
  • иметь необходимый функционал безопасности, который удовлетворял бы текущей политики безопасности (а в идеале и росту ее дальнейших требований)
  • иметь возможность питания труднодоступных сетевых устройств с возможностью удаленной перезагрузки их по питанию (PoE, PoE+)
  • иметь возможность резервировать собственное электро-питание, чтобы использовать это в тех местах, где это необходимо
  • иметь (по возможности) дальнейший потенциал роста функционала — частый пример, когда коммутатор доступа со временем превращается в коммутатор распределения
  
  К коммутаторам распределения в свою очередь тоже предъявляются соответствующие требования:
  
  
  • как в части магистральных нисходящих портов в сторону коммутаторов доступа, так и в сторону peer интерфейсов соседних коммутаторов распределения (а в дальнейшем и возможных uplink интерфейсов в сторону ядра)
  • в части L2 и L3 функционала
  • в части функционала безопасности
  • в части обеспечения отказоустойчивости (резервирование, кластеризация и резервирование эл. питания)
  • в части обеспечения гибкости при балансировке трафика
  • иметь (по возможности) дальнейший потенциал роста функционала (трансформация со временем устройства агрегации в ядро)
  • в некоторых случаях на коммутаторах распределения может быть уместным использовать PoE, PoE+ порты.
  
  Дальше — больше: в случае проведения руководством политики активного роста и развития предприятия, сеть в дальнейшем также продолжит развиваться — предприятие может начать арендовать соседние здания, строить свои собственные корпуса или поглощать более мелких конкурентов, увеличивая тем самым количество рабочих мест для сотрудников. Одновременно с этим также происходит рост сети, который требует:
  
  
  • обеспечение сотрудников рабочими местами — необходимы новые коммутаторы доступа с портами доступа
  • наличие новых коммутаторов распределения для агрегирования линков от коммутаторов доступа
  • построения новых, а также модернизации существующих линий связи
  
  Как следствие происходит рост трафика по следующим причинам:
  
  
  • из-за увеличения портов доступа и соответственно пользователей сети
  • из-за увеличения трафика смежных подсистем, которые выбирают для себя в качестве транспорта сеть предприятия — телефония, безопасность, инженерные системы и т.д.
  • из-за внедрения дополнительных сервисов — с ростом персонала появляются новые отделы, требующие определенного ПО
  • увеличиваются вычислительные мощности ЦОД, чтобы удовлетворять требованиям инфраструктуры и приложений
  • растут требования безопасности к сети и информации — знаменитая триада ЦРУ (шутка), а если серьезно, то CIA — Confidentiality, Integrity and Availability:
    
    
    • в связи с этим, к критичным уровням сети — распределения и ЦОД появляются дополнительные требования по отказоустойчивости и резервированию
    • опять же происходит рост трафика из-за внедрения новых систем безопасности — например РКВИ и т.д.
    
    
  
  Рано или поздно рост трафика, сервисов и количества пользователей приведет к необходимости внедрения дополнительного уровня сети — ядра, которое будет выполнять высокоскоростную коммутацию/маршрутизацию пакетов с использованием высокоскоростных линков связи.
  
  В этот момент предприятие может перейти к 3-х уровневой модели сети:
  
  
  
  Как видно на рисунке выше — в такой сети присутствует уровень ядра, который агрегирует в себе скоростные линки от коммутаторов распределения. Таким образом к коммутаторам ядра также выдвигаются требования по:
  
  
  • пропускной способности интерфейсов — 1GE, 2.5GE,10GE, 40GE, 100GE
  • производительности коммутатора (switching capacity и forwarding perfomance)
  • типам интерфейсов — 1000BASE-T, SFP, SFP+, QSFP, QSFP+
  • количеству и набору интерфейсов
  • возможностей резервирования (стэкирование, кластеризация, резервирования плат управления (актуально для модульных коммутаторов), резервирование эл. питания и т.д.)
  • функционалу
  
  На таком уровне сети определенно необходима как ее техническая модификация:
  
  
  • резервирование узлов и связей ядра (очень-очень-очень желательно)
  • резервирование узлов и линков связей уровня распределения (в зависимости от критичности)
  • резервирование линков связи между коммутаторами доступа и уровнем распределения (по необходимости)
  • ввод протоколов динамической маршрутизации
  • балансировка трафика как в ядре так и на уровнях распределения и доступа (при необходимости )
  • внедрение дополнительных сервисов — как транспортных, так и сервисов безопасности (при необходимости)
  
  так и юридическая, определяющая сетевую политику безопасности предприятия, которая дополняет общую политику безопасности в части:
  
  
  • требований по внедрению и настройке тех или иных функций безопасности на коммутаторах доступа и распределения
  • требований доступа, мониторинга и управления оборудованием сети (протоколы удаленного доступа, разрешенные для управления сегменты сети, настройки логирования и т.д.)
  • требований к резервированию
  • требований к формирования минимально необходимого ЗИП-комплекта
  
  В этом разделе я кратко описал эволюцию сети и предприятия от нескольких коммутаторов и пары десятков сотрудников до нескольких десятков (а может быть и сотен коммутаторов) и нескольких сотен (а то и тысяч) только тех сотрудников, которые непосредственно работают в сети предприятия (а ведь есть еще производственные департаменты и инженерные сети).
  Понятно, что в реальности такого «чудесного» и быстрого развития предприятия не происходит.
  Обычно проходят годы, чтобы предприятие и сеть выросла от своего начального 1 уровня, до 3-го, описываемого мной.
  
  Зачем я пишу все эти прописные истины? Затем, что хочу здесь упомянуть такой термин как ROI — return-on-investment (возврат/окупаемость инвестиций) и рассмотреть ту его сторону, которая касается напрямую выбора сетевого оборудования.
  
  При выборе оборудования, сетевые инженеры и их руководители зачастую выбирают оборудование исходя из 2-х факторов — текущей цены оборудования и минимального технического функционала, который необходим на данный момент для решения конкретной задачи, или задач (о закупке оборудования для резервирования расскажу далее).
  
  При этом, редко рассматриваются возможности дальнейшего «роста» оборудования. При возникновении ситуации, когда оборудование себя исчерпает по функционалу или производительности, то в дальнейшем закупается более мощное и функциональное, а старое сдается на склад, либо куда-нибудь на сеть по принципу «чтобы стояло» (это кстати тоже служит причиной появления большого зоопарка оборудования и закупки кучи информационных систем, работающих с ним).
  
  Таким образом вместо покупки части лицензий на доп. функционал и производительность, которые стоят гораздо дешевле чем новое более высокопроизводительное оборудование, приходится покупать новую железку и переплачивать по следующим причинам:
  
  
  • сеть зачастую растет медленно и расширение функционала, или производительности коммутатора вашей сети может хватить еще на долгое время
  • не секрет, что оборудование иностранных вендоров привязано к заграничной валюте (доллару или евро). Если быть честным — рост доллара или евро (или периодическая мини-девальвация рубля, тут как посмотреть) приводит к тому, что доллар 10 лет назад и доллар сейчас это совсем разные вещи с точки зрения рубля
  
  Суммируя все выше сказанное, хочу заметить, что покупка сетевого оборудования с более широким функционалом сейчас, может привести к экономии в дальнейшем.
  Здесь затраты на закупку оборудования я рассматриваю в контексте инвестирования в свою сеть и инфраструктуру.
  
  Таким образом многие вендоры (не только Extreme) придерживаются принципа pay-as-you-grow, закладывая в оборудование кучу функционала и возможностей по увеличению производительности интерфейсов, которые в дальнейшем активируются покупкой отдельных лицензий. Также они предлагают модульные коммутаторы с широким набором интерфейсных и процессорных карточек, и возможностью последовательного наращивания как их количества, так и производительности.
  
  

  Резервирование критичных узлов

  
  В данной части статьи я хотел бы кратко описать основные принципы резервирования таких важных узлов сети, как коммутаторы ядра, ЦОД или распределения. И начать я хочу с рассмотрения общих видов резервирования — стэкирования и кластеризации.
  
  У каждого из методов есть свои плюсы и минусы, о которых я и хотел бы поговорить.
  
  Ниже представлена общая сводная таблица сравнения 2-х методов:
  
  
  
  
  • управление — как видно из таблицы, в этом плане преимущество у стэкирования так как с точки зрения управления стэк из нескольких коммутаторов представляется одним коммутатором с большим количеством портов. Вместо управления например 8-ю различными коммутаторами при кластеризации вы можете управлять только одним при стэкировании.
  • расстояние — на данный момент, строго говоря, преимущество у кластеризации не является таким уж явным, так как появились технологии стэкирования коммутаторов через порты стэкирования или порты двойного назначения (например SummitStack-V у Extreme, VSS — у Cisco и т.д.), которые также зависят от типов трансиверов. Здесь преимущество отдано кластеризации по принципу того, что при стэкировании существуют варианты, при которых приходится использовать обычные порты стэкирования, которые зачастую подключаются специальными кабелями ограниченной длины — 0.5, 1, 1.5, 3 или 5 метров.
  • обновление ПО — здесь мы видим, что у кластеризации преимущество перед стэкированием и дело в следующем — при обновлении версии ПО оборудования при стэкировании вы обновляете ПО на мастер-коммутаторе, который в дальнейшем берет на себя роль размещения нового ПО на standby-member коммутаторах стэка. С одной стороны это облегчает вашу работу, но обновление ПО зачастую требует аппаратной перезагрузки оборудования, что приводит к перезагрузке всего стэка и таким образом к перерыву его работы и всех завязанных на него сервисов на время = времени перезагрузки. Обычно это очень критично для ядра и ЦОД. При кластеризации — у вас имеется 2 независящих друг от друга устройства, на которых вы можете обновлять ПО последовательно друг за другом. При этом перерывов в сервисах можно избежать.
  • конфигурация настроек — здесь преимущество конечно у стэкирования, так как в случае и с управлением вам необходимо править настройки только для одного устройства и его конфигурационного файла. У кластеризации же количество файлов конфигурации будет равняться количесту узлов кластера.
  • отказоустойчивость — здесь обе технологии приблизительно равны, но небольшое преимущество все-таки имеется у кластеризации. Причина здесь кроется в следующем — если рассматривать стэк с точки зрения запущенных процессов и протоколов, то мы увидим следующее:
    
    • есть master-switch, на котором запущены все основные процессы и протоколы (например протокол динамической маршрутизации — OSPF)
    • есть остальные slave-switch коммутаторы, на которых запущены основные процессы, необходимые для работы в стэке и обслуживании трафика, проходящего через них
    • при выходе из строя master-switch коммутатора, следующий по приоритету slave-switch коммутатор обнаруживает отказ мастера
    • он инициирует себя как мастера и запускает все процессы, которые работали на мастере (в том числе и наблюдаемый нами протокол OSPF)
    • после некоторого времени старта процессов (обычно довольно маленького), начинает отрабатывать уже сам протокол OSPF
    • таким образом OSPF при отказе одного из узлов при кластеризации отработает чуточку быстрее чем при стэкировании (на время, необходимое запуску и инициализации процессов и протоколов на slave коммутаторе стэка). Хотя должен заметить, что современные протоколы стэкирования и коммутаторы отрабатывают очень быстро, зачастую длительность перерыва по трафику при переключении стэка занимает менее одной секунды, но все-таки номинально кластеризация выигрывает по данному параметру.
    
    
  • сложность — как видно из таблицы, в плане сложности выигрывает стэкирование. Это прямое следствие пунктов «управления» и «конфигурации настроек». Одиночный узел занимает гораздо меньше времени для настроек и управления. Также при кластеризации довольно часто приходится настраивать дополнительные протоколы маршрутизации или протоколы резервирования шлюзов — VRRP, HSRP и другие.
  • замена узлов — тут однозначное преимущество у стэкирования. Очень часто для замены коммутатора в стэке необходимо провести минимально необходимые настройки оборудования, например:
    
    • обновить ПО нового коммутатора до версии ПО стэка (а это можно делать сразу при поступлении коммутаторов в ЗИП)
    • настроить несколько базовых комманд для стэкирования (а для некоторых видов коммутаторов даже это может не требоваться)
    • вытащить вышедший из строя коммутатор стэка и подключить новый
    • подключить электропитание и патчкорды
    
    
  • упругость — я рассматриваю для себя как один из основных параметров. В целом упругость это комплексная характеристика, которая означает свойство чего-либо изменяться под действием нагрузки и возвращаться к первоначальному виду после ее исчезновения. Как не странно для кластеризации она будет выше даже с учетом счета 4:3 по характеристикам в пользу стэкирования. Все дело в человеческом факторе. Да-да, не удивляйтесь — в силе таких параметрах стэкирования, как единое управление, конфигурация настроек и облегченная сложность и кроется слабость стэкирования, когда в дело вступает человеческий фактор.
  
  За свою работу в области IT я много раз встречал ситуации (да чего уж греха таить и сам наступал на эти же грабли, особенно в начале), когда при настройке стэка инженер ошибался в вводе той или иной команды или включением/oтключением того или иного функионала на оборудовании, что приводило к отказу всего стэка и его ручной перезагрузке. Отдельно стоит упомянуть любителей приложения Putty для Windows (ох уж это копирование правой кнопкой мыши).
  
  На самом деле обе технологии довольно хороши (особенно по сравнению с отсутствием резервирования) и у каждой есть свои сильные и слабые стороны, но для уровня ядра и для высоконагруженного ЦОД я бы предпочел все-таки использовать кластеризацию.
  
  Хотя это только мое мнение. Многие профессиональные инженеры, которые уже много лет на профессиональном уровне занимаются поддержкой сети, могут в равной степени пользоваться обеими технологиями — тут все зависит от опыта и квалификации.
  
  Помимо технологий стэкирования и резервирования узлов сети, существуют также общие принципы резервирования частей самого узла сети и связей между узлами:
  
  Под резервированием внутри узла сети я понимаю:
  
  
  • резервирование блоков питания — установка 2-х блоков питания, дублирующих друг друга (да еще желательно подключенная к 1-й категории электропитания) может значительно облегчить вам жизнь.
  • резервирование плат управления — в большей степени относится к модульным коммутаторам, у которых предусмотрено подключение нескольких дублирующих друг друга плат управления.
  • резервирование интерфейсных карт — также относится по большей части к модульным коммутаторам.
  
  Под резервированием связей/линков понимается в основном наличие дублирующих друг друга кабельных трасс (или радиолинков в случае открытых пространств) с:
  
  
  • распределением по разным кабельным шахтам и каналам внутри здания
  • географическим распределением по территории на уровне 2-х и более зданий, города, области или страны (так называемые объемные кольца)
  
  При этом при построении резервных линков связи необходимо соблюдать ряд рекомендаций для оборудования:
  
  
  • в случае дублирования интерфейсных карт модульного коммутатора, или при наличии стэка, необходимо распределять линки между юнитами — интерфейсными карточками в случае модульных коммутаторов и коммутаторами в случае стэка.
  • желательно использовать протоколы агрегирования связи (LACP, MLT, PAgP и т.д.) для объединения линков в группы и балансировки нагрузки между ними.
  • использовать маршрутизаторы поддерживающие протоколы ECMP (Equal-Cost-Multi-Path) — когда при доставке нескольких пакетов по одному маршруту эти пакеты идут не через один best path (и интерфейс) а распределяются по нескольким best-path (и нескольким интерфейсам), которые определяются по равенстве метрик протокола маршрутизации, который в свою очередь отвечает за наполнение итоговой таблицы маршрутизации.
  
  А теперь, как и обещал, опишу реальный случай из моей практики и принцип экономии при резервировании критичных узлов, который произошел несколько лет назад:
  
  
  • в одной компании, назову ее X, была стандартная 3-х уровневая модель сети:
    
    • с несколькими ядрами
    • несколькими десятками агрегаций
    • несколькими тысячами коммутаторов доступа
    • несколькими десятками тысяч пользователей
    
    
  • сеть была довольно сложно построена:
    
    
    • с кучей динамических протоколов маршрутизации и протоколов — OSPF, MP-BGP, MPLS, PIM, IGMP, IPv6 и т.д.
    • кучей сервисов — доступ в интернет, L2 и L3 VPN, VoIP, IPTV, выделенных линий и т.д.
    
    
  • но было одно узкое место в сети — граничный маршрутизатор, который сочетал в себе функции BGP-бордера и терминировал некоторые пользовательские сервисы
  • да, он стоил как крыло самолета (несколько миллионов рублей)
  • да, на тот момент он был одним из топовых устройств в линейки у самого именитого сетевого вендора
  • да, он должен был быть очень надежным — с отличным показателем MTBF
  • да, у него было 4 блока питания, собранных по схеме 2х2 и включенных с разных УЭПС и вводов.
  
  Но все это не отменяло того факта, что он был единой точкой отказа сети.
  
  И в один, далеко не прекрасный для меня и моих коллег день этот маршрутизатор приказал долго жить (в дальнейшем уже выяснили, что произошел какой-то сбой на линии эл. питания через УЭПС, который привел к выходу одновременно 2-х блоков питания и при этом один из блоков спалил модуль RP маршрутизатора и интерфейсную карту, которые были подключены к общей шине данных устройства).
  
  Резервных плат — RP и интерфейсной карточки у нас не было, но был контракт на замену оборудования или его комплектующих с одним из партнеров по схеме NBD.
  
  К сожалению у партнеров на тот момент на складе оказалась только интерфейсная карточка, но не было платы RP, она пришла только спустя несколько дней (через 3 дня).
  
  В итоге наличие единой точки отказа в сети (даже с наличием контракта поддержки и замены оборудования) вылилось в следующие финансовые затраты:
  
  
  • доля услуг компании, приходящаяся или связанная с этим бордером, составляла порядка 60-70%
  • как потом было подсчитано, дневная прибыль составляла около 900 тыс. рублей (примерно) на тот момент
  • таким образом за 3 дня простоя теоретически была утеряна прибыль в размере от 1 млн 620 тыс. рублей до 1 млн 890 тыс. рублей
  
  Конечно чистые потери были меньше, так как компенсации основной части пользователей были возвращены не в виде денег, а в виде услуг, но они все равно были:
  
  
  • часть компенсаций корпоративным пользователям
  • повышенные расходы на сотрудников предприятия, которые работали все эти 3-4 дня в полном составе — переработки, ночные дежурства, увеличение смен и т.д.
  • репутационные потери, что тоже не маловажно
  • и самое важное — нервы, как руководства и сотрудников, так и клиентов
  
  В итоге политика компании была пересмотрена:
  
  
  • отказались от контракта замены по условию NBD
  • оставили обычный сервисный контракт
  • закупили дублирующий маршрутизатор стоимостью примерно 1 — 1.3 млн рублей для резервирования 90% функционала основного
  
  В дальнейшем закупка дополнительного оборудования и резервирование основного позволило сбалансировать между ними нагрузку по внешним линкам, трафику и пользователям, и обеспечило в дальнейших авариях запас прочности для компании.
  
  

  Пример проектирования сети Enterprise

  
  В данной части статьи я постараюсь изложить основные моменты при расчете опорной сети предприятия. Я не буду перегружать вас всей методикой PPDIOO (Prepare-Planning-Design-Implement-Operate-Optimize), а лишь обозначу главные ее моменты:
  
  
  • Prepare/Подготовка — необходимо определиться со своим руководством о целях модернизации сети, которых вы хотите добиться — повысить отказоустойчивость, внедрить новые сервисы или технологии. Определение ограничений — технических и организационных я здесь пропущу, так как предполагаю, что вы являетесь сотрудником организации и обладаете большим запасом по времени на их преодоление. К теме бюджета вернусь ниже.
  • Planning/Планирование — здесь вы должны будете построить полную характеристику вашей текущей сети (если вы ее еще не знаете), т.е. описать сеть как она есть сейчас:
    
    
    • количество и тип оборудования
    • количество и типы портов
    • существующие кабельные трассы и схемы коммутации внутри зданий и между ними
    • схемы электропитания
    • L2 и L3 адресации
    • построить карты сетей Wi-Fi c указанием точек доступа и контроллеров
    • описать свою серверную ферму
    • желательно описать все свои сервисы и связи между ними
    • если у вас уже внедрена в том или ином виде политика сетевой безопасности и разграничения сетевого доступа обязательно учесть ее при проектировании
    • сразу замечу, что второй шаг, по сути представляет из себя полную инвентаризацию сети, начиная от кабельной инфраструктуры и схем электропитания, и заканчивая сервисами (приложениями и их портами). Этот шаг очень-очень трудоемкий и даже порой нудный. Если вы или ваш предшественник не вел документации или даже элементарной системы мониторинга, то самое время подумать об этом. Сеть имеет тенденцию меняться со временем с той или иной скоростью и только ведение актуальной документации или системы мониторинга может помочь вам уследить за ее состоянием и облегчить ее администрирование. Но это уже относится к шагу operate.
    
    
  • Design/Проектирование — вооружившись полными знаниями о вашей сети, полученными на предыдущем шаге, вы наконец-то садитесь и думаете как модернизировать вашу сеть. Ниже я постараюсь продемонстрировать небольшой пример расчета сети.
  
  Для себя я составил небольшой список с исходными данными, которым я буду руководствоваться при расчете и проектировании опорной сети.
  
  Представим шаг Prepare в виде списка того, что у нас есть в наличии и что планируется сделать:
  
  
  • есть довольно крупное предприятие с приблизительным количеством рабочих мест, порядка 700-800 шт (здесь я имею ввиду тех сотрудников, которым требуется доступ к сети предприятия)
  • имеется несколько отдельно-стоящих зданий в пределах территории предприятия:
  • Основные корпуса:
    
    
    • количество зданий — 2 шт
    • количество этажей в здании — 7 шт
    • количество телекоммуникационных шкафов на этаже в одном здании — 3 (всего 21) шт
    • количество сотрудников в здании =~ 250 человек
    
    
  • Дополнительные корпуса:
    
    
    • количество зданий — 10 шт
    • количество этажей в здании/цеху — 2 шт
    • количество телекоммуникационных шкафов в здании — 3 шт
    • количество сотрудников в здании =~ 20 человек
    
    
  • Текущий уровень ядра сети (кстати очень распространенная схема, которая встречалась мне не раз в том или ином виде и составе портов) представлен:
    
    • 2-мя коммутаторами L2:
      
      
      • 1Gb порты типа RJ-45 — 24 шт
      • 1Gb SFP порты — 4 шт
    • 1-м коммутатором L2:
      
      
      • 1Gb SFP порты — 24 шт
    • топология ядра — кольцо
    • peer-to-peer линки между коммутаторами включены с использованием оптических волокон
    • коммутаторы располагаются в небольших серверных комнатах со шкафами
  • Текущий уровень распределения:
    • совмещен с уровнем ядра сети в части агрегирования линков от коммутаторов доступа
    • L3 адресация вынесена на граничный маршрутизатор и/или межсетевой экран
  • Текущий уровень доступа:
    
    
    • коммутаторы L2 с 16 x 100 Mb портами доступа RJ-45 и 2-х гигабитными аплинк combo-портами RJ-45/SFP
    • коммутаторы располагаются в шкафах на этажах
    • топология коммутаторов доступа:
      
      
      • звезда (hub-and-spoke — ступица и спицы) с коммутатором ядра/распределения в середине
      • луч/spoke представляет из себя ветку коммутаторов по этажам — 3 шт в цепочке
    • имеются неуправляемые коммутаторы доступа
    • коммутаторы в 9 дополнительных корпусах включены через медиаконвертора (преобразователи оптического сигнала в электрический)
  • Текущая кабельная инфраструктура:
    
    
    • Кабельная система между зданиями:
      
      • имеется оптический кабель между 2-мя главными зданиями емкостью 8 волокон
      • имеется по 1-му оптическому кабелю между одним из дополнительных корпусов (где установлен коммутатор ядра) и каждым из основных строений емкостью 8 волокон каждый
      • имеется по 1-му оптическому кабелю между доп. корпусами и корпусами с установленными коммутаторами ядра емкостью 4 волокна (их распределение показано на картинке ниже)
      • тип волокон во всех кабелях — одномодовый/SMF
      • используются 2-х волоконные одномодовые SFP трансиверы
      • часть кабелей терминируются на оптических кроссах (ODF) в отдельных помещениях (кросс-залы/серверные), а часть кабелей в этажных ШТО
      
      
    • Кабельная система внутри зданий:
      
      
      • имеется смешанная кабельная структура между серверными комнатами и первыми шкафами на этажах:
      • медные кабели Cat5e — 10 шт (или 100 парные кабели)
      • оптоволоконный многомодовый/MMF кабель на 4 или 8 волокон — 1 шт
      • оптоволоконный многомодовый/MMF кабель на 4 волокна между этажными шкафами
      • медные кабели Cat5e между этажными шкафами и розетками доступа
    • текущий ЦОД:
      
      
      • есть несколько серверов, например 6 штук
      • включены 1Gb портами в коммутатор ядра в 1-м основном здании
      • все приложения предприятия вынесены на сервера
    • адресация L2, L3 и маршрутизация:
      
      • в сети имеется несколько VLAN — 2,3 штуки на здание
      • сервера выделены в отдельную /24 сеть
      • для внутренних нужд используются серые сети класса B, входящие в диапазон — 172.16.0.0/16
      • L3 адреса терминируются на граничном маршрутизаторе и/или на межсетевом экране
      • используется статическая маршрутизация
    • дополнительная информация:
      
      
      • телефония:
        
        • в зданиях и некоторых корпусах развернута традиционная телефония с использованием цифровых АТС старого образца (не IP-АТС)
        • необходимо телефонизировать новые корпуса, без затрат на протяжку дорогих медных кабельных линий определенной емкости и построения дублирующей СКС для телефонии внутри зданий
        • со временем планируется внедрять IP-телефонию на всей территории предприятия, совмещать ее с CRM-системами и переводить на нее всех сотрудников
      • емкость портов:
        
        
        • необходимо проанализировать текущую емкость магистральных портов и портов доступа, и зарезервировать не менее 25-30% под будущие нужды
        • проанализировать достаточность текущей пропускной способности портов доступа и магистральных линков
        • предусмотреть наличие PoE/PoE+ портов доступа для устройств из смежных систем — видеонаблюдения и телефонии
      • видеонаблюдение:
        
        • планируется использовать сеть предприятия в качестве транспорта для сети видеонаблюдения
        • необходимо предусмотреть наличие PoE портов для камер видеонаблюдения
      • беспроводные системы:
        
        
        • в дальнейшем планируется внедрить беспроводную инфраструктуру для мобильности сотрудников
        • необходимо предусмотреть наличие PoE портов для точек доступа
      • бюджет, сроки и требования к оборудованию:
        
        
        • использовать имеющееся оборудование по максимуму
        • при проектировании сети учесть возможность расширения пропускной способности сети на N лет вперед
        • при проектировании сети учесть поддержку всевозможных функций безопасности — тут перечень функционала, начиная от port-security и заканчивая аутентификацией и авторизацией пользователей по 802.1х.
        • максимально возможно зарезервировать критичные узлы сети первостепенной важности — ядро и ЦОД, и предусмотреть возможность резервирования узлов второстепенной важности — узлов распределения
        • бюджет проекта должен предусматривать последовательное финансирование в несколько этапов
        • сумма бюджета — тут уже каждое предприятие определяет для себя, руководствуясь своими финансовыми показателями
        • сроки — в самом идеальном случае тут не будет явных сроков, так как это внутренний проект компании, который реализуется силами своих сотрудников, либо они будут относительно комфортные — например, 1 год (и более). В более худшем случае — может быть от 3-х месяцев до полугода.
      • устранить текущие проблемы в сети:
        
        
        • потери пакетов
        • проблемы с DHCP на более-менее интеллектуальных коммутаторах доступа, связанные с использованием семейства протоколов STP для борьбы с петлями на портах доступа.
        • избавиться от наличия интерфейса DHCP сервера в каждом VLAN сотрудников
        • возникновение петель коммутации, связанных с самовольным включением управляемых/неуправляемых коммутаторов в кабинетах и подключением к них всевозможных устройств
        • список можно продолжать и продолжать...
      
      Шаг Planning — характеристика состояния вашей текущей сети, как я уже писал, зависит от наличия качественной системы мониторинга и степени ее документированности. На этом шаге вам придется:
      
      
      • как минимум зарисовать существующую сеть для дальнейшего анализа
      • собрать данные с оборудования:
        
        
        • трафик по магистральным портам
        • ошибки на портах
        • загрузка CPU и расход памяти на коммутаторах и маршрутизаторах
        • расписать L2-L3 схемы по VLAN-ам и IP адресам
      • поднять схемы кабельных трасс:
        
        
        • поволоконные схемы и схемы распайки оптических кроссов
        • схемы медных кабельных распределений между серверными и этажами
        • схемы медных кабельных распределений между этажами и кабинетами
        • проверить наличие оптических кроссов и патч-панелей в серверных и шкафах
      • проверить схемы электропитания в серверных и этажных шкафах
      • проверить наличие ИБП и АКБ на критичных узлах
      • проанализировать все данные
      
      Руководствуясь данными из этапа подготовки, у меня получилась приблизительная логическая схема:
      
      
      
      Далее, следуя модульному подходу, необходимо выделить уровни и модули предприятия:
      
      
      
      Границы (Edge) в данной статье я не буду касаться, а коротко напомню базовые тезисы по каждому из модулей Campus:
      
      
      • Доступ — на данном уровне должен обеспечивать:
        
        • необходимое количество портов для доступа пользователей к сети
        • выполнение политик безопасности — фильтрация трафика и протоколов
        • сжатие широковещательных доменов и сегментирование сети с помощью VLAN
        • внедрение отдельных VLAN для голосового трафика
        • поддержку QoS
        • поддержку PoE портов доступа
        • поддержку IP multicast
        • отказоустойчивость восходящих линков связи совместно с уровнем распределения (желательно)
      • Распределение — на данном уровне должно обеспечиваться:
        
        
        • необходимое количество портов для подключения коммутаторов доступа
        • агрегирование и резервирование линков коммутаторов доступа
        • IP маршрутизация
        • фильтрация пакетов
        • поддержка QoS
        • отказоустойчивость на уровне линков, оборудования и электропитания (очень желательно)
      • Ядро — должно обеспечивать:
        
        
        • высокую скорость коммутации и маршрутизации пакетов
        • необходимое количество портов для подключения коммутаторов распределения
        • поддержку IP маршрутизации и динамических протоколов маршрутизации с быстрой сходимостью сети
        • поддержку QoS
        • функционал безопасности для защиты доступа к оборудованию и сontrol plane
        • отказоустойчивость на уровне оборудования и электропитания (обязательно)
      • ЦОД — сетевой уровень этого модуля должен обеспечивать:
        
        
        • высокоскоростные линки связи
        • необходимое количество портов для подключения серверов
        • резервирование линков связи как между серверами и коммутаторами ЦОД, так и между коммутаторами ЦОД и ядром сети (обязательно)
        • резервирование оборудования и электропитания (обязательно)
        • поддержку QoS
      
      Далее нам нужно посчитать наши порты и линки связи и определить требования.
      Уровень доступа — таблица расчета портов
      
      Итак, мы получили данные распределения портов доступа по зданиям. Теперь необходимо проанализировать требования к уровню доступа и замечания и наметить варианты решения.
      Уровень доступа — требования и варианты решения
      
      Далее посчитаем порты и линки связи для следующих уровней:
      
      Уровень распределения
      
      Уровень ядра
      
      Уровень ЦОД
      
      При расчете мы получили следующее:
      
      
      • уровень доступа — требуются 24-х и 48-ми портовые коммутаторы доступа, желательно с 1Gb портами доступа и с оптическими uplink портами SFP с поддержкой PoE и широким функционалом:
        
        
        • в сумме они дадут 504 порта доступа, что в принципе покроет требования spare портов, если будет принято решения использовать 2 порта на рабочее место — IP-телефон и порт данных.
        • возможно использование на каждом этаже одного 48-ми портового коммутатора с PoE функционалом, обеспечивающего порты доступа для требований:
          
          
          • резерва — примерно 102 spare порта (22%) на главных зданиях. Для дополнительных корпусов чуть больше — 25%.
          • видеонаблюдение
          • беспроводной сети
      • уровень распределения — требуются коммутаторы с набором SFP портов от 12 до 48 портов с наличием SFP+ портов не менее 2-х штук, с возможностью стэкирования и расширенным функционалом, а также наличием резервных блоков питания.
      • уровень ядра — требуются высокоскоростные коммутаторы от 12 до 24-х SFP/SFP+ портов с поддержкой как стэкирования, так и кластеризации с поддержкой MC-LAG. Должен заметить, что возможно использование и средств маршрутизации для балансировки трафика. Последние поколения L3 коммутаторов и маршрутизаторов поддерживает ECMP с балансировкой трафика по 4 и более маршрутам с одинаковой метрикой.
      • уровень ЦОД — требуются коммутаторы от 8 до 24-х SFP/SFP+ портов с поддержкой как стэкирования, так и кластеризации с поддержкой MC-LAG.
      
      Целевая схема сети в итоге получилась такой
      
      

      Выбор коммутаторов Extreme для реализации проекта

      
      Ну вот мы и подошли к главному — моменту выбора коммутаторов для реализации нашего проекта. Для получившейся целевой схемы подойдут следующие коммутаторы Extreme:
      

      Уровень	Модель	Порты	Описание
      ядро	x620-16x-Base * x670-G2-48x-4q-Base*	16 x 10GE SFP+       48x10GE SFP+ и 4x40 GE QSFP+	Для основных нужд ядра: высокоскоростные линки расширенный функционал маршрутизации и безопасности резервирование электропитания доп. блоками питания поддержка стэкирования и кластеризации С минимальными требованиями подойдет коммутатор серии x620. В случае расширенных требований к количеству портов и более широкому функционалу стоит рассматривать коммутаторы серии x670-G2.
      ЦОД	x620-16x-Base* x590-24x-1q-2c* x670-G2-48x-4q-Base*	16 x 10GE SFP+       24x10GE SFP, 1xQSFP+, 2xQSFP28     48x10GE SFP+ и 4x40 GE QSFP+	Для основных нужд ЦОД: высокоскоростные линки резервирование электропитания доп. блоками питания поддержка стэкирования и кластеризации С минимальными требованиями подойдет коммутатор серии x620. В случае расширенных требований к количеству портов и более широкому функционалу стоит рассматривать коммутаторы серии x670-G2 и x590-24x-1q-2c.
      распределение	X460-G2-24x-10GE4-Base* X460-G2-48x-10GE4-Base*	24x1GE SFP, 8x1000 RJ-45, 4x10GE SFP+       48x1GE SFP, 4x10GE SFP+	Для основных нужд распределения: необходимое количество оптических портов резервирование электропитания доп. блоками питания поддержка стэкирования и кластеризации необходимый L3 функционал Идеально подойдут коммутаторы серии x460-G2. Наличие резервных блоков питания с возможностью расширения и добавления портов 10G, CX (для стэкирования) и QSFP+ делает их идеальными коммутаторами для уровня распределения с портами до 1 Gb.
      доступ	X440-G2-24p-10GE4* X440-G2-24t-10GE4* X440-G2-48t-10GE4* X440-G2-48p-10GE4*	24x1000BASE-T(4 x SFP combo), 4x10GE SFP+ (PoE бюджет 380 Вт)   24x1000BASE-T(4 x SFP combo), 4x10GE SFP+     24x1000BASE-T(4 x SFP combo), 4x10GE SFP+ combo ports   48x1000BASE-T(4 x SFP combo),4x10GE SFP+ combo ports (PoE бюджет 740 Вт)	Для нужд доступа: необходимое количество портов доступа поддержка PoE/PoE+ функционал и возможность расширения портов дополнительный бонус в виде поддержки стэкирования 10Gb портами «из коробки» Рекомендую обратить внимания на эту линейку в виде ее гибкости в части портов, производительности и функционала.

      
      *спецификацию выбранных коммутаторов можно посмотреть в первой статье цикла — обзор коммутаторов Extreme
      
      На этом мне можно было бы закончить статью, но я хотел бы осветить дополнительно 2 аспекта, с которыми столкнется любой инженер при развитии или модернизации своей сети:
      
      
      • работа с кабельными трассами — волокнами и медными линиями
      • IP адресация
      
      

      Работа с волокнами

      
      Выше я привел целевую схему к которой необходимо прийти. Для ее реализации необходимо следующее количество связей для оборудования:
      
      количество линков связи
      
      Как видно из таблицы минимальное количество волокон требующееся для обеспечения отказоустойчивости уровней сети (модуля ядра, цод и распределений в 2-х зданий) — 10 штук.
      
      На этапе характеризации сети мы выяснили, что в кабеле между зданиями всего 8 волокон. Что же делать в такой ситуации?
      
      Я приведу несколько решений:
      
      
      • первый очевидный шаг — использовать свободные волокна в кабеле между зданием 1 — корпусом 1 и корпусом 1- зданием 2 (как видно из таблицы — используется только 2 из 8 волокон в каждом кабеле). Для этого достаточно поставить оптические кроссировки между кроссами в корпусе 1 и при необходимости использовать SFP модули с запасом оптического бюджета.
      • вторым шагом — возможно использование технологии CWDM — уплотнение несущих длин волн в пределах одного волокна. Эта технология гораздо дешевле DWMD и довольно проста для реализации. В основном требования предъявляются к качеству оптических волокон и SFP/SFP+ трансиверам определенной длинны и бюджета. Как я уже говорил в предыдущей статье — возможность коммутаторов распознавать трансиверы сторонних производителей может сильно облегчить нам жизнь и снизить капитальные расходы на строительство дополнительных оптических кабелей.
      • третьим шагом стоит рассматривать возможность увеличения волокон путем прокладки дополнительных оптических кабелей.
      
      Дальше мы смотрим на количество волокон между зданиями с установленными коммутаторами распределения и доп. корпусами 2-10. Здесь тоже далеко не все так однозначно:
      
      
      • во-первых, не хватает волокон для реализации нашей целевой схемы — на каждый коммутатор по 2 волокна (как мы помним у нас кабели с 4 ОВ на каждый корпус)
      • во-вторых, даже при наличии достаточного количества волокон между зданиями, внутри корпусов используются MMF волокна, которые не позволят нам просто так состыковать волокна SMF и MMF (я говорю о расстояниях между зданиями свыше 300-400 метров)
      
      В таких случаях можно рассматривать следующие варианты:
      
      
      • обеспечение каждого коммутатора SMF волокнами:
        
        
        • если позволяет расстояние — можно протянуть дополнительные длинные патчкорды между коммутаторами. В свое время мы пользовались патчкордами 30-50 м длины.
        • проложить относительно дешевый оптический SMF кабель малой емкости между шкафами
        • на крайний вариант использовать различные SMF-MMF преобразователи
      • Для минимизации используемых волокон между зданиями можно:
        
        
        • использовать функционал стэкирования коммутаторов доступа x440-G2 — при этом использовать по 1 SMF волокну до каждого коммутатора на этаже, что позволит вместо 6 волокон и портов использовать 3 волокна и порта на каждой стороне
        • использовать по 2 волокна для подключения первого коммутатора в ветке и последнего. Агрегировать линки на граничных коммутаторах доступа и использовать протоколы STP в получившемся кольце.
      
      

      IP-адресация

      
      Здесь я приведу примерный расчет адресации для нашей схемы.
      
      На данный момент у нас имеется несколько сетей B класса — 172.16.0.0/16. При расчете IP адресного пространства я буду руководствоваться следующими соображениями:
      
      
      • 4 бита второго октета будут обозначать здания — 172.16.0.0/12.
      • 3 октет будет обозначать номер этажа в здании.
      • 3 октет = 255 будет выделен для point-to-point линков оборудования и сети управления.
      • один managment VLAN на этаж для управления коммутаторами.
      • один пользовательский VLAN на коммутатор (в среднем 24 порта).
      • один Voice VLAN на коммутатор (в среднем 24 порта).
      • один VLAN для системы видеонаблюдения на этаж.
      • один влан для Wi-Fi устройств на этаж.
      
      У меня получилась примерно такие таблицы:
      сеть 172.16.0.0/14
      сеть 172.20.0.0/14
      
      В таблице выше я привел примерное разнесение сетей по зданиям и этажам с одной стороны и сетям (пользовательские, управление и служебные) с другой.
      
      На самом деле выбор серой сети 172.16.0.0/12 является не самым оптимальным, так как ограничивает нас в количестве сетей (с 16 до 31) для зданий, а ведь есть еще и удаленные офисы, которым также необходимо нарезать блоки сетей, возможно более оптимальным будет вариант с использованием 10.0.0.0/8 сетей, либо совместного использования 172.16.0.0/12 сетей (например для служебных нужд и серверов) и 10.0.0.0/8 (для пользовательских сетей).
      
      В целом подход к выделению IP-сетей также является модульным и желательно придерживаться правил суммирования подсетей в одну summary-сеть на уровнях распределения, а также на граничных маршрутизаторах в удаленных филиалах. Делается это по нескольким причинам:
      
      
      • для минимизации таблиц маршрутизации на роутерах
      • для минимизации служебного трафика протоколов маршрутизации (всевозможных update сообщениях, при недоступности вложенных подсетей)
      • для упрощения администрирования и лучшей читаемости L3 сетей
      
      Хотя по первым 2-м пунктам стоит заметить, что мощности современных маршрутизаторов гораздо выше, чем те, которые были 15-20 лет назад и позволяют содержать в своей оперативной памяти большие таблицы маршрутизации, да и соотношение цены и пропускной способности каналов связи снизилось по сравнению с ценами времен повального использования потоков E1/T1 (G.703).
      
      

      Заключение

      
      Друзья, в данной статье я попытался насколько возможно коротко рассказать об основных принципах проектирования кампусных сетей. Да, материала получилось довольно много и это при том, что я не затрагивал такие темы как:
      
      
      • организация границы предприятия (а это отдельная история со своими коммутаторами, бордерами, firewall, IPS/IDS системами, DMZ, VPN и прочими штуками)
      • организация Wi-Fi сетей
      • организация VoIP сетей
      • организация ЦОД
      • безопасность (а это тоже свой отдельный мир, который по объему и требованиям не уступает проектированию чистой сетевой инфраструктуры, а порой и превосходит ее)
      • энергетика
      • список можно продолжать и продолжать
      
      На самом деле проектирование и построение сети предприятия довольно кропотливая задача, требующая большого количества времени и ресурсов.
      
      Но надеюсь моя статья поможет вам оценить и на начальном уровне разобраться как подойти к этой задаче.
      
      Это далеко не последняя статья по Extreme Networks, так что следите за обновлениями (Telegram, Facebook, VK, TS Solution Blog)!