Перейти к содержимому
Калькуляторы

sFlow на dlink DES-3200 на e-core так работало

Иногда хотим смотреть, что шлёт абонент в порт. Для этих целей на свичах доступа включаем sflow на определённое время, смотрим, потом оно само отключается. На свичах edge-core 3528M такое даже работало -- прилетали сами семплы трафика (прям пакеты arp и другие), глядя на которые можно было сказать, что у абонента не так с настройками. Взял первый попавшийся длин (3200-10), пытаюсь с него получить то же самое -- фреймы с порта абонента. Делаю примерно так:

enable sflow
create sflow analyzer_server 1 owner TEST1
config sflow analyzer_server 1 timeout 120 collectoraddress 192.168.253.237
create sflow counter_poller ports 1-10 analyzer_server_id 1 interval 30
create sflow flow_sampler ports 1-10 analyzer_server_id 1 rate 1000 maxheadersize 128

 

Но при этом прилетают не сами фреймы, а статистика счётчиков коммутатора:

$ sflowtool -p 6343 -g
13/Sep/2016:16:50:22 - 0 0 0:0 0:0 0:0 startDatagram =================================
13/Sep/2016:16:50:22 - 0 0 0:0 0:0 0:0 datagramSourceIP 192.168.251.235
13/Sep/2016:16:50:22 - 0 0 0:0 0:0 0:0 datagramSize 1188
13/Sep/2016:16:50:22 - 0 0 0:0 0:0 0:0 unixSecondsUTC 1473760222
13/Sep/2016:16:50:22 - 0 0 0:0 0:0 0:0 datagramVersion 5
13/Sep/2016:16:50:22 192.168.251.235 1 0 0:0 0:0 0:0 agentSubId 1
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:0 0:0 0:0 agent 192.168.251.235
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:0 0:0 0:0 packetSequenceNo 4
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:0 0:0 0:0 sysUpTime 363283770
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:0 0:0 0:0 samplesInPacket 10
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:0 0:2 0:0 startSample ----------------------
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:0 0:2 0:0 sampleType_tag 0:2
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:0 0:2 0:0 sampleType COUNTERSSAMPLE
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:0 0:2 0:0 sampleSequenceNo 4
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:0 sourceId 0:1
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 counterBlock_tag 0:1
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifIndex 1
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 networkType 6
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifSpeed 0
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifDirection 3
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifStatus 0
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifInOctets 408975010354
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifInUcastPkts 55817378
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifInMulticastPkts 308303574
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifInBroadcastPkts 81077
13/Sep/2016:16:50:22 192.168.251.235 1 4 0:1 0:2 0:1 ifInDiscards 0
...

 

Она нафик не нужна, хочу трафик смотреть вот так: "$ sflowtool -p 6343 -t | tcpdump -r - -ne", но так ничего не показывает. Пару лет назад на е-корах делал примерно то же самое и видел трафик.

 

Может быть можно как-то иначе настроить свич, чтобы видеть пакетики в tcpdump ? "sampleType COUNTERSSAMPLE" изменить ? Как ?

 

Ещё я не нашёл в документации описания этих команд, взял с какой-то презентации. Непонятно, как конфигурить выбрку, "rate 1000" это один из тысячи пакетов или что-то другое означает ? На корках весь трафик видеть не получалось, но каждый второй пакет получалось.

 

Ну может конечно это не каждый второй пакет был, но какие-то пакеты показывало :-) Обычно при проблемах у абонента на порту трафика практически нет и увиденного вполне хватало для диагностики.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1. Из мануала:

rate

-

(Optional) Specify the sampling rate for packet sampling. <value 0-65535>

- Specify the sampling rate for packet sampling. The configured rate value multiplied by 256 is the actual rate. For example, if the rate is 20, the actual rate 5120. One packet will be sampled from every 5120 packets. If set to 0, the sampler is disabled. If the rate is not specified, its default value is 0.

 

2. Вам не Sflow нужен, а RSPAN, наверное?

 

3. Формат коммутатор отдаёт именно такой, и его не перенастроить. Он же описан в довольно старой презенташке: http://ftp.dlink.ru/pub/Trainings/SwitchWhitePapers/sFlow.pdf

Изменено пользователем pkozik

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

RSPAN на D-Link-ах http://forum.dlink.ru/viewtopic.php?f=2&t=137094

В конце есть дока.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1. Из мануала:

rate

-

(Optional) Specify the sampling rate for packet sampling. <value 0-65535>

- Specify the sampling rate for packet sampling. The configured rate value multiplied by 256 is the actual rate. For example, if the rate is 20, the actual rate 5120. One packet will be sampled from every 5120 packets. If set to 0, the sampler is disabled. If the rate is not specified, its default value is 0.

 

2. Вам не Sflow нужен, а RSPAN, наверное?

 

3. Формат коммутатор отдаёт именно такой, и его не перенастроить. Он же описан в довольно старой презенташке: http://ftp.dlink.ru/pub/Trainings/SwitchWhitePapers/sFlow.pdf

 

Спасибо за цитату из мануала. Я вчера методом научного тыка выяснил, что если не делать "create sflow counter_poller ...", то шлются сами пакеты.

enable sflow
create sflow analyzer_server 1 owner TEST1
config sflow analyzer_server 1 timeout 120 collectoraddress 192.168.253.237
create sflow flow_sampler ports 9 analyzer_server_id 1 rate 1 tx_rate 1

так работает.

 

А можно этот множитель, который 256, сконфигурить поменьше ? Напрмиер, 1 или хотя бы 10 :-).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тут ещё вопрос возник: чем собирать COUNTERSSAMPLE ?

 

Замысел такой: берём кучу свичей, конфигурим их бесконечно долго раз в 5-30 минут слать COUNTERSSAMPLE'ы со всех портов вон в тот ойпи, а там складируем эти сэмплы и потом из этих данных можно сделать график любого порта.

 

sflowtool в этом плане не совсем адекватен -- не разделяет данные, может только в текстовом виде показывать, демоном не запускается. К нему идут какие-то простые скрипты, есть какие-то ключи запуска, но для продакшена это не годится.

 

sfcapd (из nfdump) складирует только пакеты, т.е. ловит сэмплы пакетов и делаетиз них такие же файлы, как деалет nfdump. Информации по каунтерам портов свиче там нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тут ещё вопрос возник: чем собирать COUNTERSSAMPLE ?

 

Замысел такой: берём кучу свичей, конфигурим их бесконечно долго раз в 5-30 минут слать COUNTERSSAMPLE'ы со всех портов вон в тот ойпи, а там складируем эти сэмплы и потом из этих данных можно сделать график любого порта.

 

sflowtool в этом плане не совсем адекватен -- не разделяет данные, может только в текстовом виде показывать, демоном не запускается. К нему идут какие-то простые скрипты, есть какие-то ключи запуска, но для продакшена это не годится.

 

sfcapd (из nfdump) складирует только пакеты, т.е. ловит сэмплы пакетов и делаетиз них такие же файлы, как деалет nfdump. Информации по каунтерам портов свиче там нет.

Для графиков по SNMP не проще будет собирать стандартную статистику в какой-нибудь Cacti и подобных? Или "хочется странного"?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тут ещё вопрос возник: чем собирать COUNTERSSAMPLE ?

 

Замысел такой: берём кучу свичей, конфигурим их бесконечно долго раз в 5-30 минут слать COUNTERSSAMPLE'ы со всех портов вон в тот ойпи, а там складируем эти сэмплы и потом из этих данных можно сделать график любого порта.

 

sflowtool в этом плане не совсем адекватен -- не разделяет данные, может только в текстовом виде показывать, демоном не запускается. К нему идут какие-то простые скрипты, есть какие-то ключи запуска, но для продакшена это не годится.

 

sfcapd (из nfdump) складирует только пакеты, т.е. ловит сэмплы пакетов и делаетиз них такие же файлы, как деалет nfdump. Информации по каунтерам портов свиче там нет.

Для графиков по SNMP не проще будет собирать стандартную статистику в какой-нибудь Cacti и подобных? Или "хочется странного"?

 

В какти конечно есть скрипты для автоматического создания хоста, но это не то :-). По идее с sflow телодвижений должно быть в разы меньше. Зачем-то же придумали sflow, надо разобраться зачем :-).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тут ещё вопрос возник: чем собирать COUNTERSSAMPLE ?

 

Замысел такой: берём кучу свичей, конфигурим их бесконечно долго раз в 5-30 минут слать COUNTERSSAMPLE'ы со всех портов вон в тот ойпи, а там складируем эти сэмплы и потом из этих данных можно сделать график любого порта.

 

sflowtool в этом плане не совсем адекватен -- не разделяет данные, может только в текстовом виде показывать, демоном не запускается. К нему идут какие-то простые скрипты, есть какие-то ключи запуска, но для продакшена это не годится.

 

sfcapd (из nfdump) складирует только пакеты, т.е. ловит сэмплы пакетов и делаетиз них такие же файлы, как деалет nfdump. Информации по каунтерам портов свиче там нет.

Для графиков по SNMP не проще будет собирать стандартную статистику в какой-нибудь Cacti и подобных? Или "хочется странного"?

 

В какти конечно есть скрипты для автоматического создания хоста, но это не то :-). По идее с sflow телодвижений должно быть в разы меньше. Зачем-то же придумали sflow, надо разобраться зачем :-).

Затем же, зачем и NetFlow - собирать статистику по соединениям и трафику. Только с SFlow она будет с большой погрешностью, т.к. захватываются не все пакеты. Мы сейчас пишем свой сборщик с хранением в БД для анализа профиля трафика по портам и протоколам + разбор DDoS атак на полосе 20Гбит. 10 дней всех flow в БД занимает 60Гб.

13:25:41 total2 Speed 10606Mb/s Samples/s 669   Flows: 17240
Statistics by destination ip address and bytes:
===== IP:     92.157.41.209     Speed:  103 Mbit/s       Flows:4
===== IP:     92.157.87.151     Speed:   90 Mbit/s       Flows:32
===== IP:    82.224.161.204     Speed:   89 Mbit/s       Flows:90
===== IP:      92.31.148.33     Speed:   87 Mbit/s       Flows:19
===== IP:    82.224.206.156     Speed:   82 Mbit/s       Flows:22
Statistics by source ip address and bytes:
===== IP:     95.142.201.66     Speed:  179 Mbit/s       Flows:172
===== IP:     95.142.201.67     Speed:  162 Mbit/s       Flows:175
===== IP:       31.13.72.53     Speed:  149 Mbit/s       Flows:255

Еще в отличии от NetFlow нельзя отследить начало/конец TCP-сессии.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тут ещё вопрос возник: чем собирать COUNTERSSAMPLE ?

 

Замысел такой: берём кучу свичей, конфигурим их бесконечно долго раз в 5-30 минут слать COUNTERSSAMPLE'ы со всех портов вон в тот ойпи, а там складируем эти сэмплы и потом из этих данных можно сделать график любого порта.

 

sflowtool в этом плане не совсем адекватен -- не разделяет данные, может только в текстовом виде показывать, демоном не запускается. К нему идут какие-то простые скрипты, есть какие-то ключи запуска, но для продакшена это не годится.

 

sfcapd (из nfdump) складирует только пакеты, т.е. ловит сэмплы пакетов и делаетиз них такие же файлы, как деалет nfdump. Информации по каунтерам портов свиче там нет.

Для графиков по SNMP не проще будет собирать стандартную статистику в какой-нибудь Cacti и подобных? Или "хочется странного"?

 

В какти конечно есть скрипты для автоматического создания хоста, но это не то :-). По идее с sflow телодвижений должно быть в разы меньше. Зачем-то же придумали sflow, надо разобраться зачем :-).

Затем же, зачем и NetFlow - собирать статистику по соединениям и трафику. Только с SFlow она будет с большой погрешностью, т.к. захватываются не все пакеты. Мы сейчас пишем свой сборщик с хранением в БД для анализа профиля трафика по портам и протоколам + разбор DDoS атак на полосе 20Гбит. 10 дней всех flow в БД занимает 60Гб.

13:25:41 total2 Speed 10606Mb/s Samples/s 669   Flows: 17240
Statistics by destination ip address and bytes:
===== IP:     92.157.41.209     Speed:  103 Mbit/s       Flows:4
===== IP:     92.157.87.151     Speed:   90 Mbit/s       Flows:32
===== IP:    82.224.161.204     Speed:   89 Mbit/s       Flows:90
===== IP:      92.31.148.33     Speed:   87 Mbit/s       Flows:19
===== IP:    82.224.206.156     Speed:   82 Mbit/s       Flows:22
Statistics by source ip address and bytes:
===== IP:     95.142.201.66     Speed:  179 Mbit/s       Flows:172
===== IP:     95.142.201.67     Speed:  162 Mbit/s       Flows:175
===== IP:       31.13.72.53     Speed:  149 Mbit/s       Flows:255

Еще в отличии от NetFlow нельзя отследить начало/конец TCP-сессии.

 

Это всё понятно, но я вдруг захотел собирать именно COUNTERSSAMPLE :-). Т.е. просто собираем счётчики свичей, которые их шлют, складируем в базу. Когда нам надо что-то посмотреть по конкретному свичу, тогда и лезем в эту базу, строим графики, ищем CRC ошибки и другие действия. Вот такой софтины я не нашёл.

 

Не подскажете софт который примерно так умеет ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.