А я вот считаю дизайн продукции Apple омерзительным, как и используемые в макбуке материалы (алюминий никуда не годится). И что, разве я хожу по всем связанным с яблоками топикам и ору об этом?
возвращаемся к вопросу о саппорте
Тут можно вспомнить мир IP телефонии и то, что огромное количество операторов использует астериск… Всегда можно найти компанию со своим штатом разработчиков, которая за деньги берется сопровождать опенсорсное решение.
Ну ладно, дальше спорить лень. Финальным аккордом дайте ссылку на 100% программное решение, которое осилит весь указанный Вами функционал на 30гб/с и обеспечит задержку не более одной миллисекунды :)
«А нетфлоу-коллектор ещё небось денег стоит в случае масштабов SP, да?»
Учитывая, что многие сервис-провайдеры переходят на опенсорс — вообще не факт. У большинства какти внедрен к примеру. С плагинами он способен на всё.
Есть ли возможность при помощи NBAR повесить на него определённую политику в соответствии с его тарифным планом?
Вы уж определитесь — нужно решение «всё в одном», или нет?
С точки зрения провайдера, есть две разные задачи: зарезать скорость Васе до тарифной и узнать, чем же он занимался. В первом случае — причем тут NBAR?
Вообще ИМХО глупо ставить в inline анализатор трафика, который не будет вмешиваться в трафик. Т.е. логичнее всего просто-напросто организовать SPAN в сторону DPI девайса.
Можно на цифры взглянуть? В IPS же ещё эвристика во все поля?
Я же говорю — Вы как-то много чего пропустили. en.wikipedia.org/wiki/Intrusion_prevention_system
«Signature-Based Detection: This method of detection utilizes signatures, which are attack patterns that are preconfigured and predetermined. A signature-based intrusion prevention system monitors the network traffic for matches to these signatures. Once a match is found the intrusion prevention system takes the appropriate action. Signatures can be exploit-based or vulnerability-based. Exploit-based signatures analyze patterns appearing in exploits being protected against, while vulnerability-based signatures analyze vulnerabilities in a program, its execution, and conditions needed to exploit said vulnerability.»
По сигнатурам определяются пакеты, способные использовать известную уязвимость.
Это лишь один из методов работы IDS/IPS.
Цифры? Счет, по-моему, идет на десятки/сотни тысяч. Но вот момент: нет смысла включать те сигнатуры, что не представляют угрозы. Потому по факту будет задействовано меньшее их количество.
девайсы пеерсылают друг другу as is весь трафик, считающийся асимметричным.
То есть никаких отличий от классического ERSPAN? У меня тоже в нескольких точках сети собирается голосовой трафик и отсылается на сниффилки за несколько хопов. Скучно.
Ну вот не знаю я NBAR, застрелиться мне теперь?
Вы прямо перед этим писали, что NBAR — отстой и вообще ни на что не годится. А сейчас выясняется, что Вы просто про него не знаете…
а построить быстро и качественно работающую систему, позволяющую из этих пустых цифр рисовать то, что мне требуется — это совсем другое.
У циски оно работает превосходно. У Sourcefire оно работает превосходно. Это за деньги. Бесплатно — snort, rrdtool, пара недель работы напильником — и тоже все отлично.
Но вопрос отображения данных уже не относится к вопросу отлавливания и анализа пакетов, тут как раз никакого rocket science.
Можете оценить, сколько денег будет стоить разработка софта, который будет лазить в нетфлоу-коллектор, выискивать там циферки и рисовать графики в режиме реального времени?
А уж представьте себе, сколько стоит разработка такой сложной штуки, как ядро Linux :) Ах да, он же бесплатно распространяется…
какая задержка в трафик вносится при работе NBAR?
Понятия не имею. Если сильно надо — могу погуглить.
Но опять же, если мы говорим о порядочном провайдере, то сенсор будет лишь получать копию трафика, а не стоять на его пути.
перформанс хилый, стоит дорого, занимает драгоценные слоты в недешёвой коробке.
Обалдеть…
1) 15гб/с гарантируют.
2) Бандл WS-C6506-E-NAM3-K9 (по названию все понятно?) стоит по GPL $95k. Аналогично с 6509 — $98k. И нет, шасси cat6500 как раз самое дешевое в нем, слоты — не проблема.
Вы можете предложить мне вменяемое интегрированное решение, рассчитанное на близкую к сотне гиг производительность в режиме полной загрузки коробки?
Вы не смогли. Речь шла про 20 гиг, во что тоже не слишком верится.
Но: NAM3 стоит $60k (опять же, цены GPL, в реальности куда ниже). В один cat6500 можно набить много этих самых NAMов. В принципе — пока слоты не закончатся. Иными словами — я могу предоставить коробку, которая гарантированно (не только в пике) осилит, скажем, 120гб/с анализа трафика (линейные карты тоже надо куда-то втыкать), а маршрутизировать суммарно сможет теоретически под 2тб/с (хотя останется слишком мало слотов, чтобы этим воспользоваться).
Вы сможете дать мне такую коробку от конкурентов? Есть мнение, что даже любая из блейд-корзин будет уступать шеститоннику…
Оно умеет по Netflow отдавать статистику по каждому приложению?
Ага. www.networkworld.com/community/node/48191 А интегрироваться с биллингом будет?
Это следует из возможности экспортировать статистику. В чём если не секрет?
Очевидно — в нагрузке на ЦП. У IPS сильно больше сигнатур. NBAR protocol-discovery на роутерах кушает меньше ЦП, чем средний IPS. И как мне это ставить в проекте масштабов страны? Как оно будет саппортиться?
А никак. Саппортиться будет тот же sourcefire. Но лучше цискины решения. Ну-ну, сами-то проверяли на сложных протоколах, таких как skype и шифрованный торрент?
У меня дома оно прекрасно делает match protocol skype, иосу где-то год уже.
Думаю, с uTP и тому подобным проблем тоже не будет.
Написать свою сигнатуру не проблема ;) На офсайте вижу последний апдейт аж от 27 января, а на дворе середина мая.
В составе новой версии ОС уже имеются свежие PDLM. Или их можно скачать отдельно. а как у NBAR с асимметричным трафиком дела обстоят?
А не существует (даже теоретически) решений, действительно качественно работающих с асимметричным роутингом. Не верьте маркетологам. Какого рода статистику можно собрать при помощи NBAR? Подозреваю ...
Может, надо не подозревать, а просто знать? нормальные DPI коробки рисуют самые разнообразные графики
На основе тех же данных по количеству пакетиков за определенный интервал времени :)
Маркетологи умеют промывать мозги… что происходит с загрузкой CPU при работе NBAR?
Где-то на четверть проседает. Учитывая, что хороший тон при выборе железа исходить из 25% загрузки ЦП в пике — не проблема. Не надо пытаться мне доказать, что всё-в-одном-флаконе будет лучше, чем stand-alone решение, разработанное для решения этой и только это задачи
Так откройте глаза и взгляните например на блейд Cisco NAM — www.cisco.com/en/US/products/ps11659/index.html. Вот как бы отдельная железка, но вставляемая в шасси cat6500 или 7600. Любители разнообразных графиков оценят :) я в теме DPI варюсь не первый год.
Честно говоря, не очень заметно. Вы оперируете маркетинговыми терминами, но не назвали ни одного конкретного довода.
А какой смысл спорить с такими преподавателями?
Я «учился» у одного из той же серии. В состоянии фейспалма прослушав первую лекцию, я подошел к нему, показал карточку с надписью «CCNP», назвал работодателя и должность — и больше не ходил, проставив в зачетку пятерку где-то через неделю после экзамена (лень было на сам экзамен идти) :)
Глубокий анализ всех проходящих пакетов с разбивкой по приложениям
То есть тот же NBAR на цискиных роутерах, с прикрученным netflow. А он ЗНАЧИТЕЛЬНО быстрее IPSа. 10G FDX означает, что девайс перелопатит трафик даже в том случае, если каждое из устройств будет генерить его с битрейтом 10Gbps.
То есть тем более данная реализация DPI значительно проще, чем IPS (кстати — тоже подвид DPI). Стоит такой модуль вместе с лицензией $150k. Сколько стоит ваш снорт?
Снорт бесплатен, и вроде его можно скомпилировать под каждый процессор. Это и есть «заточка».
Готовый апплайанс на снорте? Например, есть Sourcefire. Точные расценки на анализ 10G не назову, но он значительно дешевле.
Даже Cisco ASR1000 «Flexible Packet Inspection Bundles» под 20гб/с стоят от $75к до $100к (это по GPL, т.е. смело вычитаем минимум 30%). Да, даже более примитивный роутерный NBAR легко отличит различит HTTPS, skype и торренты.
«я имел в виду достаточно мощный DPI девайс, исполняющий нечто куда сложнее, чем IPS»
Любопытства ради — чем же он там таким сложным занимается?
mikelococo.com/2011/08/snort-capacity-planning/ One or two links 1-10Gbit/sec – You definitely need multi-snort with high-performance capture hardware. I’m partial to Endace, but pfring with a 10G TNAPI-compatible card should also work. You need 1-core and 4Gbytes of ram for every 250Mbits/sec of traffic that you need to inspect. Alternatively, consider a Sourcefire system. If you’re just getting started with Snort this is going to be a big project to do on your own.
Many links or greater than 10Gbit/sec traffic – Try to break the problem down into multiple instances of the above cases. A Gigamon box at each site may give you the flexibility that you need to split the problem across multiple servers effectively. You also might also need a moderately high-performance database server, properly tuned and sized.
В упомянутой Вами системе говорится про 10гб/с инспектирования (я правильно понимаю, что под «full duplex» имеется в виду, что обработанный трафик покидает коробку через тот же шнурок?), и при этом справляются 12 ядер. Хотя тот же Snort обещает загнуться при таких условиях, или как минимум работать на пределе. Странно как-то…
двух Xeon L5638 хватает, чтобы перелопатить 10gbps в фуллдуплексе
Скучный вторник для ASAшек. 5585X потянет это еще и с IPS инспектированием. По сравнению с этим исходящий шейпер — мелочь, недостойная внимания.
Товарищ salium умело аргументировал тут
Товарищ аргументировал про сильно операторскую сеть, и хочет много чего явно лишнего.
Я не вижу смысла в ядре заглядывать настолько глубоко в пакет ради идеального распараллеливания трафика. Что до базового FRR (как с MPLS, так и без) — все умеют это делать.
Если коротко, то там нечто сугубо самописное и очень производительное.
Вас, видимо, кто-то обманул, либо Вы не поняли сказанное.
«Ядро сети» — по определению довольно безмозглые пакетодробилки. От них не требуется какого-либо инспектирования. Но они должны обеспечить высокую скорость передачи данных с минимальными задержками (единицы микросекунд), ну и иметь кучу портов. Ни одно программное решение по определению под такое не годится.
Так что советую переспросить знакомых, точно ли у них аплинки с коммутаторов уровня доступа сходятся на серверах :)
Ну а если они заказывают у кого-нибудь нормальные железки с нормальными ASICами и лишь пишут под них control plane — другой разговор. Но это не софтовый роутинг.
Топовые роутеры — скорее линейки CRS, ASR, 7600 (ну и 6500, который по недоразумению назван свитчем). Нет, они все железные. Софтовые — только 7200, 3900 и ниже. Т.е. наиболее медленные из всех.
Только не надо говорить «даже у CRS-3 внутри ОС, потому они все софтовые» :)
«роутеринг, DPI» мне ни о чем не говорят, но да, можно еще рендер-фермы вспомнить. Я все-таки говорю о наиболее типичных случаях. А сейчас типично 1G до сервера и 10G на аплинк.
Опять же, live migration сотен виртуалок разом — нонсенс в любом случае. А если произошла (или вот-вот должна произойти) катастрофа, то тем более любой нормальный человек отбросит понты и просто поднимет виртуалки с реплицированного хранилища на новой площадке.
Но все-таки как сетевик я терпеть не могу L2, особенно когда он сильно спанится.
1) Делать простой транк между площадками — безумие. Авария на одном ЦОДе имеет шанс положить и соседа. Да и даже без аварий на транке будет гулять слишком много мусора. И нужны костыли, чтобы сервер на каждой из площадок выбирал правильного next hop'а. Так что надеюсь, так никто никогда не делает.
2) OTV к примеру гарантирует, что broadcast и unknown unicast трафик не будут бегать между ЦОДами, и скорее всего авария одной площадки не затронет другую («скорее всего» — полную гарантию даст только L3). Но он дорого стоит (Nexus 7k), и все равно трафик будет ходить абсолютно неоптимально.
Потому наиболее красивое решение — чтобы by design не было нужды перемещать машину с площадки на площадку с сохранением IP адреса. Пусть будут по две занятые общим делом машины в двух разных ЦОДах. В пределах ЦОДа можно делать балансировку средствами ACE. Между ЦОДами — GSS. Да можно хоть включить route injection — клиенты обращаются к VIP адресу ресурса, и этот VIP анонсируется как /32 маршрут тем балансировщиком, который является активным, а при смерти ЦОДа этот /32 маршрут через несколько секунд всплывет в другом месте. И уже неважно, какие у серверов адреса. И нет никакой нагрузки на сеть в момент переезда.
Все эти решения значительно лучше, чем «VLAN растянут на 2 ЦОДа».
Но в принципе, существует типичный конфликт непонимания между «server guys» и «network guys».
«И судя по тому, сколько усилий в этот направлении тратят производители сетевого оборудования и платформ виртуализации, функционал востребован заказчиками. „
Основные усилия тратятся производителями платформ виртуализации и направлены на промывание мозгов серверных админов. И часто бывает, что те загораются новой идеей и начинают давить на сетевиков, не понимая возникающих на уровне сети проблем. И тут сетевые вендоры присасываются к кормушке и выпускают костыли, убирающие часть проблем.
И мало кто акцентирует внимание на L3 технологиях, потому что тут в восторге будут сетевики, но не будет никаких killer-фич для server guys.
подобная тактика из крупных вендоров осталась разве что у Cisco
Одна скрытая команда, затем предупреждение на полэкрана вида «TAC пошлет вас куда подальше с неродными трансиверами» — и циска (cat6500 по крайней мере) начинает вполне уверенно работать с чужими SFP.
Тут можно вспомнить мир IP телефонии и то, что огромное количество операторов использует астериск… Всегда можно найти компанию со своим штатом разработчиков, которая за деньги берется сопровождать опенсорсное решение.
Ну ладно, дальше спорить лень. Финальным аккордом дайте ссылку на 100% программное решение, которое осилит весь указанный Вами функционал на 30гб/с и обеспечит задержку не более одной миллисекунды :)
Учитывая, что многие сервис-провайдеры переходят на опенсорс — вообще не факт. У большинства какти внедрен к примеру. С плагинами он способен на всё.
Есть ли возможность при помощи NBAR повесить на него определённую политику в соответствии с его тарифным планом?
Вы уж определитесь — нужно решение «всё в одном», или нет?
С точки зрения провайдера, есть две разные задачи: зарезать скорость Васе до тарифной и узнать, чем же он занимался. В первом случае — причем тут NBAR?
Вообще ИМХО глупо ставить в inline анализатор трафика, который не будет вмешиваться в трафик. Т.е. логичнее всего просто-напросто организовать SPAN в сторону DPI девайса.
Можно на цифры взглянуть? В IPS же ещё эвристика во все поля?
Я же говорю — Вы как-то много чего пропустили.
en.wikipedia.org/wiki/Intrusion_prevention_system
«Signature-Based Detection: This method of detection utilizes signatures, which are attack patterns that are preconfigured and predetermined. A signature-based intrusion prevention system monitors the network traffic for matches to these signatures. Once a match is found the intrusion prevention system takes the appropriate action. Signatures can be exploit-based or vulnerability-based. Exploit-based signatures analyze patterns appearing in exploits being protected against, while vulnerability-based signatures analyze vulnerabilities in a program, its execution, and conditions needed to exploit said vulnerability.»
По сигнатурам определяются пакеты, способные использовать известную уязвимость.
Это лишь один из методов работы IDS/IPS.
Цифры? Счет, по-моему, идет на десятки/сотни тысяч. Но вот момент: нет смысла включать те сигнатуры, что не представляют угрозы. Потому по факту будет задействовано меньшее их количество.
девайсы пеерсылают друг другу as is весь трафик, считающийся асимметричным.
То есть никаких отличий от классического ERSPAN? У меня тоже в нескольких точках сети собирается голосовой трафик и отсылается на сниффилки за несколько хопов. Скучно.
Ну вот не знаю я NBAR, застрелиться мне теперь?
Вы прямо перед этим писали, что NBAR — отстой и вообще ни на что не годится. А сейчас выясняется, что Вы просто про него не знаете…
а построить быстро и качественно работающую систему, позволяющую из этих пустых цифр рисовать то, что мне требуется — это совсем другое.
У циски оно работает превосходно. У Sourcefire оно работает превосходно. Это за деньги. Бесплатно — snort, rrdtool, пара недель работы напильником — и тоже все отлично.
Но вопрос отображения данных уже не относится к вопросу отлавливания и анализа пакетов, тут как раз никакого rocket science.
Можете оценить, сколько денег будет стоить разработка софта, который будет лазить в нетфлоу-коллектор, выискивать там циферки и рисовать графики в режиме реального времени?
А уж представьте себе, сколько стоит разработка такой сложной штуки, как ядро Linux :) Ах да, он же бесплатно распространяется…
какая задержка в трафик вносится при работе NBAR?
Понятия не имею. Если сильно надо — могу погуглить.
Но опять же, если мы говорим о порядочном провайдере, то сенсор будет лишь получать копию трафика, а не стоять на его пути.
перформанс хилый, стоит дорого, занимает драгоценные слоты в недешёвой коробке.
Обалдеть…
1) 15гб/с гарантируют.
2) Бандл WS-C6506-E-NAM3-K9 (по названию все понятно?) стоит по GPL $95k. Аналогично с 6509 — $98k. И нет, шасси cat6500 как раз самое дешевое в нем, слоты — не проблема.
Вы можете предложить мне вменяемое интегрированное решение, рассчитанное на близкую к сотне гиг производительность в режиме полной загрузки коробки?
Вы не смогли. Речь шла про 20 гиг, во что тоже не слишком верится.
Но: NAM3 стоит $60k (опять же, цены GPL, в реальности куда ниже). В один cat6500 можно набить много этих самых NAMов. В принципе — пока слоты не закончатся. Иными словами — я могу предоставить коробку, которая гарантированно (не только в пике) осилит, скажем, 120гб/с анализа трафика (линейные карты тоже надо куда-то втыкать), а маршрутизировать суммарно сможет теоретически под 2тб/с (хотя останется слишком мало слотов, чтобы этим воспользоваться).
Вы сможете дать мне такую коробку от конкурентов? Есть мнение, что даже любая из блейд-корзин будет уступать шеститоннику…
Ага.
www.networkworld.com/community/node/48191
А интегрироваться с биллингом будет?
Это следует из возможности экспортировать статистику.
В чём если не секрет?
Очевидно — в нагрузке на ЦП. У IPS сильно больше сигнатур. NBAR protocol-discovery на роутерах кушает меньше ЦП, чем средний IPS.
И как мне это ставить в проекте масштабов страны? Как оно будет саппортиться?
А никак. Саппортиться будет тот же sourcefire. Но лучше цискины решения.
Ну-ну, сами-то проверяли на сложных протоколах, таких как skype и шифрованный торрент?
У меня дома оно прекрасно делает match protocol skype, иосу где-то год уже.
Думаю, с uTP и тому подобным проблем тоже не будет.
Написать свою сигнатуру не проблема ;)
На офсайте вижу последний апдейт аж от 27 января, а на дворе середина мая.
В составе новой версии ОС уже имеются свежие PDLM. Или их можно скачать отдельно.
а как у NBAR с асимметричным трафиком дела обстоят?
А не существует (даже теоретически) решений, действительно качественно работающих с асимметричным роутингом. Не верьте маркетологам.
Какого рода статистику можно собрать при помощи NBAR? Подозреваю ...
Может, надо не подозревать, а просто знать?
нормальные DPI коробки рисуют самые разнообразные графики
На основе тех же данных по количеству пакетиков за определенный интервал времени :)
Маркетологи умеют промывать мозги…
что происходит с загрузкой CPU при работе NBAR?
Где-то на четверть проседает. Учитывая, что хороший тон при выборе железа исходить из 25% загрузки ЦП в пике — не проблема.
Не надо пытаться мне доказать, что всё-в-одном-флаконе будет лучше, чем stand-alone решение, разработанное для решения этой и только это задачи
Так откройте глаза и взгляните например на блейд Cisco NAM — www.cisco.com/en/US/products/ps11659/index.html. Вот как бы отдельная железка, но вставляемая в шасси cat6500 или 7600. Любители разнообразных графиков оценят :)
я в теме DPI варюсь не первый год.
Честно говоря, не очень заметно. Вы оперируете маркетинговыми терминами, но не назвали ни одного конкретного довода.
На современных свитчах и при full duplex такого нет и на 100мб/с.
Типовые свитчи дают около 8 микросекунд задержки.
У циски есть и накачанные стероидами нексусы 3000, разработанные специально для ситуаций, когда даже 8мкс — слишком много: www.cisco.com/en/US/prod/collateral/switches/ps9441/ps11541/white_paper_c11-661939.html#wp9000066
Я «учился» у одного из той же серии. В состоянии фейспалма прослушав первую лекцию, я подошел к нему, показал карточку с надписью «CCNP», назвал работодателя и должность — и больше не ходил, проставив в зачетку пятерку где-то через неделю после экзамена (лень было на сам экзамен идти) :)
То есть тот же NBAR на цискиных роутерах, с прикрученным netflow. А он ЗНАЧИТЕЛЬНО быстрее IPSа.
10G FDX означает, что девайс перелопатит трафик даже в том случае, если каждое из устройств будет генерить его с битрейтом 10Gbps.
То есть тем более данная реализация DPI значительно проще, чем IPS (кстати — тоже подвид DPI).
Стоит такой модуль вместе с лицензией $150k. Сколько стоит ваш снорт?
Снорт бесплатен, и вроде его можно скомпилировать под каждый процессор. Это и есть «заточка».
Готовый апплайанс на снорте? Например, есть Sourcefire. Точные расценки на анализ 10G не назову, но он значительно дешевле.
Даже Cisco ASR1000 «Flexible Packet Inspection Bundles» под 20гб/с стоят от $75к до $100к (это по GPL, т.е. смело вычитаем минимум 30%). Да, даже более примитивный роутерный NBAR легко отличит различит HTTPS, skype и торренты.
Любопытства ради — чем же он там таким сложным занимается?
mikelococo.com/2011/08/snort-capacity-planning/
One or two links 1-10Gbit/sec – You definitely need multi-snort with high-performance capture hardware. I’m partial to Endace, but pfring with a 10G TNAPI-compatible card should also work. You need 1-core and 4Gbytes of ram for every 250Mbits/sec of traffic that you need to inspect. Alternatively, consider a Sourcefire system. If you’re just getting started with Snort this is going to be a big project to do on your own.
Many links or greater than 10Gbit/sec traffic – Try to break the problem down into multiple instances of the above cases. A Gigamon box at each site may give you the flexibility that you need to split the problem across multiple servers effectively. You also might also need a moderately high-performance database server, properly tuned and sized.
В упомянутой Вами системе говорится про 10гб/с инспектирования (я правильно понимаю, что под «full duplex» имеется в виду, что обработанный трафик покидает коробку через тот же шнурок?), и при этом справляются 12 ядер. Хотя тот же Snort обещает загнуться при таких условиях, или как минимум работать на пределе. Странно как-то…
А вот это уже другой разговор.
Скучный вторник для ASAшек. 5585X потянет это еще и с IPS инспектированием. По сравнению с этим исходящий шейпер — мелочь, недостойная внимания.
Товарищ аргументировал про сильно операторскую сеть, и хочет много чего явно лишнего.
Я не вижу смысла в ядре заглядывать настолько глубоко в пакет ради идеального распараллеливания трафика. Что до базового FRR (как с MPLS, так и без) — все умеют это делать.
Вас, видимо, кто-то обманул, либо Вы не поняли сказанное.
«Ядро сети» — по определению довольно безмозглые пакетодробилки. От них не требуется какого-либо инспектирования. Но они должны обеспечить высокую скорость передачи данных с минимальными задержками (единицы микросекунд), ну и иметь кучу портов. Ни одно программное решение по определению под такое не годится.
Так что советую переспросить знакомых, точно ли у них аплинки с коммутаторов уровня доступа сходятся на серверах :)
Ну а если они заказывают у кого-нибудь нормальные железки с нормальными ASICами и лишь пишут под них control plane — другой разговор. Но это не софтовый роутинг.
Какой псих поставит в ядро ISR? Зачем?
Только не надо говорить «даже у CRS-3 внутри ОС, потому они все софтовые» :)
Но все-таки как сетевик я терпеть не могу L2, особенно когда он сильно спанится.
1) Делать простой транк между площадками — безумие. Авария на одном ЦОДе имеет шанс положить и соседа. Да и даже без аварий на транке будет гулять слишком много мусора. И нужны костыли, чтобы сервер на каждой из площадок выбирал правильного next hop'а. Так что надеюсь, так никто никогда не делает.
2) OTV к примеру гарантирует, что broadcast и unknown unicast трафик не будут бегать между ЦОДами, и скорее всего авария одной площадки не затронет другую («скорее всего» — полную гарантию даст только L3). Но он дорого стоит (Nexus 7k), и все равно трафик будет ходить абсолютно неоптимально.
Потому наиболее красивое решение — чтобы by design не было нужды перемещать машину с площадки на площадку с сохранением IP адреса. Пусть будут по две занятые общим делом машины в двух разных ЦОДах. В пределах ЦОДа можно делать балансировку средствами ACE. Между ЦОДами — GSS. Да можно хоть включить route injection — клиенты обращаются к VIP адресу ресурса, и этот VIP анонсируется как /32 маршрут тем балансировщиком, который является активным, а при смерти ЦОДа этот /32 маршрут через несколько секунд всплывет в другом месте. И уже неважно, какие у серверов адреса. И нет никакой нагрузки на сеть в момент переезда.
Все эти решения значительно лучше, чем «VLAN растянут на 2 ЦОДа».
Но в принципе, существует типичный конфликт непонимания между «server guys» и «network guys».
«И судя по тому, сколько усилий в этот направлении тратят производители сетевого оборудования и платформ виртуализации, функционал востребован заказчиками. „
Основные усилия тратятся производителями платформ виртуализации и направлены на промывание мозгов серверных админов. И часто бывает, что те загораются новой идеей и начинают давить на сетевиков, не понимая возникающих на уровне сети проблем. И тут сетевые вендоры присасываются к кормушке и выпускают костыли, убирающие часть проблем.
И мало кто акцентирует внимание на L3 технологиях, потому что тут в восторге будут сетевики, но не будет никаких killer-фич для server guys.
Одна скрытая команда, затем предупреждение на полэкрана вида «TAC пошлет вас куда подальше с неродными трансиверами» — и циска (cat6500 по крайней мере) начинает вполне уверенно работать с чужими SFP.