Перейти к содержимому
Калькуляторы

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

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

 

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

 

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

Изменено пользователем zlolotus

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

Изменено пользователем Alex/AT

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

 

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

 

Именно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

 

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Да.

 

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

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

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

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

 

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем Alex/AT

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А разве нет? функционал 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?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.