Разработчик зачем-то админит гостиницу. Серия 2: меняем корневые свитчи и стараемся ничего не сломать

07.09.2026

В какой-то момент я решил, что прежде чем добавлять отдельный VLAN для гостевого Wi-Fi, неплохо бы сначала привести в порядок само ядро сети. На тот момент оно состояло из нескольких D-Link разных поколений, старого HPE 1910-24 и Zyxel GS1900-24HP. Часть оборудования выполняла понятную работу. Часть, судя по всему, просто исторически оказалась между двумя другими свитчами и продолжала жить там по принципу: "работает — не трогай."

Из оборудования для замены у меня были:

  • доставшийся по наследствую обесточенный Eltex MES2428P
  • 2 новых Eltex MES2424P

План был таков: Zyxel заменить на Eltex MES2428P из серверной, два корневых D-Link заменить на новые Eltex MES2424P, часть старой цепочки убрать совсем, а клиентские линии со старого HPE перенести на Zyxel GS1900-24HP(этот у меня уже был).

Казалось бы: сохранил конфиги -> переставил кабели -> готово. Разумеется, нет.

Для начала выяснилось, что сначала нужно понять, куда вообще ведут все эти кабели. Подписи на портах местами устарели, часть устройств не имела нормальных имён, а некоторые соединения существовали только в старых схемах и уже давно не соответствовали реальности. Поэтому перед заменой я собирал сеть обратно по кусочкам:

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

Постепенно появилась таблица:

старый порт -> реальное устройство -> VLAN -> новый порт.

Причём кабель в выключенном порту нельзя было автоматически считать ненужным. Но и переносить его вслепую тоже нельзя.

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

Сами Eltex MES2424P сначала настраивал отдельно от production-сети. Hostname, LLDP, RSTP, приоритеты root bridge, access-порты, tagged и untagged VLAN, PVID, ingress filtering.

На словах всё это звучит вполне последовательно(ну, когда знаешь все эти аббревиатуры).

На практике даже подключение к консоли оказалось отдельным квестом: FTDI-адаптер, 115200 8N1, screen на macOS — и некоторое количество вопросительных знаков вместо нормального приглашения командной строки. В конечном итоге я пользовался утилитой dhcpmasque на маке, чтобы имитировать dhcp сервер при подключении к свитчу и выдавать нужный мне айпишник этому свитчу по его MAC-адресу. Адрес я узнавал по DHCPREQUEST от свитча, во время его startup, отлавливая через tcpdump. Хоть в доке Eltex и указано, что с завода свитчи настроены на статический адрес - это было не так, они ждали DHCPACK поэтому пришлось выкручиваться.

Очень обнадёживающее начало миграции.

Management-адреса новых свитчей я не прописывал статически. Для них подготовил DHCP reservations, чтобы после отключения старого устройства новый свитч мог занять его прежний адрес.

Сам перенос делался поэтапно.

  1. Сначала основной uplink.
  2. Потом проверка management-доступа, LLDP и связности.
  3. И только после этого — остальные линии.

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

Что-то, конечно же, пошло не так.

После переноса одного из внешних каналов начал пропадать интернет. Оказалось, со стороны провайдера приходят BPDU - STP пакеты необходимые сетевому оборудованию для понимания кто здесь главный. Новый Eltex честно обрабатывает их через RSTP и в какой-то момент блокирует порт, т.к. считает себя "root"-свитчем, то есть главным. А по правилам Spanning Tree Protocol главным может быть только один свитч(«There can be only one!»).

Я забыл, что на старом D-Link включал блокировку BPDU на порту от провайдера 🙈 Повторил эту магию на Eltex, и uplink не заставил себя долго ждать. На внутренних соединениях RSTP остался работать как раньше, чтобы не допустить случайных сетевых колец.

Потом обнаружился ещё один сюрприз. Кабель, ведущий к одному из access switch'ей(Unifi US8), нормально работал через старый HPE, но вообще не хотел поднимать link при прямом подключении к новому Eltex или Zyxel. Можно было долго объяснять это особенностями совместимости оборудования. Но тот факт, что соединение через HPE поднималось только на 100 Мбит/с, довольно прозрачно намекал на физическую линию: обжим, патч-панель или неполный набор пар. Ни обжимки, ни кросс-ножа, ни ethernet-тестера у меня с собой не было, поэтому старый HPE пришлось временно оставить в сети. Практически всё остальное с него уже переехало, но сам свитч продолжил работать как довольно большой и энергоёмкий переходник между одним кабелем и UniFi. В итоге корневые D-Link были заменены на Eltex MES2424P, клиентские линии переехали на Zyxel GS1900-24HP, лишний транзитный свитч исчез, а между основными узлами осталась нормальная оптика.

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

С реальными портами, VLAN, uplink’ами, исключениями и понятным rollback. После этого можно переходить к следующей непростой задаче: вынести гостевой Wi-Fi в отдельный VLAN. Не переключайтесь.

На фото:

  1. Текущая обезличенная карта сети. На ней уже нет старого HPE, т.к. с кабелем я разобрался. На нём были перепутаны пары. 🤷‍♂️
  2. Тот свитч, что достался мне в наследство. Его я настраивал первым.