Приветствую.
Имеется ситуация следующего вида:
Блейд-шасси IBM Blade Center H, в нём два коммутатора IBM BNT Virtual Fabric Switch Module с идентичными настройками, назовём их BNT1 и BNT2 для ясности. Каждый из них подключен по одному линку к Cisco 6509. До кучи, между этими двумя BNT есть прямой линк. Для отключения избыточного линка и во избежание петель в сети на коммутаторах используется PVRST, в котором имеется 128 Spanning Tree Group. По мере заведения на коммутаторе новых виланов, количество свободных STG иссякло, и все новые автоматически добавляются в дефолтную STG за номером 1. Проблемы начались, когда в stg 1 на BNT1 попал седьмой по счёту (в этой группе) вилан. Симптоматика проблем следующая:
1. Назначение портов в группе меняется каждую секунду. Должно быть так:
EXT1 128 20000! DISC ALTN мак-адрес соседнего коммутатора 8011 P2P - линк к соседу
EXT5 128 20000! FWD ROOT мак-адрес Cisco 6509 9116 P2P - линк к шеститоннику
А бывает вот так:
EXT1 128 20000! FWD ROOT мак-адрес соседнего коммутатора 8011 P2P
EXT5 128 20000! DISC DESG свой собственный мак-адрес 8015 P2P
Или вот так:
EXT1 128 20000! DISC DESG мак-адрес соседнего коммутатора 8011 P2P
EXT5 128 20000! FWD ROOT мак-адрес Cisco 6509 8916 P2P
Или даже так:
EXT1 128 20000! DISC ALTN мак-адрес соседнего коммутатора 8011 P2P
EXT5 128 20000! DISC DESG свой собственный мак-адрес 8015 P2P
2. Шеститонник видит на обоих интерфейсах, которыми он подключен к этим BNT, свои же собственные фреймы.
3. По обоим портам к шеститоннику приходят BPDU от BNT1.
4. В вилане, который является седьмым по счёту, вне зависимости от его VLANID, пакеты идут через один. На один ответ — один потерянный.
Есть ли у уважаемого сообщества идеи, как с этим бороться, не перезагружая коммутатор? А то у меня что-то идеи кончились, и осталась только мысль о том, что это глюк, который вылечится ребутом.
Простой