[s.lobanov]

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

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

 

Ну это как раз странно. NAT это та самая задача, которая довольно неплохо решается на x86 софтроутерах. Видимо вы что-то недоосилили, может у вас хеш-таблица было маленькая или ещё что...

 

Мое мнение - на тазики вешать только БРАС-ы

Просто нет небольших BRAS-ов для небольших операторов(микротик в расчёт не берём). Ну есть SE100, но сейчас 6GE портов сделать на сервере это вообще не проблема(и получится намного дешевле, если есть нормальный специалист по линуксу), да и вообщем-то 2x10G карты для x86-серверов доступные.

А так hw решения BRAS отлично работают, только большие кап. вложения получаются на малых объёмах.

[Aliech]

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

Вендор мог спокойно не реализовать то, что обещал в спеке. Или реализовать криво. Если это было бы не так, то тех. поддержка вендора сидела бы без работы.

 

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

В любом деле важно подходить к вопросу без фанатизма.

 

Просто нет небольших BRAS-ов для небольших операторов(микротик в расчёт не берём). Ну есть SE100, но сейчас 6GE портов сделать на сервере это вообще не проблема(и получится намного дешевле, если есть нормальный специалист по линуксу), да и вообщем-то 2x10G карты для x86-серверов доступные.

А так hw решения BRAS отлично работают, только большие кап. вложения получаются на малых объёмах.

Я к тому же.

 

Граждане дорогие, я так и не нашёл упоминаний, чем конкретно надёжней аппаратные решения. А про производительность... Так не хотелось упоминать, но "да за эти деньги можно пачку серверов купить!!!!11111"

[s.lobanov]

Вендор мог спокойно не реализовать то, что обещал в спеке. Или реализовать криво. Если это было бы не так, то тех. поддержка вендора сидела бы без работы.

 

По поводу багов уже обсудили. А по поводу фич, то есть такая вещь как "взять оборудование на тест". Если вы не микрооператор с какими-нибудь 500 абонентами онлайн, то вам дадут желеку на тест(возможно, удалённо с подключенным к ней PC). А если вы очень маленький, то продолжайте пользоваться серверами и не парьтесь, никто особо и заморачиваться с вами не будет, чтобы что-то продать вам(вопросов от вам будет море, а выхлоп(прибыль) мизерная)

[NiTr0]

Т.е. сами составили спеку, купили, начали настраивать и поняли, что не хватает такой-то фичи("вендор что-то не реализовал")?

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

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

 

Кстати, яркий пример надежности железок - эпопея с апгрейдом UA-IX: свежеустановленные Extreme таращило несколько месяцев, окончилось вроде как заменой железок вендором, ибо софтово побороть краши/дропы не получилось. Ну и попутно - значительной потерей трафика, который перетек в другие точки обмена и в разрастающиеся на этой почве пиринги между операторами.

[s.lobanov]

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

На это я уже ответил, берите оборудование на тест.

 

 

И ладно если это вылезет сразу после покупки - вернуть-то не проблема. Гораздо хуже, если это начнет вылазить в процессе эксплуатации (добавление нового функционала, мультикастового влана для иптв к примеру, вызовет проблемы с MSTP,

Перед запуском новых услуг надо обкатывать их на стенде. Оборудование для стенда брать из ЗИПа(если не руководствоваться принципом, что ЗИП это для лохов)

 

или просто при увеличении кол-ва маков/роста трафика на железке ее начнет сказочно таращить как л3 длинки

Основная проблема - L3-длинка(и других подобных "L3") это большая arp таблица и неустойчивость к некоторым видам arp атак. Терминирование абонентов на L3 коммутаторах это ошибка дизайна(ваша ошибка), а не проблема длинка.

 

Кстати, яркий пример надежности железок - эпопея с апгрейдом UA-IX: свежеустановленные Extreme таращило несколько месяцев, окончилось вроде как заменой железок вендором, ибо софтово побороть краши/дропы не получилось. Ну и попутно - значительной потерей трафика, который перетек в другие точки обмена и в разрастающиеся на этой почве пиринги между операторами.

 

Очень хотелось бы услышать тех. подобностей по существу.

Кто и как составлял спеку(участвовали ли в этом известные интеграторы или представители вендора)?

IX же это вообще тупая коммутация по сути(со статической мак-таблицей). Как они там крешей добились, не очень понятно. Или они там RS подняли на железке, а не на сервере?

[zi_rus]

и наткнулись на багу ... И не факт что вендор исправит - особенно если никто, кроме вас не пытался в таком конфиге запускать (и навряд попытается), а исправление займет много человекочасов.

интересно что вы собираетесь делать, если в этом вашем линуксе вылезет такой же баг

если сами, то это бабки много большие чем заплатите вендору за сервис контракт

упросите комьюнити - вот уж нелепость, никаких гарантий ни по срокам ни по результату

купите поддержку у разаработчика типа Red Hat - так чем же это лучше производителя аппартных решений

[s.lobanov]

и наткнулись на багу ... И не факт что вендор исправит - особенно если никто, кроме вас не пытался в таком конфиге запускать (и навряд попытается), а исправление займет много человекочасов.

интересно что вы собираетесь делать, если в этом вашем линуксе вылезет такой же баг

если сами, то это бабки много большие чем заплатите вендору за сервис контракт

упросите комьюнити - вот уж нелепость, никаких гарантий ни по срокам ни по результату

купите поддержку у разаработчика типа Red Hat - так чем же это лучше производителя аппартных решений

 

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

[zi_rus]

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

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

 

А про производительность... Так не хотелось упоминать, но "да за эти деньги можно пачку серверов купить!!!!11111"

можно, только если взять типичную Cisco ASR 9010 и посчитать сколько нужно серверов чтобы обеспечить хотябы приблизительную производительность (440Gbps на слот между прочим), 40*10G портов в одном слоту может быть, сколько серверов понадобится чтобы просто получить такое количество портов, сколько еще сил и оборудования уйдет на просто организацию их взаимодействия, сколько это все места займет (решение вендора имеет высоту 22U), а еще энергопотребление и охлаждение (аппаратное решение вендора при полной набивке всех слотов способно работать от пары двухкиловатных БП).

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

 

Где тут была тема, 36Gbps выжали из сервера кажется, с дичайшим тюнингом и выносом всех-всех-всех фич прочь, на другие устройства, и при этом кажется 2% трафика терялось, посмотрю я что с вами сделают пользователи если будет теряться 2% трафика от iptv, или voip

[replicant]

Основная проблема - L3-длинка(и других подобных "L3") это большая arp таблица и неустойчивость к некоторым видам arp атак. Терминирование абонентов на L3 коммутаторах это ошибка дизайна(ваша ошибка), а не проблема длинка.

 

Про arp-атаки и прочие ошибки дизайна товарищи из D-Link пытались грузить всех весьма долго, пока не повторили проблему на стендах. Около трех или более лет назад я обращался туда и даже не раз ездил и встречался со спецами и т.п., обсуждая проблему 3627 и его несоответствия заявленным параметрам. Однако пока решения нет.

 

Только идиот будет терминировать абонентов на L3 сразу и проблема была несколько иная, но в данном случае D-Link признал проблему в серии 3627, 3620 и даже в 3420, хотя это так называемый L2+.

 

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

 

Самое странное в данной ситуации - это именно несоответствие заявленным спецификациям в отношении L3 части. Когда заявлено 8000, а коммутатор начинает подыхать на 1500-2000 - это весьма неслабый просчет.

 

В данный момент у меня стоят три тазика, которые выполняют всю L3 работу с VLAN'ами при практически нулевой нагрузке, пропуская через себя в совокупности более 15 Гбит/с трафика и имея теоретическую пропускную в 30 Гбит/с.

 

На текущий момент нет "аппаратного" решения (смотрел у разных производителей), которое уложится в 150-180 т.руб. и будет готово сразу лупить более 10к ip-mac и обслуживать быстрый L3 участок + иметь отказоустойчивость т.е. дублера, потому что с тремя тазиками я легко перекидываю маршрутизацию на любые два из трех, в случае вывода на профилактику одного.

 

Если появится у D-Link решение известной беды с L3, то будем проводить тесты дальше, но пока вижу только альтернативу в виде DXS-3600 на основную агрегацию вместо трех 3627 и второй DXS-3600 на работу в L3 режиме вместо трех тазиков. Если все получится и будет работать, то будет 2 девайса вместо 6, что уже само по себе хорошо.

[s.lobanov]

Самое странное в данной ситуации - это именно несоответствие заявленным спецификациям в отношении L3 части. Когда заявлено 8000, а коммутатор начинает подыхать на 1500-2000 - это весьма неслабый просчет.

 

Т.е. он умирает при таблице arp 2К записей и без arp-атак? Ну допустим, они исправят это, но это не означает, что на нём можно терминировать абонентов, т.к. arp-атаки и прочая гадость всё равно могут убить эту железку

 

Заявлено 8К, потому что в чип можно столько залить, но их кривой софт не может это нормально сделать

[zi_rus]

Самое странное в данной ситуации - это именно несоответствие заявленным спецификациям в отношении L3 части. Когда заявлено 8000, а коммутатор начинает подыхать на 1500-2000 - это весьма неслабый просчет.

 

Т.е. он умирает при таблице arp 2К записей и без arp-атак? Ну допустим, они исправят это, но это не означает, что на нём можно терминировать абонентов, т.к. arp-атаки и прочая гадость всё равно могут убить эту железку

 

Заявлено 8К, потому что в чип можно столько залить, но их кривой софт не может это нормально сделать

если отталкиваться только от того, что длинк глючит, и потому записывать в аутсайдеры все Л3 свичи, то далеко так не уедешь. на этих китайцах свет клином сошелся что ли

[NiTr0]

На это я уже ответил, берите оборудование на тест.

На стенде нереально смоделировать все нюансы боевой сети.

 

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

Вот незадача-то, железо может на стенде работать, а в реальной сети - нет ;)

 

Терминирование абонентов на L3 коммутаторах это ошибка дизайна(ваша ошибка), а не проблема длинка.

А на чем собссно терминировать абонов-то? На тазиках? :)

 

Очень хотелось бы услышать тех. подобностей по существу.

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

 

интересно что вы собираетесь делать, если в этом вашем линуксе вылезет такой же баг

Фиксить или искать workaround. Только вот незадача, багов в ядре почему-то практически не попадается (ну не считая случаев кривого железа, которое может на стенде пахать сутками, а на живом трафике падать в панику - но таких случаев за всю мою практику был всего один), юзерленд - либо юзается стандартный, обкатанный годами софт без особой нагрузки, либо - оттестированный экспериментальный (как accel), либо - самописный.

 

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

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

[replicant]

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

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

Хорошо, что хоть L2 уровень на коммутаторах стабилен, поэтому и трудятся на доступе и агрегации, но маршрутизация сетей для большинства решений стоимостью до 150 тыс. руб. дело неподъемное и чреватое неожиданными проблемами. При этом планка в 150 т.руб. предполагает как минимум тройное резервирование на тазиках, т.е. входная планка для маршрутизаторов опускается до 50 т.руб.

 

Увы и ах, но за 50 т.руб. организовать маршрутизацию и шлюзы для абонентского трафика до 10 Гбит/с можно только на тазике, при этом проблемы с 2000 arp точно не будет.

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

Изменено 9 марта, 2013 пользователем replicant

[replicant]

если взять типичную Cisco ASR 9010

 

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

 

У всех разные потребности и любое обсуждение начинается с суммы примерно так "Я готов потратить N денег для такой-то задачи. Что Вы имеете предложить за эту сумму?".

 

Если ответ "Ничего", то идем к другому вендору и т.п. Если никто не предлагает ничего вменяемого, то делаем тазик и копим деньги дальше.

[replicant]

если отталкиваться только от того, что длинк глючит, и потому записывать в аутсайдеры все Л3 свичи, то далеко так не уедешь. на этих китайцах свет клином сошелся что ли

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

Изменено 9 марта, 2013 пользователем replicant

[Shiva]

SE100 по доке умеет Netflow... Но не выставляет Src & Dst AS - это фича, как оказалось.

SCE2020 - найдите в линухе аналог, хотя бы с потребным URL filtering.

[zi_rus]

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

для кого-то это вполне типичная железка. просто тут разговор идет про то что набор серверов может заменить ЛЮБУЮ аппаратную железку, а на поверку оказывается, что сервера если и годятся то только для ISP с парой тысяч хомячков, а SP по-крупнее предоставляющий полный спектр ethernet сервисов выберет аппаратное решение, сервера тут не игроки, основные характеристики я привел (энергопотребление, плотность портов, сложность управления) для сравнения. есть железки и больше и меньше той что я привел в качестве примера.

 

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

[NiTr0]

просто тут разговор идет про то что набор серверов может заменить ЛЮБУЮ аппаратную железку

Где вы такое увидели? Тут наоборот, некоторые пытаются доказать, что тазики падают, виснут, глючат и т.п., и только железки всех спасут; а на поверку оказывается - и у железок не все гладко и шелковисто, только вот стабильность от владельца зависит в гораздо меньшей мере, чем у тазика - если не работает что-то, то не работает... Да и гибкость на порядки ниже. Хотя - да, молотят трафик быстро, и для больших скоростей приходится мириться с их минусами.

[zi_rus]

приходится мириться

звучит как снисхождение

[NiTr0]

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

[Aliech]

А где тут было написано, что тазик заменяет в любом случае железку? Или я читать разучился? Цитату! Цитату!

 

Наоборот, тут внезапно рассказывалось о том, что железка по-определению надёжней. Кстати, никак сие не подкреплено доказательствами. И, относительно производительности, никто не делает классический пересчёт "цена/мбит".

 

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

Изменено 9 марта, 2013 пользователем Aliech

[replicant]

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

 

Просто уровень тазиков как и уровень железок бывает разный. Это тоже следует брать в расчет.

[Aliech]

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

 

Просто уровень тазиков как и уровень железок бывает разный. Это тоже следует брать в расчет.

 

$i++;

 

Меня удивили высказывания о том, что железка в любом случае надёжней, например такие:

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

[sexst]

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

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

[kaktak]

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

 

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