Список команд коммутатора полезен только вместе с указанием семейства CLI. У D-Link есть устройства с разными синтаксисами, и строка из инструкции для одного семейства может не работать на другом. Здесь рассматривается классический CLI DGS-3000 Series по руководству Rev B, версия 4.00; перед изменениями сверяйте модель, аппаратную ревизию и firmware своего устройства. Примеры предназначены для существующей инфраструктуры и отдельного тестового порта.
1. Определите модель и сохраните исходное состояние
Запишите маркировку устройства, hardware revision и версию firmware из стартового баннера. Консольные параметры берите из руководства именно своей ревизии: одинаковый разъём не гарантирует одинаковую скорость порта. Используйте локальную консоль или уже настроенный SSH из сети управления. Не открывайте Telnet в пользовательскую сеть ради удобства.
Начните с чтения состояния. Сохраните полный вывод терминала в защищённый файл, отдельно обозначив время и имя устройства. В дампе могут находиться адреса управления и сведения о сети; публично его не размещайте.
show switch
show ports
show vlan
show port_vlan
show fdbЕсли команда не принимается, используйте подсказку ? и CLI Reference Guide DGS-3000 Rev B. Не переводите автоматически классические команды в синтаксис interface другого семейства.
Дополните исходный снимок состоянием управления и журналом:
show ipif
show logСверьте VLAN интерфейса System и порт, через который приходит управление. Если управляетесь через тот же порт, который собираетесь переносить, сначала подключите независимую консоль. Пример диагностической ситуации: физический LinkUp, MAC тестового ПК появляется в VLAN 1, а ожидается VLAN 120. Это указывает прежде всего на PVID/членство, а не на необходимость сменить IP коммутатора.
2. Отличайте административное состояние от физического линка
Для выбранного порта проверьте одновременно наличие линка, согласованную скорость и duplex. Порт может быть административно включён, но физически не иметь соединения. Обратная ситуация тоже возможна: подключённый кабель не помогает, если порт выключен конфигурацией.
show ports 1
show ports 1 detailsЕсли вместо ожидаемого гигабита согласовалось 100 Мбит/с, проверьте все пары кабеля, патч-панель, сетевую карту и настройки второй стороны. Принудительная установка скорости на одном конце при автоматическом согласовании на другом может ухудшить ситуацию. Сначала замените короткий патч-корд заведомо исправным и сравните результат; затем исследуйте постоянную линию. Для оптического соединения дополнительно проверьте совместимость модулей и параметры оптики, доступные в конкретной модели.
3. Ищите устройство по MAC в нужном VLAN
MAC-таблица отвечает на вопрос, через какой порт коммутатор недавно видел источник Ethernet-кадров. Она не показывает полный список IP-адресов и не доказывает, что устройство сейчас включено.
show fdbНайдите нужный MAC в выводе и запишите VLAN, порт и тип записи. Один MAC может появиться в разных VLAN, а динамическая запись может исчезнуть после периода старения. Если адрес найден на uplink, продолжайте поиск на следующем коммутаторе. Это нормальный путь через несколько устройств, а не признак неисправности.
Сравните MAC из таблицы с сетевой картой, записью DHCP или инвентаризацией. У виртуальных машин, телефонов с проходным портом и Wi-Fi точек за одним интерфейсом закономерно видны несколько адресов. Резкое перемещение одного MAC между несвязанными портами требует проверки петли, дублирования MAC и схемы резервирования.
4. Подготовьте тестовый сценарий VLAN
Предположим, порт 1 подключён к тестовому компьютеру, а порт 8 — к заранее согласованному uplink. Новый VLAN 120 называется OFFICE120; на другой стороне uplink этот VLAN уже разрешён. Сеть управления и рабочие uplink-порты в примере не переносятся. Номера портов и VLAN условные: сначала убедитесь, что они свободны и соответствуют топологии.
Нужно проверить три независимые вещи: членство порта в VLAN, наличие тега на выходе и PVID для входящего нетегированного трафика. Настройка только одного из этих параметров часто создаёт одностороннюю связность. Отдельно выясните поведение автоматического назначения PVID на своей прошивке: не меняйте глобальную настройку на работающем устройстве ради одного примера.
5. Создайте VLAN и проверьте членство
Следующий фрагмент изменяет конфигурацию. Выполняйте его только на подготовленном тестовом стенде или в согласованном окне, имея резервный путь управления.
create vlan OFFICE120 tag 120
config vlan OFFICE120 add untagged 1
config vlan OFFICE120 add tagged 8
config port_vlan 1 pvid 120
show vlan OFFICE120
show port_vlan 1Проверьте, не остался ли порт 1 нетегированным участником прежнего пользовательского VLAN. Если стенд действительно требует удаления из VLAN default, сначала подтвердите его фактическое имя и исходное членство, затем примените config vlan default delete 1. Не выполняйте это на порту управления или рабочем uplink. На практике VLAN может называться иначе, а удаление может автоматически повлиять на PVID: результат всегда читайте заново.
6. Проверьте путь от компьютера до шлюза
На тестовом компьютере получите адрес из нужной подсети или назначьте согласованный статический адрес. Проверьте шлюз, DNS и доступ к разрешённому сервису. Затем проверьте путь через uplink и наличие ответного трафика. Коммутатор второго уровня не создаёт DHCP-сервер и не начинает маршрутизировать новый VLAN автоматически.
Если локальная связность есть, а шлюз недоступен, проверьте tagged VLAN на обеих сторонах межкоммутаторного соединения. Если DHCP не работает, сравните успешность ARP и доступность статического шлюза: так можно отделить проблему VLAN от DHCP relay, snooping или серверного фильтра. Не добавляйте разрешение «всё всем» на межсетевом экране только ради быстрого положительного ping.
На тестовом Linux-компьютере выполните конкретную проверку. enp1s0 и шлюз 10.120.0.1 замените своими:
ip -br address show dev enp1s0
ip route get 10.120.0.1
ping -c 3 10.120.0.1
ip neigh show dev enp1s0
sudo tcpdump -ni enp1s0 -e -c 30 'arp or (udp port 67 or 68)'INCOMPLETE у шлюза означает, что ARP-разрешение не завершилось: проверяйте L2/VLAN и наличие шлюза. Наличие ARP-ответа при неудачном ping требует проверки IP-правил, потому что ICMP может быть запрещён. В DHCP-трассе наличие Discover без Offer отличается от полного отсутствия Discover. На обычном access-порту клиент получает нетегированные кадры; отсутствие 802.1Q-тега там ожидаемо. Проверка тега на uplink требует согласованного mirror/TAP, а не захвата на произвольном клиенте.
7. Сравните счётчики ошибок в динамике
Один накопленный CRC за месяцы работы отличается от десятков ошибок в секунду. Снимите значения, подождите фиксированный интервал при похожей нагрузке и снимите повторно. До записи исходных значений счётчики не очищайте.
show error ports 1
show utilizationВ руководстве есть несогласованность заголовка и строки формата для команды ошибок; пример использует show error ports. Если конкретная прошивка принимает другую форму, следуйте её подсказке. Рост CRC и symbol errors прежде всего заставляет проверять физическую линию; drops при чистой физике — очереди, скорость выхода, перегрузку и политику обработки. Предел интерфейса оценивайте по обоим направлениям и пикам, а не по среднему графику за сутки.
Запишите количество CRC и drops в моменты T0 и T1 через 60 секунд. Пример: 12 → 72 CRC означает 60 новых ошибок за минуту, а не «72 ошибки сейчас». Одновременно проверьте negotiated speed: одинаковое количество drops на 100 Мбит/с и 1 Гбит/с может иметь разные причины. При росте CRC заменяйте по одному элементу линии, сохраняя результаты каждого шага. Если ошибки исчезают только после замены одного патч-корда, это проверяемое основание заменить его, а не массово менять настройки всех портов.
8. Разберите петлю без массового выключения защиты
Признаки петли: скачущие MAC, широковещательный шторм, высокая загрузка процессора, нестабильность нескольких VLAN и массовые потери. Начните с карты соединений и недавних изменений: куда подключили новый кабель, точку доступа или небольшой неуправляемый коммутатор.
Проверьте состояние STP и защитных функций командами из руководства вашей модели. Не выключайте STP, loop detection или storm control одновременно, иначе причина исчезнет из диагностики, а последствия могут усилиться. Изолируйте только подтверждённый проблемный пользовательский порт, сохранив uplink и управление. После устранения физической петли проверьте стабилизацию MAC-таблицы, загрузки и счётчиков.
9. Сохраните только проверенный результат
На классическом CLI изменения могут действовать в оперативной конфигурации до записи в энергонезависимую память. Сохранение выполняйте после проверки управления и пользовательского трафика.
save configУспешная запись не равна успешной резервной копии. Отдельно выгрузите конфигурацию штатным способом, поддерживаемым вашей прошивкой, и проверьте, что файл получен и не пуст. Если доступен только TFTP, используйте изолированный сегмент управления и ограниченное окно: у TFTP нет защиты конфиденциальности. Имя и порядок параметров передачи зависят от версии CLI, поэтому их нужно брать из раздела TFTP/FTP своего руководства.
Для этой версии классического CLI пример выгрузки на временно разрешённый TFTP-сервер 10.99.0.20 выглядит так:
upload cfg_toTFTP 10.99.0.20 dest_file dgs3000-after.cfgПодготовьте writable-каталог на сервере и ограничьте обмен сетью управления. После ответа Success на принимающем узле проверьте файл:
ls -lh /srv/tftp/dgs3000-after.cfg
sha256sum /srv/tftp/dgs3000-after.cfgИсходную копию выгружайте до изменений под другим именем. Upload в этой команде означает передачу с коммутатора на сервер. Сохранение в flash и выгрузка — отдельные операции; полученный файл держите закрытым, так как он может содержать сведения и секреты конфигурации.
10. Подготовьте возврат и журнал изменений
До изменений запишите прежние PVID и членство затрагиваемых портов. Возврат состоит из восстановления именно этих параметров, проверки линка и трафика, а затем сохранения восстановленной конфигурации. Перезагрузка помогает только если сохранённая конфигурация заведомо правильная; без этого она может закрепить ошибку или прервать работу всей сети.
В журнале укажите модель, ревизию, firmware, время, затронутые порты, VLAN, команды, исходные и конечные показания, место хранения резервной копии. Приёмка включает доступ из сети управления, работу тестового компьютера, правильный VLAN на uplink и отсутствие роста ошибок. Для администраторов такой журнал полезнее универсального списка из сотни команд: он позволяет повторить конкретное действие и безопасно вернуться к исходному состоянию.
Связанные инструкции: справочник CLI популярных коммутаторов, настройка Cisco L2.
Пример возврата именно лабораторного VLAN. Он применим только если до эксперимента порт 1 был untagged в default с PVID 1, порт 8 не состоял в OFFICE120, а VLAN создан только для теста:
config vlan OFFICE120 delete 1
config vlan default add untagged 1
config port_vlan 1 pvid 1
config vlan OFFICE120 delete 8
show port_vlan 1
show vlan default
delete vlan OFFICE120
save configЕсли исходное состояние другое, используйте записанные PVID и членство. Перед удалением VLAN убедитесь, что он не используется иными портами или интерфейсами. После возврата подтвердите прежний DHCP/шлюз тестового компьютера и доступ управления. Не делайте restart заменой этих проверок.