Как мы спроектировали и реализовали новую сеть на Huawei в московском офисе, часть 2



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

    В этот раз я расскажу о процессе миграции пользователей (более 1600 человек) со старой сети на новую. Всех заинтересовавшихся приглашаю под кат.

    Итак, существующая сеть компании по состоянию на прошлое лето:

    • простейшая топология «collapsed backbone» — ядро сети (оно же уровень распределения) образовано двумя коммутаторами сетевого уровня, объединёнными в VSS-кластер;
    • уровень доступа представлен коммутаторами и стеками коммутаторов канального уровня, установленными в кроссовых, а иногда и непосредственно в коридорах и даже в рабочих помещениях;
    • часть коммутаторов доступа включена в цепочку, т. е. коммутатор включен в другой коммутатор, а последний — уже в ядро;
    • отказоустойчивость подключения коммутаторов доступа к ядру обеспечивается в основном посредством LACP, иногда — никак не обеспечивается;
    • разграничение доступа — посредством VLAN, маршрутизация VLAN — на ядре;
    • используются коммутаторы доступа трёх производителей и четырёх поколений, подключение пользователей осуществляется на скорости от 100 Мбит/с до 1 Гбит/с;
    • некоторые пользователи всё ещё применяют аналоговые телефоны, некоторые — IP-телефоны, подключенные через PoE-инжекторы, у меньшинства — IP-телефоны, получающие питание по PoE от коммутаторов доступа.

    Задача:

    • привести сеть в приличный вид;
    • не нарушить в ходе модернизации работу сотрудников;
    • исправить максимально возможное количество проблем, накопившихся за предыдущие 15 лет эксплуатации.

    Прежняя жизнь


    Ранее система эксплуатации и расширения сети в офисе была следующей: предположим, что нам необходимо организовать рабочие места для новых сотрудников. В бизнес-центре арендовались дополнительные площади, делался ремонт, прокладывалась СКС, после чего развертывались компьютерная и телефонная сеть.

    На одно рабочее место приходилось, в зависимости от потребностей подразделения, от 2 до 4 розеток RJ-45. Одна из розеток назначалась телефонной (получала зеленую маркировку), остальные (от одной до трёх) назначались компьютерными (получали синюю маркировку).


    Розетки на типовом рабочем месте

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

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

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

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

    Подготовка к миграции


    На первом этапе мы решили заменить все коммутаторы доступа. В качестве стандартной была выбрана модель семейства Huawei S5720, конкретно S5720-52X-PWR-SI-AC. Ее характеристики:

    • подключается к магистрали на скорости 10 Гбит/с;
    • объединяется в стек по обычным интерфейсам 10G;
    • допускает подключение ко всем пользовательским портам на скорости 1 Гбит/с;
    • предоставляет на всех пользовательских портах питание по PoE.

    Таким образом, к любому порту допускается подключение компьютера, IP-телефона, компьютера через IP-телефон, точки беспроводного доступа, камеры видеонаблюдения и других устройств.
    Нам пришлось выяснить, какие розетки в помещениях реально используются и что к ним подключено. У нас были:

    • данные старых и не очень старых проектов прокладки СКС;
    • «не совсем актуальные» кабельные журналы по всем помещениям компании;
    • таблицы MAC-адресов на существующих коммутаторах доступа, которые мы получили с помощью встроенных средств сетевого оборудования;
    • таблицы соответствия MAC-адресов телефонных аппаратов и внутренних номеров абонентов — с телефонной станции.

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

    • помещение;
    • маркировка порта на рабочем месте;
    • маркировка розетки на коммутационной панели в кроссовой;
    • имя (hostname) старого коммутатора (стека);
    • номер порта на старом коммутаторе;
    • VLAN ID;
    • MAC-адрес подключенного устройства (или несколько);
    • тип подключенного устройства (определялся по MAC-адресу);
    • имя (hostname) нового коммутатора (стека);
    • номер порта на новом коммутаторе.


    Результаты работы скрипта

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


    Фрагмент нового кроссового журнала


    Настройки порта доступа

    Таким образом, работы сводились к следующему:

    • отключить старые коммутаторы доступа, удалить патч-корды;
    • установить новые коммутаторы доступа, подключить питание;
    • выполнить коммутации по кроссовому журналу;
    • обойти рабочие помещения, убедиться, что телефоны и компьютеры работают нормально.

    Выглядит просто, но…

    Первый этап — замена коммутаторов доступа: три месяца работы без выходных


    С середины 2018 года мы три месяца каждые выходные заменяли коммутаторы доступа и делали перекоммутацию рабочих мест по нашим таблицам миграций (всего около 3500 портов).
    Первая миграция заняла у нас больше 12 часов, мы успели за это время заменить один стек доступа из пяти коммутаторов и перекоммутировать примерно 200 портов, подключенных к нему.
    Больше всего времени занимала… подготовка патч-кордов. Каждый патч-корд нужно было освободить от упаковки и наклеить с двух сторон бирки с номером. Только после этого патч-корд можно было использовать для коммутации.

    При следующих миграциях мы оптимизировали процесс, и готовили патч-корды заранее. Поэтому последняя миграция заняла те же 12 часов, и мы успели за это время заменить пять стеков доступа, от 3 до 5 коммутаторов в каждом, и перекоммутировать более 1000 портов.

    Что мы получили в итоге?

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

    Во-вторых, рабочие места, подключенные к новым современным коммутаторам доступа. Параллельно мы окончательно избавились от аналоговых телефонов и отдельных блоков питания для IP-телефонов, обновили и унифицировали прошивки в IP-телефонах, чтобы телефон и коммутатор корректно опознавали друг друга по протоколу LLDP. Это необходимо для того, чтобы телефон понимал, в каком VLAN-е ему следует передавать голосовые фреймы, и в каком — фреймы подключенного через телефон оборудования. Таким образом, телефон может обращаться к серверам телефонной станции, а пользователи могут подключать компьютеры на рабочих местах как непосредственно в розетку, так и через телефон.

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

    Таким образом, мы:

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

    Миграция в разгаре — переключение на новую магистраль


    После завершения первого этапа у нас нормализовалась ситуация с пользовательскими подключениями, но с магистралью ничего не поменялось. Как было сказано выше, до модернизации она была устроена достаточно просто. Имелось около 100 VLAN, которые маршрутизировались на центральном коммутаторе, вернее, на двух коммутаторах, объединённых в кластер по технологии VSS.

    Параллельно с первым этапом миграции мы строили и тестировали новую магистраль в соответствии с принципами, изложенными в первой статье:

    • установили коммутаторы ядра Huawei CE8850;
    • установили коммутаторы распределения Huawei CE6870;
    • проложили дополнительные ВОЛС;
    • выполнили все соединения;
    • настроили протоколы маршрутизации overlay и underlay (но пока не завершился первый этап, коммутаторы простаивали и грели воздух).

    Далее начался следующий этап миграции. Не очень длительный, но самый сложный.

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

    Затем мы подключили всю старую сеть к одной паре коммутаторов распределения на правах единого стека доступа. После этого мы приступили к переключению стеков на новую магистраль с изменением номеров VLAN-ов и, соответственно, с изменением IP-адресов подключаемых пользователей на новые диапазоны.

    Мы планировали работы так, чтобы за один раз переключить достаточно большую группу коммутаторов доступа. Работали или ночью, или в выходные, в зависимости от специфики работы переключаемых подразделений.

    Перед началом работ мы заранее выполняли следующие операции:

    1. настраивали корпоративный DHCP-сервер так, чтобы он выдавал для переключаемых пользователей IP-адреса из нового диапазона;
    2. настраивали порты на коммутаторах распределения, в которые планировалось включать коммутаторы доступа при миграции;
    3. с помощью ещё одного специально разработанного скрипта готовили измененные конфигурации для переключаемых коммутаторов.

    Работали в следующем порядке:

    1. переключали коммутаторы доступа со старой магистрали на новую;
    2. убеждались, что коммутаторы доступны по управляющему интерфейсу;
    3. заливали на переключенные коммутаторы заранее подготовленную конфигурацию для изменения номеров VLAN-ов.

    Перед выполнением перечисленных работ VLAN, содержащий управляющие интерфейсы всех коммутаторов доступа, был «растянут» между старой и новой магистралью, поэтому шаг 2 обычно занимал минимум времени. В самом простом случае пользовательские рабочие станции (а также телефоны, принтеры и другие устройства) сразу получали от DHCP-сервера IP-адреса из нового диапазона и продолжали работать без изменений.



    Куда же без проблем?


    На этом пути нам встретилось несколько трудностей.
    Во-первых, у многих пользователей переставали работать принтеры. На рабочих станциях некоторых пользователей доступ к принтерам был настроен по конкретному IP-адресу. После переключения принтеров на новый диапазон они получили и новые адреса, а пользователи потеряли к ним доступ. Для решения проблемы на следующий день после миграции мы на половину рабочего дня выделяли одного специалиста поддержки, чтобы он обошел пользователей, которые подверглись миграции, и перенастроил принтеры на использование не IP-адресов, а DNS-имен.

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

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

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

    В какой-то момент мы обнаружили, что в старой сети не осталось ни одного пользовательского рабочего места! И открыли шампанское. Далее мы приступили к миграции серверного сегмента. К нему применили уже другую схему, поскольку сервер обычно нельзя останавливать даже на 15 минут. Об этом я отдельно расскажу в следующей статье.

    Максим Клочков
    Старший консультант группы сетевого аудита и комплексных проектов
    Центра сетевых решений
    «Инфосистемы Джет»
    Инфосистемы Джет
    392,56
    Системный интегратор
    Поделиться публикацией

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

      +3
      Вы всё это описываете сильно страшнее, чем оно есть в реальности )

      и, нет, у вас сеть не операторского класса, как бы вы этого не хотели. Ни масштабы не дотягивают, ни используемые технологии. Так, средних размеров предприятия — как у небольшого банка, допустим. Но без заморочек с безопасностью.
      Хоть бы 802.1x сделали, чтоб номера vlan-ов в конфиг не писать.
        +3
        Не приживается у нас 802.1x (в проводной сети, в беспроводной — конечно да, но об этом напишем как-нибудь потом).
        Он хорош в том случае, если есть группы пользователей, условно, «Бухгалтерия», «Кадры», «Производство», «Продажи» и т. п., которые надо разнести по разным VLAN и предоставить соответствующий доступ.
        Наша ситуация — есть, условно, «просто пользователи», «инженеры», «телефоны», «видеокамеры», «мультимедиа-оборудование», «другое». Причем группа «другое» — достаточно большая.
        0
        1. Можете показать внешний вид web-приложения кроссового журнала, который у вас получился?
        2. Расскажите подробнее про принцип маркировки патч-панелей, патчкордов. Что взято за идею?
          0
          Сегодня к концу дня постараюсь ответить подробно.
            +1
            1. Приложение выглядит так: youtu.be/TfTFcWdpuQs Не судите строго, я второй раз в жизни делаю видео с экрана. Серым прямоугольником закрыты реальные IP-адреса коммутаторов.
            2. Наша СКС строилась по нескольким проектам в продолжение многих лет, поэтому принципы маркировки могут несколько отличаться. Маркировка на фото 1.633.R2.P03.11 расшифровывается так: 1 — здание, 633 — кроссовая, R2 — второй rack, P03 — третья патч-панель, 11 — одиннадцатая розетка. Что касается патч-кордов — используем самый простой вариант, сквозную нумерацию от 000 до 999 в пределах одной кроссовой. Лучше пока ничего не придумали.
            +2
            Кое что из описанного выше (переход на новые сетевые оборудования) приходится и мне пережить. Спасибо за советы и поделенный опыт.
              0
              обновили и унифицировали прошивки в IP-телефонах, чтобы телефон и коммутатор корректно опознавали друг друга по протоколу LLDP. Это необходимо для того, чтобы телефон понимал, в каком VLAN-е ему следует передавать голосовые фреймы, и в каком — фреймы подключенного через телефон оборудования.


              Не совсем понял. Ну получил телефон по LLDP оборудование и порт в который он воткнут, как он по нему поймет какой у него vlan для голоса а какой для даты?
                0
                По DHCP с помощью опций прилетит. А вот как LLDP помогает — никак не могу вспомнить.
                  0
                  Еще раз. Не понял при чем здесь DHCP опции.
                  Коммутатор и телефон обменялись LLDP, как телефон узнает какой vlan у него для voip какой для data?

                    0
                    по LLDP получит доступ в нативный VLAN, в нем пошлет DHCP-запорс. а DHCP-сервер ему пошлёт:
                    — настройки сетевой карты в VoiceVLAN;
                    — опцию, содержащую IP-адрес АТС для регистрации;
                    — опцию, содержащую номера VoiceVLAN и DataVLAN.

                    Вроде бы так. Если я не прав — надеюсь, коллеги разъяснят.

                    А по поводу необходимости обновления прошивок телефонов тут все просто. Мне попадались китайские поделки, которые не умели VLAN-ы в заводской прошивке.
                      +1
                      Наверное не правы, вероятнее всего речь шла о LLDP-med.
                        0
                        Ух ты, и вправду!
                        Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP-MED) — расширение стандарта LLDP, которое позволяет:

                        Автоматически обнаруживать сетевые политики (VLAN, 802.1p, DSCP),
                        Использовать более расширенное и автоматическое управление питанием на PoE хостах,
                        Отслеживать местоположения устройств и топологию, в том числе таких устройств как IP-телефоны,
                        Выполнять инвентаризацию устройств в сети и определение их характеристик
                        Отслеживать перемещения устройств и отправлять SNMP-сообщения на соответствующий управляющий хост.

                        Спасибо Вам! Узнал кое-что новое.
                          0
                          Судя по команде voice vlan legacy enable, коммутатор еще и по CDP расскажет телефону какой номер voice vlan.
                            0
                            CDP — это больше к Cisco, я не знаю, открыли ли его сейчас, но он всю жизнь был проприетарным. А Huawei с LLDP работает.
                              0
                              sanhces7 Ваше желание показать всем свое невежество в области сетевых технологий поражает.

                              voice-vlan legacy enable command to enable CDP-compatible function so that the switch encapsulates voice VLAN information in CDP packets and sends them to connected IP phones.
                                0
                                спасибо, и Вам здоровьичка. мы немного о разном говорим, просветили бы. ну да ладно, тренируйтесь в оскорблениях. у Вас это чуть лучше получается, чем технические беседы вести.
                  +2
                  LLDP (точнее, расширение LLDP-MED) допускает передачу любой информации через дополнительные поля TLV (type-length-value). Наши коммутаторы и телефоны используют поле 'network-policy'.
                  Про настройки можно здесь почитать: support.huawei.com/enterprise/en/doc/EDOC1000114005/f8e1b7dd/interoperation-between-switches-and-ip-phones-through-lldp-med
                    0
                    красиво
                  0
                  Скажите, а о чем статья? У Вас миграция не на новое оборудование, а просто обновление. Вот я видел миграцию на Huawei:
                  — привозят NE20, ставят вместо того, с чего мигрируют (сами понимаете). Нужно собирать мультильнки из серийных интерфейсов. а они не работают на Huawei, когда с дугой стороны не Huawei. не работают, и всё. трудолюбивые китайцы месяц пилят прошивку — потом начинает работать.
                  — привозят NE08, собирают бриджгруппу. а она не работает. не работает, и всё. трудолюбивые китайцы месяц пилят прошивку — потом начинает работать.
                  — привозят NE08, собирают OSPF. а он то работает, не работает, и всё. трудолюбивые китайцы пока ведут переписку.

                  про абзац с банальным SNMP, отстутствием местами на роутерах DHCP, нестабильной работой NQA — ну о чем Вы, сударь.

                  вот это миграция
                    +1
                    Классика жанра. Сетевой инженер, считаю, не состоялся в профессии, пока по его баг-репорту вендор не выпустил инженерный релиз :)
                    0
                    Новая сеть Huawei без слова шпионская последнее время звучит неестественно.
                      0

                      До последних слов статьи ждал чего-нибудь нового… Нет, все уже давно проверено и в эксплуатации у сотен/тысяч инженеров.

                        0
                        Вы совершенно правы — такая миграция для опытной квалифицированной команды представляет собой обычную задачу.
                        Тем не менее, у наших заказчиков мы постоянно сталкиваемся с сомнениями и опасениями: «У нас нестандартная ситуация, очень сложная сеть, мы не можем провести сегментацию/миграцию/замену вендора/и т. п.» Одна из целей настоящей статьи — рассказать, что такие миграции можно делать, и это занимает конечный объем усилий.
                        0
                        Печально, что компания, которая позиционирует себя как лидера в области информационной безопасности в России, создаёт свою сетевую инфраструктуру на оборудовании компании Huawei, имеющей неоднозначную репутацию в мире в области информационной безопасности
                          0
                          Прочитал, как бы вернулся на пяток лет назад. « Кроссовские журналы « оказывается ещё живы. Это не надолго :)

                          Как только внедрите нормальный NAC, никакой журнал и маркировка кабелей больше не потребуется.

                          Мы отказались от всех журналов. Розетки подключены ВСЕ. Description на Port Interface достаточно. Всю остальную информацию поставляет NAC.

                          Dot1.X в LAN тоже идёт « со скипом «. Хаос у Windows клиентов, Массовый наплыв Apple, постепенный переход на Linux. Все это усложняет.Х. Мы « уходим назад « в MAB & Fingerprint.

                            0
                            Ну вот и мы так жили долгое время (в смысле, со всеми подключенными розетками). Потом посчитали, сколько реально используется. И уменьшили количество коммутаторов доступа со 140 до 100. Это всё же существенная экономия, в том числе по энергопотреблению.

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

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