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

На L1 у нас просто биты, бегущие по проводу. Чтобы из этого «потока бит» получились кадры (frames) с адресацией, проверкой целостности и порядком — нужен канальный уровень. В современном мире это почти всегда означает Ethernet. Всё остальное — Token Ring, FDDI, ATM — давно ушло в музей.

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

«Заявка #41577. Перевезли бухгалтерию на 3-й этаж. У ПК главбуха сеть „подключено“, адрес получен, но файловый сервер в той же подсети недоступен: ping отвечает „Destination host unreachable“. У соседнего ПК всё работает. Айтишник на месте уже переустановил драйвер сетевой карты». «Host unreachable» в одной подсети — это почти всегда не «интернет сломался», а сбой на канальном уровне: ARP не смог превратить IP сервера в MAC-адрес. Почему это ключевая операция всей локальной сети, как её увидеть в дампе и что проверить на коммутаторе — разберём в этом уроке, а в конце вернёмся к заявке и закроем её.

Что узнаешь — после урока ты сможешь

Разобрать Ethernet-кадр по полям (preamble, MAC, EtherType, payload, FCS) в живом дампе
Прочитать MAC-адрес: найти вендора по OUI, объяснить биты U/L и I/G
Объяснить эволюцию hub → bridge → switch через понятия collision/broadcast domain
Проследить, как свитч учит CAM-таблицу, и предсказать, куда уйдёт кадр с неизвестным MAC
Рассказать ARP-диалог наизусть: кто спрашивает, кто отвечает, что кэшируется и на сколько
Посчитать связку MTU → MSS и диагностировать «пинг ходит, а сайт не открывается»
Различить симптомы L1 (CRC) и L2 (MAC-flapping, ARP-сбои) — и не чинить не тот этаж

Вспомни из модуля 1

Физика доставляет биты: импульсы по меди или свет по стеклу, до 100 м у витой пары, дальше — оптика. Счётчики ошибок интерфейса (CRC, input errors) — первый взгляд диагностики; если там мусор, L2 бессилен. Auto-negotiation договаривается о скорости и дуплексе — сегодня увидишь, что бывает, когда договор сорвался (half-duplex и коллизии). На этом фундаменте строим второй этаж: превращаем поток бит в осмысленные кадры.

1. Что такое Ethernet и почему он победил

Ethernet — это семейство стандартов IEEE 802.3. Придуман в 1973 Бобом Меткалфом в Xerox PARC, в 1980-х вытеснил всех конкурентов (Token Ring, ARCnet) и сегодня живёт от 10 Мбит/с (древний 10BASE-T) до 800 Гбит/с (современный 800GBASE).

Почему именно Ethernet? Простой, открытый, бесконечно масштабируется (тот же кадр работает и на 10М, и на 400G), цена единицы порта падает каждый год.

Эволюция скоростей Ethernet

От 10 Мбит/с до 400 Гбит/с — 40000-кратный рост за 45 лет. Кадр остался прежним.

2. Анатомия Ethernet-кадра

Кадр (frame) — это то, что реально летит по проводу. У него строгая структура из нескольких полей. Понимать байтовое устройство кадра — must для любого, кто работает с tcpdump или Wireshark.

Структура кадра Ethernet II (DIX) — IEEE 802.3

Минимальная длина кадра — 64 байта (с FCS), максимальная — 1518. Меньше — дополняется padding. Больше — нужен Jumbo frame.

Поля по порядку

Preamble (7 байт) — последовательность 10101010 × 7. Нужна, чтобы приёмник вошёл в синхронизацию с битовым потоком отправителя. Не считается частью «полезного» кадра.
SFD (1 байт, 10101011) — Start Frame Delimiter. «Сейчас начнётся настоящий кадр».
Destination MAC (6 байт) — кому. Может быть unicast, multicast или broadcast (FF:FF:FF:FF:FF:FF).
Source MAC (6 байт) — от кого. Всегда unicast.
EtherType (2 байта) — какой протокол лежит внутри payload. По нему ОС/свитч узнаёт, что делать с содержимым.
Payload (46–1500 байт) — собственно данные (IP-пакет, ARP-запрос и т.д.). Если данных меньше 46 байт — добивается padding'ом до минимума.
FCS (4 байта) — Frame Check Sequence, контрольная сумма CRC32. Если не совпала на приёме — кадр дропается.

Откуда минимум 64 байта? Это «time-slot»-наследие старого CSMA/CD half-duplex Ethernet: отправителю нужно успеть детектить коллизию до окончания передачи. На 10 Мбит/с time-slot = 51.2 мкс = 512 бит = 64 байта. Сейчас полнодуплексный Ethernet коллизий не имеет, но минимум так и остался.

3. MAC-адреса — глубоко

MAC-адрес (Media Access Control) — это уникальный 48-битный идентификатор сетевой карты. Записывается шестью парами шестнадцатеричных цифр через двоеточие или дефис: 00:1B:44:11:3A:B7.

Структура MAC-адреса (48 бит)

Чётность первого октета даёт мгновенный ответ на главные вопросы: кому шлём и кто такой.

Префикс OUI	Производитель	Префикс OUI	Производитель
`00:50:56`	VMware	`00:0C:29`	VMware ESXi
`00:1B:21`	Intel	`00:25:90`	Supermicro
`00:50:E4`	Apple	`3C:5A:B4`	Google
`00:0D:3A`	Microsoft (Azure)	`52:54:00`	QEMU/KVM
`D0:50:99`	ASRock	`FC:AA:14`	Gigabyte

Совет. Когда видишь странный MAC в логах — ищи OUI на standards-oui.ieee.org или через утилиту macchanger / ouilookup. Часто помогает быстро понять, что это виртуалка / физическая машина / IoT-устройство.

4. Hub vs Bridge vs Switch

Три устройства, которые когда-то были рядом, но сейчас остался только один. Понимать различие важно — потому что концепции «коллизионного домена» и «broadcast-домена» до сих пор актуальны.

Эволюция: Hub → Bridge → Switch

Hub шлёт кадр всем портам сразу, switch — только нужному получателю. Это уменьшает коллизии и увеличивает throughput на порядки.

5. Как свитч учится — CAM-table learning

Когда коммутатор только включается, его таблица MAC-адресов (CAM, Content-Addressable Memory) пуста. Он не знает, где какой хост. Учится он в процессе работы — по полю Source MAC проходящих кадров.

Алгоритм обучения коммутатора — пошагово

Это основной алгоритм коммутации. На команде show mac address-table ты увидишь эту самую CAM-таблицу в реальном времени.

атака CAM table overflow. Атакующий шлёт миллион поддельных src MAC → таблица переполняется → свитч начинает flooding всё подряд → атакующий снифает чужой трафик. Защита: port security (ограничить число MAC на порт), 802.1X (аутентификация устройств).

6. ARP — как IP превращается в MAC

Хост хочет отправить пакет на IP-адрес. Но в Ethernet-кадре нужен MAC. Как узнать MAC по IP? Через ARP (Address Resolution Protocol), RFC 826. Это «телефонный справочник» локальной сети.

ARP request / reply — как работает резолвинг

Кэш стандартно живёт 60 секунд (Linux) или несколько минут. После — повторный ARP-запрос.

Gratuitous ARP — «представляюсь без спроса»

Хост может сам отправить ARP-«ответ», даже если никто не спрашивал. Цель — обновить ARP-кэши соседей. Используется в:

VRRP/HSRP — при takeover master шлёт gARP с VIP+своим MAC.
Failover keepalived/haproxy — то же самое.
Linux при поднятии интерфейса — чтобы коммутаторы быстрее обновили MAC-table.
ARP spoofing-атаки 😈 — атакующий шлёт gARP «я gateway, мой MAC такой» → MITM.

7. MTU, Jumbo frames и реальные проблемы

MTU (Maximum Transmission Unit) — максимальный размер полезной нагрузки на сетевом интерфейсе. Для Ethernet это 1500 байт. Это критично, потому что:

Стандартный кадр vs Jumbo frame

ВСЕ устройства на пути должны поддерживать jumbo. Один MTU=1500 в середине и пакеты теряются.

Jumbo используется в ДЦ для iSCSI/NFS/бэкапов. В интернет НЕ пускают (PMTUD black hole).

типичный баг «После настройки jumbo пинги короткие проходят, ssh и web виснут». Это MTU mismatch. На одном устройстве MTU=9000, на другом 1500. Маленькие пакеты (ping без -s) проходят, большие (TCP с MSS=1460) — не проходят. Решение: либо везде одинаковый MTU, либо рабочий PMTUD с пропуском ICMP.

MSS vs MTU

MSS (Maximum Segment Size) — это максимум полезной нагрузки TCP (payload TCP-сегмента).

# Для Ethernet MTU 1500: MSS = MTU − IP_header − TCP_header = 1500 − 20 − 20 = 1460 байт # Для туннелей (GRE, IPsec, VXLAN, WireGuard) overhead больше → MSS меньше: GRE: MSS = 1500 − 20 − 20 − 24 = 1436 IPsec ESP: MSS ≈ 1410 (зависит от ciphers) VXLAN: MSS = 1500 − 50 = 1450 WireGuard: MSS = 1500 − 80 = 1420

8. Half-duplex vs Full-duplex

Дуплекс — как ходят кадры по проводу

В современной сети ВСЁ работает в full-duplex. Если в логе interface видишь «half-duplex» — это баг конфига auto-negotiation.

9. Команды для работы с L2

Linux

$ ip link show # интерфейсы и их MAC, состояние, MTU $ ip -s link show eth0 # счётчики rx/tx, errors, drops $ ip link set eth0 mtu 9000 # сменить MTU $ ip link set eth0 address 02:01:02:03:04:05 # сменить MAC (LAA) $ ip neigh # ARP-кэш $ ip neigh flush all # сбросить ARP-кэш $ arping -I eth0 10.0.0.1 # целевой ARP-запрос на интерфейс $ bridge fdb show # MAC-таблица софтового bridge (br0) $ tcpdump -i eth0 -e ether host 00:1b:44:11:3a:b7 # фильтр по MAC

Cisco IOS

switch# show mac address-table # CAM-таблица switch# show mac address-table aging-time # TTL записей switch# show interface gi0/1 switchport # режим порта switch# show interfaces counters errors # CRC errors, runts, giants switch# clear mac address-table dynamic # очистить CAM (для дебага) # Port security — защита от CAM overflow и rogue устройств switch(config-if)# switchport port-security switch(config-if)# switchport port-security maximum 2 switch(config-if)# switchport port-security violation shutdown

Wireshark / tcpdump display filters

# tcpdump $ tcpdump -e -nn ether broadcast # только broadcast-кадры $ tcpdump -e -nn arp # только ARP $ tcpdump -e -nn ether host 00:50:56:01:02:03 # кадры от/к конкретному MAC # Wireshark display filter eth.src == 00:50:56:aa:bb:cc eth.dst == ff:ff:ff:ff:ff:ff arp.opcode == 1 # ARP request arp.opcode == 2 # ARP reply eth.type == 0x0806 # EtherType ARP

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

сценарий 1 «Хосты в одной подсети не пингуются друг друга» → 1) ip neigh — есть ли ARP-запись? 2) tcpdump -ni eth0 arp — уходит ли запрос? Если запрос уходит, ответа нет — проверь, не блокирует ли firewall на получателе ICMP (IPTables INPUT), или VLAN-изоляцию на коммутаторе (private VLAN, port isolation).

сценарий 2 «Интерфейс up, но трафик не идёт. CRC errors растут». → Это L1, а не L2. Возвращайся к уроку 1: патч-корд, обжимка, EMI, грязные оптические разъёмы. L2 ничего не починит, пока на L1 проблема.

сценарий 3 «MAC-flapping в логах коммутатора» → Один и тот же MAC видится то на одном порту, то на другом. Причины: 1) петля (loop) в L2 без STP → MAC мигрирует; 2) кто-то поставил два сервера с одинаковым MAC (баг hypervisor); 3) Гнерируется gratuitous ARP с одной и той же машины через разные порты (NIC bonding active-backup на свитче без MC-LAG). Лечится: STP + BPDU guard, проверкой конфига bonding.

11. Плейбук: «сосед по подсети недоступен» — закрываем заявку #41577

Возвращаемся к бухгалтерии с 3-го этажа: ПК получил адрес, но сервер в той же подсети — «Destination host unreachable». Драйвер тут ни при чём. Ходим по уровням снизу вверх:

Прочитай сообщение об ошибке буквально

«Destination host unreachable» от собственного адреса ПК означает: система даже не смогла отправить пакет — ARP-запрос остался без ответа, MAC получателя неизвестен. Это не «где-то в интернете потерялось», это умерло в пределах локального сегмента. Круг подозреваемых сразу сужается до: ПК ↔ коммутатор ↔ сервер.

Проверь ARP-кэш и повтори резолв

arp -a (Windows) / ip neigh (Linux): запись сервера отсутствует или в состоянии INCOMPLETE/FAILED? Сбрось (arp -d / ip neigh flush) и пингуй снова, параллельно смотри дамп: tcpdump -ni eth0 arp. Запрос «Who has 10.20.3.5?» уходит? Ответа нет? Двигаемся к коммутатору — кадры не доходят или не возвращаются.

Сравни с работающим соседом

Сосед видит сервер — значит, сервер жив и в сети. Отличия между двумя ПК — в порту коммутатора: show interface gi0/14 switchport против рабочего gi0/15. Самая частая находка после переездов: порт остался в другом VLAN (см. следующий модуль) — кадры бухгалтера физически живут в другом broadcast-домене, и его ARP-запрос сервер никогда не услышит.

Проверь port security и состояние порта

Вторая классика переезда: на порту включён switchport port-security с привязкой к MAC старого устройства. Новый MAC → порт в err-disabled или молча дропает кадры. Смотри: show port-security interface gi0/14 и

show interfaces status
        err-disabled

. Лечение: очистить привязку, shutdown / no shutdown.

Убедись, что кадры вообще доходят: CAM-таблица

show mac address-table | include gi0/14 — выучил ли коммутатор MAC бухгалтерского ПК? Нет записи = кадры до коммутатора не доходят (кабель? розетка скоммутирована в другой порт патч-панели?). Есть запись, но в неожиданном VLAN — снова сценарий VLAN-несоответствия.

Отчитайся и закрой

В заявке #41577 оказалось: розетку бухгалтера при переезде скоммутировали в порт, который год назад отдали под гостевой VLAN. ПК получал адрес от гостевого DHCP (потому «сеть подключена»!), но серверная подсеть из гостевого сегмента недостижима. Перевод порта в VLAN бухгалтерии — 2 команды, 5 минут. Драйвер был не виноват.

12. Мини-лаба: Ethernet и ARP у тебя дома

Всё, что разобрали, можно потрогать за 15 минут на любом домашнем ПК:

Найди вендора своего роутера по MAC

arp -a (Windows) / ip neigh (Linux) — найди MAC своего шлюза (обычно 192.168.0.1/192.168.1.1). Возьми первые три байта (OUI) и вбей в поиск «mac oui lookup» + эти байты. Увидишь производителя: TP-Link, Keenetic, Huawei… Тот же приём работает в бою: по OUI в CAM-таблице находят «что за неизвестное устройство воткнули в переговорке».

Посмотри живой ARP-диалог

Открой Wireshark, фильтр arp. Сбрось кэш (arp -d * от администратора / sudo ip neigh flush all) и пингани шлюз. В дампе будет пара: broadcast-запрос «Who has 192.168.1.1? Tell 192.168.1.42» (dst = ff:ff:ff:ff:ff:ff) и unicast-ответ «192.168.1.1 is at xx:xx…». Разверни кадр запроса и найди все поля из раздела 2: dst MAC, src MAC, EtherType 0x0806.

Нащупай MTU своего канала

Windows: ping 8.8.8.8 -f -l 1472 — пройдёт; -l 1473 — «Packet needs to be fragmented but DF set». Магия чисел: 1472 (данные) + 8 (ICMP) + 20 (IP) = ровно 1500, MTU Ethernet. Один байт сверху — и кадр не влезает. Если у тебя PPPoE или VPN, порог окажется ниже (1464, 1432…) — вот и причина легендарного «пинг ходит, сайты не открываются».

Посчитай broadcast-шум своей сети

Оставь Wireshark с фильтром eth.dst == ff:ff:ff:ff:ff:ff на 5 минут. Сколько кадров набежало? Кто шумит (ARP, NetBIOS, mDNS от телевизора)? Каждый такой кадр обязан обработать каждый хост сегмента. Теперь представь сегмент не из 10 устройств, а из 500 — и ты понял, зачем большие сети режут на VLAN (следующий модуль).

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

Термин	По-английски	Смысл в одну строку
Кадр	frame	единица передачи L2: dst/src MAC + EtherType + данные + контрольная сумма FCS
MAC-адрес	MAC address	48-битный адрес сетевой карты: 3 байта вендора (OUI) + 3 байта серийника
Таблица коммутации	CAM / MAC address table	память свитча «какой MAC за каким портом»; учится по src MAC входящих кадров
Флудинг	flooding, unknown unicast	кадр с неизвестным dst MAC копируется во все порты сегмента, кроме входного
Широковещание	broadcast	кадр на ff:ff:ff:ff:ff:ff — обязаны обработать все хосты broadcast-домена
Домен коллизий	collision domain	участок, где кадры могут столкнуться; у свитча — отдельный на каждый порт
Широковещательный домен	broadcast domain	область распространения broadcast; режется только L3 или VLAN
ARP	address resolution protocol	резолвинг IP → MAC: broadcast-вопрос, unicast-ответ, кэш на минуты
Самопроизвольный ARP	gratuitous ARP	анонс своего IP→MAC без вопроса — при старте, смене MAC, failover
MTU	maximum transmission unit	максимум полезной нагрузки кадра; Ethernet-стандарт 1500 байт
Джамбо-кадры	jumbo frames	MTU до ~9000 внутри ДЦ; должны быть включены на каждом устройстве пути
MSS	maximum segment size	максимум данных TCP-сегмента = MTU − 20 (IP) − 20 (TCP) = 1460 при MTU 1500
Дуплекс	duplex, full/half	одновременная передача в обе стороны / по очереди; half сегодня = авария
Миграция MAC	MAC flapping	MAC скачет между портами — признак петли L2 или дублированного MAC
Защита порта	port security	ограничение MAC-адресов на порту; нарушение → err-disabled

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

Задача 1. Свитч только что включили, CAM-таблица пуста. Хост A (порт 1) шлёт кадр хосту B (порт 5). Опиши по шагам, что сделает свитч с этим кадром и со своей таблицей. А с ответным кадром B → A?

Кадр A→B: свитч читает src MAC A → записывает «A за портом 1»; dst MAC B неизвестен → флудит кадр во все порты, кроме 1-го. Ответ B→A: свитч записывает «B за портом 5»; dst MAC A уже в таблице → отправляет только в порт 1. С этого момента диалог A↔B идёт точечно. Правило: учится по источнику, решает по получателю.

Задача 2. MTU канала — 1500. Сколько байт данных приложения влезет в один TCP-сегмент? А если путь идёт через VPN, съедающий 60 байт на инкапсуляцию?

MSS = 1500 − 20 (IP) − 20 (TCP) = 1460 байт. С VPN: эффективный MTU 1440, MSS = 1440 − 40 = 1400 байт. Если VPN не подрежет MSS (MSS clamping), хосты продолжат слать по 1460, пакеты перестанут влезать — и получится «пинг ходит (он маленький), а страницы не грузятся (они большие)».

Задача 3. В дампе видишь кадр с dst MAC 01:00:5e:00:00:fb. Это unicast, broadcast или multicast — и как ты определил?

Multicast. Смотрим младший бит первого октета (I/G-бит): 0x01 — нечётный, бит = 1 → групповой адрес. Broadcast — частный случай (все биты = 1, ff:ff:…). Диапазон 01:00:5e:… — это IPv4-multicast (здесь: mDNS 224.0.0.251, «привет» от умного телевизора).

Задача 4. Пользователь жалуется: «файл на сервер копируется со скоростью дискеты, но всё остальное вроде работает». На порту растут late collisions. Диагноз?

Duplex mismatch: одна сторона full-duplex, другая half. Half-сторона считает канал общим, ловит «коллизии» от встречного трафика и переповторяет кадры. Мелкий трафик (пинг, RDP) почти не страдает, а массовая передача рушится в разы. Лечение: обе стороны в auto (или обе жёстко). Late collisions — фирменная подпись этой беды.

Задача 5. Зачем существует gratuitous ARP, если его никто не спрашивал? Приведи два реальных сценария.

1) Failover: резервный узел кластера забирает виртуальный IP и рассылает gratuitous ARP «этот IP теперь на моём MAC» — иначе соседи до минуты слали бы трафик на мёртвый MAC из кэша. 2) Проверка дубликата IP при старте: если на анонс кто-то ответил — адрес занят. (Бонус: тем же механизмом VRRP/HSRP из модуля 14 переключают шлюз.)

Задача 6. В логах коммутатора «MAC 00:50:56:aa:bb:cc is flapping between Gi0/3 and Gi0/7». Назови три возможные причины и первое действие для каждой.

1) Петля L2 (кто-то соединил два порта кабелем/через мини-свитч): смотри STP-топологию и BPDU guard, физически найди лишний линк. 2) Два устройства с одним MAC (клонированная ВМ): по OUI понять вендора, найти обе точки включения. 3) NIC bonding active-backup, переключающийся туда-сюда: проверить конфиг агрегации на сервере и связку с коммутатором (LACP/MC-LAG). Пока разбираешься — петлю глуши первой: она кладёт весь сегмент.

Ethernet-кадр = Preamble + Dst MAC + Src MAC + EtherType + Payload + FCS.
MAC = 48 бит = OUI (3 байта вендора) + NIC (3 байта серийника). Бит U/L и I/G в первом октете.
HUB → BRIDGE → SWITCH: эволюция от «всем шлю всё» до «учу и шлю точечно».
Свитч учит MAC по полю SrcMAC. Неизвестный dstMAC → flooding. После — unicast.
ARP — резолвинг IP → MAC. Broadcast request, unicast reply. Кэш 60–300 секунд.
MTU 1500 — стандарт. Jumbo 9000 — внутри ДЦ. Везде на пути должен быть одинаковый.
Современная сеть — full-duplex. Half-duplex = баг.
CRC errors → L1. MAC-flapping → L2 loop. ARP не резолвит → проверь broadcast/firewall.

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

В мини-лабе ты видел: каждый broadcast слышат все устройства сегмента. Пока их десяток — неважно; когда их пятьсот, а бухгалтерия юридически не должна видеть трафик разработки, — сегмент надо резать. Резать физически (отдельные коммутаторы) — дорого. Резать логически — это VLAN: один коммутатор, много изолированных сетей. А где несколько путей между коммутаторами, там петли и широковещательные штормы — их укрощает STP. И заметь: заявка #41577 закрылась именно словом «VLAN» — самое время понять, что это такое.