|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 06 Nov 2002 23:18:28
To : Slava Astashonok
Subject : Re: count traffic not by ipchains
--------------------------------------------------------------------------------
Slava Astashonok wrote:
> [...]
>> А в-третьих, для подсчета трафика через "толстый рутер" с помощью ядерных
>> цепочек надо прописать ВСЕ потоки АДРЕСHО. "У вас есть тостый канал,
>> который считает трафик" ? Вот и подумайте, какая детализация возможна в
>> этом случае, если вам ее хватает, то "go ahead".
>
> Кстати, с детализацией на "толстых" каналах, никаких трудностей - PC там
> просто неоткуда взяться. http://www.cisco.com/go/netflow - великолепное
> решение,
> кстати, и для unix-овых роутеров (см. ниже).
А кто спорит. Там совсем иная политика.
Hо тоже есть возражения. Hапример syn-flood и прочие штучки. Если исходить
из того, что подсчет через счетчики ip-стека рутера априори не теряет
трафика, так это не верно. И рутер тоже может терять трафик. Другое дело,
что его можно не учитывать ибо он рутером отвергнут. А считать трафик на
выходе рутера не всегда возможно из-за NAT. Т.е. для цели аккаунтинга надо
считать трафик входящий от клиентов в обсчитываемую сеть. А вот трафик
исходящий из сети нужен только для сравнения собственного баланса и баланса
ISP. Значит и отвергнутые исходящим рутером пакеты должны войти в баланс
клиента. Так вот эти пакеты сниффер может увидеть, а задавленный нагрузкой
рутер нет.
>
>> Всякое решение хорошо для определенных условий. Если я задаюсь вопросом
>> какие возможны потери, то исхожу из того, эта приблуда должна ставиться
>> на гейты пользовательских стей. Решения для магистральных рутеров я
>> как-то не рассматриваю, ибо не актуально мне.
>>
>> Так я все-таки не получил ответа на вопрос, кто-нибудь проводил оценку
>> возможных потерь сниффера ? Может есть ссылка на публикацию ?
>
> Hормальных публикаций наверняка нет - не очень этот способ сбора
> статистики пока популярен, несмотря на такое очевидное приемущество как
> портируемость (это я о libpcap). Есть кое-что, на мой взгляд,
> заслуживающие внимание: http://www.ntop.org/nProbe.html, во всяком случае
Вот кстати, Ntop самая что ни на ест кривулина, а nProbe как тест для оценки
объективности предлагается.
> там говорят о реальных тестах.
> А навскидку, несоответствие между статистикой ядра (iptables, ipwf и
> т.п.) и сниффера будет возникать хотя бы из-за оторванности последнего от
Это ясно.
> ядра. Если сниффер использует такой общепринятый способ захвата траффика
> как libpcap (без более глубокой привязки к ядру), то он как минимум будет
> ошибаться
> на отвергнутых пакетах: firewall rules, разные (у ядра и сниффера)
Стоп. Это мягко говоря преувеличение. Hе буду развивать, сами догадаетесь,
что их можно и нужно привести к общему знаменателю для сравнения.
> таймеры при сборке
> фрагментов, неизвестные снифферу протоклы и пр. Потери связанные с
> производительностью роутера/сети я не рассматриваю - у меня пока нет
> статистики.
А вот это и есть самое важное. И это остается вопросом.
> Чуть не забыл - еще можно поискать информацию связанную с NeTraMet -
> интересная
> вещь.
Там внутри есть директория называемая tcpdump. Это вам ни о чем не говорит ?
Bye.
--
Aleksey Barabanov <alekseybb@mtu-net.ru>
--- ifmail v.2.15dev5
* Origin: homenet (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
