cap_bpf

[nightfly]

Ровно 3 вопроса:

 

1. А возможно ли посмотреть что творит сабжевый модуль в живую какнить?

2. Уроны пакетов на каких скоростях на нем начинаются и какого % соотношения достигать могут?

3. с smp у него часом никаких болезней не наблюдалось?

 

 

Спасибо за внимание, сижу-боюсь.

[madf]

Ровно 3 вопроса:

 

1. А возможно ли посмотреть что творит сабжевый модуль в живую какнить?

2. Уроны пакетов на каких скоростях на нем начинаются и какого % соотношения достигать могут?

3. с smp у него часом никаких болезней не наблюдалось?

 

 

Спасибо за внимание, сижу-боюсь.

Внутрь в него в основной цикл добавить журналирование.

Статистическими данными не владею.

SMP ничего специфического в систему не добавляет, влиять не должно.

[nightfly]

1. понял

2. около 50-70% трафика не учитываться может?

3. так и подозревал но решил для полной уверенности переспросить. (хотя одной сетевухе смп таки не понравился)

 

Если не bpf/divert то чем из рассчета на возрастающие скоростя? nf?

 

Видел темы вида "считается в 2 раза больше" и "вобще не считается" (по очевидным причинам), но тем вида "ловиться от 30 до 70% трафика" еще тут не встречал.

Основная проблема в том что просто не могу просечь когда началось - связано ли с потоком или таки с последними переборками ядра.. или еще с чем.

[madf]

1. понял

2. около 50-70% трафика не учитываться может?

3. так и подозревал но решил для полной уверенности переспросить. (хотя одной сетевухе смп таки не понравился)

 

Если не bpf/divert то чем из рассчета на возрастающие скоростя? nf?

 

Видел темы вида "считается в 2 раза больше" и "вобще не считается" (по очевидным причинам), но тем вида "ловиться от 30 до 70% трафика" еще тут не встречал.

Основная проблема в том что просто не могу просечь когда началось - связано ли с потоком или таки с последними переборками ядра.. или еще с чем.

divert дает 100% гарантию обсчета, но может вызывать тормоза роутера и тормозить сам трафик.

nf считает, вроже, точно, но с задержкой обратно пропорциональной частоте сброса данных от сенсора. При этом минимально нагружается stargazer.

[nightfly]

divert тормозной как сволочь - когда-то уже имел с ним проблемы, повторять не хочу.

nf чем можете посоветовать продуктивно експортить под фрю софтово?

 

Спасибо за внимание.

 

PS bpf точно не имеет шансов на жизнь при потоках в 80-120мбит? Ничего крутить не рекомендуется?

[madf]

divert тормозной как сволочь - когда-то уже имел с ним проблемы, повторять не хочу.

nf чем можете посоветовать продуктивно експортить под фрю софтово?

 

Спасибо за внимание.

 

PS bpf точно не имеет шансов на жизнь при потоках в 80-120мбит? Ничего крутить не рекомендуется?

На самом деле он написан очень неэффективно и подкрутить там есть чего. На это еще один из местных троллей в прошлом году обращал внимание. Просто у меня никогда небыло под рукой FreeBSD чтобы нормально заняться этим плагином.

По поводу NetFlow - говорят, фря это как-то сама умеет (админ наш так говорит и, по идее, у нас так реализовано). Только я не знаю как это делается. Из альтернативных решений - fprobe. Она написана с использованием libpcap и должна работать и под фрей.

[nightfly]

По поводу NetFlow - говорят, фря это как-то сама умеет

видимо намекает на softflowd и flow-tools

 

Ок, спасибо - буду пробовать.

[nightfly]

cap_nf + softflowd, поток около 80 Мбит, два часа полет нормальный, точность потрясает.

Stg v. 2.406-rc1

Module: 'CAP_NF v. 0.3'

 

Хозяйке на заметку: как показала практика проблемы теряния трафика у cap_bpf начинаются на скоростях от 20 мбит/с на затюненом в усмерть sysctl.

 

Спасибо еще раз за добрый совет.

[madf]

cap_nf + softflowd, поток около 80 Мбит, два часа полет нормальный, точность потрясает.

Stg v. 2.406-rc1

Module: 'CAP_NF v. 0.3'

 

Хозяйке на заметку: как показала практика проблемы теряния трафика у cap_bpf начинаются на скоростях от 20 мбит/с на затюненом в усмерть sysctl.

 

Спасибо еще раз за добрый совет.

Хочу предупредить об одном маленьком побочном эффекте. Если используется авторизация пользователей через mod_auth_ia - часть трафика полученного непосредственно перед отключением юзера не будет учитана.

Происходит это потому что после разавторизации для пользователя прекращается обсчет трафика, а сенсор отдает данные с некоторой задержкой. В будущем это будет исправлено (я думаю к 407-й версии).

[nightfly]

always_online поголовно, с другой стороны в сенсоре ж можно выкрутить до минимума flows expiring time если хочется бояться за каждый байт.

[madf]

always_online поголовно, с другой стороны в сенсоре ж можно выкрутить до минимума flows expiring time если хочется бояться за каждый байт.

При выкручивании теряется вся прелесть такого подхода. Это тогда будет более тормозной аналог ipq/divert

[nightfly]

Согласен.

 

С другой стороны прелестью nf считаю возможность вынести сенсор подальше от биллинга отдав только под это все ресурсы целевого хоста

[vlad5503]

Прочитал манал по Stargazer-у, но не нашел нигде упоминания или запрета использовать вместо имени интерфейса ip-адрес.

Т.е. есть модули учитывающие трафик, такие как mod_cap_bpf.co. В описании сказано, что параметр в iface прописываеться имя интерфейса, например как em0, re0 и т.п.

Хотел узнать у тех кто пробовал вместо имени вписать адрес - работает при этом Stargazer или нет?

Причина вопроса возникла после падения интерфейса, а на нем был прописан ещё алиас. И после поднятия, адрес алиаса стал первым. И запросы/ответы клиентам пошли не от основного адреса а от алиаса. В следствии чего авторизаторы у клиентов покраснели.

Дабы избежать такого в будущем хотел как-то зафиксировать работу stargazera и ip-адреса меж собой.

Спасибо за ответы и советы.

[madf]

Ну могли бы и сами проверить. Делов-то на пару минут. Но я сразу скажу — не работает.

Используйте другие плагины захвата трафика: cap_divert например, или cap_nf и какой-нибуть NetFlow-сенсор.

[vlad5503]

Для сбора статистики используем NetFlow, Тут проблема как раз в работе между Авторизатором и сервером. Нужно заставить сервер Stargazer работать с определённого для этого IP-адреса.

[madf]

Для сбора статистики используем NetFlow, Тут проблема как раз в работе между Авторизатором и сервером. Нужно заставить сервер Stargazer работать с определённого для этого IP-адреса.

Если у вас NetFlow то при чем тут cap_bpf?

 

К авторизации оно вообще отношения не имеет. И привязать авторизатор к какому-то локальному IP нельзя (хотя и не невозможно), он всегда шлет с подходящего по нужному маршруту.

Вообще вам бы с физикой проблему решить, а не костыли городить.

[vlad5503]

Согласен модуль cap_bpf не имеет отношения. Однако только в нем указаны имена интерфейсов которые слушает старгейзер.

Далее...

Авторизатору задается адрес или имя сервера. В данном случае был собран авторизатор с адресом и раздавался клиентам.

Авторизатор отсылает и принимает данные на/от адреса 192.168.128.1. Сервер имеет адрес 192.168.128.1 и алиас 192.168.128.5.

После падения интерфейса основной адрес сервера пропал, остался только алиас.

Прописал с консоли адрес 19.168.128.1. Вроде бы интернет заработал у людей, но вот авторизаторы были красными. Потому как сервер отправлял запросы и ответы от адреса 192.168.128.5.

В итоге пришлось удалить оба адреса и заново прописать 192.168.128.1 - основнй, 192.168.128.5 - алиасом. После этого авторизаторы позеленели.

 

Вот дабы избежать такой ситуации, что можете предложить?

[madf]

Согласен модуль cap_bpf не имеет отношения. Однако только в нем указаны имена интерфейсов которые слушает старгейзер.

Которые слушает модуль захвата.

 

Далее...

Авторизатору задается адрес или имя сервера. В данном случае был собран авторизатор с адресом и раздавался клиентам.

Авторизатор отсылает и принимает данные на/от адреса 192.168.128.1. Сервер имеет адрес 192.168.128.1 и алиас 192.168.128.5.

После падения интерфейса основной адрес сервера пропал, остался только алиас.

Прописал с консоли адрес 19.168.128.1. Вроде бы интернет заработал у людей, но вот авторизаторы были красными. Потому как сервер отправлял запросы и ответы от адреса 192.168.128.5.

В итоге пришлось удалить оба адреса и заново прописать 192.168.128.1 - основнй, 192.168.128.5 - алиасом. После этого авторизаторы позеленели.

 

Вот дабы избежать такой ситуации, что можете предложить?

Не использовать алиасы. Не допускать пропадания линка. При пропадании линка вычищать алиасы с ним связанные.