Jump to content
Калькуляторы

Hardware vs Software (Бордеры)

А вот скажите какое бытует мнение, в пользу аппаратных решений в качестве бордера?

 

Какие плюсы? Латентность разная и примерно насколько? Хочется услышать практический опыт.

 

(Сорри, если это обсуждалось)

Edited by zlolotus

Share this post


Link to post
Share on other sites

Есть где-то 5 критериев:

1. Пропускная способность. 1-2-4-8 Mpps Вы на софте еще пропустите (8, возможно, уже не одной железкой), но на большее придется смотреть в сторону аппаратного решения.

2. Энергопотребление: у софтроутеров оно, как правило, выше.

3. Гибкость / удобство конфигурации. Гибкость как правило выше у софтового решения, удобство - как правило, у проприетарного аппаратного.

4. Надежность / резервируемость. У аппаратных решений надежность обычно в целом выше, чем у серверов общего назначения. Резервируемость - на софте можно построить в принципе любую, но надо время. У серьезных аппаратных решений резервируемость уже заложена.

5. Стоимость. Аппаратное решение обойдется вам минимум в 2-3 раза дороже сервера в единовременном плане. Серьезное аппаратное решение с резервированием, саппортом и прочим - в десятки раз. В эксплуатации - тут уже надо считать, сколько потратите там и там на поддержку, каковы риски, и т.п. - т.е. единой версии нет.

Edited by Alex/AT

Share this post


Link to post
Share on other sites

3. Гибкость / удобство конфигурации. Гибкость как правило выше у софтового решения, удобство - как правило, у проприетарного аппаратного.

Удобство - сомнительно. В чем умеешь работать, в том и работаешь. Работать в сети с разнобрендовыми железки удовольствие не из приятных.

 

4. Надежность / резервируемость. У аппаратных решений надежность обычно в целом выше, чем у серверов общего назначения. Резервируемость - на софте можно построить в принципе любую, но надо время. У серьезных аппаратных решений резервируемость уже заложена.

В серьезных аппаратных решениях за резерв надо платить часто больше.

 

 

6) Скорость замены по гарантии разная.

7) Длительность фикса багов в аппаратных решениях.

8) За новые прошивки к аппаратным железкам надо платить отдельно.

Share this post


Link to post
Share on other sites

А вот скажите какое бытует мнение, в пользу аппаратных решений в качестве бордера?

 

Какие плюсы? Латентность разная и примерно насколько? Хочется услышать практический опыт.

До пары гигабит аппаратное решение преимуществ imho не имеет.

После 3-4 гигабит программное решение превращается просто в придаток к 10г-картам.

Обработку такого трафика надо делать не одной коробкой, а комплексом из нескольких,

который включает в себя и быстрые специализированные аппаратные молотилки, и универсальные недорогие PC.

Share this post


Link to post
Share on other sites

Кстати, интересно найти такой вариант: маломощный PC софтроутер с несколькими FullView и какой-то "аппаратный комплекс", который пропускает через себя несколько 10Г каналов трафика (что-то вроде L3 свича). Соответственно, софтроутер управляет маршрутизацией "аппарата".

 

Кто-нибудь подскажет решение?

Share this post


Link to post
Share on other sites

Кстати, интересно найти такой вариант: маломощный PC софтроутер с несколькими FullView и какой-то "аппаратный комплекс", который пропускает через себя несколько 10Г каналов трафика (что-то вроде L3 свича). Соответственно, софтроутер управляет маршрутизацией "аппарата".

 

Кто-нибудь подскажет решение?

 

Решение называется route-server и используется в основном на пиринговых площадках.

Share this post


Link to post
Share on other sites

Решение называется route-server и используется в основном на пиринговых площадках.

В последнее время очень полюбилось ТТК.

Share this post


Link to post
Share on other sites

Кстати, интересно найти такой вариант: маломощный PC софтроутер с несколькими FullView и какой-то "аппаратный комплекс", который пропускает через себя несколько 10Г каналов трафика (что-то вроде L3 свича). Соответственно, софтроутер управляет маршрутизацией "аппарата".

 

Кто-нибудь подскажет решение?

 

А как оно работает? На пирах нужно настраивать bgp multihop ?

 

Решение называется route-server и используется в основном на пиринговых площадках.

Share this post


Link to post
Share on other sites

Кстати, интересно найти такой вариант: маломощный PC софтроутер с несколькими FullView и какой-то "аппаратный комплекс", который пропускает через себя несколько 10Г каналов трафика (что-то вроде L3 свича). Соответственно, софтроутер управляет маршрутизацией "аппарата".

 

Кто-нибудь подскажет решение?

 

А как оно работает? На пирах нужно настраивать bgp multihop ?

 

 

Именно.

Share this post


Link to post
Share on other sites

ИМХО, при низких скоростях у железки будет одно преимущество - от флуда не скукожится. Минусы железок уже описали (имеете то, что дает вендор, и никаких доп. фич не прикрутить внутрь). А при скоростях в несколько гигабит на девайс (тазик/железку) - таки тазики становятся слишком уж монструозными и требуют тщательного тюнинга... 10G и выше - уже, пожалуй, на тазиках отроутить не получится адекватно, а если и получится - железка может оказаться дешевле.

Share this post


Link to post
Share on other sites

Минусы железок уже описали (имеете то, что дает вендор, и никаких доп. фич не прикрутить внутрь)

вы на самом деле думаете, что тазик с линуксом более фичаст, чем решение известного производителя? или фичастость заключается в "поднять брас/бордер/днс/веб сервер в одной коробке"?

аппаратные решения, как правило, более узкоспециализированны (bras не умеет dpi, fw - не умеет bgp), но это скорее последствия высокой производительности, решения enterprise класса с ограниченной производительностью умеют всё и одновременно. Впрочем, есть и операторские решения, обладающие универсальностью, но зачем? архитектура сети операторского класса не потворствует аггрегации всего функционала в одну железку.

Share this post


Link to post
Share on other sites
ИМХО, при низких скоростях у железки будет одно преимущество - от флуда не скукожится. Минусы железок уже описали (имеете то, что дает вендор, и никаких доп. фич не прикрутить внутрь). А при скоростях в несколько гигабит на девайс (тазик/железку) - таки тазики становятся слишком уж монструозными и требуют тщательного тюнинга... 10G и выше - уже, пожалуй, на тазиках отроутить не получится адекватно, а если и получится - железка может оказаться дешевле.

Железо подтягивается.

PCI-E v3, тундерболт (лайтпик) - как пример что оно возможно.

Через года два всё это будет в ближайшем ларьке. Пока иви бридж официально ещё не вышел и никто не шевелится.

Share this post


Link to post
Share on other sites
ИМХО, при низких скоростях у железки будет одно преимущество - от флуда не скукожится. Минусы железок уже описали (имеете то, что дает вендор, и никаких доп. фич не прикрутить внутрь). А при скоростях в несколько гигабит на девайс (тазик/железку) - таки тазики становятся слишком уж монструозными и требуют тщательного тюнинга... 10G и выше - уже, пожалуй, на тазиках отроутить не получится адекватно, а если и получится - железка может оказаться дешевле.

Железо подтягивается.

PCI-E v3, тундерболт (лайтпик) - как пример что оно возможно.

Через года два всё это будет в ближайшем ларьке. Пока иви бридж официально ещё не вышел и никто не шевелится.

Как правило через два года будут другие требования, да и работать нужно сейчас, а не через два года.

Share this post


Link to post
Share on other sites

вы на самом деле думаете, что тазик с линуксом более фичаст, чем решение известного производителя? или фичастость заключается в "поднять брас/бордер/днс/веб сервер в одной коробке"?

аппаратные решения, как правило, более узкоспециализированны (bras не умеет dpi, fw - не умеет bgp), но это скорее последствия высокой производительности, решения enterprise класса с ограниченной производительностью умеют всё и одновременно. Впрочем, есть и операторские решения, обладающие универсальностью, но зачем? архитектура сети операторского класса не потворствует аггрегации всего функционала в одну железку.

Очень большая стоимость у "аппаратных". Иногда надо банально 5 линков на 10G, десяток линков по 1Г, 3 фулвью (сейчас почти 400к маршрутов в одном, с перспективой в 1кк в ближайшие годы), миррор трафика в порт 10G, и чтобы стоило не дороже 10кбаксов. И нету!

Share this post


Link to post
Share on other sites

Иногда надо банально 5 линков на 10G, десяток линков по 1Г, 3 фулвью (сейчас почти 400к маршрутов в одном, с перспективой в 1кк в ближайшие годы), миррор трафика в порт 10G, и чтобы стоило не дороже 10кбаксов. И нету!

Хочу новый мерседес. есть 1000 баксов. И нету, представляете! предлагают только убитую девятку!!!

 

ISP - это вам не шаурмой торговать на рынке, это бизнес с большими капиталовложениями. Вспомните про "сжечь 100 долларов".

Share this post


Link to post
Share on other sites

Иногда надо банально 5 линков на 10G, десяток линков по 1Г, 3 фулвью (сейчас почти 400к маршрутов в одном, с перспективой в 1кк в ближайшие годы), миррор трафика в порт 10G, и чтобы стоило не дороже 10кбаксов. И нету!

Хочу новый мерседес. есть 1000 баксов. И нету, представляете! предлагают только убитую девятку!!!

 

ISP - это вам не шаурмой торговать на рынке, это бизнес с большими капиталовложениями. Вспомните про "сжечь 100 долларов".

 

С капиталовложениями понятно, но хочется именно их избежать.

 

Фактически то, что называют "аппаратным решением" - это софтовый роутер (control plane, если я не ошибаюсь в терминологии) + быстрый свич (Forwarding plane) в одной коробке/шасси.

 

А ищется решение, когда, например, таблицей свича управляет роутер на pc.

 

И можно было бы достичь желаемого "костылями", но тут попадаем на ограничение числа маршрутов в таблице свича. Ходят слухи, что как-то подобную проблему решали с MPLS, но осмыслить это пока не удалось.

Share this post


Link to post
Share on other sites

Вспомните про "сжечь 100 долларов".

 

Что за идиома?

Share this post


Link to post
Share on other sites

Фактически то, что называют "аппаратным решением" - это софтовый роутер (control plane, если я не ошибаюсь в терминологии) + быстрый свич (Forwarding plane) в одной коробке/шасси.

 

А ищется решение, когда, например, таблицей свича управляет роутер на pc.

 

И можно было бы достичь желаемого "костылями", но тут попадаем на ограничение числа маршрутов в таблице свича.

от оно! вы сами понимаете, где собака порылась! что свичик то должен быть не простой! вот какая штука, вендоров на рынке - вагон и маленькая тележка. Кроме сиски и жунипера, есть хуавей, есть алкатель-люсент, снизу подпирают так многими любимые писи-"сделай сам". А цена вот такая. И даже братья-китайцы ценник не роняют.

 

Что за идиома?

несколько лет назад весьма популярна была на этом форуме. Хотите заниматься ISP -возьмите 100$ и сожгите их. Рука не дрогнула? Сожгите ещё 100. И ещё. Когда сожгёте миллион, вы достигли нужной зрелости и можете вкладывать в ISP.

Share this post


Link to post
Share on other sites

вы на самом деле думаете, что тазик с линуксом более фичаст, чем решение известного производителя?

Да.

 

или фичастость заключается в "поднять брас/бордер/днс/веб сервер в одной коробке"?

Фичастость заключается в реализации любого функционала, который только пожелаете. Захотелось к примеру получать по бгп несколько вью, при этом анонсить первый вью только бгп-клиентам из влана 5, второй - только бгп-клиентам из влана 10, а третий вообще никуда не анонсить, а пользовать локально - на тазике это элементарно реализовать. На железке, если не заложено - никак.

Захотелось еще форвардить пакеты из влана 5 в один аплинк, а из влана 10 - в другой, которые равноценны, и при падении одного из аплинков пускать всех в другой - опять же элементарно на тазике, на железке - скорее всего никак.

Хот ответ на это я уже знаю - "это никому не нужно, ибо в железе моего любимого вендора не реализовано, а следовательно - подстраивайтесь под железо, ибо вендор бог и лучше вас знает что вам надо".

 

решения enterprise класса с ограниченной производительностью умеют всё и одновременно

Во-первых - не все, а только то, что заложил производитель при разработке софта. Во-вторых - они по сути представляют собой меганавороченный тазик с кастомным софтом, обернутый в красивую коробку с модным лого, и имеют все проблемы, присущие софтроутерам.

 

несколько лет назад весьма популярна была на этом форуме. Хотите заниматься ISP -возьмите 100$ и сожгите их. Рука не дрогнула? Сожгите ещё 100. И ещё. Когда сожгёте миллион, вы достигли нужной зрелости и можете вкладывать в ISP.

Мы к примеру стартонули с пары десятков килобаксов. Развиваемся только из прибыли от клиентов, в условиях достаточно жесткой конкуренции (на некоторых домах присутствует 5-6 провайдеров), причем конкуренция была всегда. И развиваемся достаточно успешно.

Share this post


Link to post
Share on other sites

Фичастость заключается в реализации любого функционала, который только пожелаете. Захотелось к примеру получать по бгп несколько вью, при этом анонсить первый вью только бгп-клиентам из влана 5, второй - только бгп-клиентам из влана 10, а третий вообще никуда не анонсить, а пользовать локально - на тазике это элементарно реализовать. На железке, если не заложено - никак.

Захотелось еще форвардить пакеты из влана 5 в один аплинк, а из влана 10 - в другой, которые равноценны, и при падении одного из аплинков пускать всех в другой - опять же элементарно на тазике, на железке - скорее всего никак.

если вы считаете, что на "железке" вы ограничены функционалом вендора железки, то хочу напомнить, что на тазике вы ограничены функционалом используемого софта. Вы, конечно, возразите, что возьмёте опенсорс решение и в случае чего сами допилите его код, пофиксите баги. Главное, не забыть добавить человекочасы классного программиста (а вы ведь таким являетесь, раз готовы допиливать кваггу и ядро) в стоимость решения "на тазике".

 

и я что-то не помню, чтобы в квагге была хоть одна фича, которой не было бы в cisco ios. Описанные вами хотелки у сиско и жунипера настраиваются с пол-пинка

Share this post


Link to post
Share on other sites
если вы считаете, что на "железке" вы ограничены функционалом вендора железки, то хочу напомнить, что на тазике вы ограничены функционалом используемого софта. Вы, конечно, возразите, что возьмёте опенсорс решение и в случае чего сами допилите его код, пофиксите баги. Главное, не забыть добавить человекочасы классного программиста (а вы ведь таким являетесь, раз готовы допиливать кваггу и ядро) в стоимость решения "на тазике".

Условия бывают разные, может нитро сам владелец и тогда для него это реальная экономия.

Share this post


Link to post
Share on other sites

Вы, конечно, возразите, что возьмёте опенсорс решение и в случае чего сами допилите его код, пофиксите баги. Главное, не забыть добавить человекочасы классного программиста (а вы ведь таким являетесь, раз готовы допиливать кваггу и ядро) в стоимость решения "на тазике".

Тогда сравните уже, сколько вам придется заплатить вендору, чтобы он впилил в вашу железку нужный вам функционал, с доработкой софта на тазике...

 

и я что-то не помню, чтобы в квагге была хоть одна фича, которой не было бы в cisco ios.

А кто говорит только о квагге? Посмотрите на BIRD что ли, для общего развития. IOS что, умеет несколько таблиц маршрутизации различных анонсить, как BIRD?

Share this post


Link to post
Share on other sites

А кто говорит только о квагге? Посмотрите на BIRD что ли, для общего развития. IOS что, умеет несколько таблиц маршрутизации различных анонсить, как BIRD?

 

А разве нет? функционал vrf + ospf multi-process/MP-BGP

 

В 99.9% случаев квагги достаточно и куда привычнее конфигурить, чем bird.

Share this post


Link to post
Share on other sites
А разве нет? функционал 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, благополучно было сдвинуто на соседний тазик, и там давно уже и работает.

Edited by Alex/AT

Share this post


Link to post
Share on other sites
А разве нет? функционал 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?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this