netwizard Опубликовано 26 января, 2010 · Жалоба Добрый день, столкнулся с очень странной проблемой на 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 исчезает и мост работает как часики до следующего "глюка". Замена гигабитной карточки рояля не играет :( Может у кого-нить есть идеи что это за "полтергейтс" и как с ним бороться? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 28 января, 2010 · Жалоба Зачем вам два моста? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
netwizard Опубликовано 28 января, 2010 · Жалоба дублирование. железо старое, надежность ниже желаемого. да и сервера - это все таки софтверная штука, которую надо обновлять - ребуты неизбежны, а постоянно предупреждать всех юзверей надоело :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ugluck Опубликовано 29 января, 2010 · Жалоба идея проста: спаннинг-три перестраивается. чтоб этого избежать, можно попробовать задрать на одном из бриджей приорити, но может не помочь, т.к. неизвестно, как ведут себя с т.зр. сппаннинг-три мыльницы 1 и 3. ИМХО проще из горячего резерва сделать холодный, т.е. включать бридж на 2-м серваке ручками при отказе 1-го сервака Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
netwizard Опубликовано 29 января, 2010 · Жалоба то, что он перестраивается - это понятно ;) вопрос в другом: почему после "утряски" топологии мост Б не успокаивается? глюки kernelspace stp процесса? если так - то реально-ли его поменять на RSTP userspace демон из git'a. (в смысле неизвестна его стабильность... ) К вопросу о воркарауде - тогда уж проще на мосте А отрубить STP - мост Б сам встанет в резерв (а нужный активный интерфейс подкрутить portprio параметром). При падении моста А через 50 сек он сам начнет форвардить. Правда это в теории... Насколько стабильно это будет работать на практике - тоже очень интересный вопрос :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...