Мультивендорная сеть это инфраструктура, где уровень доступа, уровень агрегации, ядро, периметр защиты и беспроводной сегмент собраны на оборудовании разных производителей. Складывается она редко по проекту и чаще по факту: слияния компаний, смена ИТ-руководителей, закупки, где побеждает минимальная цена на конкретную позицию. Аргумент в пользу такой схемы звучит разумно: устройства работают по открытым стандартам IEEE и IETF, значит соединятся между собой и будут понимать друг друга.
Стандарт описывает формат кадра и порядок обмена, но не описывает поведение реализации в спорных ситуациях и не обязывает производителя отказываться от расширений, которые он добавил сверху. Расхождения проявляются не на монтаже, а через месяцы эксплуатации, когда сеть уже несёт рабочую нагрузку. Ниже пять ошибок проектирования, из-за которых это происходит, и признак, по которому каждая опознаётся в работающей сети.
Таблица собрана так, чтобы её можно было приложить к своей сети: сначала смотрим на признак, который виден в эксплуатации, и только потом ищем причину в проекте. Перечислены признаки, которые проявляются именно на стыке оборудования разных производителей, а не общие симптомы перегрузки канала.
| Ошибка проектирования | Признак в эксплуатации | Причина | Что делать |
|---|---|---|---|
| Смешение производителей внутри одного слоя коммутации | После включения нового коммутатора часть рабочих портов уходит в блокировку, либо сегмент встаёт от широковещательного шторма | Разные режимы связующего дерева по умолчанию и разное распределение VLAN по экземплярам дерева | Держать слой на одном производителе, а на стыке слоёв фиксировать в проекте режим STP, роль корня и правила обработки BPDU |
| Стык маршрутизации спроектирован без сверки метрик и таймеров | Трафик идёт туда одним путём, обратно другим, часть сессий рвётся при исправных каналах | Разная опорная величина при расчёте стоимости интерфейса OSPF и разные значения таймеров соседства | Назначать стоимость интерфейсов и таймеры явно, проверять путь в обе стороны и согласовывать его с правилами межсетевого экрана |
| Политика доступа описана под возможности одной платформы | 802.1X работает в одном здании и не переносится в другое, часть портов выведена из-под авторизации | Списки доступа и назначение групп политики передаются частными атрибутами RADIUS, набор которых у каждого производителя свой | Свести перечень атрибутов, поддерживаемых каждой моделью из спецификации, и либо опустить политику до общего пересечения, либо унифицировать уровень доступа |
| Централизованное управление заложено в проект, но не проверено на всём парке | Контроллер управляет частью устройств, остальные настраиваются вручную через консоль | Система управления даёт полный набор функций на своей линейке, чужие устройства принимает только как объект мониторинга | До закупки проверять не факт поддержки модели, а перечень доступных по ней операций, либо строить управление на конфигурационных скриптах сразу для всего парка |
| Ответственность за стык не закреплена в договоре | Обращение по плавающей потере пакетов между ядром и периметром неделями ходит между службами поддержки | Производитель отвечает за своё устройство и не обязан разбирать поведение чужого кода, а сторона, которая сводит две реализации, в документах не названа | Назначить одного ответственного за стык, заранее описать состав журналов и дампов, которые снимаются с обеих сторон при разборе |
Четыре ошибки из пяти закладываются на бумаге, до закупки, и стоят дешевле всего на этапе проекта. Пятая закладывается в договоре, и цена у неё выше остальных: пока стороны выясняют, чьё устройство ведёт себя неверно, сеть продолжает работать с потерями. Как распределяется ответственность между интегратором, реселлером и производителем, разобрано в статье про ответственность за упавший ЦОД.
На втором уровне это видно на протоколе связующего дерева. Оборудование Cisco по умолчанию строит отдельное дерево на каждый VLAN в режиме PVST+, значительная часть остальных производителей работает по MSTP, где VLAN распределены по нескольким экземплярам дерева. Соединение двух таких участков без согласования экземпляров и правил обработки BPDU даёт либо блокировку исправного порта, либо незамеченную петлю, которая кладёт сегмент при первом всплеске широковещательного трафика.
На третьем уровне расхождение тоньше. Стоимость интерфейса в OSPF считается через опорную величину пропускной способности, и если у двух производителей она задана по-разному, один и тот же канал получает разную стоимость с двух сторон стыка. Дальше трафик уходит одним маршрутом, а возвращается другим. Для самой маршрутизации это допустимо, для межсетевого экрана с контролем состояния сессий нет: он видит половину сессии и отбрасывает пакеты. Лечится это не подбором настроек по месту, а явным назначением стоимости интерфейсов и таймеров в проектной документации.
Контроль доступа по 802.1X устроен так: коммутатор передаёт запрос на сервер авторизации, сервер проверяет сертификат или учётную запись и возвращает решение вместе с параметрами, которые коммутатор применяет к порту. Номер VLAN передаётся стандартным атрибутом и переносится между платформами без доработок. Всё, что сложнее, идёт частными атрибутами производителя, и вот их набор совпадает редко.
Практический результат такой: загружаемый на порт список доступа, назначение группы политики и перенаправление гостя на портал регистрации работают на том оборудовании, под которое писался профиль, и не работают на соседнем. Проект, где политика доступа описана один раз для всей сети, на разнородном парке не реализуется. Остаются два выхода: свести политику к набору атрибутов, который понимают все модели в парке, либо сделать однородным уровень доступа и оставить разнородность выше по схеме. Что смотреть при подборе моделей для этого слоя, разобрано в материале про коммутаторы Huawei по сериям.
Система централизованного управления это продукт конкретного производителя, и полный набор операций она выполняет на своей линейке. Чужие устройства она либо не видит вовсе, либо принимает как объект наблюдения по SNMP, без настройки политик и без обновления прошивок. Поэтому в проекте проверяют не факт поддержки, а её объём по каждой модели из спецификации: инвентаризация, изменение настроек, обновление микрокода и откат к прежней версии.
С мониторингом граница проходит по глубине данных. Опрос по SNMP даёт состояние порта, загрузку процессора и счётчики ошибок, и это снимается с любого оборудования. Потоковая телеметрия, показатели оптического модуля, задержка и джиттер по конкретному приложению отдаются средствами производителя и в разном формате. Свести их в одну картину можно, но это отдельная работа по нормализации данных, и её объём считают до закупки. Как требования к управлению и мониторингу фиксируются в проекте, показано в статье про HLD и LLD документацию.
Встречный довод к унификации звучит так: сеть на одном производителе это зависимость от него по ценам, срокам поставки и по самой возможности получить оборудование. Довод рабочий, но из него не следует, что смешивать нужно внутри одного слоя. Границу проводят по логическим слоям, а внутри слоя парк остаётся однородным.
Второй довод в пользу однородности внутри слоя виден в эксплуатации, а не в проекте. Подменный фонд считается по каждому производителю отдельно: блоки питания, вентиляторные модули и линейные карты между линейками не переставляются, а часть трансиверов проверяет код производителя в прошивке порта. Пять линеек на уровне доступа означают пять комплектов запаса вместо одного. Что и в каком количестве держать на площадке, разобрано в материале про склад ЗИП в серверной.
Требования к людям меняются так же. Один парк это одна ветка обучения и один набор команд, пять парков это либо редкий инженер по всем сразу, либо несколько узких специалистов. Прежде чем менять архитектуру, состав парка описывают: что стоит в стойках, какие версии прошивок, что уже снято с поддержки производителя. Это задача аудита ИТ-инфраструктуры, без него план перехода строится наугад.
Нет. Однородность нужна внутри логического слоя: ядро, уровень агрегации и уровень доступа. Периметр защиты и беспроводной сегмент допускают отдельного производителя, потому что стык с ними описывается номерами VLAN и маршрутизацией, а не механизмами фабрики, которые у каждого вендора свои.
Можно, если стык спроектирован, а не собран по месту. На нём фиксируют режим связующего дерева и роль корня, согласуют экземпляры дерева и распределение VLAN, задают обработку BPDU. На третьем уровне явно назначают стоимость интерфейсов и таймеры соседства. Опасны не разные производители сами по себе, а несовпадающие умолчания.
Стандартные атрибуты RADIUS вроде номера VLAN переносятся. Динамические списки доступа, группы политики и перенаправление на портал регистрации передаются частными атрибутами производителя, и их набор у каждого свой. Профиль, написанный под одну платформу, на другой применяется частично либо не применяется вовсе.
Начать с описания парка и схемы связей, включая версии прошивок и сроки поддержки. Затем выбрать слой, где смешение мешает больше всего: тот, на котором работают общие механизмы фабрики и политика доступа. Переход делают по слоям, а не всей сетью сразу, привязывая замену к плановому обновлению оборудования, снятого с поддержки.
Главный признак это привязка сбоя к стыку. Проблема воспроизводится на канале между оборудованием разных производителей и не воспроизводится внутри однородного сегмента, а счётчики ошибок и отброшенных кадров растут на портах стыка. Второй признак: настройка, которая на одной стороне описывается одной командой, на другой требует нескольких и ведёт себя иначе.
Меню
Каталог
