Канальный уровень (L2) модели OSI: MAC-адреса, кадры и коммутаторы

Физический уровень умеет передавать биты, но не умеет отличать, где заканчивается одна порция данных и начинается другая. Этим занимается канальный уровень: он упаковывает данные в кадр — со служебной преамбулой в начале, адресом получателя, адресом отправителя, полем типа, самими данными и контрольной суммой в конце.

Зачем нужна контрольная сумма

Последние четыре байта кадра — это CRC, результат вычисления по всему содержимому. Получатель считает то же самое сам и сравнивает. Не сошлось — кадр молча отбрасывается. Никаких запросов «повтори, не расслышал» на этом уровне нет: Ethernet просто выбрасывает испорченное, а разбираться с потерей будет TCP несколькими уровнями выше.

Именно поэтому растущий счётчик CRC-ошибок на порту — такой ценный симптом. Он означает, что до устройства данные доходят, но искажёнными, и виновата почти наверняка физика: кабель, коннектор, наводки.

Кадр не покидает свою сеть

Работает всё это только в пределах одного сегмента. Кадр не переживает перехода через маршрутизатор: там он разбирается, а данные упаковываются в новый кадр уже для следующего участка пути. Поэтому MAC-адрес вашего ноутбука никогда не долетит до сервера в другом городе — за пределами вашей сети про него никто не знает и знать не может.

MAC-адрес — это 48 бит, которые обычно записывают шестью парами шестнадцатеричных цифр: a4:bb:6d:1f:3c:02. Первая половина — идентификатор производителя (его называют OUI), вторая — номер конкретного устройства. По первой половине иногда удобно опознавать железку в таблице коммутатора: видно, что это принтер определённой марки или виртуальная машина на гипервизоре.

Адрес зашит в сетевой интерфейс на заводе, но это не значит, что его нельзя изменить: почти любая ОС позволяет его поменять одной командой, а телефоны сегодня по умолчанию подставляют случайный MAC при подключении к незнакомому Wi-Fi. Поэтому привязывать безопасность исключительно к MAC-адресу — плохая идея: фильтрация по нему отсекает случайных людей, но не того, кто действительно захочет попасть в сеть.

Три типа адресов получателя

• Unicast — кадр адресован одному устройству. Обычный случай.

• Broadcast — адрес ff:ff:ff:ff:ff:ff, кадр уходит во все порты сегмента.

• Multicast — кадр для группы устройств, подписанных на определённый поток. Так работает, например, IPTV внутри сети провайдера.

Никакой магии: коммутатор учится на ходу. Когда в порт приходит кадр, он запоминает пару «адрес отправителя — номер порта» в свою таблицу. Постепенно набирается карта: за первым портом такое-то устройство, за пятым — такое-то.

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

Записи не вечны

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

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

Кадр с широковещательным адресом коммутатор рассылает во все порты. На этом механизме держатся ARP и DHCP: устройство, которому нужно что-то выяснить, буквально кричит в сеть, потому что спросить больше не у кого — адреса собеседника оно ещё не знает.

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

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

У кадра, в отличие от IP-пакета, нет счётчика прожитых переходов (TTL). Совсем. Если случайно соединить два порта коммутатора между собой или замкнуть кольцо через два устройства, широковещательный кадр пойдёт по кругу и будет размножаться на каждом витке.

За считаные секунды сеть забивается мусором и перестаёт отвечать. Симптом опознаваемый: разом «умирают» все, индикаторы портов мигают синхронно и непрерывно, загрузка процессора коммутатора уходит в полку. Часто это происходит после того, как кто-то «прибрался в серверной» или воткнул второй конец патч-корда в свободную розетку, чтобы не болтался.

Как от этого защищаются

Штатное средство — протоколы семейства STP (Spanning Tree). Они обнаруживают кольцо и логически блокируют один из портов, оставляя единственный путь между любыми двумя точками. Если рабочая линия оборвётся, заблокированный порт включится и возьмёт трафик на себя — то есть кольцо из аварии превращается в резерв.

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

Когда связь не работает, а кабель точно живой, следующий шаг — посмотреть на второй уровень. Вопросов немного, и все они проверяемы.

• Видит ли устройство соседей по своей сети — arp -a покажет, с кем вообще был обмен.

• Появился ли его MAC в таблице коммутатора — на управляемых это команда вроде show mac address-table.

• Нет ли в сети двух устройств с одинаковым адресом — тогда запись будет прыгать между портами.

• Не растут ли ошибки и не мигают ли все порты разом — это уже признак петли.

Если на этом уровне всё в порядке, дальше можно спокойно подниматься на третий — к IP-адресам, маскам и маршрутам. И наоборот: пока устройство не видит даже шлюз по MAC, проверять настройки маршрутизации бессмысленно.

Ещё одна вещь, которая происходит на втором уровне, — объединение нескольких физических линков в один логический. Два гигабитных кабеля между коммутаторами превращаются в канал на два гигабита, и заодно получается резерв: оборвался один — трафик идёт по второму. Настраивается это протоколом LACP, а саму связку называют агрегированным каналом или port-channel.

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

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

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

Настройка недооценённая, хотя занимает одну строку на порт. Без неё одно вышедшее из строя устройство кладёт весь сегмент, и найти виновника в упавшей сети непросто. С ней проблема остаётся локальной, а в логах сразу видно, какой порт шумит.