форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Маршрутизаторы CISCO и др. оборудование. (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Выбор core switch"

Сообщение от kuralesovo (??) on 24-Фев-06, 18:49

Всем привет! Посоветуйте L3 коммутатор Cisco уровня ядра. Маршрутизация порядка 5-7 подсетей, около 200-300 пользователей. Статическая маршрутизация. Выбор пал на два ус-ва - 3560G-24TS и Сatalyst 3750G-24T. Разница в цене- штука уев. Читал описание и тех. характеристики. Единственное отличие которое я увидел между ними- 3750 стэковый. В остальном (пропускная способность, память и пр.) абсолютно одинаковы. Может есть какие отличия которые я не углядел? Что посоветуете господа? Всем СПАСИБО!

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Сообщения по теме

[Сортировка по времени, UBB]

1. "Выбор core switch"

Сообщение от Gnom (??) on 25-Фев-06, 18:39

>Всем привет! >Посоветуйте L3 коммутатор Cisco уровня ядра. >Маршрутизация порядка 5-7 подсетей, около 200-300 пользователей. >Статическая маршрутизация. Выбор пал на два ус-ва - 3560G-24TS и Сatalyst 3750G-24T. >Разница в цене- штука уев. Читал описание и тех. характеристики. Единственное >отличие которое я увидел между ними- 3750 стэковый. В остальном (пропускная >способность, память и пр.) абсолютно одинаковы. Может есть какие отличия которые >я не углядел? Что посоветуете господа? Всем СПАСИБО! C3750-48TS-E у меня пашет на большое кол-во юзеров до 700 и еще ospf работает. вообще машина очень мощная, проблем не будет. покрайне мере упиреться в произвордительность врядли удастся...

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	2. "Выбор core switch"
	Сообщение от Alex (??) on 25-Фев-06, 21:48
	Разницы кроме стека между ними нет никакой.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	3. "Выбор core switch"
	Сообщение от NoSe (??) on 25-Фев-06, 23:58
	Рекомендую взять две штуки и поставить в стек. На них можно будет реализовать Cross-stack Etherchannel, что позволит организовать резервные подключения к ядру сети не используя STP.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	4. "Выбор core switch"
	Сообщение от kuralesovo (??) on 26-Фев-06, 13:06
	>Рекомендую взять две штуки и поставить в стек. На них можно будет >реализовать Cross-stack Etherchannel, что позволит организовать резервные подключения к ядру сети >не используя STP. Всем спасибки Скорее всего буду брать 3560 (денег дают в обрез) Тем более, что если оба девайса практически одинаковые и на "вырост" не  нужно. Еще раз спасибо
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	5. "Выбор core switch"
	Сообщение от Wowa (??) on 26-Фев-06, 13:15
	>Рекомендую взять две штуки и поставить в стек. На них можно будет >реализовать Cross-stack Etherchannel, что позволит организовать резервные подключения к ядру сети >не используя STP. Вот как раз в ядре стек не рекомендуется использовать... Перевыборы мастера в случае сбоя - около минуты downtime. А от STP надо уходить используя L3 линки.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	7. "Выбор core switch"
	Сообщение от NoSe (??) on 27-Фев-06, 14:08
	>Вот как раз в ядре стек не рекомендуется использовать... Ага... шеститонник рекомендует. Впрочем, так же, как и на аксесс...))) Сам шеститонник с DFS модулями, по сути своей, и есть стек... Та же 36Gb Shared bus, как и в случае, с 3750. Так что, все нормально... >Перевыборы мастера в случае сбоя - около минуты downtime. The new stack master becomes available after a few seconds. In the meantime, the switch stack uses the forwarding tables in memory to minimize network disruption. The physical interfaces on the other available stack members are not affected while a new stack master is elected and is resetting. http://www.cisco.com/en/US/partner/products/hw/switches/ps5023/products_configuration_guide_chapter09186a00802c111d.html When one master switch becomes inactive and while a new master is elected, <b>the stack continues to function</b>. Layer 2 connectivity continues unaffected. The new master uses its hot standby unicast table to continue processing unicast traffic. Multicast tables and routing tables are flushed and reloaded to avoid loops... cisco.com. Overview StackWise. http://www.cisco.com/en/US/partner/products/hw/switches/ps5023/products_white_paper09186a00801b096a.shtml#wp40993 >А от STP надо уходить используя L3 линки. Все зависит от политики назначения виланов. Если виланы назначаются по функциональному признаку, то L3 тут не применим. А отказаться от STP можно только через EtherChannel. В случае со стеком это cross-stack etherchannel.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	8. "Выбор core switch"
	Сообщение от Wowa (??) on 28-Фев-06, 09:30
	>>Вот как раз в ядре стек не рекомендуется использовать... > >Ага... шеститонник рекомендует. Впрочем, так же, как и на аксесс...))) Сам шеститонник > Шеститонник не предлагаю, в нашей сети от него в core отказались, а насчет акцесса - только стек 3750, а вот в больших серверных фермах он очень даже хорош. >>Перевыборы мастера в случае сбоя - около минуты downtime. > >The new stack master becomes available after a few seconds. In the >meantime, the switch stack uses the forwarding tables in memory to >minimize network disruption. The physical interfaces on the other available stack >members are not affected while a new stack master is elected >and is resetting. http://www.cisco.com/en/US/partner/products/hw/switches/ps5023/products_configuration_guide_chapter09186a00802c111d.html > > >When one master switch becomes inactive and while a new master is elected, <b>the stack continues to function</b>. Layer 2 connectivity continues unaffected. The new master uses its hot standby unicast table to continue processing unicast traffic. Multicast tables and routing tables are flushed and reloaded to avoid loops... cisco.com. Overview StackWise. http://www.cisco.com/en/US/partner/products/hw/switches/ps5023/products_white_paper09186a00801b096a.shtml#wp40993 > >>А от STP надо уходить используя L3 линки. > >Все зависит от политики назначения виланов. Если виланы назначаются по функциональному признаку, >то L3 тут не применим. А отказаться от STP можно только >через EtherChannel. В случае со стеком это cross-stack etherchannel. Назначение вланов решается в административном порядке, так что на стадии проектирования это все можно предусмотреть. В любом случае, если потеря трафика в несколько секунд приемлима, то можно использовать стеки и STP, только непонятно зачем это, если на том же оборудовании можно сделать лучше. А вообще есть хороший документ по дизайну отказоустойчивых кампусных сетей http://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/cdccont_0900aecd801a8a2d.pdf
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	9. "Выбор core switch"
	Сообщение от NoSe (??) on 28-Фев-06, 16:57
	>Шеститонник не предлагаю, в нашей сети от него в core отказались, а >насчет акцесса - только стек 3750, а вот в больших серверных >фермах он очень даже хорош. О чем и речь. 3750 вообще достаточно удачная железка. В зависимости от требований, ее можно успешно эксплуатировать практически в любой роли. >Назначение вланов решается в административном порядке, так что на стадии проектирования это >все можно предусмотреть. Правильно! Так на стадии проектирования оборудование и подбирается. Сначале решается что нужно, а потом -- как и на чем это реализовывать, а не наоборот... покупается оборудование, а потом решается, что на нем можно построить. > >В любом случае, если потеря трафика в несколько секунд приемлима, то можно >использовать стеки и STP, только непонятно зачем это, если на том >же оборудовании можно сделать лучше. Начнем с того, что я абсолютно не против рутинга в ядре. Разговор стоит относительно стека. К примеру, вот две схемы, которые автор темы может реализовать... одна со стеком и L3 свитчингом, другая без стека и с рутингом. http://nose1980.chat.ru/sw-vs-rt.gif Мало того, что придется использовать EIGRP unequal load ballansing и HSRP, так еще и вланы могут быть назначены только по географическому признаку... В нижней схеме, в случае сбоя на линках, etherchannel быстрее на это отреагирует.. плюс более или менее нормальная баллансировка в обе стороны, что не неполучится реализовать из-за HSRP (GLBP на 3750 по-моему еще не поддерживается). Что касается вылета коммутатора из стека... Как вы думаете, часто ли это будет происходить? Думаю нет... тут главное, чтоб сеть правильно отреагировала и автоматическом режиме перешла в аварийный режим... Циска вроде как гарантирует nonstop forwarding при вылете мастера из стека... хотя, я где-то слышал, что вроде как стек все-таки перегрузится в этом случае... нужно на стенд. Ну а если секундный простой ну совсем неприемлем -- господа, мы не те железки обсуждаем. Ну и как дополнение -- понадобится некоторое количество портов для соединения коммутаторов если не использовать стек. > >А вообще есть хороший документ по дизайну отказоустойчивых кампусных сетей >http://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/cdccont_0900aecd801a8a2d.pdf Одно из правил всякого там проектирования защиты информации, отказоустойчивости и т.д. есть то, что стоимость всех этих систем не должна превышать возможных потерь при простое сети, фальсификации данных или кражи информации. Гайд это хорошо... только на полноту конечного решения больше влияет бюджет, а не его идеальность. Иначе зачем все эти отделы проектирования? Дергай картинки из SRND и вставляй в проект...
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	10. "Выбор core switch"
	Сообщение от Wowa (??) on 01-Мрт-06, 12:28
	>Начнем с того, что я абсолютно не против рутинга в ядре. Разговор >стоит относительно стека. К примеру, вот две схемы, которые автор темы >может реализовать... одна со стеком и L3 свитчингом, другая без стека >и с рутингом. http://nose1980.chat.ru/sw-vs-rt.gif Сорри, может не совсем понятно выразился, но имеется ввиду использование L3 не только в ядре, а и в аплинках на акцесс. >Мало того, что придется использовать EIGRP unequal >load ballansing и HSRP, так еще и вланы могут быть назначены >только по географическому признаку... >В нижней схеме, в случае сбоя на линках, etherchannel быстрее на это >отреагирует.. плюс более или менее нормальная баллансировка в обе стороны, что >не неполучится реализовать из-за HSRP (GLBP на 3750 по-моему еще не >поддерживается). Схема с HSRP совсем неприемлима, т.к. позволяет использовать только один свич в одном влане, иначе при падении линка HSRP не отработает, а также не будет балансировки. >Что касается вылета коммутатора из стека... Как вы думаете, часто >ли это будет происходить? Думаю нет... тут главное, чтоб сеть правильно >отреагировала и автоматическом режиме перешла в аварийный режим... Циска вроде как >гарантирует nonstop forwarding при вылете мастера из стека... хотя, я где-то >слышал, что вроде как стек все-таки перегрузится в этом случае... нужно >на стенд. А в случае с L3 в ядре и линках на акцесс потерь трафика точно не будет. >Ну а если секундный простой ну совсем неприемлем -- >господа, мы не те железки обсуждаем. А какие же тогда предлагаете??? >Ну и как дополнение -- >понадобится некоторое количество портов для соединения коммутаторов если не использовать стек. > > >> >>А вообще есть хороший документ по дизайну отказоустойчивых кампусных сетей >>http://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/cdccont_0900aecd801a8a2d.pdf > >Одно из правил всякого там проектирования защиты информации, отказоустойчивости и т.д. есть >то, что стоимость всех этих систем не должна превышать возможных потерь >при простое сети, фальсификации данных или кражи информации. Гайд это хорошо... Золотые слова :))
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	11. "Выбор core switch"
	Сообщение от NoSe (??) on 01-Мрт-06, 13:57
	>Сорри, может не совсем понятно выразился, но имеется ввиду использование L3 не >только в ядре, а и в аплинках на акцесс. Циска уже давно двигает эту идею. Вопрос в буджете. >Схема с HSRP совсем неприемлима, т.к. позволяет использовать только один свич в >одном влане, иначе при падении линка HSRP не отработает, а также >не будет балансировки. Про баллансировку я понял, а вто что вы имеете ввиду под "не отработает HSRP при падении линка и один свитч в одном вилане?" >А в случае с L3 в ядре и линках на акцесс потерь >трафика точно не будет. Да, но схема уже сложнее получается... Все-таки я склонен думать, что все-таки стек не перегружается. А если не перегружается, то вылет одного коммутатора из ядра даже никто не заметит. Etherchannel отработает быстрее. Проверить перегружается ли стек при вылете мастера смогу только на сл. недели. >А какие же тогда предлагаете??? Хе...))) в ядро 2х6509 с резервными супами и блоками питания. плюс электропитание первой категории. Только тут я бы я полностью гарантировал эти самые секунды и то теоретически. А то малоли что...)))
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	12. "Выбор core switch"
	Сообщение от Wowa (??) on 01-Мрт-06, 14:59
	>>Схема с HSRP совсем неприемлима, т.к. позволяет использовать только один свич в >>одном влане, иначе при падении линка HSRP не отработает, а также >>не будет балансировки. > >Про баллансировку я понял, а вто что вы имеете ввиду под "не >отработает HSRP при падении линка и один свитч в одном вилане?" > > При падении линка, падает интерфейс vlan на котором настроен hsrp, в случае если на акцесс идет два или больше линков с разных свичей в одном влане, интерфейс влан не упадет и hspr не сработает, в случае падении линка на активный роутер, трафик на акцесс свич пропадет. Таким образом эта схема предусматривает отказ одного из свичей ядра, но не падение линков (обрыв кабеля, сгоревший порт).
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	13. "Выбор core switch"
	Сообщение от NoSe (??) on 01-Мрт-06, 17:02
	>При падении линка, падает интерфейс vlan на котором настроен hsrp, в случае >если на акцесс идет два или больше линков с разных свичей >в одном влане, интерфейс влан не упадет и hspr не сработает, >в случае падении линка на активный роутер, трафик на акцесс свич >пропадет. >Таким образом эта схема предусматривает отказ одного из свичей ядра, но не >падение линков (обрыв кабеля, сгоревший порт). А с чего вы взяли, что HSRP резервирует линки? HSRP и предназначен для резервирования маршрутизаторов. Для резервирования линков есть STP или EtherChannel. Да и потом, в HSRP есть такая вещь, как interface tracking, которая мониторит состояние интерфейса и на основании этого делает вывод, нужно ли переключаться на резервный маршрутизатор или нет... В приведенной мною схема (та, что верхняя... с HSRP) в случае падения линка к активному маршрутизатору вместе с физическим интерфейсом упадет и интерфейс вилан, т.к. каждый влан на каждом коммутаторе представлен через один физический интерфейс...
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	14. "Выбор core switch"
	Сообщение от Wowa (??) on 01-Мрт-06, 17:55
	>А с чего вы взяли, что HSRP резервирует линки? HSRP и предназначен >для резервирования маршрутизаторов. Для резервирования линков есть STP или EtherChannel. Да Я и не говорил что HSRP резервирует линки... >и потом, в HSRP есть такая вещь, как interface tracking, которая >мониторит состояние интерфейса и на основании этого делает вывод, нужно ли >переключаться на резервный маршрутизатор или нет... >В приведенной мною схема (та, что верхняя... с HSRP) в случае падения >линка к активному маршрутизатору вместе с физическим интерфейсом упадет и интерфейс >вилан, т.к. каждый влан на каждом коммутаторе представлен через один физический >интерфейс... В том то и дело что "каждый влан на каждом коммутаторе представлен через один физический интерфейс...", а если необходимо добавить портов в один влан, т.е. подключить еще один свич?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	15. "Выбор core switch"
	Сообщение от NoSe (??) on 01-Мрт-06, 19:00
	>В том то и дело что "каждый влан на каждом коммутаторе представлен >через один физический интерфейс...", а если необходимо добавить портов в один >влан, т.е. подключить еще один свич? А вот это правильный вопрос! В этом решении получается, что да. Эта схема имеет ограничения и подразумевает географическое назначение виланов. Один аксесный свитч - своя база данных виланов. Для назначения виланов по функциональному признаку она не подходит. Вернее теоретически можно конечно, только в случае нештатной ситуации получиться полный бардак... Собственно, те же ограничения как и в случае рутинга между аксесом и кором, где виланы изолированы в сети в пределах аксесных свичей... переехав на другой свич нельзя остаться в своем старом вилане. Я не говорю, что это плохо... циска сама сейчас эту тему и двигает в массы с точки зрения секьюрности и отказоустойчивости. Просто под каждые требования свое решение.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	16. "Выбор core switch"
	Сообщение от Wowa (??) on 06-Мрт-06, 10:40
	Проверил на стенде, в стеке из пяти свичей при отключении по питанию мастера трафик не прерывается. Так что согласен, схему с cross-stack etherchannel можно применять для "бюджетных" решений.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	6. "Выбор core switch"
	Сообщение от Wowa (??) on 26-Фев-06, 13:16
	>Разницы кроме стека между ними нет никакой. Совершенно верно.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]