Здравствуйте.
Есть организация порядка 300компов в главном офисе, + несколько филиалов.
В каждом офисе есть основной канал и резервный, главном и того больше.
НО. На каждом канале висит либо pix либо asa, но при этом нет не одного маршрутизатора.
Нет как такового нормально организованного ядра сети. Т.е, чтобы переключится на другой канал, на серверах приходится переписывать маршруты ))) НУ ладно это вступление.
Настал момент когда нужно все перестраивать. Опыта у меня мало в построении крупных систем с серьезным оборудованием, поэтому хочу посоветоваться.
Первое что хочется, это создать нормальное ядро сети с отказоустойчивостью шлюза по умолчанию, здесь у нас первый спор с шефом, он хочет ставить маршрутизаторы, я хочу свитчи третьего уровня в стек, либо которые поддерживаются протоколы типа HSRP (отказоустойчивости шлюза по умолчанию). Вопрос кто прав? Если я, как обосновать, почему именно свитчи. И какие модели можете посоветовать для данной задачи.
Далее, на каждом канале, соответственно на ASA или Pix, которые стоят на границе данного канала, есть соответственно порт в локаль и DMZ, т.е, для DMZ сети получается нужно будет покупать также пару оборудования для маршрутизации с отказойстойчивость.Пока все, по мере ответов будут новые вопросы :) Не хочу пока все сваливать в кучу, хочется много чего обсудить.
Спасибо.
>[оверквотинг удален]
> протоколы типа HSRP (отказоустойчивости шлюза по умолчанию). Вопрос кто прав? Если
> я, как обосновать, почему именно свитчи. И какие модели можете посоветовать
> для данной задачи.
> Далее, на каждом канале, соответственно на ASA или Pix, которые стоят на
> границе данного канала, есть соответственно порт в локаль и DMZ, т.е,
> для DMZ сети получается нужно будет покупать также пару оборудования для
> маршрутизации с отказойстойчивость.
> Пока все, по мере ответов будут новые вопросы :) Не хочу пока
> все сваливать в кучу, хочется много чего обсудить.
> Спасибо.FHRP в ядро? боже упаси. Делайте через протоколы динамической маршрутизации.
А по поводу филлилалов, я бы в главный офис поставил две 7200( если денег не жалко конечно) в филлиалы что-нибудь попроще( зависит от потребностей). Между всем этим хозяйством DMVPN и ospf (или EIGRP).
а локалку я бы конечно роутил на коммутаторах ну там 3750 или если денег не жалко 6500 с Sup 32
300 ПК это не много. В ядро ставьте 3750 стекируемый никаких роутеров - они умрут при первом серьезном бекапировании. Кстати 3750 L3 поддерживают поднимите динамику и будет порядок. Если все цисковское - то поднимайте EIGRP по мой взгляд лучшего не придумали для распределённой сети.
HSRP GLBP это технологии которые скорее резервируют маршрутизатор чем сеть.Вопрос номер 2 каналы/тунели/резервирование:
Строить Easy VPN на ASA конечно можно но работа такого канала оставляет желать лучшего (часто без каких либо причит залипает канал, он как бы есть но он как бы не с нами и все коректно ошибок нет вот только трафик в нем не бегает) переключение на резерв происходит с большой по сетевым меркам задержкой, если будет еще и редистрибъюция в АСА то вообще глына.
Я бы рекомендовал стоить GRE+IPSEC на маршрутизаторах.Вопрос 3
ДМЗ построить отдельной подсетью и в разрез вставить PIX/ASA (заодно и слепить active/active or active/standby failover )а от них линк в 3750.
> В ядро ставьте 3750 стекируемый никаких роутеров
> - они умрут при первом серьезном бекапировании.Бред. С чего они должны умереть?
Я имел ввиду роутеры ставить в качестве edge, на них же и туннели, а ниже коммутаторы для аггрегации и "inter-VLAN routing".
По поводу GRE+IPSEC согласен, только на мой взгляд если филлиалов много лучше DMVPN.
http://xgu.ru/wiki/%D0%9D%D0%B0%D1&...
> 300 ПК это не много. В ядро ставьте 3750 стекируемый никаких роутеров
> - они умрут при первом серьезном бекапировании. Кстати 3750 L3 поддерживают
> поднимите динамику и будет порядок. Если все цисковское - то поднимайте
> EIGRP по мой взгляд лучшего не придумали для распределённой сети.
> HSRP GLBP это технологии которые скорее резервируют маршрутизатор чем сеть.Смотрите, если 3750 ставить в ядро (2 в стек)
Они будут являться шлюзом по умолчанию, для всех подключенных машин, правильно я понимаю.
Если нет, то кто? АSA не получается, ибо нужно еще маршрутизировать между Vlan.
Если всетаки шлюзом по умолчанию, они смогут резервировать шлюз? Никогда не работал со стековыми свитчами. В случае с протоколами типа HSRP GLBP хоть принцип понятен, а здесь нет.А Аsa стоит в режиме асtive/active причем по паре для каждого провайдера. )) И от каждой по линку в DMZ и в локаль. Т.е одна из них является шлюзом в тек момент. Пипец получается. Столько дорогущего оборудования и так коряво.
А филиалы соеденены, либо через VLAN провайдера либо через IPSEC, но без Gre ( как понимаю без это-го не сделать нормальной динамики внутри тунелей.
> Смотрите, если 3750 ставить в ядро (2 в стек)
> Они будут являться шлюзом по умолчанию, для всех подключенных машин, правильно я
> понимаю.Все правильно, именно ip виртуальных интерфейсов 3750 будут шлюзами по умолчанию для ПК в сети. HSPR, VRRP, GLBP актуально только если есть избыточные линки между комутаторами.
> Если нет, то кто? АSA не получается, ибо нужно еще маршрутизировать между
> Vlan.
> Если всетаки шлюзом по умолчанию, они смогут резервировать шлюз? Никогда не работал
> со стековыми свитчами. В случае с протоколами типа HSRP GLBP хоть
> принцип понятен, а здесь нет.про это забудьте,неверно написали.
> А Аsa стоит в режиме асtive/active причем по паре для каждого провайдера.
> )) И от каждой по линку в DMZ и в локаль.
> Т.е одна из них является шлюзом в тек момент. Пипец получается.
> Столько дорогущего оборудования и так коряво.
> А филиалы соеденены, либо через VLAN провайдера либо через IPSEC, но без
> Gre ( как понимаю без это-го не сделать нормальной динамики внутри
> тунелей.
> Все правильно, именно ip виртуальных интерфейсов 3750 будут шлюзами по умолчанию для
> ПК в сети. HSPR, VRRP, GLBP актуально только если есть избыточные
> линки между комутаторами.Так в случае стека, от коммутаторов доступа будет идти по 2 линка ( по одному в каждую свитч входящий в стек) Правильно?
Aleks305, а про что забыть? я не совсем понял.
> Так в случае стека, от коммутаторов доступа будет идти по 2 линка
> ( по одному в каждую свитч входящий в стек) Правильно?Правильно с точки зрения отказоустойчивости. А работать можно и по одному линку.
>> Так в случае стека, от коммутаторов доступа будет идти по 2 линка
>> ( по одному в каждую свитч входящий в стек) Правильно?
> Правильно с точки зрения отказоустойчивости. А работать можно и по одному линку.Мне нужно обеспечить, отказоустойчивость шлюза по умолчанию.
Внимание вопрос. Для этого нужно заводить протоколы типа HSRP, на свитчах которые находятся в стеке или нет? Если да, то зачем тогда стек :)
3750 в стеке на ядре - отказоустойчивость ядра. Логически это одно устройство. Т.е. при выхое из строя одного из коммутаторов ядра само ядро продолжает работать.Теперь по аплинкам: в идеале вы физически соединяете каждый коммутатор доступа в каждый физический коммутатор стека. В результате при выходе из строя одного из 3750 в стеке вы не теряете работоспособность сети.
HSRP тут вообще не применяется. Нужно будет просто объединить аплинки по Etherchannel, крайне желательно по технологии LACP либо PgAP.
> 3750 в стеке на ядре - отказоустойчивость ядра. Логически это одно устройство.
> Т.е. при выхое из строя одного из коммутаторов ядра само ядро
> продолжает работать.
> Теперь по аплинкам: в идеале вы физически соединяете каждый коммутатор доступа в
> каждый физический коммутатор стека. В результате при выходе из строя одного
> из 3750 в стеке вы не теряете работоспособность сети.
> HSRP тут вообще не применяется. Нужно будет просто объединить аплинки по Etherchannel,
> крайне желательно по технологии LACP либо PgAP.Спасибо, очень понятно.
>> 3750 в стеке на ядре - отказоустойчивость ядра. Логически это одно устройство.
>> Т.е. при выхое из строя одного из коммутаторов ядра само ядро
>> продолжает работать.
>> Теперь по аплинкам: в идеале вы физически соединяете каждый коммутатор доступа в
>> каждый физический коммутатор стека. В результате при выходе из строя одного
>> из 3750 в стеке вы не теряете работоспособность сети.
>> HSRP тут вообще не применяется. Нужно будет просто объединить аплинки по Etherchannel,
>> крайне желательно по технологии LACP либо PgAP.
> Спасибо, очень понятно.Для свитчей access/distribution layers для пущей отказоустойчивости можно взять по 1 линку с каждого 3750 коммутарора в стеке, обеденить их в Etherchannel а сам Etherchannel сделать транком и в таком виде принять на access-свитч двумя физ портами в Etherchannel trunk (ограничение работает только mode on для Etherchannel) и тогда даже при выгорании свитча на ядре 3750 кроме дымка ничего топологически страшного не произойдет ;)
> даже при выгорании свитча на ядре 3750
> кроме дымка ничего топологически страшного не произойдет ;)ваш оптимизм почему-то исключает разваливание самого стека как такового...)
>> Так в случае стека, от коммутаторов доступа будет идти по 2 линка
>> ( по одному в каждую свитч входящий в стек) Правильно?
> Правильно с точки зрения отказоустойчивости. А работать можно и по одному линку.Stack ne yavlyaetsa otkazoustoichivim resheniem, skoree naoborot. On voobshe nuzhe dlay steckirovaniay :-) Dlya otkazoustoichivosti lucshe 2 otdelnih switcha s dvumya etherchannel linkami, hsrp/vrrp (glbp na 3750 net) i t.p.
sorry za translit
> Stack ne yavlyaetsa otkazoustoichivim resheniem, skoree naoborot. On voobshe nuzhe dlay
> steckirovaniay :-) Dlya otkazoustoichivosti lucshe 2 otdelnih switcha s dvumya
> etherchannel linkami, hsrp/vrrp (glbp na 3750 net) i t.p.
> sorry za translitВот и что после этого думать, совершенно противоположная информация (((
> Stack ne yavlyaetsa otkazoustoichivim resheniem, skoree naoborot. On voobshe nuzhe dlay
> steckirovaniay :-) Dlya otkazoustoichivosti lucshe 2 otdelnih switcha s dvumya
> etherchannel linkami, hsrp/vrrp (glbp na 3750 net) i t.p.Вы тогда уж пару 65хх + VSS советуйте.
С чего вдруг стек 3750 не является отказоустойчивым решением? Cisco solutions вроде не отменяли, поясните?
>> Stack ne yavlyaetsa otkazoustoichivim resheniem, skoree naoborot. On voobshe nuzhe dlay
>> steckirovaniay :-) Dlya otkazoustoichivosti lucshe 2 otdelnih switcha s dvumya
>> etherchannel linkami, hsrp/vrrp (glbp na 3750 net) i t.p.
> Вы тогда уж пару 65хх + VSS советуйте.
> С чего вдруг стек 3750 не является отказоустойчивым решением? Cisco solutions вроде
> не отменяли, поясните?Итак, всетаки HSRP или стек на свитчах 3750 для отказоустойчивости ядра и шлюза по умолчанию
Какие плюсы и минусы. Кто чего скажет :)
>> Stack ne yavlyaetsa otkazoustoichivim resheniem, skoree naoborot. On voobshe nuzhe dlay
>> steckirovaniay :-) Dlya otkazoustoichivosti lucshe 2 otdelnih switcha s dvumya
>> etherchannel linkami, hsrp/vrrp (glbp na 3750 net) i t.p.
> Вы тогда уж пару 65хх + VSS советуйте.
> С чего вдруг стек 3750 не является отказоустойчивым решением? Cisco solutions вроде
> не отменяли, поясните?Это лучше :-) VSS сыроват, правда с последними иосами пока проблем не наблюдал. Если стек начинает глючить (было не однократно) - перевыборы мастераб свитч тормозит и т.п. как повезет в общем и все приехали - STP, RSTP, HSRP, OSPF whatever уже разрулить ситуацию не могут и получаем флапающее ядро со всеми остальными плюшками. При отделных свитчах/роутерах такого нет. Хотя рулить стеком несомненно приятней.
Я не помню у циско рекоммендаций стеков в качестве отказоустойчивости, у 2960-S есть FlexStack технология и вроде они пишут что рулит неподетски, не работал с ними, не знаю. Но 3750 в ОДИН стек в ЯДРО я б не ставил, лучше 2 3560 если с деньгами напряг
Ставил как то в ядро 2 3750S в один стек, но исключительно из за недостатка оптических портов, позжеее добавил 4500 как второй свитч в ядро...То есть лучше считать стек как ОДИН свитч все таки и не 2 или N
Логика понятна, возможно Вы и правы.
Хотя, честно говоря, никогда не имел проблем со стеком на 3750, ваш опыт даже несколько удивил...
> Логика понятна, возможно Вы и правы.
> Хотя, честно говоря, никогда не имел проблем со стеком на 3750, ваш
> опыт даже несколько удивил...примерно из 1000 3750 штук 7 - 10 с проблемными стек портами, не биг дил, но осадок остался :-)
>> Но 3750 в ОДИН стек в
> ЯДРО я б не ставил, лучше 2 3560 если с деньгами
> напряг
> Ставил как то в ядро 2 3750S в один стек, но исключительно
> из за недостатка оптических портов, позжеее добавил 4500 как второй свитч
> в ядро...
> То есть лучше считать стек как ОДИН свитч все таки и не
> 2 или NА почему 3560, в чем их преимущество, вы их рекомендуете в стек
или отдельно с hsrp?
>>> Но 3750 в ОДИН стек в
>> ЯДРО я б не ставил, лучше 2 3560 если с деньгами
>> напряг
>> Ставил как то в ядро 2 3750S в один стек, но исключительно
>> из за недостатка оптических портов, позжеее добавил 4500 как второй свитч
>> в ядро...
>> То есть лучше считать стек как ОДИН свитч все таки и не
>> 2 или N
> А почему 3560, в чем их преимущество, вы их рекомендуете в стек
> или отдельно с hsrp?Они дешевле, но НЕ стекируются. 3750 более практичнее конечно
производительность одинакова
> Они дешевле, но НЕ стекируются. 3750 более практичнее конечно
> производительность одинаковаСмотрите, если мы настраиваем свитч для hsrp, мы получаем рабочий один свитч, так? Второй остается полностью резервным и задействовать его порты для других целей не получится.
Вообще Hsrp может настраиваться нак каком уровне для интерфейсов, Vlan. Т.е я могу обеспечить отказоустойчивость шлюзов для маршрутизации между Vlan?
>> Они дешевле, но НЕ стекируются. 3750 более практичнее конечно
>> производительность одинакова
> Смотрите, если мы настраиваем свитч для hsrp, мы получаем рабочий один свитч,
> так? Второй остается полностью резервным и задействовать его порты для других
> целей не получится.
> Вообще Hsrp может настраиваться нак каком уровне для интерфейсов, Vlan. Т.е я
> могу обеспечить отказоустойчивость шлюзов для маршрутизации между Vlan?HSRP - Это резерв для шлюза в основном, также он может трекать интерфесы и т .п.
Настраивается на L3 интерфесах. L2 инт можно и нужно использовать на обоих свитчах
Спасибо за разъяснения.
Теперь возникает вопрос по внешнему периметру сети.
Что должно стаять на границе с провайдерами первым устройством, роутер, или феервол ASA.
Просто в стандартной сети все понятно, здесь немного другой уровень, требование к безопастности, надежности.
Допустим, есть три провайдера, каждый для своих целей, сервисов.
Ставить одну железку активную куда будут воткнуты все, как бы не очень нравится с точки зрения защиты от DDOS(да учитываю и это) уже бомбили не раз, загрузка сisco asa по 100% вместе с IPS.
Т.е поидеи, должны быть активные железки по периметру, которые могут дать некоторый уровень защиты, дальше они идут в одну допустим ASA 5540(можно active/active)которая делит DMZ и LocalВот. Написал немного сумбурно, но смысл организовать правильно внешний периметр сети с несколькими провайдерами, с высоким уровнем безобасности, DMZ
>[оверквотинг удален]
> безопастности, надежности.
> Допустим, есть три провайдера, каждый для своих целей, сервисов.
> Ставить одну железку активную куда будут воткнуты все, как бы не очень
> нравится с точки зрения защиты от DDOS(да учитываю и это) уже
> бомбили не раз, загрузка сisco asa по 100% вместе с IPS.
> Т.е поидеи, должны быть активные железки по периметру, которые могут дать некоторый
> уровень защиты, дальше они идут в одну допустим ASA 5540(можно active/active)которая
> делит DMZ и Local
> Вот. Написал немного сумбурно, но смысл организовать правильно внешний периметр сети с
> несколькими провайдерами, с высоким уровнем безобасности, DMZя бы сделал 2 железки к двум провайдерам, которые упираются в две asa, на которых висит DMZ и LAN. На роутерах с провайдерами поставил бы грубые правила(acl), типа антиспуфа приватных адресов, на ASA бы фильтровал все остальное более точечно.IPS бы ставил возле хостов в DMZ-зоне, уже после фильтрации ASA, чтобы минимизировать на него нагрузку. Доступ из Интернет в LAN полностью бы закрыл...ну а дальше нюансы вашей сети.
> я бы сделал 2 железки к двум провайдерам, которые упираются в две
> asa, на которых висит DMZ и LAN. На роутерах с провайдерами
> поставил бы грубые правила(acl), типа антиспуфа приватных адресов, на ASA бы
> фильтровал все остальное более точечно.IPS бы ставил возле хостов в DMZ-зоне,
> уже после фильтрации ASA, чтобы минимизировать на него нагрузку. Доступ из
> Интернет в LAN полностью бы закрыл...ну а дальше нюансы вашей сети.Под 2 железками, вы подразумеваете, маршрутизаторы?
Не совсем понятна и роль, поскольку провайдеров можно точно также воткнуть в outside асы, в общем конечно ясно, что это поможет повысить безопасность и снизить нагрузку на АSA, но не достаточно чтобы четко обосновать :)
Далее, если получается что на каждой асе висит DMZ, тогда в DMZ видимо тоже придется ставить какое-то ядро, так сказать шлюз по умолчанию для все серверов. Хотя, нужно подумать.
>> я бы сделал 2 железки к двум провайдерам, которые упираются в две
>> asa, на которых висит DMZ и LAN. На роутерах с провайдерами
>> поставил бы грубые правила(acl), типа антиспуфа приватных адресов, на ASA бы
>> фильтровал все остальное более точечно.IPS бы ставил возле хостов в DMZ-зоне,
>> уже после фильтрации ASA, чтобы минимизировать на него нагрузку. Доступ из
>> Интернет в LAN полностью бы закрыл...ну а дальше нюансы вашей сети.
> Под 2 железками, вы подразумеваете, маршрутизаторы?да, два маршрутизатора
> Не совсем понятна и роль, поскольку провайдеров можно точно также воткнуть в
> outside асы,аса все же не маршрутизатор в конечном итоге и не всегда может обеспечить те функции, которые от нее хотелось бы(например, bgp)
> в общем конечно ясно, что это поможет повысить безопасность
> и снизить нагрузку на АSA, но не достаточно чтобы четко обосновать
> :)
> Далее, если получается что на каждой асе висит DMZ, тогда в DMZ
> видимо тоже придется ставить какое-то ядро, так сказать шлюз по умолчанию
> для все серверов. Хотя, нужно подумать.а что у Вас один сервер в DMZ?
у нас как минимум с десяток. Задача решается установкой комутатора уровня 3, на котором и будет шлюз по умолчанию, а он уже будет обеспечивать маршрутизацию через асы к маршрутизаторам внешним
Нет, конечно сервер не один. Просто потребуется тоже железка дорогая, а лучше 2 для отказоустойчивости.
Возвращаюсь к теме, правильной организации сети :)
Речь идет о ядре сети, где планируется использовать что-нибудь на подобие cisco 3750.
Смотрите, есть несколько филиалов, в каждом по 2 канала интернет (основной резервный), везде на границе с двух сторон стоят ASA, тунель организован через ipsec. Чтобы поднять динамику, нужно поднимать gre внутри ipsec, ASA такое делать не может. Логично было бы поднять тунель прямо из ядра через ASA, но проблема что cisco 3750 не может ставить gre тунели. Т.е нужно либо в ядро ставить какую-то железку, которая может такое делать, или дополнительно ставить роутер.
Какие есть мысли, уважаемые?
> но проблема что cisco 3750 не может ставить gre тунели.что значит не может ставить?
#sh interface Tunnel1
Tunnel1 is up, line protocol is up
Hardware is Tunnel
Description: "Tunnel to ADSL-gorod"
Internet address is x.x.x.x/30
MTU 1514 bytes, BW 10000 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 6/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source x.x.x.x (Vlan1), destination x.x.x.x, fastswitch TTL 255
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Tunnel TTL 255
Checksumming of packets disabled, fast tunneling enabled
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 264000 bits/sec, 44 packets/sec
5 minute output rate 49000 bits/sec, 39 packets/sec#sh ver
Cisco IOS Software, C3750 Software (C3750-IPSERVICES-M), Version 12.2(35)SE5, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Thu 19-Jul-07 19:15 by nachen
Image text-base: 0x00003000, data-base: 0x01280000ROM: Bootstrap program is C3750 boot loader
BOOTLDR: C3750 Boot Loader (C3750-HBOOT-M) Version 12.2(25r)SEE4, RELEASE SOFTWARE (fc1)sovxoz-dsw1 uptime is 6 weeks, 4 days, 2 hours, 6 minutes
System returned to ROM by power-on
System restarted at 10:09:35 YAKST Thu Apr 14 2011
System image file is "flash:c3750-ipservices-mz.122-35.SE5/c3750-ipservices-mz.122-35.SE5.bin"cisco WS-C3750G-24TS-1U (PowerPC405) processor (revision E0) with 118784K/12280K bytes of memory.
Processor board ID FOC1213Y0Y3
Спасибо за ответ.
Да я много читал про это, что они обещали включить софтварную поддержку тунелей в новых версиях IOS. А как дела обстоят со скорость в таком тунеле, вроде говорят, тормозной он получается.
Годится ли это для рабочей сети, где будет заходить 3-4 тунеля, да и скорость должна быть мегабит 20-30.
> Спасибо за ответ.
> Да я много читал про это, что они обещали включить софтварную поддержку
> тунелей в новых версиях IOS. А как дела обстоят со скорость
> в таком тунеле, вроде говорят, тормозной он получается.
> Годится ли это для рабочей сети, где будет заходить 3-4 тунеля, да
> и скорость должна быть мегабит 20-30.Сказать не могу, на 3750 у меня всего один туннель, да и канал там всего 2 МБит/с, поэтому не могу проверить на большей скорости.
>[оверквотинг удален]
> Речь идет о ядре сети, где планируется использовать что-нибудь на подобие cisco
> 3750.
> Смотрите, есть несколько филиалов, в каждом по 2 канала интернет (основной резервный),
> везде на границе с двух сторон стоят ASA, тунель организован через
> ipsec. Чтобы поднять динамику, нужно поднимать gre внутри ipsec, ASA такое
> делать не может. Логично было бы поднять тунель прямо из ядра
> через ASA, но проблема что cisco 3750 не может ставить gre
> тунели. Т.е нужно либо в ядро ставить какую-то железку, которая может
> такое делать, или дополнительно ставить роутер.
> Какие есть мысли, уважаемые?Из коммутаторов GRE аппаратно умеет только 6500.
На Cat3750 у меня уже при 20 мб/с был стопрор сети и 90% CPU и более.
Т.е. для терминации тунелей сабж не предназначен. Функционал соответствующий для галочки только. Любой рутер 2800 с этим справится лучше.
> На Cat3750 у меня уже при 20 мб/с был стопрор сети и
> 90% CPU и более.
> Т.е. для терминации тунелей сабж не предназначен. Функционал соответствующий для галочки
> только. Любой рутер 2800 с этим справится лучше.подтверждаю
> Stack ne yavlyaetsa otkazoustoichivim resheniem, skoree naoborot. On voobshe nuzhe dlay
> steckirovaniay :-) Dlya otkazoustoichivosti lucshe 2 otdelnih switcha s dvumya
> etherchannel linkami, hsrp/vrrp (glbp na 3750 net) i t.p.
> sorry za translitне совсем по теме отвечаю, но вас читать сложно. Можно использовать хотя бы виртуальную клавиатуру www.keyboard.su чтобы другим глаза не портить :)
>> Stack ne yavlyaetsa otkazoustoichivim resheniem, skoree naoborot. On voobshe nuzhe dlay
>> steckirovaniay :-) Dlya otkazoustoichivosti lucshe 2 otdelnih switcha s dvumya
>> etherchannel linkami, hsrp/vrrp (glbp na 3750 net) i t.p.
>> sorry za translitКакие могут быть езерченел линки без стека между разными коммутаторами?
Уважаемы, прокоментируйте пожалуйста свое утверждение по поводу не надежности стека.
А то не впервый раз слышу подобное, но никаких вменяемых аргументов не приводится.Я же считаю наоборот, что STP + HSRP - глючное и менее надежное решение, нежели стек из 3750. С в 2 раза менее эффективным использованием полосы пропускания.
Имею 2 относительно не больших офиса с сопоставимым числом пользователей, где ядро на стеках. Аптайм в обоих случая большой, никаких проблем. Знаю ряд людей, которые также считают подобное решение предпочтительным, и используют его.
Очень хочется услышать вменяемых аргументов, почему глючное STP лучше.
Какие могут быть езерченел линки без стека между разными коммутаторами?
----- имелось ввиду 2 линка между каждым коммутаторомУважаемы, прокоментируйте пожалуйста свое утверждение по поводу не надежности стека.
А то не впервый раз слышу подобное, но никаких вменяемых аргументов не приводится.----- Как показала практика стек вилетает намного чаще чем отдельные свитчи (что логично) и это намного больнее, стоит заглючить одному стек порту - и весь стек под вопросом, может кольцо спасет а может и нет, может проработат без проблем толко с сообшениями в лог и.д. Выше по ветке я писал не на транслите :-)
Я же считаю наоборот, что STP + HSRP - глючное и менее надежное решение, нежели стек из 3750. С в 2 раза менее эффективным использованием полосы пропускания.--- это ваша точка зрения, переубеждать никакого намерения нет абсолютно, Глюков с STP + HSRP при правильном дизаине не наблюдал (про STP я не говорил вообще).
Имею 2 относительно не больших офиса с сопоставимым числом пользователей, где ядро на стеках. Аптайм в обоих случая большой, никаких проблем. Знаю ряд людей, которые также считают подобное решение предпочтительным, и используют его.---- причем тут количество пользователей? Все ползователи остаются на аксес левеле, в ядре много портов обычно не нужно, если только оно не совмешенно с дистрибушеном (но ми же говорим о ядре) ядро на стеках - для нищих (не поимите не правильно), так делается в последнюю очередь когда другого вихода нет. Аптайм - это не отказоустоичивость! ПОкажите cisco HA SRND в котором рекоммендуют ставить в ядро стек из 3750! В моих сетях стеки есть и будут, но при наличии в требованиях к сети HA, Redudancy etc и того что я буду за это ответственным - в ядре стек стоять не будет никогда!
Очень хочется услышать вменяемых аргументов, почему глючное STP лучше.
-----Я не говорил что STP лучше, и вообще я не понимаю как это можно сравнивать
2 SerbБлагодарю за развернутый ответ
Логика ваша в целом понятна.
Про STP я писал, т.к. естейственно, что там где до 300 пользователей и ядро на 3750 - никакого дистрибушн левела нет. Т.е. в этом случае без STP + HSRP не обойтись никак (аксесс - 2 уровня). И именно подобный вариант я имел в виду, когда предлагал стек.
Если же дистрибьюшн есть и ядро чистый L3 - то естейственно, без стека надежнее и логичнее. Это понятно.
По поводу глючности стека - к счастью не наблюдал. Но на будующее буду иметь в виду ваш опыт.
Все же ИМХО аналогичные програмные глюки могут привести и к глюкам STP, и к двум активным HSRP и т.д. По большому счету - все резервирование гарантирует 100% отказоустойчивость только в случаях, когда 1 из нод полностью выходит из строя (сгорел блок питания и т.д.). От различных програмных глюков ни один дизайн не является 100% панацеей.
А то что нет рекомендаций от циски - это понятно. Циска всегда рекомендует обязательбно 3-х уровневую модель, даже если она не нужна. И только 6500 и нексусы в ядро. Потому как прибыль от продаж подобного железа сильно выше.
>[оверквотинг удален]
> буду иметь в виду ваш опыт.
> Все же ИМХО аналогичные програмные глюки могут привести и к глюкам STP,
> и к двум активным HSRP и т.д. По большому счету -
> все резервирование гарантирует 100% отказоустойчивость только в случаях, когда 1
> из нод полностью выходит из строя (сгорел блок питания и т.д.).
> От различных програмных глюков ни один дизайн не является 100% панацеей.
> А то что нет рекомендаций от циски - это понятно. Циска всегда
> рекомендует обязательбно 3-х уровневую модель, даже если она не нужна. И
> только 6500 и нексусы в ядро. Потому как прибыль от продаж
> подобного железа сильно выше.вы не поверите :-) сегодня ночью случилось то о чем так долго говорили большевики
========================================================
-Traceback= 20A364 187F04 58D6FC 58B950 2D7CE0 2E00C8 2E2BEC 2E2F24 2B0BF8 Jun 28 04:21:21.789 EDT: %LINK-3-BADMACREG: Interface StackPort1, non-existent MACADDR registry for link 0 -Process= "<interrupt level>", ipl= 4 ========================================================
........вылечилось только заменой больного свитча, стек работал года 3 без проблем, но произошло отключение света, а после включения посыпалась хрень в логи. (все на УПС и т.п ) повезло что это было ночью, и что это не ядро :-) но это вся телефония - 6x 3750 PoE по 48 портов каждый. Что интересно проблема в основном с PoE свитчами, за последний год 3й раз и в разных местах
а в целом - глючит все!
>[оверквотинг удален]
> for link 0 -Process= "<interrupt level>", ipl= 4 ========================================================
> ........
> вылечилось только заменой больного свитча, стек работал года 3 без проблем, но
> произошло отключение света, а после включения посыпалась хрень в логи. (все
> на УПС и т.п ) повезло что это было ночью, и
> что это не ядро :-) но это вся телефония -
> 6x 3750 PoE по 48 портов каждый. Что интересно проблема в
> основном с PoE свитчами, за последний год 3й раз и в
> разных местах
> а в целом - глючит все!Забавно :)
А как по вашему мнению, конкретно для выше указанной задачи (воип аксесс): Корзина 4500 с дублированными супервизорами и блоками питания была бы надежнее и стабильнее стека из 3750?