LINUX.ORG.RU
ФорумAdmin

snmp классификация трафика


0

1

Добрый день.
Кто-нибудь пытался решать задачу классификацию трафика по протоколу/порту (не активности интерфейса) и его активности при помощи snmp?


SNMP не для этого придумывали, и по нему такие данные не получить.

В худшем случае счетчики с правил firewall можно попробывать собирать.

netflow - ответ на еще не заданные вопрос :)

ну или SFlow если точность не нужна.

zhiltsov ()
Ответ на: комментарий от zhiltsov

>SNMP не для этого придумывали, и по нему такие данные не получить.

Мы не знаем, с какого устройства данные получать предполагается. С цыскороутеров трафик по протоколам с любого интерфейса через SNMP получается без особых затруднений (ip nbar protocol-discovery на интерфейсе, и вперед).

gaestur ()
Ответ на: комментарий от zhiltsov

>С цыскороутеров трафик по протоколам с любого интерфейса через SNMP получается без особых затруднений
Совершенно верно....

av ()
Ответ на: комментарий от Othniel

> Тебе точно не к SNMP. И вообще, старайся не трогать эту гадость, с ним мучений не оберёшься.
А в чем мучения?
Сейчас снимаю разную статистику(загрузка интерфейса, загрузка CPU, памяти, температуры) - и не каких мучений не испытываю. Вот только хотелось бы расширить функционал по аналогии с snmp от cisco, которые этот функционал имеют.

av ()
Ответ на: комментарий от av

> бы расширить функционал по аналогии с snmp от cisco, которые этот функционал имеют.

ВСё же, как тут уже сказали, это не к SNMP. SNMP - это просто способ получить данные от кого-то. И вот этот кто-то и нужен. Тот, кто будет трафик классифицировать. И, как опция, этот кто-то должен уметь отдать данные по SNMP.

AS ★★★★★ ()
Ответ на: комментарий от Nefer

>Цыскороутеры прекрасно отдают данные по netflow. SNMP это вообще из другой оперы.

Для netflow можно иметь не более двух ip flow-export destination, а через snmp данные nbar можно тянуть на столько машин, на сколько нужно. Очень даже из этой оперы.

gaestur ()
Ответ на: комментарий от gaestur

До до до! Дупликация пакетов - это магия, доступная только избранным! Не подскажете OID для цЫски для трафа на 80й порт? А что б еще гугловый отделить? Ну хотя бы россия-зарубеж разделить можно, а? Как всегда у нас котлеты с мухами потребляют... Бяда бяда.

Nefer ()
Ответ на: комментарий от Nefer

>До до до! Дупликация пакетов - это магия, доступная только избранным!

Ну, туп я - подскажи мне, пожалуйста, как с роутера раскидать нетфлоу на три анализатора, два из которых NAM-2, а один - вендомашина. На каком устройстве мне дупликацией пакетов заниматься - отдельную машину для этого заводить, слать на нее, с нее рассылать анализаторам?

Не подскажете OID для цЫски для трафа на 80й порт?


Делаем так:
интерфейсы по именам .1.3.6.1.4.1.9.9.244.1.8.1.1.2
протоколы .1.3.6.1.4.1.9.9.244.1.2.1.1.2
входящие байты для всего: .1.3.6.1.4.1.9.9.244.1.2.1.1.5
исходящие байты для всего: .1.3.6.1.4.1.9.9.244.1.2.1.1.6

К OID нужного вида трафика добавляем через точку последнее число в OID интерфейса и последнее число в OID протокола. Например, входящие байты для интерфейса №7 по протоколу №2 (для данного конкретного рутера - gi0/3/0, протокол http):

.1.3.6.1.4.1.9.9.244.1.2.1.1.5.7.2

Что характерно, Гугель и не думает хранить такие страшные тайны, а выдает на раз любому желающему.

В Cacti этим занимается замечательный сторонний скрипт ss_nbar_all.php, при наличии соответствующих темплейтов, разумеется. Его можно найти тем же Гуглом, и посмотреть на всякие OID. Да и Циска, при всем своём коварстве, MIB ни от кого не скрывает.

А что б еще гугловый отделить? Ну хотя бы россия-зарубеж разделить можно, а? Как всегда у нас котлеты с мухами потребляют... Бяда бяда.


Действительно, бяда. Где я в этом топике обещал через snmp получать данные о назначении трафика, а? И топикстартер об этом где просил? Срочно выбрасывай мух из котлет, не надо их есть, они лапки не моют!

gaestur ()
Ответ на: комментарий от gaestur

> Ну, туп я - подскажи мне, пожалуйста, как с роутера раскидать нетфлоу на три анализатора, два из которых NAM-2, а один - вендомашина. На каком устройстве мне дупликацией пакетов заниматься - отдельную машину для этого заводить, слать на нее, с нее рассылать анализаторам?

Не волнуйся, я еще тупее. Нахрена десять коллекторов? nfdump && nfreply если лениво и быстро. Кучка nfproxy в придачу. Да и просто udp forward много всяких приблуд. Ну это еще ладно, всякое бывает. Но вот то что циска несмотря на всю свою круть далеко не единственный производитель - факт. А если киваем на конкретику ТС, то он про железо не говорил. И в продолжение веселья - а как мускуль посмотреть? А, он не нужен. Жалька. он мне очень нравился. :( И постгрес ненужен? Нужен только маленький и мягкий? Не, спасибо. Я как ньть пешком постою.

Действительно, бяда. Где я в этом топике обещал через snmp получать данные о назначении трафика, а? И топикстартер об этом где просил? Срочно выбрасывай мух из котлет, не надо их есть, они лапки не моют!

Так все же - netflow && snmp из одной оперы или из разных? Как по snmp узнать сколько сессий было на OpenVPN? Как по netflow определить hostname и сколько интерфейсоф подняты? SNMP хорошая и годная штука. Но анализ трафика - не его область. И ненадо его туда толкать - by design область немного другая.

P.S. Да, я знаю, что и русский-нерусский траф можно через SNMP получить. Но это неправильный ход мысли.

Nefer ()
Ответ на: комментарий от Nefer

>Нахрена десять коллекторов? nfdump && nfreply если лениво и быстро. Кучка nfproxy в придачу. Да и просто udp forward много всяких приблуд.

Вот понадобилось. Одни коллеги предпочитают NAMы, расположенные в двух основных локациях, другие - FlowAnalyzer. Такая вот блажь. Насчет nfdump, nfreply, nfproxy - т.е, мне таки придется завести отдельную машину, на которой это все будет крутиться. А мне лениво. Перемучаемся одним NAMом и одним FlowAnalyzerом.

Но вот то что циска несмотря на всю свою круть далеко не единственный производитель - факт. А если киваем на конкретику ТС, то он про железо не говорил. И в продолжение веселья - а как мускуль посмотреть? А, он не нужен. Жалька. он мне очень нравился. :( И постгрес ненужен? Нужен только маленький и мягкий? Не, спасибо. Я как ньть пешком постою.


Дык а кто ж спорит - не единственный. Тут просто сразу начали писать, что snmp - гадость и ТСу не подходит. А посмотри на топик - ему надо только «задачу классификацию трафика по протоколу/порту (не активности интерфейса) и его активности при помощи snmp». На каком именно оборудовании это ему надо - мы, таки да, не знаем. Может оно умеет и snmp и netflow лучше всяких цысок.

Так зачем сразу говорить «snmp -гадость». В моей сети, на имеющемся в ней оборудовании, задача ТСа решается именно через SNMP, и все довольны.

Кстати, по запросам mysql+snmp и postgres+snmp Гугол выдает ненулевое количество примочек - сам я их, правда, не пробовал.

Так все же - netflow && snmp из одной оперы или из разных? Как по snmp узнать сколько сессий было на OpenVPN? Как по netflow определить hostname и сколько интерфейсоф подняты? SNMP хорошая и годная штука. Но анализ трафика - не его область. И ненадо его туда толкать - by design область немного другая.


P.S. Да, я знаю, что и русский-нерусский траф можно через SNMP получить. Но это неправильный ход мысли.


Для задачи, поставленной ТСом, в ее нынешнем виде, они однохренственны. А дальше - зависит от конкретики. Если надо «сколько байт/пакетов в секунду по протоколу такому-то на интерфейсе таком-то, нарисовать график» - ИМХО, snmp лучше. Если надо «сколько всего скачано по FTP за последнюю неделю с vasyapupkind.com? А за три дня?» - NetFlow. А что именно умеет отдавать сетевое оборудование автора топика - мы еще не знаем.

P.S. Запрос openvpn+snmp тоже отдает вовсе не девственно чистую страницу.

gaestur ()
Ответ на: комментарий от gaestur

Мир дружба жвачка!

Я не говорил что snmp гадость. Да, бывают там свои выкрутасы. Ну так и netflow не ангел. Одно только UDP и потери иногда заставляют сииильно чесать репу. И при прочих равных snmp развернуть проще. И система попроще и описана получшев большинстве случаев.

Nefer ()
Ответ на: Мир дружба жвачка! от Nefer

Взаимно!

А по теме - из имеющихся исходных уже выжали, похоже, что могли. Будут уточнения - будем думать.

gaestur ()
Ответ на: комментарий от gaestur

Не думал, что такой жаркий спор разгорится :), но такое глубокое обсуждение мне очень понравилось, для более глубокого понимания вопроса, за что обоим оппонентам большое спасибо :)

Теперь по существу.
Мне действительно нужно только сколько байт/пакетов в секунду по протоколу такому-то на интерфейсе таком-то смотреть и нарисовать график. А железо/софт для которого этот вопрос возник - является обычный компутер-роутер с OS linux на борту.

anonymous ()
Ответ на: комментарий от gaestur

Не думал, что такой жаркий спор разгорится :), но такое глубокое обсуждение мне очень понравилось, для более глубокого понимания вопроса, за что обоим оппонентам большое спасибо :)

Теперь по существу.
Мне действительно нужно только сколько байт/пакетов в секунду по протоколу такому-то на интерфейсе таком-то смотреть и нарисовать график. А железо/софт для которого этот вопрос возник - является обычный компутер-роутер с OS linux на борту.

av ()
Ответ на: комментарий от av

Покопавшись немного в сети, нашел руководство, как приспособить iptables+SNMP для подсчета трафика для отдельного клиента по ip адресу:

http://blog.ausweb.com.au/cacti-iptablesipfw-traffic-monitoring/

Переделав правила iptables можно сделать похожий счетчик для трафика для отдельных tcp или udp портов. Это, конечно, не полноценный анализатор по протоколам, но, ИМХО, лучше, чем ничего.

gaestur ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.