Guest Posted July 26, 2004 Posted July 26, 2004 А где посмотреть поддерживает свич STP протокол или нет? а то весь инет излазил... Вставить ник Quote
Guest Posted July 26, 2004 Posted July 26, 2004 Всем бОльшое спасибо!!! откликнулись ВСЕ разом :( Вставить ник Quote
Guest Posted July 26, 2004 Posted July 26, 2004 Всем бОльшое спасибо!!! откликнулись ВСЕ разом :( Так а что ты хочешь - это индивидуально для каждого свитча, и смотрися в руководстве либо на сайте производителя. Если бы ты указал модель свитча, то возможно, кто-либо и откликнулся... Вставить ник Quote
Guest Posted July 26, 2004 Posted July 26, 2004 Проблема в том, что я подбираю свичи для последующего подключения их в кольцо. Смотрел на D-Link DES-1008(5), а не где не написано что он поддерживает STP... Какие из не дорогих свичей поддерживают данный протокол? Вставить ник Quote
Sirco Posted July 26, 2004 Posted July 26, 2004 не дорогих нету с STP.... Это управляемые только могут .... да и ненадо чтобы все свичи в кольце поддерживали STP достаточно одного (центрального) он будет тогда выбирать или по одному порту пускать или по другому если 1 упал. ты бы зарегистрировался - а то не понятно с кем разговариваеш .... Вставить ник Quote
teodor Posted July 26, 2004 Posted July 26, 2004 Хорошо, а в сети все свичи должны поддерживать STP или только в узлах? Вставить ник Quote
teodor Posted July 26, 2004 Posted July 26, 2004 Немного информации по STP я нашел (http://www.rrs.ru/article_astra2.shtml), но так и не понял между свичами поддерживающих STP можно ставить простые или нет? Вставить ник Quote
Guest Posted July 26, 2004 Posted July 26, 2004 Des1005/1008D не поддерживают STP. Ставить обычные свитчи между умеющими STP можно. Но в рамках домашней сети STP нафиг не нужно. Вставить ник Quote
Askel Posted July 26, 2004 Posted July 26, 2004 Это как посмотреть... сразу нафиг ненужен Наоборот очень даже и нужно! Вставить ник Quote
Guest Posted July 26, 2004 Posted July 26, 2004 Надо клиентам объявляет реальные сроки восстановления работоспособности сети, вот и весь STP. Если есть круглосуточные операторы, то за 8-10 часов вполне реально поменять пару воздушек и активку. Вставить ник Quote
repa Posted July 27, 2004 Posted July 27, 2004 Примечание: Если ставить комутатор с STP тока на узле, то при образовании петли на неуправляемом коммутаторе заблокируются оба порта. И скорее всего после устранения петли (лечебный хвостик), придется вручную разблокировать оба порта. Полезные функции STP для ДС 1. При обрыве линка включается в работу резервный. 2. При выгорании портов на неуправляемых коммутаторах, выключаться из работы будет только часть сети. Вставить ник Quote
pkozik Posted July 27, 2004 Posted July 27, 2004 Если ставить комутатор с STP тока на узле, то при образовании петли на неуправляемом коммутаторе заблокируются оба порта. Это еще с какой такой травы?? Порты может отключать только управляемый коммутатор - один из двух портов петли будет программно отключен (discarding в 802.1w). При разрыве петли отключенный порт автоматически перейдет в состояние коммутации пакетов. Вставить ник Quote
repa Posted July 27, 2004 Posted July 27, 2004 Один из двух будет отключен до образования петли. После образования петли заблокируюся оба порта управляемого коммутатора. Необязательно, что в этот момент в сегменте будет бродкаст шторм. Но из "нездорового" сегмента в "здоровый" пакеты ходить не будут. После устранения петли на неуправляемом коммутаторе, на Nortel-овском оборудовании автоматическое востановления работы портов не происходит. На каком оборудовании вы проверяли STP? Вставить ник Quote
pkozik Posted July 27, 2004 Posted July 27, 2004 Какая разница какое оборудование? Есть стандарты 802.1d, 802.1w (уже и 802.1s есть, но не читал). Корневой коммутатор (ROOT switch в STP) регулярно рассылает спецпакеты BPDU. Если он получает свой-же пакет на каком-то порту (что возможно при условии петли), то порт в петле с большим номером отключается (в общем случае). При этом второй порт работает в нормальном режиме. Как только на отключенный порт перестают приходить свои пакеты BPDU (при разрыве петли) коммутатор разблокирует порт, и переводит его в состояние коммутации пакетов. Вся прелесть стандартов именно в их автоматизме, админу не надо при изменении топологиии бегать по всей сети. Соответственно неуправляемые коммутаторы не могут участвовать в работе протоколов (они не понимают BPDU), отключать что-то они тоже не должны. Если на вашей железке работает как-то иначе - значит либо STP кривой, либо его совсем нет, либо настроено все ой как непонятно. Вставить ник Quote
repa Posted July 27, 2004 Posted July 27, 2004 Касательно анализа реализаци STP стандарта на Nortel-овском оборудовании, то я его не проводил. Что касается той схемы, что ты описываешь, то вней ничего удивительного нет. Оно так и работает. Ты попробуй следующу: Подключаешь к ROOT коммутатору неуправляемый одним (1) линком. Подключашь к неуправляемому комутатору комп. Ставишь что-нибудь на закачку. Берешь кросоверный патч и на неуправляемом коммутаторе соединяешь между собой два порта. Обращаю еще раз внимание педля делается на неуправляемом коммутаторе. Теперь ROOT комутатор свой же пакет BPDU получит на томже порту на котором он вышел!!!!! Упеждаемся, что закачка прекратилась. После этого разрываем петлю и пытаемся выяснить через какое время востановится работа машины в сети.... Очень надеюсь, что вы проделаете вышеописаные действия и скажите результаты. А после сделаем выводы юзабельности коммутаторов с STP от разных производителей, а также будем открывать стандарт и приводить выдержки из него. З.Ы. Порт после молнии, зачастую представляет из себя петлю между двумя портами. Вышеприведеная ситуация, более чем реальная. Вставить ник Quote
teodor Posted July 27, 2004 Posted July 27, 2004 Спосиби большое, repa, за доходчиво донесённую информацию. Вставить ник Quote
pkozik Posted July 27, 2004 Posted July 27, 2004 тестим D-Link DGS-3312SR. запущен RSTP: DGS-3312SR:4#sh stp Command: show stp Bridge Parameters Settings STP Status : Enabled Max Age : 20 Hello Time : 2 Forward Delay : 15 Priority : 32768 STP Version : RSTP TX Hold Count : 3 Forwarding BPDU : Enabled Bridge Current Status Designated Root Bridge : 00-0D-88-62-5C-E0 Root Priority : 32768 Cost to Root : 0 Root Port : None Last Topology Change : 322sec Topology Changes Count : 6 Protocol Specification : 3 Max Age : 20 Hello Time : 2 Forward Delay : 15 Hold Time : 3 Подключаю к нему в пятый порт шлюз di-624+ (используется только его коммутатор). Сам сижу на ДГС, пингую этот шлюз: Reply from 192.168.0.1: bytes=1000 time<1ms TTL=127 Reply from 192.168.0.1: bytes=1000 time<1ms TTL=127 Reply from 192.168.0.1: bytes=1000 time<1ms TTL=127 Reply from 192.168.0.1: bytes=1000 time<1ms TTL=127 Reply from 192.168.0.1: bytes=1000 time<1ms TTL=127 Reply from 192.168.0.1: bytes=1000 time<1ms TTL=127 Reply from 192.168.0.1: bytes=1000 time<1ms TTL=127 Reply from 192.168.0.1: bytes=1000 time<1ms TTL=127 Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Request timed out. Reply from 192.168.0.1: bytes=1000 time=52ms TTL=127 Request timed out. Reply from 192.168.0.1: bytes=1000 time<1ms TTL=127 Reply from 192.168.0.1: bytes=1000 time<1ms TTL=127 Посередине потерянные пинги - это момент создания петли между портами коммутатора на di-624 (т.е. как выше и описывали). После разрывания петли пинги опять пошли, без вмешательства. Статистика на порту, к которому подключался di-624: DGS-3312SR:4#sh pa po 15:5 Command: show packet ports 15:5 Port number : 15:5 Frame Size Frame Counts Frames/sec Frame Type Total Total/sec ------------ ------------ ---------- ---------- ---------- --------- 64 9495 0 RX Bytes 441348604 0 65-127 4901005 1 RX Frames 5269232 0 128-255 5 0 256-511 359273 0 TX Bytes 129820 68 512-1023 3 0 TX Frames 670 1 1024-1518 121 0 Unicast RX 97 0 Multicast RX 5259932 0 Broadcast RX 9203 0 Порт коммутатора не отключался, но в такой схеме он по стандарту и не должен отключатся. Единственный выход, вероятно, в построении всей сети на управляемых с запущенным STP... Либо настройка функции Broadcast Storm Control: DGS-3312SR:4#sh traffic con Command: show traffic control Traffic Control Broadcast Multicast Destination Unit Group [ports] Threshold Storm Storm Lookup Fail ---- ------------- --------- --------- --------- ----------- 15 1 [ 1 ] 128 Disabled Disabled Disabled 15 2 [ 2 ] 128 Disabled Disabled Disabled 15 3 [ 3 ] 128 Disabled Disabled Disabled 15 4 [ 4 ] 128 Disabled Disabled Disabled 15 5 [ 5 ] 128 Disabled Disabled Disabled 15 6 [ 6 ] 128 Disabled Disabled Disabled 15 7 [ 7 ] 128 Disabled Disabled Disabled 15 8 [ 8 ] 128 Disabled Disabled Disabled 15 9 [ 9 ] 128 Disabled Disabled Disabled 15 10[ 10 ] 128 Disabled Disabled Disabled 15 11[ 11 ] 128 Disabled Disabled Disabled 15 12[ 12 ] 128 Disabled Disabled Disabled Total Entries: 12 В результатет чего бОльшую часть пакетов из этой петли коммутатор просто будет дропать (планка задается). И кроме этого сегмента никто серьезно не пострадает. Вставить ник Quote
repa Posted July 28, 2004 Posted July 28, 2004 Спасибо, за поведеный эксперимент. Теперь, есть основания задуматься о не коректной реализации STP протокола на BayStack-ах 450. Вставить ник Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.