Linux bridge не знает заранее, за каким интерфейсом находится конкретный MAC-адрес.
Он изучает это динамически, наблюдая за входящими кадрами.
Для этого используется FDB - Forwarding Database.
▪️Сначала bridge учится
Допустим:
eth0 ── PC-A
eth1 ── PC-B
PC-A отправляет кадр с:
src MAC = aa:aa:aa:aa:aa:aa
Bridge видит, что этот MAC пришёл через
eth0, и запоминает:aa:aa:aa:aa:aa:aa → eth0
Посмотреть таблицу:
bridge fdb show
▪️Что происходит с первым кадром
Если bridge ещё не знает MAC назначения:
PC-A → bridge → неизвестный MAC
он не может выбрать конкретный порт.
Поэтому кадр отправляется через все подходящие порты, кроме того, откуда он пришёл.
Это unknown unicast flooding.
Если MAC назначения уже есть в FDB:
aa:aa:aa:aa:aa:aa → eth1
bridge отправляет кадр только через eth1.
Получается:
unknown MAC
↓
flooding
↓
bridge learns MAC
↓
known MAC
↓
unicast
▪️Запись не вечная
FDB содержит динамические записи, и они имеют lifetime.
Посмотреть подробнее:
bridge -d fdb show
Удалить конкретную запись можно, например:
bridge fdb del aa:aa:aa:aa:aa:aa dev eth0
После этого bridge снова должен будет изучить расположение MAC.
▪️Почему это важно
Если FDB постоянно заполняется, очищается или содержит неожиданные MAC, это уже может быть полезным диагностическим сигналом.
Например:
bridge fdb show br br0
может показать, какой MAC bridge сейчас связывает с каждым портом.
А если один MAC начинает «прыгать» между интерфейсами, появляется MAC flapping. Такое бывает при петлях, неправильной коммутации или некоторых схемах виртуализации.
FDB - одна из причин, почему обычный Ethernet-коммутатор не рассылает каждый кадр на все порты: после обучения он знает, куда отправить unicast напрямую.
BashTex 📱 #bash #linux