Виртуальные локальные сети, связующее дерево и агрегирование каналов

В теме 4 был построен коммутируемый Ethernet: коммутатор изучает MAC-адреса отправителей, пересылает кадр только в тот порт, за которым находится получатель, а кадры с неизвестным или широковещательным адресом рассылает во все порты, кроме входного. Такая сеть работает без всякой настройки — достаточно соединить коммутаторы кабелями. Именно эта простота порождает три вопроса, на которые в теме 4 ответа не было. Что делать, когда сеть разрастается до сотен и тысяч узлов и каждый широковещательный кадр доходит до каждого из них? Как соединить коммутаторы с резервированием, если два параллельных пути между ними превращают лавинную рассылку в бесконечную циркуляцию кадров? Как получить между двумя коммутаторами канал быстрее одного физического звена, не создав при этом той же петли?

Ответы на эти вопросы дают три механизма, стандартизованные рабочей группой IEEE 802.1. Виртуальные локальные сети (англ. Virtual Local Area Network, VLAN) разбивают одну физическую сеть на несколько логически независимых широковещательных доменов ¹. Протокол связующего дерева (англ. Spanning Tree Protocol, STP) позволяет строить сеть с избыточными связями, автоматически отключая лишние звенья так, чтобы активная топология оставалась деревом ²⁴. Агрегирование каналов (англ. Link Aggregation) объединяет несколько параллельных звеньев в один логический канал, который и STP, и протоколы верхних уровней видят как одно звено ³.

Изложение построено так. Сначала разбираются ограничения «плоской» сети канального уровня. Затем рассматривается стандарт IEEE 802.1Q: формат тега, порты доступа и магистральные порты, native VLAN и типичные ошибки настройки. Третий раздел посвящён петлям и широковещательному шторму, четвёртый — алгоритму связующего дерева, его протоколу и быстрым вариантам RSTP и MSTP. Пятый раздел описывает агрегирование каналов и протокол LACP, шестой — иерархическое проектирование кампусной сети и обзор атак на канальный уровень. Примеры выводов команд получены на программном мосте Linux в топологии лабораторной работы 5.

Пределы плоской сети канального уровня

Широковещательный домен и его рост

Широковещательный домен (англ. broadcast domain) — множество узлов, до которых доходит кадр, отправленный на адрес ff:ff:ff:ff:ff:ff. В сети из коммутаторов без дополнительной настройки широковещательный домен совпадает со всей сетью: коммутатор не фильтрует широковещательные кадры, а рассылает их во все порты, как было показано в теме 4. Маршрутизатор, напротив, широковещательные кадры канального уровня не пересылает, поэтому именно он традиционно служит границей домена.

Широковещательных кадров в обычной сети много больше, чем кажется. Протокол разрешения адресов ARP рассылает широковещательный запрос всякий раз, когда хосту нужен MAC-адрес соседа, отсутствующий в кеше (подробно — в теме 7). Клиент DHCP ищет сервер широковещательным сообщением (тема 14). Многие службы обнаружения — NetBIOS, mDNS, SSDP — используют широковещание или групповую рассылку, которую простой коммутатор обрабатывает так же, как широковещание. Каждый такой кадр должен принять и обработать каждый узел домена: сетевая карта передаёт его операционной системе, и та тратит процессорное время хотя бы на то, чтобы его отбросить.

Нагрузка растёт квадратично. Пусть в домене N узлов и каждый порождает в среднем r широковещательных кадров в секунду. Тогда каждый узел принимает N·r кадров в секунду, а суммарно по всем портам доставляется N²·r кадров. Для N = 50 и r = 0,5 кадра в секунду каждый узел получает 25 кадров в секунду — незаметная величина. Для N = 5000 при той же интенсивности каждый узел получает 2500 кадров в секунду, а беспроводная точка доступа обязана передать все эти кадры в эфир на минимальной скорости, отнимая время передачи у полезного трафика. Поэтому на практике широковещательный домен ограничивают несколькими сотнями узлов; в адресации IPv4 этому соответствует подсеть размером порядка /24 (тема 6).

Безопасность и управление

Плоская сеть плоха не только нагрузкой. Все узлы широковещательного домена находятся «в одном сегменте»: каждый из них видит широковещательный трафик остальных и может напрямую, минуя любой фильтр, отправить кадр любому соседу. Если в одном домене оказались рабочие станции бухгалтерии, гостевой Wi-Fi и сервер с базой данных, то атака подменой ARP-ответов или простое сканирование сети с гостевого ноутбука ничем не ограничены. Разделение на сегменты, между которыми трафик проходит только через маршрутизатор или межсетевой экран, — базовый приём сетевой безопасности (тема 18).

Есть и организационная сторона. Принадлежность узла к сегменту в плоской сети определяется тем, к какому коммутатору подведён его кабель. Переезд сотрудника из одного отдела в другой, появление в офисе IP-телефонов, которым нужен отдельный сегмент с приоритетом трафика, временный проектный сегмент — каждое такое изменение требует перекоммутации кабелей или покупки отдельных коммутаторов. Желательно, чтобы принадлежность порта к сегменту задавалась настройкой, а не физической топологией.

Логическое разделение вместо физического

Все три задачи — ограничение широковещательного домена, изоляция и гибкость управления — решаются одной идеей: на одном физическом коммутаторе создаётся несколько логических, каждый со своей таблицей MAC-адресов и своим широковещательным доменом. Порт коммутатора относится к одному из логических коммутаторов, и кадр, принятый на порту, может покинуть коммутатор только через порты того же логического коммутатора. Если такие логические сети нужно протянуть через несколько физических коммутаторов, кадрам между коммутаторами приходится нести метку принадлежности. Стандартный способ такой метки и составляет содержание стандарта IEEE 802.1Q ¹.

Заметим, что VLAN не заменяет IP-подсети, а дополняет их. Обычно одной VLAN соответствует одна IP-подсеть: узлы внутри VLAN связываются непосредственно на канальном уровне, а для связи между VLAN нужен маршрутизатор, как между любыми двумя подсетями. В лабораторной работе 5 все хосты намеренно помещены в одну подсеть 10.5.0.0/24, чтобы показать: изоляцию обеспечивает именно VLAN, и хост из VLAN 10 не может достичь хоста из VLAN 20, даже если IP-адреса формально позволяют.

Виртуальные локальные сети IEEE 802.1Q

Тег 802.1Q и его поля

Стандарт IEEE 802.1Q, впервые принятый в 1998 году и с тех пор вобравший в себя большинство стандартов о мостах ¹, определяет способ пометить кадр Ethernet номером VLAN. Между полем адреса источника и полем EtherType вставляются 4 байта тега (англ. VLAN tag). Тег состоит из двух частей.

• Идентификатор протокола тега (англ. Tag Protocol Identifier, TPID) — 2 байта со значением 0x8100. Он стоит на месте, где в обычном кадре находится EtherType, поэтому устройство, не знающее о VLAN, увидит «неизвестный протокол 0x8100» и не спутает тег с данными.
• Управляющая информация тега (англ. Tag Control Information, TCI) — 2 байта, из которых:
  • PCP (англ. Priority Code Point), 3 бита — приоритет кадра от 0 до 7, используемый для обслуживания очередей (иногда это поле называют по старому стандарту 802.1p);
  • DEI (англ. Drop Eligible Indicator), 1 бит — признак кадра, который допустимо отбросить первым при перегрузке; в ранних редакциях стандарта этот бит назывался CFI и имел другой смысл;
  • VID (англ. VLAN Identifier), 12 бит — номер VLAN.

Двенадцать бит дают 4096 значений, но два из них зарезервированы: VID 0 означает, что кадр несёт только приоритет и к VLAN не относится (англ. priority-tagged frame), а VID 4095 (0xFFF) зарезервирован для реализаций. Для нумерации VLAN остаются значения от 1 до 4094 ¹. VLAN 1 по традиции служит VLAN по умолчанию: в ней находятся все порты нового коммутатора, в том числе программного моста Linux.

Как видно на рисунке, тег увеличивает максимальный размер кадра с 1518 до 1522 байт. Минимальный размер кадра при этом остаётся 64 байтами, поэтому минимальная длина данных в помеченном кадре — 42 байта вместо 46. Вставка тега меняет содержимое кадра, и коммутатор, добавляющий или снимающий тег, обязан заново вычислить контрольную сумму FCS. Порядок приоритетов PCP не совпадает с числовым: значение 1 означает «фоновый» трафик и обслуживается хуже, чем значение 0 — «обычный» (англ. best effort) ¹. Эта особенность исторически связана с тем, что кадры без тега считаются имеющими приоритет 0, и для фонового трафика пришлось выделить значение, отличное от нуля.

Разберём реальный кадр — эхо-запрос, захваченный на межкоммутаторном звене учебной топологии:

0x0000:  0200 0000 0003 0200 0000 0001 8100 000a
0x0010:  0800 4500 0054 f9df 4000 4001 2cbc 0a05
0x0020:  0001 0a05 0003 0800 dd5d ab24 0001 ...

Первые 6 байт 02:00:00:00:00:03 — адрес назначения, следующие 6 байт 02:00:00:00:00:01 — адрес источника. Далее вместо EtherType стоит 8100 — это TPID, признак тега. Два следующих байта 000a — TCI: в двоичной записи 0000 0000 0000 1010, то есть PCP = 000 (приоритет 0), DEI = 0, VID = 0x00a = 10. Только после тега идёт настоящий EtherType 0800 — IPv4, и с байта 45 начинается заголовок IP. Утилита tcpdump -e выводит ту же информацию в разобранном виде:

02:00:00:00:00:01 > 02:00:00:00:00:03, ethertype 802.1Q (0x8100), length 102:
    vlan 10, p 0, ethertype IPv4 (0x0800), 10.5.0.1 > 10.5.0.3: ICMP echo request, ...

Длина кадра 102 байта на 4 больше, чем у такого же кадра без тега (98 байт; FCS при захвате не показывается).

Порты доступа и магистральные порты

Конечные узлы — компьютеры, принтеры, телефоны — о VLAN обычно не знают и отправляют кадры без тега. Решение о том, к какой VLAN относится кадр, принимает коммутатор по порту, на который кадр пришёл. Порт, к которому подключён один конечный узел одной VLAN, называют портом доступа (англ. access port). Принятый на нём кадр без тега коммутатор относит к VLAN порта, а кадры этой VLAN, уходящие через порт, отправляет без тега. Номер VLAN, присваиваемый входящим кадрам без тега, в стандарте называется идентификатором VLAN порта (англ. Port VLAN Identifier, PVID) ¹.

Звено между двумя коммутаторами должно переносить кадры нескольких VLAN. Порт такого звена называют магистральным (англ. trunk port; в терминах стандарта — порт, через который кадры передаются с тегом). Каждый кадр, уходящий через магистральный порт, получает тег с номером своей VLAN, а коммутатор на другой стороне по тегу определяет, в какую VLAN кадр поместить. Термин «trunk» — профессиональный жаргон, введённый производителями оборудования; в стандарте 802.1Q его нет, а в документации Linux слово «trunk» не используется вовсе.

Схема на рисунке показывает учебную топологию лабораторной работы 5 и путь кадра от h1 к h3. Хост h1 отправляет кадр без тега; коммутатор sw1 принимает его на порту доступа p1 и относит к VLAN 10. Таблицу MAC-адресов коммутатор ведёт отдельно для каждой VLAN: запись «адрес h3 — порт t12» действует только в VLAN 10. Через магистраль t12 кадр уходит с тегом VID 10. Коммутатор sw2 по тегу помещает кадр в VLAN 10, находит в своей таблице порт p3 и, поскольку p3 — порт доступа VLAN 10, снимает тег. Хост h3 получает обычный кадр и не подозревает о существовании VLAN.

Поведение порта определяется тремя независимыми параметрами: какие VLAN разрешены на порту, какая VLAN является PVID и для каких VLAN исходящие кадры отправляются без тега. Порт доступа и магистральный порт — лишь два типичных сочетания этих параметров. Таблица сводит обработку кадра на входе и выходе порта.

Программный мост Linux реализует фильтрацию по VLAN с версии ядра 3.8; её включает параметр моста vlan_filtering 1 ⁹¹². Без него мост вообще не обращает внимания на теги и пересылает помеченные кадры как любые другие. Настройка выполняется командой bridge vlan: флаг pvid назначает VLAN входящим кадрам без тега, флаг untagged предписывает снимать тег на выходе. Порт доступа и магистральный порт в учебной топологии настраиваются так:

# порт доступа p1 в VLAN 10: убрать VLAN 1 по умолчанию, назначить 10
bridge -n sw1 vlan del dev p1 vid 1
bridge -n sw1 vlan add dev p1 vid 10 pvid untagged
# магистраль t12: VLAN 10 и 20 с тегом; VLAN 1 остаётся без тега (native)
bridge -n sw1 vlan add dev t12 vid 10
bridge -n sw1 vlan add dev t12 vid 20
bridge -n sw1 vlan show

port              vlan-id
br0               1 PVID Egress Untagged
p1                10 PVID Egress Untagged
p2                20 PVID Egress Untagged
t12               1 PVID Egress Untagged
                  10
                  20

Строка br0 описывает сам мост как порт: через неё кадры попадают в стек IP самого коммутатора-пространства имён. Это пригодится, когда коммутатору нужен управляющий адрес в одной из VLAN.

Native VLAN и ошибки на магистрали

VLAN, кадры которой на магистральном порту передаются без тега, называют native VLAN (термин производителей; в стандарте ей соответствует PVID магистрального порта). Она нужна, чтобы через магистраль можно было подключить устройство, не умеющее работать с тегами, и чтобы служебные протоколы, передающие кадры без тега, работали поверх магистрали. На каждой магистрали native VLAN может быть только одна: кадр без тега не несёт номера, и отнести его можно лишь к одной VLAN.

Отсюда самая коварная ошибка настройки — несовпадение native VLAN на двух концах магистрали (англ. native VLAN mismatch). Пусть на sw1 магистральный порт отправляет без тега VLAN 10, а на sw2 тот же порт считает кадры без тега принадлежащими VLAN 20. Кадр h1 из VLAN 10 уходит из sw1 без тега, sw2 помещает его в VLAN 20 и доставляет хосту h4 из чужой VLAN. Два широковещательных домена молча сливаются в один, и никакой ошибки ни одна сторона не видит: каждый коммутатор в отдельности настроен корректно. Симптомы при этом выглядят странно: часть пар хостов связана, часть — нет, и связаны как раз те, кто по замыслу изолирован. Лабораторная работа 5 содержит задание на поиск именно такой неисправности. Коммерческие коммутаторы обнаруживают несоответствие собственными служебными протоколами (например, Cisco CDP), но стандарт 802.1Q такой проверки не предусматривает.

Вторая типичная ошибка — забытая VLAN на магистрали. Если VLAN 20 разрешена на портах доступа обоих коммутаторов, но не добавлена на магистральный порт хотя бы одного из них, кадры этой VLAN отбрасываются на магистрали, и хосты VLAN 20 на разных коммутаторах не видят друг друга, тогда как VLAN 10 работает. Третья ошибка — использование VLAN 1 и native VLAN для пользовательского трафика; почему это опасно, будет показано в разделе о безопасности канального уровня.

Связь между VLAN и вложенные теги

VLAN — отдельные широковещательные домены, и кадр из одной VLAN в другую коммутатор канального уровня не передаст никогда. Связь между VLAN — задача сетевого уровня: у каждой VLAN есть своя IP-подсеть, и пакеты между подсетями пересылает маршрутизатор. Существуют два распространённых способа подключить маршрутизатор к нескольким VLAN. В схеме «маршрутизатор на палочке» (англ. router-on-a-stick) маршрутизатор подключён к коммутатору одним магистральным звеном, а на его интерфейсе созданы логические подынтерфейсы — по одному на VLAN, каждый со своим адресом шлюза; в Linux такой подынтерфейс создаётся командой ip link add link eth0 name eth0.10 type vlan id 10. Второй способ — коммутатор третьего уровня (англ. Layer 3 switch), у которого внутри есть виртуальный интерфейс маршрутизации для каждой VLAN и аппаратная пересылка пакетов между ними. Подробности маршрутизации между VLAN, включая таблицы маршрутизации и выбор шлюза, рассматриваются в теме 8.

Двенадцати бит VID хватает предприятию, но не провайдеру, который хочет передавать через свою сеть VLAN множества клиентов, сохраняя их номера. Для этого стандарт IEEE 802.1ad (2005 год, ныне часть 802.1Q) ввёл двойное тегирование (англ. QinQ, Provider Bridging) ¹. На входе в сеть провайдера к кадру с клиентским тегом (C-tag, TPID 0x8100) добавляется внешний сервисный тег (S-tag) с TPID 0x88A8, номер которого обозначает клиента. Внутри сети провайдера коммутаторы смотрят только на внешний тег, а клиентский переносится прозрачно. Число возможных сочетаний возрастает до 4094 × 4094, а максимальный размер кадра — ещё на 4 байта. В центрах обработки данных ту же задачу масштабирования решают наложенные сети VXLAN с 24-битным идентификатором сегмента (тема 21).

Петли и широковещательный шторм

Зачем нужны избыточные связи

Сеть, в которой между любыми двумя коммутаторами существует ровно один путь, — дерево — уязвима: отказ любого звена или коммутатора разрывает её на части. Кабель, случайно выдернутый в коммутационном шкафу, отключит целый этаж. Естественная мера — добавить резервные звенья, например соединить коммутаторы кольцом или подключить каждый коммутатор этажа к двум коммутаторам уровня распределения. Но как только в топологии появляется цикл, правила работы прозрачного моста, изложенные в теме 4, перестают работать.

Механизм шторма

Рассмотрим кольцо из трёх коммутаторов sw1, sw2, sw3 и хост h1, подключённый к sw1. Хост отправляет ARP-запрос на широковещательный адрес. Коммутатор sw1 обязан разослать широковещательный кадр во все порты, кроме входного, — в том числе в оба звена кольца, t12 и t13. Коммутатор sw2 получает копию по t12 и тоже рассылает её во все порты, кроме входного, — в том числе в t23. Коммутатор sw3 получает её и пересылает в t13, обратно к sw1. Тот снова рассылает её во все порты, кроме входного, — в том числе в t12. Круг замкнулся, и навстречу этой копии по кольцу в обратном направлении движется вторая.

Схема на рисунке иллюстрирует три следствия. Во-первых, кадр никогда не исчезает: ни один коммутатор не имеет оснований его отбросить. Во-вторых, на каждом обходе кольца каждая копия заново доставляется всем хостам всех трёх коммутаторов, и каждый хост принимает один и тот же ARP-запрос тысячи раз в секунду. В-третьих, копии кадра приходят на коммутатор то с одной стороны, то с другой, и коммутатор каждый раз «переучивается»: запись об адресе источника h1 переносится с порта на порт. Это явление называют нестабильностью таблицы MAC-адресов (англ. MAC address flapping). Пока шторм продолжается, кадры, адресованные h1, коммутатор отправляет в звено кольца вместо порта, к которому h1 подключён на самом деле.

В простом кольце число копий не растёт: каждый коммутатор кольца имеет лишь два порта в кольце, и копия, вошедшая в один, выходит через другой. Но скорость их обращения ограничена только производительностью коммутаторов и пропускной способностью звеньев, поэтому звенья кольца загружаются полностью. Если же у коммутатора больше двух портов, ведущих в циклы (например, в полносвязной топологии из четырёх коммутаторов), каждая копия на каждом коммутаторе порождает несколько новых, и число кадров растёт экспоненциально, пока не упрётся в пропускную способность. Эксперимент лабораторной работы 5 замыкает кольцо из трёх мостов Linux на две секунды и отправляет с h1 один ARP-запрос:

Кольцо замкнуто. Отправляем один ARP-запрос с h1...
Кольцо разомкнуто через ~2 с.
Кадров принято портом t12 коммутатора sw1 за это время: 209707
Где теперь «живёт» MAC-адрес h1 (02:00:00:00:00:01) по мнению коммутаторов:
  sw1: t12(vlan 10)
  sw2: t12(vlan 1) t23(vlan 10)
  sw3: t23(vlan 10)

Один-единственный кадр за две секунды превратился примерно в двести тысяч кадров на одном порту, причём в кольце циркулировали и служебные групповые кадры IPv6, которые мосты Linux отправляют при включении портов. Точное число зависит от быстродействия машины. Важнее последние строки: коммутатор sw1, к которому h1 подключён непосредственно через порт p1, считает, что h1 находится за звеном t12. После размыкания кольца эта ошибочная запись будет держаться, пока h1 не отправит новый кадр или запись не устареет. На реальном оборудовании шторм за доли секунды делает сеть неработоспособной: перегружены звенья, процессоры коммутаторов, обрабатывающие широковещательные кадры, и все хосты сегмента. Шторм прекращается только с разрывом петли.

Почему у Ethernet нет TTL

В сетевом уровне от бесконечной циркуляции защищает поле «время жизни» (англ. Time to Live, TTL) заголовка IP: каждый маршрутизатор уменьшает его на единицу, и пакет, у которого TTL достиг нуля, уничтожается (тема 7). В кадре Ethernet подобного поля нет, и это не упущение, а следствие исходного требования к мосту. Мост задумывался как прозрачный (англ. transparent bridge): его установка не должна требовать изменения ни хостов, ни формата кадров, и хост не должен знать, отделён ли он от соседа мостом или нет ²⁵. Счётчик переходов пришлось бы добавить в заголовок кадра, а значит, изменить формат, который к тому времени уже был реализован в миллионах сетевых адаптеров. Кроме того, даже с TTL петля оставалась бы бедствием: каждый кадр всё равно размножался бы до истечения счётчика, а таблицы MAC-адресов оставались бы нестабильными.

Поэтому задача была решена иначе: если петель в топологии быть не должно, а резервные звенья нужны, мосты должны сами договориться, какие звенья временно не использовать. Эту договорённость и обеспечивает протокол связующего дерева. Позднее были предложены и решения, сохраняющие использование всех звеньев за счёт маршрутизации на канальном уровне: протокол TRILL (англ. Transparent Interconnection of Lots of Links), в заголовке которого есть счётчик переходов ¹⁰, и стандарт IEEE 802.1aq (Shortest Path Bridging). Оба применяются ограниченно; в современных центрах обработки данных петли канального уровня чаще устраняют, заменяя коммутацию маршрутизацией между стойками (тема 21).

Протокол связующего дерева

Идея алгоритма и выбор корня

Алгоритм связующего дерева предложила Радия Перлман в 1985 году ⁴. Сеть мостов рассматривается как граф: вершины — мосты и сегменты, рёбра — порты. Требуется выбрать подмножество портов, которые будут пересылать кадры, так, чтобы активная топология была деревом, связывающим все сегменты, — связующим деревом (англ. spanning tree) графа. Остальные порты переводятся в заблокированное состояние: они принимают служебные сообщения протокола, но не пересылают пользовательские кадры. При отказе звена дерево перестраивается, и заблокированный ранее порт может стать активным. Мосты вычисляют дерево распределённо, обмениваясь сообщениями лишь с непосредственными соседями, без центрального управления и без настройки — в этом достоинство алгоритма. Стандартом алгоритм стал в IEEE 802.1D ².

Дерево строится от корня. Каждый мост имеет идентификатор моста (англ. Bridge ID) длиной 8 байт: 2 байта приоритета и 6 байт MAC-адреса моста. В редакции 802.1D-2004 двухбайтное поле приоритета разделено: старшие 4 бита — собственно приоритет, задаваемый администратором кратно 4096 (от 0 до 61440, по умолчанию 32768), младшие 12 бит — расширение системного идентификатора (англ. System ID Extension), куда коммутаторы, строящие отдельное дерево для каждой VLAN, записывают номер VLAN ². Корнем (англ. root bridge) становится мост с наименьшим идентификатором. Идентификаторы сравниваются как 64-битные числа: сначала по приоритету, при равенстве — по MAC-адресу.

Выбор корня происходит сам собой. Сразу после включения каждый мост считает корнем себя и рассылает через все порты сообщения, в которых объявляет: «корень — я, расстояние до корня — 0». Получив от соседа сообщение с меньшим идентификатором корня, мост признаёт этот корень, перестаёт объявлять себя и далее передаёт сведения о лучшем корне. Через несколько интервалов обмена все мосты сходятся на одном корне — мосте с наименьшим идентификатором во всей сети.

Отсюда важное практическое следствие. Если приоритеты не настраивать, корнем станет мост с наименьшим MAC-адресом — как правило, самый старый коммутатор сети, который вполне может оказаться маломощным устройством в дальнем углу. Весь трафик между ветвями дерева пойдёт через него. Поэтому администратор всегда назначает корень явно, задавая наименьший приоритет коммутатору ядра или распределения (например, 4096) и следующий по величине — резервному корню (8192).

Стоимости путей, корневые и назначенные порты

Каждому порту приписана стоимость пути (англ. path cost), зависящая от скорости звена: чем быстрее звено, тем меньше стоимость. Расстояние моста до корня (англ. root path cost) — сумма стоимостей входных портов вдоль пути от корня. Стандарт рекомендует значения стоимости; в редакции 1998 года они были 16-битными, в редакции 2004 года стали 32-битными, потому что для скоростей выше 10 Гбит/с старой шкалы не хватало ².

Мост Linux по умолчанию вычисляет стоимость по старой шкале исходя из скорости, о которой сообщает драйвер интерфейса: виртуальный интерфейс veth объявляет скорость 10 Гбит/с, поэтому в лабораторной работе все порты получают стоимость 2. Стоимость любого порта можно задать вручную командой bridge link set dev t12 cost 100.

Когда корень определён, роли портов назначаются двумя правилами.

1. У каждого моста, кроме корня, ровно один корневой порт (англ. root port, RP) — порт с наименьшей стоимостью пути до корня. При равенстве стоимостей выбирается порт, ведущий к соседу с меньшим идентификатором моста, затем — порт с меньшим идентификатором порта.
2. В каждом сегменте ровно один назначенный порт (англ. designated port, DP) — порт того моста, который ближе всего к корню; при равенстве — моста с меньшим идентификатором. Назначенный порт отвечает за пересылку кадров из сегмента к корню и обратно. У корня все порты назначенные.

Порты, не ставшие ни корневыми, ни назначенными, блокируются. Рассмотрим топологию лабораторной работы на рисунке ниже.

Все три моста имеют приоритет 32768 (0x8000), поэтому корень выбирается по MAC-адресу: sw1 с адресом 02:00:00:00:05:01. Для sw2 и sw3 корневыми становятся порты прямых звеньев к корню (стоимость 2 против 4 через соседа). На сегменте t12 назначенный порт — у корня, так же и на t13. На сегменте t23 оба моста находятся на расстоянии 2 от корня, и назначенным становится порт моста с меньшим идентификатором — sw2. Порт sw3 на t23 не корневой и не назначенный, поэтому блокируется. Вывод команды bridge link на sw3 это подтверждает:

3: t13@...: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
4: t23@...: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state blocking priority 32 cost 2

Разберём более показательный пример с разными скоростями (стоимости по шкале 802.1D-2004). Четыре коммутатора: A с приоритетом 4096 и B, C, D с приоритетом по умолчанию. Звенья: A–B 10 Гбит/с (2000), B–C 10 Гбит/с (2000), A–C 1 Гбит/с (20 000), B–D 1 Гбит/с (20 000), C–D 1 Гбит/с (20 000). Корень — A, у него наименьший приоритет. Расстояния и роли вычисляются так.

Назначенные порты: на A–B и A–C — порты корня A; на B–C и B–D — порты B (расстояние 2000 меньше, чем у C и D); на C–D — порт C (4000 меньше 22 000). Блокируются порт C на звене A–C и порт D на звене C–D. Результат поучителен: прямое гигабитное звено между C и корнем не используется, потому что путь через два десятигигабитных звена «дешевле». Именно этого и добиваются стоимостями — дерево собирается из быстрых звеньев.

Сообщения BPDU

Мосты обмениваются блоками данных протокола моста (англ. Bridge Protocol Data Unit, BPDU). Конфигурационный BPDU передаётся в кадре IEEE 802.3 с полем длины вместо EtherType, на групповой адрес 01:80:C2:00:00:00, с заголовком LLC, в котором DSAP и SSAP равны 0x42 ². Адреса диапазона 01:80:C2:00:00:00–01:80:C2:00:00:0F зарезервированы стандартом: мосты, соответствующие 802.1D, такие кадры никогда не пересылают, поэтому BPDU доходит только до непосредственного соседа. Конфигурационный BPDU занимает 35 байт и содержит:

• идентификатор протокола (2 байта, 0x0000), версию (1 байт: 0 — STP, 2 — RSTP, 3 — MSTP) и тип (1 байт: 0x00 — конфигурационный, 0x80 — уведомление об изменении топологии, 0x02 — RST/MST BPDU);
• флаги (1 байт): изменение топологии (TC) и подтверждение изменения (TCA), в RSTP — также роль порта и флаги согласования;
• идентификатор корня (8 байт) и расстояние до корня (4 байта) — мнение отправителя о дереве;
• идентификатор моста-отправителя (8 байт) и идентификатор порта (2 байта);
• четыре таймера по 2 байта в единицах 1/256 секунды: возраст сообщения (англ. message age), максимальный возраст (англ. max age, 20 с), интервал приветствия (англ. hello time, 2 с), задержка пересылки (англ. forward delay, 15 с).

Корень рассылает BPDU каждые 2 секунды (hello time). Некорневой мост, получив BPDU на корневом порту, формирует собственные BPDU и рассылает их через назначенные порты, увеличив расстояние на стоимость своего корневого порта. Так сведения о корне расходятся по дереву волной от корня. Захват на звене t23 учебной топологии показывает BPDU, отправленный мостом sw2 через назначенный порт:

16:d8:2d:87:ad:74 > 01:80:c2:00:00:00, 802.3, length 38: LLC, dsap STP (0x42) Individual,
    ssap STP (0x42) Command, ctrl 0x03: STP 802.1d, Config, Flags [none],
    bridge-id 8000.02:00:00:00:05:02.8004, length 35
	message-age 1.61s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
	root-id 8000.02:00:00:00:05:01, root-pathcost 2

Читать его следует так: «отправитель — мост 8000.02:00:00:00:05:02 (sw2), порт 0x8004; корнем я считаю 8000.02:00:00:00:05:01 (sw1), моё расстояние до корня — 2». Мост sw3, получая на t23 это сообщение, сравнивает его с собственным: его расстояние до корня тоже 2, но идентификатор больше, поэтому сообщение sw2 лучше, и порт sw3 на t23 остаётся заблокированным. Заметим две детали. Адрес источника кадра — MAC-адрес порта, а не моста: идентификатор моста передаётся внутри BPDU. Идентификатор порта 0x8004 в Linux складывается из приоритета порта (по умолчанию 32, в старшей части) и номера порта 4; в нотации 802.1D-2004 тот же приоритет записывается как 128.

Протокол «мягкого состояния»: если мост в течение max age (20 с) не получает BPDU на корневом порту, он считает сведения устаревшими и начинает перевыборы. Когда отказывает не порт, а соседний мост, или звено обрывается без потери несущей, именно таймер max age определяет, сколько времени пройдёт до реакции.

Состояния портов и сходимость

Порт классического STP находится в одном из пяти состояний ².

Промежуточные состояния нужны для безопасности. Сведения об изменении топологии распространяются по сети не мгновенно, и если бы порт начинал пересылку, едва решив, что он назначенный, он мог бы на короткое время замкнуть петлю, пока соседний мост ещё не узнал, что его порт должен быть заблокирован. Поэтому порт сначала проводит forward delay (15 с) в состоянии прослушивания, ожидая, пока сведения разойдутся, затем ещё 15 с изучает адреса, не пересылая кадров, — чтобы при переходе в пересылку не рассылать лавиной кадры с ещё не изученными адресами. Итого порт, ставший активным, начинает пересылку через 30 с, а если до этого пришлось ждать истечения max age — через 50 с.

Тридцатисекундная пауза после подключения компьютера к порту коммутатора создаёт заметные неудобства: клиент DHCP может не дождаться ответа и остаться без адреса. Для портов, к которым подключены конечные узлы, производители ввели режим немедленного перехода в пересылку (у Cisco — PortFast); в стандарте RSTP это понятие закреплено как пограничный порт (англ. edge port).

Изменение топологии меняет и расположение хостов относительно мостов. Записи таблиц MAC-адресов, изученные до изменения, могут указывать в неверные порты, а время их старения по умолчанию — 300 с. Поэтому мост, обнаруживший изменение, отправляет к корню уведомление (англ. Topology Change Notification, TCN), а корень некоторое время рассылает BPDU с флагом TC. Получив такой BPDU, мост временно сокращает время старения записей до forward delay (15 с), и устаревшие записи быстро исчезают. В захвате лабораторной работы такой BPDU виден как Flags [Topology change].

Быстрое связующее дерево и множественные деревья

Сходимость за 30–50 с была приемлема в 1990-е годы, но не для сети, по которой идут голос и видео. Протокол быстрого связующего дерева (англ. Rapid Spanning Tree Protocol, RSTP) принят как IEEE 802.1w в 2001 году и в 2004 году включён в 802.1D, заменив классический STP ². Алгоритм выбора корня и стоимости остались прежними, а механизм перехода портов изменился.

RSTP различает больше ролей портов. Кроме корневого и назначенного, введены альтернативный порт (англ. alternate port) — запасной путь к корню, который немедленно становится корневым при отказе текущего корневого, — и резервный порт (англ. backup port) — запасное подключение к сегменту, где у моста уже есть назначенный порт. Состояний осталось три: отбрасывание (англ. discarding, объединившее disabled, blocking и listening), обучение и пересылка. Главное же отличие — механизм предложения и согласия (англ. proposal/agreement): назначенный порт на звене «точка — точка» не ждёт истечения таймеров, а предлагает соседу перейти в пересылку; сосед, временно заблокировав свои остальные некорневые порты, отвечает согласием, и звено переходит в пересылку за время обмена парой BPDU. Волна согласований проходит по дереву за доли секунды. Кроме того, BPDU в RSTP рассылает каждый мост сам каждые 2 с, и пропуск трёх подряд означает потерю соседа — реакция за 6 с вместо 20.

Классический и быстрый STP строят одно дерево на всю сеть, общее для всех VLAN. Это расточительно: звено, заблокированное для одной VLAN, могло бы нести трафик другой. Протокол множественных связующих деревьев (англ. Multiple Spanning Tree Protocol, MSTP), принятый как 802.1s и вошедший в 802.1Q, позволяет построить несколько экземпляров дерева (англ. MST instance) с разными корнями и отобразить на каждый группу VLAN ¹. Например, VLAN 10–19 используют дерево с корнем в коммутаторе распределения D1, а VLAN 20–29 — с корнем в D2, и оба вертикальных звена от коммутатора доступа заняты полезным трафиком. Производители выпускают и собственные варианты с отдельным деревом на каждую VLAN (Cisco PVST+, Rapid PVST+).

Модуль моста ядра Linux реализует только классический STP 802.1D; RSTP и MSTP поддерживаются демоном пространства пользователя mstpd ¹². Включение STP на мосту выполняется командой ip link set br0 type bridge stp_state 1, состояние портов показывает bridge link show, параметры моста — каталог /sys/class/net/br0/bridge/.

Защита связующего дерева

STP доверяет любому полученному BPDU. Компьютер или неуправляемый коммутатор, подключённый к порту доступа и отправляющий BPDU с приоритетом 0, станет корнем всей сети, и трафик между ветвями дерева пойдёт через порт пользователя. Это может быть и атакой, и ошибкой: принесённый из дома коммутатор с включённым STP и малым MAC-адресом. Для защиты коммутаторы предлагают несколько механизмов (названия — производителей, функции — общие).

• Защита от BPDU (англ. BPDU guard) — на порту, к которому должны подключаться только конечные узлы, получение любого BPDU немедленно отключает порт. Обычно включается вместе с режимом пограничного порта.
• Защита корня (англ. root guard) — на порту, ведущем вниз по иерархии, BPDU с лучшим корнем не принимается во внимание, и порт не может стать корневым; это не даёт подчинённому коммутатору захватить роль корня.
• Фильтрация BPDU (англ. BPDU filter) — порт не отправляет и не принимает BPDU; опасна, так как фактически отключает STP на порту.

В мосте Linux защите от BPDU соответствует флаг порта guard, защите корня — флаг root_block ⁹. Если в учебной топологии превратить хост h1 в мост с приоритетом 0, корнем всей сети станет h1, о чём свидетельствует root_id моста sw1, равный 0000.020000000001. После включения bridge link set dev p1 guard on порт p1 переходит в состояние disabled при первом же BPDU.

Агрегирование каналов

Задача и место среди механизмов канального уровня

Между коммутатором доступа и коммутатором распределения нередко требуется канал быстрее одного звена: например, 40 компьютеров с гигабитными адаптерами подключены к коммутатору, связанному с ядром одним гигабитным звеном. Можно заменить звено на десятигигабитное, но это требует нового оборудования. Можно проложить второе гигабитное звено — но STP немедленно заблокирует его как избыточное, и выигрыша не будет. Агрегирование каналов решает задачу иначе: несколько параллельных звеньев между двумя устройствами объединяются в одну логическую группу (англ. Link Aggregation Group, LAG), которая для моста, STP и протоколов верхних уровней является одним портом с одним MAC-адресом ³. Сбои отдельных звеньев группа переживает сама: трафик распределяется по оставшимся звеньям за доли секунды, без перестройки связующего дерева.

Механизм стандартизован в 2000 году как IEEE 802.3ad, в 2008 году перенесён в отдельный стандарт IEEE 802.1AX ³. Производители называют его по-разному: EtherChannel, port channel, trunk (ещё одно значение многозначного слова), bonding или teaming. Классическое агрегирование соединяет ровно два устройства; вариант, при котором один конец группы приходит на два разных коммутатора (англ. Multi-Chassis LAG, MLAG), требует согласования между этими коммутаторами и реализуется частными протоколами производителей.

Протокол LACP

Звенья группы можно объединить статически, настроив обе стороны вручную. Но тогда при ошибке кабельного подключения — например, одно звено группы попало в порт другого коммутатора — трафик будет уходить «в никуда». Протокол управления агрегированием каналов (англ. Link Aggregation Control Protocol, LACP) проверяет, что звенья действительно соединяют одни и те же два устройства и что обе стороны согласны их объединить ³. Устройства обмениваются сообщениями LACPDU: кадрами с EtherType 0x8809 (так называемые «медленные протоколы», англ. Slow Protocols) на групповой адрес 01:80:C2:00:00:02. Каждое сообщение содержит сведения о себе (англ. actor) и о том, что сторона знает о партнёре (англ. partner): системный идентификатор (приоритет и MAC-адрес), ключ — номер группы, к которой порт может быть отнесён, — номер и приоритет порта и байт флагов состояния.

0a:38:c2:0e:dc:73 > 01:80:c2:00:00:02, ethertype Slow Protocols (0x8809), length 124: LACPv1, length 110
	Actor Information TLV (0x01), length 20
	  System 0a:38:c2:0e:dc:73, System Priority 65535, Key 15, Port 1, Port Priority 255
	  State Flags [Activity, Timeout, Aggregation, Synchronization, Collecting, Distributing]
	Partner Information TLV (0x02), length 20
	  System 6e:59:e3:e4:e2:1e, System Priority 65535, Key 15, Port 1, Port Priority 255
	  State Flags [Activity, Timeout, Aggregation, Synchronization, Collecting, Distributing]

Звено включается в группу, когда каждая сторона увидела в сообщениях партнёра себя саму и согласие на агрегирование; флаги Collecting и Distributing в выводе выше означают, что звено принимает и передаёт трафик группы. Флаг Activity обозначает активный режим (сторона сама начинает обмен; в пассивном режиме она только отвечает), флаг Timeout — короткий интервал: сообщения раз в секунду вместо раза в 30 с, а партнёр считается потерянным после трёх пропущенных сообщений, то есть через 3 с вместо 90 с ³. В Linux агрегирование реализует драйвер bonding; режим LACP называется 802.3ad, короткий интервал включается параметром lacp_rate fast, а состояние группы показывает файл /proc/net/bonding/bond0 ⁸. Кроме режима 802.3ad драйвер поддерживает режимы, не требующие поддержки со стороны коммутатора, например active-backup: трафик идёт через одно звено, второе ждёт отказа первого.

Распределение кадров по звеньям

Агрегированный канал из двух звеньев по 1 Гбит/с не является звеном 2 Гбит/с. Кадр целиком передаётся по одному звену, и вопрос в том, по какому. Простейший способ — по очереди (англ. round robin) — нарушил бы порядок кадров: звенья могут иметь разные очереди и задержки, и кадры одного соединения приходили бы переставленными. Канальный уровень обязан сохранять порядок кадров внутри «разговора» ³, поэтому распределение выполняется по потокам. От каждого кадра вычисляется хеш-функция полей заголовка — MAC-адресов, IP-адресов, портов транспортного уровня, — и номер звена равен остатку от деления хеша на число звеньев. Все кадры одного потока имеют одинаковые поля, а значит, идут по одному звену и не переупорядочиваются.

Следствия этого правила важно понимать. Одно соединение TCP никогда не получит скорость больше, чем у одного звена. Распределение неравномерно: если потоков мало, они могут случайно оказаться на одном звене, а другое будет простаивать. И распределение зависит от того, какие поля входят в хеш. Драйвер bonding по умолчанию (xmit_hash_policy layer2) хеширует только MAC-адреса ⁸: весь трафик между двумя узлами, например между двумя маршрутизаторами, у которых MAC-адреса одни и те же, идёт по одному звену. Политика layer3+4 добавляет IP-адреса и порты, и разные соединения между теми же узлами распределяются по звеньям. Эксперимент лабораторной работы отправляет восемь UDP-потоков, отличающихся только портом отправителя:

поток          порты      e1      e2
    0   50000->40000     201       0
    1   50001->40000     200       0
    2   50002->40000       0     200
    3   50003->40000       1     201
    4   50004->40000     200       0
    5   50005->40000     200       0
    6   50006->40000       0     200
    7   50007->40000       0     200

Каждый поток целиком ушёл через одно звено (единичные кадры на другом звене — служебные ARP и LACPDU), и потоки разделились четыре на четыре. При политике layer2 те же потоки все до одного уходят через звено e1. Хеширование выполняет передающая сторона, и каждая сторона выбирает звено для своего направления независимо, поэтому прямой и обратный трафик одного соединения могут идти по разным звеньям.

Проектирование кампусной сети и безопасность канального уровня

Иерархическая модель

Механизмы этой темы складываются в типовую архитектуру сети здания или группы зданий — кампусной сети (англ. campus network). Её принято строить по трёхуровневой иерархической модели ⁶⁷.

• Уровень доступа (англ. access layer) — коммутаторы в коммутационных шкафах этажей, к которым подключаются компьютеры, телефоны, точки доступа. Здесь порты доступа распределяются по VLAN, включены пограничные порты и защита от BPDU, работают механизмы безопасности порта.
• Уровень распределения (англ. distribution layer) — пара коммутаторов на здание или крыло, к которым каждый коммутатор доступа подключён двумя магистральными звеньями (часто — агрегированными каналами). Здесь находится корень связующего дерева, здесь же коммутаторы третьего уровня маршрутизируют трафик между VLAN, и здесь проходит граница широковещательных доменов.
• Уровень ядра (англ. core layer) — высокоскоростная маршрутизируемая магистраль, связывающая блоки распределения, серверную и выход в Интернет. От ядра требуется скорость и устойчивость, а не сложные функции.

Смысл иерархии — в ограничении области действия механизмов канального уровня. Каждый блок «доступ — распределение» — небольшой домен с понятной топологией, корнем STP и набором VLAN; между блоками работает маршрутизация с её TTL, суммаризацией адресов (тема 6) и быстрой сходимостью протоколов динамической маршрутизации (тема 9). Петля или шторм в одном блоке не выходят за его пределы. В небольших сетях уровни распределения и ядра объединяют (англ. collapsed core), и для офиса «Северного узла» это обычное решение: коммутаторы этажей подключаются к паре центральных коммутаторов третьего уровня, которые маршрутизируют между VLAN отделов, серверной и гостевой сети.

Современная тенденция — выносить маршрутизацию всё ближе к доступу и уменьшать область действия STP вплоть до отдельного коммутатора: если каждое звено вверх от коммутатора доступа маршрутизируемое, петель канального уровня нет вовсе, а резервирование обеспечивает маршрутизация с равноценными путями. Плата — VLAN не может простираться за пределы одного коммутатора доступа.

Атаки на канальный уровень

Канальный уровень проектировался в предположении, что все подключённые к сети устройства доброжелательны. Ни таблица MAC-адресов, ни BPDU, ни ARP не содержат никакой проверки подлинности, поэтому пользователь, получивший доступ к порту, имеет широкие возможности. Рассмотрим основные атаки кратко; подробно методы защиты обсуждаются в теме 18.

Переполнение таблицы MAC-адресов (англ. MAC flooding). Таблица коммутатора имеет ограниченный размер — от нескольких тысяч до сотен тысяч записей. Атакующий отправляет кадры с огромным количеством случайных адресов источника, таблица заполняется ими, и для настоящих адресов места не остаётся. Кадры к неизученным адресам коммутатор рассылает лавиной во все порты (тема 4), и атакующий получает возможность видеть чужой трафик. Защита — ограничение числа адресов, изучаемых на порту (англ. port security); в мосте Linux можно отключить обучение на порту (bridge link set dev p1 learning off) и задать адреса статически.

Перескок между VLAN (англ. VLAN hopping) существует в двух вариантах. При подмене коммутатора (англ. switch spoofing) атакующий имитирует коммутатор, договариваясь с портом о переходе в магистральный режим с помощью частного протокола автоматического согласования (у Cisco — DTP), и получает доступ ко всем VLAN. Защита — явная настройка портов доступа и отключение автоматического согласования. При двойном тегировании (англ. double tagging) атакующий, находящийся в native VLAN магистрали, отправляет кадр с двумя тегами: внешним — с номером native VLAN, внутренним — с номером VLAN жертвы. Первый коммутатор снимает внешний тег и, поскольку кадр принадлежит native VLAN, отправляет его по магистрали без тега — но в кадре остаётся внутренний тег, и второй коммутатор помещает кадр в VLAN жертвы. Атака односторонняя: ответ к атакующему не вернётся, но её достаточно, например, для отправки пакета UDP. Защита — не размещать пользовательские порты в native VLAN, использовать в качестве native неиспользуемую VLAN или тегировать на магистрали все VLAN.

Подмена ответов DHCP и ARP. Пользователь может запустить собственный сервер DHCP и раздавать клиентам свой адрес в качестве шлюза или рассылать поддельные ARP-ответы, перенаправляя трафик соседей через себя (атака «человек посередине», ARP-спуфинг рассматривается в теме 7). Защита на коммутаторе — отслеживание DHCP (англ. DHCP snooping): коммутатор пропускает ответы DHCP только с доверенных портов, к которым подключены настоящие серверы, и запоминает, какой адрес выдан на каком порту. На основе этой таблицы динамическая проверка ARP (англ. Dynamic ARP Inspection) отбрасывает ARP-ответы, не соответствующие выданным адресам.

Контроль доступа к порту

Все перечисленные механизмы ограничивают, что может сделать подключённое устройство, но не отвечают на вопрос, кто подключился. Его решает стандарт IEEE 802.1X — управление доступом на основе портов (англ. Port-Based Network Access Control) ¹¹. Пока устройство не прошло аутентификацию, порт коммутатора пропускает только кадры протокола EAP поверх LAN (англ. EAPOL, EtherType 0x888E). Коммутатор в роли аутентификатора (англ. authenticator) пересылает обмен EAP между устройством-просителем (англ. supplicant) и сервером аутентификации, обычно RADIUS, и открывает порт только после успешной проверки сертификата или пароля. Сервер может вместе с разрешением указать номер VLAN, и порт будет динамически помещён в VLAN отдела, к которому относится пользователь, или в гостевую VLAN. Тот же механизм лежит в основе корпоративного режима Wi-Fi WPA2/WPA3-Enterprise (тема 20).

Итоги темы

Плоская сеть коммутаторов, удобная своей беспредельной простотой, плохо масштабируется: широковещательный трафик растёт квадратично с числом узлов, все узлы находятся в одном сегменте безопасности, а принадлежность к сегменту определяется прокладкой кабелей. Виртуальные локальные сети IEEE 802.1Q разделяют физическую сеть на независимые широковещательные домены. Кадр относится к VLAN по порту доступа, на котором он принят, а между коммутаторами несёт 4-байтный тег с 12-битным номером VLAN. Порт определяется тремя параметрами — разрешёнными VLAN, PVID и списком VLAN без тега на выходе, — и большинство ошибок настройки, в том числе опасное несовпадение native VLAN, сводятся к рассогласованию этих параметров на двух концах магистрали.

Резервные связи в сети мостов образуют петли, а прозрачный мост, у кадров которого нет счётчика переходов, превращает петлю в широковещательный шторм с нестабильностью таблиц MAC-адресов. Протокол связующего дерева устраняет петли распределённо: мосты выбирают корень с наименьшим идентификатором, каждый мост — корневой порт с наименьшей стоимостью пути до корня, каждый сегмент — назначенный порт, а прочие порты блокируются. Классический STP медлителен — 30–50 секунд на сходимость, — и в современных сетях используется RSTP с механизмом предложения и согласия и MSTP с отдельными деревьями для групп VLAN. Корень дерева назначают явно, а порты доступа защищают от чужих BPDU.

Агрегирование каналов IEEE 802.1AX с протоколом LACP объединяет параллельные звенья в один логический порт, который не блокируется STP и переживает отказ отдельных звеньев. Кадры распределяются по звеньям хешированием полей заголовка, поэтому порядок кадров внутри потока сохраняется, но отдельный поток не может превысить скорость одного звена, а равномерность распределения зависит от политики хеширования и числа потоков.

Механизмы канального уровня складываются в иерархическую кампусную сеть, где широковещательные домены и связующее дерево ограничены блоками «доступ — распределение», а между блоками работает маршрутизация. Граница широковещательного домена совпадает с границей IP-подсети, и следующий шаг — понять, как устроены сами IP-адреса, как разбить адресное пространство организации на подсети для отдельных VLAN и как описать их компактно. Этому посвящена тема 6.

Литература

1. IEEE Standard for Local and Metropolitan Area Networks — Bridges and Bridged Networks. — IEEE Std 802.1Q-2022, IEEE, 2022.
2. IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges. — IEEE Std 802.1D-2004, IEEE, 2004.
3. IEEE Standard for Local and Metropolitan Area Networks — Link Aggregation. — IEEE Std 802.1AX-2020, IEEE, 2020.
4. Perlman R. An Algorithm for Distributed Computation of a Spanning Tree in an Extended LAN. — ACM SIGCOMM Computer Communication Review, 1985, Vol. 15, No. 4, P. 44–53.
5. Perlman R. Interconnections: Bridges, Routers, Switches, and Internetworking Protocols. 2nd ed. — Addison-Wesley, 1999.
6. Олифер В. Г., Олифер Н. А. Компьютерные сети. Принципы, технологии, протоколы. 5-е изд. — СПб.: Питер, 2016.
7. Kurose J. F., Ross K. W. Computer Networking: A Top-Down Approach. 8th ed. — Pearson, 2021.
8. The Linux Kernel Documentation. Linux Ethernet Bonding Driver HOWTO. — 2025. https://docs.kernel.org/networking/bonding.html
9. Linux manual page. bridge(8) — show / manipulate bridge addresses and devices. — 2025. https://man7.org/linux/man-pages/man8/bridge.8.html
10. Perlman R., Eastlake D., Dutt D., Gai S., Ghanwani A. Routing Bridges (RBridges): Base Protocol Specification. — RFC 6325, IETF, 2011. https://www.rfc-editor.org/rfc/rfc6325
11. IEEE Standard for Local and Metropolitan Area Networks — Port-Based Network Access Control. — IEEE Std 802.1X-2020, IEEE, 2020.
12. The Linux Kernel Documentation. Ethernet Bridging. — 2025. https://docs.kernel.org/networking/bridge.html

Дополнительные материалы

Вопросы для самопроверки

1. Почему нагрузка от широковещательного трафика на сеть растёт квадратично с числом узлов широковещательного домена? Приведите численный пример.
2. Какие поля содержит тег IEEE 802.1Q, сколько бит занимает каждое и какие значения VID зарезервированы?
3. Кадр без тега пришёл на магистральный порт моста Linux с PVID 1. В какую VLAN он попадёт? А если на порту нет VLAN 1?
4. Чем схема «маршрутизатор на палочке» отличается от коммутатора третьего уровня? Какое звено становится узким местом в первой схеме?
5. Зачем провайдеру двойное тегирование 802.1ad и чем внешний тег отличается от внутреннего?
6. Опишите по шагам, как один ARP-запрос в кольце из трёх коммутаторов порождает шторм. Почему шторм не прекращается сам?
7. Как устроен идентификатор моста в редакции 802.1D-2004 и почему приоритет задаётся кратно 4096?
8. Мосты A, B, C имеют одинаковый приоритет; MAC-адрес A меньше, чем у B и C. Звенья A–B и A–C — 1 Гбит/с, B–C — 10 Гбит/с. Какой порт будет заблокирован при стоимостях 802.1D-2004?
9. Какие сведения содержит конфигурационный BPDU и почему коммутаторы не пересылают кадры на адрес 01:80:C2:00:00:00?
10. Почему порт классического STP проходит состояния listening и learning, а не переходит в forwarding сразу? Из чего складываются 50 с сходимости в худшем случае?
11. Что такое альтернативный порт RSTP и как механизм предложения и согласия ускоряет переход в пересылку?
12. Какую задачу решает MSTP, которую не решают STP и RSTP?
13. Чем защита от BPDU отличается от защиты корня? На каких портах применяется каждая?
14. Почему агрегированный канал из четырёх звеньев по 1 Гбит/с не передаёт одно соединение TCP со скоростью 4 Гбит/с?
15. Как работает атака двойным тегированием и какая настройка магистрали делает её невозможной?

Глоссарий темы

Шпаргалка по инструментам

VLAN на мосту Linux:

ip link add br0 type bridge vlan_filtering 1        # мост с фильтрацией VLAN
ip link set br0 type bridge vlan_filtering 1        # включить на существующем
bridge vlan show                                    # VLAN на всех портах
bridge vlan add dev p1 vid 10 pvid untagged         # порт доступа VLAN 10
bridge vlan del dev p1 vid 1                        # убрать VLAN по умолчанию
bridge vlan add dev t12 vid 10                      # VLAN 10 с тегом на магистрали
bridge vlan add dev t12 vid 100-110                 # диапазон VLAN
bridge vlan add dev br0 vid 10 self                 # VLAN на самом мосту (для управления)
bridge fdb show br br0                              # таблица MAC-адресов по VLAN
ip link add link eth0 name eth0.10 type vlan id 10  # подынтерфейс VLAN 10 на хосте

Связующее дерево:

ip link set br0 type bridge stp_state 1             # включить STP
ip link set br0 type bridge priority 4096           # приоритет моста
ip link set br0 type bridge forward_delay 1500      # задержка пересылки, 1/100 с
bridge link show                                    # состояния и стоимости портов
bridge link set dev p1 cost 100                     # стоимость порта
bridge link set dev p1 priority 16                  # приоритет порта (0–63)
bridge link set dev p1 guard on                     # защита от BPDU
bridge link set dev p1 root_block on                # защита корня
cat /sys/class/net/br0/bridge/root_id               # корень с точки зрения моста
ip -d link show br0                                 # все параметры моста

Агрегирование:

ip link add bond0 type bond mode 802.3ad lacp_rate fast xmit_hash_policy layer3+4 miimon 100
ip link set e1 master bond0                         # звено в агрегат (интерфейс DOWN)
cat /proc/net/bonding/bond0                         # состояние агрегата и LACP

Захват:

Что почитать и посмотреть

• Perlman R. An Algorithm for Distributed Computation of a Spanning Tree in an Extended LAN. — ACM SIGCOMM CCR, 1985. Исходная статья с алгоритмом связующего дерева: короткая, понятная и показывающая, из каких требований (прозрачность, отсутствие настройки) возник алгоритм.
• Perlman R. Interconnections. 2nd ed. — Addison-Wesley, 1999. Главы о прозрачных мостах и связующем дереве, написанные автором алгоритма; в конце книги — сравнение мостов и маршрутизаторов, проясняющее, почему петли в L2 так опасны.
• Документация Linux «Ethernet Bridging»: https://docs.kernel.org/networking/bridge.html — описание моста ядра, STP, фильтрации VLAN и интерфейсов настройки.
• Linux Ethernet Bonding Driver HOWTO: https://docs.kernel.org/networking/bonding.html — подробное описание режимов агрегирования, политик хеширования (с формулами) и типичных ошибок; полезно и как введение в агрегирование вообще.
• Страница руководства bridge(8): https://man7.org/linux/man-pages/man8/bridge.8.html — все флаги портов моста (guard, root_block, learning, flood) и подкоманды vlan, fdb.
• Wireshark Wiki, страницы о VLAN и STP: https://wiki.wireshark.org/VLAN и https://wiki.wireshark.org/STP — как Wireshark разбирает теги и BPDU, примеры файлов захвата.
• Статья «Spanning Tree Protocol» в англоязычной Википедии: https://en.wikipedia.org/wiki/Spanning_Tree_Protocol — хороший обзор вариантов STP, RSTP, MSTP и производительских расширений с таблицами стоимостей.
• Cisco. Understanding Rapid Spanning Tree Protocol (802.1w): https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24062-146.html — классическая подробная статья о ролях портов и механизме предложения и согласия.
• RFC 6325 (TRILL): https://www.rfc-editor.org/rfc/rfc6325 — пример того, как в канальный уровень вносят маршрутизацию и счётчик переходов; разделы 1–2 читаются как продолжение темы.

Углубление (по желанию)

«Algorhyme»: стихотворение о связующем дереве

Радия Перлман, придумав алгоритм связующего дерева, написала о нём стихотворение «Algorhyme», которое приводится в её книге и стало частью профессионального фольклора: «I think that I shall never see / A graph more lovely than a tree…» — парафраз известного стихотворения Джойса Килмера «Trees». В последних строках сформулирована вся суть алгоритма: сначала выбирается корень, затем строится дерево кратчайших путей от него. Позднее, предлагая протокол TRILL, Перлман сочинила ответ «Algorhyme v2», где дерево заменено на маршрутизацию по кратчайшим путям: «I hope that we shall one day see / A graph more lovely than a tree». Это хорошая иллюстрация эволюции взглядов: связующее дерево было компромиссом ради прозрачности мостов, и автор алгоритма сама предложила от него уйти.

Почему 4094, а не больше

Двенадцать бит на номер VLAN казались в 1990-е годы огромным запасом: редкое предприятие нуждалось больше чем в сотне сегментов. Ограничение стало ощутимым у провайдеров и в облачных центрах обработки данных, где каждому клиенту нужны свои изолированные сети. Двойное тегирование 802.1ad решает задачу для провайдеров Ethernet, но вынуждает весь путь кадра оставаться коммутируемым — с STP и широковещательными доменами на всю сеть провайдера. Облачные платформы пошли другим путём: инкапсуляция VXLAN (RFC 7348) помещает кадр Ethernet в пакет UDP с 24-битным идентификатором сегмента (около 16 млн сетей), и между стойками работает обычная IP-маршрутизация. Канальный уровень при этом сохраняется только как виртуальная абстракция для гостевых машин (тема 21).

Шторм в реальной сети

Широковещательный шторм — одна из немногих неисправностей, способных за секунды вывести из строя всю сеть здания. Частая причина — не ошибка проектирования, а пользователь: кабель, которым соединили два порта одного настенного разъёма или настольного неуправляемого коммутатора, или IP-телефон с встроенным коммутатором, подключённый двумя кабелями. Поэтому даже в сетях, где резервных звеньев нет, STP на коммутаторах доступа не выключают, а дополнительно включают ограничение широковещательного трафика на порту (англ. storm control) — коммутатор отбрасывает широковещательные кадры сверх заданной доли полосы. Для диагностики уже начавшегося шторма служат счётчики портов: широковещательные кадры на всех портах растут одновременно и синхронно, а в журнале коммутатора появляются сообщения о перемещении MAC-адресов между портами.

Лабораторная работа 5. VLAN и связующее дерево на мосту Linux

• Раздел курса: тема 5 «Виртуальные локальные сети, связующее дерево и агрегирование каналов»

Введение

В лабораторной работе 4 программный мост Linux был изучен как обучающийся коммутатор: наблюдалось заполнение таблицы MAC-адресов, лавинную рассылку и широковещательные кадры. Настоящая работа переходит от одного коммутатора к сети коммутаторов и воспроизводит три механизма темы 5. Сначала одна физическая сеть делится на две VLAN, и по захвату трафика проверяется, что кадры несут тег 802.1Q и что изоляция обеспечивается канальным уровнем, а не IP-адресами. Затем в сеть добавляется резервное звено, и наблюдается, во что превращается один широковещательный кадр в кольце без защиты. Наконец, включается протокол связующего дерева, и по выводам команд и захваченным BPDU восстанавливается ход его работы: выбор корня, роли портов, сходимость после отказа.

Работа состоит из базовой и продвинутой частей. Базовая часть (части 1–5) составляет основу работы. Продвинутая часть (часть 6: агрегирование каналов и программный разбор BPDU) выполняется по желанию.

Цель работы

Освоить настройку виртуальных локальных сетей и протокола связующего дерева на программном мосте Linux и научиться объяснять их работу по выводам команд и захвату трафика.

После выполнения работы можно будет:

• настроить порты доступа и магистральный порт моста Linux и проверить изоляцию VLAN;
• найти в захвате трафика тег 802.1Q и расшифровать его поля по шестнадцатеричному дампу;
• обнаружить и устранить несовпадение native VLAN на концах магистрали по симптомам и выводу bridge vlan show;
• объяснить механизм широковещательного шторма и нестабильности таблицы MAC-адресов по результатам измерения;
• предсказать корень связующего дерева и роли портов по идентификаторам мостов и стоимостям и проверить предсказание;
• измерить время сходимости STP после отказа звена и объяснить его значениями таймеров;
• настроить агрегированный канал LACP и объяснить распределение потоков по звеньям (продвинутая часть).

Теоретический минимум

Теоретический материал изложен в теме 5: разделы «Виртуальные локальные сети IEEE 802.1Q», «Петли и широковещательный шторм», «Протокол связующего дерева» и «Агрегирование каналов». Ниже — сжатая справка.

Учебная топология. Каждый коммутатор — отдельное сетевое пространство имён с мостом br0, у которого включена фильтрация VLAN (vlan_filtering 1). Хосты — пространства имён с интерфейсом eth0. Все хосты намеренно находятся в одной IP-подсети.

 h1 10.5.0.1   h2 10.5.0.2              h3 10.5.0.3   h4 10.5.0.4
      | p1          | p2                     | p3          | p4
  +------- sw1 (br0) -------+ t12 ---- t12 +------- sw2 (br0) -------+
               | t13 (после loop.sh)                 | t23
               +--------------- sw3 (br0) -----------+

Команды работы.

Полезные фильтры. Для tcpdump: vlan (кадры с тегом), vlan 10, stp, arp; ключ -e выводит заголовок канального уровня, -XX — шестнадцатеричный дамп всего кадра. Для Wireshark: vlan.id == 10, stp, stp.flags.tc == 1, lacp.

Перечень оснащения

• Ubuntu 24.04 (физическая или виртуальная машина либо WSL2) с пакетами, установленными в лабораторной работе 1: iproute2, iputils-ping, tcpdump, wireshark, python3.
• Архив окружения lr-env: скрипты up.sh, vlans.sh, break-native.sh, loop.sh, storm.sh, up-lag.sh, down.sh, программы flows.py и bpdu_decode.py, файл README.md с описанием.
• Права администратора (sudo).
• Два-три окна терминала: в одном выполняются команды, в другом работает захват.

Порядок выполнения работы

Распакуйте архив и перейдите в каталог окружения:

unzip lr-env.zip -d ~/lab05 && cd ~/lab05/lr-env && chmod +x *.sh
sudo ./up.sh
ns() { sudo ip netns exec "$@"; }   # сокращение для команд в пространствах имён

Функция ns действует в текущем окне терминала; определите её в каждом окне. Топология разбирается командой sudo ./down.sh; после неё всё можно начать заново с up.sh. Скрипт vlans.sh восстанавливает эталонную настройку VLAN части 2, если конфигурация оказалась испорчена.

Файлы захвата записывайте в /tmp (-w /tmp/имя.pcap): tcpdump, запущенный через sudo, после старта работает от имени пользователя tcpdump и в домашний каталог записать не может. Открыть файл в Wireshark можно командой wireshark /tmp/имя.pcap.

В каждой части задание начинается с предсказания. Записывайте предсказание в журнал до эксперимента, а после эксперимента — совпало ли оно и если нет, почему.

Часть 1. Плоская сеть из двух коммутаторов

Задание

1. Убедитесь, что топология поднята: ip netns list должно показать sw1, sw2, h1–h4. Выведите bridge -n sw1 vlan show. Какой PVID у портов и почему все порты в одной VLAN?

2. Предскажите: какие из шести пар хостов связаны? Проверьте ns h1 ping -c 2 10.5.0.4 и остальные пары (достаточно пар с участием h1 и h2).

3. Запустите во втором окне захват на магистральном звене со стороны sw2:

   ns sw2 tcpdump -i t12 -e -nn
   

   Очистите кеш ARP у h1 (ns h1 ip neigh flush all) и выполните ns h1 ping -c 1 10.5.0.3. Есть ли в кадрах на звене t12 тег 802.1Q?

4. Выведите таблицу MAC-адресов bridge -n sw2 fdb show br br0 | grep -v permanent. Через какой порт sw2 «видит» хост h1 и в какой VLAN?

Что должно получиться

Таблица связности шести пар хостов, фрагмент захвата с ARP-запросом и эхо-запросом, строка таблицы MAC-адресов sw2 для h1 с пояснением. Ответ на вопрос: какой широковещательный домен образуют четыре хоста и какой кадр из захвата это доказывает.

Часть 2. Две VLAN, порты доступа и магистраль

Задание

1. Требуется разделить сеть: h1 и h3 — VLAN 10 (отдел продаж), h2 и h4 — VLAN 20 (бухгалтерия). Звено t12 должно переносить обе VLAN с тегом, VLAN 1 на нём оставить без тега. Предскажите и запишите в журнал таблицу связности после настройки.

2. Настройте порт доступа p1 коммутатора sw1:

   sudo bridge -n sw1 vlan del dev p1 vid 1
   sudo bridge -n sw1 vlan add dev p1 vid 10 pvid untagged
   

   Аналогично настройте p2 (VLAN 20) в sw1 и p3, p4 в sw2. Затем разрешите VLAN 10 и 20 на магистральном порту обоих коммутаторов:

   sudo bridge -n sw1 vlan add dev t12 vid 10
   sudo bridge -n sw1 vlan add dev t12 vid 20
   

   и то же для sw2. Сравните bridge -n sw1 vlan show с выводом из теоретической части. Объясните каждый флаг в строке порта p1.

3. Проверьте связность всех пар. Хосты h1 и h4 находятся в одной IP-подсети: почему эхо-запрос между ними не проходит? Что в этот момент показывает ns h1 ip neigh show 10.5.0.4?

4. Запустите захват ns sw2 tcpdump -i t12 -e -nn -XX vlan и выполните ping от h1 к h3 и от h2 к h4. Найдите в шестнадцатеричном дампе одного кадра байты TPID и TCI, переведите TCI в двоичную запись и выделите PCP, DEI и VID. Какова длина кадра с тегом и чем она отличается от длины того же кадра в части 1?

5. Запустите одновременно захват на порту доступа ns sw2 tcpdump -i p3 -e -nn. Есть ли тег в кадрах на этом порту? Объясните, какой флаг конфигурации за это отвечает.

6. Таблица MAC-адресов теперь ведётся по VLAN. Выведите bridge -n sw1 fdb show br br0 | grep -v permanent и объясните колонку vlan.

7. Эксперимент «забытая VLAN». Удалите VLAN 20 с магистрали только на стороне sw2 (sudo bridge -n sw2 vlan del dev t12 vid 20). Предскажите, какие пары потеряют связь, проверьте и верните настройку.

Что должно получиться

Вывод bridge vlan show для обоих коммутаторов, таблица связности «предсказано — получено», разобранный по битам тег одного кадра, сравнение длин кадров, ответ на вопрос о связи h1 и h4 с выводом ip neigh, результат эксперимента с забытой VLAN.

Часть 3. Найти ошибку: магистраль после правки коллеги

Задание

1. Убедитесь, что настройка части 2 работает (при необходимости выполните sudo ./vlans.sh). Затем выполните sudo ./break-native.sh. Не читайте этот скрипт до завершения части.
2. Составьте таблицу связности всех пар хостов. Какая пара связана, хотя связана быть не должна? Какие пары потеряли связь?
3. Найдите причину по захвату на звене t12 (в каких кадрах есть тег, в каких нет) и по выводу bridge vlan show dev t12 на обоих коммутаторах. Сформулируйте её в терминах темы 5.
4. Проследите путь эхо-запроса от h1 к h4: в какой VLAN кадр находится на каждом участке, где теряет тег и почему оказывается в чужой VLAN?
5. Исправьте конфигурацию командами bridge vlan, не используя vlans.sh, и проверьте связность.

Что должно получиться

Таблица симптомов, фрагмент захвата и вывод bridge vlan show, обосновывающие диагноз, описание пути кадра h1 → h4 по участкам, команды исправления. Ответ на вопрос: почему ни один из коммутаторов не сообщил об ошибке и какую опасность для безопасности представляет такая неисправность.

Часть 4. Петля и широковещательный шторм

Задание

1. Выполните sudo ./loop.sh. Скрипт добавляет коммутатор sw3 и звенья t13, t23, но оставляет порт t13 в sw1 выключенным, поэтому петли пока нет. Нарисуйте в журнале работы получившуюся топологию.

   Не включайте порт t13 в sw1 вручную, пока на мостах выключен STP. Для эксперимента используйте только storm.sh: он замыкает кольцо на заданное время и гарантированно размыкает его даже при прерывании.

2. Предскажите, что произойдёт с одним широковещательным кадром, если кольцо замкнуть: сколько копий возникнет, будут ли они размножаться, исчезнут ли сами. Сколько кадров, по вашей оценке, примет порт t12 коммутатора sw1 за две секунды?

3. Выполните sudo ./storm.sh (по умолчанию кольцо замкнуто 2 с). Скрипт с h1 отправляет один эхо-запрос на несуществующий адрес 10.5.0.99, отчего h1 рассылает один ARP-запрос, и выводит число кадров, принятых портом t12, а также положение MAC-адреса h1 в таблицах трёх коммутаторов. Повторите с STORM_SECONDS=1 и STORM_SECONDS=4 и постройте зависимость числа кадров от длительности.

4. Объясните по выводу скрипта, почему sw1 считает, что h1 находится за портом t12, хотя h1 подключён к порту p1. Как долго будет действовать эта ошибочная запись, если h1 больше ничего не отправит? (Подсказка: ip netns exec sw1 cat /sys/class/net/br0/bridge/ageing_time, значение в сотых долях секунды.)

5. Объясните, почему число кадров растёт линейно, а не экспоненциально, и в какой топологии рост был бы экспоненциальным.

Что должно получиться

Схема кольца, предсказание и результаты трёх запусков таблицей, объяснение нестабильности таблицы MAC-адресов, ответы на вопросы пп. 4–5.

Часть 5. Протокол связующего дерева

Задание

1. Убедитесь, что кольцо разомкнуто (ip -n sw1 link show t13 — состояние DOWN). Предскажите по MAC-адресам мостов и стоимостям портов (выведите bridge -n sw1 link show), какой мост станет корнем, какие порты будут корневыми, назначенными и какой порт будет заблокирован. Нарисуйте предсказанное дерево.

2. Запустите в отдельном окне захват BPDU на звене t23: ns sw2 tcpdump -i t23 -e -nn -v stp -w /tmp/bpdu.pcap (без -w — для наблюдения на экране). Включите STP на всех мостах и замкните кольцо:

   for s in sw1 sw2 sw3; do sudo ip -n $s link set br0 type bridge stp_state 1; done
   sudo ip -n sw1 link set t13 up
   

3. В течение 40 с каждые 5 с выводите состояния портов: bridge -n sw3 link show. Запишите, в какие моменты порты проходили состояния listening, learning, forwarding, blocking, и сопоставьте интервалы с параметром forward_delay (cat /sys/class/net/br0/bridge/forward_delay внутри пространства sw3, значение в сотых долях секунды).

4. Проверьте предсказание п. 1: выведите root_id, root_port и root_path_cost моста sw3 из /sys/class/net/br0/bridge/. Найдите в захвате BPDU от sw2 и sw3 и прочитайте поля root-id, root-pathcost, bridge-id. Почему порт sw3 на звене t23 заблокирован, а порт sw2 на том же звене — нет?

5. Проверьте, что петли нет: выполните ns h1 ping -c 3 10.5.0.99 и убедитесь по счётчикам ip -n sw1 -s link show t12, что шторма не возникло.

6. Перенос корня. Требуется, чтобы корнем был sw3. Задайте ему приоритет 4096 (sudo ip -n sw3 link set br0 type bridge priority 4096). Предскажите новое дерево, подождите сходимости и проверьте. Какой порт заблокирован теперь?

7. Измерение сходимости. Верните sw3 приоритет 32768 и дождитесь сходимости. Запустите ns h1 ping -D -i 0.5 -W 1 -c 150 10.5.0.3 и через несколько секунд в другом окне отключите звено sudo ip -n sw1 link set t12 down. По меткам времени найдите длительность перерыва связи. Предскажите её до эксперимента. Объясните результат через таймеры max age и forward delay: какое событие ожидал sw3, прежде чем начать переводить свой порт t23 в пересылку? Для сравнения на одном из запусков уменьшите таймеры на всех мостах: forward_delay 400 max_age 600 (значения в сотых долях секунды).

8. Сломать и починить: захват корня. Включите звено t12 обратно. Превратите хост h1 в «коммутатор с приоритетом 0»:

   sudo ip -n h1 link add brx type bridge stp_state 1 priority 0
   sudo ip -n h1 link set eth0 master brx
   sudo ip -n h1 link set brx up
   

   Какой мост теперь корень всей сети? Затем включите защиту на порту доступа: sudo bridge -n sw1 link set dev p1 guard on. Что произошло с портом p1 и почему? Как вернуть порт в работу после удаления моста brx у h1 (sudo ip -n h1 link set eth0 nomaster; sudo ip -n h1 link del brx)?

Что должно получиться

Предсказанное и фактическое дерево (две схемы), таблица смены состояний портов во времени, разбор двух BPDU, результат переноса корня, измеренные времена сходимости при стандартных и уменьшенных таймерах с объяснением, результат эксперимента с захватом корня и защитой порта.

Часть 6. Продвинутая: агрегирование каналов и разбор BPDU

Задание

1. Разберите основную топологию (sudo ./down.sh) и поднимите топологию агрегированного канала: sudo ./up-lag.sh. Узлы la и lb соединены двумя звеньями e1 и e2, объединёнными в bond0 в режиме 802.3ad. Изучите файл ns la cat /proc/net/bonding/bond0: найдите режим, политику хеширования, идентификатор агрегатора каждого звена, MAC-адрес партнёра.
2. Захватите LACPDU на одном из звеньев (ns lb tcpdump -i e1 -e -nn -v ether proto 0x8809). Как часто они передаются и какой флаг об этом говорит? Объясните флаги Collecting и Distributing.
3. Предскажите, как распределятся по двум звеньям восемь UDP-потоков, отличающихся только портом отправителя, при политике layer3+4. Запустите приёмник ns lb python3 flows.py recv и в другом окне отправитель ns la python3 flows.py send 10.5.99.2 --flows 8 --packets 200.
4. Смените политику хеширования на layer2 (интерфейс нужно временно выключить: ip -n la link set bond0 down, затем type bond xmit_hash_policy layer2, затем up) и повторите эксперимент. Объясните результат. Почему одно соединение TCP не может получить скорость двух звеньев?
5. Отказ звена. Запустите ns la ping -D -i 0.2 10.5.99.2 и отключите одно звено (sudo ip -n la link set e1 down). Есть ли перерыв связи? Сравните с временем сходимости STP из части 5.
6. Разбор BPDU программой. Запишите захват BPDU части 5 в файл /tmp/bpdu.pcap (если не записали) и выполните python3 bpdu_decode.py /tmp/bpdu.pcap. Сверьте значения с выводом tcpdump -v. Дополните программу, как указано в комментарии «ЗАДАНИЕ» в её тексте: для каждого отправителя выведите число BPDU и средний интервал между ними, отметьте момент первого BPDU с флагом TC. Сопоставьте интервал с hello time.

Что должно получиться

Фрагмент /proc/net/bonding/bond0 с пояснениями, разобранный LACPDU, две таблицы распределения потоков с объяснением, результат эксперимента с отказом звена, исходный текст доработанной программы и её вывод.

Журнал работы

Ведите для себя журнал: для каждой части записывайте предсказание, сделанное до эксперимента, команду, фактический вывод и объяснение расхождений. Таблицы, графики и файлы захватов, перечисленные в разделах «Что должно получиться», удобно хранить там же. В конце полезно сформулировать несколько предложений собственных выводов по работе.

Контрольные вопросы

1. Почему тег 802.1Q вставлен именно на место поля EtherType, а не, например, в конец кадра? Как устройство, не знающее о VLAN, обработает помеченный кадр?
2. Чем порт доступа отличается от магистрального порта в терминах трёх параметров порта моста Linux (разрешённые VLAN, PVID, egress untagged)? Можно ли на одном порту иметь две VLAN без тега на выходе и к чему это приведёт?
3. Хосты h1 и h4 из разных VLAN находятся в одной IP-подсети. Что нужно, чтобы они могли обмениваться пакетами, и почему недостаточно поменять маску?
4. Почему несовпадение native VLAN на концах магистрали не обнаруживается стандартными средствами 802.1Q? Какие симптомы его выдают?
5. Почему в простом кольце число копий широковещательного кадра постоянно, а нагрузка всё равно предельная? Почему нестабильность таблицы MAC-адресов нарушает доставку и одноадресных кадров?
6. Почему в кадре Ethernet нет аналога поля TTL и почему его добавление не решило бы проблему петель полностью?
7. По каким правилам выбираются корень, корневой порт и назначенный порт? Какой порт будет заблокирован в кольце из четырёх мостов с одинаковыми приоритетами и стоимостями?
8. Почему после отказа звена в части 5 перерыв связи оказался дольше удвоенного forward delay? В каком случае он был бы ровно 30 с?
9. Зачем порту STP состояние learning, если он всё равно не пересылает кадры?
10. Какие изменения RSTP сокращают время сходимости до долей секунды? Почему они работают только на звеньях «точка — точка»?
11. Почему агрегированный канал не блокируется STP, а два отдельных параллельных звена — блокируются?
12. От чего зависит равномерность распределения трафика по звеньям агрегированного канала? Приведите пример трафика, при котором канал из четырёх звеньев не даст выигрыша по сравнению с одним.