Кстати, могу предложить наш открытый софт по детекированию атак: github.com/FastVPSEestiOu/fastnetmon К сожалению, отбивать их пока не умеет, но известит и сделает отпечаток атаки оперативно :)
А как собрать? Мне вот интересен транспорт по netlink из доверенной машины до ВПСок на ноде. Где взять модули под это дело и насколько это оттестировано?
Ну это ясно-понятно, но кто-то из клиентов Билайна может это сделать и расшарить сообществу =)
Это крайне плохо, пиариться «мы сделали такой крутой роутер», а на деле — на 99% все это сделало сообщество Linux, про которое почему-то никто не упомянул, ни разу, это плохо.
Самое интересное. Друзья, в основе прошивки ведь Linux? А Вы ведь оптимизировали работу L2TP. Будут ли патчи в ядро или у себя в анналах сокроете нарушив GPL?
В надежном железе за кучу денег не должно быть черных ящиков, это мантра, которую нужно повторять бесконечно. Если сами инженеры, которые разработали это железо, не могут разобраться не собрав митинг, то Вы правда спите спокойно имея эту железку в продакшене? Вам правда спокойно спится, когда Вы ничего не понимаете о том, как работает Ваше железо в ядре огромной (да даже малой) сети? А в open source есть огромный пласт документации и в конце-концов кода, который можно изучить (вовсе не обязательно вычитывать весь, для понимания работы стека IP того же линукса достаточно прочесть 20-30 файлов исходников и хорошую книгу класса TCP/IP implementation). И после этого для Вас не останется «черных пятен».
Ну и опять же, «а что если криво запрограммирован TCAM» — cumulus заявляя работу с конкретной железкой четко обозначает, что это в его сфере интересов, поэтому по этой задаче — писать им. А решение вопроса с вендором — уже их дело. Кроме этого, не стоит забывать, что у Cumulus очень прочные связи со всеми вендорами железа, на котором они работают и поэтому это не тоже самое что «воткнуть на неизвестное железо». Если они пишут «мы работаем на вот этом чипе», то значит они отдают отчет, что их будут долбать любым багом.
Если для штатной операции обновления железки нужно три инженера TAC, то стало быть пора эту железку отправить на свалку. Вы говорите что «опенсорц софт и отдельное железо ненадежно и не найдешь концов», а при этом приводите пример, когда для типовой операции разве что технического директора в TAC не притащили =)
Вы давно с реальным саппортом какого-либо софта или железа работали? :) Dell, HP? Juniper?
Вы своим клиентам тоже самое скажете? Ой, извините милые 100500 коммерческих клиентов, Вы знаете, у нас тут был договорчик с одним очень крупным вендором (очень надежным!), там было указано решение проблемы за сутки, а вот уже неделя, у нас и у Вас все лежит. Но Вы не сердитесь на нас, ведь вендор обещал решение за сутки. Верьте ему и говорите вашим разгневанным кастомерам тоже самое.
Решать надо конкретные проблемы, а не коней в вакууме. Ровно с той же проблемой можно столкнуться на любой другой аппаратной платформе и бесконечное число времени ждать ответа саппорта.
Не сделает, по крайне мере в ближайшие лет несколько, в 10GE очень сложная схемотехника и ресиверы/транзмиттеры для него может делать дааааааалеко не любая контора, как это было с 1GE.
Если связана с железом — то к производителю железа, если с софтом — к производителю софта. По-моему весьма очевидно, нет? Фичи, которые свич делает в железе, на коммутационной матрице перечислены, например, здесь: cumulusnetworks.com/media/cumulus/pdf/misc/10G-Quick-Reference-Guide-2.5.pdf это производительность матрицы, число MAC адресов, число VLAN, число LPM префиксов, размер буфера, число vxvlan, число QoS правил и их вид, ACL правила.
Все что кроме этого — OSPF, BGP, LACP, MLAG (multy chassy aggregation), bonding — это все вопросы к data pane, а именно к управляющей системе, а моем примере — это Cumulus, который является весьма надежной компанией, с которой Вы заключаете договора и от которой получаете поддержку. С вендором, который сделал саму железку, будь то Dell или HP у Вас также договор и если что-то не так в железе — Вам обязаны это поправить в том или ином виде.
Мало того, если глюк специфичен и его никто не хочет чинить. Могу привести пример целой серии «багов», которые Cisco, Juniper, Extreme, D-Link багами не считают и чинить не хотят, никак, вообще, ни за миллион ни за миллиард!
И тут врубается супер подход Cumulus, что у него открытый код и открытые SDK, можно взять и починить, вот так. Либо патчик найти либо к сторонним спецам сходить. Кто из хваленых вендоров может так? Да никто. Вот и преимущества.
А еще лучше использовать крутые модерновые решения класса — железо свича отдельно, а софт отдельно. Кто из вендоров может предоставить свич о 48 портах 10GE за $ 4000 как здесь bm-switch.com/index.php/bare-metal-switches/10g-bare-metal-switches/quanta-ly2r.html? А если еще добавить, что на это решение ставится Cumulus Linux, который интегрируется в Linux инфраструктуру на раз и стоит от $1000 и умеет все, что только можно из миров L2 и L3, то вообще становится страшно за всех этих Cisco, Junuper, Netgear и компания. А вот HP и Dell отлично подсуетились и сделали свичи в партнерстве с софтом Cumulus! Ура, товарищи! Идем к светлому будущему почти без кривого проприетарного софта по крайне мере на свичах. Ура!
Спасибо за развернутый ответ! Очень интересная информация! На самом деле долго думал — неужели нету надежной реализации такой популярной и очень полезное структуры как map.Получается, аналогов CDS толком-то и нету. Обязательно попробую вашу библиотеку для своего проекта.
Это крайне плохо, пиариться «мы сделали такой крутой роутер», а на деле — на 99% все это сделало сообщество Linux, про которое почему-то никто не упомянул, ни разу, это плохо.
Ну и опять же, «а что если криво запрограммирован TCAM» — cumulus заявляя работу с конкретной железкой четко обозначает, что это в его сфере интересов, поэтому по этой задаче — писать им. А решение вопроса с вендором — уже их дело. Кроме этого, не стоит забывать, что у Cumulus очень прочные связи со всеми вендорами железа, на котором они работают и поэтому это не тоже самое что «воткнуть на неизвестное железо». Если они пишут «мы работаем на вот этом чипе», то значит они отдают отчет, что их будут долбать любым багом.
Как говорится, попробуйте и втянетесь :)
Вы своим клиентам тоже самое скажете? Ой, извините милые 100500 коммерческих клиентов, Вы знаете, у нас тут был договорчик с одним очень крупным вендором (очень надежным!), там было указано решение проблемы за сутки, а вот уже неделя, у нас и у Вас все лежит. Но Вы не сердитесь на нас, ведь вендор обещал решение за сутки. Верьте ему и говорите вашим разгневанным кастомерам тоже самое.
Все что кроме этого — OSPF, BGP, LACP, MLAG (multy chassy aggregation), bonding — это все вопросы к data pane, а именно к управляющей системе, а моем примере — это Cumulus, который является весьма надежной компанией, с которой Вы заключаете договора и от которой получаете поддержку. С вендором, который сделал саму железку, будь то Dell или HP у Вас также договор и если что-то не так в железе — Вам обязаны это поправить в том или ином виде.
Мало того, если глюк специфичен и его никто не хочет чинить. Могу привести пример целой серии «багов», которые Cisco, Juniper, Extreme, D-Link багами не считают и чинить не хотят, никак, вообще, ни за миллион ни за миллиард!
И тут врубается супер подход Cumulus, что у него открытый код и открытые SDK, можно взять и починить, вот так. Либо патчик найти либо к сторонним спецам сходить. Кто из хваленых вендоров может так? Да никто. Вот и преимущества.
Читаю вашу серию с самого начала, пока дошел до RCU, очень много полезной информации, чтобы усвоить ее нужно время. Спасибо за Ваш труд!
Попутно возник вопрос, а что Вы думаете про Thread Building Blocks от Intel? На первый взгляд выглядит замечательно просто.