On Thu, May 26, 2016 at 12:40:25PM +0300, Max Tulyev wrote:

BIRD

+1 :)

On 26.05.16 12:04, Andrii Stesin wrote:

...

Коллeги, а на чeм нончe модно поднимать BGP eсли FreeBSD? Zebra, чи Quagga, чи eсть что-то болee актуальноe? Надо стeндик учeбньій собрать шоб 2-3 full view дeржал.

Заранee спасибо за хинт :)

С ув., я :)

-- MINO-RIPE

Спасибо, коллeги, вьі открьіли мнe новьіe горизонтьі :) ушeл сeтапить.

On 27.05.16 11:55, Maksym Tulyuk wrote:

Привет!

А какие нюансы?

Из личного опыта: - Quagga - большие проблемы с маштабированием из-за single-thread кода 20летней давности; разработчики много раз обещали поправить (последний раз на райповке в 2012), но результата пока нет (в 2015 опять собирали деньги на новый BGPd) согласен. - OpenBGPd - работает но медленно на больших BGP таблицах или при большом кол-ве сессий; разработка почти остановилась; разработчики отвечают “по настроению” не соглашусь. да, были проблемы, но в Опенке сейчас обновленная версия, с большими улучшениями механизма фильтрации. - BIRD - хорошо работает и разработчики регулярно исправляют глюки угу, только настройка достаточно эзотерична, и порой требует заглядывания в исходники, чтобы понять, что же разрабы этим хотели сказать.

-- With best regards, Gregory Edigarov

Today May 27, 2016 at 13:40 Vladimir Sharun wrote:

Всем привет, А сколько оно может (без файрвола) выдать мегапакетов например с 2-3 full view ?

"Оно" - это кто? Работа BGPd принять анонсы, посчитать и построить таблицы ядру, а маршрутизацией пакетов уже ядро занимается. -- WNGS-RIPE

Today May 27, 2016 at 15:41 Vladimir Sharun wrote:

Привет,

Обычно не на смарт-часах bird пускают и не только для "а вот смотрите детки, как комьюнити делается". Бывает, что и роутят. И есть отличное от нуля кол-во компаний, которые используют х64 сервера как роутеры в мире.

Потому я и спросил ""Оно" - это кто?", ведь на х64 серверах "отличное от нуля кол-во" ОС и "отличное от нуля кол-во" железа. Там два весомых момента - пропускание через себя пакетов и поиск куда их отправлять по таблице. Напрямую в обоих Quagga/OpenBGPD/BIRD не участвуют. Косвенно могут мешать локами при перестройке, но даже это в большей степени зависит от реализации в ядре. -- WNGS-RIPE

Я бы перефразировал вопрос в сторону "за сколько времени оно пережуёт 2 фуллвью? 3? 4? помогут ли тучаядер или нужен жидкий азот и разгон", т.к. именно "квагга долго раздупляется" явилось для нас причиной отказа от фулл-вью в своё время. А собственно от ОС зависят PPS и скорость изменения маршрутов в ядре - странно, что нету апи "впендюрить этот кусок памяти в ядро в качестве таблицы маршрутизации", а есть "добавить-удалить 1 маршрут" и так 100500 раз - "это не может быть вкусно"(с)ЮТ про белковый коктейль с утра. On Fri, May 27, 2016 at 03:59:10PM +0300, Vladimir Sharun wrote:

Спасибо,

Вернемся к первому вопросу: опыт использования, pps reached/sustained и negatives. 

--- Оригінальне повідомлення --- Від кого: "Oleksandr V. Typlyns'kyi" Дата: 27 травня 2016, 15:56:28

Today May 27, 2016 at 15:41 Vladimir Sharun wrote:

...

Привет,

Обычно не на смарт-часах bird пускают и не только для "а вот смотрите детки, как комьюнити делается". Бывает, что и роутят. И есть отличное от нуля кол-во компаний, которые используют х64 сервера как роутеры в мире.

Потому я и спросил ""Оно" - это кто?", ведь на х64 серверах "отличное от нуля кол-во" ОС и "отличное от нуля кол-во" железа. Там два весомых момента - пропускание через себя пакетов и поиск куда их отправлять по таблице. Напрямую в обоих Quagga/OpenBGPD/BIRD не участвуют. Косвенно могут мешать локами при перестройке, но даже это в большей степени зависит от реализации в ядре.

-- WNGS-RIPE

-- Best regards, Paul Arakelyan.

Всем привет, Тёмную сторону продажника чувствую в твоих словах я. Философия есть объективная наука об истине, наука о ее необходимости, познание посредством понятий, а не мнение, и не тканье паутины мнений… Вот по-этому мне подход Гегеля ближе. --- Оригінальне повідомлення --- Від кого: "Volodymyr Litovka" Дата: 27 травня 2016, 17:36:58 современным процам переварить 5 full view - понты, гораздо дольше занимает инсталлиция маршрутов в FIB именно поэтому опорные маршрутизаторы стоят дорого - потому что у них операция "впендюрить этот кусок памяти в качестве таблицы маршрутизации" делается в железе (ну и не так топорно, конечно) честно говоря, я не вижу применения софт-BGP-раутерам кроме функции route reflector. Там, где нужно гонять трафик - там надо ставить маршрутизатор и не морочить себе голову вопросом "сколько pps можно выжать из x64". Нисколько. On 5/27/16 5:21 PM, Paul Arakelyan wrote: Я бы перефразировал вопрос в сторону "за сколько времени оно пережуёт 2 фуллвью? 3? 4? помогут ли тучаядер или нужен жидкий азот и разгон", т.к. именно "квагга долго раздупляется" явилось для нас причиной отказа от фулл-вью в своё время. А собственно от ОС зависят PPS и скорость изменения маршрутов в ядре - странно, что нету апи "впендюрить этот кусок памяти в ядро в качестве таблицы маршрутизации", а есть "добавить-удалить 1 маршрут" и так 100500 раз - "это не может быть вкусно"(с)ЮТ про белковый коктейль с утра. On Fri, May 27, 2016 at 03:59:10PM +0300, Vladimir Sharun wrote: Спасибо, Вернемся к первому вопросу: опыт использования, pps reached/sustained и negatives.  --- Оригінальне повідомлення --- Від кого: "Oleksandr V. Typlyns'kyi" Дата: 27 травня 2016, 15:56:28 Today May 27, 2016 at 15:41 Vladimir Sharun wrote: Привет, Обычно не на смарт-часах bird пускают и не только для "а вот смотрите детки, как комьюнити делается". Бывает, что и роутят. И есть отличное от нуля кол-во компаний, которые используют х64 сервера как роутеры в мире. Потому я и спросил ""Оно" - это кто?", ведь на х64 серверах "отличное от нуля кол-во" ОС и "отличное от нуля кол-во" железа. Там два весомых момента - пропускание через себя пакетов и поиск куда их отправлять по таблице. Напрямую в обоих Quagga/OpenBGPD/BIRD не участвуют. Косвенно могут мешать локами при перестройке, но даже это в большей степени зависит от реализации в ядре. -- WNGS-RIPE -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

On Sat, May 28, 2016 at 01:25:37AM +0300, Volodymyr Litovka wrote:

On 5/27/16 9:18 PM, Vladimir Sharun wrote:

...

Всем привет,

Тёмную сторону продажника чувствую в твоих словах я.

/Философия есть объективная наука об истине, наука о ее необходимости, познание посредством понятий, а не мнение, и не тканье паутины мнений???/

Вот по-этому мне подход Гегеля ближе.

Ээээээ.... ок... ;-)

Я еще где-то в мире 100-гигабитного ethernet, прости :) скоро попустит и я даже соглашусь, что x86 - очень даже ничего маршрутизатор.

Ну не всюду же 100Г - далеко не все, кто хочет себе "фулл-вью" много-ного раз имеют 10Г или даже 1Г. При этом цена 1Г роутера с такими возможностями оказывается "достаточно кусачей", а необходимость быстрой замены железки множит её на 2. Таки непонятно, почему при наличии домашних мыльниц с гигабитом за "менее 100$" нету "продвинутых мыльниц с БГП за 300" с кучей памяти на борту и процом помощнее, ну и 10Г должны бы в 600-800 уложиться (учитывая вагон сетевух 10Г на ебее за 100+- уе). Ышчо не понятно, а фигли ж не видно PC-роутеров с видяшками? Хотя я затрудняюсь ответить "за сколько времени OpenCL залукапит и вернет что-то", но параллелизм офигенный же. -- Best regards, Paul Arakelyan.

On Sat, May 28, 2016 at 02:20:35PM +0300, Oleksandr V. Typlyns'kyi wrote:

Today May 28, 2016 at 10:53 Paul Arakelyan wrote:

...

On Sat, May 28, 2016 at 01:25:37AM +0300, Volodymyr Litovka wrote:

...

Я еще где-то в мире 100-гигабитного ethernet, прости :) скоро попустит и я даже соглашусь, что x86 - очень даже ничего маршрутизатор.

Ну не всюду же 100Г - далеко не все, кто хочет себе "фулл-вью" много-ного раз имеют 10Г или даже 1Г. При этом цена 1Г роутера с такими возможностями оказывается "достаточно кусачей", а необходимость быстрой замены железки множит её на 2. Таки непонятно, почему при наличии домашних мыльниц с гигабитом за "менее 100$" нету "продвинутых мыльниц с БГП за 300" с кучей памяти на борту и процом помощнее, ну и 10Г должны бы в 600-800 уложиться (учитывая вагон сетевух 10Г на ебее за 100+- уе).

И они выдают 10G, а не 3-4? Я не пробовал, домашний iSCSI вылезает за гигабит только под hyper-v :) (virtualbox и vmware - раскочегариваются до 50-60, но у vmware глючный vmxnet3 - пакеты иногда бъются, причем никакой закономерности я не нашел), так что дома 10Г вроде как и не нужен (плюс жрёт оно наверно дофига электричества). Но в целом - там куча каких-то интелов в окрестностях 100-200уе.

...

Ышчо не понятно, а фигли ж не видно PC-роутеров с видяшками? Хотя я затрудняюсь ответить "за сколько времени OpenCL залукапит и вернет что-то", но параллелизм офигенный же.

Скорее FPGA дорастут. Пока у них проблемка с объёмами памяти и доступом к внешней памяти, как я помню из майнинга лайтов, ну и цена зашкаливающая. А шансы появления "ASIC for PC router" почти равны нулю - нужна куча (пусть и простых) ядер для лукапа плюс расширяемость памяти. В любом случае - масштаб вносимых задержек не ясен. Зато тот же микротик уже штампует железки с "100500 ядер проца".

-- Best regards, Paul Arakelyan.

Привет ! Saturday, May 28, 2016, 1:25:37 AM, Volodymyr Litovka doka.ua@gmail.com you wrote: VL> On 5/27/16 9:18 PM, Vladimir Sharun wrote: VL> Тёмную сторону продажника чувствую в твоих словах я. пять баллоов :-) VL> Философия есть объективная наука об истине, наука о ее VL> необходимости, познание посредством понятий, а не мнение, и не тканье паутины мнений… Не существует "непосредственного восприятия" Реальности. Всё есть Искажение Истинного, посредством наших органов чувств, математических приближений и моделирования. Так чтаа... Напочитать про зрение например: http://www.nkj.ru/archive/articles/1865/ VL> Я еще где-то в мире 100-гигабитного ethernet, прости :) VL> скоро попустит и я даже соглашусь, что x86 - очень даже ничего маршрутизатор. Я, как человек который до сих пор программирует всякие микроконтроллеры, работающие в реал-тайм (настоящем реал-тайм а не той отрыжке которая "виртуальные машины" и "Виньда" и "Юних"), могу сказать, что религиозные споры на тему "Киска лучше чем" напоминает споры про то чем Армяне лучше :) Так вот, для целей гоняния трафика, сильно важно чтобы заторов процессор-память-сетевая карта не было. Заторы обычно всякие ОСы вызывают, мешая процессору заниматься делом пересылки байт и оценкой(разборкой-сборкой) всяких пакетов и простых задач сортировок. "Помогают" всей проблеме тормознутости - программисты, которые программяд для какого-то сферического процессора в вакууме, свято веря что оно в С++ та внутрях работает, вырисовывая всякие извратные конструкции на С++... "Завещание Вирта" - ищем и читаем. до просветления. Реалтайм ройтер хоть с сотнями гиг трафика можно делать на любой платформе, НО КОТОРАЯ позволяет аппаратную скорость пересылки байт, достаточную для сборки-разборки анализа пакетов. ЛЮБОЙ ПЛАТФОРМЕ которая отвечает по скорости. Писюки сейчас, если писать софт для процессора и железа, а не для тормозной Винды, имеют такую производительность, что многим кискам и не снилась. Все упирается в скорость шины и DMA, т.е. применять "серверные материнки". Так шо не сотвори кумира - выбрасывайте все-все лишнее из Юниха, пересобирайте ядро с огромными буферными возможностями по памяти, и будет вам щастье в виде быстрого раутера :) Аминь :-) VL> VL> VL> --- Оригінальне повідомлення --- VL> VL> VL> VL> современным процам переварить 5 full view - VL> понты, гораздо дольше занимает инсталлиция маршрутов в FIB VL> VL> именно поэтому опорные маршрутизаторы стоят VL> дорого - потому что у них операция "впендюрить VL> этот кусок памяти в качестве таблицы VL> маршрутизации" делается в железе (ну и не так топорно, конечно) VL> VL> честно говоря, я не вижу применения VL> софт-BGP-раутерам кроме функции route VL> reflector. Там, где нужно гонять трафик - там VL> надо ставить маршрутизатор и не морочить себе VL> голову вопросом "сколько pps можно выжать из x64". Нисколько. VL> VL> VL> VL> VL> VL> -- Best regards, Alexander V Soroka http://www.svr.ua/ AS106-RIPE mailto:alex@euro.net.ua

VL> Философия есть объективная наука об истине, наука о ее VL> необходимости, познание посредством понятий, а не мнение, и не тканье паутины мнений…

Не существует "непосредственного восприятия" Реальности. Всё есть Искажение Истинного, посредством наших органов чувств, математических приближений и моделирования. Так чтаа... Напочитать про зрение например: http://www.nkj.ru/archive/articles/1865/

Александр Васильич, знаете как отличить шарлатанскую статью от научной ? В научных статьях предельно точны и выверены формулировки. Все. Исключений нет. "Спектр - это зависимость амплитуды (или энергии) колебаний от их частоты." Вот "по материалам" кого писалась статья в НиЖ, на которую Вы ссылаетесь: http://scorcher.ru/art/any/hazen.php

Александр Василич,

Всего один вопрос к вам: 1) обьясните НАУЧНО почему "чтобы увидеть мелкие детали нам надо ВКЛЮЧИТЬ БОЛЬШЕ ОСВЕЩЕНИЯ".

https://books.google.com.ua/books?id=kPyyBAomC4cC&printsec=frontcover#v=onepage&q&f=false Страница 29 и 30. Вкратце если - разрешающая способность - это функция размера зрачка (при прочих равных). Слишком раскрытый - высокие абберации внутри системы снижают контраст и соотв. разрешение, слишком закрытый (да-да, если слишком много света дать, то разрешение тоже УПАДЁТ) - уже дифракционные эффекты. Тот же эффект можно наблюдать на "простых" фиксах 50-85мм с дыркой 1.4 и больше - они все до единого низкоконтрастны открытые (и резкость - тоже с проблемами.). Zeiss в своей серии Otus'ов пошел по стопе борьбы с абберациями на открытой и таки добился результата, за что и чаржит премиум (от 5кбкс за полтос). А если дырку на full frame начать закрывать после F/8 дальше, то с F/11 можем наблюдать дифракционное падение резкости при соблюдении общего контраста. На кропе - уже с F/8 это видно. Там же (стр 30) - формула зависимости диаметра зрачка от освещенности объекта.

Александр Васильевич,

...

...

Всего один вопрос к вам: 1) обьясните НАУЧНО почему "чтобы увидеть мелкие детали нам надо ВКЛЮЧИТЬ БОЛЬШЕ ОСВЕЩЕНИЯ".

VS> https://books.google.com.ua/books?id=kPyyBAomC4cC&printsec=frontcover#v=onepage&q&f=false VS> Страница 29 и 30.

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

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

сами-же себе противоречите:

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

ваши слова : VS> Слишком раскрытый - высокие абберации внутри системы снижают VS> контраст и соотв. разрешение, слишком закрытый (да-да, если VS> слишком много света дать, то разрешение тоже УПАДЁТ) - уже VS> дифракционные эффекты.

противоречат вашим-же словам о размере зрачка. :-)

Это Ваше мнение, я не собираюсь с ним спорить или Вас переубеждать. Вы попросили научный подход, объясняющий - я его привёл, там в т.ч. на стр 29-30 формируется формула, описывающая MTF глаза.

и тем-более противоречат "тому как работает ПЗЦ матрица". и опять про "палочки и колбочки" напомню: почему в глазу они смотрят не вне (в сторону роговицы) а назад (в сторону мозга)? :-) Это тоже от размеров зрачка зависит ? :)))

https://askabiologist.asu.edu/rods-and-cones Здесь объясняется почему они так, а не иначе и чем это выгодно Вот тут разжевуется еще лучше, почему нерв находится между зрачком и кластерами конусов: http://www.faculty.virginia.edu/ASTR3130/lectures/humaneye/humaneye.html

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

Надо-надо. В массы шарлатанство нести - лишнее.

Кстати быстрый свитчинг на интеле - вопрос уже очень недурно проработан, см. http://dpdk.org/ и что характерно http://openvswitch.org/ is the default switch in XenServer 6.0 в частности, и он на базе DPDK https://github.com/openvswitch/ovs/blob/master/FAQ.md 2016-06-29 12:03 GMT+03:00 Volodymyr Litovka :

On 5/30/16 9:29 AM, Alexander V Soroka wrote:

...

Реалтайм ройтер хоть с сотнями гиг трафика можно делать на любой платформе, НО КОТОРАЯ позволяет аппаратную скорость пересылки байт, достаточную для сборки-разборки анализа пакетов. ЛЮБОЙ ПЛАТФОРМЕ которая отвечает по скорости. Писюки сейчас, если писать софт для процессора и железа, а не для тормозной Винды, имеют такую производительность, что многим кискам и не снилась. Все упирается в скорость шины и DMA, т.е. применять "серверные материнки".

Готов идти к согласию, когда мы определимся с тем, что ты вкладываешь в слова "сборка-разборка-анализ пакетов": - IPoE? PPPoE? dot1q? qinq? EoMPLS? сколько меток? - L3-анализ? DPI? IPSec?

;-)

...

Так шо не сотвори кумира - выбрасывайте все-все лишнее из Юниха, пересобирайте ядро с огромными буферными возможностями по памяти, и будет вам щастье в виде быстрого раутера :)

Просто беда у всех этих Інтелов, HPE, Цисок и прочих производителей сетевых решений - постоянно придумывают что-то новое для решения такой простой задачи ;-)

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

Если мне не изменяет техническая интуиция, DPDK расшивает узкое "горлышко" архитектуры, а уж такие вещи как DPI etc. реализуются просто на процессоре(ах) в общей RAM без каких-то особых ухищрений, в N потоков, ... 2016-06-29 14:45 GMT+03:00 Volodymyr Litovka :

Свичинг - не вопрос. Даже ip routing уже почти не вопрос.

Вопрос - анализ и обработка пакетов. Например, vBNG (QoS, ACL, accounting) или DPI или whatever else выше простого ip lookup.

On 6/29/16 2:43 PM, Andrii Stesin wrote:

...

Кстати быстрый свитчинг на интеле - вопрос уже очень недурно проработан, см. http://dpdk.org/ и что характерно http://openvswitch.org/ is the default switch in XenServer 6.0 в частности, и он на базе DPDK https://github.com/openvswitch/ovs/blob/master/FAQ.md

On Wed, Jun 29, 2016 at 03:11:16PM +0300, Volodymyr Litovka wrote:

Но DPI - в любом случае в тысячи раз более "тяжелая" задача, чем mac / ip-lookup :) Тут нужна предельная оптимизация кода, но, на самом деле, всё равно вся надежда на Intel, в программистов я не верю :-)

Думаю, тут только выход за пределы "1 железка на всё" спасти может - т.е. балансировщики перед стойкой для DPI. -- Best regards, Paul Arakelyan.

Привет! С прерываниями уже давно научились бороться: поллинг во Фре был ещё в конце 90-х AFAIR ;) Коме прерываний, DPDK помогает избежать переключений контекста (драйвера карт работают в userspace), экономит кэш блока управления памятью (используя hugepages) и предоставляет базовые библиотеки (от управления памятью до QoS). DPI пишут. Кстати, BIRD тоже пытаются интегрировать с VPP: https://wiki.fd.io/view/VPP_Sandbox/router Andriy

On 29 Jun 2016, at 14:11, Volodymyr Litovka wrote:

Для DPDK выделяется отдельный CPU core (или несколько), которые заняты опрашиванием сетевых карт на предмет новых данных. Это позволяет процессорам не отвлекаться на прерывания, что существенно упрощает жизнь системе "в целом".

Но DPI - в любом случае в тысячи раз более "тяжелая" задача, чем mac / ip-lookup :) Тут нужна предельная оптимизация кода, но, на самом деле, всё равно вся надежда на Intel, в программистов я не верю :-)

...

On 6/29/16 3:07 PM, Andrii Stesin wrote: Если мне не изменяет техническая интуиция, DPDK расшивает узкое "горлышко" архитектуры, а уж такие вещи как DPI etc. реализуются просто на процессоре(ах) в общей RAM без каких-то особых ухищрений, в N потоков, ...

2016-06-29 14:45 GMT+03:00 Volodymyr Litovka :

...

Свичинг - не вопрос. Даже ip routing уже почти не вопрос.

Вопрос - анализ и обработка пакетов. Например, vBNG (QoS, ACL, accounting) или DPI или whatever else выше простого ip lookup.

...

On 6/29/16 2:43 PM, Andrii Stesin wrote: Кстати быстрый свитчинг на интеле - вопрос уже очень недурно проработан, см. http://dpdk.org/ и что характерно http://openvswitch.org/ is the default switch in XenServer 6.0 в частности, и он на базе DPDK https://github.com/openvswitch/ovs/blob/master/FAQ.md

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

On Fri, May 27, 2016 at 11:34:02AM -0700, Igor Sviridov wrote:

hi, On Fri, May 27, 2016 at 05:36:58PM +0300, Volodymyr Litovka wrote:

...

честно говоря, я не вижу применения софт-BGP-раутерам кроме функции route reflector. Там, где нужно гонять трафик - там надо ставить маршрутизатор и не морочить себе голову вопросом "сколько pps можно выжать из x64". Нисколько. После "почитав как пашет ASA" - ну да, очень прикольно и непонятно как это сделать на "любой ОС", хотя жесть её настраивать не учившись это делать. (а куда деваться - так мы и не знаем, куда ж пропал нач.ДЦ., живой хотя бы или таки что-то случилось...) Удивительно другое - ведь решение "выделить память, влить туда таблицу, поменять указатель на новую таблицу" - простое как Ж, фигли его нет - непонятно. Или какой-нить Джунипер такое уже написал :).

Кстати, у меня аналогичная проблема с ipfw - спаморезка набирает кучу правил, при ребуте они сохраняются - это быстро, потом загружаются скриптом - и для 10+К правил - "это ппц".

Такие чудеса таки встречаются в production, даже в штатах (где цена времени админа часто выше цены железа), по крайней мере на гигабитных скоростях (слыхал, но не видел такие конфигурации с 10GigE).

Вопросы обычно с failover; а главная проблема - что с этим делать, когда автор решения перешел на другую работу.

нанять пашу аракеляна - для разбиралова "шо ж там понастроили, почему так и как жеж оно работает" :). -- Best regards, Paul Arakelyan.

On Sat, May 28, 2016 at 09:52:34AM +0300, Alexandr Baryshnyev wrote:

Доброго дня всем.

28.05.2016 8:53, Paul Arakelyan пишет:

...

Кстати, у меня аналогичная проблема с ipfw - спаморезка набирает кучу правил, при ребуте они сохраняются - это быстро, потом загружаются скриптом - и для 10+К правил - "это ппц".

Извините, если глупость спрошу, да и не по теме, но так, на всякий случай. Вы каждое правило добавляете в скрипте отдельным вызовом ipfw или одним вызовом ipfw вливаете весь пакет правил? В первом случае - да: ужос-ужос. Но во втором довольно шустро влетает.

Да оно вроде как в любом случае "не очень быстро": LIST OF RULES AND PREPROCESSING To ease configuration, rules can be put into a file which is processed using ipfw as shown in the last synopsis line. An absolute pathname must be used. The file will be read line by line and applied as arguments to the ipfw utility. Экономия на запуске ipfw - существенно, но всё же никаких "хитрых трюков" оно не делает time ipfw -nq /ZS3/smtpp/ipfw/fww2 7.072u 0.485s 0:07.90 95.5% wc -l fww2 2550 fww2 Так что "в былые времена", когда спама было больше - это десятки секунд, что колоссально отличается от "мгновенно список в файл закинуть и посчитать md5" (чтоб не получилось, что будем пытаться загрузить битый файл). Впрочем, это только при перезагрузке - в отличие от сохранения каждые несколько минут. -- Best regards, Paul Arakelyan.

On Sat, May 28, 2016 at 11:45:59AM +0300, Konstantin Belousov wrote:

On Sat, May 28, 2016 at 11:30:35AM +0300, Paul Arakelyan wrote:

...

Да оно вроде как в любом случае "не очень быстро": LIST OF RULES AND PREPROCESSING To ease configuration, rules can be put into a file which is processed using ipfw as shown in the last synopsis line. An absolute pathname must be used. The file will be read line by line and applied as arguments to the ipfw utility. Экономия на запуске ipfw - существенно, но всё же никаких "хитрых трюков" оно не делает time ipfw -nq /ZS3/smtpp/ipfw/fww2 7.072u 0.485s 0:07.90 95.5% И все, или большинство, правил одинаковые, только адреса отличаются ? Такое делается таблицей с 2.5K хостов, а не 2.5K правил. Таблицы и грузятся быстрее, и существенно меньше едят время CPU. Номера критичны - хосты попадают в правило с номером, являющимся функцией от времени и продолжительности, и удаляются соответственно правила по номеру - т.е. я не держу таблиц "кого засунул" в памяти, это ОС делает. Соответственно - между писать ещё кучу кода или использовать готовый механизм - ответ очевиден :).

-- Best regards, Paul Arakelyan.

On Sat, May 28, 2016 at 01:28:58PM +0300, George L. Yermulnik wrote:

Hello!

On Sat, 28 May 2016 at 12:14:14 (+0300), Paul Arakelyan wrote:

...

...

И все, или большинство, правил одинаковые, только адреса отличаются ? Такое делается таблицей с 2.5K хостов, а не 2.5K правил. Таблицы и грузятся быстрее, и существенно меньше едят время CPU. Номера критичны - хосты попадают в правило с номером, являющимся функцией от времени и продолжительности, и удаляются соответственно правила по номеру - т.е. я не держу таблиц "кого засунул" в памяти, это ОС делает.

В таблицах ipfw каждой записи можно давать значение. И значение это можно использовать в других правилах. Либо парсить листинг таблицы и в зависимости от значения удалять записи. [957] 2004-03-07 14:32:40 Start smtpshield daemon [957] 2004-03-07 14:32:40 config - port: 193.124.54.51:25 -> 193.124.54.50:25 [957] 2004-03-07 14:32:40 config - port: 193.124.54.54:25 -> 10.9.8.7:25 [957] 2004-03-07 14:32:40 configured. Таблиц тогда ещё не очень было (они появились на несколько месяцев позже), зато был вагон спама и legacy-софта, типа uucp, который продолжала ещё долго использоваться и содержал кучу "интересностей", которые и закрывала эта штука.

-rw-r--r-- 1 unisol wheel 4752 Mar 25 2005 addfw.c -rw-r--r-- 1 unisol wheel 10794 Mar 25 2005 bllookup.c -rw-r--r-- 1 unisol wheel 1871 Mar 25 2005 expired.c -rw-r--r-- 1 unisol wheel 6534 Apr 22 2004 keytbl.c lrwxr-xr-x 1 root wheel 16 Sep 1 2013 proxy.c -> proxy.c.nofilter -rw-r--r-- 1 root wheel 52870 Apr 18 2008 proxy.c.nofilter -rw-r--r-- 1 unisol wheel 16495 Feb 15 2004 proxy.c.nofilter.v1 Вот как оно работает (писалось в 2004г, и поглядев в код с хитрожопой математикой я только могу сказать, что там более 3К номеров правил и время меряется "попугаями", а не минутами): прилетел спам с IP1 в 10:00 - создаём правило 1000 deny from IP1 setup прилетел спам с IP1 в 10:01 - создаём правило 1001 deny from IP1 setup (допустим, оно начало влетать раньше, чем появилось правило 1000) прилетел спам с IP2 в 10:15 - создаём правило 1015 deny from IP2 setup в 10:15 удаляем правила с номером 1000, в 10:16 снова создаются правила начиная с 1000. Такая политика, вкупе с "торможением" адресов в RBL очень мешает спамить и "умные спамеры" могут просто выбрасывать такие адреса из списков. Соответственно есть несколько таких закольцованных наборов правил = или понадобится несколько тысяч таблиц и грохать таблицы целиком (отдельно блочатся хосты на бОльшие временные промежутки - net.inet.ip.fw.tables_max: 128 наверно не просто так и что будет при 3000 вместо 128 - не знаю) или мучаться с ipfw table number delete addr - затратно, т.к. удалять нужно кучу адресов, у которых value, т.е. понадобится писать парсилку таблицы=затраты проца и вообще взаимодействовать с структурами ядра напрямую, иначе просто северный лис или держать в памяти все заблоченные адреса с таймаутами - т.е. притопать к модели с БД. Всё же сваять софтину, делающую что-то из разряда system("/sbin/ipfw add 1000") и ещё одну, удаляющую кучу правил по номеру sprintf (buf, "/sbin/ipfw -q -f delete %d %d %d %d %d", 1000+modint(nowtm, 21), 2000+modint(nowtm, 31), 3000+modint(nowtm, 46), 4000+modint(nowtm, 999), 5000+modint(nowtm, 2999)); было несоизмеримо проще. Чтоб уехать на таблицы или вообще другую ОС/фаервол - нужно переписать добавлялку и удалялку :). Всё же задача была сваять спаморезку, умеющую взаимодействовать с SA/clamd/чем-то ещё, а не уйти с головой в системное программирование. Плюс вопрос насколько это бы надёжно работало - добавить-удалить правило - это было написано "чуть не изначально", а таблицами только в середине 2004 начали ворочать и хз как оно себя повело бы при хроническом "добавили-удалили", вариант "шото крэшнулось бы" не подходил совсем - это ж не отдельный сервер с такой задачей, там ещё куча всего... -- Best regards, Paul Arakelyan.

Привет Володя! “Опорные маршрутизаторы” такой же товар как и все остальное и к ним тоже применяется теория “спроса-предложения” т.е. они стоят “дорого” потому что на рынке БЫЛ баланс спроса и предложения: у покупателей не было альтернативы (нет маршрутизаторов - сервис провайдер не работает), а продавцы не заинтересованы в снижении цены (зачем снижать если и как покупают) Но появляется все больше и больше компаний, которые задают вопрос: действительно ли нужно платить 500,000 USD за железо и софт https://labs.spotify.com/2016/01/26/sdn-internet-router-part-1/ ? В текущем варианте: “мы можем написать софт и железо почти работает” https://labs.spotify.com/2016/01/27/sdn-internet-router-part-2/ . Вроде бы "все по старому", но ребята из Spotify не ищут “где купить дешевый раутер-свитч” они ищут где купить “железо которое сможет full view”, а все остально они сделают сами. В таком мире, софт из 80х не нужен; и TAC на сотни/тысячи людей тоже не нужен; и “сертифицированные специалисты” с двумя прочитанными книгами тоже не нужны; и очень многое из тоже что сейчас поставляют вендоры тоже будет не нужно. P.S. Кстати, железо уже есть http://www.cavium.com/XPliant-Ethernet-Switch-Product-Family.html просто оно еще не запаковано в обертку для mass-market как например вот этот http://whiteboxswitch.com/products/edge-core-as6701-32x Максим

On 27 May 2016, at 16:36, Volodymyr Litovka wrote:

современным процам переварить 5 full view - понты, гораздо дольше занимает инсталлиция маршрутов в FIB

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

честно говоря, я не вижу применения софт-BGP-раутерам кроме функции route reflector. Там, где нужно гонять трафик - там надо ставить маршрутизатор и не морочить себе голову вопросом "сколько pps можно выжать из x64". Нисколько.

On 5/27/16 5:21 PM, Paul Arakelyan wrote:

...

Я бы перефразировал вопрос в сторону "за сколько времени оно пережуёт 2 фуллвью? 3? 4? помогут ли тучаядер или нужен жидкий азот и разгон", т.к. именно "квагга долго раздупляется" явилось для нас причиной отказа от фулл-вью в своё время. А собственно от ОС зависят PPS и скорость изменения маршрутов в ядре - странно, что нету апи "впендюрить этот кусок памяти в ядро в качестве таблицы маршрутизации", а есть "добавить-удалить 1 маршрут" и так 100500 раз - "это не может быть вкусно"(с)ЮТ про белковый коктейль с утра.

On Fri, May 27, 2016 at 03:59:10PM +0300, Vladimir Sharun wrote:

...

Спасибо,

Вернемся к первому вопросу: опыт использования, pps reached/sustained и negatives.

--- Оригінальне повідомлення --- Від кого: "Oleksandr V. Typlyns'kyi" mailto:astral@wangsamp.km.ua Дата: 27 травня 2016, 15:56:28

Today May 27, 2016 at 15:41 Vladimir Sharun wrote:

...

Привет,

Обычно не на смарт-часах bird пускают и не только для "а вот смотрите детки, как комьюнити делается". Бывает, что и роутят. И есть отличное от нуля кол-во компаний, которые используют х64 сервера как роутеры в мире. Потому я и спросил ""Оно" - это кто?", ведь на х64 серверах "отличное от нуля кол-во" ОС и "отличное от нуля кол-во" железа. Там два весомых момента - пропускание через себя пакетов и поиск куда их отправлять по таблице. Напрямую в обоих Quagga/OpenBGPD/BIRD не участвуют. Косвенно могут мешать локами при перестройке, но даже это в большей степени зависит от реализации в ядре.

-- WNGS-RIPE

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

"IPv4/IPv6 Routes 20k/64k" - это Broadcom Trident II или Cavium Xpliant ? Максим

On 29 May 2016, at 22:59, Igor Sviridov wrote:

...

P.S. Кстати, железо уже есть http://www.cavium.com/XPliant-Ethernet-Switch-Product-Family.html http://www.cavium.com/XPliant-Ethernet-Switch-Product-Family.html просто оно еще не запаковано в обертку для mass-market как например вот этот http://whiteboxswitch.com/products/edge-core-as6701-32x http://whiteboxswitch.com/products/edge-core-as6701-32x

Мне кажется, что это все еще не железка для 5 full BGP feed's: | IPv4/IPv6 Routes 20k/64k

...

Максим

--igor

Привет!

Мне кажется, что это все еще не железка для 5 full BGP feed's: | IPv4/IPv6 Routes 20k/64k

Для БГП у Кавиума есть ТандерИкс - 64 битный АРМ с сетевым процессором на борту. У нас в лабе есть такой с парами 10 и 40 гиговых интерфейсов, кучей памяти и 96 ядрами. Каждое ядро спокойно несколько миллионов ППС делает в рутинге даже без аппаратной акселерации. Так что железо есть, софт подтягивается, скоро будет счастье ;) Андрей

Привет!

Хмм, любопытно - только цен пока не найти.

По ценам, к сожалению, не сориентирую - у нас девборды. Мы под тандеры допиливаем датаплейны (дпдк и одп) и фрю: https://community.arm.com/groups/processors/blog/2015/11/03/semihalfs-arm64-... Андрей

Макс, привет согласен с тем, что ты говоришь - тренд налицо и заключается он в переходе на merchant silicon, COTS hardware и внешнее управление. Я всего лишь говорю, что на сегодня основная проблема заключается не столько в traffic switching, сколько в traffic processing :) оффлоад Ethernet и TCP/IP в чипы уже не rocket science, но обработка пакетов на уровнях немножко выше пока что делается либо на general purpose CPU, либо на специализированных NPU. В первом случае имеем performance degradation, во втором случае - пока что высокая стоимость решения. Например, Cisco vBNG на двух ядрах показывает производительность около 5Gbps на усредненном размере пакета в режиме IPoE, а в режиме PPPoE - в два раза ниже. Если приложить QoS (marking / policing), то производительность тоже падает соответственно. Та же история - с firewall / IPS. Еще хуже - с IPSec. Что до опорных маршрутизаторов, то здесь есть два нюанса: 1) скорость пересчета таблицы маршрутизации в случае изменения топологии. Я не про "один апдейт пришел от одного из пиров" и сделали одиночное изменение в FIB, а про "отвалился peer" и нужно сделать массовый пересчет таблицы. Впрочем, это - чисто софтовый механизм, он может быть реализован на внешнем контроллере и, в принципе, не космически сложен... если не брать во внимание топологии оптической сети снизу (во избежание образования Shared Link Risk Group) и оверлейной топологии (MPLS TE, например) сверху :) 2) физическое обновление FIB - на всех линейных картах, с автоматическим апдейтом всей остальной информации про коммутацию пакетов, с минимальным простоем форвардинга. Можно еще добавить пункт обновление микрокода на линейных картах в случае обновления софта на маршрутизаторе - архитектура маршрутизатора должна поддерживать две копии микрокода :) На сегодняшний момент стоимость опорного маршрутизатора складывается из обоих пунктов, причем я не уверен, какой из них добавляет больше денег в стоимость. Понятно, что в этом может не быть необходимости - защиту можно делать на оптическом уровне, на простой в несколько секунд можно тупо забивать, апдейтить софт раз в год в течении 30-минутного maintenance window и т.д., но когда ты говоришь про "опорный маршрутизатор за $500k", то подразумеваешь, наверное, именно тот, который mission critical, для Tier-1 с мульти-терабитной пропускной полосой. Вот как раз такому в ближайшее время замены не предвидится, а предвидится только некоторое уменьшение стоимости владения (TCO). Еще раз - я не против использования general purpose platforms для сетевых функций, нужно просто соотносить их возможности и ограничения с требованиями и правилами, установленными оператором на данной сети. On 5/29/16 11:24 PM, Maksym Tulyuk wrote:

Привет Володя!

“Опорные маршрутизаторы” такой же товар как и все остальное и к ним тоже применяется теория “спроса-предложения” т.е. они стоят “дорого” потому что на рынке БЫЛ баланс спроса и предложения: у покупателей не было альтернативы (нет маршрутизаторов - сервис провайдер не работает), а продавцы не заинтересованы в снижении цены (зачем снижать если и как покупают)

Но появляется все больше и больше компаний, которые задают вопрос: действительно ли нужно платить 500,000 USD за железо и софт https://labs.spotify.com/2016/01/26/sdn-internet-router-part-1/ ? В текущем варианте: “мы можем написать софт и железо почти работает” https://labs.spotify.com/2016/01/27/sdn-internet-router-part-2/ . Вроде бы "все по старому", но ребята из Spotify не ищут “где купить дешевый раутер-свитч” они ищут где купить “железо которое сможет full view”, а все остально они сделают сами.

В таком мире, софт из 80х не нужен; и TAC на сотни/тысячи людей тоже не нужен; и “сертифицированные специалисты” с двумя прочитанными книгами тоже не нужны; и очень многое из тоже что сейчас поставляют вендоры тоже будет не нужно.

P.S. Кстати, железо уже есть http://www.cavium.com/XPliant-Ethernet-Switch-Product-Family.html просто оно еще не запаковано в обертку для mass-market как например вот этот http://whiteboxswitch.com/products/edge-core-as6701-32x

Максим

...

On 27 May 2016, at 16:36, Volodymyr Litovka mailto:doka.ua@gmail.com> wrote:

современным процам переварить 5 full view - понты, гораздо дольше занимает инсталлиция маршрутов в FIB

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

честно говоря, я не вижу применения софт-BGP-раутерам кроме функции route reflector. Там, где нужно гонять трафик - там надо ставить маршрутизатор и не морочить себе голову вопросом "сколько pps можно выжать из x64". Нисколько.

On 5/27/16 5:21 PM, Paul Arakelyan wrote:

...

Я бы перефразировал вопрос в сторону "за сколько времени оно пережуёт 2 фуллвью? 3? 4? помогут ли тучаядер или нужен жидкий азот и разгон", т.к. именно "квагга долго раздупляется" явилось для нас причиной отказа от фулл-вью в своё время. А собственно от ОС зависят PPS и скорость изменения маршрутов в ядре - странно, что нету апи "впендюрить этот кусок памяти в ядро в качестве таблицы маршрутизации", а есть "добавить-удалить 1 маршрут" и так 100500 раз - "это не может быть вкусно"(с)ЮТ про белковый коктейль с утра.

On Fri, May 27, 2016 at 03:59:10PM +0300, Vladimir Sharun wrote:

...

Спасибо,

Вернемся к первому вопросу: опыт использования, pps reached/sustained и negatives.

--- Оригінальне повідомлення --- Від кого: "Oleksandr V. Typlyns'kyi" Дата: 27 травня 2016, 15:56:28

Today May 27, 2016 at 15:41 Vladimir Sharun wrote:

...

Привет,

Обычно не на смарт-часах bird пускают и не только для "а вот смотрите детки, как комьюнити делается". Бывает, что и роутят. И есть отличное от нуля кол-во компаний, которые используют х64 сервера как роутеры в мире. Потому я и спросил ""Оно" - это кто?", ведь на х64 серверах "отличное от нуля кол-во" ОС и "отличное от нуля кол-во" железа. Там два весомых момента - пропускание через себя пакетов и поиск куда их отправлять по таблице. Напрямую в обоих Quagga/OpenBGPD/BIRD не участвуют. Косвенно могут мешать локами при перестройке, но даже это в большей степени зависит от реализации в ядре.

-- WNGS-RIPE

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

Привет, Роутить исходящий трафик например . Это не запрещено. 27 травня 2016, 15:05:44, від "Volodymyr Litovka" < doka.ua@gmail.com >: А зачем? On 5/27/16 1:40 PM, Vladimir Sharun wrote: Всем привет, А сколько оно может (без файрвола) выдать мегапакетов например с 2-3 full view ? --- Оригінальне повідомлення --- Від кого: "Gregory Edigarov" Дата: 27 травня 2016, 12:02:15 On 27.05.16 11:55, Maksym Tulyuk wrote:

Привет!

А какие нюансы?

Из личного опыта: - Quagga - большие проблемы с маштабированием из-за single-thread кода 20летней давности; разработчики много раз обещали поправить (последний раз на райповке в 2012), но результата пока нет (в 2015 опять собирали деньги на новый BGPd) согласен. - OpenBGPd - работает но медленно на больших BGP таблицах или при большом кол-ве сессий; разработка почти остановилась; разработчики отвечают “по настроению” не соглашусь. да, были проблемы, но в Опенке сейчас обновленная версия, с большими улучшениями механизма фильтрации. - BIRD - хорошо работает и разработчики регулярно исправляют глюки угу, только настройка достаточно эзотерична, и порой требует заглядывания в исходники, чтобы понять, что же разрабы этим хотели сказать.

-- With best regards, Gregory Edigarov -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

Про OpenBGPd согласен - полгода назад обновили код; сюда по отзывам должно быть легче Про конфигурацию BIRD - да, вначале конфигурация выглядит странно, но потом привыкаешь :) Максим

On 27 May 2016, at 11:01, Gregory Edigarov wrote:

On 27.05.16 11:55, Maksym Tulyuk wrote:

...

Привет!

А какие нюансы?

Из личного опыта: - Quagga - большие проблемы с маштабированием из-за single-thread кода 20летней давности; разработчики много раз обещали поправить (последний раз на райповке в 2012), но результата пока нет (в 2015 опять собирали деньги на новый BGPd) согласен. - OpenBGPd - работает но медленно на больших BGP таблицах или при большом кол-ве сессий; разработка почти остановилась; разработчики отвечают “по настроению” не соглашусь. да, были проблемы, но в Опенке сейчас обновленная версия, с большими улучшениями механизма фильтрации. - BIRD - хорошо работает и разработчики регулярно исправляют глюки угу, только настройка достаточно эзотерична, и порой требует заглядывания в исходники, чтобы понять, что же разрабы этим хотели сказать.

-- With best regards, Gregory Edigarov