|
| 1.2, ReT (?), 01:12, 19/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
 Очень громкое заявление и очень далекое от действительности. Продукт обрабатывающий 10Гбит поток претендует на очень многое, вот nPulse и прыгает выше головы. Простая арифметика: предположим поймали всего 10Гб за минуту (в принципе реально у какого-нибудь телекома). Что с этим делать в pcap формате? Ведь реально это plain файл без какого-либо индекса. Сам Wireshark перечитывает его после каждого "чиха" пользователя, с реально большими трейсами в принципе работать невозможно.
Писал аналог(к сожалению закрытый), основной упор на работу в режиме реального времени. Заказчик решил обеспечить возможность подключения шарка как внешнего анализатора(протоколов уж больно много знает). Извращались как могли, в конце концов даже диссекторы(декодируют протоколы) выдернули и попытались использовать только их. 2000 пакетов/сек --- просто предел. Соответственно в реальном времени строить сущности более высоких уровней(сессии, вызовы) в принципе нереально, а кого сейчас заинтересует возможность видеть 10Гбит пакетов в секунду? Кого сейчас вообще пакеты волнуют? Пропускной способности шарка не хватит и для 1Гбит/сек.
Продукт с громким названием сохраняет часть проходящего трафика(низкоуровневые быстрые фильтры у них точно есть) нарезая его на разумного размера pcap файлы, которые впоследствии могут быть открыты шарком.
Ни о какой связанности данных, детальной информации и режиме реального времени речь не идет. Поддержка современного стандарта да огромный диск вот и все технологии. Высокопроизводительный сканер будет довольствоваться образцами до 100Мб размером и анализировать их с очень заметными задержками.
Прошлый век с современным бантиком, одним словом.
| | |
| |
| 2.3, xGa (?), 08:21, 19/08/2009 [^] [^^] [^^^] [ответить] | –4 +/– | Мэйби вы тоже далеки от реальности Такие скорости думаю более чем реальны Прим... большой текст свёрнут, показать | | |
| |
| 3.4, pcapAnonymous (?), 09:26, 19/08/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
>[оверквотинг удален]
>скорости порта (до 10Гбит/с на порт), работают с живым трафиком, при
>этом не создают никаких задержек (прозрачным режим), но отлично контролируют полосу
>во все возможных решениях. Для аналитических махинаций использует коллектор, в который
>сливает NetFlow пакеты.
>Вот так и тут вполне спокойно люди могли допилить продукт до адекватного
>состояния, и натянув его на довольно таки производительную платформу.
>p.s. и заявления, что именно у вас ничего не вышло, звучит как
>"они все п***расы, один я д'артаньян", но при этом любой адекватный
>человек, вплотную работающий с технологиями магистрального масштаба скажет вам что вы
>просто неудачник и только позоритесь здесь своими громкими выхлопами.
1) пакетики этот сканер и их содержимое на таких скоростях может и покажет, но вот если начать работы по сбору сессии или еще более высокоуровневые операции то боюсь тормоза обеспечены.
Вопрос не в том что бы пропустить через себя такой трафик а проделать что то осмысленное и более менее сложное.
Особенно забавно если надо будет поднять статистику за большой промежуток времени - без соответствующей индексации это тоже проблема
2) большинство подобных железок имеет интересные ссылки что скорость 10 гигабит достигается на определенном размере пакета, так что на маленьких пакетах может быть весьма значительное падение скорости
| | |
| 3.8, ReT (?), 13:27, 19/08/2009 [^] [^^] [^^^] [ответить] | +/– | xGa, во-первых Вы меня не совсем поняли, во-вторых у Вас странное хобби бросатьс... большой текст свёрнут, показать | | |
| |
| 4.11, аноним (?), 16:29, 19/08/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Диалог производителя(П) подобного рода систем с телекомом(Т)
Мхату сто лет, браво! Уважаемый, сходите на сайт к ним и почитайте хотя бы. Ваши догадки, построенные на 'а у нас не получилось, значит это невозможно' тут мало кому интересны.
| | |
| |
| 5.15, ReT (?), 21:14, 19/08/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
>Мхату сто лет, браво! Уважаемый, сходите на сайт к ним и почитайте
>хотя бы.
Что Вас на сайте поразило? "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.
----------
Ваши аргументы?
| | |
| |
| 6.19, аноним (?), 22:17, 19/08/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Ваши аргументы?
Какие аргументы могут быть на эту глупость? Тут описана проблема интерфеса WS, которая при необходимости работы с большими дампами элементарно решается, и товарищи из nPulse ее решили. Вас еще раз послать к ним на сайт?
| | |
| |
| 7.20, ReT (?), 02:08, 20/08/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
>Какие аргументы могут быть на эту глупость? Тут описана проблема интерфеса WS,
>которая при необходимости работы с большими дампами элементарно решается, и товарищи
>из nPulse ее решили. Вас еще раз послать к ним на
>сайт?
Вот так уж и глупость и проблемы _интерфейса_? :) Просьбу процитировать сайт Вы проигнорировали, что вполне естественно и будет, я надеюсь, отмечено независимыми читателями.
Позвольте послать Вас чуть дальше, еще раз к этой странице и к исходному коду шарка.
| | |
|
|
|
|
|
| 2.10, pentarh (ok), 16:05, 19/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
 Думаю, если сливать инфу на HDFS и применять распределенный map/reduce хадопа, при определенном размере вычислительной сети можно делать анализ близко приближенный к реалтайму.
| | |
| 2.17, anonymous (??), 21:47, 19/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
С какого перепугу ты решил, что капчер дивайс это компьютер ? Все сетевое, что работает на скоростях больше 100 мб и сделано правильно это заказные процессоры (ASIC)или в крайнем случае стандартные нет-процессора вроде Марвела.
| | |
|
| 1.5, t0ly (?), 11:33, 19/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 по поводу неудачника не согласен.
т.к. netflow и pcap это немного разные вещие, в pcap может быть полный дам траффика, а в нетфлоу поопределению только заголовки.
| | |
| |
| 2.7, pcapAnonymous (?), 13:23, 19/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>А что мешает им pcap загонять в БД, а затем анализировать сессии
>итд?
Тем что в pcap файле находится весь перехваченный трафик. что бы это можно было записать в базу необходима обработка. Самая от полноты обработки зависит ресурсоемкость. Одно дело просто вытянуть ip адреса и совсем другое например уже из тех же пакетов востановить содержимое http сессии.
Вот и интересно какой уровень DPI (deep packet inspection) обеспечивает сабж
| | |
| |
| 3.13, аноним (?), 16:33, 19/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Тем что в pcap файле находится весь перехваченный трафик. что бы это
>можно было записать в базу необходима обработка. Самая от полноты обработки
>зависит ресурсоемкость. Одно дело просто вытянуть ip адреса и совсем другое
>например уже из тех же пакетов востановить содержимое http сессии.
Ресурсоемкость там минимальная, так что это вполне возможно. Минимум - анализ TCP сессий - вообще ничего не стоит, а прикладной уровень можно уже и налету при анализе разгрести.
| | |
| |
| 4.26, alexr_ (ok), 21:13, 22/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>Тем что в pcap файле находится весь перехваченный трафик. что бы это
>>можно было записать в базу необходима обработка. Самая от полноты обработки
>>зависит ресурсоемкость. Одно дело просто вытянуть ip адреса и совсем другое
>>например уже из тех же пакетов востановить содержимое http сессии.
>
>Ресурсоемкость там минимальная, так что это вполне возможно. Минимум - анализ TCP
>сессий - вообще ничего не стоит, а прикладной уровень можно уже
>и налету при анализе разгрести.
Я более трех лет занимаюсь анализом TCP сессий, И смею вас уверить что проблемм там очень много. Еще больше в SCTP особенно если их на лету из середины подхватывать надо.
Например Как вы защите от банального DoS а DDos?
А от 1000K++ сессий у вас как это в память для агрегирования поместится?
И чтобы при этом был минимум ресурсоемкость. И важные данные не пропустить.
А прикладной уровень какой-нибудь протокол на ASN.1 на лету в per encoding 8-) да вы батенька похоже ничего про него не знаете... (про прикладной уровень конечно)...
| | |
|
|
| 2.9, ReT (?), 13:31, 19/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>А что мешает им pcap загонять в БД, а затем анализировать сессии
>итд?
С БД, в общепринятом смысле, очень неэффективно. Berkeley DB --- существенно лучше.
| | |
| |
| 3.12, аноним (?), 16:31, 19/08/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>С БД, в общепринятом смысле, очень неэффективно. Berkeley DB --- существенно лучше.
Ну реляционное убожество понятно что нафиг не уперлось. BDB тоже страшно тормозная вещь. А достаточно всего лишь писать рядом с pcap файлом индекс.
| | |
| |
| 4.16, ReT (?), 21:19, 19/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Ну реляционное убожество понятно что нафиг не уперлось. BDB тоже страшно тормозная
>вещь. А достаточно всего лишь писать рядом с pcap файлом индекс.
Не сочтите за придирку, любопытства ради. Какой именно индекс?
| | |
| |
| 5.18, аноним (?), 22:13, 19/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
Подумайте, что вам с этим траффиком потом надо будет делать и ответ придет сам собой.
| | |
| |
| 6.21, ReT (?), 02:12, 20/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Подумайте, что вам с этим траффиком потом надо будет делать и ответ
>придет сам собой.
И это стоило писать? :)
Полное отсутствие конкретики, общие фразы и не совсем корректные наезды --- краткий итог Ваших ответов.
Друг мой, с Вами предельно неинтересно разговаривать --- Вы не в состоянии предоставить даже намек на полезную информацию.
Успехов :)
| | |
|
|
|
|
|
| 1.14, Tetragramaton (?), 18:55, 19/08/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Напоминает разговор доктора и пациента.
П. Доктор я ходить буду?
Д. Да но только под себя.
П. А плавать?
Д. Да если будете много ходить?
Я к тому что маршрут построить это значит перелопатить все файлы огромных размеров!
А в базе можно это хоть как то это вместе связать.
Никто не говорит что это нужно делать на шарманке 286. Хранилище должно быть как минимум данные за неделю это 10Gb/s x 60s x 60m x 24h x 7d = 6 048 TB понты хранить такой трафик? Если будут такие нагрузки? Карточка сделана для реалтайма не более ну и + захват если, что пошло не так.
| | |
| |
| 2.22, CaptainJack (?), 07:52, 20/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>быть как минимум данные за неделю это 10Gb/s x 60s x
>60m x 24h x 7d = 6 048 TB понты хранить
>такой трафик?
Формулу поправьте - 10Gb/s это БИТ в секунду, а не байт
| | |
| |
| 3.27, alexr_ (ok), 21:20, 22/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>быть как минимум данные за неделю это 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ПетаБайт в месяц а это реально дохрена...
| | |
| |
| 4.28, pentarh (ok), 22:53, 22/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
А что, затыкал стораджами стойку да и все. Благо, имеются файловые системы, способные это сохранить и извлечь.
| | |
|
|
| 2.24, аноним (?), 16:35, 20/08/2009 [^] [^^] [^^^] [ответить]
| +/– |
Биты с байтами не путай. В итоге там жалкие 3ТБ в месяц - я дома-то могу хранить траффик десятигигабитного канала за два месяца, что говорить о специализированных фасилитях для этого дела?
| | |
|
|
