Производитель систем мониторинга и анализа сетевой активности, компания nPulse, начала (http://finance.yahoo.com/news/Wireshark-Edition-Delivers-prn...) выпускать высокопроизводительный сканер, построенный на базе ПО Wireshark. Решение от nPulse позволяет вести запись проходящего трафика, и, в зависимости от потребностей, воспроизводить сохраненные образцы на скорости до 10 Гбит. Компания является признанным лидером в производстве высокоскоростных сетевых систем, а также «золотым» спонсором проекта dPacket.org.Wireshark (http://www.wireshark.org/) считается самым широко используемым анализатором пакетов. Принятую информацию он сохраняет в файлы формата pcap, которые являются де-факто стандартом хранения информации о сетевом трафике. Устройство PCAP Express Box выполняет функции своего рода сервера, аккумулирующего поступающие данные. В последующем, они могут быть скопированы на компьютер специалиста, который будет заниматься их изучением.
По сл...
URL: http://finance.yahoo.com/news/Wireshark-Edition-Delivers-prn...
Новость: http://www.opennet.me/opennews/art.shtml?num=23072
а кто-нибудь юзал 10гигабитные карточки от этой компании? типа http://www.pcapexpress.com/index.php/pcapxnt20
Очень громкое заявление и очень далекое от действительности. Продукт обрабатывающий 10Гбит поток претендует на очень многое, вот nPulse и прыгает выше головы. Простая арифметика: предположим поймали всего 10Гб за минуту (в принципе реально у какого-нибудь телекома). Что с этим делать в pcap формате? Ведь реально это plain файл без какого-либо индекса. Сам Wireshark перечитывает его после каждого "чиха" пользователя, с реально большими трейсами в принципе работать невозможно.Писал аналог(к сожалению закрытый), основной упор на работу в режиме реального времени. Заказчик решил обеспечить возможность подключения шарка как внешнего анализатора(протоколов уж больно много знает). Извращались как могли, в конце концов даже диссекторы(декодируют протоколы) выдернули и попытались использовать только их. 2000 пакетов/сек --- просто предел. Соответственно в реальном времени строить сущности более высоких уровней(сессии, вызовы) в принципе нереально, а кого сейчас заинтересует возможность видеть 10Гбит пакетов в секунду? Кого сейчас вообще пакеты волнуют? Пропускной способности шарка не хватит и для 1Гбит/сек.
Продукт с громким названием сохраняет часть проходящего трафика(низкоуровневые быстрые фильтры у них точно есть) нарезая его на разумного размера pcap файлы, которые впоследствии могут быть открыты шарком.
Ни о какой связанности данных, детальной информации и режиме реального времени речь не идет. Поддержка современного стандарта да огромный диск вот и все технологии. Высокопроизводительный сканер будет довольствоваться образцами до 100Мб размером и анализировать их с очень заметными задержками.
Прошлый век с современным бантиком, одним словом.
Мэйби вы тоже далеки от реальности. Такие скорости думаю более чем реальны. Примеры живые есть - Cisco SCE (8080 серии) - работают на скорости порта (до 10Гбит/с на порт), работают с живым трафиком, при этом не создают никаких задержек (прозрачным режим), но отлично контролируют полосу во все возможных решениях. Для аналитических махинаций использует коллектор, в который сливает NetFlow пакеты.
Вот так и тут вполне спокойно люди могли допилить продукт до адекватного состояния, и натянув его на довольно таки производительную платформу.
p.s. и заявления, что именно у вас ничего не вышло, звучит как "они все п***расы, один я д'артаньян", но при этом любой адекватный человек, вплотную работающий с технологиями магистрального масштаба скажет вам что вы просто неудачник и только позоритесь здесь своими громкими выхлопами.
>[оверквотинг удален]
>скорости порта (до 10Гбит/с на порт), работают с живым трафиком, при
>этом не создают никаких задержек (прозрачным режим), но отлично контролируют полосу
>во все возможных решениях. Для аналитических махинаций использует коллектор, в который
>сливает NetFlow пакеты.
>Вот так и тут вполне спокойно люди могли допилить продукт до адекватного
>состояния, и натянув его на довольно таки производительную платформу.
>p.s. и заявления, что именно у вас ничего не вышло, звучит как
>"они все п***расы, один я д'артаньян", но при этом любой адекватный
>человек, вплотную работающий с технологиями магистрального масштаба скажет вам что вы
>просто неудачник и только позоритесь здесь своими громкими выхлопами.1) пакетики этот сканер и их содержимое на таких скоростях может и покажет, но вот если начать работы по сбору сессии или еще более высокоуровневые операции то боюсь тормоза обеспечены.
Вопрос не в том что бы пропустить через себя такой трафик а проделать что то осмысленное и более менее сложное.
Особенно забавно если надо будет поднять статистику за большой промежуток времени - без соответствующей индексации это тоже проблема2) большинство подобных железок имеет интересные ссылки что скорость 10 гигабит достигается на определенном размере пакета, так что на маленьких пакетах может быть весьма значительное падение скорости
xGa, во-первых Вы меня не совсем поняли, во-вторых у Вас странное хобби бросаться на людей.
Диалог производителя(П) подобного рода систем с телекомом(Т):
П: У нас 10Gbit ready система, подойдет вам идеально, покупайте
Т: Ок, нам нужно 3-4 недели сигнального траф. и 1-2 дня голоса (подразумевается возможность оперативной работы со всей информацией)
П: У нас гибкие настройки, мы можем выборочно сохранять по ХХ Мб...
Т: Другими словами вы не 10Gbit ready?
П: Нет10Гбит/с на порт не проблема --- дальше что?
Не нужно быть голословным --- потрудитесь посмотреть код Шарка. Он был и есть отличным продуктом, но стоит помнить об ограничениях налагаемых устаревшей архитектурой и технологиями. К слову, одна из первых версий именно Wireshark'а (после проблем з Ethereal'ом) не замечала нескольких доступных ядер, продолжая мариновать пользователя очередным диалогом "подождите, я уже обработал хх %".
Относительно реальных скоростей, читаем внимательно --- все реально, но не стоит забывать о реальных задачах. Повторю, никого не интересуют пакеты, никто не хочет их видеть. QoS -- другое дело. Один из зарубежных провайдеров: "Мы не будем запускать сервис сейчас --- у нас нет возможность контролировать качество и эффективно решать проблемы. Задержка для нас очень болезненна, но некачественный сервис будет просто катастрофой". QoS никогда не был сильной стороной шарка. Посмотрите древний Hammer Call Analyzer, например.
Далее, внимательно смотрим роадмап Интел, понимаем что мир немного изменился и "натянуть" устаревшее, в архитектурном смысле, решение на "довольно таки производительную" платформу(64+ ядра, ...) будет не очень легко. Подобный проект скорее всего просто не профинансируют или потом "натянут" идейного вдохновителя.
У Вас потрясающая способность извращать информацию, делать на ее основе свои выводы и переходить на личности. В нашем случае Шарк остался второстепенным механизмом. Он отлично справляется со своими задачами, но все дыры им закрывать явно не стоит.
xGa, успехов, у Вас тоже все получится :)
> Диалог производителя(П) подобного рода систем с телекомом(Т)Мхату сто лет, браво! Уважаемый, сходите на сайт к ним и почитайте хотя бы. Ваши догадки, построенные на `а у нас не получилось, значит это невозможно' тут мало кому интересны.
>Мхату сто лет, браво! Уважаемый, сходите на сайт к ним и почитайте
>хотя бы.Что Вас на сайте поразило? "Best-of-Breed, Monitoring Applications"? Процитировать "упущенное" мною небеса не позволили?
Предлагаю ознакомиться со сделующим (http://wiki.wireshark.org/Performance)
----------
Some tips to fine tune Wireshark's performance.
If you have a large capture file e.g. > 100MB, Wireshark will become slow while loading, filtering and alike actions.
There are some things you can do, but unfortunately this will remove some decoding comfort:
* Disable Coloring Rules
* Disable Network Layer (hostname) DNS lookups under
...
If the above hints didn't help, you may need to advance your machine.harddisk - as fast as possible, a fast RAID might be preferrable
CPU - the task processed is a single task, a multi-core CPU won't help a lot
The amount of memory isn't really critical for capturing.
----------Ваши аргументы?
>Ваши аргументы?Какие аргументы могут быть на эту глупость? Тут описана проблема интерфеса WS, которая при необходимости работы с большими дампами элементарно решается, и товарищи из nPulse ее решили. Вас еще раз послать к ним на сайт?
>Какие аргументы могут быть на эту глупость? Тут описана проблема интерфеса WS,
>которая при необходимости работы с большими дампами элементарно решается, и товарищи
>из nPulse ее решили. Вас еще раз послать к ним на
>сайт?Вот так уж и глупость и проблемы _интерфейса_? :) Просьбу процитировать сайт Вы проигнорировали, что вполне естественно и будет, я надеюсь, отмечено независимыми читателями.
Позвольте послать Вас чуть дальше, еще раз к этой странице и к исходному коду шарка.
Думаю, если сливать инфу на HDFS и применять распределенный map/reduce хадопа, при определенном размере вычислительной сети можно делать анализ близко приближенный к реалтайму.
С какого перепугу ты решил, что капчер дивайс это компьютер ? Все сетевое, что работает на скоростях больше 100 мб и сделано правильно это заказные процессоры (ASIC)или в крайнем случае стандартные нет-процессора вроде Марвела.
по поводу неудачника не согласен.
т.к. netflow и pcap это немного разные вещие, в pcap может быть полный дам траффика, а в нетфлоу поопределению только заголовки.
А что мешает им pcap загонять в БД, а затем анализировать сессии итд?
>А что мешает им pcap загонять в БД, а затем анализировать сессии
>итд?Тем что в pcap файле находится весь перехваченный трафик. что бы это можно было записать в базу необходима обработка. Самая от полноты обработки зависит ресурсоемкость. Одно дело просто вытянуть ip адреса и совсем другое например уже из тех же пакетов востановить содержимое http сессии.
Вот и интересно какой уровень DPI (deep packet inspection) обеспечивает сабж
>Тем что в pcap файле находится весь перехваченный трафик. что бы это
>можно было записать в базу необходима обработка. Самая от полноты обработки
>зависит ресурсоемкость. Одно дело просто вытянуть ip адреса и совсем другое
>например уже из тех же пакетов востановить содержимое http сессии.Ресурсоемкость там минимальная, так что это вполне возможно. Минимум - анализ TCP сессий - вообще ничего не стоит, а прикладной уровень можно уже и налету при анализе разгрести.
>>Тем что в pcap файле находится весь перехваченный трафик. что бы это
>>можно было записать в базу необходима обработка. Самая от полноты обработки
>>зависит ресурсоемкость. Одно дело просто вытянуть ip адреса и совсем другое
>>например уже из тех же пакетов востановить содержимое http сессии.
>
>Ресурсоемкость там минимальная, так что это вполне возможно. Минимум - анализ TCP
>сессий - вообще ничего не стоит, а прикладной уровень можно уже
>и налету при анализе разгрести.Я более трех лет занимаюсь анализом TCP сессий, И смею вас уверить что проблемм там очень много. Еще больше в SCTP особенно если их на лету из середины подхватывать надо.
Например Как вы защите от банального DoS а DDos?
А от 1000K++ сессий у вас как это в память для агрегирования поместится?
И чтобы при этом был минимум ресурсоемкость. И важные данные не пропустить.А прикладной уровень какой-нибудь протокол на ASN.1 на лету в per encoding 8-) да вы батенька похоже ничего про него не знаете... (про прикладной уровень конечно)...
>А что мешает им pcap загонять в БД, а затем анализировать сессии
>итд?С БД, в общепринятом смысле, очень неэффективно. Berkeley DB --- существенно лучше.
>С БД, в общепринятом смысле, очень неэффективно. Berkeley DB --- существенно лучше.Ну реляционное убожество понятно что нафиг не уперлось. BDB тоже страшно тормозная вещь. А достаточно всего лишь писать рядом с pcap файлом индекс.
>Ну реляционное убожество понятно что нафиг не уперлось. BDB тоже страшно тормозная
>вещь. А достаточно всего лишь писать рядом с pcap файлом индекс.Не сочтите за придирку, любопытства ради. Какой именно индекс?
Подумайте, что вам с этим траффиком потом надо будет делать и ответ придет сам собой.
>Подумайте, что вам с этим траффиком потом надо будет делать и ответ
>придет сам собой.И это стоило писать? :)
Полное отсутствие конкретики, общие фразы и не совсем корректные наезды --- краткий итог Ваших ответов.
Друг мой, с Вами предельно неинтересно разговаривать --- Вы не в состоянии предоставить даже намек на полезную информацию.
Успехов :)
Второе образование театральное?Сорри за офтоп...А так к всему Вами сказаному... +1
Напоминает разговор доктора и пациента.
П. Доктор я ходить буду?
Д. Да но только под себя.
П. А плавать?
Д. Да если будете много ходить?Я к тому что маршрут построить это значит перелопатить все файлы огромных размеров!
А в базе можно это хоть как то это вместе связать.
Никто не говорит что это нужно делать на шарманке 286. Хранилище должно быть как минимум данные за неделю это 10Gb/s x 60s x 60m x 24h x 7d = 6 048 TB понты хранить такой трафик? Если будут такие нагрузки? Карточка сделана для реалтайма не более ну и + захват если, что пошло не так.
>быть как минимум данные за неделю это 10Gb/s x 60s x
>60m x 24h x 7d = 6 048 TB понты хранить
>такой трафик?Формулу поправьте - 10Gb/s это БИТ в секунду, а не байт
>>быть как минимум данные за неделю это 10Gb/s x 60s x
>>60m x 24h x 7d = 6 048 TB понты хранить
>>такой трафик?
>
>Формулу поправьте - 10Gb/s это БИТ в секунду, а не байтВы че ваще считать не умеете?
там >172TB в день !!!
10GBit/sec ~ 1G octets в сек если убрать meta overhead. Еще умножим на два поскольку два направления.
В 1 дне 86400 сек если кто не знает => надо > 172TByte в день!!!
За 30 дней имеем >5ПетаБайт в месяц а это реально дохрена...
А что, затыкал стораджами стойку да и все. Благо, имеются файловые системы, способные это сохранить и извлечь.
Биты с байтами не путай. В итоге там жалкие 3ТБ в месяц - я дома-то могу хранить траффик десятигигабитного канала за два месяца, что говорить о специализированных фасилитях для этого дела?
Дели на 8