форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Вопросы по организации сети..."	+/–
Сообщение от dxnet (ok) on 22-Мрт-11, 10:02
Здравствуйте. Есть организация порядка 300компов в главном офисе, + несколько филиалов. В каждом офисе есть основной канал и резервный, главном и того больше. НО. На каждом канале висит либо pix либо asa, но при этом нет не одного маршрутизатора. Нет как такового нормально организованного ядра сети. Т.е, чтобы переключится на другой канал, на серверах приходится переписывать маршруты ))) НУ ладно это вступление. Настал момент когда нужно все перестраивать. Опыта у меня мало в построении крупных систем с серьезным оборудованием, поэтому хочу посоветоваться. Первое что хочется, это создать нормальное ядро сети с отказоустойчивостью шлюза по умолчанию, здесь у нас первый спор с шефом, он хочет ставить маршрутизаторы, я хочу свитчи третьего уровня в стек, либо которые поддерживаются протоколы типа HSRP (отказоустойчивости шлюза по умолчанию). Вопрос кто прав? Если я, как обосновать, почему именно свитчи. И какие модели можете посоветовать для данной задачи. Далее, на каждом канале, соответственно на ASA или Pix, которые стоят на границе данного канала, есть соответственно порт в локаль и DMZ, т.е, для DMZ сети получается нужно будет покупать также пару оборудования для маршрутизации с отказойстойчивость. Пока все, по мере ответов будут новые вопросы :) Не хочу пока все сваливать в кучу, хочется много чего обсудить. Спасибо.
Ответить | Правка | Cообщить модератору

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

[Сортировка по времени | RSS]

1. "Вопросы по организации сети..."	+/–
Сообщение от Merridius on 22-Мрт-11, 11:26
>[оверквотинг удален] > протоколы типа HSRP (отказоустойчивости шлюза по умолчанию). Вопрос кто прав? Если > я, как обосновать, почему именно свитчи. И какие модели можете посоветовать > для данной задачи. > Далее, на каждом канале, соответственно на ASA или Pix, которые стоят на > границе данного канала, есть соответственно порт в локаль и DMZ, т.е, > для DMZ сети получается нужно будет покупать также пару оборудования для > маршрутизации с отказойстойчивость. > Пока все, по мере ответов будут новые вопросы :) Не хочу пока > все сваливать в кучу, хочется много чего обсудить. > Спасибо. FHRP в ядро? боже упаси. Делайте через протоколы динамической маршрутизации. А по поводу филлилалов, я бы в главный офис поставил две 7200( если денег не жалко конечно) в филлиалы что-нибудь попроще( зависит от потребностей). Между всем этим хозяйством DMVPN и ospf (или EIGRP).
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Вопросы по организации сети..."	+/–
	Сообщение от Merridius (ok) on 22-Мрт-11, 11:32
	а локалку я бы конечно роутил на коммутаторах ну там 3750 или если денег не жалко 6500 с Sup 32
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Вопросы по организации сети..."	+/–
	Сообщение от Николай (??) on 22-Мрт-11, 12:28
	300 ПК это не много. В ядро ставьте 3750 стекируемый никаких роутеров - они умрут при первом серьезном бекапировании. Кстати 3750 L3 поддерживают поднимите динамику и будет порядок. Если все цисковское - то поднимайте EIGRP по мой взгляд лучшего не придумали для распределённой сети. HSRP GLBP это технологии которые скорее резервируют маршрутизатор чем сеть. Вопрос номер 2 каналы/тунели/резервирование: Строить Easy VPN на ASA конечно можно но работа такого канала оставляет желать лучшего (часто без каких либо причит залипает канал, он как бы есть но он как бы не с нами и все коректно ошибок нет вот только трафик в нем не бегает) переключение на резерв происходит с большой по сетевым меркам задержкой, если будет еще и редистрибъюция в АСА то вообще глына. Я бы рекомендовал стоить GRE+IPSEC на маршрутизаторах. Вопрос 3 ДМЗ построить отдельной подсетью и в разрез вставить PIX/ASA (заодно и слепить active/active or active/standby failover )а от них линк в 3750.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "Вопросы по организации сети..."	+/–
	Сообщение от Merridius (ok) on 22-Мрт-11, 13:00
	> В ядро ставьте 3750 стекируемый никаких роутеров > - они умрут при первом серьезном бекапировании. Бред. С чего они должны умереть? Я имел ввиду роутеры ставить в качестве edge, на них же и туннели, а ниже коммутаторы для аггрегации и "inter-VLAN routing". По поводу GRE+IPSEC согласен, только на мой взгляд если филлиалов много лучше DMVPN. http://xgu.ru/wiki/%D0%9D%D0%B0%D1&...
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "Вопросы по организации сети..."	+/–
	Сообщение от dxnet (ok) on 22-Мрт-11, 15:43
	> 300 ПК это не много. В ядро ставьте 3750 стекируемый никаких роутеров > - они умрут при первом серьезном бекапировании. Кстати 3750 L3 поддерживают > поднимите динамику и будет порядок. Если все цисковское - то поднимайте > EIGRP по мой взгляд лучшего не придумали для распределённой сети. > HSRP GLBP это технологии которые скорее резервируют маршрутизатор чем сеть. Смотрите, если 3750 ставить в ядро (2 в стек) Они будут являться шлюзом по умолчанию, для всех подключенных машин, правильно я понимаю. Если нет, то кто? АSA не получается, ибо нужно еще маршрутизировать между Vlan. Если всетаки шлюзом по умолчанию, они смогут резервировать шлюз? Никогда не работал со стековыми свитчами. В случае с протоколами типа HSRP GLBP хоть принцип понятен, а здесь нет. А Аsa стоит в режиме асtive/active причем по паре для каждого провайдера. )) И от каждой по линку в DMZ и в локаль. Т.е одна из них является шлюзом в тек момент. Пипец получается. Столько дорогущего оборудования и так коряво. А филиалы соеденены, либо через VLAN провайдера либо через IPSEC, но без Gre ( как понимаю без это-го не сделать нормальной динамики внутри тунелей.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	6. "Вопросы по организации сети..."	+/–
	Сообщение от Aleks305 (ok) on 22-Мрт-11, 16:02
	> Смотрите, если 3750 ставить в ядро (2 в стек) > Они будут являться шлюзом по умолчанию, для всех подключенных машин, правильно я > понимаю. Все правильно, именно ip виртуальных интерфейсов 3750 будут шлюзами по умолчанию для ПК в сети. HSPR, VRRP, GLBP актуально только если есть избыточные линки между комутаторами. > Если нет, то кто? АSA не получается, ибо нужно еще маршрутизировать между > Vlan. > Если всетаки шлюзом по умолчанию, они смогут резервировать шлюз? Никогда не работал > со стековыми свитчами. В случае с протоколами типа HSRP GLBP хоть > принцип понятен, а здесь нет. про это забудьте,неверно написали. > А Аsa стоит в режиме асtive/active причем по паре для каждого провайдера. > )) И от каждой по линку в DMZ и в локаль. > Т.е одна из них является шлюзом в тек момент. Пипец получается. > Столько дорогущего оборудования и так коряво. > А филиалы соеденены, либо через VLAN провайдера либо через IPSEC, но без > Gre ( как понимаю без это-го не сделать нормальной динамики внутри > тунелей.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "Вопросы по организации сети..."	+/–
	Сообщение от dxnet (ok) on 22-Мрт-11, 16:39
	> Все правильно, именно ip виртуальных интерфейсов 3750 будут шлюзами по умолчанию для > ПК в сети. HSPR, VRRP, GLBP актуально только если есть избыточные > линки между комутаторами. Так в случае стека, от коммутаторов доступа будет идти по 2 линка ( по одному в каждую свитч входящий в стек) Правильно? Aleks305, а про что забыть? я не совсем понял.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	8. "Вопросы по организации сети..."	+/–
	Сообщение от Myxa (ok) on 22-Мрт-11, 16:56
	> Так в случае стека, от коммутаторов доступа будет идти по 2 линка > ( по одному в каждую свитч входящий в стек) Правильно? Правильно с точки зрения отказоустойчивости. А работать можно и по одному линку.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	9. "Вопросы по организации сети..."	+/–
	Сообщение от dxnet (ok) on 22-Мрт-11, 17:06
	>> Так в случае стека, от коммутаторов доступа будет идти по 2 линка >> ( по одному в каждую свитч входящий в стек) Правильно? > Правильно с точки зрения отказоустойчивости. А работать можно и по одному линку. Мне нужно обеспечить, отказоустойчивость шлюза по умолчанию. Внимание вопрос. Для этого нужно заводить протоколы типа HSRP, на свитчах которые находятся в стеке или нет? Если да, то зачем тогда стек :)
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "Вопросы по организации сети..."	+/–
	Сообщение от Myxa (ok) on 22-Мрт-11, 17:30
	3750 в стеке на ядре - отказоустойчивость ядра. Логически это одно устройство. Т.е. при выхое из строя одного из коммутаторов ядра само ядро продолжает работать. Теперь по аплинкам: в идеале вы физически соединяете каждый коммутатор доступа в каждый физический коммутатор стека. В результате при выходе из строя одного из 3750 в стеке вы не теряете работоспособность сети. HSRP тут вообще не применяется. Нужно будет просто объединить аплинки по Etherchannel, крайне желательно по технологии LACP либо PgAP.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	11. "Вопросы по организации сети..."	+/–
	Сообщение от dxnet (ok) on 22-Мрт-11, 17:38
	> 3750 в стеке на ядре - отказоустойчивость ядра. Логически это одно устройство. > Т.е. при выхое из строя одного из коммутаторов ядра само ядро > продолжает работать. > Теперь по аплинкам: в идеале вы физически соединяете каждый коммутатор доступа в > каждый физический коммутатор стека. В результате при выходе из строя одного > из 3750 в стеке вы не теряете работоспособность сети. > HSRP тут вообще не применяется. Нужно будет просто объединить аплинки по Etherchannel, > крайне желательно по технологии LACP либо PgAP. Спасибо, очень понятно.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "Вопросы по организации сети..."	+/–
	Сообщение от Николай (??) on 22-Мрт-11, 17:53
	>> 3750 в стеке на ядре - отказоустойчивость ядра. Логически это одно устройство. >> Т.е. при выхое из строя одного из коммутаторов ядра само ядро >> продолжает работать. >> Теперь по аплинкам: в идеале вы физически соединяете каждый коммутатор доступа в >> каждый физический коммутатор стека. В результате при выходе из строя одного >> из 3750 в стеке вы не теряете работоспособность сети. >> HSRP тут вообще не применяется. Нужно будет просто объединить аплинки по Etherchannel, >> крайне желательно по технологии LACP либо PgAP. > Спасибо, очень понятно. Для свитчей access/distribution layers для пущей отказоустойчивости можно взять по 1 линку с каждого 3750 коммутарора в стеке, обеденить их в Etherchannel а сам Etherchannel сделать транком и в таком виде принять на access-свитч двумя физ портами в Etherchannel trunk (ограничение работает только mode on для Etherchannel) и тогда даже при выгорании свитча на ядре 3750 кроме дымка ничего топологически страшного не произойдет ;)
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	13. "Вопросы по организации сети..."	+/–
	Сообщение от L3 on 22-Мрт-11, 20:30
	> даже при выгорании свитча на ядре 3750 > кроме дымка ничего топологически страшного не произойдет ;) ваш оптимизм почему-то исключает разваливание самого стека как такового...)
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	14. "Вопросы по организации сети..."	+/–
	Сообщение от Serb on 23-Мрт-11, 05:32
	>> Так в случае стека, от коммутаторов доступа будет идти по 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
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	15. "Вопросы по организации сети..."	+/–
	Сообщение от dxnet (ok) on 23-Мрт-11, 08:51
	> 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 Вот и что после этого думать, совершенно противоположная информация (((
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	16. "Вопросы по организации сети..."	+/–
	Сообщение от Myxa (ok) on 23-Мрт-11, 09:02
	> 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 вроде не отменяли, поясните?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	17. "Вопросы по организации сети..."	+/–
	Сообщение от dxnet (ok) on 23-Мрт-11, 12:47
	>> 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 для отказоустойчивости ядра и шлюза по умолчанию Какие плюсы и минусы. Кто чего скажет :)
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	18. "Вопросы по организации сети..."	+/–
	Сообщение от Serb on 23-Мрт-11, 16:10
	>> 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
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	19. "Вопросы по организации сети..."	+/–
	Сообщение от Myxa (ok) on 23-Мрт-11, 17:05
	Логика понятна, возможно Вы и правы. Хотя, честно говоря, никогда не имел проблем со стеком на 3750, ваш опыт даже несколько удивил...
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	20. "Вопросы по организации сети..."	+/–
	Сообщение от Serb on 23-Мрт-11, 17:20
	> Логика понятна, возможно Вы и правы. > Хотя, честно говоря, никогда не имел проблем со стеком на 3750, ваш > опыт даже несколько удивил... примерно из 1000 3750 штук 7 - 10 с проблемными стек портами, не биг дил, но осадок остался :-)
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	21. "Вопросы по организации сети..."	+/–
	Сообщение от dxnet (ok) on 24-Мрт-11, 09:55
	>> Но 3750 в ОДИН стек в > ЯДРО я б не ставил, лучше 2 3560 если с деньгами > напряг > Ставил как то в ядро 2 3750S в один стек, но исключительно > из за недостатка оптических портов, позжеее добавил 4500 как второй свитч > в ядро... > То есть лучше считать стек как ОДИН свитч все таки и не > 2 или N А почему 3560, в чем их преимущество, вы их рекомендуете в стек или отдельно с hsrp?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	22. "Вопросы по организации сети..."	+/–
	Сообщение от Serb on 24-Мрт-11, 20:45
	>>> Но 3750 в ОДИН стек в >> ЯДРО я б не ставил, лучше 2 3560 если с деньгами >> напряг >> Ставил как то в ядро 2 3750S в один стек, но исключительно >> из за недостатка оптических портов, позжеее добавил 4500 как второй свитч >> в ядро... >> То есть лучше считать стек как ОДИН свитч все таки и не >> 2 или N > А почему 3560, в чем их преимущество, вы их рекомендуете в стек > или отдельно с hsrp? Они дешевле, но НЕ стекируются. 3750 более практичнее конечно производительность одинакова
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	23. "Вопросы по организации сети..."	+/–
	Сообщение от dxnet (ok) on 25-Мрт-11, 08:59
	> Они дешевле, но НЕ стекируются. 3750 более практичнее конечно > производительность одинакова Смотрите, если мы настраиваем свитч для hsrp, мы получаем рабочий один свитч, так? Второй остается полностью резервным и задействовать его порты для других целей не получится. Вообще Hsrp может настраиваться нак каком уровне для интерфейсов, Vlan. Т.е я могу обеспечить отказоустойчивость шлюзов для маршрутизации между Vlan?
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	24. "Вопросы по организации сети..."	+/–
	Сообщение от Serb on 25-Мрт-11, 19:08
	>> Они дешевле, но НЕ стекируются. 3750 более практичнее конечно >> производительность одинакова > Смотрите, если мы настраиваем свитч для hsrp, мы получаем рабочий один свитч, > так? Второй остается полностью резервным и задействовать его порты для других > целей не получится. > Вообще Hsrp может настраиваться нак каком уровне для интерфейсов, Vlan. Т.е я > могу обеспечить отказоустойчивость шлюзов для маршрутизации между Vlan? HSRP  - Это резерв для шлюза в основном, также он может трекать интерфесы и т .п. Настраивается на L3 интерфесах. L2 инт можно и нужно использовать на обоих свитчах
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	25. "Вопросы по организации сети..."	+/–
	Сообщение от dxnet (ok) on 30-Мрт-11, 11:05
	Спасибо за разъяснения. Теперь возникает вопрос по внешнему периметру сети. Что должно стаять на границе с провайдерами первым устройством, роутер, или феервол ASA. Просто в стандартной сети все понятно, здесь немного другой уровень, требование к безопастности, надежности. Допустим, есть три провайдера, каждый для своих целей, сервисов. Ставить одну железку активную куда будут воткнуты все, как бы не очень нравится с точки зрения защиты от DDOS(да учитываю и это) уже бомбили не раз, загрузка сisco asa по 100% вместе с IPS. Т.е поидеи, должны быть активные железки по периметру, которые могут дать некоторый уровень защиты, дальше они идут в одну допустим ASA 5540(можно active/active)которая делит DMZ и Local Вот. Написал немного сумбурно, но смысл организовать правильно внешний периметр сети с несколькими провайдерами, с высоким уровнем безобасности, DMZ
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	26. "Вопросы по организации сети..."	+/–
	Сообщение от Aleks305 (ok) on 30-Мрт-11, 13:50
	>[оверквотинг удален] > безопастности, надежности. > Допустим, есть три провайдера, каждый для своих целей, сервисов. > Ставить одну железку активную куда будут воткнуты все, как бы не очень > нравится с точки зрения защиты от DDOS(да учитываю и это) уже > бомбили не раз, загрузка сisco asa по 100% вместе с IPS. > Т.е поидеи, должны быть активные железки по периметру, которые могут дать некоторый > уровень защиты, дальше они идут в одну допустим ASA 5540(можно active/active)которая > делит DMZ и Local > Вот. Написал немного сумбурно, но смысл организовать правильно внешний периметр сети с > несколькими провайдерами, с высоким уровнем безобасности, DMZ я бы сделал 2 железки к двум провайдерам, которые упираются в две asa, на которых висит DMZ и LAN. На роутерах с провайдерами поставил бы грубые правила(acl), типа антиспуфа приватных адресов, на ASA бы фильтровал все остальное более точечно.IPS бы ставил возле хостов в DMZ-зоне, уже после фильтрации ASA, чтобы минимизировать на него нагрузку. Доступ из Интернет в LAN полностью бы закрыл...ну а дальше нюансы вашей сети.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	27. "Вопросы по организации сети..."	+/–
	Сообщение от dxnet (ok) on 30-Мрт-11, 14:42
	> я бы сделал 2 железки к двум провайдерам, которые упираются в две > asa, на которых висит DMZ и LAN. На роутерах с провайдерами > поставил бы грубые правила(acl), типа антиспуфа приватных адресов, на ASA бы > фильтровал все остальное более точечно.IPS бы ставил возле хостов в DMZ-зоне, > уже после фильтрации ASA, чтобы минимизировать на него нагрузку. Доступ из > Интернет в LAN полностью бы закрыл...ну а дальше нюансы вашей сети. Под 2 железками, вы подразумеваете, маршрутизаторы? Не совсем понятна и роль, поскольку провайдеров можно точно также воткнуть в outside асы, в общем конечно ясно, что это поможет повысить безопасность и снизить нагрузку на АSA, но не достаточно чтобы четко обосновать :) Далее, если получается что на каждой асе висит DMZ, тогда в DMZ видимо тоже придется ставить какое-то ядро, так сказать шлюз по умолчанию для все серверов. Хотя, нужно подумать.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	28. "Вопросы по организации сети..."	+/–
	Сообщение от Aleks305 (ok) on 30-Мрт-11, 16:28
	>> я бы сделал 2 железки к двум провайдерам, которые упираются в две >> asa, на которых висит DMZ и LAN. На роутерах с провайдерами >> поставил бы грубые правила(acl), типа антиспуфа приватных адресов, на ASA бы >> фильтровал все остальное более точечно.IPS бы ставил возле хостов в DMZ-зоне, >> уже после фильтрации ASA, чтобы минимизировать на него нагрузку. Доступ из >> Интернет в LAN полностью бы закрыл...ну а дальше нюансы вашей сети. > Под 2 железками, вы подразумеваете, маршрутизаторы? да, два маршрутизатора > Не совсем понятна и роль, поскольку провайдеров можно точно также воткнуть в > outside асы, аса все же не маршрутизатор в конечном итоге и не всегда может обеспечить те функции, которые от нее хотелось бы(например, bgp) > в общем конечно ясно, что это поможет повысить безопасность > и снизить нагрузку на АSA, но не достаточно чтобы четко обосновать > :) > Далее, если получается что на каждой асе висит DMZ, тогда в DMZ > видимо тоже придется ставить какое-то ядро, так сказать шлюз по умолчанию > для все серверов. Хотя, нужно подумать. а что у Вас один сервер в DMZ? у нас как минимум с десяток. Задача решается установкой комутатора уровня 3, на котором и будет шлюз по умолчанию, а он уже будет обеспечивать маршрутизацию через асы к маршрутизаторам внешним
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	29. "Вопросы по организации сети..."	+/–
	Сообщение от dxnet (ok) on 31-Мрт-11, 16:52
	Нет, конечно сервер не один. Просто потребуется тоже железка дорогая, а лучше 2 для отказоустойчивости.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	30. "Вопросы по организации сети..."	+/–
	Сообщение от dxnet (ok) on 28-Май-11, 23:56
	Возвращаюсь к теме, правильной организации сети :) Речь идет о ядре сети, где планируется использовать что-нибудь на подобие cisco 3750. Смотрите, есть несколько филиалов, в каждом по 2 канала интернет (основной резервный), везде на границе с двух сторон стоят ASA, тунель организован через ipsec. Чтобы поднять динамику, нужно поднимать gre внутри ipsec, ASA такое делать не может. Логично было бы поднять тунель прямо из ядра через ASA, но проблема что cisco 3750 не может ставить gre тунели. Т.е нужно либо в ядро ставить какую-то железку, которая может такое делать, или дополнительно ставить роутер. Какие есть мысли, уважаемые?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	31. "Вопросы по организации сети..."	+/–
	Сообщение от crash (ok) on 30-Май-11, 06:28
	> но проблема что 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: 0x01280000 ROM: 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
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	32. "Вопросы по организации сети..."	+/–
	Сообщение от dxnet (ok) on 30-Май-11, 14:56
	Спасибо за ответ. Да я много читал про это, что они обещали включить софтварную поддержку тунелей в новых версиях IOS. А как дела обстоят со скорость в таком тунеле, вроде говорят, тормозной он получается. Годится ли это для рабочей сети, где будет заходить 3-4 тунеля, да и скорость должна быть мегабит 20-30.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	33. "Вопросы по организации сети..."	+/–
	Сообщение от crash (ok) on 01-Июн-11, 07:15
	> Спасибо за ответ. > Да я много читал про это, что они обещали включить софтварную поддержку > тунелей в новых версиях IOS. А как дела обстоят со скорость > в таком тунеле, вроде говорят, тормозной он получается. > Годится ли это для рабочей сети, где будет заходить 3-4 тунеля, да > и скорость должна быть мегабит 20-30. Сказать не могу, на 3750 у меня всего один туннель, да и канал там всего 2 МБит/с, поэтому не могу проверить на большей скорости.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	34. "Вопросы по организации сети..."	+/–
	Сообщение от Pve1 (ok) on 01-Июн-11, 10:09
	>[оверквотинг удален] > Речь идет о ядре сети, где планируется использовать что-нибудь на подобие cisco > 3750. > Смотрите, есть несколько филиалов, в каждом по 2 канала интернет (основной резервный), > везде на границе с двух сторон стоят ASA, тунель организован через > ipsec. Чтобы поднять динамику, нужно поднимать gre внутри ipsec, ASA такое > делать не может. Логично было бы поднять тунель прямо из ядра > через ASA, но проблема что cisco 3750 не может ставить gre > тунели. Т.е нужно либо в ядро ставить какую-то железку, которая может > такое делать, или дополнительно ставить роутер. > Какие есть мысли, уважаемые? Из коммутаторов GRE аппаратно умеет только 6500. На Cat3750 у меня уже при 20 мб/с был стопрор сети и 90% CPU и более. Т.е.  для терминации тунелей сабж не предназначен. Функционал соответствующий для галочки только. Любой рутер 2800 с этим справится лучше.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	41. "Вопросы по организации сети..."	+/–
	Сообщение от Сергей (??) on 29-Июн-11, 19:58
	> На Cat3750 у меня уже при 20 мб/с был стопрор сети и > 90% CPU и более. > Т.е.  для терминации тунелей сабж не предназначен. Функционал соответствующий для галочки > только. Любой рутер 2800 с этим справится лучше. подтверждаю
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	35. "Вопросы по организации сети..."	+/–
	Сообщение от Isaiah (ok) on 26-Июн-11, 19:23
	> 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 чтобы другим глаза не портить :)
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	36. "Вопросы по организации сети..."	+/–
	Сообщение от Pve1 (ok) on 27-Июн-11, 12:53
	>> 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 лучше.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	37. "Вопросы по организации сети..."	+/–
	Сообщение от Serb on 28-Июн-11, 08:33
	Какие могут быть езерченел линки без стека между разными коммутаторами? ----- имелось ввиду 2 линка между каждым коммутатором Уважаемы, прокоментируйте пожалуйста свое утверждение по поводу не надежности стека. А то не впервый раз слышу подобное, но никаких вменяемых аргументов не приводится. ----- Как показала практика стек вилетает намного чаще чем отдельные свитчи (что логично) и это намного больнее, стоит заглючить одному стек порту - и весь стек под вопросом, может кольцо спасет а может и нет, может проработат без  проблем толко с сообшениями в лог и.д. Выше по ветке я писал не на транслите :-) Я же считаю наоборот, что STP + HSRP - глючное и менее надежное решение, нежели стек из 3750. С в 2 раза менее эффективным использованием полосы пропускания. --- это ваша точка зрения, переубеждать никакого намерения нет абсолютно, Глюков с STP + HSRP при правильном дизаине не наблюдал (про STP я не говорил вообще). Имею 2 относительно не больших офиса с сопоставимым числом пользователей, где ядро на стеках. Аптайм в обоих случая большой, никаких проблем. Знаю ряд людей, которые также считают подобное решение предпочтительным, и используют его. ---- причем тут количество пользователей? Все ползователи остаются на аксес левеле, в ядре много портов обычно не нужно, если только оно не совмешенно с дистрибушеном (но ми же говорим о ядре) ядро на стеках - для нищих (не поимите не правильно), так делается в последнюю очередь когда другого вихода нет. Аптайм - это не отказоустоичивость! ПОкажите cisco HA SRND в котором рекоммендуют ставить в ядро стек из 3750! В моих сетях стеки есть и будут, но при наличии в требованиях к сети HA, Redudancy etc и того что я буду за это ответственным - в ядре стек стоять не будет никогда! Очень хочется услышать вменяемых аргументов, почему глючное STP лучше. -----Я не говорил что STP лучше, и вообще я не понимаю как это можно сравнивать
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	38. "Вопросы по организации сети..."	+/–
	Сообщение от Pve1 (ok) on 28-Июн-11, 10:33
	2 Serb Благодарю за развернутый ответ Логика ваша в целом понятна. Про STP я писал, т.к. естейственно, что там где до 300 пользователей и ядро на 3750 - никакого дистрибушн левела нет. Т.е. в этом случае  без STP + HSRP не обойтись никак (аксесс - 2 уровня). И именно подобный вариант я имел в виду, когда предлагал стек. Если  же дистрибьюшн есть и ядро чистый L3 - то естейственно, без стека надежнее и логичнее.  Это понятно. По поводу глючности стека - к счастью не наблюдал. Но на будующее буду иметь в виду ваш опыт. Все же ИМХО аналогичные програмные глюки могут привести и к глюкам STP, и к двум активным HSRP и т.д. По большому счету - все  резервирование гарантирует 100% отказоустойчивость только в случаях, когда 1 из нод полностью выходит из строя (сгорел блок питания и т.д.). От различных програмных глюков ни один дизайн не является 100% панацеей. А то что нет рекомендаций от циски - это понятно. Циска всегда рекомендует обязательбно 3-х уровневую модель, даже если она не нужна. И только 6500 и нексусы в ядро. Потому как прибыль от продаж подобного железа сильно выше.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	39. "Вопросы по организации сети..."	+/–
	Сообщение от Serb on 28-Июн-11, 20:19
	>[оверквотинг удален] > буду иметь в виду ваш опыт. > Все же ИМХО аналогичные програмные глюки могут привести и к глюкам 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й раз и в разных местах а в целом - глючит все!
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	40. "Вопросы по организации сети..."	+/–
	Сообщение от Pve1 (ok) on 29-Июн-11, 16:23
	>[оверквотинг удален] > for link 0 -Process= "<interrupt level>", ipl= 4 ======================================================== > ........ > вылечилось только заменой больного свитча, стек работал года 3 без проблем, но > произошло отключение света, а после включения посыпалась хрень в логи. (все > на УПС и т.п ) повезло что это было ночью, и > что это не ядро :-)  но это вся телефония - > 6x 3750 PoE по 48 портов каждый. Что интересно проблема в > основном с PoE свитчами, за последний год 3й раз и в > разных местах > а в целом - глючит все! Забавно :) А как по вашему мнению, конкретно для выше указанной задачи (воип аксесс): Корзина 4500 с дублированными супервизорами и блоками питания была бы надежнее и стабильнее стека из 3750?
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема