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

Транк может быть Up и нести VLAN 1/20, но не VLAN 10, где живёт 10.0.10.0/24. Смотрите allowed vlan, VTP pruning, native mismatch и то, что порт вообще trunk, а не access после DTP. С клиента это выглядит как «VLAN не работает», но соседний VLAN на том же кабеле жив — ключ именно транк.

Не расширяйте allowed vlan all на все аплинки без нужды: сначала точечно добавьте 10.

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

  • Пользователи VLAN 20 в интернете, VLAN 10 (шлюз 10.0.10.1) — нет;
  • MAC клиента не появляется на ядре в VLAN 10;
  • CDP: native VLAN mismatch.

Отличие от не работает VLAN: там часто неверный access порта. Здесь access правильный, ломается путь между свитчами/гипервизором.

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

  1. switchport trunk allowed vlan 20,30 без 10.
  2. VTP pruning убрал VLAN 10 как «не нужный».
  3. Native 10 на одном конце, 1 на другом.
  4. Порт dynamic auto стал access.
  5. Hyper-V/VMware: trunk ID не включает 10, или VLAN 4095/0 misconfig.
  6. Linux bridge vlan не прописал VID на uplink.
  7. QinQ/внешний тег съел внутренний.
  8. ACL на L3-порту транка (routed port вместо SVI).

Диагностика

1. Доказать, что access-клиент в VLAN 10 живой локально

На access-свитче: MAC в VLAN 10 есть. Ping до локального SVI, если он здесь. Нет SVI на access — ping до 10.0.10.1 зависит от транка.

С клиента:

Get-NetIPConfiguration
ping -n 4 10.0.10.1
Get-NetNeighbor -IPAddress 10.0.10.1

Если ARP нет, а на access-свитче MAC есть — кадры не доходят до шлюза за транком.

2. Оба конца транка

show interfaces trunk
show interfaces GigabitEthernet1/0/1 switchport
show running-config interface GigabitEthernet1/0/1

Ищите: Mode trunk, Native, Vlans allowed, Vlans allowed and active, STP forwarding. Allowed без 10 — ответ.

3. Pruning

show vtp status
show interface trunk | include pruning

Если 10 в allowed, но не в «active» — VLAN не создан на свитче или pruned. Добавление VLAN в базу важнее «ещё один кабель».

4. Гипервизор / Ubuntu

Ubuntu uplink tagged:

bridge vlan show
ip -d link show
sudo tcpdump -n -e -i eth0 'vlan 10'

Нет тега 10 на проводе — хост/мост не маркирует. Есть тег, нет на ядре — allowed/pruning.

5. Native mismatch

Untagged кадры VLAN 10 с одного конца попадают в VLAN 1 на другом: DHCP с чужого scope, «не тот шлюз». Сравните native на обоих концах. См. также DHCP неверный шлюз.

Решение

Сценарий A. Нет в allowed

На обоих концах:

switchport trunk allowed vlan add 10

Не заменяйте список целиком командой allowed vlan 10, если там уже 20,30 — сотрёте их.

Сценарий B. Pruning

Добавьте VLAN 10 в нужные свитчи явно или switchport trunk pruning vlan none только если понимаете эффект. Лучше корректный VTP/без pruning в маленькой сети.

Сценарий C. Это не trunk

switchport mode trunk
switchport nonegotiate

DTP выключить на границах. Не оставляйте dynamic desirable к серверу.

Сценарий D. Linux

# пример, интерфейсы свои
sudo bridge vlan add dev eth0 vid 10
sudo bridge vlan add dev br0 vid 10 pvid untagged

Согласуйте с тем, что ждёт свитч.

Сценарий E. Hypervisor

VLAN ID 10 на port group, NIC физической в trunk. Не ставьте VLAN 10 на VM и на port group одновременно без нужды (двойной тег).

6. Путь транка по узлам, не «ещё один кабель»

Нарисуйте hop: access-свитч → aggregation → ядро, где SVI 10.0.10.1. На каждом транке show interfaces trunk: VLAN 10 в allowed and active, STP forwarding. Allowed на одном конце и забытый на втором даёт одностороннюю картину: MAC локально есть, на ядре нет. Pruning: 10 в allowed, но не active — VLAN не создан на промежуточном. Не лечите это allowed vlan all в сторону DMZ.

С Ubuntu-гипервизора tcpdump -e vlan 10 на uplink. Нет тега — мост/port group. Есть тег, ядро не видит — транк/pruning. Native mismatch проявится как DHCP из чужого scope на untagged. После allowed vlan add 10 не забудьте второй конец и порт-канал: правка только на member, не на Port-channel, часто ничего не меняет. Проверьте, что соседний VLAN 20, который работал, не исчез из списка — типичный эффект команды без add. Клиентская проверка: ARP 10.0.10.1 и ping, плюс MAC в VLAN 10 на ядре. Это закрывает тикет лучше, чем «транк Up».

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

show interfaces trunk — VLAN 10 allowed and active, STP forwarding. MAC клиента виден на ядре в VLAN 10. С клиента:

ping -n 4 10.0.10.1
nslookup contoso.example 10.0.10.2
ping -c 4 10.0.10.1
ip neigh show 10.0.10.1

Соседний VLAN, который работал, не сломан. Снимите tcpdump с тегом 10 на uplink.

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

  • VLAN 10 allowed, SVI на ядре down — вернитесь к статье VLAN/SVI.
  • Фильтр MAC/port-security.
  • MTU jumbo только на транке.
  • Маршрут за SVI есть, NAT нет — уже L3: NAT не для всех.

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

  • Шаблон транка: явный allowed список в git/доке.
  • Одинаковый native, лучше не VLAN пользовательских данных.
  • Чек-лист после добавления VLAN: все транки на пути.
  • LLDP/CDP мониторинг mismatch.

FAQ

Почему VLAN 1 всегда «идёт»?

Часто native untagged. Не делайте рабочие сети native без нужды.

add 10 vs allowed vlan 10,20?

add дополняет. Полный список заменяет. На проде легко снести VLAN голоса.

Нужен ли VLAN на промежуточном свитче, если он только транзитный?

Да, 802.1Q транк пропускает только известные/allowed VID. Свитч должен знать VLAN 10.

LACP: allowed на Port-channel или на членах?

На port-channel. На членах — в канале. Не рассогласовывайте.

Можно ли диагностировать транк только ping с Windows?

Косвенно. Без show trunk вы не отличите pruning от ACL. Имейте доступ к свитчу или зеркало.