Соединие свиче в кольцо

[SniZ]

привет всем, я знаю, что такая технология не работает с езернете, но я карем уха услышал, что можно както решить эту проблему, типа нужны умные свичи, с технологией транк, может я ошибаюсь, но посоватовали какието Компексы 16портовые, не пинайте меня %)

[Harmer]

:-)) Да уж.

Транки - это другое. Это обьединение нескольких портов в один логический порт, с целью увеличения пропускной способности.

Чтобы свитчи объединять в кольца, свитчи должны уметь STP. Ну или есть еще Лайтком за 70$ со своей фирменной технологией. Правда у нее время переключения 3-5 минут.

[Barsick]

Компексы 16портовые,

Ну или есть еще Лайтком за 70$ со своей фирменной технологией. Правда у нее время переключения 3-5 минут.

На этих компексах http://forum.nag.ru/viewtopic.php?t=15955&...50fd2286d8e84b8 тоже можно настроить loop detect, должен определять петлю за те же 3-5 мин

[Sirco]

Ключевое слово для Google "Spanning tree protocol" а дальше читай в свое удовольствие ;-)

А вот тут написано по русски да еще и критика - а перед тем довольно неплохо описывают что это есть ....

http://www.osp.ru/lan/2002/01/088.htm

[notsaint]

а ещё ищите - "прозрачный мост под линукс" дёшево и сердито и поддерживает STP

[SniZ]

значит берём свичи такие как надо, а сколько надо свичей?

[Nailer]

значит берём свичи такие как надо, а сколько надо свичей?

 

Минимум - один на каждое кольцо. В таком случае время переключения всех клиентов будет около 5 минут.

 

Максимум - каждый свитч в кольце. Переключаться будет за 1 минуту..

[Kuzmich]

Если сеть большая, лучше использовать не STP, а свичи третьего уровня с динамической маршрутизацией (OSPF). STP вырождает любую физическую топологию в дерево, в результате часть проводов простаивает. Маршрутизация позволяет задействовать все линки, направляя трафик по кратчайшему пути.

 

При грамотном проектировании позволяет достичь времени переконфигурации сети в 10-15 секунд.

 

Но это разумно только для сетей, состоящих из нескольких IP-подсетей, иначе просто маршрутизировать окажется нечего...

[LessM]

Максимум - каждый свитч в кольце. Переключаться будет за 1 минуту..

А потом замаещься ждать, пока обычные свичи в другую сторону перелистнутся...

[Nailer]

 

Максимум - каждый свитч в кольце. Переключаться будет за 1 минуту..

А потом замаещься ждать, пока обычные свичи в другую сторону перелистнутся...

 

Дык я и имел в виду, что ВСЕ свитчи с STP и понимают TCN..

[notsaint]

в STP время перепроверки выставляется руками - у меня стоит 5 секунд и работает

[sadmitry]

в STP время перепроверки выставляется руками - у меня стоит 5 секунд и работает

На каких свитчах ?

[notsaint]

Я думаю на любых с нормальным STP а не "собственный протокол Лайтком"

, у меня прозрачные мосты под линуксом с поддержкой STP

[lamer]

"собственный протокол Лайтком"  

А может "собственный протокол REALTEK" будет корректнее? )

[Технократ]

в STP время перепроверки выставляется руками - у меня стоит 5 секунд и работает

Там многое выставляется ручками (и головой).

Вот когда Nailer пишет TCN - понимаю, а что такое время перепроверки - не понимаю.

Значит есть какое-то время проверки и еще перепроверка :)

[Nailer]

в STP время перепроверки выставляется руками - у меня стоит 5 секунд и работает

Там многое выставляется ручками (и головой).

Вот когда Nailer пишет TCN - понимаю, а что такое время перепроверки - не понимаю.

Значит есть какое-то время проверки и еще перепроверка :)

 

Я крутил так, что при потере единичного линка пинг пропадал на 5 сек :-)

 

Чего крутил - не помню. Хелло точно на 1сек ставил.

[Технократ]

Если мне не изменяет память, хелло по-умолчанию 10 сек. И по 15 сек listening and learning. Можно уменьшать, но если что-то зафлипует, то будет песня, а не сеть. Поэтому на стенде разрешается многое.

[notsaint]

notsaint писал(а):  

в STP время перепроверки выставляется руками - у меня стоит 5 секунд и работает

 

 

Там многое выставляется ручками (и головой).  

Вот когда Nailer пишет TCN - понимаю, а что такое время перепроверки - не понимаю.  

Значит есть какое-то время проверки и еще перепроверка :)

Ох зачмырили меня - сдаюсь-сдаюсь, но кажется мне что можно и так сказать - что первая проверка она - "проверка" а все остальные уже "перепроверки" ибо оно уже проверило и теперь перепроверяет :) возражения?

[Nailer]

Если мне не изменяет память, хелло по-умолчанию 10 сек. И по 15 сек listening and learning. Можно уменьшать, но если что-то зафлипует, то будет песня, а не сеть. Поэтому на стенде разрешается многое.

 

Times: hold 1, topology change 35, notification 2

hello 2, max age 20, forward delay 15

[ayamb]

(удалено пользователем)

[Технократ]

Все так, но нормальное железо сейчас реализует per Vlan STP - если грамотно настроить, избыточные каналы не будут простаивать, а будут пропускать другие Vlan.

Единственно MSTP использует RSTP, по крайней мере на каталистах, поэтому решение не дешевое и на мой взгляд проще перейти на 3 уровень.

[ayamb]

(удалено пользователем)

[Nailer]

2. Уровень 3 проще только для ограниченного количества функционалов и топологий сеток. Он не приемлим, например, при передаче из точки в одном конце города в точку на другом конце 16 программ телевидения по гигабитному каналу ethernet. :)

 

Ну почему же :-)

Гоните по IP, нормальные L3-коммутаторы прогонят через себя гигабит не напрягаясь.

[ayamb]

(удалено пользователем)

[Kuzmich]

2. Уровень 3 проще только для ограниченного количества функционалов и топологий сеток. Он не приемлим, например, при передаче из точки в одном конце города в точку на другом конце 16 программ телевидения по гигабитному каналу ethernet. :)

 

А что, L2 это позволяет лучше?

Кроме того, нормальный коммутатор L3 позволит тебе иметь и L2 прараллельно с маршрутизируемой сетью - в другом VLAN'е, проходящем транзитом через L3-коммутаторы...

 

И что такое 16 программ телевидения? При DVD-качетве с потоком в 3,5 мегабита это всё укладывается даже не в гигабит, а в 100 мегабит. А в гигабит свободно и ненапряжно влезет сотня каналов с потоком 8 мегабит. Причем для коммутатора это будет вполне штатной нагрузкой, т.к. пакеты крупные.