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

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

Что узнаешь

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

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

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

Эволюция скоростей Ethernet
1980 1995 2002 2010 2017 2025 10M 10BASE-T 100M Fast Ethernet 1G Gigabit 10G 10GBASE 100G QSFP28 400G 800G coming Тот же базовый Ethernet-кадр работает на всех скоростях — изменилась только «физика»
От 10 Мбит/с до 400 Гбит/с — 40000-кратный рост за 45 лет. Кадр остался прежним.

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

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

Структура кадра Ethernet II (DIX) — IEEE 802.3
Preamble 7 байт SFD 1 байт Dest MAC 6 байт Src MAC 6 байт EtherType 2 байта Payload (данные) 46 – 1500 байт FCS 4 байта (CRC32) 10101010... синхро NIC 10101011 «старт» кому? от кого? что внутри? IPv4? IPv6? ARP? проверка не побит ли кадр EtherType — что лежит в payload 0x0800 → IPv4 0x0806 → ARP 0x86DD → IPv6 0x8100 → 802.1Q (VLAN) 0x8847 → MPLS 0x88CC → LLDP 0x88A8 → QinQ 0x8809 → LACP / OAM 0x8035 → RARP
Минимальная длина кадра — 64 байта (с FCS), максимальная — 1518. Меньше — дополняется padding. Больше — нужен Jumbo frame.

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

Откуда минимум 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 бит)
00 : 1B : 44 : 11 : 3A : B7 OUI — Organizationally Unique Identifier 24 бита · производитель сетевой карты NIC — Network Interface Controller 24 бита · серийник конкретной NIC Раскладываем первый байт 00 = 0000 0000 0 0 0 0 0 0 0 0 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 U/L I/G U/L bit (Universal/Local) 0 → universal (от вендора, OUI зарегистрирован в IEEE) 1 → locally administered (LAA, назначено вручную) Применяется для VRRP virtual MAC, на VM, для NIC bonding I/G bit (Individual/Group) 0 → unicast (один конкретный получатель) 1 → multicast / broadcast (группа получателей) Broadcast = все 48 бит в 1: FF:FF:FF:FF:FF:FF Примеры 00:1B:44:... — Cisco, universal unicast 02:00:00:... — locally admin (виртуалка) 01:00:5E:... — IPv4 multicast (224.0.0.0/4) 33:33:00:... — IPv6 multicast FF:FF:FF:FF:FF:FF — broadcast
Чётность первого октета даёт мгновенный ответ на главные вопросы: кому шлём и кто такой.
Префикс OUIПроизводительПрефикс OUIПроизводитель
00:50:56VMware00:0C:29VMware ESXi
00:1B:21Intel00:25:90Supermicro
00:50:E4Apple3C:5A:B4Google
00:0D:3AMicrosoft (Azure)52:54:00QEMU/KVM
D0:50:99ASRockFC:AA:14Gigabyte
Совет. Когда видишь странный MAC в логах — ищи OUI на standards-oui.ieee.org или через утилиту macchanger / ouilookup. Часто помогает быстро понять, что это виртуалка / физическая машина / IoT-устройство.

4. Hub vs Bridge vs Switch

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

Эволюция: Hub → Bridge → Switch
HUB (L1) «тупой повторитель» HUB A B C D A→B A→B A→B A→B Шлёт всем = слышит всем Один collision domain Half-duplex, CSMA/CD BRIDGE (L2) «разделяет коллизии» BRIDGE hub L hub R A B C D Учит MAC, фильтрует Каждый сегмент — свой collision domain SWITCH (L2) «bridge на стероидах» SWITCH A B C D A→B Каждый порт — свой collision domain Full-duplex, MAC table Где сейчас применяется HUB — нигде, музей. BRIDGE — в виде программной концепции (Linux bridge, OVS), но как железо — нет. SWITCH — везде. От 8-портового home-свитча до Nexus 9000 с тысячами 100G портов.
Hub шлёт кадр всем портам сразу, switch — только нужному получателю. Это уменьшает коллизии и увеличивает throughput на порядки.

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

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

Алгоритм обучения коммутатора — пошагово
1 A (00:AA) хочет послать кадр на B (00:BB). Свитч ещё ничего не знает. A: 00:AA B: 00:BB C: 00:CC D: 00:DD SWITCH port 1 port 2 port 3 port 4 → frame MAC table MAC port (пусто) 2 Свитч видит src=00:AA на порту 1 → запоминает. Dst=00:BB неизвестен → flooding на все порты, кроме входного. A: 00:AA B: 00:BB C: 00:CC D: 00:DD SWITCH flood (всем кроме входного) MAC table (учим!) MAC port 00:AA 1 3 B отвечает: src=00:BB через port 2. Свитч запоминает и про B. Теперь dst=00:AA известен → отправляет только на port 1. A: 00:AA B: 00:BB C: 00:CC D: 00:DD SWITCH → только port 1 (unicast) MAC table MAC port 00:AA 1 00:BB 2 4 Aging: если запись не обновлялась N минут (по умолчанию 300с/5мин в Cisco) — стирается. Лимит таблицы: ~8000-128000 записей (зависит от модели). При переполнении старые вытесняются или новые игнорируются.
Это основной алгоритм коммутации. На команде 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 — как работает резолвинг
① ARP Request — broadcast Host A IP: 10.0.0.10 MAC: 00:AA «нужен MAC для 10.0.0.20» FF:FF:FF:FF:FF:FF (broadcast) «Кто такой 10.0.0.20?» .30 .40 .20 ✓ .50 все слышат, отвечает только .20 ② ARP Reply — unicast Host A IP: 10.0.0.10 MAC: 00:AA → unicast от 00:BB к 00:AA «я 10.0.0.20, мой MAC 00:BB» Host B .20 00:BB ③ Хост A кэширует в ARP cache. Дальше шлёт unicast напрямую. ARP cache на Host A IP MAC TTL 10.0.0.20 00:BB 120 s Linux команды $ ip neigh # ARP cache  
Кэш стандартно живёт 60 секунд (Linux) или несколько минут. После — повторный ARP-запрос.

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

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

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

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

Стандартный кадр vs Jumbo frame
Стандартный Ethernet-кадр (MTU 1500) hdr payload: 1500 байт FCS ≈ 1518 байт «на проводе» (hdr 14 + payload 1500 + FCS 4) Jumbo frame (MTU 9000) hdr payload: до 9000 байт FCS ≈ 9018 байт. Меньше прерываний, меньше overhead %. Подвох: ВСЕ устройства на пути должны поддерживать 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

Дуплекс — как ходят кадры по проводу
Half-duplex (один провод, по очереди) A B A→B A передаёт, B молчит A B A→B B→A ✦ COLLISION! Оба отбрасывают, случайный backoff, повтор Full-duplex (две пары, одновременно) A B A→B B→A Одновременно в обе стороны Коллизий нет CSMA/CD выключен Эффективная скорость 2× Стандарт со времён 100BASE-TX
В современной сети ВСЁ работает в 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.
Ключевое за этот урок