throughtheether

По моему, не самому богатому, опыту, от 10 минут (до следующего bgp-пира) и более. Вы можете сами проверить на looking glass пиров вашего провайдера или, если ваш префикс достаточной длины, на looking glass tier-1 оператора (level3, как пример).

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

Вы не могли бы прояснить, что означают символы 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) встроенный фаерволл (брандмауэр) запрещает входящие пинги.

Надо сделать так, чтобы пакет отправлялся не в один, а в несколько портов

Другой возможный способ - воспользоваться RSPAN. Примерно как здесь.
RSPAN, если я правильно понял, на 2960S поддерживается.

Первое - обеспечить доставку пакета только на одно устройство

Если на вашем оборудовании нормально реализован Ethernet (не шлете, например, слишком длинные фреймы, не используете FF:FF:FF:FF:FF:FF в качестве адреса источника во фрейме), то каждому порту будет поставлен в соответствие MAC-адрес устройства (X), к нему подключенного. Фреймы, имеющие X в качестве адреса назначения, будут коммутироваться только в этот порт. Первоначально, пока таблица таких соответствий еще не составлена, фреймы будут коммутироваться на все порты (интерфейсы). Как только устройство ответит фреймом со своим MAC-адресом в качестве адреса источника, запись в таблице появится и фреймы, предназначенные этому устройству, будут коммутироваться только в этот порт. Если это неприемлемо, и надо все приколотить гвоздями с самого начала, поможет команда:

mac-address-table static AA:BB:CC:DD:EE:FF vlan VVV interface fa0/N

Второе - тут я вообще не понимаю, с какой стороны подступиться. Надо сделать так, чтобы пакет отправлялся не в один, а в несколько портов

На некоторых коммутаторах можно командой
no mac-address-table learning vlan VVV
где VVV - номер влана, сделать так, что все фреймы, входящие для интерфейсов в заданном влане, будут скоммутированы (скопированы) на все остальные интерфейсы в этом влане. Именно это вам и надо, как понял. Но я не помню, поддерживает ли 2960S эту команду. Подробнее здесь.

Я с оборудованием Linksys не работал, но мысли такие:

1) доступ между вланами наблюдается, потому что, предположительно, SG300 маршрутизирует трафик между вланами. Проверить можно при помощи (команда Cisco IOS CLI, в Linksys синтаксис может отличаться):
show ip route Почему при подключении к Gi2 (если я правильно понял) не были доступны хосты в других вланах - надо разбираться отдельно (вероятно, некорректный адрес шлюза по умолчанию на хосте, подключаемом к этому порту)

2) Если хотите заблокировать весь трафик влана 102 от проникания в другие вланы, попробуйте (опять же, предполагая синтаксис Cisco IOS CLI):

ip access-list extended vlan102-in
ip access-list extended vlan102-out
interface vlan 102
 ip access-group vlan102-in in
 ip access-group vlan102-out out

Да, лучше разобраться, какой сервер использует какой влан. Так как вланы 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, при желании. Пока непонятно, почему вообще у вас до сих пор широковещательного шторма не наблюдается, условия для него, как я понимаю, есть.

Я небольшой специалист в python, но предполагаю, что основные ресурсы тратятся здесь:

host[ip]['data'] = ''
...
host[ip]['data'] = host[ip]['data'] + d

Почему вы используете словарь как значение ключей внешнего словаря (переменная host)? Попробуйте сделать так:

host[ip] = ''
...
host[ip] = host[ip] + d

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

Вряд ли причина в этом коммутаторе (о причине ниже), но просьба указать, какие еще 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) с полной легендой. Как здесь:

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

Включил, действительно свитчи увидели рут бридж, стоимости нормально посчитали,

Хорошо. Какой линк сейчас блокируется?

RSTP все равно на портах выключен, насколько я могу судить из выделенного. Попробуйте включить RSTP на этих портах (раздел Spanning tree per port в документации).

Также проверьте, на всех линках между коммутаторами режим Edge port обязательно должен быть выключен с каждой стороны. Иногда этот режим называют portfast.

Root guard, если где-то активен, тоже пока надо выключить.

Посмотрите по легенде, обведенные красным значения - это что? Случайно не активность STP на интерфейсе?

Сравните, пожалуйста, конфигурацию STP корневого коммутатора и одного из sw1/sw2/sw5.
Общую конфигурацию STP и по портам-аплинкам до других коммутаторов (страницы 49,58).