zlolotus Опубликовано 17 марта, 2012 (изменено) · Жалоба А вот скажите какое бытует мнение, в пользу аппаратных решений в качестве бордера? Какие плюсы? Латентность разная и примерно насколько? Хочется услышать практический опыт. (Сорри, если это обсуждалось) Изменено 17 марта, 2012 пользователем zlolotus Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 17 марта, 2012 (изменено) · Жалоба Есть где-то 5 критериев: 1. Пропускная способность. 1-2-4-8 Mpps Вы на софте еще пропустите (8, возможно, уже не одной железкой), но на большее придется смотреть в сторону аппаратного решения. 2. Энергопотребление: у софтроутеров оно, как правило, выше. 3. Гибкость / удобство конфигурации. Гибкость как правило выше у софтового решения, удобство - как правило, у проприетарного аппаратного. 4. Надежность / резервируемость. У аппаратных решений надежность обычно в целом выше, чем у серверов общего назначения. Резервируемость - на софте можно построить в принципе любую, но надо время. У серьезных аппаратных решений резервируемость уже заложена. 5. Стоимость. Аппаратное решение обойдется вам минимум в 2-3 раза дороже сервера в единовременном плане. Серьезное аппаратное решение с резервированием, саппортом и прочим - в десятки раз. В эксплуатации - тут уже надо считать, сколько потратите там и там на поддержку, каковы риски, и т.п. - т.е. единой версии нет. Изменено 17 марта, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 17 марта, 2012 · Жалоба 3. Гибкость / удобство конфигурации. Гибкость как правило выше у софтового решения, удобство - как правило, у проприетарного аппаратного. Удобство - сомнительно. В чем умеешь работать, в том и работаешь. Работать в сети с разнобрендовыми железки удовольствие не из приятных. 4. Надежность / резервируемость. У аппаратных решений надежность обычно в целом выше, чем у серверов общего назначения. Резервируемость - на софте можно построить в принципе любую, но надо время. У серьезных аппаратных решений резервируемость уже заложена. В серьезных аппаратных решениях за резерв надо платить часто больше. 6) Скорость замены по гарантии разная. 7) Длительность фикса багов в аппаратных решениях. 8) За новые прошивки к аппаратным железкам надо платить отдельно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 18 марта, 2012 · Жалоба А вот скажите какое бытует мнение, в пользу аппаратных решений в качестве бордера? Какие плюсы? Латентность разная и примерно насколько? Хочется услышать практический опыт. До пары гигабит аппаратное решение преимуществ imho не имеет. После 3-4 гигабит программное решение превращается просто в придаток к 10г-картам. Обработку такого трафика надо делать не одной коробкой, а комплексом из нескольких, который включает в себя и быстрые специализированные аппаратные молотилки, и универсальные недорогие PC. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MMM Опубликовано 18 марта, 2012 · Жалоба Кстати, интересно найти такой вариант: маломощный PC софтроутер с несколькими FullView и какой-то "аппаратный комплекс", который пропускает через себя несколько 10Г каналов трафика (что-то вроде L3 свича). Соответственно, софтроутер управляет маршрутизацией "аппарата". Кто-нибудь подскажет решение? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
StSphinx Опубликовано 18 марта, 2012 · Жалоба Кстати, интересно найти такой вариант: маломощный PC софтроутер с несколькими FullView и какой-то "аппаратный комплекс", который пропускает через себя несколько 10Г каналов трафика (что-то вроде L3 свича). Соответственно, софтроутер управляет маршрутизацией "аппарата". Кто-нибудь подскажет решение? Решение называется route-server и используется в основном на пиринговых площадках. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 18 марта, 2012 · Жалоба Решение называется route-server и используется в основном на пиринговых площадках. В последнее время очень полюбилось ТТК. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MMM Опубликовано 18 марта, 2012 · Жалоба Кстати, интересно найти такой вариант: маломощный PC софтроутер с несколькими FullView и какой-то "аппаратный комплекс", который пропускает через себя несколько 10Г каналов трафика (что-то вроде L3 свича). Соответственно, софтроутер управляет маршрутизацией "аппарата". Кто-нибудь подскажет решение? А как оно работает? На пирах нужно настраивать bgp multihop ? Решение называется route-server и используется в основном на пиринговых площадках. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
StSphinx Опубликовано 18 марта, 2012 · Жалоба Кстати, интересно найти такой вариант: маломощный PC софтроутер с несколькими FullView и какой-то "аппаратный комплекс", который пропускает через себя несколько 10Г каналов трафика (что-то вроде L3 свича). Соответственно, софтроутер управляет маршрутизацией "аппарата". Кто-нибудь подскажет решение? А как оно работает? На пирах нужно настраивать bgp multihop ? Именно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 18 марта, 2012 · Жалоба ИМХО, при низких скоростях у железки будет одно преимущество - от флуда не скукожится. Минусы железок уже описали (имеете то, что дает вендор, и никаких доп. фич не прикрутить внутрь). А при скоростях в несколько гигабит на девайс (тазик/железку) - таки тазики становятся слишком уж монструозными и требуют тщательного тюнинга... 10G и выше - уже, пожалуй, на тазиках отроутить не получится адекватно, а если и получится - железка может оказаться дешевле. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
puh Опубликовано 18 марта, 2012 · Жалоба Минусы железок уже описали (имеете то, что дает вендор, и никаких доп. фич не прикрутить внутрь) вы на самом деле думаете, что тазик с линуксом более фичаст, чем решение известного производителя? или фичастость заключается в "поднять брас/бордер/днс/веб сервер в одной коробке"? аппаратные решения, как правило, более узкоспециализированны (bras не умеет dpi, fw - не умеет bgp), но это скорее последствия высокой производительности, решения enterprise класса с ограниченной производительностью умеют всё и одновременно. Впрочем, есть и операторские решения, обладающие универсальностью, но зачем? архитектура сети операторского класса не потворствует аггрегации всего функционала в одну железку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 18 марта, 2012 · Жалоба ИМХО, при низких скоростях у железки будет одно преимущество - от флуда не скукожится. Минусы железок уже описали (имеете то, что дает вендор, и никаких доп. фич не прикрутить внутрь). А при скоростях в несколько гигабит на девайс (тазик/железку) - таки тазики становятся слишком уж монструозными и требуют тщательного тюнинга... 10G и выше - уже, пожалуй, на тазиках отроутить не получится адекватно, а если и получится - железка может оказаться дешевле. Железо подтягивается. PCI-E v3, тундерболт (лайтпик) - как пример что оно возможно. Через года два всё это будет в ближайшем ларьке. Пока иви бридж официально ещё не вышел и никто не шевелится. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 18 марта, 2012 · Жалоба ИМХО, при низких скоростях у железки будет одно преимущество - от флуда не скукожится. Минусы железок уже описали (имеете то, что дает вендор, и никаких доп. фич не прикрутить внутрь). А при скоростях в несколько гигабит на девайс (тазик/железку) - таки тазики становятся слишком уж монструозными и требуют тщательного тюнинга... 10G и выше - уже, пожалуй, на тазиках отроутить не получится адекватно, а если и получится - железка может оказаться дешевле. Железо подтягивается. PCI-E v3, тундерболт (лайтпик) - как пример что оно возможно. Через года два всё это будет в ближайшем ларьке. Пока иви бридж официально ещё не вышел и никто не шевелится. Как правило через два года будут другие требования, да и работать нужно сейчас, а не через два года. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MMM Опубликовано 18 марта, 2012 · Жалоба вы на самом деле думаете, что тазик с линуксом более фичаст, чем решение известного производителя? или фичастость заключается в "поднять брас/бордер/днс/веб сервер в одной коробке"? аппаратные решения, как правило, более узкоспециализированны (bras не умеет dpi, fw - не умеет bgp), но это скорее последствия высокой производительности, решения enterprise класса с ограниченной производительностью умеют всё и одновременно. Впрочем, есть и операторские решения, обладающие универсальностью, но зачем? архитектура сети операторского класса не потворствует аггрегации всего функционала в одну железку. Очень большая стоимость у "аппаратных". Иногда надо банально 5 линков на 10G, десяток линков по 1Г, 3 фулвью (сейчас почти 400к маршрутов в одном, с перспективой в 1кк в ближайшие годы), миррор трафика в порт 10G, и чтобы стоило не дороже 10кбаксов. И нету! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
puh Опубликовано 18 марта, 2012 · Жалоба Иногда надо банально 5 линков на 10G, десяток линков по 1Г, 3 фулвью (сейчас почти 400к маршрутов в одном, с перспективой в 1кк в ближайшие годы), миррор трафика в порт 10G, и чтобы стоило не дороже 10кбаксов. И нету! Хочу новый мерседес. есть 1000 баксов. И нету, представляете! предлагают только убитую девятку!!! ISP - это вам не шаурмой торговать на рынке, это бизнес с большими капиталовложениями. Вспомните про "сжечь 100 долларов". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MMM Опубликовано 18 марта, 2012 · Жалоба Иногда надо банально 5 линков на 10G, десяток линков по 1Г, 3 фулвью (сейчас почти 400к маршрутов в одном, с перспективой в 1кк в ближайшие годы), миррор трафика в порт 10G, и чтобы стоило не дороже 10кбаксов. И нету! Хочу новый мерседес. есть 1000 баксов. И нету, представляете! предлагают только убитую девятку!!! ISP - это вам не шаурмой торговать на рынке, это бизнес с большими капиталовложениями. Вспомните про "сжечь 100 долларов". С капиталовложениями понятно, но хочется именно их избежать. Фактически то, что называют "аппаратным решением" - это софтовый роутер (control plane, если я не ошибаюсь в терминологии) + быстрый свич (Forwarding plane) в одной коробке/шасси. А ищется решение, когда, например, таблицей свича управляет роутер на pc. И можно было бы достичь желаемого "костылями", но тут попадаем на ограничение числа маршрутов в таблице свича. Ходят слухи, что как-то подобную проблему решали с MPLS, но осмыслить это пока не удалось. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
apm Опубликовано 18 марта, 2012 · Жалоба Вспомните про "сжечь 100 долларов". Что за идиома? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
puh Опубликовано 18 марта, 2012 · Жалоба Фактически то, что называют "аппаратным решением" - это софтовый роутер (control plane, если я не ошибаюсь в терминологии) + быстрый свич (Forwarding plane) в одной коробке/шасси. А ищется решение, когда, например, таблицей свича управляет роутер на pc. И можно было бы достичь желаемого "костылями", но тут попадаем на ограничение числа маршрутов в таблице свича. от оно! вы сами понимаете, где собака порылась! что свичик то должен быть не простой! вот какая штука, вендоров на рынке - вагон и маленькая тележка. Кроме сиски и жунипера, есть хуавей, есть алкатель-люсент, снизу подпирают так многими любимые писи-"сделай сам". А цена вот такая. И даже братья-китайцы ценник не роняют. Что за идиома? несколько лет назад весьма популярна была на этом форуме. Хотите заниматься ISP -возьмите 100$ и сожгите их. Рука не дрогнула? Сожгите ещё 100. И ещё. Когда сожгёте миллион, вы достигли нужной зрелости и можете вкладывать в ISP. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 18 марта, 2012 · Жалоба вы на самом деле думаете, что тазик с линуксом более фичаст, чем решение известного производителя? Да. или фичастость заключается в "поднять брас/бордер/днс/веб сервер в одной коробке"? Фичастость заключается в реализации любого функционала, который только пожелаете. Захотелось к примеру получать по бгп несколько вью, при этом анонсить первый вью только бгп-клиентам из влана 5, второй - только бгп-клиентам из влана 10, а третий вообще никуда не анонсить, а пользовать локально - на тазике это элементарно реализовать. На железке, если не заложено - никак. Захотелось еще форвардить пакеты из влана 5 в один аплинк, а из влана 10 - в другой, которые равноценны, и при падении одного из аплинков пускать всех в другой - опять же элементарно на тазике, на железке - скорее всего никак. Хот ответ на это я уже знаю - "это никому не нужно, ибо в железе моего любимого вендора не реализовано, а следовательно - подстраивайтесь под железо, ибо вендор бог и лучше вас знает что вам надо". решения enterprise класса с ограниченной производительностью умеют всё и одновременно Во-первых - не все, а только то, что заложил производитель при разработке софта. Во-вторых - они по сути представляют собой меганавороченный тазик с кастомным софтом, обернутый в красивую коробку с модным лого, и имеют все проблемы, присущие софтроутерам. несколько лет назад весьма популярна была на этом форуме. Хотите заниматься ISP -возьмите 100$ и сожгите их. Рука не дрогнула? Сожгите ещё 100. И ещё. Когда сожгёте миллион, вы достигли нужной зрелости и можете вкладывать в ISP. Мы к примеру стартонули с пары десятков килобаксов. Развиваемся только из прибыли от клиентов, в условиях достаточно жесткой конкуренции (на некоторых домах присутствует 5-6 провайдеров), причем конкуренция была всегда. И развиваемся достаточно успешно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
puh Опубликовано 19 марта, 2012 · Жалоба Фичастость заключается в реализации любого функционала, который только пожелаете. Захотелось к примеру получать по бгп несколько вью, при этом анонсить первый вью только бгп-клиентам из влана 5, второй - только бгп-клиентам из влана 10, а третий вообще никуда не анонсить, а пользовать локально - на тазике это элементарно реализовать. На железке, если не заложено - никак. Захотелось еще форвардить пакеты из влана 5 в один аплинк, а из влана 10 - в другой, которые равноценны, и при падении одного из аплинков пускать всех в другой - опять же элементарно на тазике, на железке - скорее всего никак. если вы считаете, что на "железке" вы ограничены функционалом вендора железки, то хочу напомнить, что на тазике вы ограничены функционалом используемого софта. Вы, конечно, возразите, что возьмёте опенсорс решение и в случае чего сами допилите его код, пофиксите баги. Главное, не забыть добавить человекочасы классного программиста (а вы ведь таким являетесь, раз готовы допиливать кваггу и ядро) в стоимость решения "на тазике". и я что-то не помню, чтобы в квагге была хоть одна фича, которой не было бы в cisco ios. Описанные вами хотелки у сиско и жунипера настраиваются с пол-пинка Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 19 марта, 2012 · Жалоба если вы считаете, что на "железке" вы ограничены функционалом вендора железки, то хочу напомнить, что на тазике вы ограничены функционалом используемого софта. Вы, конечно, возразите, что возьмёте опенсорс решение и в случае чего сами допилите его код, пофиксите баги. Главное, не забыть добавить человекочасы классного программиста (а вы ведь таким являетесь, раз готовы допиливать кваггу и ядро) в стоимость решения "на тазике". Условия бывают разные, может нитро сам владелец и тогда для него это реальная экономия. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 19 марта, 2012 · Жалоба Вы, конечно, возразите, что возьмёте опенсорс решение и в случае чего сами допилите его код, пофиксите баги. Главное, не забыть добавить человекочасы классного программиста (а вы ведь таким являетесь, раз готовы допиливать кваггу и ядро) в стоимость решения "на тазике". Тогда сравните уже, сколько вам придется заплатить вендору, чтобы он впилил в вашу железку нужный вам функционал, с доработкой софта на тазике... и я что-то не помню, чтобы в квагге была хоть одна фича, которой не было бы в cisco ios. А кто говорит только о квагге? Посмотрите на BIRD что ли, для общего развития. IOS что, умеет несколько таблиц маршрутизации различных анонсить, как BIRD? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 19 марта, 2012 · Жалоба А кто говорит только о квагге? Посмотрите на BIRD что ли, для общего развития. IOS что, умеет несколько таблиц маршрутизации различных анонсить, как BIRD? А разве нет? функционал vrf + ospf multi-process/MP-BGP В 99.9% случаев квагги достаточно и куда привычнее конфигурить, чем bird. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 19 марта, 2012 (изменено) · Жалоба А разве нет? функционал vrf + ospf multi-process/MP-BGP На 76xx RSP720/3CXL 12.2.33SRC/D/E, к примеру, это веселая песня. В веселой теории есть, и должно работать. Как только поднимаешь, при достаточно большом числе маршрутов видел всякое - от стойкого падения BGP-пиров, лечится только no neighbor / пересозданием конфига neighbor'а, до полного периодического "замирания" L3-коммутации на ряде интерфейсов глобальной таблицы. Причем 100% VRF - как только выкинул, хрень с коммутацией сразу прекратилась. 15.x не тестировал, негде, стенда из 76xx нет. Надо заводить support ticket в TAC, но всё равно это надолго. Поэтому то, что было в VRF, благополучно было сдвинуто на соседний тазик, и там давно уже и работает. Изменено 19 марта, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alks Опубликовано 19 марта, 2012 · Жалоба А разве нет? функционал vrf + ospf multi-process/MP-BGP На 76xx RSP720/3CXL 12.2.33SRC/D/E, к примеру, это веселая песня. В веселой теории есть, и должно работать. Как только поднимаешь, при достаточно большом числе маршрутов видели всякое - от стойкого падения BGP-пиров, лечится только no neighbor / пересозданием конфига neighbor'а, до полного периодического "замирания" L3-коммутации на ряде интерфейсов глобальной таблицы. Причем 100% VRF - как только выкинули, хрень с коммутацией сразу прекратилась. 15.x еще не тестировали, негде. Надо заводить support ticket в TAC, но всё равно это надолго. Поэтому сейчас то, что было в VRF, благополучно сдвинуто на соседний тазик, и там давно уже и работает. вы что в vrf налили full view? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...