то, что он перестраивается - это понятно ;) вопрос в другом: почему после "утряски" топологии мост Б не успокаивается? глюки kernelspace stp процесса? если так - то реально-ли его поменять на RSTP userspace демон из git'a. (в смысле неизвестна его стабильность... )
К вопросу о воркарауде - тогда уж проще на мосте А отрубить STP - мост Б сам встанет в резерв (а нужный активный интерфейс подкрутить portprio параметром). При падении моста А через 50 сек он сам начнет форвардить. Правда это в теории... Насколько стабильно это будет работать на практике - тоже очень интересный вопрос :)
дублирование. железо старое, надежность ниже желаемого. да и сервера - это все таки софтверная штука, которую надо обновлять - ребуты неизбежны, а постоянно предупреждать всех юзверей надоело :)
Добрый день,
столкнулся с очень странной проблемой на linux'овом бридже.
Начнем с топологии:
1. DLink ADSL роутер (1 wan + 4 LAN) с включеной трансляцией адресов.
2. 2 параллельных линуксовых бриджа-сервера. 100Мбпс интерфейсы смотрят в сторону АДСЛ роутера. 1Гбпс интерфейсы смотрят в 8-и портовый свитч HP 1400.
3. 8-и портовый свитч HP 1400.
4. 3 независимых АП на базе DD-WRT (sp2) (STP включен) + MythTV backend+frontend + 1 Ubuntu workstation + 2 WinXP workstation.
оба моста с включенным STP. Ubuntu 9.10, 2.6.31-15 bridge-utils из родного репоза. на br интерфейсе обоих мостов висят адреса + VIP + куча сервисов (Exim+Apache+Postgress+NFS+Samba+MythTV backend) (VIP и сервисы разруливаются с помощью heartbeat2)
Странности в поведении мостов:
Мост А висит в FORWARD-FORWARD.
Мост Б - BLOCKED-FORWARD (заблочен 100Мбпс интерфейс)
через некоторое время (от 15 мин до 2-3 дней) мост Б переходит в состояние TOPOLOGY_CHANGE_DETECTED и каждые 5-15 минут начинает "бесится" - на гигабитном интерфейсе при нагрузке около 20 Mbps одноразово генерит ~50 ошибок на TX. При этом интерфейс становится недоступным на 15-30 сек. Затем все проходит на 5-15 минут (трафик идет без ошибок на интерфейсе) и опять по новой. Без нагрузки проблем нет.
лечится это только 1 способом: отключить STP на мосте Б (при этом он переходит в состояние FORWARD-FORWARD, а мост А - BLOCKED-FORWARD) и через некоторое время (2-3 мин) включением STP (при этом он переходит в состояние BLOCKED-FORWARD, а мост А - FORWARD-FORWARD). флаг TOPOLOGY_CHANGE_DETECTED исчезает и мост работает как часики до следующего "глюка". Замена гигабитной карточки рояля не играет :(
Может у кого-нить есть идеи что это за "полтергейтс" и как с ним бороться?