s.lobanov Опубликовано 9 марта, 2013 · Жалоба Вот у нас например НАТ-ы на железках. Довольны куда более нежели на тазиках. Проблем никаких. Ну это как раз странно. NAT это та самая задача, которая довольно неплохо решается на x86 софтроутерах. Видимо вы что-то недоосилили, может у вас хеш-таблица было маленькая или ещё что... Мое мнение - на тазики вешать только БРАС-ы Просто нет небольших BRAS-ов для небольших операторов(микротик в расчёт не берём). Ну есть SE100, но сейчас 6GE портов сделать на сервере это вообще не проблема(и получится намного дешевле, если есть нормальный специалист по линуксу), да и вообщем-то 2x10G карты для x86-серверов доступные. А так hw решения BRAS отлично работают, только большие кап. вложения получаются на малых объёмах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aliech Опубликовано 9 марта, 2013 · Жалоба Т.е. сами составили спеку, купили, начали настраивать и поняли, что не хватает такой-то фичи("вендор что-то не реализовал")? Ну сами виноваты, раз возлагаете на себя функцию интегратора/инженера вендора по подбору оборудования под ТЗ и не можете справиться с этой задачей. Вендор мог спокойно не реализовать то, что обещал в спеке. Или реализовать криво. Если это было бы не так, то тех. поддержка вендора сидела бы без работы. А вон в соседней теме обсуждают как выгрести fdb таблицу из linux-бриджа, видимо кто-то считает что и свитчи должны быть собраны на базе обычных PC/серверов... В любом деле важно подходить к вопросу без фанатизма. Просто нет небольших BRAS-ов для небольших операторов(микротик в расчёт не берём). Ну есть SE100, но сейчас 6GE портов сделать на сервере это вообще не проблема(и получится намного дешевле, если есть нормальный специалист по линуксу), да и вообщем-то 2x10G карты для x86-серверов доступные. А так hw решения BRAS отлично работают, только большие кап. вложения получаются на малых объёмах. Я к тому же. Граждане дорогие, я так и не нашёл упоминаний, чем конкретно надёжней аппаратные решения. А про производительность... Так не хотелось упоминать, но "да за эти деньги можно пачку серверов купить!!!!11111" Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 9 марта, 2013 · Жалоба Вендор мог спокойно не реализовать то, что обещал в спеке. Или реализовать криво. Если это было бы не так, то тех. поддержка вендора сидела бы без работы. По поводу багов уже обсудили. А по поводу фич, то есть такая вещь как "взять оборудование на тест". Если вы не микрооператор с какими-нибудь 500 абонентами онлайн, то вам дадут желеку на тест(возможно, удалённо с подключенным к ней PC). А если вы очень маленький, то продолжайте пользоваться серверами и не парьтесь, никто особо и заморачиваться с вами не будет, чтобы что-то продать вам(вопросов от вам будет море, а выхлоп(прибыль) мизерная) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 9 марта, 2013 · Жалоба Т.е. сами составили спеку, купили, начали настраивать и поняли, что не хватает такой-то фичи("вендор что-то не реализовал")? Т.е. поставили, начали настраивать нетипичный конфиг (ибо захотелось "все на железке"), и наткнулись на багу в вари, или на недокументированную особенность в виде невозможности одновременной работы каких-то фич. И не факт что вендор исправит - особенно если никто, кроме вас не пытался в таком конфиге запускать (и навряд попытается), а исправление займет много человекочасов. И ладно если это вылезет сразу после покупки - вернуть-то не проблема. Гораздо хуже, если это начнет вылазить в процессе эксплуатации (добавление нового функционала, мультикастового влана для иптв к примеру, вызовет проблемы с MSTP, или добавление в сеть железки другого вендора вызовет сказочные глюки, или просто при увеличении кол-ва маков/роста трафика на железке ее начнет сказочно таращить как л3 длинки). Кстати, яркий пример надежности железок - эпопея с апгрейдом UA-IX: свежеустановленные Extreme таращило несколько месяцев, окончилось вроде как заменой железок вендором, ибо софтово побороть краши/дропы не получилось. Ну и попутно - значительной потерей трафика, который перетек в другие точки обмена и в разрастающиеся на этой почве пиринги между операторами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 9 марта, 2013 · Жалоба Т.е. поставили, начали настраивать нетипичный конфиг (ибо захотелось "все на железке"), и наткнулись на багу в вари, или на недокументированную особенность в виде невозможности одновременной работы каких-то фич. И не факт что вендор исправит - особенно если никто, кроме вас не пытался в таком конфиге запускать (и навряд попытается), а исправление займет много человекочасов. На это я уже ответил, берите оборудование на тест. И ладно если это вылезет сразу после покупки - вернуть-то не проблема. Гораздо хуже, если это начнет вылазить в процессе эксплуатации (добавление нового функционала, мультикастового влана для иптв к примеру, вызовет проблемы с MSTP, Перед запуском новых услуг надо обкатывать их на стенде. Оборудование для стенда брать из ЗИПа(если не руководствоваться принципом, что ЗИП это для лохов) или просто при увеличении кол-ва маков/роста трафика на железке ее начнет сказочно таращить как л3 длинки Основная проблема - L3-длинка(и других подобных "L3") это большая arp таблица и неустойчивость к некоторым видам arp атак. Терминирование абонентов на L3 коммутаторах это ошибка дизайна(ваша ошибка), а не проблема длинка. Кстати, яркий пример надежности железок - эпопея с апгрейдом UA-IX: свежеустановленные Extreme таращило несколько месяцев, окончилось вроде как заменой железок вендором, ибо софтово побороть краши/дропы не получилось. Ну и попутно - значительной потерей трафика, который перетек в другие точки обмена и в разрастающиеся на этой почве пиринги между операторами. Очень хотелось бы услышать тех. подобностей по существу. Кто и как составлял спеку(участвовали ли в этом известные интеграторы или представители вендора)? IX же это вообще тупая коммутация по сути(со статической мак-таблицей). Как они там крешей добились, не очень понятно. Или они там RS подняли на железке, а не на сервере? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zi_rus Опубликовано 9 марта, 2013 · Жалоба и наткнулись на багу ... И не факт что вендор исправит - особенно если никто, кроме вас не пытался в таком конфиге запускать (и навряд попытается), а исправление займет много человекочасов. интересно что вы собираетесь делать, если в этом вашем линуксе вылезет такой же баг если сами, то это бабки много большие чем заплатите вендору за сервис контракт упросите комьюнити - вот уж нелепость, никаких гарантий ни по срокам ни по результату купите поддержку у разаработчика типа Red Hat - так чем же это лучше производителя аппартных решений Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 9 марта, 2013 · Жалоба и наткнулись на багу ... И не факт что вендор исправит - особенно если никто, кроме вас не пытался в таком конфиге запускать (и навряд попытается), а исправление займет много человекочасов. интересно что вы собираетесь делать, если в этом вашем линуксе вылезет такой же баг если сами, то это бабки много большие чем заплатите вендору за сервис контракт упросите комьюнити - вот уж нелепость, никаких гарантий ни по срокам ни по результату купите поддержку у разаработчика типа Red Hat - так чем же это лучше производителя аппартных решений В некоторых операторах встречаются люди, которые умеют трейсить ядро и что-то исправлять или находить workaround-ы. Насколько я понимаю, NiTr0 как раз к ним отноится. Но это больше исключение, чем правило Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zi_rus Опубликовано 9 марта, 2013 · Жалоба В некоторых операторах встречаются люди, которые умеют трейсить ядро и что-то исправлять или находить workaround-ы. Насколько я понимаю, NiTr0 как раз к ним отноится. Но это больше исключение, чем правило встречаются, но они в любом случае не смогут найти и исправить проблему быстрее разработчика А про производительность... Так не хотелось упоминать, но "да за эти деньги можно пачку серверов купить!!!!11111" можно, только если взять типичную Cisco ASR 9010 и посчитать сколько нужно серверов чтобы обеспечить хотябы приблизительную производительность (440Gbps на слот между прочим), 40*10G портов в одном слоту может быть, сколько серверов понадобится чтобы просто получить такое количество портов, сколько еще сил и оборудования уйдет на просто организацию их взаимодействия, сколько это все места займет (решение вендора имеет высоту 22U), а еще энергопотребление и охлаждение (аппаратное решение вендора при полной набивке всех слотов способно работать от пары двухкиловатных БП). плюс надежность, предположим что одно шасси не так надежно как десяток стоек с серверами, значит ставим второе шасси с такой же набивкой (это все равно не будет дороже чем сервера которые пытались тягаться со специализированным решением), и вот получаются два шасси которые дублируют друг друга и у которых внутри также все дублировано... в общем все очевидно, причем, прощу учесть, это не тупой CRS который сервисов почти не умеет и заточен только на скоростной форвардинг, это самый что ни на есть РЕ-роутер обеспечивающий сервисы Где тут была тема, 36Gbps выжали из сервера кажется, с дичайшим тюнингом и выносом всех-всех-всех фич прочь, на другие устройства, и при этом кажется 2% трафика терялось, посмотрю я что с вами сделают пользователи если будет теряться 2% трафика от iptv, или voip Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 9 марта, 2013 · Жалоба Основная проблема - 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, что уже само по себе хорошо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 9 марта, 2013 · Жалоба Самое странное в данной ситуации - это именно несоответствие заявленным спецификациям в отношении L3 части. Когда заявлено 8000, а коммутатор начинает подыхать на 1500-2000 - это весьма неслабый просчет. Т.е. он умирает при таблице arp 2К записей и без arp-атак? Ну допустим, они исправят это, но это не означает, что на нём можно терминировать абонентов, т.к. arp-атаки и прочая гадость всё равно могут убить эту железку Заявлено 8К, потому что в чип можно столько залить, но их кривой софт не может это нормально сделать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zi_rus Опубликовано 9 марта, 2013 · Жалоба Самое странное в данной ситуации - это именно несоответствие заявленным спецификациям в отношении L3 части. Когда заявлено 8000, а коммутатор начинает подыхать на 1500-2000 - это весьма неслабый просчет. Т.е. он умирает при таблице arp 2К записей и без arp-атак? Ну допустим, они исправят это, но это не означает, что на нём можно терминировать абонентов, т.к. arp-атаки и прочая гадость всё равно могут убить эту железку Заявлено 8К, потому что в чип можно столько залить, но их кривой софт не может это нормально сделать если отталкиваться только от того, что длинк глючит, и потому записывать в аутсайдеры все Л3 свичи, то далеко так не уедешь. на этих китайцах свет клином сошелся что ли Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 9 марта, 2013 · Жалоба На это я уже ответил, берите оборудование на тест. На стенде нереально смоделировать все нюансы боевой сети. Перед запуском новых услуг надо обкатывать их на стенде. Вот незадача-то, железо может на стенде работать, а в реальной сети - нет ;) Терминирование абонентов на L3 коммутаторах это ошибка дизайна(ваша ошибка), а не проблема длинка. А на чем собссно терминировать абонов-то? На тазиках? :) Очень хотелось бы услышать тех. подобностей по существу. В этом плаче о 15-ти страницах проскакивают и технические детали происходящего. Мне как-то не особо интересно было выяснять все детали, а общую картину апгрейда, переросшего в бета-тестирование, и так сложил. интересно что вы собираетесь делать, если в этом вашем линуксе вылезет такой же баг Фиксить или искать workaround. Только вот незадача, багов в ядре почему-то практически не попадается (ну не считая случаев кривого железа, которое может на стенде пахать сутками, а на живом трафике падать в панику - но таких случаев за всю мою практику был всего один), юзерленд - либо юзается стандартный, обкатанный годами софт без особой нагрузки, либо - оттестированный экспериментальный (как accel), либо - самописный. встречаются, но они в любом случае не смогут найти и исправить проблему быстрее разработчика Разработчик вполне может положить болт на правку (и часто ложит - если конфиг нетиповый, и обращения единичные). И счастливый владелец остается один на один с шайтан-коробкой в раздумиях: или ну его нах совмещать фичи, или ну его нах пользовать купленную за много денег коробку. Или будет ждать у моря погоды месяцами, пока вендор пофиксит багу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 9 марта, 2013 (изменено) · Жалоба Правильно NiTr0 сказал. По крайней мере, когда у меня в руках тазик и дистрибутив, то я знаю что смогу, а что не смогу из этого выжать. А когда у меня в руках шайтан-коробка, то приходится доверяться разработчикам, рискуя что в любой момент с коробкой может произойти такое, что ты не сможешь предвидеть и быстро устранить. Хорошо, что хоть L2 уровень на коммутаторах стабилен, поэтому и трудятся на доступе и агрегации, но маршрутизация сетей для большинства решений стоимостью до 150 тыс. руб. дело неподъемное и чреватое неожиданными проблемами. При этом планка в 150 т.руб. предполагает как минимум тройное резервирование на тазиках, т.е. входная планка для маршрутизаторов опускается до 50 т.руб. Увы и ах, но за 50 т.руб. организовать маршрутизацию и шлюзы для абонентского трафика до 10 Гбит/с можно только на тазике, при этом проблемы с 2000 arp точно не будет. Таким образом у каждого потребителя тех или иных решений есть отправная точка в виде суммы денег, которую можно выделить для решения задачи. В эту сумму и вписываемся. Изменено 9 марта, 2013 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 9 марта, 2013 · Жалоба если взять типичную Cisco ASR 9010 Нормальная такая типичная ситуация ... %) Манагеры-продаваны еще любят при этом петь песнь о том, сколько много миллионов денег можно выжать из бизнес процессов при такой-то железке и прочий маркетинговый бред ... У всех разные потребности и любое обсуждение начинается с суммы примерно так "Я готов потратить N денег для такой-то задачи. Что Вы имеете предложить за эту сумму?". Если ответ "Ничего", то идем к другому вендору и т.п. Если никто не предлагает ничего вменяемого, то делаем тазик и копим деньги дальше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 9 марта, 2013 (изменено) · Жалоба если отталкиваться только от того, что длинк глючит, и потому записывать в аутсайдеры все Л3 свичи, то далеко так не уедешь. на этих китайцах свет клином сошелся что ли Не все, а только стоимостью как минимум до 150 т.р. практически вне зависимости от фирмы-производителя. Хотя есть мнение, что и многие более дорогие тоже приходится записывать в аутсайдеры. :) Изменено 9 марта, 2013 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Shiva Опубликовано 9 марта, 2013 · Жалоба SE100 по доке умеет Netflow... Но не выставляет Src & Dst AS - это фича, как оказалось. SCE2020 - найдите в линухе аналог, хотя бы с потребным URL filtering. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zi_rus Опубликовано 9 марта, 2013 · Жалоба Нормальная такая типичная ситуация ... %) Манагеры-продаваны еще любят при этом петь песнь о том, сколько много миллионов денег можно выжать из бизнес процессов при такой-то железке и прочий маркетинговый бред ... для кого-то это вполне типичная железка. просто тут разговор идет про то что набор серверов может заменить ЛЮБУЮ аппаратную железку, а на поверку оказывается, что сервера если и годятся то только для ISP с парой тысяч хомячков, а SP по-крупнее предоставляющий полный спектр ethernet сервисов выберет аппаратное решение, сервера тут не игроки, основные характеристики я привел (энергопотребление, плотность портов, сложность управления) для сравнения. есть железки и больше и меньше той что я привел в качестве примера. было бы не верно утверждать что сервера вообще ни на что не годятся, но я уверен что приведенным примером однозначно доказал что есть ситуации когда на серверах каши не сваришь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 9 марта, 2013 · Жалоба просто тут разговор идет про то что набор серверов может заменить ЛЮБУЮ аппаратную железку Где вы такое увидели? Тут наоборот, некоторые пытаются доказать, что тазики падают, виснут, глючат и т.п., и только железки всех спасут; а на поверку оказывается - и у железок не все гладко и шелковисто, только вот стабильность от владельца зависит в гораздо меньшей мере, чем у тазика - если не работает что-то, то не работает... Да и гибкость на порядки ниже. Хотя - да, молотят трафик быстро, и для больших скоростей приходится мириться с их минусами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zi_rus Опубликовано 9 марта, 2013 · Жалоба приходится мириться звучит как снисхождение Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 9 марта, 2013 · Жалоба Ага, если тазик может справиться с задачей, а особенно если задача требует сколь-либо умного поведения девайса - железку туда я не вижу смысла ставить. Ибо завтра понадобится доп. функционал - и железка превращается в тыкву. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aliech Опубликовано 9 марта, 2013 (изменено) · Жалоба А где тут было написано, что тазик заменяет в любом случае железку? Или я читать разучился? Цитату! Цитату! Наоборот, тут внезапно рассказывалось о том, что железка по-определению надёжней. Кстати, никак сие не подкреплено доказательствами. И, относительно производительности, никто не делает классический пересчёт "цена/мбит". А ввиду того, что упёртые сторонники железок сейчас могут воспринять это как наезд на их священную корову: нет, не наезд. Просто не всё однозначно в данном вопросе. Изменено 9 марта, 2013 пользователем Aliech Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 10 марта, 2013 · Жалоба Поэтому и сосуществуют железки вместе с тазиками одновременно не только у небольших операторов, но даже и у крупных игроков. Просто уровень тазиков как и уровень железок бывает разный. Это тоже следует брать в расчет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aliech Опубликовано 10 марта, 2013 · Жалоба Поэтому и сосуществуют железки вместе с тазиками одновременно не только у небольших операторов, но даже и у крупных игроков. Просто уровень тазиков как и уровень железок бывает разный. Это тоже следует брать в расчет. $i++; Меня удивили высказывания о том, что железка в любом случае надёжней, например такие: таки это вы для начала потрудитесь предоставить пруфы что это не так, потому что превосходство в производительности (да и надежности) аппаратного решения очевидно любому здравомыслящему человеку, а вот обратное стоит для начала подкрепить хоть чем-то Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sexst Опубликовано 10 марта, 2013 · Жалоба Железка единичная как правило надежнее (в хардварном плане) единичного тазика, но тазики с лихвой компенсируют это ценой. Там где для того же ната/полисинга/нетфлоу/ваша задача стоит железка, нередко можно влепить за те же деньги пачку тазиков, что уже явно надежнее в сумме. Вдобавок для бешеного и тупого молочения трафика и MPLS железкам вообще конкуренции нет. Так что тут и сравнивать незачем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaktak Опубликовано 10 марта, 2013 · Жалоба Там где для того же ната/полисинга/нетфлоу/ваша задача стоит железка, нередко можно влепить за те же деньги пачку тазиков, что уже явно надежнее в сумме. а мне вот кажется, что покупая пачку тазиков, мы существенно увеличиваем вероятность встретить косяк одного из компонентов, из-за которого сервер магическим образом перезагружается, виснет, глючет etc. А потом потратить месяцы и нервы на его поиски и устранение. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...