throughtheether

есть ли где-нибудь в интернетах какие-нибудь сводные таблицы, может быть полученные эксперементальным путем, в которых четко указано значение уровня доступности

Не думаю. Даже если они есть, особого смысла в них не вижу. На мой взгляд, практичнее говорить об уровне доступности не отдельного устройства, а программно-аппаратного комплекса в целом. Это, конечно, усложняет расчет метрики, но и учитывает множество специфичных факторов (качество электропитания, вентиляции, взаимодействия технических служб и прочая).

Касательно отдельных устройств, иногда в информлистах (datasheet) к ним указывают значение среднего времени наработки на отказ (mean time between failure, MTBF). Пример, таблица 2, последняя строка.

Можно дать следующую оценку доступности:
Availability=100%*MTBF/(MTBF+MTTR),
где MTTR (mean time to restore) - среднее время приведения отказавшего устройства в рабочее состояние. Но повторюсь, более конструктивным подходом считаю оценку работы всей системы в комплексе.

Я не работал с AP от Cisco, но разве gi1/0/3 не должен быть транком с тегированным 4 вланом?

ловит петлю и отключает порт

Вы уверены, что порт отключается из-за формирования петли (т.е. он переходит в режим blocking/alternate), а не из-за срабатывания, к примеру, root guard?

Кроме того, стоит проверить, нет ли в настройках маршрутизаторов (router 1, router 2) какого-либо форвардинга фреймов (бриджинг, например, или форвардинг BPDU) между портами, указанными на схеме (т.е. не является ли один из маршрутизаторов причиной, по которой root считает, что в наличии петля).

Пока все работает - все стабильно.

Рад, что все работает, но позволю себе еще пару наблюдений (см. исправленную схему топологии). Судя по предоставленным вами данным (см. поля Path cost и Designated bridge ID), вы назначили на sw5 высокую стоимость интерфейсу до sw6, вместо интерфейса до sw4. Также, для устранения дальнейших эффектов (наблюдаются при смене корневого RSTP-коммутатора), лучше назначить интерфейсам линка одно и то же значение стоимости с разных сторон.

на sw5 этот порт пишется alternate, но по факту там трафик в 10 Мбит и по всему кольцу нет места, где трафика нет

Линк блокируется только с одной стороны (sw5). Другая сторона, видимо, продолжает слать трафик и в этот порт, ничего страшного. Я думаю, что это какой-то броадкаст. Если это юникаст, то, теоретически, соответствующая запись таблицы MAC-адресов через некоторое врем должна устареть и быть удалена.

еще заметил странную вещь
на sw1 designated bridge id:
25port 32768-00:15:77:fd:40:00 (id root bridge)
26port 32768-20:fd:f1:96:cb:90 (id this bridge)
на sw2 такая же история: айдишник sw1 и айдишник sw2
а вот на sw5 идет айдишник sw4 и sw6

Это нормально, так и должно быть, учитывая, что именно на sw5 блокируется порт. Можете сравнить с результатами эмуляции.

посидел покурил протоколы, на одном свитче стоял древний протокол, изменил на свежий. На еще одном свитче на линках был включен edge, выключил

Для корректной работы RSTP важно, чтобы edge режим использовался только на портах, подсоединенных к рабочим станциям, чтобы все STP-коммутаторы работали в режиме RSTP, и чтобы линки между коммутаторами работали в режиме p2p. Я, по-моему, неоднократно об этом упоминал.

Вот что получилось по предоставленным вами скриншотам: toster-rstp-costs.pdf

Вот что получилось при эмуляции: toster-rstp-lab-results.pdf

Учитывая разницу в теории и практике, к вам просьба предоставить данные повторно (состояния портов, cost, примерно как здесь ) для коммутаторов sw1-sw5.

Предлагаю аккуратно измерить напряжение между "землями"/корпусами коммутатора, сетевого фильтра и АТС.

Мне кажется или тут все равно что-то не то и при очередном отключении какого-либо свитча трафик не пойдет в обход?

Мне все-таки представляется, что на некоторых портах RSTP выключен и соответствующие коммутаторы всего лишь перенаправляют чужие BPDU (опция BPDU handling, значение flooding). Точнее смогу сказать немного позже, когда разберусь со значениями designated cost - соответствуют ли они топологии.

Возник вопрос

Вы не могли бы прояснить, что означают символы e/d в колонке STP для коммутаторов sw1, sw2, sw5? Если проводить аналогию с корневым коммутатором, то, вероятно, это означает enabled/disabled. Это многое бы объяснило. Проверьте, пожалуйста, чем отличаются настройки для 25 и 26 портов этих коммутаторов (sw1, sw2, sw5).

Предлагаю с маршрутизатора запустить пинг до интересующего вас сервера. Затем посмотреть, формируются ли соответствующие записи в ARP- и MAC-таблицах. В случае с Cisco IOS CLI это можно сделать так

ping 192.168.0.2
show arp
show mac address-table

В вашем случае синтаксис может немного отличаться.

Я вообще полагаю, что из отсутствия ответа на ICMP Echo-request еще не обязательно следует неполадка в маршрутизации. Насколько мне известно, в некоторых случаях (ОС Windows) встроенный фаерволл (брандмауэр) запрещает входящие пинги.

Да, лучше разобраться, какой сервер использует какой влан. Так как вланы 350 и 1 по факту объединены, проще будет посмотреть, IP-адреса из каких префиксов на каком сервере/хосте настроены и дальше уже отобразить префикс на номер влана, используя конфигурацию роутера, находящегося зя коммутатором root.

Предлагаю:
1) для порта 49 коммутатора root задать нетегированный влан 1
2) порт 26 коммутатора sw2 перевести в аксесс-режим (задать нетегированный влан 1)
Делать это желательно поэтапно. Учитывая общую неординарность дизайна сети, стоит быть готовым к её неработоспособности (в том числе отказ управляющего влана), хотя это и маловероятно. То есть лучше это делать в нерабочее время, возможно придется откатывать настройки на месте, используя консольный доступ на коммутатор.

Вот черновая диаграмма топологии. Осталась пара неясностей - модель коммутатора sw5 (судя по MAC-адресу это 3com, у вас указан HP, но пока некритично, думаю) и транк со стороны root до sw1 (на нем, как я понял, тегируются все вланы кроме 1, так какие вланы на нем вообще присутствуют?).

Самое главное - настройки линков sw2<->sw3и root<->sw9. В каждом случае нетегируемый влан с одной стороны 1, с другой - 350. В результате у вас фактически на L2 они объединены. Любой хост из влана 1 может получить доступ к любому хосту во влане 350, при желании. Пока непонятно, почему вообще у вас до сих пор широковещательного шторма не наблюдается, условия для него, как я понимаю, есть.

не может ли мое кольцо не работать из-за этого свитча, который, собственно, отростком в кольце состоит...

Вряд ли причина в этом коммутаторе (о причине ниже), но просьба указать, какие еще STP-коммутаторы есть в L2-домене.

нет, состояния портов не изменились. Действительно, странно.

Я все больше утверждаюсь в предположении, что двусторонней проходимости BPDU на каждом линке не наблюдается, и вероятная причина в неконсистентном распределении вланов по портам. К примеру, коммутаторы Cisco работают в RSTP (IEEE 802.1w) режиме или на аксессных портах, или во влане 1 транков (см. здесь). Я думаю, в вашем случае творчество вендора также вполне вероятно.

Далее, вы писали:

sw3 vlan1<-> vlan1; tag 75,350 sw2 vlan 350; tag 75<-> vlan1; tag 75,350 sw3 vlan1; tag 75,350 <-> trunk vlan1 root bridge vlan350<-> vlan1 sw9

Я не вполне понял, где какие вланы. Вы можете предоставить скриншоты настроек каждого порта в плане вланов и прочего?

Далее, я тут рисую более внятную схему сети, уточните, пожалуйста bridge ID коммутаторов sw3-4,sw6-9. На вашей схеме часть, определяемая MAC-адресом, имеет длину 7 октетов вместо 6 (пример - sw9 32768-20:38:ea:a7:bb:7a:40), я этого тоже не понял.

Я надеюсь, если каждый линк будет настроен одинаково (одинаковые вланы с каждой стороны линка), дерево выстроится как надо. Только пока не будет четкого плана, изменять VLAN-конфигурацию линков нежелательно. Я пока предполагаю, необходим нетегированный влан 1 в каждом линке между коммутаторами.

ничего не изменилось.

На приведенных вами скриншотах ( состояния портов, 1, 2, 3)все порты находятся в состоянии (port state) Forwarding. В случае нормальной работы RSTP в кольце один порт должен быть в состоянии Blocking (вероятно, использован другой, схожий термин). Просьба проверить, не изменилось ли где-либо состояние порта, участвующего в RSTP с Forwarding на Blocking.

И дешевый линк до сих пор в блокировке находится.

Повторяя предыдущее, все порты находятся в состоянии Forwarding, что странно. Скажите пожалуйста, как вы определяете заблокированный статус линка? По уровню трафика?

п.с. есть еще мысли отчего кольцо не срабатывает

Если мои предположения оправдаются и значения root path cost изменятся после отмены режима Edge порта 1 коммутатора sw3, то вероятно RSTP работает нормально,и будем более предметно смотреть на распределение вланов по портам.

Вообще говоря, так как все коммутаторы определили корневой коммутатор правильно, то BPDU хотя бы в одном направлении кольца проходят нормально.

Далее, после того, как переключили порт 1 коммутатора sw3 из режима Edge в обычный, пришлите, пожалуйста, еще раз состояние RSTP-портов всех коммутаторов. Должны измениться значения root port и root path cost на некоторых из них. С вланами предлагаю разобраться позже.

Я подозреваю, до сих пор почему-то BPDU не проходят по кольцу.
Пришлите, пожалуйста, для каждого коммутатора состояние портов-аплинков (в смысле STP) с полной легендой. Как здесь:

И просьба как-то пометить, где какой коммутатор, чтобы скриншоты не перепутались.