Как работает Ethernet-коммутатор: MAC-таблица, flooding, STP и сетевые петли

Что делает Ethernet-коммутатор

L2-коммутатор соединяет устройства внутри канального домена и пересылает Ethernet-кадры между портами на основе MAC-адресов. Он не обязан отправлять каждый кадр во все порты, как это делал классический hub.

Основная логика проста:

В обычной L2-пересылке коммутатор работает прежде всего с Ethernet header и VLAN-контекстом. IP-адрес нужен уже L3-маршрутизации. Поэтому один и тот же switch может передавать IPv4, IPv6, ARP и другие Ethernet payload без необходимости «понимать интернет» как маршрутизатор.

Место коммутатора в сетевом стеке разобрано в статье Модель OSI и TCP/IP.

Hub, switch и router - это разные устройства

Какие поля кадра важны коммутатору

Для базового L2 forwarding особенно важны source MAC и destination MAC. При VLAN-схеме учитывается также принадлежность кадра к VLAN.

Source MAC сообщает, откуда кадр пришёл. Destination MAC говорит, кому он предназначен. Коммутатор использует source для обучения forwarding database, а destination - для выбора исходящего порта.

MAC-таблица, FDB и CAM table

Таблицу, по которой bridge/switch принимает L2 forwarding decisions, корректно называть Filtering Database, FDB. В документации оборудования также широко используется название MAC address table.

Термин CAM table часто применяют как бытовой синоним MAC-table, потому что аппаратные коммутаторы традиционно используют content-addressable memory или похожие аппаратные структуры для быстрых lookup. Но FDB - это логическая таблица forwarding, а CAM - конкретный способ реализации памяти. Поэтому эти слова не всегда полностью взаимозаменяемы.

В managed switch таблицу обычно можно посмотреть командой или через web-интерфейс. Название функции зависит от производителя: MAC Address Table, FDB, Forwarding Database, Bridge Hosts и т.п.

Как коммутатор обучается MAC-адресам

Когда кадр приходит на порт, switch анализирует source MAC. Если такого адреса ещё нет в таблице или он раньше был привязан к другому порту, запись создаётся или обновляется для текущего порта и VLAN.

Что происходит, когда destination MAC уже известен

Если FDB содержит destination MAC и этот MAC связан с другим forwarding-портом, кадр отправляется только в этот порт.

Если destination MAC найден на том же порту, откуда кадр пришёл, bridge не должен отправлять его обратно в этот сегмент. Это называют filtering.

Что такое flooding неизвестного unicast

Если destination MAC отсутствует в FDB, switch пока не знает конкретный исходящий порт. Такой unknown unicast обычно реплицируется на остальные forwarding-порты соответствующего VLAN, кроме входного.

Это нормальная часть Ethernet switching. Проблемой flooding становится тогда, когда он происходит массово и постоянно, например из-за неправильного aging, асимметрии, переполнения таблицы или L2-loop.

Актуальная документация Cisco описывает именно такую логику: известный destination отправляется на конкретный порт, неизвестный destination flood-ится внутри того же VLAN.

Чем broadcast отличается от unknown unicast

Ethernet broadcast имеет destination MAC FF:FF:FF:FF:FF:FF. Он предназначен всем участникам broadcast domain и обычно распространяется на все подходящие forwarding-порты VLAN, кроме входного.

ARP Request в IPv4 является знакомым примером Ethernet broadcast. После ARP Request/Reply switch одновременно получает возможность обучиться MAC-адресам участников.

ARP подробно разобран в материале ARP, IP и MAC: ARP-кэш, конфликты IP и Gratuitous ARP.

Multicast нельзя объяснять только правилом «flood во все порты»

Без дополнительной информации L2-switch может распространять multicast внутри VLAN шире, чем реально требуется получателям. Но managed switches часто используют IGMP/MLD snooping и формируют multicast forwarding state, чтобы отправлять поток только туда, где есть заинтересованные receivers.

Multicast и IGMP имеет смысл вынести в отдельный материал, если после завершения этого кластера останется подтверждённый поисковый интент.

Почему динамические MAC-записи не хранятся вечно

Устройства перемещаются между портами, выключаются, меняют topology. Поэтому dynamic FDB entries имеют aging timer. Если source MAC долго не наблюдается на данном порту, запись удаляется и при необходимости будет изучена заново.

Значение 300 секунд является распространённым default в ряде реализаций, включая Linux bridge и многие Cisco switches, но считать его универсальным стандартным значением для любого оборудования нельзя.

Что такое MAC flapping

MAC flapping означает, что один MAC быстро изучается то на одном, то на другом порту. Иногда это объяснимо нормальной topology или virtualized environment, но в обычной домашней/офисной LAN частое flapping часто указывает на петлю, неправильную агрегацию или некорректное подключение.

При loop FDB становится нестабильной: switch видит копии кадров с одинаковыми source MAC с разных направлений и постоянно меняет запись. Cisco прямо указывает MAC flapping как возможный признак loop или misconfiguration.

MAC-таблица работает в контексте VLAN

Managed switch не должен смешивать одинаковый L2 forwarding domain разных VLAN. На практике MAC forwarding entry обычно рассматривается вместе с VLAN/FID-контекстом.

Это разные forwarding contexts. Flooding также ограничивается соответствующим VLAN, а не автоматически всей физической коробкой.

Tagged/untagged ports, access/trunk и разделение камер, IoT и гостей уже подробно разобраны в статье VLAN простыми словами для дома и малого офиса.

Что происходит с MAC learning на trunk

Trunk переносит несколько VLAN между сетевыми устройствами. Поэтому за одним физическим uplink switch может изучить десятки или тысячи MAC из разных VLAN.

Если на uplink видно много MAC, это само по себе нормально. Важно, соответствуют ли они ожидаемым VLAN и topology.

Почему Ethernet-петля так опасна

Представим два коммутатора, соединённые двумя обычными независимыми Ethernet-линками без STP или корректной link aggregation.

Broadcast или flooded frame может пройти A → B по одному линку, вернуться B → A по другому, снова размножиться и продолжить циркуляцию.

Почему кадр не «заканчивается по TTL»

Обычный Ethernet L2 frame не имеет IP TTL/Hop Limit, который маршрутизатор уменьшал бы на каждом L3-hop. Поэтому прозрачная L2-петля не обладает встроенным IP-подобным счётчиком, который гарантированно остановит такой кадр.

Последствия

В актуальном руководстве Cisco по troubleshooting L2 loops broadcast storm рассматривается как один из типичных результатов петли, а повышенные interface input rates рекомендуются как важный диагностический признак.

Что делает Spanning Tree Protocol

STP строит loop-free active topology в bridged Ethernet network. Избыточные физические пути могут существовать, но часть из них не участвует в обычной forwarding topology до тех пор, пока основной путь работает.

Switches обмениваются Bridge Protocol Data Units, BPDUs, и используют priority vectors, path cost и идентификаторы для выбора root bridge и ролей портов.

Зачем STP выбирает root bridge

Root bridge является логической точкой отсчёта spanning tree. Остальные bridges выбирают лучший путь к root по path cost и BPDU-information.

В управляемой сети root лучше выбирать осознанно. Если priority нигде не планируется, root может стать тот switch, у которого просто выиграл Bridge ID, а это не всегда оптимальная topology.

RSTP и классический STP

Rapid Spanning Tree Protocol был разработан для более быстрой convergence при изменениях topology. Исторически он появился как IEEE 802.1w и позже был интегрирован в стандарты bridging IEEE 802.1.

Для практической сети главное отличие не в названии стандарта, а в более быстрой и явной работе с port roles и rapid transitions.

Cisco в актуальной документации описывает STP/RSTP как механизм, который назначает роли портам, оставляет redundant data paths в standby и активирует резерв при отказе основного пути.

Root, designated, alternate и backup port

RSTP разделяет port role и port state. Поэтому понимать только слово «blocked» недостаточно: важно, почему именно этот порт не forwarding и какую роль он выполняет.

Discarding, learning и forwarding

Именно эти три состояния RSTP сопоставляет с более старой STP-моделью; disabled, blocking и listening старой модели объединены в discarding с точки зрения RSTP states.

Что такое edge port и почему его нельзя назначать вслепую

Edge port предназначен для подключения конечного устройства, где за портом не ожидается другой bridge, способный создать L2-loop. Такое определение позволяет RSTP быстрее перевести endpoint-port в рабочее состояние.

В UniFi Network уже встречается Auto STP Edge, но автоматизация не отменяет понимание uplinks и topology. Это отдельно отмечено в вашем материале про UniFi Network 10.5.67.

BPDU Guard, Root Guard и Loop Guard - не одно и то же

У разных производителей названия и детали реализации могут отличаться, но смысл механизмов различается:

LACP не заменяет STP, но правильно объединяет параллельные линки

Если между двумя switches нужны два и более физических линка одновременно, их нельзя просто соединить параллельно и надеяться, что всё заработает. Один из правильных вариантов - собрать их в единый Link Aggregation Group, LAG.

LACP является протоколом управления link aggregation в рамках IEEE 802.1AX. Для STP корректно сформированный aggregate обычно выглядит как один логический link, а распределение flows внутри LAG решает агрегатор.

Практический контекст 2.5G, 10G и агрегации уже разобран в статье 2.5G или 10G Ethernet для дома, NAS и Wi-Fi 7.

LLDP помогает понять topology, но не пересылает пользовательский трафик

LLDP сообщает соседям информацию об устройстве и порте: system name, port ID, capabilities и другие TLV. Это помогает понять, какой switch, access point, IP-телефон или другое устройство подключено к порту.

Но LLDP не строит FDB вместо switch и не является STP. Это discovery-протокол.

Практическая диагностика уже есть в материале LLDP и LLDP-MED: как узнать, что подключено к порту коммутатора.

PoE и Ethernet switching работают рядом, но решают разные задачи

PoE-коммутатор одновременно передаёт данные Ethernet и питание совместимому Powered Device. При этом MAC learning, VLAN, STP и forwarding остаются сетевыми функциями, а PoE budget, class и power negotiation относятся к питанию.

Что умеет обычный неуправляемый коммутатор

Даже простой unmanaged switch обычно выполняет MAC learning, known-unicast forwarding, flooding и aging автоматически. Для этого не нужен web-интерфейс.

Но пользователь часто не может:

• посмотреть FDB;
• увидеть STP topology;
• создать VLAN;
• управлять multicast snooping;
• настроить LACP;
• включить BPDU Guard/Loop Guard;
• посмотреть port counters и errors;
• ограничить storm control.

Поддержка STP/RSTP на unmanaged-моделях зависит от конкретного устройства. Нельзя исходить из предположения, что любой «маленький switch» корректно участвует в spanning tree.

Когда управляемый switch действительно нужен

Managed switch оправдан не ради красивой панели, а когда нужны VLAN, контролируемые uplinks, STP/RSTP, PoE monitoring, LLDP, LACP, multicast control, port statistics или централизованная диагностика.

Как диагностировать L2-проблему по шагам

Как выглядит сетевой L2-loop на практике

Как действовать, если сеть уже попала в broadcast storm

Если сеть практически недоступна, главная задача - остановить цикл. Но перед хаотичным отключением всех кабелей полезно хотя бы зафиксировать, какие uplinks показывают аномально высокий traffic и где MAC flapping.

После локализации loop нужно восстановить правильную topology: один физический link, корректный LAG или redundant links под STP/RSTP, а не просто оставить отключённый кабель без понимания причины.

Что можно увидеть с обычного компьютера

ПК не видит FDB управляемого switch напрямую, но может дать полезные косвенные данные.

arp -a показывает ARP/neighbor information хоста, а не MAC table switch. Это принципиально разные таблицы.

Linux тоже умеет быть Ethernet bridge

Linux bridge реализует L2 bridging программно или совместно с hardware offload. В нём также есть FDB, MAC learning, aging, flooding controls, VLAN filtering и STP state.

Актуальная документация Linux Kernel отдельно описывает FDB learned entries, aging time, per-port learning, unicast flood и STP state, то есть логика программного bridge соответствует тем же фундаментальным понятиям.

Что чаще всего понимают неправильно

• Считать, что switch знает IP каждого устройства для обычного L2 forwarding.
• Считать ARP table и MAC/FDB одной таблицей.
• Думать, что switch учится по destination MAC.
• Считать unknown unicast ошибкой - ограниченный flooding нормален.
• Считать любой multicast обычным broadcast.
• Соединять два switches двумя независимыми кабелями без STP или LAG.
• Отключать STP ради «уменьшения задержки».
• Назначать все ports edge без понимания topology.
• Считать LACP способом ускорить один TCP-flow в N раз.
• Считать VLAN и STP взаимоисключающими функциями.
• Игнорировать MAC flapping.
• Сбрасывать switch до factory defaults вместо анализа FDB/STP/counters.

Как связать Ethernet switching с остальным кластером

На что опирается материал

Частые вопросы про Ethernet-коммутаторы