L2 VLAN, 802.1Q, STP

Один коммутатор — это одна общая L2-сеть, где все слышат друг друга. Это плохо для безопасности (бухгалтерия видит broadcast серверов), плохо для производительности (один большой broadcast-домен), плохо для проектирования. Решается это VLAN'ами.

Когда в сети появляется резервирование (две связки между свитчами на случай обрыва), возникает другой подвох — петля L2, которая за секунды кладёт всю сеть. Лечится STP/RSTP.

Заявка из очереди

«Инцидент. 9:05 утра, офис на 400 человек: сеть лежит ВСЯ — ни телефония, ни интернет, ни принтеры. На этажных коммутаторах все индикаторы мигают как гирлянда, CPU 99%, в консоль не зайти. В 8:50 сотрудник подключил принесённый из дома „маленький свитчик на 5 портов“, чтобы воткнуть ноутбук и телефон одновременно». Это широковещательный шторм — самая зрелищная авария L2: один кадр, попавший в петлю, размножается миллионы раз в секунду, потому что у Ethernet-кадра нет TTL. Почему пятипортовый свитчик убил сеть на 400 человек, как за 3 минуты найти петлю и какие две команды на каждом access-порту сделали бы аварию невозможной — весь этот урок.

Что узнаешь — после урока ты сможешь
Вспомни из модуля 2

Broadcast-домен — область, где широковещательный кадр слышат все; коммутаторы его не ограничивают, только расширяют. CAM-таблица учится по src MAC и решает по dst MAC; неизвестный unicast — флудится во все порты. MAC-flapping — когда один MAC скачет между портами. Сегодня всё это сложится в картину: VLAN режет broadcast-домены, а петля превращает флудинг в шторм — и flapping в логах будет первым свидетелем.

1. Что такое VLAN — и зачем

VLAN (Virtual LAN) — это способ логически разделить один физический коммутатор на несколько независимых сетей. Хосты в разных VLAN не слышат друг друга на L2, даже если воткнуты в один и тот же свитч.

Физическая топология vs логическая (с VLAN)
Физическая топология один свитч, 6 портов SWITCH 24p 24× GigE, 4× SFP+ PC-1 PC-2 SRV-1 SRV-2 VoIP-1 VoIP-2 Проблема: один broadcast-домен broadcast от PC-1 слышат все 5 остальных хостов VoIP-приоритет не сделать бухгалтерию не отделить от dev-окружения Логическая (с VLAN) тот же свитч, три VLAN SWITCH 24p 3 VLAN сконфигурированы VLAN 10 · USERS VLAN 20 · SERVERS VLAN 30 · VOICE PC-1 PC-2 SRV-1 SRV-2 VoIP-1 VoIP-2 Три изолированных broadcast-домена PC-1 не слышит SRV-1 на L2 VoIP отдельная сеть, можно QoS Сегментация + безопасность даром
Один и тот же физический коммутатор — но «как будто три разных свитча» с точки зрения хостов.

Зачем нужны VLAN — реальные причины

2. Формат тега 802.1Q

Когда кадр идёт между свитчами по trunk-порту, ему нужно нести информацию: «я из VLAN 10». Это делается через тег 802.1Q — 4 байта, вставляемые в Ethernet-кадр.

Кадр Ethernet с тегом 802.1Q
Untagged (обычный кадр) Dst MAC Src MAC EtherType 0x0800 Payload (IP-пакет) FCS Tagged (с 802.1Q) — добавляется 4 байта между Src MAC и EtherType Dst MAC Src MAC 802.1Q tag TPID (2B) TCI (2B) EtherType 0x0800 Payload FCS Тег раскладываем по битам — 32 бита всего TPID 0x8100 Tag Protocol ID 16 бит, всегда 0x8100 PCP 3 бита Priority QoS, 0-7 DEI 1 бит Drop eligible VID — VLAN ID 12 бит = 0..4095 собственно номер VLAN VID=0/4095 reserved
Тег 802.1Q добавляет 4 байта overhead. Максимальный размер фрейма становится 1522 байт (или 9022 для jumbo).

Reserved VLAN IDs

VIDНазначение
0Priority-only tag (есть PCP, но нет принадлежности к VLAN)
1Default VLAN на большинстве коммутаторов (Cisco). НЕ используется в production.
2-1001Стандартный диапазон, доступен везде.
1002-1005Зарезервированы Cisco для legacy (Token Ring, FDDI). Не использовать.
1006-4094Расширенный диапазон, доступен на современных свитчах.
4095Reserved (служебный).

3. Access vs Trunk порты

Порт коммутатора может работать в одном из двух режимов:

Access port vs Trunk port
Access port «один порт = один VLAN» PC обычный хост access SWITCH interface gi0/1 → VLAN 10 Хост шлёт untagged → свитч внутри помечает VLAN 10 При выходе на access — тег снимается Trunk port «несёт несколько VLAN сразу, с тегами» SWITCH-A VLAN 10, 20, 30 SWITCH-B VLAN 10, 20, 30 TRUNK [VLAN10] frame from PC-1 → SRV-A [VLAN20] frame from PC-3 → DB [VLAN30] frame from VoIP phone Trunk несёт все VLAN с тегами в одном кадре. Свитч на другом конце видит тег и роутит куда надо.
Access — между свитчем и хостом. Trunk — между свитчами или между свитчем и роутером/гипервизором.

Native VLAN — нюанс trunk-порта

На trunk-порту один из VLAN объявляется native — его кадры идут без тега. По умолчанию native = VLAN 1.

безопасность VLAN hopping атака. Если native VLAN на trunk = 1, и обычный access-порт стоит в VLAN 1 — атакующий может отправить кадр с двумя 802.1Q тегами подряд (double-tagging). Первый тег снимется на первом свитче, второй пройдёт дальше → попал в другой VLAN, минуя файрвол. Защиты: 1) native = неиспользуемый VLAN (например 999), 2) на каждом trunk явно прописать switchport trunk native vlan tag.

4. Inter-VLAN routing — как VLAN общаются между собой

L2-коммутатор внутри VLAN'а — это L2. А чтобы пакет ушёл из VLAN 10 в VLAN 20, нужен L3. Между разными VLAN — всегда маршрутизация.

Три способа inter-VLAN routing
1. Router-on-a-stick (старая школа) L2 SWITCH TRUNK ROUTER subinterfaces VLAN 10 VLAN 20 VLAN 30 VLAN 10 Минусы: bottleneck на одном trunk-линке, «hairpin» — пакет туда-сюда. Дёшево, но не для DC. Используется в малых офисах 2. L3-switch с SVI (современный стандарт) L3 SWITCH SVI: vlan10 = 10.10.0.1/24 SVI: vlan20 = 10.20.0.1/24 VLAN 10 VLAN 20 VLAN 30 VLAN 10 SVI = Switch Virtual Interface. L3-свитч имеет per-VLAN виртуальный gateway. Wire-speed routing, никакого hairpin 3. Routed access / spine-leaf (современный ДЦ) SPINE SPINE LEAF-1 LEAF-2 LEAF-3 LEAF-4 VLAN терминируется на leaf (или вообще нет VLAN, всё L3 + VXLAN)
Современный ДЦ — это spine-leaf с routing на каждом leaf. VLAN живёт только в пределах одного rack.

5. STP — зачем нужен и что без него

Представь сеть с резервированием — два uplink'а между свитчами на случай обрыва одного. Это правильно с точки зрения надёжности. Но без специальной защиты — это смерть сети.

Без STP: broadcast-storm — почему сеть умирает за секунды
① Топология: три свитча в кольце. Резервирование — это хорошо… SW-A SW-B SW-C PC ② PC шлёт broadcast (например ARP). Что происходит? SW-A SW-B SW-C PC BCAST ×N BCAST ×N BCAST ×N BROADCAST STORM Каждый свитч получает broadcast, флудит на все порты, включая uplink. Соседний получает — флудит обратно. Кадры размножаются экспоненциально. В Ethernet НЕТ TTL! Кадры летают вечно — CPU свитчей 100%, сеть мёртвая за 10-30 секунд.
В IP есть TTL (счётчик хопов). В Ethernet — нет. Loop в L2 = катастрофа. Поэтому нужен STP.

6. Как STP всё это лечит

STP (Spanning Tree Protocol, 802.1D) умеет одну простую вещь: построить из топологии с кольцами логическое дерево (без циклов), заблокировав избыточные порты. Если основной линк падает — заблокированный «оживает» автоматически. Эластичность + защита от петель.

STP в действии: выбор root и блокировка лишнего
До STP — кольца есть, петля возможна SW-A (ROOT) priority 4096 SW-B priority 32768 SW-C priority 32768 SW-D priority 32768 X BLOCKED резерв на случай аварии Как выбирался root: Меньшая Bridge ID = Priority (4096) + MAC. SW-A приоритет ниже → стал root. Если приоритеты одинаковые — побеждает MAC, который меньше численно.
Один линк намеренно заблокирован. Если уйдёт SW-A↔SW-B — за 30-60 сек STP переключится на резерв.

Состояния портов STP (классический)

Состояния порта STP
Blocking слушает BPDU 20 секунд Listening слушает + шлёт BPDU 15 секунд Learning учит MAC 15 секунд Forwarding данные идут Disabled админ. shutdown Итого: 50 секунд до начала передачи данных. Это очень долго! Поэтому придумали RSTP (802.1w) — переход в Forwarding за ~6 секунд.
Между Disabled и Forwarding порт проходит три промежуточных состояния, итого ~50 секунд.

RSTP — современная замена

RSTP (Rapid Spanning Tree Protocol, 802.1w) сократил время сходимости с 50с до ~6с. Состояний теперь три: DiscardingLearningForwarding. Используется по умолчанию на всех современных свитчах.

Расширения STP — must know

ФичаЗачем
BPDU Guard На access-портах. Если кто-то воткнул свой свитч (а тот шлёт BPDU) → порт мгновенно err-disabled. Защита от подделки root.
Root Guard На trunk-портах в сторону «не root». Если оттуда приходит BPDU с лучшим priority — порт блокируется. Защита, что root не «переедет» внезапно.
BPDU Filter Запрещает порту участвовать в STP. Использовать ОСТОРОЖНО — можно создать loop, если ошибся в топологии.
PortFast / edge port На access-портах. Порт сразу в Forwarding, не ждёт STP. Для DHCP-клиентов, серверов — важно (быстрая загрузка).
Loop Guard Защита от «unidirectional link» (когда BPDU перестали приходить, но физически линк жив) — блокирует порт вместо ошибочного forwarding.
UDLD (Unidirectional Link Detection) Cisco-specific. Активная проверка двунаправленности линка. Часто включают на оптике.

7. EtherChannel / LAG — альтернатива STP

Когда нужно несколько линков в одну сторону, но не хочется блокировать половину через STP — собирают их в EtherChannel (Cisco) / Link Aggregation Group (стандарт IEEE 802.3ad / 802.1AX). Несколько физических линков становятся одним логическим, с балансировкой по hash.

STP vs LAG
С STP: один линк работает, второй спит SW-A SW-B 1G FORWARDING 1G BLOCKED Эффективная скорость: 1 Gbps 50% линка простаивает LAG: оба линка работают параллельно SW-A SW-B port-channel Эффективная скорость: 2 Gbps балансировка по hash(src/dst MAC) + failover автоматический
LAG настраивается через LACP (динамический, стандарт) или PAgP (Cisco-only). Стандарт: LACP.

8. Cisco-конфиги для практики

Создать VLAN

switch# configure terminal switch(config)# vlan 10 switch(config-vlan)# name USERS switch(config-vlan)# exit switch(config)# vlan 20 switch(config-vlan)# name SERVERS switch(config-vlan)# exit

Access-порт

switch(config)# interface GigabitEthernet0/1 switch(config-if)# switchport mode access switch(config-if)# switchport access vlan 10 switch(config-if)# spanning-tree portfast # быстрый старт для хоста switch(config-if)# spanning-tree bpduguard enable # err-disable, если придёт BPDU switch(config-if)# description "Marketing PC-15"

Trunk-порт

switch(config)# interface GigabitEthernet0/24 switch(config-if)# switchport trunk encapsulation dot1q switch(config-if)# switchport mode trunk switch(config-if)# switchport trunk allowed vlan 10,20,30,99 # только эти switch(config-if)# switchport trunk native vlan 999 # native = unused switch(config-if)# switchport trunk native vlan tag # тегировать всё, безопасность

SVI (L3 на L3-свитче)

switch(config)# ip routing switch(config)# interface vlan 10 switch(config-if)# ip address 10.10.0.1 255.255.255.0 switch(config-if)# no shutdown switch(config)# interface vlan 20 switch(config-if)# ip address 10.20.0.1 255.255.255.0 switch(config-if)# no shutdown # Теперь VLAN 10 ↔ VLAN 20 общаются через wire-speed routing

STP / RSTP

switch(config)# spanning-tree mode rapid-pvst # RSTP per-VLAN switch(config)# spanning-tree vlan 10 priority 4096 # этот свитч = root для VLAN 10 switch(config)# spanning-tree portfast bpduguard default # BPDU guard на всех PortFast switch# show spanning-tree # текущая топология STP switch# show spanning-tree root # кто root

LACP (LAG)

switch(config)# interface range gi0/23 - 24 switch(config-if-range)# channel-group 1 mode active # LACP active switch(config-if-range)# exit switch(config)# interface Port-channel 1 switch(config-if)# switchport mode trunk switch(config-if)# switchport trunk allowed vlan 10,20,30 switch# show etherchannel summary

9. QinQ (802.1ad) — двойной тег

Провайдеру нужно пропустить через свою сеть клиентские VLAN'ы, не трогая их. Решение — QinQ: добавляет ещё один внешний 802.1Q-тег поверх клиентского. Клиент думает, что его кадры идут «как есть»; провайдер коммутирует по своему внешнему тегу.

QinQ — внешний тег провайдера + внутренний тег клиента
Dst MAC Src MAC S-TAG TPID 0x88a8 VID = провайдер C-TAG TPID 0x8100 VID = клиент ET Payload FCS S-TAG (service / outer) + C-TAG (customer / inner)
Провайдер пропускает 4096 клиентов × 4096 VLAN каждого = 16 миллионов виртуальных сетей.

QinQ на стыке: внешний тег занимает место, и его надо где-то взять

Второй тег — это +4 байта к каждому кадру. Кадр, который на клиентской стороне ровно помещался в допустимый размер, на стыке провайдера в него уже не помещается. Это самая частая авария при вводе QinQ, и выглядит она знакомо по уроку о MTU: мелкое проходит, объёмное — нет.

Официальная документация Junos OS формулирует выбор прямо. При значении MTU по умолчанию «you need to make one of the following adjustments»:

На практике операторы почти всегда выбирают второе: урезать клиента означает трогать его оборудование, к которому доступа нет, а расширять свой стык — работа внутри своей зоны. Отсюда практическое правило: перед вводом QinQ поднимается допустимый размер кадра на всех устройствах по пути услуги, а не только на двух крайних.

ловушка Вендоры считают MTU от разных мест. В приведённой документации Junos значение по умолчанию названо как 1514 байт — то есть с учётом заголовка Ethernet. Другие платформы считают то же самое как 1500, отсчитывая от полезной нагрузки. Одно и то же число на двух сторонах стыка может означать разный размер кадра, и разница ровно в те самые байты, из-за которых услуга не работает. Перед согласованием значения выясни, что именно вендор включает в MTU.

10. Частые ошибки и сценарии

сценарий 1 «VLAN не работает между двумя свитчами» → 1) Проверь, что VLAN существует на обоих (show vlan brief). 2) Проверь, что trunk правильно поднят (show interfaces trunk). 3) Проверь, что в switchport trunk allowed vlan есть нужный номер. 4) Если разные native VLAN на сторонах — увидишь warning «native VLAN mismatch».
сценарий 2 «После подключения нового свитча половина сети легла» → Самое вероятное: новый свитч прибыл с дефолтным STP priority (32768) и более низким MAC, стал root для всего домена → топология перестроилась → пакеты «потерялись» на 30 секунд. Профилактика: на core-свитчах spanning-tree priority 4096, на новых устанавливай bpduguard на все access-порты.
сценарий 3 «PC получает IP из «чужого» DHCP» → Кто-то воткнул роутер с DHCP в офисную сеть → broadcast DISCOVER пошёл к нему первому → клиент получил «не тот» IP, default gateway уводит в никуда. Защита: DHCP snooping на свитчах + access-порты с BPDU guard.

11. Плейбук: «легла вся сеть» — разбираем шторм из заявки

Возвращаемся к инциденту 9:05. Сеть на 400 человек мертва, коммутаторы мигают всеми портами. Действия по секундам — здесь дорога каждая минута простоя:

Распознай шторм по подписи (30 секунд)
Три симптома вместе = шторм, а не «упал сервер»: 1) легло всё и сразу, включая телефонию и печать; 2) индикаторы всех портов мигают синхронно и бешено; 3) CPU коммутаторов упирается в потолок, консоль еле дышит. Одиночные отказы так не выглядят. Причина всегда одна: где-то замкнулась петля L2.
Зайди на ближайший коммутатор через консольный кабель
По сети (SSH) не зайдёшь — она забита. Консольный порт работает всегда. Смотри: show processes cpu (интерапты под 100%), show interfaces (у всех портов гигантский broadcast input rate), и главное — show mac address-table | include flap или лог: «MAC … flapping between Gi0/12 and Gi0/24». Эти два порта — стороны петли или путь к ней.
Отрежь петлю, а не выключай сеть
На порту-подозреваемом: shutdown. Сеть оживает мгновенно — шторм умирает в ту же секунду, как рвётся кольцо. Если flapping указывает на аплинк к этажному коммутатору — глуши не аплинк, а спускайся на этот коммутатор и ищи петлю там (тот самый принесённый свитчик, у которого сотрудник воткнул оба конца одного патч-корда или соединил две розетки).
Найди физическую причину
В нашей заявке: домашний свитчик на 5 портов, в который воткнули две офисные розетки («чтобы работало наверняка»). Обе розетки ведут в один этажный коммутатор → кольцо готово. Домашний свитч не говорит STP и не отправляет BPDU — для офисного коммутатора петля невидима, пока тот сам не получит свои кадры обратно.
Сделай повторение невозможным
На каждый access-порт: spanning-tree portfast + spanning-tree bpduguard enable (чужой коммутатор с BPDU → порт в err-disabled), плюс storm-control broadcast level 1.00 (душить broadcast выше 1% полосы — петля через тупой свитч без BPDU тоже будет обезврежена). На аплинках — root guard. 15 минут конфигурации против часа простоя всей компании.
Отчитайся по-инженерному
«Причина: петля L2 через неавторизованный коммутатор, STP-защита на access-портах отсутствовала. Устранено: порт отключён, устройство изъято. Профилактика: BPDU guard + storm-control развёрнуты на все access-порты всех этажей, заведён стандарт конфигурации порта». Такой отчёт закрывает не заявку — класс аварий.

12. Мини-лаба: потрогай тег 802.1Q руками

Домашние свитчи теги снимают, поэтому берём два пути: виртуальный Linux (WSL2 подойдёт) и Packet Tracer для полной картины.

Создай VLAN-интерфейс в Linux и поймай тег в дампе
# пара veth: как патч-корд между двумя "хостами" $ sudo ip link add vethA type veth peer name vethB $ sudo ip link set vethA up && sudo ip link set vethB up # на обоих концах — сабинтерфейс с тегом VLAN 10 $ sudo ip link add link vethA name vethA.10 type vlan id 10 $ sudo ip link add link vethB name vethB.10 type vlan id 10 $ sudo ip addr add 10.0.10.1/24 dev vethA.10 && sudo ip link set vethA.10 up $ sudo ip addr add 10.0.10.2/24 dev vethB.10 && sudo ip link set vethB.10 up # дамп на "проводе" (vethB, БЕЗ .10) + пинг по VLAN $ sudo tcpdump -ni vethB -e vlan & $ ping -c 2 10.0.10.2
В дампе увидишь vlan 10, p 0, ethertype IPv4 — тег 802.1Q в живом кадре. Сабинтерфейс .10 — ровно то, что делает router-on-a-stick из раздела 4. Уборка: sudo ip link del vethA.
Собери два VLAN в Packet Tracer
Скачай Cisco Packet Tracer (бесплатно после регистрации в Netacad). Схема: 1 коммутатор, 4 ПК. Два ПК → VLAN 10 (10.0.10.x), два → VLAN 20 (10.0.20.x). Проверь: внутри VLAN пинг ходит, между — нет, даже если адреса из одной подсети. Это ключевой инсайт: VLAN изолирует на L2, до IP дело даже не доходит (ARP не проходит).
Добавь второй коммутатор и trunk
Разнеси VLAN 10 и 20 по двум коммутаторам, соедини их: сначала access-портом (VLAN 10 заработает, VLAN 20 — нет), потом trunk'ом (switchport mode trunk) — поедут оба. Открой Simulation-режим и посмотри, как кадр получает тег на входе в trunk и теряет на выходе в access.
Устрой шторм — в симуляторе можно!
Соедини два коммутатора двумя кабелями и выключи STP (no spanning-tree vlan 1). Пусти один broadcast (пинг на несуществующий адрес) в Simulation-режиме — и смотри, как кадр бесконечно ходит по кольцу, размножаясь. Потом включи STP обратно и увидь, как один порт станет оранжевым (blocked) — кольцо разорвано логически. Всё, ты видел шторм и его лекарство своими глазами.

13. Словарик урока

ТерминПо-английскиСмысл в одну строку
VLANvirtual LAN, 802.1Qлогическая L2-сеть внутри физической; отдельный broadcast-домен на каждый VID
Тег802.1Q tag4 байта в кадре: 12 бит VID (до 4094 сетей) + 3 бита приоритета (CoS)
Порт доступаaccess portпорт одного VLAN, кадры ходят без тега — для конечных устройств
Магистральный портtrunk portнесёт много VLAN, кадры с тегами — между коммутаторами и к роутеру
Нетегированный VLANnative VLANVLAN без тега на trunk; несовпадение сторон = тихая утечка кадров между сетями
SVIswitched virtual interfaceL3-интерфейс VLAN на коммутаторе (interface vlan 10) — современный inter-VLAN routing
Роутер-на-палочкеrouter-on-a-stickодин физический линк, сабинтерфейсы с тегами — старая школа inter-VLAN
ПетляL2 loopкольцо в топологии; у кадра нет TTL — трафик размножается до смерти сети
Широковещательный штормbroadcast stormлавина размноженных петлёй кадров: CPU 100%, сеть мертва за секунды
STP / RSTPspanning tree protocolпротокол, логически блокирующий избыточные линки; RSTP сходится за ~6 с
Корневой мостroot bridge«центр» STP-дерева: выбирается по наименьшему priority+MAC; назначай его сам!
BPDUbridge protocol data unitслужебные кадры STP; по ним строится дерево и ловятся чужие коммутаторы
Защита BPDU guardBPDU на access-порту → порт в err-disabled; главный щит от принесённых свитчей
Portfastaccess-порт минует состояния STP и работает сразу — иначе DHCP-клиенты ждут 30 с
Агрегация линковLAG / EtherChannel / LACPнесколько линков как один логический: и резерв, и вся полоса (STP не блокирует)
Двойной тегQinQ, 802.1adпровайдер оборачивает клиентский тег своим: 4094×4094 ≈ 16 млн сетей

14. Задачи на понимание

Задача 1. Два ПК воткнуты в один коммутатор, адреса 192.168.1.10/24 и 192.168.1.20/24, но порты в разных VLAN (10 и 20). Будет ли пинг и почему? Что покажет arp -a?

Пинга не будет, хотя подсеть одна. ARP-запрос — это broadcast, а broadcast не пересекает границу VLAN: второй ПК его физически не услышит. arp -a покажет запись INCOMPLETE/недоступную, пинг скажет «Destination host unreachable». Мораль: VLAN изолирует ниже IP — никакая адресация не поможет без L3-маршрутизатора между VLAN.

Задача 2. На trunk между двумя коммутаторами native VLAN: слева 1, справа 99. Чем это опасно и как проявится?

Кадры VLAN 1 слева уходят в trunk без тега; справа бестеговые кадры зачисляются в VLAN 99 — трафик тихо перетекает между сетями (и это вектор атаки VLAN hopping). CDP выдаст «Native VLAN mismatch», STP может блокировать. Правило: native VLAN одинаковый с обеих сторон, выделенный, без пользователей — а лучше тегировать всё (vlan dot1q tag native).

Задача 3. Четыре коммутатора: A (priority 4096, MAC …aa), B (32768, …01), C (32768, …ff), D (8192, …bb). Кто root bridge? А если A выключится?

Root — A: сначала сравнивается priority, 4096 меньше всех. Если A умрёт — root станет D (8192). MAC решает только при равных priority (тогда между B и C выиграл бы B с меньшим …01). Вывод: root назначают руками через priority на core-коммутаторах, иначе root'ом станет случайная железка с древним MAC — и трафик поедет через неё.

Задача 4. Зачем на access-порту нужны ОБЕ команды: spanning-tree portfast И bpduguard enable? Что делает каждая и что будет, если оставить только portfast?

portfast — порт не ждёт 30 секунд STP-состояний (иначе ПК не успевает получить DHCP при загрузке). Но portfast-порт всё ещё доверяет BPDU: воткнутый коммутатор может встроиться в топологию или даже стать root. bpduguard закрывает дыру: пришёл BPDU → порт в err-disabled. Вместе: быстрый старт для ПК + смерть для принесённых свитчей. По одиночке каждая решает полдела.

Задача 5. После подключения нового коммутатора из коробки сеть «замерла» на полминуты, потом ожила, но стала медленнее. Ни петли, ни шторма. Что произошло?

Новый коммутатор с дефолтным priority 32768 и старым/маленьким MAC выиграл выборы root bridge. STP перестроил дерево (пауза ~30–50 с у классического STP), и теперь межэтажный трафик ходит через новую слабую железку — отсюда «медленнее». Диагностика: show spanning-tree root. Лечение: на core — spanning-tree vlan 1-4094 priority 4096, на границе — root guard.

Задача 6. Провайдер даёт тебе EPL-услугу «прозрачный L2 между офисами» через QinQ. Твои кадры уже несут теги VLAN 10–30. Сколько тегов будет в кадре внутри сети провайдера и кто какой снимет?

Два тега: внутренний (C-tag, твой 10–30 — провайдер его не трогает и не видит) и внешний (S-tag, например 1547 — номер твоей услуги в сети провайдера). На входе PE-коммутатор провайдера надевает S-tag, на выходе к второму офису — снимает. Твои VLAN приезжают нетронутыми, как будто офисы соединили длинным патч-кордом. Подробный разбор EPL — в треке СПД, урок «EPL/EVPL».

15. Источники

Мост к следующему модулю

Ты нарезал сеть на VLAN — и у тебя появились изолированные broadcast-домены: бухгалтерия, разработка, телефония, гости. Но каждому домену теперь нужна своя IP-подсеть, и кто-то должен решить: сколько адресов выделить каждой, как их нарезать без пересечений и оставить запас на рост. Это ремесло следующего модуля — IP-адресация и подсети: маски, CIDR, VLSM и расчёты, которые сетевик делает в уме. Именно там VLAN 10 получит свои 10.0.10.0/24.