Pull to refresh

Comments 91

Спасибо. Коротко, ясно и понятно. Новичкам можно посоветовать почитать статью. А то некоторые думают, что многомодовый кабель — это кабель с несколькими оптическими модулями.
По поводу 100м на 10GBase-T. Необходимо понимать, что категория кабеля должна быть не менее 6a, это важно. Даже на простой шестёрке расстояние будет куда скромнее. Может быть, имеет смысл добавить это в таблицу.
В целом экскурс достаточно полезен. Но 40G уже наступает на пятки, особенно в ЦОДах, во взрослых решениях оно используется уже во все поля.
Насчет 10GBase-T — полностью согласен. Вообще надо иметь в виду что любые тут приведенные цифры расстояний — сферические и в вакууме, и к оптике это относится даже больше, чем к меди, поскольку там еще приходится учитывать большой разброс характеристик модулей среды.
Насчет 40G — есть мнение, что он так и останется в ЦОДах. По своей природе стандарт был промежуточным и далее развивать его нет смысла. Пока порт 40G сильно дешевле 100G — их будут использовать там, где сильно надо, потом они постепенно сойдут на нет.
Про сферического коня в вакууме знаю, сам как-то объяснял это заказчику, когда для того, чтобы пройти 9.5км я закладывал модули ER, потому что по затуханиям из-за огромного количества транзитных патч-панелей мы не пролезали.
Про 40G да, я тоже думаю, что это обречённая штука, но как временное решение отлично себя проявившая.
В этой статье рассматривается подключение серверов к свитчам. А вот аплинки самих свитчей до ядра уже можно делать 40G/100G.

Зачем одиночному серверу 40G? Он и гигабит-то редко когда займет.
Сервера бывают разные, знаете ли, и решают они самые разные задачи. Например, роутеринг, DPI. Не знаю, насколько далеко шагнуло процессоростроение, но если шагнуло хорошо, то и для 40G это всё будет применимо.
«роутеринг, DPI» мне ни о чем не говорят, но да, можно еще рендер-фермы вспомнить. Я все-таки говорю о наиболее типичных случаях. А сейчас типично 1G до сервера и 10G на аплинк.
В рот мне ноги, роутеринг… Роутинг, разумеется, пардон. Но сути дела это не меняет, такие приложения есть.
Никто, никогда не поставит софтовую железку под роутинг, когда речь идет о гигабитах.
Про яндекс слышали? Узнайте как-нибудь на досуге, что у них в качестве роутеров в ядре используется и сколько девелоперов у них в штате это всё саппортит и допиливает.
В ядре тем более никогда софтовые железки не используют. Ставятся L3 свитчи, осиливающие сотни/тысячи/более гигабит в секунду роутинга.
Предлагаю на этом дискуссию закончить. Я сказал, в каком направлении копать.
На будущее — в текущем ряде маршрутизаторов Cisco всё, что ниже 7600 — это софтовые девайсы, не имеющие специализированных NPU.
Или речь шла про SDN? Но это тоже далеко не софтовый роутинг. Пакетики-то ASICами пересылаются.
Мне кажется, у нас разговор не в ту степь пошёл.
Ещё раз — просветитесь, на чём у яндекса роутеры всю жизнь работали. В свободном доступе информации, увы, нет, но если у вас есть знакомые в соответствующих кругах, то поспрашивайте, будете удивлены. Если коротко, то там нечто сугубо самописное и очень производительное.
Если коротко, то там нечто сугубо самописное и очень производительное.

Вас, видимо, кто-то обманул, либо Вы не поняли сказанное.

«Ядро сети» — по определению довольно безмозглые пакетодробилки. От них не требуется какого-либо инспектирования. Но они должны обеспечить высокую скорость передачи данных с минимальными задержками (единицы микросекунд), ну и иметь кучу портов. Ни одно программное решение по определению под такое не годится.
Так что советую переспросить знакомых, точно ли у них аплинки с коммутаторов уровня доступа сходятся на серверах :)

Ну а если они заказывают у кого-нибудь нормальные железки с нормальными ASICами и лишь пишут под них control plane — другой разговор. Но это не софтовый роутинг.
Моей ошбикой было использовать слово «ядро», прошу прощения. Я имел в виду бордеры, а также PE-коробки. Использую рядовые сервера с вполне себе обычными процессорами, никаких выделенных NPU или PPE, всё на CPU роутится. По поводу мощности CPU могу сказать следующее — двух Xeon L5638 хватает, чтобы перелопатить 10gbps в фуллдуплексе, и сделать это интеллектуально, со всякими шейперами, и прочими прелестями. Ежедневно работаю с девайсами, построенными на этих камнях.

По поводу безмозглых пакетодробилок уже не согласен. Товарищ salium умело аргументировал тут habrahabr.ru/company/senetsy/blog/114887/#comment_4662903
Я имел в виду бордеры, а также PE-коробки.

А вот это уже другой разговор.
двух Xeon L5638 хватает, чтобы перелопатить 10gbps в фуллдуплексе

Скучный вторник для ASAшек. 5585X потянет это еще и с IPS инспектированием. По сравнению с этим исходящий шейпер — мелочь, недостойная внимания.
Товарищ salium умело аргументировал тут

Товарищ аргументировал про сильно операторскую сеть, и хочет много чего явно лишнего.
Я не вижу смысла в ядре заглядывать настолько глубоко в пакет ради идеального распараллеливания трафика. Что до базового FRR (как с MPLS, так и без) — все умеют это делать.
Когда я говорил про ксеоны, я имел в виду достаточно мощный DPI девайс, исполняющий нечто куда сложнее, чем IPS. Указано это было для примера того, для чего можно использовать софтовые коробки, и зачем на них могут понадобиться 40G дырки. Но, как обычно в интернетах, всё свелось к полемике, мы забыли с чего всё началось.
«я имел в виду достаточно мощный DPI девайс, исполняющий нечто куда сложнее, чем IPS»
Любопытства ради — чем же он там таким сложным занимается?

mikelococo.com/2011/08/snort-capacity-planning/
One or two links 1-10Gbit/sec – You definitely need multi-snort with high-performance capture hardware. I’m partial to Endace, but pfring with a 10G TNAPI-compatible card should also work. You need 1-core and 4Gbytes of ram for every 250Mbits/sec of traffic that you need to inspect. Alternatively, consider a Sourcefire system. If you’re just getting started with Snort this is going to be a big project to do on your own.

Many links or greater than 10Gbit/sec traffic – Try to break the problem down into multiple instances of the above cases. A Gigamon box at each site may give you the flexibility that you need to split the problem across multiple servers effectively. You also might also need a moderately high-performance database server, properly tuned and sized.


В упомянутой Вами системе говорится про 10гб/с инспектирования (я правильно понимаю, что под «full duplex» имеется в виду, что обработанный трафик покидает коробку через тот же шнурок?), и при этом справляются 12 ядер. Хотя тот же Snort обещает загнуться при таких условиях, или как минимум работать на пределе. Странно как-то…
чем же он там таким сложным занимается?
Глубокий анализ всех проходящих пакетов с разбивкой по приложениям (HTTP, Skype, Bittorrent, Streaming Media, RTP и т.д. более полутора тысяч сигнатур). Можно собирать статистику, делать шейпинг per-application per-subscriber, собирать разные интересные логи по абонентским сессиям, сливать трафик наружу для ребят в погонах, для работы VAS и т.д., дофига чего интересного можно сделать.

Под FDX я имел в виду следующее. Есть два сетевых устройства (роутера, свитча, фаервола, неважно), между ними висит 10G линк. DPI включается в разрыв этого линка, т.е. он имеет два интерфейса, по одному в сторону каждого из устройств. 10G FDX означает, что девайс перелопатит трафик даже в том случае, если каждое из устройств будет генерить его с битрейтом 10Gbps. С точки зрения сетевых устройств DPI — штука совершенно прозрачная на L2.

По поводу 12 ядер — всё дело в вылизанности продукта под конкретную задачу и специфику железа. Если софт заточен под конкретный процессор, это одна оптимизация. Если же он заточен под целое семейство процессоров, то это совсем другая песня. На упомянутом мной девайсе (а на самом деле это по сути своей блэйд, коих может быть несколько штук) помимо ксеонов стоит 48 гиг RAM. Стоит такой модуль вместе с лицензией $150k. Сколько стоит ваш снорт?
Глубокий анализ всех проходящих пакетов с разбивкой по приложениям
То есть тот же NBAR на цискиных роутерах, с прикрученным netflow. А он ЗНАЧИТЕЛЬНО быстрее IPSа.
10G FDX означает, что девайс перелопатит трафик даже в том случае, если каждое из устройств будет генерить его с битрейтом 10Gbps.
То есть тем более данная реализация DPI значительно проще, чем IPS (кстати — тоже подвид DPI).
Стоит такой модуль вместе с лицензией $150k. Сколько стоит ваш снорт?
Снорт бесплатен, и вроде его можно скомпилировать под каждый процессор. Это и есть «заточка».
Готовый апплайанс на снорте? Например, есть Sourcefire. Точные расценки на анализ 10G не назову, но он значительно дешевле.
Даже Cisco ASR1000 «Flexible Packet Inspection Bundles» под 20гб/с стоят от $75к до $100к (это по GPL, т.е. смело вычитаем минимум 30%). Да, даже более примитивный роутерный NBAR легко отличит различит HTTPS, skype и торренты.
То есть тот же NBAR на цискиных роутерах, с прикрученным netflow. А он ЗНАЧИТЕЛЬНО быстрее IPSа.
NBAR. Удивлён, что эта унылость ещё жива, думал загнётся. Если вам будет так угодно, то да, это типа NBAR. Оно умеет по Netflow отдавать статистику по каждому приложению? А интегрироваться с биллингом будет? Если это ASR1k, тогда ок, поверю, что да, вроде как BRAS пытаются изобразить из него.

То есть тем более данная реализация DPI значительно проще, чем IPS
В чём если не секрет? Какую задержку вносит IPS?

Снорт бесплатен
И как мне это ставить в проекте масштабов страны? Как оно будет саппортиться?

Да, даже более примитивный роутерный NBAR легко отличит различит HTTPS, skype и торренты.
Ну-ну, сами-то проверяли на сложных протоколах, таких как skype и шифрованный торрент? Как часто обновляются сигнатуры NBAR? На офсайте вижу последний апдейт аж от 27 января, а на дворе середина мая. Скайп частенько делает протокольные изменения, после очередного из них ваш NBAR сядет в лужу. С новыми протоколами аналогично. А, да, а как у NBAR с асимметричным трафиком дела обстоят? Под асимметричным я понимаю такой трафик, который заходит в сеть через одну коробку, а выходит через другую. Т.е. NBAR видит только одно направление данных в рамках информационного потока. Какого рода статистику можно собрать при помощи NBAR? Подозреваю, что довольно унылую, в то время как нормальные DPI коробки рисуют самые разнообразные графики, которые могут быть весьма полезны при планировании сети и разработке/модификации тарифных планов. И, наконец, что происходит с загрузкой CPU при работе NBAR? Не надо пытаться мне доказать, что всё-в-одном-флаконе будет лучше, чем stand-alone решение, разработанное для решения этой и только это задачи, это немного бесполезно, я в теме DPI варюсь не первый год. Видел я это несчастье на ASR1k, и на MX тоже видел — неедущее дерьмо. Циска вон всё никак не угомонится, заявили, что будут делать DPI на CRS и ASR9k. У джунипера хотя бы мозгов хватило забить на это.

Всё, что я озвучил выше, относится исключительно к SP рынку. В энтерпрайзе всё сильно проще, там и NBAR хватит.
Оно умеет по Netflow отдавать статистику по каждому приложению?
Ага.
www.networkworld.com/community/node/48191
А интегрироваться с биллингом будет?
Это следует из возможности экспортировать статистику.
В чём если не секрет?
Очевидно — в нагрузке на ЦП. У IPS сильно больше сигнатур. NBAR protocol-discovery на роутерах кушает меньше ЦП, чем средний IPS.
И как мне это ставить в проекте масштабов страны? Как оно будет саппортиться?
А никак. Саппортиться будет тот же sourcefire. Но лучше цискины решения.
Ну-ну, сами-то проверяли на сложных протоколах, таких как skype и шифрованный торрент?
У меня дома оно прекрасно делает match protocol skype, иосу где-то год уже.
Думаю, с uTP и тому подобным проблем тоже не будет.
Написать свою сигнатуру не проблема ;)
На офсайте вижу последний апдейт аж от 27 января, а на дворе середина мая.
В составе новой версии ОС уже имеются свежие PDLM. Или их можно скачать отдельно.
а как у NBAR с асимметричным трафиком дела обстоят?
А не существует (даже теоретически) решений, действительно качественно работающих с асимметричным роутингом. Не верьте маркетологам.
Какого рода статистику можно собрать при помощи NBAR? Подозреваю ...
Может, надо не подозревать, а просто знать?
нормальные DPI коробки рисуют самые разнообразные графики
На основе тех же данных по количеству пакетиков за определенный интервал времени :)
Маркетологи умеют промывать мозги…
что происходит с загрузкой CPU при работе NBAR?
Где-то на четверть проседает. Учитывая, что хороший тон при выборе железа исходить из 25% загрузки ЦП в пике — не проблема.
Не надо пытаться мне доказать, что всё-в-одном-флаконе будет лучше, чем stand-alone решение, разработанное для решения этой и только это задачи
Так откройте глаза и взгляните например на блейд Cisco NAM — www.cisco.com/en/US/products/ps11659/index.html. Вот как бы отдельная железка, но вставляемая в шасси cat6500 или 7600. Любители разнообразных графиков оценят :)
я в теме DPI варюсь не первый год.
Честно говоря, не очень заметно. Вы оперируете маркетинговыми терминами, но не назвали ни одного конкретного довода.
Ага.
Ок, оно действительно продвинулось в своём развитии. А нетфлоу-коллектор ещё небось денег стоит в случае масштабов SP, да?

Это следует из возможности экспортировать статистику.
Я не о том, я подразумевал полиси-сервер, который, как правило, входит в состав биллинга. Я о том, что есть сферический юзер с именем Вася. Есть ли возможность при помощи NBAR повесить на него определённую политику в соответствии с его тарифным планом? С условием, что Вася адрес получает по DHCP (ну или PPPoE) и каждый раз разный. На ASR1k, ясное дело, можно. Интересует всё остальное, где есть NBAR.

У IPS сильно больше сигнатур.
Можно на цифры взглянуть? В IPS же ещё эвристика во все поля?

А никак. Саппортиться будет тот же sourcefire.
Ок, для энтерпрайза покатит, для SP — вряд ли.

У меня дома оно прекрасно делает match protocol skype, иосу где-то год уже.
Думаю, с uTP и тому подобным проблем тоже не будет.
Написать свою сигнатуру не проблема ;)

Скайп свежий? Unknown трафика не фиксируется?) uTP не так сложно распознать, яростный UDP мелкими пакетами. Я имел в виду крипотованный торрент, он не так очевиден. Написание своих сигнатур — это ок.

А не существует (даже теоретически) решений, действительно качественно работающих с асимметричным роутингом. Не верьте маркетологам.
Мне не надо верить или не верить, я вижу как оно реально работает на коробках моего заказчика, мне этого достаточно. Есть решения, позволяющие идентифицировать 100% асимметричного трафика при том условии, что весь интересующий трафик проходит через девайсы, работающие в составе однго комплекса, т.е. ни один пакет не проходит мимо DPI, пусть даже и разнесённых территориально. Но эти решения не очень масштабируемы, т.к. девайсы пеерсылают друг другу as is весь трафик, считающийся асимметричным. При высоком уровне асимметрии это засада. TCP-шную асимметрию с использованием интеллектуального механизма взаимодействия коробок (по сути синхронизация стейтов) пара вендоров распознавать умеет, никакого rocket-science тут нет, всё довольно логично и стройно. UDP сильно сложнее, но тоже есть механизмы, вполне работоспособные.

Может, надо не подозревать, а просто знать?
Ну вот не знаю я NBAR, застрелиться мне теперь?

На основе тех же данных по количеству пакетиков за определенный интервал времени :)
Маркетологи умеют промывать мозги…

Ну они же рисуют эти графики, верно? Посчитать циферки это полдела, а построить быстро и качественно работающую систему, позволяющую из этих пустых цифр рисовать то, что мне требуется — это совсем другое. В случае покупки нормального DPI заказчик получает это сразу из коробки, и без работы с напильником для достижения нужного результата, за минимальные сроки. Видел своими глазами DPI-решения, рисующие гарфики по полчаса. И в то же время видел такие, которые делают то же самое за 5 секунд. Можете оценить, сколько денег будет стоить разработка софта, который будет лазить в нетфлоу-коллектор, выискивать там циферки и рисовать графики в режиме реального времени?

Где-то на четверть проседает.
Запомним, спасибо. Кстати, какая задержка в трафик вносится при работе NBAR? Порядок микросекунд или миллисекунд?

Так откройте глаза и взгляните например на блейд Cisco NAMВсё бы ничего, но перформанс хилый, стоит дорого, занимает драгоценные слоты в недешёвой коробке. Увы.

Честно говоря, не очень заметно. Вы оперируете маркетинговыми терминами, но не назвали ни одного конкретного довода.
Мне кажется, выше мои доводы, хоть и не все, но указаны. Вы можете предложить мне вменяемое интегрированное решение, рассчитанное на близкую к сотне гиг производительность в режиме полной загрузки коробки?
«А нетфлоу-коллектор ещё небось денег стоит в случае масштабов SP, да?»
Учитывая, что многие сервис-провайдеры переходят на опенсорс — вообще не факт. У большинства какти внедрен к примеру. С плагинами он способен на всё.

Есть ли возможность при помощи NBAR повесить на него определённую политику в соответствии с его тарифным планом?
Вы уж определитесь — нужно решение «всё в одном», или нет?
С точки зрения провайдера, есть две разные задачи: зарезать скорость Васе до тарифной и узнать, чем же он занимался. В первом случае — причем тут NBAR?
Вообще ИМХО глупо ставить в inline анализатор трафика, который не будет вмешиваться в трафик. Т.е. логичнее всего просто-напросто организовать SPAN в сторону DPI девайса.

Можно на цифры взглянуть? В IPS же ещё эвристика во все поля?
Я же говорю — Вы как-то много чего пропустили.
en.wikipedia.org/wiki/Intrusion_prevention_system
«Signature-Based Detection: This method of detection utilizes signatures, which are attack patterns that are preconfigured and predetermined. A signature-based intrusion prevention system monitors the network traffic for matches to these signatures. Once a match is found the intrusion prevention system takes the appropriate action. Signatures can be exploit-based or vulnerability-based. Exploit-based signatures analyze patterns appearing in exploits being protected against, while vulnerability-based signatures analyze vulnerabilities in a program, its execution, and conditions needed to exploit said vulnerability.»
По сигнатурам определяются пакеты, способные использовать известную уязвимость.
Это лишь один из методов работы IDS/IPS.
Цифры? Счет, по-моему, идет на десятки/сотни тысяч. Но вот момент: нет смысла включать те сигнатуры, что не представляют угрозы. Потому по факту будет задействовано меньшее их количество.

девайсы пеерсылают друг другу as is весь трафик, считающийся асимметричным.
То есть никаких отличий от классического ERSPAN? У меня тоже в нескольких точках сети собирается голосовой трафик и отсылается на сниффилки за несколько хопов. Скучно.

Ну вот не знаю я NBAR, застрелиться мне теперь?

Вы прямо перед этим писали, что NBAR — отстой и вообще ни на что не годится. А сейчас выясняется, что Вы просто про него не знаете…

а построить быстро и качественно работающую систему, позволяющую из этих пустых цифр рисовать то, что мне требуется — это совсем другое.
У циски оно работает превосходно. У Sourcefire оно работает превосходно. Это за деньги. Бесплатно — snort, rrdtool, пара недель работы напильником — и тоже все отлично.
Но вопрос отображения данных уже не относится к вопросу отлавливания и анализа пакетов, тут как раз никакого rocket science.

Можете оценить, сколько денег будет стоить разработка софта, который будет лазить в нетфлоу-коллектор, выискивать там циферки и рисовать графики в режиме реального времени?
А уж представьте себе, сколько стоит разработка такой сложной штуки, как ядро Linux :) Ах да, он же бесплатно распространяется…

какая задержка в трафик вносится при работе NBAR?
Понятия не имею. Если сильно надо — могу погуглить.
Но опять же, если мы говорим о порядочном провайдере, то сенсор будет лишь получать копию трафика, а не стоять на его пути.

перформанс хилый, стоит дорого, занимает драгоценные слоты в недешёвой коробке.
Обалдеть…
1) 15гб/с гарантируют.
2) Бандл WS-C6506-E-NAM3-K9 (по названию все понятно?) стоит по GPL $95k. Аналогично с 6509 — $98k. И нет, шасси cat6500 как раз самое дешевое в нем, слоты — не проблема.

Вы можете предложить мне вменяемое интегрированное решение, рассчитанное на близкую к сотне гиг производительность в режиме полной загрузки коробки?
Вы не смогли. Речь шла про 20 гиг, во что тоже не слишком верится.
Но: NAM3 стоит $60k (опять же, цены GPL, в реальности куда ниже). В один cat6500 можно набить много этих самых NAMов. В принципе — пока слоты не закончатся. Иными словами — я могу предоставить коробку, которая гарантированно (не только в пике) осилит, скажем, 120гб/с анализа трафика (линейные карты тоже надо куда-то втыкать), а маршрутизировать суммарно сможет теоретически под 2тб/с (хотя останется слишком мало слотов, чтобы этим воспользоваться).
Вы сможете дать мне такую коробку от конкурентов? Есть мнение, что даже любая из блейд-корзин будет уступать шеститоннику…
У большинства какти внедрен к примеру. С плагинами он способен на всё.
Какти клёвый, да, но возвращаемся к вопросу о саппорте, которого с точки зрения SLA нет. Да и сервера СХД с базой данных бесплатными не будут.

Вы уж определитесь — нужно решение «всё в одном», или нет?
С точки зрения провайдера, есть две разные задачи: зарезать скорость Васе до тарифной и узнать, чем же он занимался. В первом случае — причем тут NBAR?

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

нет смысла включать те сигнатуры, что не представляют угрозы
Эмм, а смысл их писать тогда если он угрозу не представляют?

То есть никаких отличий от классического ERSPAN?
Это лишь один из вариантов, как я сказал, из немасштабируемых. Правильные вендоры делают иначе. В тот момент, когда коробка детектит SYN ACK, но при этом SYN она не видела, она делает бродкаст своим друзьям с вопросом, не видел ли кто-то из них SYN для этого соединения. В случае положительного ответа один из девайсов юникастом отвечает, что да, и далее они начинают обмениваться сигналингом, которого достаточно для определения приложения в рамках отдельно взятого соединения. Несколько более интеллектуально, чем ERSPAN, согласитесь. Работает как часы.

А сейчас выясняется, что Вы просто про него не знаете…
Вот и узнаю, как и вы что-то новое сейчас узнаёте, хоть и со скепсисом.

Но вопрос отображения данных уже не относится к вопросу отлавливания и анализа пакетов, тут как раз никакого rocket science.
Согласен, это другая песня. Которая, тем не менее, DPI-вендорами решается из коробки.

А уж представьте себе, сколько стоит разработка такой сложной штуки, как ядро Linux :)
Это вообще показательный пример того, что упорство порождает чудеса. Ладно, к примеру, софт тоже опенсорсный. Но он же может сломаться, а SP любят SLA, т.к. они могут предоставлять коммерческие услуги для корпоративных клиентов на базе формирования отчётов. Если оно сломается, оператор может не получить денег.

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

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

1) 15гб/с гарантируют.
2) Бандл WS-C6506-E-NAM3-K9 (по названию все понятно?) стоит по GPL $95k. Аналогично с 6509 — $98k. И нет, шасси cat6500 как раз самое дешевое в нем, слоты — не проблема.

Да, вижу, за 98k мы ещё и суп впридачу получаем. Ок, посчитаем DPI, за который я так ратую.
Берём двухюнитовое шасси (нет смысла ставить многослотовое решение для такого перформанса). Коробка с 10G дырками стоит $60k. Она способна перелопатить 30Gbps. Лицензия только под сбор статистики (функционал NAM) стоит $80k. Итого $140k. Если добавить в 6500 бандл ещё один NAM-бандл с софтом, то тут и без калькулятора всё понятно. Если же мы купим лицензию для DPI для интеллектуального шейпинга-филтеринга, то моя спека вырастает на $50k, т.е что-то в районе $190k выходит. GPL, разумеется. Тут вы можете сказать, что 6500 ещё и считчить умеет, на что я отвечу, что DPI ещё и управлять трафиком может.

Иными словами — я могу предоставить коробку, которая гарантированно (не только в пике) осилит, скажем, 120гб/с анализа трафика (линейные карты тоже надо куда-то втыкать), а маршрутизировать суммарно сможет теоретически под 2тб/с (хотя останется слишком мало слотов, чтобы этим воспользоваться).
Соберём 120Gbps, у меня есть такой DPI. 6513-E с SUP2T (иначе мы не прокачаем NAM на полную), 8 слотов забиваем NAM, что даёт нам 120Gbps. И в один слот пихаем 8-слотовый десяточный модуль, дабы откуда-то брать трафик. Бандл 6513 с SUP2T стоит $44k (бандлов с NAM на нём нет), десяточная карточка $40k. Прибавляем 8 бандлов NAM, получаем $760k. Всякая требуха ещё тысяч на 15. Итого получается где-то $860k.
DPI под 120Gbps будет стоить дороже, в районе $950k-$1M, в зависимости от мощности дополнительной обвязки. Но он за эти деньги будет ещё и управлять трафиком, а не просто рисовать красивые картинки. И занимает почти в два раза меньше места — 13RU против 20RU. Просто рисовать картинки — я уже считал выше 2RU-коробку под 30Gbps. Ставим 4 таких девайса на сайт, и получаем $560k в GPL. Профит очевиден.
возвращаемся к вопросу о саппорте
Тут можно вспомнить мир IP телефонии и то, что огромное количество операторов использует астериск… Всегда можно найти компанию со своим штатом разработчиков, которая за деньги берется сопровождать опенсорсное решение.

Ну ладно, дальше спорить лень. Финальным аккордом дайте ссылку на 100% программное решение, которое осилит весь указанный Вами функционал на 30гб/с и обеспечит задержку не более одной миллисекунды :)
UFO just landed and posted this here
Топовые роутеры — скорее линейки CRS, ASR, 7600 (ну и 6500, который по недоразумению назван свитчем). Нет, они все железные. Софтовые — только 7200, 3900 и ниже. Т.е. наиболее медленные из всех.
Только не надо говорить «даже у CRS-3 внутри ОС, потому они все софтовые» :)
UFO just landed and posted this here
Не 6500 по недоразумению назвал свичем, а 7600 по недоразумению назван маршрутизатором. И то, и то — L3 свичи.
6500 c SIP модулем вполне неотличим от роутера…
Если Вы устанавливаете в 7600/6500 шасси такие модули как SIP/SPA/ES/ES+ (то есть WAN карточки), то по сути в модульный коммутатор Вы устанавливаете ОТДЕЛЬНЫЙ маршрутизатор выполненный в форм факторе модуля (блейда).
Как программист, пишуший цисковскую фирмварь, подтверждаю — раньше внутри был VXworks, сейчас переползаем на Линукс, но вся обработка пакетов делается хардверно, на пакет-процессоре, который в свою очередь управляется софтово. Считать ли роутер софтовым? Умеют ли подводные лодки плавать?
Стоит добавить, что у сетевой карты «с другой стороны», то есть внутри сервера, тоже есть среда передачи данных, и в условиях конкурентного использования шины именно она может оказываться узким местом всей системы. В принципе, в сервер можно воткнуть 2,3,4 и тэдэ 10G интерфейсов, но решит ли это проблему?
Это уже вопрос к серверостроителям, в первую очередь, и, в частности, к всеми любимому интелу.
У нас есть сервера, что раздают файлы на скорости 15Gb на soho железе. Это soho с 9ю винтами (ssd). Если взять двухпроцессорный сервер и 24 винта, они вполне 40G увалят ( через 2*520-Da2).
>Ethernet в каком-то из его видов: 100 Мбит/с (Fast Ethernet, Fe), 1 Гбит/с (Gigabit Ethernet, Gbe) или 10 Гбит/с

Будете что-то разрабатывать — никогда не добавляйте в названия «fast», «new» и т.д. А то будет как с Fast Ethernet, который нынче самый медленный и Лондонским «Новым мостом», который сейчас самый старый.
Не удержусь — и New iPad через пару лет будет не новым, и всем его потомкам придется зваться как-то совсем «с подвыподвертом»…
Яблочные маркетологи пока справляются.
Хм… Судя по «new» в названии последнего iPad-а… :)
Не совсем понимаю почему 10GBase-T не используется? Неужели в датацентрах между шкафами или между хостами и СХД не юзают 10GBase-T. Думаю в плане денег он намного дешевле оптики.
В тех узлах, которые я видел своими глазами (а их довольно много) для соединений внутри шкафа использовался почти поголовно 10GBase-CX4. Насчет глубинных причин такого положения я, честно, говоря, не задумывался, но они наверняка есть. Возможно, дело в том, что порты CX4 доступнее (в широком смысле, т.е. популярнее у производителей оборудования, проще для заказа, etc).
возможно, исторически.
Попросили у поставщика железа 10GbE карточку потестить — привезли карту с CX4, говорят, другой нет.
Поскольку у них не было ни второй такой, ни кабеля, потестировать так ничего и не удалось.
Ставим пока четырехпортовые гигабитные карты.
У 10GBase-T ещё на порядок выше latency относительно других модулей.
Это крайне подозрительно… Откуда растут ноги?
Оборудование в основном делается сейчас под SFP+. Внутри шкафа можно использовать SFP+ Direct Attach. Между шкафами дешевую оптику и двухволоконные модули, которые будут скоро стоить как грязь.
Стоимость порта 10G все еще такова, что экономить на проводках неинтересно.
Многомода действительно стоит копейки.
Долгое время 10GBase-T обвес был слишком прожорлив до питания и, соответственно, достаточно горячим. Не удавалось необходимую плотность портов обеспечить. У нас до сих пор самые попрулярные комбинации 10GBase-SR/LR карты (из 520-й серии, или 5771x Бродкома). Для работы внутри стойки или соседних (под iSCSI СХД) популярны также TwinAxial кабели.
Нелишним будет отметить, что у Интела существуют большие, не, даже так — БОЛЬШИЕ проблемы с совместимостью Direct Attach-кабелей. Полгода назад, например, своих DA-кабелей у Интела не было, а сторонние (конкретно — HP'шные) не работали на них вовсе. Техподдержка помочь так и не смогла, в том числе и назвать конкретные совместимые кабели.
Это раз.
Два — в интеловских драйверах существует проверка производителя SFP+ модулей, если стоит не родной — интерфейс вообще отключается. И если open-source'ные драйвера (под *NIX) патчатся легко и непринуждённо, то под VmWare или тем более Windows владельцы карт жёстко привязаны к фирменным SFP+ модулям. Предупреждая комментарии «так они перестраховываются» хочу отметить, что подобная тактика из крупных вендоров осталась разве что у Cisco — Juniper, Extreme и др. работают с нефирменными модулями без претензий.
Три — заявленная поддержка FCoE также до сих пор не реализована в драйверах.

подобная тактика из крупных вендоров осталась разве что у Cisco

Одна скрытая команда, затем предупреждение на полэкрана вида «TAC пошлет вас куда подальше с неродными трансиверами» — и циска (cat6500 по крайней мере) начинает вполне уверенно работать с чужими SFP.
ЧТД.
И не томите уж, напишите, что за команда-то. ;)
Надо только понимать, что чужие SFP не всегда чтобы полная аналогия цискиных. Но для не самых критичных направлений, да еще в не самые суровые условия — вполне себе :)

Это я к тому, что не зря предупреждение она выводит.
Лично на мой взгляд, стандарты придумывают для того, чтобы на рынке присутствовали различные производители, в том числе и сторонние. Пусть клиент сам выберет, что именно ему больше нравится.
Dell овские работают с интелями нормально.
SFP+ модули легко и непринужденно прошиваются.
Потому что в подавляющем большинстве Dell как раз Intel'овские и использует.
Прошивальщик SFP+ далеко не самая распространённая вещь.
Вы не найдете ни одного вендора, который заявит о том, что в его железе можно использовать любые оптические модули (сторонних производителей). То что модули работают — это совсем другое дело.

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

Если у вас проект на сотни тысяч денег, то экономить пару сотен долларов на оптических модулях по крайней мере глупо.
Я крайне рад за вас, и особенно за модули Cisco (которые даже в США бывают «левыми», была очень занятная тема на тамошнем операторском форуме), вот только Cisco почему-то позволяет работать и с другими оптическими модулями, путём одной простой команды.
Вы не поняли смысла. То что модули работает, ни как не связано с тем, что производитель рекомендует и продает. Вы думаете что любой вендор склепал модуль и сразу на рынок?

Оптимизм заканчивается, когда установленный сторонний модуль начинает выпадать в error-disable, на нем появляются ошибки/потери, интерфейс начинает «флапать», происходит рассогласование скоростей и дуплекса и т.д. Это все не выдумки, а случаи из личного опыта.

После этого такая сомнительная экономия превращается в полноценный геморрой.
Я сам буду решать, с какими модулями мне работать, а с какими нет, а вовсе не производитель. У меня неродные SFP модули работают много где и без проблем вообще (Opticin, PLink — все без проблем).
Alcatel-Lucent как раз на СвязьЭкспокоме показали модуль DWDM-уплотнения 400G в одну лямбду.
Это все хорошо, но на текущий момент скорее баловство для вендоров и инженеров. Даже 40G на текущий момент выглядят на порядок не привлекательнее 4*10G. Цены и наличие оборудования не радуют.

Сюда следует добавить поведение в реальных условиях. 10G на огромный порядок капризнее 1G и более требовательны в качеству линии (из личного опыта расскажу, что был случай, когда 1.2 км расстояния просвети только 40-ка километровым модулем. Вот Вам и затухания. Отдельное спасибо сварщикам оптики). С 40G проблем будет еще больше.
Ну некоторым нашим заказчикам 4*10 уже давно как мало.
XFP-CX4 стоит $1000, а XFP-SR $200. плюс разница в стоимости кабеля.
CX4 отмирает. как минимум SFP+ и XFP DirectAttach будут дешевле.

Я ожидаю от intel, когда они сделают карту для PCI-E3.0, а пока получается не больше 2Mpps на систему, а хочется больше трафика зарулить, все равно CPU простаивает.
Всё круто, но за поддержку линукса железом на уровне «дитрибутив такой-то и такой-то» следует отрывать все выступающие части тела.

Нормальная поддержка linux — в ванили. Коммить в апстрим, расползётся по дистрибутивам само.

А вот когда криворукие индусы кодят модуль, который отдают бинарно, который совместим только с одной версией ядра, а в апстриме на такой код смотрят как на г..., вот тогда — это махровый энтерпрайз и [спасибо не надо].

К счастью, интел не из этих, и поддерживается в ванили (ixgbe), так что утверждение о «совместимых ОС» в пределах RHEL/SLES — неправда.
Читать внимательнее надо. Там написано проще: Linux Stable Kernel 2.6 * * *.
забавно, что в конфигурации Catalyst порты называются Te.
Когда я вижу Te1/0/1, мне не перестает казаться, что я уже в будущем, а интерфейс — терабитный :)
Интересно, как у циски 40G интерфейсы будут называться. ;)
Ten gigabit Ethernet. На ME то же самое — Te0/1
Кстати, а почему в железе Juniper интерфейсы именуются ae, xe?
ae = Aggregated Ethernet
xe — гигабитный Ethernet на маршрутизаторах eX серии
Гигабитный интерфейс называется ge.
Полагаю, что 10G интерфейс называется xe, так как X — римская 10 :)

Juniper ориентируется больше на маршрутизаторы, поэтому вряд ли логическое имя порта дано в честь серии EX.
>самому старому десятигигабитному стандарту 802.3ae в этом году исполнилось 10 лет
А в учебных заведениях, до сих пор учат тому что 100мбит это самый край. Устал в свое время преподу объяснять что информация коей он руководствуется, давно устарела. Все равно не поверил.
>А в учебных заведениях
В некоторых, разумеется, господа :}
А какой смысл спорить с такими преподавателями?
Я «учился» у одного из той же серии. В состоянии фейспалма прослушав первую лекцию, я подошел к нему, показал карточку с надписью «CCNP», назвал работодателя и должность — и больше не ходил, проставив в зачетку пятерку где-то через неделю после экзамена (лень было на сам экзамен идти) :)
>А какой смысл спорить с такими преподавателями?
Чтобы если не препод, то хотя бы одногруппники обладали актуальной инфрмацией, а не той что им вещает неуч.
> серверные ОС Microsoft (Windows Server 2008 в различных вариантах)

Всегда хотел спросить — неужели в Win 2003 железо не заработает «как надо» либо вообще? Чем работа сетевых драйверов и сетевух в 2008 лучше, чем в 2003? Или дрова просто тупо проверяют версию, и не запустятся «не в 2008»?
За что минусы-то?

Честно говоря, раздражает, когда в описании любого нового железа перечисляют только самые последние версии ОС: я понимаю, если строить проект, то туда пойдет и новый сервер, и свежий Windows Server, но, если, скажем, искать 10G карточку в сервер, настроенный и работающий (хором — «работает — не трогай!») на Windows 2003, а в описании подходящей вроде бы карты написано только про Windows 2008, то остается только гадать, либо рускнуть, купить и попробовать. И ладно, если разговор о Windows, но ведь есть множество *nix-ОСей, а у них — также, старые версии.

Я к тому, что корпорация уровня Intel наверняка знает о наличии парка серверов со старыми версиями, и, наверняка, тестирует драйвера в разных версиях ОС (в т.ч. и в старых) — но продолжает сокращать информацию о версиях ОС, где драйвера работают.
А как на счет сравнить 10GBe и QDR Infiniband? Ведь в HPC это стандарт…
И как обстоят дела с проблемой высокой латентности Ethernet, в смысле латентности CSMA/CD — в 10GBe эту проблему как-то решили?
«в смысле латентности CSMA/CD»
На современных свитчах и при full duplex такого нет и на 100мб/с.

Типовые свитчи дают около 8 микросекунд задержки.
У циски есть и накачанные стероидами нексусы 3000, разработанные специально для ситуаций, когда даже 8мкс — слишком много: www.cisco.com/en/US/prod/collateral/switches/ps9441/ps11541/white_paper_c11-661939.html#wp9000066
У современного IB латентность сильно лучше, чем у 10G Ether (Mellanox клянется, что 0.7мкс в 56G).
У 10-гигабитного старого IB — микросекунд 6, что лучше чем 10G Ether, но непринципиально.
О какой латентности идет речь? Если я правильно помню, то в 10G не идет речь о CSMA/CD: поскольку полный дуплекс, то и коллизий нет.
Дело даже не только в дуплексе, а в том, что на 1G хабов нет =)
«CSMA/CD was used in now obsolete shared media Ethernet variants (10BASE5, 10BASE2) and in the early versions of twisted-pair Ethernet which used repeater hubs. Modern Ethernet networks built with switches and full-duplex connections no longer utilize CSMA/CD though it is still supported for backwards compatibility. IEEE Std 802.3, which defines all Ethernet variants, for historical reasons still bears the title „Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications“.»
Хочу больше статей про оптику, никогда не приходилось с ней серьезно работать, а максимум медиаконвертеры.
>Вы не поняли смысла. То что модули работает, ни как не связано с тем, что производитель рекомендует и продает. Вы думаете что любой вендор склепал модуль и сразу на рынок?

А разве cisco делает оптические модуля сама? На сколько мне известно- абсолютное большинство модулей делает пару вендоров, остальные туда льют свою прошивочку и клеят этикеточку. Да на моей практике большинство SFP модулей исполнено-то одинаково, ну или пара исполнений встречается… Вопрос только отбраковки по ряду параметров, имхо
Sign up to leave a comment.