В нашей лаборатории всем назначены статические IP-адреса. У нас менее 20 устройств, некоторые физические и некоторые виртуальные на ESXi, от серверов до планшетов Android. Все подключено к сети Ethernet. На коммутаторе 3 VLAN. Наши виртуальные Linux-машины работают нормально, потому что vSwitch, кажется, применяет теги, но для наших физических Linux-машин необходимо изменить интерфейс ifcfg-eth0 на ifcfg-eth0.20, чтобы они могли участвовать в сети. Наш Android-планшет с Ethernet-ключом не может создать эту новую конфигурацию Ethernet для маркировки vlan, как это делает Linux, из-за того, что он не рутирован, и, насколько мне известно, нет инструментов для настройки проводной vlan. (Это Android 4.0.)
Разве коммутатор не должен отвечать за маркировку сетевого трафика на основе подсети машины и портов, к которым он подключен? Почему кажется, что физические машины Windows обрабатывают VLAN без дополнительной настройки, а физическим машинам Linux требуется новая конфигурация интерфейса, чтобы видеть трафик? Разве физический коммутатор не должен делать это так же, как vSwitch делает это для наших виртуальных машин?
Я просто хочу, чтобы устройство Android потребляло сервисы виртуальных машин и компьютеров с Windows, но я не могу даже пинговать их или шлюз, потому что VLAN нельзя настроить вручную на устройстве.
Разве коммутатор не должен отвечать за маркировку сетевого трафика на основе подсети машины и портов, к которым он подключен?
VLAN - это конструкция уровня 2, а IP-адреса - конструкция уровня 3. Нет прямой связи между VLAN и IP-адресом.
Мне кажется, что у вас есть порты коммутатора, настроенные как помеченные порты для вашей VLAN, и вам, вероятно, не следует настраивать их как таковые. Когда порт коммутатора помечен тегом, коммутатор вставляет тег VLAN в кадр, и конечная точка, подключенная к этому порту коммутатора, отвечает за работу с этим тегом VLAN. Обычно теги VLAN не нужны и не нужны, за исключением магистральных портов коммутаторов. Большая часть трафика VLAN проходит через коммутатор без тегов. Коммутатор знает, к какой VLAN принадлежит трафик, и будет перемещать его между портами коммутатора в зависимости от VLAN. Магистральный порт обычно передает трафик более чем для одной VLAN между коммутаторами, и поэтому эти кадры должны быть помечены, чтобы принимающий коммутатор знал, к какой VLAN принадлежит трафик.
Похоже, вы используете VST (Virtual Switch Tagging) на своих ESXi vSwitches, что объясняет, почему ваши виртуальные машины работают. VSwitch обрабатывает теги VLAN.
Я подозреваю, что машины с Windows подключены к собственной VLAN / VLAN по умолчанию, которая не помечена, что объясняет, почему они работают.
Итак, резюмируя свои предположения:
Ваши физические машины Windows работают, потому что они подключены к портам коммутатора в собственной VLAN / VLAN по умолчанию, которая не имеет тегов, и им не требуется тег VLAN в конфигурации их NIC.
Ваши виртуальные машины работают, потому что ESXi vSwitch управляет тегами VLAN.
Другие ваши устройства не работают, потому что они не находятся в собственной VLAN / VLAN по умолчанию, и у вас есть порты VLAN, настроенные как тегированные, а конфигурация NIC этих машин не настроена с соответствующим идентификатором VLAN и поэтому не может справиться с тегированный трафик VLAN.
Вы действительно не должны быть в ситуации, когда вы устанавливаете теги VLAN на реальном клиентском устройстве. Слишком много административных накладных расходов, и он просто не масштабируется.
Вместо этого вы должны установить соответствующие порты коммутатора для устройств, которые будут немаркированными (или собственными) для желаемой VLAN.
VMware является исключением из этого правила, но параллельно можно понять, почему теги не установлены в гостевой ОС, а не в vswitch.