Перейти к содержимому
Калькуляторы

Мистическое поведение linux'ового bridge'a

Добрый день,

 

столкнулся с очень странной проблемой на 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 исчезает и мост работает как часики до следующего "глюка". Замена гигабитной карточки рояля не играет :(

 

Может у кого-нить есть идеи что это за "полтергейтс" и как с ним бороться?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

дублирование. железо старое, надежность ниже желаемого. да и сервера - это все таки софтверная штука, которую надо обновлять - ребуты неизбежны, а постоянно предупреждать всех юзверей надоело :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

идея проста: спаннинг-три перестраивается. чтоб этого избежать, можно попробовать задрать на одном из бриджей приорити, но может не помочь, т.к. неизвестно, как ведут себя с т.зр. сппаннинг-три мыльницы 1 и 3. ИМХО проще из горячего резерва сделать холодный, т.е. включать бридж на 2-м серваке ручками при отказе 1-го сервака

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

то, что он перестраивается - это понятно ;) вопрос в другом: почему после "утряски" топологии мост Б не успокаивается? глюки kernelspace stp процесса? если так - то реально-ли его поменять на RSTP userspace демон из git'a. (в смысле неизвестна его стабильность... )

К вопросу о воркарауде - тогда уж проще на мосте А отрубить STP - мост Б сам встанет в резерв (а нужный активный интерфейс подкрутить portprio параметром). При падении моста А через 50 сек он сам начнет форвардить. Правда это в теории... Насколько стабильно это будет работать на практике - тоже очень интересный вопрос :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.