Короткий ответ

Если у ПК линк Up, а в 10.0.10.0/24 нет ни ARP до 10.0.10.1, ни DHCP — чаще не «сломан IP», а L2: порт не в том VLAN, транк не пропускает тег, native VLAN не совпал, SVI шлюза down. Сверьте один порт клиента, транк до ядра и SVI. Не меняйте адресный план, пока не доказали тег.

Windows/Ubuntu не показывают номер VLAN на обычном access: истина на коммутаторе и на tagged-интерфейсе сервера.

Симптомы и как отличить

  • APIPA или статика 10.0.10.10 без ARP шлюза;
  • сосед в том же кабинете в другом порту работает;
  • tcpdump на шлюзе не видит кадры клиента.

Отличия:

Возможные причины

  1. Access порт в VLAN 20, SVI 10.0.10.1 в VLAN 10.
  2. Клиент должен быть tagged (сервер/VM), порт access untagged.
  3. Native VLAN на транке 1 vs 10 — untagged кадры не туда.
  4. SVI Vlan10 administratively down, нет ip address 10.0.10.1/24.
  5. VLAN не создан на этом свитче (не в VTP/не в allowed).
  6. Private VLAN / isolated порт.
  7. Гипервизор: port group VLAN 0 vs 10.
  8. Linux bridge без vlan_filtering.

Диагностика

1. Клиент: есть ли L3 в 10.0.10.0/24

Get-NetIPConfiguration
arp -a 10.0.10.1
Get-NetNeighbor -IPAddress 10.0.10.1
ping -n 2 10.0.10.1
ip -br addr
ip neigh show 10.0.10.1
ping -c 2 10.0.10.1

incomplete до 10.0.10.1 при статике — нет L2 до шлюза. DHCP APIPA — Discover не доходит до сервера в этом VLAN.

2. Порт access

На коммутаторе (пример IOS):

show vlan brief
show interfaces GigabitEthernet0/12 switchport
show mac address-table interface GigabitEthernet0/12

Access Mode VLAN: 10 и MAC клиента на этом порту. Если MAC нет — кадры не входят (кабель, isolated, гипервизор).

3. SVI и шлюз

show ip interface brief | include Vlan10
show running-config interface Vlan10

Ubuntu как L3:

ip -br addr show
ip link show type vlan
bridge vlan show

Должен быть адрес 10.0.10.1/24 на SVI/vlan-интерфейсе, состояние UP.

4. Native и теги на сервере

Если Ubuntu должна сидеть в VLAN 10 tagged:

ip link show eth0.10
sudo tcpdump -n -i eth0 -e vlan

На access-порту тегированный кадр часто отбрасывается. Либо порт trunk allowed 10, либо снимите тег с хоста.

5. DHCP helper

Discover из VLAN 10 должен идти на сервер 10.0.10.2 (если DHCP там) или через helper на SVI. Helper на чужом SVI не обслужит этот VLAN.

Решение

Сценарий A. Неверный access VLAN

Поставьте порт в VLAN 10 (где 10.0.10.0/24). Не создавайте второй SVI «чтобы заработало» с тем же 10.0.10.1.

Сценарий B. Хост tagged, порт access

Либо switchport mode trunk + allowed VLAN 10, либо уберите VLAN с NIC. Для пользовательского ПК почти всегда untagged access.

Сценарий C. SVI down

Поднимите VLAN и SVI, проверьте, что VLAN существует в базе свитча. IP 10.0.10.1/24 только на одном L3-интерфейсе сегмента.

Сценарий D. Гипервизор

Port group VLAN ID = 10, NIC VM без своего 802.1Q (если тег на хосте). Двойной тег = тишина.

Сценарий E. Linux bridge

Включите vlan_filtering, пропишите VID на портах. Без filtering bridge склеивает VLAN и вы получите конфликт между сетями.

6. Практическая сверка тега без догадок

Пока не доказан VID, не меняйте IP-план 10.0.10.0/24. С клиента со статикой 10.0.10.10/24 (временно, адрес свободен по ARP) смотрите только ARP к 10.0.10.1. Нет MAC — кадры не доходят до SVI, это L2. Есть MAC, нет ping — уже ICMP/ACL на SVI, VLAN как сегмент жив. На Ubuntu-сервере с tagged eth0.10 tcpdump -e должен показать vlan 10; на access-порту тег не появляется на проводе в сторону ПК.

Сверьте три точки одним номером VLAN: access порта, allowed на транке, SVI. Расхождение любой одной точки даёт «VLAN не работает». Гипервизор: port group 10 и гостевой 802.1Q одновременно — двойной тег, с ПК в access это выглядит как мёртвый сегмент. Linux bridge без vlan_filtering склеит VLAN 10 и 20: получите ARP от чужой подсети и ложные конфликты. Не «почините» это вторым IP на NIC. После исправления верните DHCP, уберите временную статику, проверьте lease scope именно 10.0.10.0.

Как проверить, что проблема устранена

Клиент: адрес 10.0.10.x/24, Get-NetNeighbor 10.0.10.1 = MAC шлюза, ping 10.0.10.1 и nslookup через 10.0.10.2. На свитче MAC клиента в VLAN 10. С другого порта того же VLAN — взаимный ping. DHCP lease на верный scope.

ipconfig /all
ping -n 4 10.0.10.1
nslookup contoso.example 10.0.10.2

Если не помогло

  • ACL на SVI режет ICMP/UDP67 — VLAN «живой» для ARP, сервисы нет.
  • VXLAN/overlay: mapping VNI не тот.
  • Одинаковый IP план в двух VLAN без маршрута — «VLAN не работает» на самом деле нет маршрута.
  • Голосовой VLAN: телефон тегирует, ПК untagged — смотрите voice VLAN отдельно.

Профилактика

  • Документ: VLAN ID ↔ подсеть ↔ SVI.
  • Access к пользователям, trunk только между свитчами/гипервизорами.
  • Native VLAN не использовать для пользовательских данных (или явно документировать).
  • Проверка allowed VLAN после каждого изменения транка.

FAQ

ПК не понимает VLAN. Нужен ли драйвер 802.1Q?

Для обычного access — нет. Тег ставит свитч. Tagged нужен серверам с несколькими VLAN на одном NIC.

Можно ли держать SVI 10.0.10.1 на двух свитчах?

Только как VRRP/HSRP с одним VIP. Два независимых SVI с одним IP — конфликт.

Почему Wi‑Fi не видит VLAN 10, кабель видит?

SSID привязан к другому VLAN. Это не «сломанный кабель».

show vlan не содержит 10, а порт access 10. Что будет?

Часто кадры drop. Создайте VLAN на свитче/в VTP по вашей модели.

Нужно ли для диагностики отключать firewall на клиенте?

Нет. ARP/ping до шлюза не требуют выключения Windows Firewall. Если ICMP запрещён политикой — используйте ARP-таблицу и DHCP.