Всем привет!
Посоветуйте L3 коммутатор Cisco уровня ядра.
Маршрутизация порядка 5-7 подсетей, около 200-300 пользователей.
Статическая маршрутизация. Выбор пал на два ус-ва - 3560G-24TS и Сatalyst 3750G-24T. Разница в цене- штука уев. Читал описание и тех. характеристики. Единственное отличие которое я увидел между ними- 3750 стэковый. В остальном (пропускная способность, память и пр.) абсолютно одинаковы. Может есть какие отличия которые я не углядел? Что посоветуете господа? Всем СПАСИБО!
>Всем привет!
>Посоветуйте L3 коммутатор Cisco уровня ядра.
>Маршрутизация порядка 5-7 подсетей, около 200-300 пользователей.
>Статическая маршрутизация. Выбор пал на два ус-ва - 3560G-24TS и Сatalyst 3750G-24T.
>Разница в цене- штука уев. Читал описание и тех. характеристики. Единственное
>отличие которое я увидел между ними- 3750 стэковый. В остальном (пропускная
>способность, память и пр.) абсолютно одинаковы. Может есть какие отличия которые
>я не углядел? Что посоветуете господа? Всем СПАСИБО!C3750-48TS-E у меня пашет на большое кол-во юзеров до 700 и еще ospf работает.
вообще машина очень мощная, проблем не будет.
покрайне мере упиреться в произвордительность врядли удастся...
Разницы кроме стека между ними нет никакой.
Рекомендую взять две штуки и поставить в стек. На них можно будет реализовать Cross-stack Etherchannel, что позволит организовать резервные подключения к ядру сети не используя STP.
>Рекомендую взять две штуки и поставить в стек. На них можно будет
>реализовать Cross-stack Etherchannel, что позволит организовать резервные подключения к ядру сети
>не используя STP.
Всем спасибки
Скорее всего буду брать 3560 (денег дают в обрез)
Тем более, что если оба девайса практически одинаковые и на "вырост" не нужно.
Еще раз спасибо
>Рекомендую взять две штуки и поставить в стек. На них можно будет
>реализовать Cross-stack Etherchannel, что позволит организовать резервные подключения к ядру сети
>не используя STP.Вот как раз в ядре стек не рекомендуется использовать...
Перевыборы мастера в случае сбоя - около минуты downtime.
А от STP надо уходить используя L3 линки.
>Вот как раз в ядре стек не рекомендуется использовать...Ага... шеститонник рекомендует. Впрочем, так же, как и на аксесс...))) Сам шеститонник с 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/ps50...
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/ps50...>А от STP надо уходить используя L3 линки.
Все зависит от политики назначения виланов. Если виланы назначаются по функциональному признаку, то L3 тут не применим. А отказаться от STP можно только через EtherChannel. В случае со стеком это cross-stack etherchannel.
>>Вот как раз в ядре стек не рекомендуется использовать...
>
>Ага... шеститонник рекомендует. Впрочем, так же, как и на аксесс...))) Сам шеститонник
>Шеститонник не предлагаю, в нашей сети от него в 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/ps50...
>
>
>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/ps50...
>
>>А от STP надо уходить используя L3 линки.
>
>Все зависит от политики назначения виланов. Если виланы назначаются по функциональному признаку,
>то L3 тут не применим. А отказаться от STP можно только
>через EtherChannel. В случае со стеком это cross-stack etherchannel.Назначение вланов решается в административном порядке, так что на стадии проектирования это все можно предусмотреть.
В любом случае, если потеря трафика в несколько секунд приемлима, то можно использовать стеки и STP, только непонятно зачем это, если на том же оборудовании можно сделать лучше.
А вообще есть хороший документ по дизайну отказоустойчивых кампусных сетей
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns43...
>Шеститонник не предлагаю, в нашей сети от него в 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/ns43...Одно из правил всякого там проектирования защиты информации, отказоустойчивости и т.д. есть то, что стоимость всех этих систем не должна превышать возможных потерь при простое сети, фальсификации данных или кражи информации. Гайд это хорошо... только на полноту конечного решения больше влияет бюджет, а не его идеальность. Иначе зачем все эти отделы проектирования? Дергай картинки из SRND и вставляй в проект...
>Начнем с того, что я абсолютно не против рутинга в ядре. Разговор
>стоит относительно стека. К примеру, вот две схемы, которые автор темы
>может реализовать... одна со стеком и 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/ns43...
>
>Одно из правил всякого там проектирования защиты информации, отказоустойчивости и т.д. есть
>то, что стоимость всех этих систем не должна превышать возможных потерь
>при простое сети, фальсификации данных или кражи информации. Гайд это хорошо...Золотые слова :))
>Сорри, может не совсем понятно выразился, но имеется ввиду использование L3 не
>только в ядре, а и в аплинках на акцесс.Циска уже давно двигает эту идею. Вопрос в буджете.
>Схема с HSRP совсем неприемлима, т.к. позволяет использовать только один свич в
>одном влане, иначе при падении линка HSRP не отработает, а также
>не будет балансировки.Про баллансировку я понял, а вто что вы имеете ввиду под "не отработает HSRP при падении линка и один свитч в одном вилане?"
>А в случае с L3 в ядре и линках на акцесс потерь
>трафика точно не будет.Да, но схема уже сложнее получается... Все-таки я склонен думать, что все-таки стек не перегружается. А если не перегружается, то вылет одного коммутатора из ядра даже никто не заметит. Etherchannel отработает быстрее. Проверить перегружается ли стек при вылете мастера смогу только на сл. недели.
>А какие же тогда предлагаете???
Хе...))) в ядро 2х6509 с резервными супами и блоками питания. плюс электропитание первой категории. Только тут я бы я полностью гарантировал эти самые секунды и то теоретически. А то малоли что...)))
>>Схема с HSRP совсем неприемлима, т.к. позволяет использовать только один свич в
>>одном влане, иначе при падении линка HSRP не отработает, а также
>>не будет балансировки.
>
>Про баллансировку я понял, а вто что вы имеете ввиду под "не
>отработает HSRP при падении линка и один свитч в одном вилане?"
>
>При падении линка, падает интерфейс vlan на котором настроен hsrp, в случае если на акцесс идет два или больше линков с разных свичей в одном влане, интерфейс влан не упадет и hspr не сработает, в случае падении линка на активный роутер, трафик на акцесс свич пропадет.
Таким образом эта схема предусматривает отказ одного из свичей ядра, но не падение линков (обрыв кабеля, сгоревший порт).
>При падении линка, падает интерфейс vlan на котором настроен hsrp, в случае
>если на акцесс идет два или больше линков с разных свичей
>в одном влане, интерфейс влан не упадет и hspr не сработает,
>в случае падении линка на активный роутер, трафик на акцесс свич
>пропадет.
>Таким образом эта схема предусматривает отказ одного из свичей ядра, но не
>падение линков (обрыв кабеля, сгоревший порт).А с чего вы взяли, что HSRP резервирует линки? HSRP и предназначен для резервирования маршрутизаторов. Для резервирования линков есть STP или EtherChannel. Да и потом, в HSRP есть такая вещь, как interface tracking, которая мониторит состояние интерфейса и на основании этого делает вывод, нужно ли переключаться на резервный маршрутизатор или нет...
В приведенной мною схема (та, что верхняя... с HSRP) в случае падения линка к активному маршрутизатору вместе с физическим интерфейсом упадет и интерфейс вилан, т.к. каждый влан на каждом коммутаторе представлен через один физический интерфейс...
>А с чего вы взяли, что HSRP резервирует линки? HSRP и предназначен
>для резервирования маршрутизаторов. Для резервирования линков есть STP или EtherChannel. ДаЯ и не говорил что HSRP резервирует линки...
>и потом, в HSRP есть такая вещь, как interface tracking, которая
>мониторит состояние интерфейса и на основании этого делает вывод, нужно ли
>переключаться на резервный маршрутизатор или нет...
>В приведенной мною схема (та, что верхняя... с HSRP) в случае падения
>линка к активному маршрутизатору вместе с физическим интерфейсом упадет и интерфейс
>вилан, т.к. каждый влан на каждом коммутаторе представлен через один физический
>интерфейс...В том то и дело что "каждый влан на каждом коммутаторе представлен через один физический интерфейс...", а если необходимо добавить портов в один влан, т.е. подключить еще один свич?
>В том то и дело что "каждый влан на каждом коммутаторе представлен
>через один физический интерфейс...", а если необходимо добавить портов в один
>влан, т.е. подключить еще один свич?А вот это правильный вопрос! В этом решении получается, что да. Эта схема имеет ограничения и подразумевает географическое назначение виланов. Один аксесный свитч - своя база данных виланов. Для назначения виланов по функциональному признаку она не подходит. Вернее теоретически можно конечно, только в случае нештатной ситуации получиться полный бардак... Собственно, те же ограничения как и в случае рутинга между аксесом и кором, где виланы изолированы в сети в пределах аксесных свичей... переехав на другой свич нельзя остаться в своем старом вилане. Я не говорю, что это плохо... циска сама сейчас эту тему и двигает в массы с точки зрения секьюрности и отказоустойчивости. Просто под каждые требования свое решение.
Проверил на стенде, в стеке из пяти свичей при отключении по питанию мастера трафик не прерывается.
Так что согласен, схему с cross-stack etherchannel можно применять для "бюджетных" решений.
>Разницы кроме стека между ними нет никакой.Совершенно верно.
