Логотип
Тема 04

Канальный уровень и Ethernet

Канальный уровень и Ethernet

Тема 3 показала, как физический уровень передаёт поток битов по одной линии: превращает биты в сигнал, борется с шумом и ограничен пределами Найквиста и Шеннона. Но поток битов — ещё не связь между компьютерами. Приёмнику нужно знать, где начинается и заканчивается порция данных, кому она адресована, не искажена ли она по пути. Если к одной среде подключено несколько станций, нужно ещё и договориться, кто и когда передаёт. Эти задачи решает канальный уровень (англ. data link layer) — второй уровень модели OSI, рассмотренной в теме 2.

Почти все проводные локальные сети сегодня построены на одной технологии канального уровня — Ethernet. Её история хорошо иллюстрирует, как меняется решение одной и той же задачи с развитием техники. Ethernet 1970-х годов — это общий коаксиальный кабель, к которому подключены все станции, и сложный протокол разрешения коллизий. Современный Ethernet — это звезда из выделенных полнодуплексных линий, сходящихся в коммутаторе, где коллизий нет вовсе, а от исторического протокола остались формат кадра, адресация и несколько чисел, смысл которых без истории непонятен: минимальная длина кадра 64 байта, межкадровый интервал 96 битовых интервалов.

Изложение построено так. Сначала формулируются задачи канального уровня и способы кадрирования. Затем рассматриваются протоколы множественного доступа — от ALOHA до CSMA/CD — и выясняется, почему коллизии определили минимальный размер кадра Ethernet. Третий раздел подробно разбирает формат кадра, четвёртый — структуру MAC-адресов. Пятый раздел посвящён коммутатору: как он обучается, что делает с кадрами для неизвестных адресов, чем отличается от концентратора и моста. Завершает тему мост Linux — программный коммутатор, который используется в лабораторной работе и во всём курсе для построения учебных топологий.

Задачи канального уровня

Сервис канального уровня

Канальный уровень отвечает за передачу блока данных — кадра (англ. frame) — между двумя узлами, непосредственно соединёнными одной линией или одной общей средой. Такие узлы называют соседними: между ними нет маршрутизаторов. Путь пакета через Интернет состоит из последовательности таких участков, и на каждом из них может использоваться своя технология канального уровня — Ethernet в офисе, Wi-Fi в квартире, оптический канал провайдера. Сетевой уровень (тема 6 и далее) отвечает за путь целиком, канальный — за каждый отдельный «прыжок» 7.

Стандарты IEEE 802 делят канальный уровень на два подуровня 2. Нижний — управление доступом к среде (англ. medium access control, MAC) — отвечает за формат кадра, адресацию и правила доступа к среде; он свой у каждой технологии (802.3 для Ethernet, 802.11 для Wi-Fi). Верхний — управление логическим каналом (англ. logical link control, LLC, IEEE 802.2) — задумывался как общий для всех технологий 802 интерфейс к сетевому уровню. На практике в Ethernet поверх IP подуровень LLC почти не используется: его функцию — указать, какому протоколу верхнего уровня принадлежат данные, — выполняет поле EtherType в заголовке кадра.

Типичные функции канального уровня:

  • кадрирование (англ. framing) — выделение кадров из потока битов;
  • адресация — указание отправителя и получателя кадра в пределах общей среды;
  • обнаружение ошибок — вычисление и проверка контрольной последовательности кадра;
  • управление доступом к среде — правила, по которым несколько станций делят один канал;
  • в некоторых технологиях — надёжная доставка с подтверждениями и повторами.

Последний пункт заслуживает пояснения. Ethernet надёжной доставки не обеспечивает: искажённый кадр просто отбрасывается, и восстановление потерь — дело транспортного уровня (тема 13). Это осознанное решение в духе принципа «из конца в конец» (тема 2): в проводной сети ошибки редки, и проверять доставку на каждом участке незачем. В радиоканале, где искажения часты, Wi-Fi подтверждает каждый кадр уже на канальном уровне (тема 20).

Кадрирование

Физический уровень доставляет непрерывный поток битов или символов. Чтобы выделить в нём кадры, применяется один из трёх приёмов 3.

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

Второй — флаговые байты со вставкой байтов (англ. byte stuffing). Кадр начинается и заканчивается особым байтом-флагом, например 0x7E в протоколе PPP. Если такой байт встречается внутри данных, передатчик заменяет его двухбайтовой последовательностью с управляющим байтом (англ. escape, в PPP — 0x7D), а приёмник выполняет обратную замену. Разновидность этого приёма на уровне битов — вставка битов (англ. bit stuffing) в протоколе HDLC: флаг имеет вид 01111110, и после каждых пяти подряд единиц в данных передатчик вставляет ноль, так что шесть единиц подряд встречаются только во флаге.

Третий — использование служебных символов физического уровня, которые не могут встретиться в данных. Именно так поступает Ethernet. Линейные коды 4B/5B, 8b/10b и 64b/66b, рассмотренные в теме 3, оставляют неиспользованные кодовые слова, и часть из них отведена под признаки начала и конца потока. Кроме того, между кадрами линия находится в состоянии простоя (англ. idle), а начало каждого кадра предваряется преамбулой и разделителем начала кадра. Поэтому в Ethernet нет ни вставки байтов, ни поля общей длины кадра: границы кадра определяет физический уровень 1.

Обнаружение ошибок в кадре

Кадр Ethernet заканчивается четырёхбайтовой контрольной последовательностью кадра (англ. frame check sequence, FCS) — 32-битовым циклическим избыточным кодом CRC-32, механизм которого подробно разобран в теме 3. Передатчик вычисляет CRC по всем полям кадра от адреса назначения до конца данных, приёмник повторяет вычисление. Кадр с неверной FCS отбрасывается молча: отправителю ничего не сообщается, а счётчик ошибок приёма интерфейса увеличивается на единицу. Такие счётчики видны в выводе ip -s link и ethtool -S и служат первым признаком неисправности кабеля или порта.

Заметим, что при захвате трафика на хосте Linux поле FCS обычно не видно: сетевая карта проверяет и отрезает его до передачи кадра в ядро. Поэтому tcpdump и Wireshark показывают кадры на 4 байта короче, чем они были в линии, а кадры с ошибкой FCS не показывают вовсе.

Множественный доступ к среде

Задача множественного доступа

Первые локальные сети строились на общей среде (англ. shared medium): все станции подключались к одному кабелю или одному радиоканалу, и сигнал любой станции получали все остальные. Если две станции передают одновременно, их сигналы накладываются, и ни один кадр не может быть принят — происходит коллизия (англ. collision). Протокол множественного доступа (англ. multiple access protocol) определяет, как станции делят среду, и оценивается по двум показателям: доле времени, в течение которой канал передаёт полезные кадры, и задержке доступа к среде.

Протоколы множественного доступа делятся на три класса 7. Протоколы разделения канала делят ресурс заранее — по времени (TDMA), по частоте (FDMA) или по коду (CDMA); они эффективны при постоянной нагрузке, но расточительны, когда большинство станций молчит. Протоколы очерёдности передают право на передачу по кругу — маркером (англ. token), как в сетях Token Ring и FDDI, или опросом центральной станцией. Протоколы случайного доступа (англ. random access) позволяют станции передавать в любой момент, а коллизии разрешают повторной передачей через случайное время. К последнему классу относятся ALOHA и Ethernet.

ALOHA и дискретная ALOHA

Протокол ALOHA был создан в Гавайском университете Норманом Абрамсоном для радиосети, связывавшей острова архипелага, и описан в 1970 году 5. Правило предельно просто: станция передаёт кадр, как только он готов; если подтверждение не пришло, считается, что произошла коллизия, и кадр повторяется через случайное время.

Оценим эффективность. Пусть все кадры имеют одинаковую длительность T, а попытки передачи всех станций вместе образуют пуассоновский поток со средним числом G попыток за время T. Кадр, начатый в момент t, будет принят, если никакая другая станция не начнёт передачу в интервале от t − T до t + T, то есть в окне длительностью 2T. Вероятность этого равна e^{-2G}, а доля времени, занятая успешными кадрами (пропускная способность протокола),

S = G \cdot e^{-2G}, \qquad \text{максимум при } G = \frac{1}{2}: \quad S = \frac{1}{2e} \approx 0{,}184

Лучше всего ALOHA использует канал на 18,4 %. Дискретная (тактированная) ALOHA (англ. slotted ALOHA) разрешает начинать передачу только в начале временных слотов длительностью T; окно уязвимости сокращается до T, и S = G \cdot e^{-G} с максимумом 1/e \approx 0{,}368 при G = 1. Обе формулы показывают общее свойство случайного доступа: при росте нагрузки сверх оптимальной доля коллизий растёт быстрее, чем доля успешных передач, и пропускная способность падает.

CSMA/CD: прослушивание несущей и обнаружение коллизий

ALOHA не прислушивается к среде. Очевидное улучшение — не начинать передачу, пока канал занят чужим сигналом. Такой протокол называется множественным доступом с контролем несущей (англ. carrier sense multiple access, CSMA). Он не устраняет коллизии полностью: сигнал распространяется с конечной скоростью, и станция, начавшая передачу, «слышна» другим лишь через время распространения. Если вторая станция успеет начать передачу в этот промежуток, кадры столкнутся.

Ethernet, предложенный Робертом Меткалфом и Дэвидом Боггсом в исследовательском центре Xerox PARC 4, добавил к CSMA обнаружение коллизий (англ. collision detection, CD). Передающая станция продолжает слушать среду и, обнаружив чужой сигнал поверх своего, немедленно прекращает передачу кадра, чтобы не тратить канал впустую. Алгоритм CSMA/CD в классическом полудуплексном Ethernet выглядит так 1:

  1. Станция, имеющая кадр, ждёт, пока среда освободится, и выдерживает межкадровый интервал (англ. interframe gap, IFG) — 96 битовых интервалов.
  2. Станция начинает передачу и одновременно контролирует среду.
  3. Если коллизия не обнаружена до конца кадра, передача успешна.
  4. При обнаружении коллизии станция прекращает передачу кадра и передаёт 32-битовую последовательность-затор (англ. jam), чтобы все участники гарантированно заметили коллизию.
  5. После n-й коллизии подряд станция выбирает случайное целое r от 0 до 2^k − 1, где k = min(n, 10), ждёт r слотов по 512 битовых интервалов и возвращается к шагу 1. После 16 неудачных попыток кадр отбрасывается.

Правило шага 5 называется усечённой двоичной экспоненциальной отсрочкой (англ. truncated binary exponential backoff). Оно адаптирует протокол к нагрузке без какого-либо знания о числе станций: при первой коллизии выбор идёт из двух вариантов (0 или 1 слот), при второй — из четырёх, при десятой — из 1024. Если сталкиваются две станции, уже на первой отсрочке они разойдутся с вероятностью 1/2; если сталкиваются десятки, интервал быстро растёт, пока не станет достаточным для всех. Вопреки распространённому представлению о том, что Ethernet «захлёбывается» уже при трети нагрузки (оценка, перенесённая с ALOHA), измерения Боггса, Могула и Кента показали, что при длинных кадрах и небольшой сети CSMA/CD использует канал более чем на 90 %: коллизии обнаруживаются за время, малое по сравнению с длительностью кадра, и обходятся дёшево 12.

Коллизии и минимальная длина кадра

Чтобы обнаружение коллизий работало, станция должна узнать о коллизии, пока ещё передаёт свой кадр: если кадр закончился, а коллизия случилась позже, станция сочтёт передачу успешной, и кадр будет потерян без повтора. Рассмотрим худший случай, изображённый на рисунке ниже. Станции A и B находятся на противоположных концах сети, время распространения сигнала между ними τ. Станция A начинает передачу; сигнал доходит до B через время τ. За мгновение до этого B, считающая среду свободной, тоже начинает передачу и тут же обнаруживает коллизию. Её сигнал (включая затор) возвращается к A ещё через τ. Итак, A узнаёт о коллизии через время, близкое к 2τ, и к этому моменту должна всё ещё передавать.

Временная диаграмма худшего случая: A начинает передачу, B начинает за мгновение до прихода сигнала A, сигнал коллизии возвращается к A через 2τ
Худший случай обнаружения коллизии в CSMA/CD: кадр должен длиться не меньше 2τ

Отсюда условие: время передачи минимального кадра должно быть не меньше удвоенного времени распространения между самыми удалёнными станциями, 2τ, называемого временем двойного оборота (англ. round-trip propagation time). Стандарт 10 Мбит/с зафиксировал этот интервал — слот — равным 512 битовым интервалам, то есть 51,2 мкс, что с учётом задержек в повторителях и трансиверах соответствует сети диаметром около 2,5 км. Минимальный кадр, следовательно, имеет длину 512 битов = 64 байта (от адреса назначения до FCS включительно), и из этого числа выводится минимальная длина поля данных: 64 − 14 (заголовок) − 4 (FCS) = 46 байтов 14. Совокупность станций, кадры которых могут столкнуться, называется доменом коллизий (англ. collision domain); его диаметр ограничен именно этим соотношением.

При переходе к 100 Мбит/с слот в 512 битовых интервалов сократился в десять раз, до 5,12 мкс, и вместе с ним сократился допустимый диаметр полудуплексной сети — до примерно 200 м. Для гигабитного полудуплексного режима пришлось ввести расширение несущей (англ. carrier extension), искусственно удлинявшее короткие кадры до 512 байтов. Этот режим практически не применялся: к тому времени Ethernet стал полнодуплексным.

Полнодуплексный коммутируемый Ethernet

Решающее изменение произошло, когда общий кабель заменила витая пара со звездообразной топологией (10BASE-T, 1990 год), а в центре звезды вместо повторителя оказался коммутатор. В стандарте 10BASE-T для передачи и приёма используются разные пары, а коммутатор принимает кадр каждого порта отдельно. Если к порту подключена одна станция, в сегменте всего два передатчика — станция и порт коммутатора, — и каждый передаёт по своей паре. Сигналы больше не могут столкнуться, и стандарт IEEE 802.3x (1997 год) ввёл полнодуплексный режим (англ. full duplex): станция передаёт, не прослушивая среду, и одновременно принимает 111.

В полнодуплексном режиме CSMA/CD выключен, коллизий не бывает, расстояние ограничено только физическим уровнем (100 м для витой пары, десятки километров для оптики), а пропускная способность в каждом направлении равна номинальной. Все стандарты Ethernet со скоростью выше 1 Гбит/с определены только в полнодуплексном режиме. От эпохи общей среды остались минимальная длина кадра 64 байта и межкадровый интервал — их сохранили ради совместимости, — а на смену доступу к среде пришла новая задача: как коммутатор решает, в какой порт отправить кадр. Ей посвящён раздел о коммутации. Общая среда и протокол случайного доступа, однако, не исчезли: в радиоканале Wi-Fi используется их вариант с предотвращением коллизий, CSMA/CA (тема 20).

Кадр Ethernet

Формат кадра Ethernet II

На рисунке ниже показан кадр Ethernet в том виде, в каком он передаётся в линию, вместе с полями физического уровня, которые его окружают.

Кадр Ethernet II: преамбула 7 байт, SFD 1 байт, адрес назначения 6, адрес источника 6, тип 2, данные 46–1500, FCS 4, межкадровый интервал 12 байт
Кадр Ethernet II в линии: поля, их длины и область вычисления FCS

Назначение полей сведено в таблицу.

ПолеДлина, байтНазначение
Преамбула (англ. preamble)7чередование 10101010 для синхронизации приёмника
Разделитель начала кадра (англ. start frame delimiter, SFD)110101011: две единицы подряд отмечают начало кадра
Адрес назначения (англ. destination address)6MAC-адрес получателя
Адрес источника (англ. source address)6MAC-адрес отправителя
Тип (англ. EtherType) или длина2протокол данных: 0x0800 — IPv4, 0x0806 — ARP, 0x86DD — IPv6, 0x8100 — тег VLAN
Данные (англ. payload)46–1500пакет верхнего уровня; при необходимости дополняется заполнением (англ. padding)
Контрольная последовательность (FCS)4CRC-32 по полям от адреса назначения до конца данных

Преамбула и SFD в современном Ethernet — наследие эпохи общей шины, когда приёмнику требовалось время, чтобы «поймать» тактовую частоту нового передатчика; в высокоскоростных физических уровнях с кодом 64b/66b они заменены управляющими символами того же назначения, но в стандарте формально сохранены. Адрес назначения стоит первым не случайно: коммутатор и сетевая карта могут начать принимать решение о кадре, прочитав лишь первые шесть байтов. Заголовок кадра — адреса и тип — занимает 14 байтов.

Если пакет верхнего уровня короче 46 байтов, передатчик дополняет поле данных нулями до 46, чтобы кадр не оказался короче 64 байтов. Длину самого пакета приёмник определяет из его собственного заголовка (например, поля общей длины IPv4), а заполнение отбрасывает. Так, запрос ARP занимает 28 байтов, и в линии его кадр дополняется 18 байтами нулей. В захвате на хосте Linux тот же кадр часто виден длиной 42 байта (14 + 28) — заполнение и FCS добавляются сетевой картой уже после того, как копия кадра передана анализатору.

Ethernet II и IEEE 802.3: тип или длина

Исторически существовало два формата кадра. Формат DIX, или Ethernet II (по первым буквам компаний DEC, Intel и Xerox, опубликовавших спецификацию в 1980–1982 годах), содержит после адресов поле типа. Стандарт IEEE 802.3 1983 года поставил на это место поле длины данных, а протокол верхнего уровня предлагал указывать в заголовке LLC (802.2) и, при необходимости, в расширении SNAP. Два формата различаются по значению этого поля: значения не больше 1500 (0x05DC) означают длину, значения не меньше 1536 (0x0600) — тип 113. В 1997 году IEEE признал оба толкования, и сегодня IPv4, IPv6 и ARP передаются в формате Ethernet II с полем EtherType, как это определил ещё RFC 894 6; кадры 802.3 с LLC встречаются у некоторых служебных протоколов канального уровня, например у протокола связующего дерева (тема 5).

Регистрацией значений EtherType ведает IEEE Registration Authority; список значений, используемых протоколами IETF, и значения для документации приведены в RFC 7042 13. Для экспериментов и учебных целей IEEE выделил значения 0x88B5 и 0x88B6 (англ. Local Experimental EtherType) — их не обрабатывает ни один стандартный протокол, и именно 0x88B5 используется в скрипте лабораторной работы.

Кадр байт за байтом

Рассмотрим реальный кадр, захваченный на хосте учебной топологии лабораторной работы. Хост h1 (MAC-адрес 02:00:00:00:04:01, IP-адрес 10.4.0.1) выполняет ping 10.4.0.2; на интерфейсе h2 перехвачен эхо-запрос ICMP. Ключ -e заставляет tcpdump показать заголовок канального уровня, -XX — вывести кадр целиком в шестнадцатеричном виде:

tcpdump -r h2.pcap -e -nn -XX icmp -c 1

12:59:21.277538 02:00:00:00:04:01 > 02:00:00:00:04:02, ethertype IPv4 (0x0800), length 98: 10.4.0.1 > 10.4.0.2: ICMP echo request, id 496, seq 1, length 64
	0x0000:  0200 0000 0402 0200 0000 0401 0800 4500  ..............E.
	0x0010:  0054 96fd 4000 4001 8fa1 0a04 0001 0a04  .T..@.@.........
	0x0020:  0002 0800 25e7 01f0 0001 79af cc6a 0000  ....%.....y..j..
	...

Первые шесть байтов 02 00 00 00 04 02 — адрес назначения (h2), следующие шесть 02 00 00 00 04 01 — адрес источника (h1), затем 08 00 — EtherType IPv4. С байта 0x0e начинается заголовок IPv4 (45 — версия 4 и длина заголовка 5 слов по 4 байта; его устройство — тема 7). Общая длина кадра 98 байтов = 14 (заголовок Ethernet) + 20 (IP) + 8 (ICMP) + 56 (данные ping по умолчанию). FCS в захвате отсутствует по указанной выше причине; в линии кадр занимал бы 102 байта плюс 8 байтов преамбулы и SFD и 12 байтов межкадрового интервала.

Предшествующий эхо-запросу кадр — широковещательный запрос протокола ARP, которым h1 выясняет MAC-адрес h2 по его IP-адресу:

12:59:21.277397 02:00:00:00:04:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.4.0.2 tell 10.4.0.1, length 28
	0x0000:  ffff ffff ffff 0200 0000 0401 0806 0001  ................
	0x0010:  0800 0604 0001 0200 0000 0401 0a04 0001  ................
	0x0020:  0000 0000 0000 0a04 0002                 ..........

Адрес назначения ff:ff:ff:ff:ff:ff — широковещательный, EtherType 0x0806. Протокол ARP подробно рассматривается в теме 7; здесь существенно лишь то, что любой обмен по IP в локальной сети начинается с таких широковещательных кадров, и их можно увидеть в захвате на любом порту коммутатора.

Размер кадра, межкадровый интервал и эффективность

Наибольшая длина поля данных стандартного кадра — 1500 байтов, и это число стало максимальным размером пакета сетевого уровня в большинстве сетей — MTU (англ. maximum transmission unit). Наибольший кадр без тега VLAN имеет длину 1518 байтов (с тегом 802.1Q — 1522, см. тему 5). Между кадрами передатчик выдерживает межкадровый интервал (англ. interpacket gap) — не менее 96 битовых интервалов, то есть 12 байтовых времён: 9,6 мкс при 10 Мбит/с и 9,6 нс при 10 Гбит/с.

Подсчитаем, какую долю линии занимают полезные данные. Каждый кадр в линии сопровождается 8 байтами преамбулы и SFD и 12 байтами интервала, поэтому кадр с 1500 байтами данных занимает 1500 + 18 + 8 + 12 = 1538 байтовых времён. Эффективность на уровне канала — 1500/1538 ≈ 97,5 %; если данные — сегмент TCP с 1448 байтами полезной нагрузки (заголовки IP 20 и TCP 32 байта с временными метками), эффективность для приложения 1448/1538 ≈ 94,1 %. Именно поэтому передача файла по линии 1 Гбит/с в идеальных условиях показывает около 941 Мбит/с. Минимальный кадр занимает в линии 64 + 8 + 12 = 84 байтовых времени, отсюда предельная скорость пересылки кадров: 10⁹ / (84 · 8) ≈ 1,488 млн кадров в секунду на 1 Гбит/с и 14,88 млн на 10 Гбит/с. Эти числа — стандартная мера производительности коммутаторов и маршрутизаторов, обязанных обрабатывать поток минимальных кадров без потерь (англ. line rate, wire speed).

Кадры с полем данных больше 1500 байтов называются jumbo-кадрами (англ. jumbo frames). Стандартом 802.3 они не определены, но поддерживаются почти всем современным оборудованием; типичное значение MTU — 9000 байтов. Jumbo-кадры повышают эффективность (9000/9038 ≈ 99,6 %) и, главное, в шесть раз уменьшают число кадров, которые нужно обработать хосту при той же скорости, поэтому применяются в сетях хранения данных и ЦОД. Их опасность — в необходимости единообразной настройки: если хоть одно устройство на пути имеет меньший MTU, большие кадры будут молча отброшены на канальном уровне, хотя маленькие (например, эхо-запросы ping по умолчанию) будут проходить. Такой сценарий разбирается в лабораторной работе; механизмы сетевого уровня для выяснения MTU пути — в теме 7.

MAC-адреса

Структура адреса

Адрес канального уровня в сетях IEEE 802 — MAC-адрес — имеет длину 48 битов и записывается шестью октетами в шестнадцатеричном виде через двоеточие или дефис: 00:00:5e:00:53:01 или 00-00-5E-00-53-01 2. Его структура показана на рисунке ниже.

Структура MAC-адреса: OUI 24 бита и номер интерфейса 24 бита; в первом октете бит b0 — I/G, бит b1 — U/L
Структура MAC-адреса и назначение двух младших битов первого октета

Первые три октета глобально уникального адреса — идентификатор организации (англ. organizationally unique identifier, OUI), который IEEE за плату выдаёт производителю оборудования; последние три октета производитель назначает сам, обеспечивая уникальность в пределах своего OUI. Так, OUI 00-00-5E принадлежит IANA, и в нём RFC 7042 выделил диапазон 00-00-5E-00-53-00…00-00-5E-00-53-FF для использования в документации 13. Реестр OUI открыт, и по первым трём октетам адреса можно определить производителя сетевой карты — Wireshark делает это автоматически.

Два младших бита первого октета имеют особый смысл:

  • бит I/G (англ. individual/group), b0: 0 — индивидуальный адрес (англ. unicast), 1 — групповой (англ. multicast);
  • бит U/L (англ. universal/local), b1: 0 — глобально уникальный адрес, назначенный по OUI, 1 — локально администрируемый.

Эти биты расположены в младших разрядах первого октета, но первыми передаются в линию, потому что Ethernet передаёт каждый октет начиная с младшего бита. Признак группового адреса приёмник получает самым первым битом кадра после SFD и может сразу решить, принимать ли кадр.

Индивидуальные, групповые и широковещательный адреса

Индивидуальный адрес идентифицирует один интерфейс. Групповой — множество интерфейсов, подписанных на группу: сетевая карта принимает кадры на групповые адреса, которые ей сообщила операционная система. Широковещательный адрес (англ. broadcast) ff:ff:ff:ff:ff:ff — частный случай группового (все биты равны единице), его принимают все станции сегмента.

Групповые адреса используются и протоколами IP. Групповые IPv4-адреса отображаются в MAC-адреса вида 01:00:5e:xx:xx:xx, групповые IPv6-адреса — в 33:33:xx:xx:xx:xx; служебные протоколы канального уровня используют зарезервированный блок 01:80:c2:00:00:00…0f (например, протокол связующего дерева — 01:80:c2:00:00:00), и кадры на эти адреса мосты не пересылают 313. Определить тип адреса по первому октету просто: если он нечётный, адрес групповой; если второй младший бит равен 1 (вторая шестнадцатеричная цифра — 2, 3, 6, 7, A, B, E или F), адрес локально администрируемый.

АдресПервый октет в двоичном видеТип
00:00:5e:00:53:010000 0000индивидуальный, глобальный (документационный блок IANA)
02:00:00:00:04:010000 0010индивидуальный, локально администрируемый
01:00:5e:00:00:010000 0001групповой IPv4 (все хосты, 224.0.0.1)
33:33:00:00:00:010011 0011групповой IPv6 (все узлы, ff02::1)
ff:ff:ff:ff:ff:ff1111 1111широковещательный

Локально администрируемые адреса и рандомизация

Локально администрируемые адреса назначаются не производителем, а администратором или программой. Их используют виртуальные интерфейсы: ядро Linux присваивает интерфейсам veth, мостам и туннелям случайные адреса с установленным битом U/L, гипервизоры назначают адреса виртуальным машинам. Стандарт IEEE 802c-2017 разбил пространство локальных адресов на четыре квадранта, чтобы разные способы назначения не конфликтовали 14.

Глобально уникальный адрес, неизменный на протяжении всей жизни устройства, позволяет отслеживать его владельца: точки доступа Wi-Fi в торговых центрах и на улицах видят адреса всех проходящих телефонов в их служебных кадрах. Поэтому современные операционные системы для беспроводных сетей используют рандомизацию MAC-адреса (англ. MAC address randomization): при поиске сетей и при подключении к каждой сети используется отдельный случайный локально администрируемый адрес. Такие адреса применяются по умолчанию в Android с версии 10, в iOS с версии 14 и в Windows 10/11 (при включённом параметре «Случайные аппаратные адреса»). Побочный эффект рандомизации — нарушение схем, в которых администратор сети опознаёт устройства по MAC-адресу, например при резервировании адресов DHCP (тема 14).

В Linux адрес интерфейса показывает и изменяет утилита ip:

ip link show eth0
ip link set dev eth0 address 02:00:00:00:04:aa   # интерфейс лучше предварительно опустить

Смена MAC-адреса — простая операция, и это следует помнить: адрес источника в кадре ничем не защищён, и любая станция может отправить кадр с чужим адресом. На этом основаны атаки подмены, которые обсуждаются в теме 5.

Коммутация в локальной сети

Повторитель, концентратор, мост и коммутатор

Устройства, объединяющие сегменты локальной сети, различаются уровнем, на котором они работают. Повторитель (англ. repeater) работает на физическом уровне: принимает сигнал, восстанавливает его форму и усиливает. Многопортовый повторитель для витой пары называется концентратором (англ. hub): сигнал, пришедший на один порт, повторяется во все остальные. Концентратор не понимает кадров и адресов; все подключённые к нему станции находятся в одном домене коллизий и делят его пропускную способность — десять станций на концентраторе 10 Мбит/с в сумме получают те же 10 Мбит/с. Сравнение устройств разных уровней с подробными схемами приводится в учебнике Олиферов 8.

Мост (англ. bridge) работает на канальном уровне. Он принимает кадр целиком, проверяет FCS и пересылает кадр в другой сегмент только тогда, когда получатель находится там. Мост разделяет домены коллизий и позволяет одновременную передачу в разных сегментах. Коммутатор (англ. switch) — это многопортовый мост с аппаратной пересылкой кадров между портами: к каждому порту обычно подключена одна станция в полнодуплексном режиме, и коммутатор обеспечивает одновременную передачу между многими парами портов. Термин «коммутатор» — коммерческий; в стандартах IEEE 802.1Q то же устройство называется мостом 3, и Linux следует стандарту, называя программный коммутатор bridge.

Обучение коммутатора и таблица MAC-адресов

Коммутатор должен знать, за каким портом находится каждый адрес. Настраивать это вручную немыслимо, поэтому коммутатор обучается сам, наблюдая за адресами источника в проходящих кадрах. Он поддерживает таблицу пересылки (англ. forwarding database, FDB), или таблицу MAC-адресов, — соответствие «MAC-адрес → порт». Обработка каждого принятого кадра состоит из двух независимых шагов 37:

  1. Обучение (англ. learning). Адрес источника кадра запоминается в таблице вместе с портом, через который кадр пришёл, и текущим временем. Если запись уже есть, обновляются её порт и время.
  2. Пересылка (англ. forwarding) по адресу назначения:
    • адрес найден в таблице, и порт отличается от порта приёма — кадр отправляется только в этот порт;
    • адрес найден, но порт совпадает с портом приёма — кадр отбрасывается (англ. filtering): получатель находится в том же сегменте и уже получил кадр;
    • адрес не найден, или адрес групповой либо широковещательный — кадр рассылается во все порты, кроме порта приёма. Это называется лавинной рассылкой (англ. flooding).

Рисунок ниже показывает, как таблица заполняется в ходе обмена трёх станций.

Коммутатор с четырьмя портами и станциями A, B, C, D; таблица по шагам: A → B рассылается лавиной, B → A отправляется в порт 1, широковещательный кадр C рассылается во все порты, кроме 3
Обучение коммутатора: таблица заполняется по адресам источника, решение о пересылке принимается по адресу назначения

Важно понимать асимметрию алгоритма: коммутатор узнаёт о станции только тогда, когда та что-нибудь отправит. Станция, которая только принимает кадры (например, сервер, на который идёт односторонний поток UDP), может так и не появиться в таблице, и весь трафик к ней будет рассылаться во все порты. Обычно эта проблема не возникает: любой обмен по IP начинается с запроса ARP, ответ на который обучает коммутатор, а протоколы верхних уровней порождают ответные кадры.

Таблица MAC-адресов не может хранить записи вечно: станции отключаются, переносятся на другие порты, меняют адреса. Поэтому у каждой динамической записи есть время старения (англ. ageing time): запись, не обновлявшаяся указанное время, удаляется. Стандарт рекомендует значение 300 секунд 3. Если станция переместится на другой порт, запись будет исправлена первым же кадром от неё — обучение обновляет порт немедленно. Если же станция переместилась и молчит, кадры к ней будут уходить в старый порт до истечения времени старения или до её первого кадра.

Размер таблицы ограничен — от нескольких тысяч записей у простых коммутаторов до сотен тысяч у коммутаторов ЦОД. Когда таблица заполнена, новые адреса не запоминаются, и кадры к ним рассылаются лавиной. На этом основана атака переполнения таблицы (англ. MAC flooding): злоумышленник посылает кадры с тысячами случайных адресов источника, коммутатор превращается в подобие концентратора, и злоумышленник получает чужой трафик. Защита от неё рассматривается в теме 5.

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

Два понятия помогают описать границы, которые вводят устройства разных уровней. Домен коллизий — совокупность станций, кадры которых могут столкнуться; концентратор его не разделяет, мост и коммутатор разделяют по портам, а в полнодуплексной сети коллизий нет вообще. Широковещательный домен (англ. broadcast domain) — совокупность станций, которые получают широковещательный кадр любой из них. Коммутаторы широковещательный домен не разделяют: кадр на ff:ff:ff:ff:ff:ff рассылается во все порты всех коммутаторов, соединённых между собой. Границей широковещательного домена служит маршрутизатор — устройство сетевого уровня — или разбиение коммутируемой сети на виртуальные локальные сети (тема 5).

Размер широковещательного домена — главное ограничение плоской сети на коммутаторах. Широковещательные кадры ARP, DHCP и других служебных протоколов получает и обрабатывает каждая станция; при тысячах станций это ощутимая нагрузка, а любая петля в топологии превращает широковещательный кадр в бесконечно размножающийся шторм, поскольку в кадре Ethernet нет поля времени жизни. Как с этим справляются — тема 5.

Способы пересылки: с промежуточным хранением и сквозная

Коммутатор может начать передачу кадра в выходной порт в разные моменты. При коммутации с промежуточным хранением (англ. store-and-forward) кадр принимается целиком, проверяется FCS, и только затем начинается передача. Повреждённые кадры отбрасываются и не распространяются по сети, а входной и выходной порты могут работать на разных скоростях. Плата — задержка, равная времени приёма кадра: для кадра 1518 байтов это 12,1 мкс при 1 Гбит/с и 121 мкс при 100 Мбит/с — на каждом коммутаторе пути.

При сквозной коммутации (англ. cut-through) передача в выходной порт начинается, как только прочитан адрес назначения — после первых 14 байтов кадра или даже 6. Задержка не зависит от длины кадра и составляет у коммутаторов ЦОД сотни наносекунд. Но кадр с ошибкой будет передан дальше прежде, чем коммутатор узнает о ней по FCS; он может лишь испортить «хвост» кадра, чтобы следующий узел его отбросил. Сквозная коммутация возможна только при одинаковых скоростях портов и свободном выходном порте; если порт занят, кадр всё равно буферизуется целиком. Её применяют там, где важна каждая микросекунда, — в сетях биржевой торговли и высокопроизводительных вычислений.

Мост Linux как программный коммутатор

Создание моста и подключение портов

Ядро Linux содержит программную реализацию моста IEEE 802.1D/802.1Q 9. Мост — это виртуальный интерфейс, к которому в качестве портов подключаются другие интерфейсы: физические сетевые карты, концы пар veth, интерфейсы виртуальных машин и контейнеров. Именно так Docker соединяет контейнеры между собой через мост docker0, а гипервизоры — виртуальные машины с физической сетью. В лабораторных работах курса мост в отдельном сетевом пространстве имён играет роль коммутатора, а хосты-пространства подключены к нему парами veth — виртуальным аналогом патч-корда.

Мост и его порты создаются утилитой ip из пакета iproute2, а наблюдаются утилитой bridge 10:

ip link add br0 type bridge          # создать мост
ip link set br0 up
ip link set p1 master br0            # подключить интерфейс p1 как порт моста
ip link set p1 up
bridge link                          # список портов и их состояние

В учебной топологии лабораторной работы четыре хоста h1–h4 подключены к мосту br0 в пространстве имён sw. Вывод bridge link показывает, что все четыре порта в состоянии пересылки:

3: p1@br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
4: p2@br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
5: p3@br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
6: p4@br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2

Поля priority и cost относятся к протоколу связующего дерева, который по умолчанию в мосте Linux выключен (stp_state 0) и рассматривается в теме 5. Флаги UP,LOWER_UP означают, что интерфейс включён администратором (UP) и у него есть «несущая» — подключённый и включённый партнёр (LOWER_UP). Порт, у которого партнёр выключен, будет показан в состоянии disabled, и кадры через него не пойдут.

Таблица пересылки моста

Таблицу MAC-адресов моста показывает команда bridge fdb show. Сразу после создания топологии в ней есть только постоянные записи:

bridge fdb show br br0

33:33:00:00:00:01 dev br0 self permanent
01:00:5e:00:00:01 dev br0 self permanent
76:94:fc:58:83:dd dev p1 vlan 1 master br0 permanent
76:94:fc:58:83:dd dev p1 master br0 permanent
33:33:00:00:00:01 dev p1 self permanent
...

Записи с флагом permanent и адресами самих портов (76:94:fc:58:83:dd — адрес порта p1 в пространстве sw) говорят мосту, что кадры на эти адреса предназначены ему самому. Записи с флагом self относятся к таблице самого интерфейса (например, групповые адреса, на которые подписан интерфейс), а не к таблице пересылки моста. После того как h1 выполнит ping 10.4.0.2, появятся динамические записи — те, которые мост выучил:

02:00:00:00:04:01 dev p1 master br0
02:00:00:00:04:02 dev p2 master br0

Мост выучил адрес h1 по запросу ARP и эхо-запросу, пришедшим через порт p1, а адрес h2 — по ответам через p2. Ключ -s добавляет к каждой записи время с момента последнего использования и обновления в секундах (used 5/5), а запись, срок жизни которой уже истёк и которая лишь ожидает удаления сборщиком мусора моста, помечается словом stale; для пересылки такая запись уже не используется.

Время старения задаётся параметром моста ageing_time. В iproute2 он указывается в сотых долях секунды: значение 30000 соответствует стандартным 300 секундам. Изменить его и очистить динамические записи можно так:

ip link set br0 type bridge ageing_time 1500   # 15 секунд
ip link set br0 type bridge fdb_flush          # удалить все динамические записи
ip -d link show br0                            # подробные параметры моста

Проверка старения требует аккуратности. Хосты, обменявшиеся кадрами, через несколько секунд проверяют актуальность записей своих таблиц ARP (тема 7) и посылают друг другу одноадресные запросы — эти кадры обновляют записи моста. Поэтому для наблюдения старения удобнее отправить единственный кадр с адресом источника, который больше не встретится; в лабораторной работе это делает скрипт sendframe.py, а запись с таким адресом по истечении времени старения помечается как stale и исчезает при ближайшем проходе сборщика мусора, то есть с небольшой задержкой, а не ровно через ageing_time:

t=5   02:00:00:00:04:77 dev p1 used 5/5 master br0
t=10  02:00:00:00:04:77 dev p1 used 10/10 master br0
t=15  02:00:00:00:04:77 dev p1 used 15/15 master br0 stale
t=20  (записи нет)

Лавинная рассылка и MTU в мосте Linux

Поведение моста при лавинной рассылке легко увидеть, перехватывая кадры на «чужом» порту. Ниже приведён захват на хосте h3, который не участвует в обмене h1 с h2. Хост h1 выполнил ping 10.4.0.2, а затем отправил кадр на несуществующий адрес 02:00:00:00:04:99:

02:00:00:00:04:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.4.0.2 tell 10.4.0.1, length 28
02:00:00:00:04:01 > 02:00:00:00:04:99, ethertype Unknown (0x88b5), length 60:

Хост h3 получил широковещательный запрос ARP и кадр на неизвестный адрес, но не эхо-запросы ICMP к h2: их адрес назначения мосту уже известен, и они ушли только в порт p2. Ответ ARP от h2 и эхо-ответы h3 тоже не видит.

Мост Linux пересылает кадры, не фрагментируя их: канальный уровень не умеет делить кадр на части. Если кадр длиннее MTU выходного порта, он молча отбрасывается. MTU самого интерфейса моста по умолчанию равен наименьшему MTU его портов. Отсюда типичная ошибка при переходе на jumbo-кадры: хосты и часть портов переведены на MTU 9000, а один порт забыт. Маленькие пакеты проходят, ping работает, а передача больших объёмов данных зависает, потому что полноразмерные кадры теряются без какого-либо сообщения. Диагностика сводится к проверке MTU на всём пути кадра командой ip link и к эхо-запросам заданного размера с запретом фрагментации:

ping -M do -s 1472 10.4.0.2    # 1472 + 8 (ICMP) + 20 (IP) = 1500 байтов
ping -M do -s 8972 10.4.0.2    # пакет 9000 байтов: проверка jumbo-пути

Наконец, заметим, что мост Linux умеет гораздо больше, чем описанная здесь базовая коммутация: фильтрацию по VLAN, протокол связующего дерева, отслеживание групповой рассылки (англ. IGMP/MLD snooping), изоляцию портов. Первые две возможности — предмет темы 5.

Итоги темы

Канальный уровень превращает поток битов физического уровня в кадры, доставляемые между соседними узлами: выделяет границы кадров, адресует их, обнаруживает ошибки с помощью CRC и, если среда общая, управляет доступом к ней. Ethernet решает задачу кадрирования средствами физического уровня — преамбулой, служебными символами линейного кода и межкадровым интервалом, — а ошибки обнаруживает 32-битовой контрольной последовательностью, не подтверждая доставку и оставляя восстановление потерь транспортному уровню.

Протоколы случайного доступа выросли из ALOHA с её пределом 18,4 % использования канала. CSMA/CD добавил прослушивание среды и обнаружение коллизий, а требование обнаружить коллизию до окончания передачи определило минимальный кадр Ethernet в 64 байта и, следовательно, минимальное поле данных в 46 байтов. С переходом к витой паре, коммутаторам и полнодуплексному режиму коллизии исчезли, но форма кадра осталась прежней — пример того, как совместимость закрепляет исторические решения.

Кадр Ethernet II состоит из адресов назначения и источника, поля EtherType, данных от 46 до 1500 байтов и FCS; значение поля после адресов от 0x0600 и выше означает тип, а не длину. MAC-адрес из 48 битов содержит OUI производителя и два служебных бита — признак группового адреса и признак локального администрирования; рандомизация MAC-адресов в беспроводных сетях использует именно локально администрируемые адреса.

Коммутатор обучается по адресам источника, пересылает по адресу назначения, рассылает лавиной кадры на неизвестные, групповые и широковещательные адреса и забывает неиспользуемые записи через время старения. Он разделяет домены коллизий, но не широковещательные домены. Мост Linux реализует тот же алгоритм программно и служит в курсе основным строительным блоком учебных сетей. Следующая тема разбирает проблемы, которые возникают, когда коммутаторов становится много: разделение сети на виртуальные локальные сети, петли и протокол связующего дерева, агрегирование каналов.

Литература

  1. IEEE Std 802.3-2022. IEEE Standard for Ethernet. — IEEE, 2022.
  2. IEEE Std 802-2014. IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture. — IEEE, 2014.
  3. IEEE Std 802.1Q-2022. IEEE Standard for Local and Metropolitan Area Networks — Bridges and Bridged Networks. — IEEE, 2022.
  4. Metcalfe R. M., Boggs D. R. Ethernet: Distributed Packet Switching for Local Computer Networks. — Communications of the ACM, 1976, Vol. 19, No. 7, P. 395–404, DOI: 10.1145/360248.360253.
  5. Abramson N. The ALOHA System — Another Alternative for Computer Communications. — Proceedings of the Fall Joint Computer Conference (AFIPS '70), 1970, P. 281–285.
  6. Hornig C. A Standard for the Transmission of IP Datagrams over Ethernet Networks. — RFC 894, IETF, 1984. https://www.rfc-editor.org/rfc/rfc894
  7. Kurose J. F., Ross K. W. Computer Networking: A Top-Down Approach. 8th ed. — Pearson, 2021.
  8. Олифер В. Г., Олифер Н. А. Компьютерные сети. Принципы, технологии, протоколы. 5-е изд. — СПб.: Питер, 2016.
  9. The Linux Kernel Documentation. Ethernet Bridging. — 2025. https://docs.kernel.org/networking/bridge.html
  10. bridge(8) — Linux manual page. — man7.org. https://man7.org/linux/man-pages/man8/bridge.8.html
  11. Spurgeon C. E., Zimmerman J. Ethernet: The Definitive Guide. 2nd ed. — O'Reilly Media, 2014.
  12. Boggs D. R., Mogul J. C., Kent C. A. Measured Capacity of an Ethernet: Myths and Reality. — Proceedings of ACM SIGCOMM '88, 1988, P. 222–234.
  13. Eastlake D., Abley J. IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters. — RFC 7042, IETF, 2013. https://www.rfc-editor.org/rfc/rfc7042
  14. IEEE Std 802c-2017. IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture — Amendment 2: Local Medium Access Control (MAC) Address Usage. — IEEE, 2017.