Ну, на всякий случай, если кто-то считал... Это был бракованный коммутатор, к сожалению. Я пошёл в магазин и купил совершенно новый. После установки нового оборудования коммутатор теперь настроен и передаёт трафик нормально. Одна вещь, которую я заметил, но не понял сразу (так как люди на YouTube-видео упоминали что-то об этом, но не очень конкретно), заключается в том, что Ubiquity не делает лёгким подключение к другим не-Unify устройствам. Действительно нужно понимать, что ты делаешь. Например, чтобы управлять коммутаторами Unify и чтобы они работали правильно, похоже, просто необходимо отлично знать концепцию native VLAN. Если ты этого не понимаешь, Ubiquity — это, возможно, не для тебя. Надеюсь, мой сценарий в качестве примера поможет другим это лучше понять. Оба моих ESXi-сервера тегируют фреймы на выходе с VLAN-значениями — то есть, когда трафик выходит из ESXi в другие направления, фреймы тегируются VLAN 10 (на уровне NIC сервера). Здесь я нашёл первое ограничение (?), когда попытался настроить USW Pro Max 24 port, к которому подключён ESXi, как "access port" (используя терминологию Cisco). Моя первая реакция была настроить порт 1 как VLAN 10 (Secure Network) как показано на одном из предоставленных выше изображений. Это, то есть, настроить порт как Native VLAN 10 (Secure VLAN), что означает, что UNTAGGED фреймы будут передаваться с VLAN-значением 10 как следствие. Не имело значения, выбирал ли я allow all или block all или custom setting, даже устройства в той же сети/vlan, напрямую подключённые к коммутатору, просто не могли общаться. Основываясь на моем понимании, trunk порты являются "untagged" портами по умолчанию, и они будут добавлять тег к фреймам, проходящим через них, чтобы устройство на другом конце знало, какой vlan должен получить фрейм на выходе. Это означает, что если нет access порта, тегирующего трафик, фрейм нужно как-то тегировать на trunk-линке, и для этого используется native vlan.

Что я должен был увидеть, это то, что ПЕРЕДАЮЩИЙ коммутатор должен удалять VLAN-тег перед прохождением по trunk-линку, если тег соответствует Native VLAN. Получающий коммутатор (в данном случае тот же коммутатор) должен знать, где перенаправить трафик, используя native vlan, всё ещё позволяя L2 и L3 трафик.

Что в итоге позволило трафику снова передаваться, так это откат Native VLAN для порта обратно к Default (Management в моем случае — VLAN 1) и разрешение только VLAN 10 в настройках custom. Я недавно понял, что теперь также доступна опция "None" для настройки native vlan. Это, наконец, заставит порт вести себя как access?

Привет, Трэвис, спасибо за ответ. Думаю, диапазон не отображается, потому что это не сеть DHCP. Я выбрал 10.10.1.254 в качестве шлюза, потому что это адрес текущего шлюза, с которого я перехожу, и поскольку сервер ESXI уже имеет назначенный IP-адрес 10.10.0.1. Попробую переназначить IP-адрес сервера и посмотреть, что получится. Нашел несколько постов в сети, где тоже писали, что такое может произойти в зависимости от версии ОС. Также проверю, какая версия ОС установлена, и обновлю ее, если это возможно (хотя, кажется, она сама обновилась сразу после принятия). Еще стоит упомянуть, что я купил его как восстановленный (open box), поэтому думаю, что это может быть и проблема с оборудованием. Если за пару дней не найду подходящее решение, верну его и возьму другой.