kostas Опубликовано 24 мая, 2013 (изменено) · Жалоба Всем доброго дня. Уважаемые гуру сетестроения, посоветуйте оборудование для мини ДЦ. Приоритет циске (есть опыт), хотя варианты рассматриваем и другие. Еще может кто расскажет, как лучше организовать уровень доступа для подключения серверов? Этот момент пока в подвешенном состоянии... Из вводных данных: Сеть порядка 100 портов 1G, распределенная по двум помещениям (есть волокно между ними). Так есть LAN для сотрудников, порядка 150 портов, так же раскиданы по нескольким помещениям. IPv4 на данный момент. В планах внедрение IPv6. Для бордера: 1. Два BGP стыка с провайдерами (Full View) 2. Трафик по 100Мбит каждый аплинк 3. Защита от DoS в пределах этих каналов, ACL 4. Желательно IPS 5. Парочка IPSec туннелей по 20-30Мбит 6. NAT в районе 100 пользователей Роутеры пока не выбраны, файрвол что нибудь из ASA5500 наверно? К примеру ASA5515 пойдет? Для ядра: 7. Пропускать трафик между сетями на скорости портов (как расчитать примерную полосу, которую могут занимать даже не знаю). Сетей не много - порядка 10. 3-4 используются прилично - переливаются террабайты данных. Не все время конечно, но частенько. Сейчас 3560 одна - местами не справляется, загрузка доходит до 80% в пиках. 8. Для упрощения содержания хозяйства, приоритет - стекирование Рассматривается стек из двух 3750X. Еще вроде есть новая линейка 38XX? Для доступа ДЦ: 9. Исходя из того, что оборудование распределено по двух помещениям, рассматриваем опять же стекирование 10. Хотелось бы иметь так же отказоустойчивый доступ, но как правильно это сделать? С STP не хотелось бы связываться. Может FHRP какой нибудь или EtherChannel? Последнее конечно более приоритетно для увеличения полосы на будущее. 11. Порты медные по 1G, если применять отказоустойчивое подключение, то порядка 2х100 портов Для доступа LAN: 12. Медные порты 1G, порядка 150 Рассматриваем вариант стекирования 2960S. Помогите пожалуйста, кто имел опыт построения подобных сетей. Может что упустил? По оборудованию может что посоветуете? Ну и доступ - скользкий момент. Заранее благодарен за помощь, советы и любую критику. Изменено 15 июля, 2013 пользователем kostas Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DruGoe_DeLo Опубликовано 24 мая, 2013 (изменено) · Жалоба Для обслуживания завода. У нас используется следующая схема. По оборудованию. Центральное ядро состоит из двух cisco 4501 они собирают в себя все пользовательские cisco в основном это 3560 или 2950. Конечный cisco соединены с ядром крест накрест одно волокно идёт в 1 ядро второе в другое. Сами ядра соеденены между собой. На другой площадке в качестве ядра используется стек из 5 cisco 3750 (три из которых sfp). Так же в сети поднят OSPF. Весь этот зоопарк не я настраивал но мне приходится его поддерживать. В качестве шлюза у нас стоит 7201. Но она служит не только для выпуска сотрудников в интернет. Но и других плюшек много на ней. В качестве фаервала стоит иса также в сети есть ад (ну это просто политика завода такая). Компьютеров порядка 500 активных. Так вот 100 мегабит для конечных пользователей хватает с лихвой. Конечные cisco соеденены с ядрами через оптику (гиговые порты) сами ядра (у нас их два, они территариально распределены) подключены по 2х10G портам. Основная нагрузка пользователей приходится на основное ядро это 4501(x2) на них также запитаны и сервера. Для удалённых пользователей на другой площадке с лихвой хватает и второго ядра из стека 5 cisco3750. Количество цисок приблезительно равно твоему. Мой тебе совет очень хорошо продумай политику доступа пользователей к интернету или к серверам. Через АД ты будешь это делать или через прокси или вообще через радиус. Но об этом надо думать сейчас. Если бы я строил нынешню сеть на заводе я бы делал это через радиус, очень много моментов можно было бы избежать и облегчить себе жизнь. Так же покупка ASA не вижу как бы сильного смысла в ней. Нет железяка крутая и брутальная. Но например касперский хорошо справляется со своей задачей. А анти флуд можно и на 7201 настроить. Но если ты будешь поднимать ISP то это будет очень круто :D ради теста играл с ним на 3801, понравилось. После того как уже продумаешь политику в нутри локальной сети у тебя выбор оборудования вылезет сам. P.S. канечно два фуль вью 7201 может и не выдержит. Но с другой стороны зачем тебе два фула. Если ты не хочешь пропускать через себя левый траф то тебе с головой хватит и простых default от двух провайдеров. Изменено 24 мая, 2013 пользователем DruGoe_DeLo Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dazgluk Опубликовано 26 мая, 2013 · Жалоба 1. 3750 - аппаратная платформа, количество трафика весьма косвенно влияет на загрузку CPU, стек из 3750X сильно ситуацию не изменит, CPU там не сильно мощнее, и имейте ввиду, в случае стекирования работать будет CPU только одной железки, вторая будет как расширитель портов. 2. С таким количеством портов, мне кажется имеет смысл рассмотреть Cat6500, Cisco как раз его сейчас позиционирует для ЦОДов к ней так же есть ASA service module, получится собрать ядро+фаервол в 2 железки. 3. По доступу серверов - сервера втыкайте напрямую в 65ю, либо через плату 6148-GE-TX (1 гигабит на 8 портов) нужно больше - 6748-GE-TX 4. По доступу LAN - идеально было бы коммутаторы доступа (2960 вполне ок) тянуть в ЦОД, причем каждый коммутатор в оба 65х. Каждая сеть - свой VLAN, для резервирования STP (65е руты) + FHRP (VRRP/HSRP). Вообще по дизаину кампуса Design guide 5. Между комнатаме в ЦОДе - либо гигабитный Etherchannel, либо 10Gb/s все зависит от вашего трафика. Так же от трафика зависит какие супервизоры брать для 65х, либо Sup720 (40 гигабит на плату) либо Sup32 (32 гигабита на шасси) 6. По бордерам много не скажу, но думаю для ваших задач либо топовый ISR (38XX), либо младший ASR (1001) - хотя ASR тут с избытком, на будующее. Как то так. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 26 мая, 2013 · Жалоба ASR судя по отзывам форумчан сам по себе редкостный глюк. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 26 мая, 2013 (изменено) · Жалоба Все красиво написано, только все завязано на cisco :) Вместо router[1,2] и ASA[1,2] поставили два 8х ядерных amd PC с 2х10Г от Интел. И в каждый PC воткнули D-Link, вроде DGS-3420-26SC. P.S. Защита от DoS в 2х100М бесполезна, ибо ддосеры забьют канал сразу. От 2Г уже имеет смысл. Изменено 26 мая, 2013 пользователем vlad11 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostas Опубликовано 26 мая, 2013 · Жалоба Всем спасибо за помощь. На PC решения не рассматриваем. 6500 (4500) новые дорогова-то будет, хотелось бы что нибудь новое, с гарантией. Хотя конечно на них было бы замечательно поднять ядро - масштабируемость на высоте. И стекирование у 6500 по 10GE замечательное, по крайней мере по описанию. Как вариант буду держать в голове, на случай, если текущая схема не пойдет. Два фулвью нужно для балансировки исходящего трафика - есть пачка публичных сервисов. По дизайну кампусов читал, представляю немного что к чему и для чего. Но как всегда - практика, лучшее дополнение к гайдам :) и хотел совета, в том числе по моделям оборудования. Что лучше использовать для подключения серверов? FHRP или EtherChannel? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SergeiK Опубликовано 26 мая, 2013 · Жалоба Всем доброго дня. Уважаемые гуру сетестроения, посоветуйте оборудование для мини ДЦ. Приоритет циске (есть опыт), хотя варианты рассматриваем и другие. Еще может кто расскажет, как лучше организовать уровень доступа для подключения серверов? Этот момент пока в подвешенном состоянии... Из вводных данных: Сеть порядка 100 портов 1G, распределенная по двум помещениям (есть волокно между ними). Так есть LAN для сотрудников, порядка 150 портов, так же раскиданы по нескольким помещениям. IPv4 на данный момент. В планах внедрение IPv6. Для бордера: 1. Два BGP стыка с провайдерами (Full View) 2. Трафик по 100Мбит каждый аплинк 3. Защита от DoS в пределах этих каналов, ACL 4. Желательно IPS 5. Парочка IPSec туннелей по 20-30Мбит Роутеры пока не выбраны, файрвол что нибудь из ASA5500 наверно? К примеру ASA5515 пойдет? Для таких скоростей хватит ISR G2. 29xx, 39xx - от бюджетов и планов расширения. Они же могут быть Firewall-ами и VPN-ми, хотя лучше ASA. Для ядра: 6. Пропускать трафик между сетями на скорости портов (как расчитать примерную полосу, которую могут занимать даже не знаю). Сетей не много - порядка 10. 3-4 используются прилично - переливаются террабайты данных. Не все время конечно, но частенько. Сейчас 3560 одна - местами не справляется, загрузка доходит до 80% в пиках. 7. Для упрощения содержания хозяйства, приоритет - стекирование Рассматривается стек из двух 3750X. Еще вроде есть новая линейка 38XX? А скорость до распределения какие? Nx1G или 10-ка? Для доступа ДЦ: 8. Исходя из того, что оборудование распределено по двух помещениям, рассматриваем опять же стекирование 9. Хотелось бы иметь так же отказоустойчивый доступ, но как правильно это сделать? С STP не хотелось бы связываться. Может FHRP какой нибудь или EtherChannel? Последнее конечно более приоритетно для увеличения полосы на будущее. 10. Порты медные по 1G, если применять отказоустойчивое подключение, то порядка 2х100 портов Для ядра, распределения и/или ДЦ я бы предложил посмотреть на 6500 c VSS. Как раз позволяет отказаться от STP. Конечно, не дешево, но могло быть и заметно дороже. Для большого ДЦ можно смотреть Nexus. Для доступа LAN: 11. Медные порты 1G, порядка 150 Рассматриваем вариант стекирования 2960S. В принципе - неплохие железки, если 4500 шасси дорого. Но если все порты в одном месте - все же предлагаю смотреть на них. Линейные карты в 4500 дешевле, чем 2960S аналогичного функционала. Само шасси, в итоге получается дороже, но и удобнее в работе (меньше железа, меньше проводов питания). Помогите пожалуйста, кто имел опыт построения подобных сетей. Может что упустил? По оборудованию может что посоветуете? Ну и доступ - скользкий момент. Заранее благодарен за помощь, советы и любую критику. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CNick Опубликовано 26 мая, 2013 · Жалоба Что лучше использовать для подключения серверов? FHRP или EtherChannel? Это технологии разного уровня, тут не может быть лучше/хуже, должна быть отказоустойчивость как на L2 так и на L3. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
-Pave1- Опубликовано 27 мая, 2013 · Жалоба 6500 для такого малого дата центра - это слишком дорого, и абсолютно бессмысленно. ИМХО. А вообще у циски для ДЦ есть специальные решения - серия коммутаторов Nexus. В частности конкретно для данного случая: 2 Nexus 5548UP в ядро + 2XXX FEX-ы на доступ. 5548UP - по совместительству полноценный FC/FCoE коммутатор с универсальными SFP/SFP+/FC портами. FEX - логически представляет линейную плату 5548UP-го. Т.е. логически имеем 1/2 модульных коммутатора. Это решение не особо дороже 3750X. Если оч хочется на классике - то хороший вариант 2 4500-х в самом дешевом наполнении. И в них втыкать сервера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostas Опубликовано 27 мая, 2013 · Жалоба Что лучше использовать для подключения серверов? FHRP или EtherChannel? Это технологии разного уровня, тут не может быть лучше/хуже, должна быть отказоустойчивость как на L2 так и на L3. :) К примеру, если железки в стеке, а к серверу идет etherchannel от обоих, то зачем в таком случае отказоустойчивость на L3? Nexus не смотре, спасибо. Думал они зело дороже чем классические девайсы циско. Посмотрю... SergeiK 10GE интерфейсов пока нет и не предвидится. Если что - будем расширяться etherchannel'ом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DruGoe_DeLo Опубликовано 27 мая, 2013 (изменено) · Жалоба Всем спасибо за помощь. На PC решения не рассматриваем. 6500 (4500) новые дорогова-то будет, хотелось бы что нибудь новое, с гарантией. Хотя конечно на них было бы замечательно поднять ядро - масштабируемость на высоте. И стекирование у 6500 по 10GE замечательное, по крайней мере по описанию. Как вариант буду держать в голове, на случай, если текущая схема не пойдет. Два фулвью нужно для балансировки исходящего трафика - есть пачка публичных сервисов. По дизайну кампусов читал, представляю немного что к чему и для чего. Но как всегда - практика, лучшее дополнение к гайдам :) и хотел совета, в том числе по моделям оборудования. Что лучше использовать для подключения серверов? FHRP или EtherChannel? Я думаю что душе лучше то и используйте. Как вариант для более бюджетного решения можно использовать свитчи и от rubytech есть очень симпотичные железки. Например RubyTech FGS-2824 у нас эти зверушки стоят как коллекторы в некоторых цодах. И бешеные пользователи нагружают порты на 100%. В общем в бою такие железки у нас уже 2 года. И тьфу тфьу тьфу не было ещё сбоев, время поднятия железки после ребута где-то секунд 10 а через 15 она уже лопатит трафик. В общем как для конечных пользователей, использовать на предприятиях, я думаю будет самое то и на гарантии и не дорого. Изменено 27 мая, 2013 пользователем DruGoe_DeLo Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostas Опубликовано 27 мая, 2013 · Жалоба VSS на 6500 - хорош. Но пока это как запасное решение, ибо VSS на сколько я понял, требует наличия прямого 10GE линка между супервизорами, при чем 720ми, которые так же дешевизной не отличаются :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DruGoe_DeLo Опубликовано 27 мая, 2013 · Жалоба ASR судя по отзывам форумчан сам по себе редкостный глюк. Это не то слово. ASR всем хороша пока смотришь по бумажке. А вот что она бывает вытворяет это уже отдельная песня. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
White_Alex Опубликовано 27 мая, 2013 · Жалоба Это не то слово. ASR всем хороша пока смотришь по бумажке. А вот что она бывает вытворяет это уже отдельная песня. как бордер пашет уже второй ASR (из 1002 выросли в 1004 :-)) и не кашляет, что вы с ним такое делаете, что оно у вас глючит? да, nat на нем мы не делаем и не планируем Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
secandr Опубликовано 27 мая, 2013 · Жалоба DruGoe_DeLo ASR 1013 обслуживает город миллионник, город спутник и пару соседних деревень и городков. Что мы делаем не так? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DruGoe_DeLo Опубликовано 28 мая, 2013 (изменено) · Жалоба DruGoe_DeLo ASR 1013 обслуживает город миллионник, город спутник и пару соседних деревень и городков. Что мы делаем не так? у нас asr 1002 держит много плющек(всяких acl, route map,wccp,dhcp,pppoe,одних ограничений по скоростям около 30. и нагрузка cpu не превышает 5-7%) без проблем держит Online 1000 человек. Но стоит отвалится основному каналу, перейти на резервный. То после поднятия основного канала, порт на asr не хочет маслать трафик. Чо только не делали и порт тушили и дебаг включали и анализировали трафик (ничего подозрительного не было найдено), в этот момент нагрузку проца повышается до 50-70%. Помогает только ребут asr. После этого сного всё круто и клёва. P.S. и действительно что мы делаем не так... Это не то слово. ASR всем хороша пока смотришь по бумажке. А вот что она бывает вытворяет это уже отдельная песня. как бордер пашет уже второй ASR (из 1002 выросли в 1004 :-)) и не кашляет, что вы с ним такое делаете, что оно у вас глючит? да, nat на нем мы не делаем и не планируем nat у нас тоже нет. Так как клиенты сидят на белых IP. И ничего мы с ним не делаем ну если только настроили... Изменено 28 мая, 2013 пользователем DruGoe_DeLo Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CityFox Опубликовано 28 мая, 2013 · Жалоба В качестве дешевой альтернативы VSS и 6500 можете посмотреть на виртуальный стек из Juniper EX4200. В каждой серверной поставить 2 или 3 EX4200, локально обьединить медным стековым кабелем и закольцевать эти две половины в общий стек через 2 оптических 10G интерфейса. Логически все будет выглядеть как один свич и можно будет собирать линки к двум серверным в EtherChannel. Ну и MX5 на бордер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
secandr Опубликовано 28 мая, 2013 · Жалоба у нас asr 1002 держит много плющек(всяких acl, route map,wccp,dhcp,pppoe,одних ограничений по скоростям около 30. и нагрузка cpu не превышает 5-7%) без проблем держит Online 1000 человек. Но стоит отвалится основному каналу, перейти на резервный. То после поднятия основного канала, порт на asr не хочет маслать трафик. Чо только не делали и порт тушили и дебаг включали и анализировали трафик (ничего подозрительного не было найдено), в этот момент нагрузку проца повышается до 50-70%. Помогает только ребут asr. После этого сного всё круто и клёва. P.S. и действительно что мы делаем не так... В этих случаях помогает cisco TAC. У нас после установки в продакшен asr 1002 крашился раз в день. Патч выпустили за 2 месяца. Uptime for this control processor is 28 weeks, 4 days, 7 hours, 15 minutes Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
-Pave1- Опубликовано 28 мая, 2013 · Жалоба В качестве дешевой альтернативы VSS и 6500 можете посмотреть на виртуальный стек из Juniper EX4200. В каждой серверной поставить 2 или 3 EX4200, локально обьединить медным стековым кабелем и закольцевать эти две половины в общий стек через 2 оптических 10G интерфейса. Логически все будет выглядеть как один свич и можно будет собирать линки к двум серверным в EtherChannel. А вот, если не секрет, нафига нужен стек между 2 сайтами? :) Чтобы один общий контрол-плэйн на все железки был натянут, и глюков было больше? В чем смысл? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CityFox Опубликовано 28 мая, 2013 · Жалоба В качестве дешевой альтернативы VSS и 6500 можете посмотреть на виртуальный стек из Juniper EX4200. В каждой серверной поставить 2 или 3 EX4200, локально обьединить медным стековым кабелем и закольцевать эти две половины в общий стек через 2 оптических 10G интерфейса. Логически все будет выглядеть как один свич и можно будет собирать линки к двум серверным в EtherChannel. А вот, если не секрет, нафига нужен стек между 2 сайтами? :) Чтобы один общий контрол-плэйн на все железки был натянут, и глюков было больше? В чем смысл? Резервирование без *STP и L3. Если оно нужно, конечно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostas Опубликовано 28 мая, 2013 · Жалоба В качестве дешевой альтернативы VSS и 6500 можете посмотреть на виртуальный стек из Juniper EX4200. В каждой серверной поставить 2 или 3 EX4200, локально обьединить медным стековым кабелем и закольцевать эти две половины в общий стек через 2 оптических 10G интерфейса. Логически все будет выглядеть как один свич и можно будет собирать линки к двум серверным в EtherChannel. Ну и MX5 на бордер. Спасибо. Посчитаю стоимость такого комплекта. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 28 мая, 2013 · Жалоба рубитеки в датацентре... я что-то не понимаю в этой жизни... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostas Опубликовано 28 мая, 2013 · Жалоба А вот, если не секрет, нафига нужен стек между 2 сайтами? :) Чтобы один общий контрол-плэйн на все железки был натянут, и глюков было больше? В чем смысл? В общем-то да - стеки нужны в пределах одного сайта для резервирования L2 линков. Между сайтами польза наверно только в едином контрол плейне, не более. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kostas Опубликовано 29 мая, 2013 (изменено) · Жалоба А как такой вариант для ядра и доступа? Раз уж пока основное это звено сейчас обсуждается :) 1. Для ядра используем не дорогие WS-C3750G-12S в стеке из 2х штук (распологаем в одном из сайтов) 2. Делаем одинаковый доступ что для LAN, что для серверов обоих ДЦ с помощью 2960S раскиданных по стойкам (при необходимости наращиваем емкость стекированием по месту). 3. На удаленный сайт цепляем доступ к ядру по волокну (есть 8шт), то есть 4 удаленных 2960S можно будет запитать + стек при необходимости Напомню, что стекирование в ядре используется для построения отказоустойчивого ядра (между сайтами размазывать его нет смысла мне кажется), а так же для подключения уровня доступа L2 по EtherChannel. Изменено 29 мая, 2013 пользователем kostas Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NikAlexAn Опубликовано 30 мая, 2013 · Жалоба А как такой вариант для ядра и доступа? Раз уж пока основное это звено сейчас обсуждается :) 1. Для ядра используем не дорогие WS-C3750G-12S в стеке из 2х штук (распологаем в одном из сайтов) 2. Делаем одинаковый доступ что для LAN, что для серверов обоих ДЦ с помощью 2960S раскиданных по стойкам (при необходимости наращиваем емкость стекированием по месту). 3. На удаленный сайт цепляем доступ к ядру по волокну (есть 8шт), то есть 4 удаленных 2960S можно будет запитать + стек при необходимости Напомню, что стекирование в ядре используется для построения отказоустойчивого ядра (между сайтами размазывать его нет смысла мне кажется), а так же для подключения уровня доступа L2 по EtherChannel. А 2960G не подходят? Если не упираетесь в производительность 1G линков можно ведь и не стекировать а для отказоустойчивости соединять коммутаторы доступа на каждый из коммутаторов ядра и использовать GLBP или HSRP. Коммутаторы доступа помещать в отдельный влан с маршрутизацией на коммутаторах ядра и тогда можно линки между ДЦ балансировать используя rapid-pvst+ или mst да и нагрузку на маршрутизирующие коммутаторы распределить приоритетами GLBP и HSRP. Да и VRRP можно использовать. Для выхода в мир использовать 2 маршрутизатора подключенные к каждому из коммутаторов ядра. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...