Управление блокировкой порта в linux

А чем плохо как сейчас?

На sw1 прилетает mac от br0 секунд так на 20-30, в то время, как на sw2 он уже есть. В итоге потеря связи с linux. Потом mac на sw1 пропадает, связь налаживается и так по кругу.

коммутаторы управляемые?

Включи stp на мосту и настрой приоритет на нем http://xgu.ru/wiki/Linux_Bridge#.D0.9F.D1.80.D0.B8.D0.BE.D1.80.D0.B8.D1.82.D0.B5.D1.82_.D0.BA.D0.BE.D0.BC.D0.BC.D1.83.D1.82.D0.B0.D1.82.D0.BE.D1.80.D0.B0

И на остальных коммутаторах.

Пока выключил stp на br0, блокировка на sw1 сработала, mac на sw1 не светится. Но от этого не легче, есть несколько таких же сетапов по аналогии - с активным stp, path cost и т.п. Там блокировка срабавтывает именно на свичах. Нихрена не понятно, в чем разница.

Прочитай как работает протокол stp и сделай так, чтобы на мосту выставлялся нужный bridgeid.

Switch Priority в порядке убывания - sw2 - sw1 - br0. sw2 всегда root.

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

Почему именно на нем? А на другом аналогичном сетапе блокировка на свиче?

Да.

По большому счету пофиг где, но вот то, что мак отсвечивает на sw1 это не айс.

Я бы для начала убедился, что с bond0 все хорошо. т.е. отключение одного из интерфейсов не приводит к потерям.

для твоего коммутатора хорошо бы прочитать документацию по настройке bonding + stp. А оно вообще поддерживается? Попадались модели с какими-то ограничениями.

В этой схеме достаточно включить stp на одном коммутаторе, а на остальных устройствах выключить его.

Можно на линуксе уменьшить fd до 0.

достаточно включить stp на одном коммутаторе

И как это будет работать?

Кольцо из 3х устройств достаточно разрезать в одном месте.

За что идет борьба?

А ты не пробовал запретить форвардинг пакетов через мост средствами ebtables? Тем самым ты не будешь создавать кольцо, но будешь использовать подключение к обоим коммутаторам.

Чтобы понять в чём разница нужно понимать как работает STP, а для этого нужно изучить как работают STP и RSTP.

Одно кольцо из любого числа устройств достаточно разрезать в одном месте =)

Свич с отключёным STP будет пробрасывать STP-шные пакеты как бродкасты?

Линуксовый бридж может и будет (а если нет, то можно и ядро пересобрать), а за «любой» свич я б наверное не поручился.

Ну и отключать STP на свиче – сомнительная идея. Сегодня оставишь его только на Sw2, а завтра очередной умник вонзит в Sw1 «свич» без 802.1d и «чтоб быстрее было» подключит двумя портами.

мак отсвечивает на sw1

А это-то чем плохо?

Я же тебе на это ответил.

С bond0 проблем не обнаружно и в конексте STP тоже. В принципе вариант отключения stp на br0 помог, так и оставлю. Но осадок остался.

Чем плохо, что MAC-адрес хоста оказывается известен Sw1?

Ты хочешь, чтобы Sw1 получив пакет для этого хоста слал его во все порты в том же VLAN, что и порт, на котором был получен пакет?

Не просто известен, а известен на порту, на котором линк с eth1, который в свою очередь state blocking со стороны linux.

Раз он известен на порту заблоченном с другой стороны, значит на этот порт прилетел пакет с таким SRC MAC, видимо до блокирования.

Всё штатно. Если хост будет молчать, то запись проэкспайрится, а если будет говорить – то этот адрес прилетит на Sw1 от Sw2.

На управляемых коммутаторах есть 2 фичи: stp и loopback detection.

На клиентских портах lbd полезен, a stp - нет.

значит на этот порт прилетел пакет с таким SRC MAC, видимо до блокирования.

И как это объясняет цикличность? Прилетел, улетел, прилетел….

Ммм… ну, на сиськах есть loop-guard, bpdu-guard и root-guard, не говоря уже про stp portfast, без которого вообще непонятно нафиг так жить.

Но тут-то на схеме три бриджа, а клиент где-то за бриджем.

Откуда ж мне знать отчего у тебя STP «звеня и подпрыгивая» на поворотах?

Всё штатно.

Так зачем ты пытаешься меня убедить, что все штатно? Моя твоя не понимать.

На клиентских портах stp bpdu-guard и stp portfast вообще первым делом .