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

Надежность решений для операторов связи. Железо. Софт. Внедрение. Специалисты.

Как бы нам хотелось, чтобы поставил железку из коробки на сеть и она заработала. И, желательно, чтобы сразу она была настроена. Или, хотя бы, настроить по инструкции и она заработала, так, как написано в инструкции.

 

Прочитал обсуждения по выбору решений. В том числе, очень много обсуждается проблема надежности. Очень коробит, когда говорят о надежности и при этом сравнивают бренды с писюками. И говорят, что надо брать бренды, а то писюки ненадежны. И почему-то никто не говорит о том, что есть, так называемые, писюки, которые на самом деле являются промышленными серверами. На которых реализуют различные задачи, и никаких вопросов по надежности и доступности сервиса не возникает. При этом, если уровня надежности, заложенного в сервер, недостаточно, то есть стандартные пути повышения этой самой надежности.

 

Спорщики, как правило, не приводят цифры, зато уверенно оперируют понятием «решение операторского уровня».

 

Это особенно удивляет. Спорят, спорят … но не приводят цифры. Казалось бы чего проще: аппаратная надежность такая, цена такая. Выбирайте. Не устраивает, вот другое решение, там цена такая. Всё остальное зависит от вашего умения.

 

И тут возвращаемся к BRAS-ам.

 

Мне хотелось бы разобраться. Что такое надежность, в данном случае? Из чего она состоит?

 

На мой взгляд, можно выделить четыре основных составляющих надежности. Железо, софт и работа софта (настройка софта), под конкретную конфигурацию сети и связки с сетевым билингом, тех. учетом и т. д. и конечно специалисты которые настраивают, и эксплуатируют данные решения.

 

Давайте рассмотрим всё по порядку.

 

 

 

Железо.

 

Понятно, что должно быть специальное помещение для железа, или, хотя бы, запирающийся шкаф, чтобы кто попало, туда не лазил. Должна быть требуемая железом климатика, электропитание, каналы связи и т.д. К тому же, есть тестирование перед установкой. То есть надо сравнивать решения при одинаковых условиях.

 

Аппаратный BRAS, производят CISCO, Juniper, Huawei и т.д..

 


  •  
  • Железо озвученных производителей общеизвестно. И является тем самым операторским решением, на которые должны ориентироваться все, по уровню надежности. Это эталон.
  • Железо уникальное, из этого проистекает две вещи, оно заточено под задачу, но оно дороже и не так быстро совершенствуется.
  • Но при этом, есть большое «но». Несмотря на операторский класс решения, приходится держать ЗиП, дублировать железку, тратя на это немалые деньги. И что самое главное, эти действия оправдываются. Как показывает практика, эталоны тоже выходят из строя. Может быть, сейчас преимущество в надежности «решения операторского класса» не столь очевидно? Может, это погоня за брендом или просто инерция? Здесь есть над чем подумать.
  • И при этом они же спорят на форумах о том, что решение операторского уровня гораздо надежнее всего остального.
  • И приводят сравнения: «… это мерседесы, а там запорожцы».

SecondHand аппаратный BRAS, производители те же.

 


  •  
  • Где-то, на уровне здравого смысла, есть понимание, что оборудование поработало и часть ресурса своего выработало.
  • Но, делаем то, что описано выше (горячая замена или дублирование на сети). И оп, надежность такая же.
  • А плюсом есть статистика по сильным и слабым сторонам оборудования. И большинство проблем решено, или признано «фичей». Заманчивый вариант.

Программный BRAS, Микротик, BRASFil

 


  •  
  • Как правило, аппаратная часть собрана на базе Intel, и, если брать нормальное промышленное аппаратное решение, то его надежность очень высока. Статистика по серверам доступна всем, загляните в свой аппаратный зал. Опыта по обеспечению требуемой надежности серверов предостаточно.
  • Аппаратная часть очень быстро совершенствуется.
  • Сделать дублирование, собрать отказоустойчивый кластер. И всё. Дальше можно идти и теоретизировать, а что будет в случае одномоментного разрушения, всего оборудования?

Free-шный вариант на Линуксе

 

 


  •  
  • Это то самое, с чем любят сравнивать по надежности оборудование производства CISCO, Juniper, Huawei. Здесь по аппаратной части сложнее всего. Может быть старая персоналка, а может быть нормальный сервер с двумя блоками питания и зеркальным рейд-массивом и т.д. Смотрите выше.
  • Отдельно стоит рассмотреть решения собранные на базе ПК. Они конечно стоят гораздо дешевле, теоретически менее надежны, но тоже имеют право на жизнь, если при принятии этого решения учитывается всё. Хотя насколько - не может сказать никто! В том числе и по причине зоопарка комплектующих. От того как и кто собирал, из чего собирал. От дешевки, до брендов с нормальным ОТК. Опять же, можно две железки в параллель поставить, если сильно надо поднять надежность за дёшево. В конце концов, собрать кластер.
  • С другой стороны многие кто держал дома компьютеры, и в свое время их не продал, могут привести примеры когда персоналка 7 -8 летнего возраста до сих пор исправно работает, поддерживая, например задачу NAS в квартире (для скептиков, забить в поисковик «nas своими руками» и получить реальные примеры). И здесь тоже получается не всё однозначно.

И вывод следующий, касательно железа, каких либо существенных преимуществ нет, нельзя сказать, что там надежность пять девяток, а там четыре девятки. Там где эту надежность надо поднять существует список вполне стандартных мероприятий, для любого подхода. Вплоть до полного дублирования. И там и там рецепты известны. И сказать, что данное решение по железу надежнее (целиком, а не отдельного ПК, сервера, BRAS-а), чем другое нельзя. Особенно если начать сравнивать кластеры.

 

Второй вопрос, по части железа, это расширение/масштабирование в связи с увеличением нагрузки, а, по сути, проблема производительности. Опять–таки, в любом подходе есть свои вопросы которые тем или иным способом решаются. Начиная от простой замены аппаратной части и заканчивая распараллеливанием нагрузки. Везде свои грабли.

 

Конечно, чтобы прекратить все споры, необходимо создать лабораторию, в которой реализовать все решения и покрутить их в одинаковых условиях лет десять. С одинаковым сервисом поддержки…. А лучше не одну, а с десяток.

 

Только тогда можно сказать, что то о надежности железной составляющей.

 

Только мне кажется, не будет там никаких различий. Или ими можно будет пренебречь. Но преимуществами универсальной платформы (ИНТЕЛ), над платформой специализированной, пренебречь нельзя. И об этом нужно помнить.

 

Прошу замечаний, устранение неточностей.

Сейчас сам разбираюсь с данной темой и могу ошибиться.

Очень не хватает статистики. Если есть у кого поделитесь.

 

 

Надежность BRAS SOFT

 

О надежности софта сложно говорить, я бы сказал, что и там, и там он одинаково не надежен. Просто в силу технологии его написания, и многообразия .

 

Аппаратный BRAS, производят CISCO, Juniper, Huawei и т.д.

  • Ситуация достаточно противоречивая, с одной стороны софт заточен под данные задачи, но с другой стороны он выполняет большое количество функций. То есть решения достаточно универсальные, надо любить весь мир. И нет возможности включить что то одно. Это порождает сложное ПО в которое сложно вносить изменения.
  • Достаточно быстрая реакция на запросы клиентов, при условии оплаченной поддержки. Конечно с учетом сложности ПО.
  • Огромный зоопарк прошивок. При решении проблем их просто перебирают.
  • Зато интерфейс единообразный.
  • Очень хорошая документация, много в сети обсуждений. Накоплен большой опыт.
  • IPoE, PPPoE - при определенном упорстве можно реализовать любую моделью, но вендоры упорно лоббируют PPPoE. 95% клиентов работает по этой модели
  • Недостаток наверное один, что то серьезное за серьезные деньги.
  • Развитие достаточно динамичное и это плюс.

 

SecondHand аппаратный BRAS, производители те же.

  • То же самое, что отмечено выше. Плюсом, как правило все грабли пройдены..
  • Минус пост гарантийное обслуживание. Без него серьезные проблемы не решить. Стоит денег.
  • Минус наверное еще и в том что снимают с поддержки.

 

Программный BRAS, Микротик, BRASFil


  •  
  • Софт специализированный, меньше функций.
  • На отдельных серверах для производительности и надежности.
  • IPoE, PPPoE – есть выбор, можно и то и то. И работает.
  • Дешевле поддержка, пропорционально стоимости.
  • Область применения меньше. Соответственно опыта меньше.
  • Миф о меньшей надежности.
  • Достаточно динамично развивается. Устраняются замечания.
  • Поддержка тоже стоит денег. И также профессиональная.

 

Free-шный вариант на Линуксе

 

  • Очень специализированный софт.
  • С точки зрения управляемости самое сложное для бизнеса. Т.к. нет никаких гарантий. И данные решения крупным бизнесом не рассматриваются.
  • Но достаточно много документации, и опыта применения. Но как правило это либо что то на коленке, либо некий стартап. Очень гибкое решение.
  • Огромное сообщество людей. Большинство молодежь.
  • Миф о маленькой надежности. Хотя технология написания софта говорит об обратном. Любой может проверить. И оттестировать.
  • Развивается, но всё зависит от энтузиастов. А они от популярности. И эксплуатация тоже зависит от популярности.
  • Главный тормоз развития, миф о том, что всё должно быть дёшево на этом решении, раз софт бесплатный. Хотя никто не отменял работ по настройке, железо, эксплуатацию.

 

Какие существенные отличия: софт на интеловой\линукс платформе как это ни странно, более специализирован. Софт на Cisco,  Juniper, Huawei обладает большей функциональностью и закрывает больше вопросов. И вроде как потенциально в таком подходе надежность должна быть меньше. Но как я понимаю компенсируется тем штатом разработчиков которые над этим софтом работают.

 

Надежность BRAS внедрение

 

 

Ни для кого не секрет что решение работает стабильно, если его правильно настроить. Предлагаю рассмотреть особенности того или иного подхода на этапе внедрения.

 

Аппаратный BRAS, производят CISCO, Juniper, Huawei и т.д.

o Здесь всё хорошо. Опыт. Поддержка. Специалисты.

o Готовые схемы организации сети на все случаи жизни. Интеграторы готовые на всё. И как следствие дорого.

o Замечательные программы обучения. Всё очень четко расписано. Курс для этого, курс для того. За очень короткий срок можно подготовить специалистов высокого уровня. Правда специалисты дорогие.

o Только PPPoE. Конечно декларируется поддержка IPoE, но навязывается IPoE. Хотя в некоторых случаях выгоднее IPoE. Не понятно с чем связано, может с тем, что решение будет дороже?

o Готовые схемы поддержки, вплоть до складов с горячей подменой.

o Ответственность специалистов достаточно легко перекладывается на поддержку.

o Интеграция с другими частями инфраструктуры наилучшая.

o Вопрос здесь возникает очень простой – окупаемость. Предприятие коммерческое. И срок окупаемости железного и софтового BRAS-ов получается различным. А клиенты приносят один и тот же доход.

o А вот когда бизнес сделает поворот в направлении, более бюджетных решений, большой вопрос. И это не будут большие компании.

 

SecondHand аппаратный BRAS, производители те же.

o Наверное всё тоже самое, кроме того, что можно найти людей которые на этих железках строили сеть или имеют опыт её эксплуатации.

 

Программный BRAS, Микротик, BRASFil

o Есть опыт. Есть готовые схемы внедрения. Решения достаточно распространены.

o Поддержка полноразмерная, и много уровневая. Вплоть до разработчиков. Которые сейчас готовы завоёвывать рынок и прислушиваться к клиентам.

o Специалисты не так распространены как у железных BRAS-ов.

o Есть программы обучения. И обучить персонал для эксплуатации возможно в очень короткий срок.

o Интеграторы данные решения не так любят. Т.к. стоимость меньше, и накрутка на само решение пропорционально меньше. Плюс работы тоже сравнивают со стоимостью решений. И здесь также приходится ужиматься. Хотя объём знаний тот же.

o Вполне возможно, что данное решение в ближайшем будущем станет главным направлением развития. Ну и как следствие производители «железных BRAS-ов» могут перейти на х86 платформу, и опустить цены. Хотя с данным утверждением можно и поспорить.

 

Free-шный вариант на х86 *nix MPD, accel-ppp, LISG

o Я не знаю больших внедрений. На мой взгляд основная проблема в том что не с кем подписать бумагу о качестве софта и устранении багов. Большие это больше 10 тыс. абонентов.

o Вопрос с поддержкой, тоже стоит остро. Разработчики не подписывают контракты на поддержку. Они просто разрабатывают и предоставляют продукт как есть.

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

o Интеграторы также ничего не могут заработать, на продаже этого решения, и соответственно его не продают.

o Ответственность техническим специалистам в большой компании не с кем делить. В этих продуктах надо разбираться досконально, общаться с разработчиками. Проблему сдавать некуда. Можно только написать на форуме. А кому это надо? Проще заплатить побольше и получать стабильно ЗП. При нештатных ситуациях сдавая проблему в поддержку разработчика. Потом кивая на него своему работодателю.

o Очень мало специалистов которые действительно разобрались. И качество внедрения зависит от конкретного человека, который это делает. Нет готовых и формализованных рецептов. Их можно легко набрать на форумах. Но никто не гарантирует, что в этом случае они сработают. Граничные условия досконально не описаны.

o Не принято хотя никто и не мешает, протестировать решение перед внедрением. И очень часто проблемы вылавливаются уже на работающей сети. Что также не добавляет доверия.

o Если к внедрению, поддержке и эксплуатации данного решения подходили так же как и к платным решениям, то FREE-шные BRAS-ы нисколько бы не уступали своим конкурентам.

 

Исходя из выше сказанного напрашивается простой вывод: у решений CISCO, Juniper, Huawei больше и продавцов, и внедренцев, а также их выгодней продавать. И если в свое время они были действительно лучше, то сейчас ответ не так однозначен с технической точки зрения.

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

Также есть у Free-шных решений недостаток отнюдь не технического плана. Он больше организационный. Если сообщество преодолеет данный недостаток, и будут написаны организационные регламенты внедрения, поддержки и эксплуатации решений, то к таким решениям начнёт присматриваться и серьезный бизнес.

В итоге получается, что самым сбалансированным решением на сегодня является коммерческие SOFT BRAS-ы. Здесь есть вполне понятный интерес с двух сторон, со стороны разработчика и оператора, основанный на взаимной выгоде. И запросы разработчика не настолько велики, как у CISCO, Juniper, Huawei.....

 

Прошу замечаний, устранение неточностей.

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

И ещё просьба приводить аргументы, что бы не было голословных утверждений.

 

BRAS Специалисты

Те кто внедряет, поддерживает и эксплуатирует данное решение. В общем на них всё держится.

Аппаратный BRAS, производят CISCO, Juniper, Huawei и т.д.

o Огромное количество специалистов.

o Проучившись на курсах, гарантированно получаешь работу. И соответственно курсы очень востребованы.

o Несколько уровней специалистов, вплоть до разработчиков. По сути на любую задачу можно найти исполнителя.

o Стоимость очень высокая данных специалистов.

SecondHand аппаратный BRAS, производители те же.

o То же самое.

o Плюс можно найти человека который именно с этой железкой поработал достаточно долгое время.

Программный BRAS, Микротик, BRASFil

o Несколько уровней специалистов, вплоть до разработчиков.

o Есть обучение. Можно достаточно быстро обучить.

o Есть некоторое количеств специалистов которые работают.

o Стоимость ниже, лояльность выше. Уходить с предприятия сложнее, т.к. решение не достаточно распространено.

o Для бизнеса это наиболее оптимальный вариант, с точки зрения качества и цены.

Free-шный вариант: MPD, accel, LISG

o Здесь специалист царь и бог, и от него зависит всё. Т.е. хороший специалист, всё работает как часы, а не очень хороший и начинаются проблемы. И никак заранее не узнаешь, только на практике или по рекомендации.

o Стоимость специалиста также зависит от того насколько он осознает сложившееся положение вещей. Но к слову сказать, что ЗП специалистов специализирующихся на Free-шном варианте гораздо меньше чем у специалистов решений железных. Наверное срабатывает стереотип о бюджетности решения.

o Специалисты разбираются в данном случае сами. И всё очень сильно зависит от личных качеств самого человека. От умения системно изучать вопрос. Соответственно качество проверить очень сложно.

o Стабильность решения, зависит от человека, который её эксплуатирует. Очень часто приход нового человека на данное место приводит к резкому изменению надежности системы. И не в всегда в лучшую сторону.

o Есть еще один нюанс. Очень важный нюанс. Действительно сильные технари начинают расти, как правило в сторону железных решений и уходят с данного направления. Т.к. нужна стабильность, высокая ЗП. Всё связано с тем, что появляются семья, дети, нужны машина, квартира, дача, отдых на море.

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

o А кто остается? А остаются либо энтузиасты, либо люди которые смогли построить некий бизнес на данных решениях, с высокой степенью автоматизации. Пользуясь тем, что отдельное решение стоит очень дёшево, но и требования по качеству и поддержке не столь высоки.

 

 

Выводы:

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

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

 

 

 

Начало статьи:

Рассуждения

Список статей

Список статей

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

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


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

А что статистика?

У нас когда то был бордер на PC.

Молотил до 600 мбит трафика -дальше начинались танцы с бубном.

Ну и падал пару раз в год, один раз посыпался хард.

Потом купили Juniper. Сначала один, потом второй. Проблем с ними за последние года 4 не было вообще никаких.

 

Еще были НАТ-ы на PC. C ними была куча проблем - перешли на железки - проблем не знаем.

А на примере BRAS - не любая железка имеет возможность сделать вещи возможные на PC с Linux/Freebsd.

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


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

В контексте темы просвятите, как сделать отказоустойчивый (вплане отказов железа, софт пока в расчет не берем) бордер из двух серверов с linux?

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


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

vrrp

 

читал про такое, но как это вяжется с bgp?

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


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

У нас когда то был бордер на PC.

Молотил до 600 мбит трафика -дальше начинались танцы с бубном.

Ну и падал пару раз в год, один раз посыпался хард.

Бордер, феном 2-головый, под 800 мбит почти симметричного траффика молотит прекрасно при загрузке % 25, падает только по причине пропадания питания (не, один раз было что-то непонятное - поиксилось чисткой контактов памяти и заменой БП на новый более другой). Винт не сыпется по причине его отсутствия, а если бы стоял полновесный дистр - был бы на нем рэйд.

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

 

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

keepalived или pacemaker или еще что, хоть надор скриптов. Сервера пингуют друг друга, один мастер, другой слэйв. Если сэлэйв перестает видеть мастера - поднимает у себя ип мастера и запускает бгп. Мастер, при старте, проверяет доступность ип мастера, если он поднят - то становится слэйвом. Можно еще для кворума один тазик поставить (если мастер упал и кворумный тазик доступен - становиться мастером, иначе - жить слэйвом).

А можно (и нужно) взять 2 канала, поставить 2 бордюра, и резервировать через бгп.

 

Да, у нас почему-то каналы аплинков падают куда чаще, чем тазики вешаются...

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


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

Да, у нас почему-то каналы аплинков падают куда чаще, чем тазики вешаются...

Вот это верно подмечено ... :)

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

А деньги на "аппаратное" решение потратить всегда можно успеть. Тут ума много не надо.

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


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

Бордер 12:05:01 up 833 days, 1:50, 2 users, load average: 0.11, 0.08, 0.02

молотит 1.5 гига трафика :)

аптайм был бы и больше, раза в 2 как минимум, но 833 дня назад нужно было в него карточку вставить интел 4 портовую :( ибо трафик за 1г начал зашкаливать :)

 

недавно сняли с агрегации района catalyst 3750, стоял с 2006 года, стал спонтанно перезагружатся, отловить ничем не могли, видимо железо... Поставили кстате SNR 3750, пока работает без проблем.

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


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

Бордер, феном 2-головый, под 800 мбит почти симметричного траффика молотит прекрасно при загрузке % 25, падает только по причине пропадания питания (не, один раз было что-то непонятное - поиксилось чисткой контактов памяти и заменой БП на новый более другой). Винт не сыпется по причине его отсутствия, а если бы стоял полновесный дистр - был бы на нем рэйд.

 

Я уже не помню точно что тогда было. Но точно еще до феномов.

А вообще тема чуть более чем бессмысленна.

Да работать будет и без железок. Да и на самосборе, и даже на домашних ПК.

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

А можно поставить железку. Оно дороже, но производительнее и в среднем менее проблемная.

 

Да и вообще - с меди на оптику зачем переходили? Медь тоже будет работать. Если ее правильно эксплуатировать - все реально.

И даже дешевле получается :)

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


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

Да и вообще - с меди на оптику зачем переходили? Медь тоже будет работать. Если ее правильно эксплуатировать - все реально.

И даже дешевле получается :)

При нынешних ценах на медь еще чуть-чуть и оптика будет дешевле даже в квартиру. :)

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

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


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

Да и вообще - с меди на оптику зачем переходили? Медь тоже будет работать. Если ее правильно эксплуатировать - все реально.

И даже дешевле получается :)

По меди, дешевле не получается :) Никак. При одинаковом сервисе.

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

А не получится, что с точки зрения железа "железные BRASы" являются теми самыми "медными линиями"? ;)

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


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

Я уже не помню точно что тогда было. Но точно еще до феномов.

Да какая разница что было. У нас на одном из районных роутеров (тога еще существовавших) аптайм был более года. Атлон какой-то на нфорс2 плате. Когда демонтировали - обнаружили подпухающие конденсаторы даже. Еще была кучка гогна уровня пеньков 2-3 в свое время. И это все успешно и в основной массе безотказно работало.

 

А можно поставить железку. Оно дороже, но производительнее и в среднем менее проблемная.

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

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


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

Если фича неподдерживаемая - да.

Но надо и головой думать.

Мы вот брасы оставляем пока на серверах.

 

А с проблемами - тут спорно. Под нас даже джунипер исправлял проблемы в джуносе, было дело.

А вообще главное прямые руки у администратора.

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


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

Под нас даже джунипер исправлял проблемы в джуносе, было дело.

 

Почему даже? Если саппорт есть, запрос открыт, баг изолирован, то все вообщем-то исправляют

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


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

А с проблемами - тут спорно. Под нас даже джунипер исправлял проблемы в джуносе, было дело.

Исправляют. Но сколько займет исправление - неделю, месяц или полгода - неведомо. И никак на это не повлиять...

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


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

Исправляют. Но сколько займет исправление - неделю, месяц или полгода - неведомо. И никак на это не повлиять...

 

Зависит от критичности проблемы, от того насколько вероятно она вылезет у других заказчиков, от того насколько крупный вы заказчик и можно ли положить на вас болт. Да и вообще, workaround-ы в 90% случаев существуют(пока вендор допиливает ПО)

 

К примеру, если коммутатор доступа зависает из-за того, что у вас в management влане 2000 хостов и все друг друга видят и он умирает от большого кол-ва arp трафика, то такую проблему могут фиксить долго, а могут и вообще не зафиксить, потому что это вызвано кривым дизайном. А если же обнаружите, что можно сформировать хитрый bgp update, приводящий к перезагрузке bgp-спикера, да если это ещё и транзитом передаётся, то такое могут зафиксить меньше чем за бизнес-день.

 

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

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


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

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

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

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


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

В этом топике не хватает Irsi. Иначе он уже провален, так как пруфов про то, что аппаратные решения производительный/надёжней не предоставлено.

 

ЗЫ: в первом посте упоминался Микротик. И это очень странно, особенно если учесть, что это всего лишь блекджек для тех, кто не осилил настоящий дистрибутив.

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


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

ну я за железки в разумных пределах.

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


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

А где они, эти пределы, заканчиваются то? Огласите, пжлста...

 

Лично моё мнение гласит, что железки должны заканчиваться на L2. Просто из-за того, что грустных рассказов про то, как что-то где-то внезапно нагнулось из-за того, что вендор что-то не реализовал, слишком уж много...

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


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

Лично моё мнение гласит, что железки должны заканчиваться на L2.

+100 активно плюсую.

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


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

пруфов про то, что аппаратные решения производительный/надёжней не предоставлено.

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

 

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

а по вопросу багов, то где их не бывает. мплс или мультикаст роутинг, типичные л3 фичи про которые я часто слышу сообщения о проблемах, только беда, первый, в линукс/бсд, вообще не реализован, а второй отстал на 20 лет от вендорских решений.

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


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

Просто из-за того, что грустных рассказов про то, как что-то где-то внезапно нагнулось из-за того, что вендор что-то не реализовал, слишком уж много...

 

Т.е. сами составили спеку, купили, начали настраивать и поняли, что не хватает такой-то фичи("вендор что-то не реализовал")? Ну сами виноваты, раз возлагаете на себя функцию интегратора/инженера вендора по подбору оборудования под ТЗ и не можете справиться с этой задачей.

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


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

Лично моё мнение гласит, что железки должны заканчиваться на L2.

+100 активно плюсую.

 

А вон в соседней теме обсуждают как выгрести fdb таблицу из linux-бриджа, видимо кто-то считает что и свитчи должны быть собраны на базе обычных PC/серверов...

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


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

Вот у нас например НАТ-ы на железках.

Довольны куда более нежели на тазиках. Проблем никаких.

Мое мнение - на тазики вешать только БРАС-ы, ну и всякие там DHCP,радиусы и прочие вещи.

Под остальное есть смысл брать железки.

Шейпер, NAT, бордер и все L3 свичи - на железках работают нормально и стабильно.

И если бы не странности - то и брасы тоже были бы железками.

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


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

Join the conversation

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

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

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

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

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

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

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