aabc Опубликовано 29 ноября, 2013 · Жалоба S_ergey Спасибо, буду думать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 29 ноября, 2013 (изменено) · Жалоба S_ergey Сделал поддержку правильного времени согласно http://www.ietf.org/id/draft-ietf-behave-ipfix-nat-logging-01.txt Должно работать и в v9. См. git коммит dbcc0ebd. Изменено 29 ноября, 2013 пользователем aabc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
S_ergey Опубликовано 29 ноября, 2013 · Жалоба В v9 работает теперь прекрасно. nfdump -r nfcapd.201311291910 -onel "nat event add" |more Date first seen Event Proto Src IP Addr:Port Dst IP Addr:Port Src NAT IP Addr:Port Dst NAT IP Addr:Port 2013-11-29 19:11:07.666 ADD TCP 192.168.64.201:49380 -> 46.200.113.203:6881 26.157.166.45:49380 -> 46.200.113.203:6881 2013-11-29 19:11:07.667 ADD TCP 192.168.202.152:26293 -> 78.25.121.233:40786 26.157.166.47:26293 -> 78.25.121.233:40786 2013-11-29 19:11:07.667 ADD UDP 192.168.140.100:6881 -> 62.78.38.93:6881 26.157.166.31:6881 -> 62.78.38.93:6881 2013-11-29 19:11:07.667 ADD UDP 192.168.157.89:64550 -> 91.52.23.132:59995 26.157.166.3:1841 -> 91.52.23.132:59995 2013-11-29 19:11:07.667 ADD TCP 192.168.203.20:26291 -> 78.57.233.48:52952 26.157.166.55:26291 -> 78.57.233.48:52952 2013-11-29 19:11:07.668 ADD TCP 192.168.61.39:8070 -> 94.29.40.13:51530 26.157.166.38:8070 -> 94.29.40.13:51530 2013-11-29 19:11:07.668 ADD TCP 192.168.202.121:3970 -> 193.106.64.36:52485 26.157.166.20:3970 -> 193.106.64.36:52485 2013-11-29 19:11:07.671 ADD UDP 192.168.214.69:45095 -> 81.215.169.232:22583 26.157.166.27:1844 -> 81.215.169.232:22583 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 29 ноября, 2013 · Жалоба S_ergey Благодарю за помощь в тестировании. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
~pavel~ Опубликовано 4 декабря, 2013 (изменено) · Жалоба Кто знает как nfdump заставить понимать NAT Addr:Port??? Посмотрел с помощью wireshark ipt_NETFLOW шлет порты правильно, а nfdump вместо Src NAT IP Addr:Port Dst NAT IP Addr:Port выдает X-Src IP Addr:Port X-Dst IP Addr:Port /usr/local/bin/nfcapd -w -D -p 30009 -u netflow -B 200000 -S 1 -P /var/data/nfsen/var/run/p30005.pid -z -I Nat -T nel -l /var/data/nfsen/profiles-data/live/Nat /usr/local/bin/nfdump -r nfcapd.201312041435 -onel "nat event add" | more Date first seen Event Proto Src IP Addr:Port Dst IP Addr:Port X-Src IP Addr:Port X-Dst IP Addr:Port 2013-12-04 14:35:00.012 ADD TCP 172.23.193.12:62645 -> 95.30.82.236:33848 34.52.73.161:1 -> 95.30.82.236:68 2013-12-04 14:35:00.012 ADD UDP 172.23.202.217:6881 -> 178.64.209.167:6881 34.52.73.187:1 -> 178.64.209.167:68 2013-12-04 14:35:00.012 ADD TCP 172.23.212.51:61807 -> 89.218.201.202:43453 34.52.73.166:1 -> 89.218.201.202:56 2013-12-04 14:35:00.016 ADD TCP 172.23.192.248:50505 -> 84.52.66.23:443 34.52.73.191:1 -> 84.52.66.23:68 2013-12-04 14:35:00.016 ADD TCP 172.23.220.182:60805 -> 46.162.255.73:46476 34.52.73.182:1 -> 46.162.255.73:68 2013-12-04 14:35:00.016 ADD TCP 172.23.200.35:57037 -> 82.131.58.247:21042 34.52.73.164:1 -> 82.131.58.247:68 2013-12-04 14:35:00.016 ADD TCP 172.23.200.35:57039 -> 5.164.179.104:6881 34.52.73.164:1 -> 5.164.179.104:68 2013-12-04 14:35:00.016 ADD TCP 172.23.200.35:57038 -> 193.34.160.56:28322 34.52.73.164:1 -> 193.34.160.56:68 2013-12-04 14:35:00.016 ADD TCP 172.23.200.35:57040 -> 85.194.226.97:16881 34.52.73.164:1 -> 85.194.226.97:56 Изменено 4 декабря, 2013 пользователем ~pavel~ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 4 декабря, 2013 · Жалоба ~pavel~ Поставьте версию nfdump 1.6.10 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
~pavel~ Опубликовано 4 декабря, 2013 · Жалоба Поставьте версию nfdump 1.6.10 Работает, спасибо! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
S_ergey Опубликовано 5 декабря, 2013 · Жалоба ~pavel~ В версии nfdump-1.6.11 можно поправить 351 и 352 строки файла nf_common.c - { "%nsap", 1, " X-Src IP Addr:Port ", String_xlateSrcAddrPort },// NEL Xlate Source Address:Port - { "%ndap", 1, " X-Dst IP Addr:Port ", String_xlateDstAddrPort },// NEL Xlate Destination Address:Port + { "%nsap", 1, " Src NAT IP Addr:Port ", String_xlateSrcAddrPort },// NEL Xlate Source Address:Port + { "%ndap", 1, " Dst NAT IP Addr:Port ", String_xlateDstAddrPort },// NEL Xlate Destination Address:Port Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
legioner0 Опубликовано 6 декабря, 2013 · Жалоба aabc, есть ли в планах использование расширенных возможностей netflow v9 и IPFIX, таких как указание типа трафика и тд? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 6 декабря, 2013 · Жалоба legioner0 Вы о чём? http://www.iana.org/assignments/ipfix/ipfix.xhtml Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
legioner0 Опубликовано 8 декабря, 2013 · Жалоба legioner0 Вы о чём? http://www.iana.org/assignments/ipfix/ipfix.xhtml Возможно мне промыли мозги маркетологи на Cisco Connect, но было обещанно, что при использовании технологии NBAR2 в ASR'ах (вроде) в NetFlow v9/IPFIX будет записываться гораздо больше информации кроме хост-порт-хост-порт-размер. Вплоть до url'ов в http и jitter в rtp. Эдакий SCE с экспортом в netflow. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 8 декабря, 2013 · Жалоба legioner0 Вы о чём? http://www.iana.org/assignments/ipfix/ipfix.xhtml Возможно мне промыли мозги маркетологи на Cisco Connect, но было обещанно, что при использовании технологии NBAR2 в ASR'ах (вроде) в NetFlow v9/IPFIX будет записываться гораздо больше информации кроме хост-порт-хост-порт-размер. Вплоть до url'ов в http и jitter в rtp. Эдакий SCE с экспортом в netflow. Спасибо за пояснение. А где, для начала, функционал NBAR/SCE в линуксе? По-моему, вы предлагаете экспортировать данные, которых в природе нет. Сначала нужно, чтоб была классификация траффика, а потом экспорт её результатов в netflow. Ну например, iptables поддерживает блокировку проходящего http трафика по урл? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
legioner0 Опубликовано 8 декабря, 2013 · Жалоба Спасибо за пояснение. А где, для начала, функционал NBAR/SCE в линуксе? По-моему, вы предлагаете экспортировать данные, которых в природе нет. Сначала нужно, чтоб была классификация траффика, а потом экспорт её результатов в netflow. Ну например, iptables поддерживает блокировку проходящего http трафика по урл? Я потому и спросил про планы. Возможно появится модуль который будет нести в себе функционал SCE, то есть классификации траффика, тогда в ipt_NETFLOW потребуется интерфейс через который будет передаваться классификация потока в обмен на данные о нем. Понятно, что без классификатора рассуждать о чем-то преждевременно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 8 декабря, 2013 · Жалоба legioner0 Делать NBAR/SCE это же целый отдельный проект, а не небольшая надстройка перед логгером. Пока такого в планах не было. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Igor Diakonov Опубликовано 3 февраля, 2014 (изменено) · Жалоба Странная ерундистика наблюдается. Debian Wheezy, ядро 3.11.8-custom-amd64 (стандартное 3.11 из wheezy-backports + несколько пропатченный под мои нужды bonding, посему "custom"). В conntrack на данный момент порядка 410000 записей, весь трафик идёт через ipt_netflow. Ставлю последнюю версию из гита - получаю количество active стремящееся к Maxflows. Т.е., ставлю 3 млн - получаю 2999000 +-, т.е. сколько потоков разрешили для ipt_netflow - столько ipt_netflow и использовал. Нашёл в экспорте пользователя с с 20тыс flow за 5 минут: 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 ...... 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 и т.п. Судя по tcpdump - пользователь просто что-то заливал на сервер гугла, заливка у него не прерывалась, порты не менялись и т.п. - по идее, это должен быть один поток. Поправил немного ipt_netflow-1.8 с sf.net, что бы он под 3.11 собирался, получаю на том же трафике Flows: active 264128, при conntrack -S entries 402529. То ли лыжи не едут, то ли в версии из гита что-то отломали. Изменено 3 февраля, 2014 пользователем Igor Diakonov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dbask Опубликовано 4 февраля, 2014 (изменено) · Жалоба Debian Wheezy 3.10-0.bpo.3-amd64 карточка intel X520-SR2, прерывания размазаны скриптом от интела по всем 8-ми ядрам. ipt_NETFLOW version 1.8.2, srcversion (null) грузит только первое ядро (cpu0) /proc/net/stat/ipt_netflow: ipt_NETFLOW version 1.8.2, srcversion (null) Flows: active 327533 (peak 1178709 reached 2d16h43m ago), mem 53735K, worker delay 1/250. Hash: size 524288 (mem 4096K), metric 1.42 [1.44, 1.16, 1.03]. MemTraf: 19161684 pkt, 17238795 K (pdu 48, 47649), Out 30034547390 pkt, 24896689407 K. Rate: 489339720 bits/sec, 75486 packets/sec; Avg 1 min: 472520586 bps, 72822 pps; 5 min: 460807637 bps, 71605 pps cpu# stat: <search found new [metric], trunc frag alloc maxflows>, sock: <ok fail cberr, bytes>, traffic: <pkt, bytes>, drop: <pkt, bytes> Total stat: 19605053757 23486762313 6566946713 [11.59], 0 0 0 0, sock: 218887377 0 0, 312940446 K, traffic: 30053709026, 24330007 MB, drop: 0, 0 K cpu0 stat: 2496200913 2952199008 849595899 [1.65], 0 0 0 0, sock: 218887377 0 0, 312940446 K, traffic: 3801794907, 3076173 MB, drop: 0, 0 K cpu1 stat: 2415899797 2928473121 829408822 [1.64], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3757881943, 3032303 MB, drop: 0, 0 K cpu2 stat: 2413877706 2918697890 814463593 [1.64], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3733161483, 3018178 MB, drop: 0, 0 K cpu3 stat: 2461515881 2901849434 819947835 [1.66], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3721797269, 2990040 MB, drop: 0, 0 K cpu4 stat: 2437185372 2993352732 801223189 [1.64], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3794575921, 3127805 MB, drop: 0, 0 K cpu5 stat: 2490411986 2928841432 820856206 [1.66], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3749697638, 2998402 MB, drop: 0, 0 K cpu6 stat: 2437960882 2942345144 825775525 [1.64], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3768120669, 3073674 MB, drop: 0, 0 K cpu7 stat: 2452001220 2921003552 805675644 [1.65], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3726679196, 3013429 MB, drop: 0, 0 K Protocol version 5 (netflow). Timeouts: active 1800, inactive 15. Maxflows 20000000 Natevents disabled, count start 0, stop 0. sock0: 172.21.21.2:8819, sndbuf 245760, filled 1, peak 64513; err: sndbuf reached 0, connect 0, other 0 можно ли заставить этот модуль параллелиться по всем 8-ми ядрам? спасибо Изменено 4 февраля, 2014 пользователем dbask Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
legioner0 Опубликовано 26 февраля, 2014 · Жалоба legioner0 Делать NBAR/SCE это же целый отдельный проект, а не небольшая надстройка перед логгером. Пока такого в планах не было. Циска подвозит технологии, http://newsroom.cisco.com/release/1354502 =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 25 марта, 2014 · Жалоба Debian Wheezy 3.10-0.bpo.3-amd64 карточка intel X520-SR2, прерывания размазаны скриптом от интела по всем 8-ми ядрам. ipt_NETFLOW version 1.8.2, srcversion (null) грузит только первое ядро (cpu0) /proc/net/stat/ipt_netflow: ipt_NETFLOW version 1.8.2, srcversion (null) Flows: active 327533 (peak 1178709 reached 2d16h43m ago), mem 53735K, worker delay 1/250. Hash: size 524288 (mem 4096K), metric 1.42 [1.44, 1.16, 1.03]. MemTraf: 19161684 pkt, 17238795 K (pdu 48, 47649), Out 30034547390 pkt, 24896689407 K. Rate: 489339720 bits/sec, 75486 packets/sec; Avg 1 min: 472520586 bps, 72822 pps; 5 min: 460807637 bps, 71605 pps cpu# stat: <search found new [metric], trunc frag alloc maxflows>, sock: <ok fail cberr, bytes>, traffic: <pkt, bytes>, drop: <pkt, bytes> Total stat: 19605053757 23486762313 6566946713 [11.59], 0 0 0 0, sock: 218887377 0 0, 312940446 K, traffic: 30053709026, 24330007 MB, drop: 0, 0 K cpu0 stat: 2496200913 2952199008 849595899 [1.65], 0 0 0 0, sock: 218887377 0 0, 312940446 K, traffic: 3801794907, 3076173 MB, drop: 0, 0 K cpu1 stat: 2415899797 2928473121 829408822 [1.64], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3757881943, 3032303 MB, drop: 0, 0 K cpu2 stat: 2413877706 2918697890 814463593 [1.64], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3733161483, 3018178 MB, drop: 0, 0 K cpu3 stat: 2461515881 2901849434 819947835 [1.66], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3721797269, 2990040 MB, drop: 0, 0 K cpu4 stat: 2437185372 2993352732 801223189 [1.64], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3794575921, 3127805 MB, drop: 0, 0 K cpu5 stat: 2490411986 2928841432 820856206 [1.66], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3749697638, 2998402 MB, drop: 0, 0 K cpu6 stat: 2437960882 2942345144 825775525 [1.64], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3768120669, 3073674 MB, drop: 0, 0 K cpu7 stat: 2452001220 2921003552 805675644 [1.65], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3726679196, 3013429 MB, drop: 0, 0 K Protocol version 5 (netflow). Timeouts: active 1800, inactive 15. Maxflows 20000000 Natevents disabled, count start 0, stop 0. sock0: 172.21.21.2:8819, sndbuf 245760, filled 1, peak 64513; err: sndbuf reached 0, connect 0, other 0 можно ли заставить этот модуль параллелиться по всем 8-ми ядрам? спасибо Как нибудь решилась проблема? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 26 марта, 2014 (изменено) · Жалоба cpu0 stat: 2496200913 2952199008 849595899 [1.65], 0 0 0 0, sock: 218887377 0 0, 312940446 K, traffic: 3801794907, 3076173 MB, drop: 0, 0 K cpu1 stat: 2415899797 2928473121 829408822 [1.64], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3757881943, 3032303 MB, drop: 0, 0 K cpu2 stat: 2413877706 2918697890 814463593 [1.64], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3733161483, 3018178 MB, drop: 0, 0 K cpu3 stat: 2461515881 2901849434 819947835 [1.66], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3721797269, 2990040 MB, drop: 0, 0 K cpu4 stat: 2437185372 2993352732 801223189 [1.64], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3794575921, 3127805 MB, drop: 0, 0 K cpu5 stat: 2490411986 2928841432 820856206 [1.66], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3749697638, 2998402 MB, drop: 0, 0 K cpu6 stat: 2437960882 2942345144 825775525 [1.64], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3768120669, 3073674 MB, drop: 0, 0 K cpu7 stat: 2452001220 2921003552 805675644 [1.65], 0 0 0 0, sock: 0 0 0, 0 K, traffic: 3726679196, 3013429 MB, drop: 0, 0 K можно ли заставить этот модуль параллелиться по всем 8-ми ядрам? Это статистика по отсылкам самого netflowа, она и должна быть на одном cpu и много нагрузки не делает. Обработка трафика у вас происходит на всех процах равномерно (см. первые столбцы). Так что на самом деле у вас всё ок. Странная ерундистика наблюдается. Debian Wheezy, ядро 3.11.8-custom-amd64 (стандартное 3.11 из wheezy-backports + несколько пропатченный под мои нужды bonding, посему "custom"). В conntrack на данный момент порядка 410000 записей, весь трафик идёт через ipt_netflow. Ставлю последнюю версию из гита - получаю количество active стремящееся к Maxflows. Т.е., ставлю 3 млн - получаю 2999000 +-, т.е. сколько потоков разрешили для ipt_netflow - столько ipt_netflow и использовал. Нашёл в экспорте пользователя с с 20тыс flow за 5 минут: 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 ...... 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 192.168.170.51 173.194.71.116 6 56308 80 1470 1 и т.п. Судя по tcpdump - пользователь просто что-то заливал на сервер гугла, заливка у него не прерывалась, порты не менялись и т.п. - по идее, это должен быть один поток. Поправил немного ipt_netflow-1.8 с sf.net, что бы он под 3.11 собирался, получаю на том же трафике Flows: active 264128, при conntrack -S entries 402529. То ли лыжи не едут, то ли в версии из гита что-то отломали. Так эта проблема решилась? Похоже что потоки экспортятся по 1 пакету, на это влияет active/intactive таймауты. Посмотрите статистику (на Timeouts), когда такое происходит, и желательно tcpdump, чтоб убедиться что потоки абсолютно одинаковые. Изменено 26 марта, 2014 пользователем aabc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dnvk Опубликовано 15 мая, 2014 · Жалоба Добрый день. Внезапно захотелось обновиться. Попытался собрать ipt_netflow, но не тут-то было. ./configure Kernel version: 3.14.4-smp (uname) Kernel sources: /lib/modules/3.14.4-smp/build (found) Kernel config file checked: /lib/modules/3.14.4-smp/build/.config ! Attention: CONFIG_NF_CONNTRACK_EVENTS is undefined in your kernel configuration ! Without this option enabled natevents will not work. ! Attention: CONFIG_IPV6 is undefined in your kernel configuration ! Without this option enabled IPv6 will not work. ! Attention: CONFIG_IP6_NF_IPTABLES is undefined in your kernel configuration ! Without this option enabled ip6tables target will not work. Iptables binary version: 1.4.21 (detected from /usr/sbin/iptables) pkg-config for version 1.4.21 exists: Yes Checking for presence of xtables.h... Yes (using pkg-config) Iptables include flags: (pkg-config) Iptables module path: /usr/lib/xtables (pkg-config) Creating Makefile.. done. Now run: make all install make Compiling for kernel 3.14.4-smp make -C /lib/modules/3.14.4-smp/build M=/tmp/ipt-netflow modules make[1]: Entering directory `/usr/src/linux-3.14.4' CC [M] /tmp/ipt-netflow/ipt_NETFLOW.o /tmp/ipt-netflow/ipt_NETFLOW.c:2130:70: warning: 'struct nf_ct_event' declared inside parameter list [enabled by default] /tmp/ipt-netflow/ipt_NETFLOW.c:2130:70: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] /tmp/ipt-netflow/ipt_NETFLOW.c: In function 'netflow_conntrack_event': /tmp/ipt-netflow/ipt_NETFLOW.c:2136:27: error: dereferencing pointer to incomplete type /tmp/ipt-netflow/ipt_NETFLOW.c:2147:13: error: dereferencing pointer to incomplete type /tmp/ipt-netflow/ipt_NETFLOW.c:2147:13: error: dereferencing pointer to incomplete type /tmp/ipt-netflow/ipt_NETFLOW.c:2147:13: error: dereferencing pointer to incomplete type /tmp/ipt-netflow/ipt_NETFLOW.c:2149:17: error: dereferencing pointer to incomplete type /tmp/ipt-netflow/ipt_NETFLOW.c: At top level: /tmp/ipt-netflow/ipt_NETFLOW.c:2205:15: error: variable 'ctnl_notifier' has initializer but incomplete type /tmp/ipt-netflow/ipt_NETFLOW.c:2206:2: error: unknown field 'fcn' specified in initializer /tmp/ipt-netflow/ipt_NETFLOW.c:2207:1: warning: excess elements in struct initializer [enabled by default] /tmp/ipt-netflow/ipt_NETFLOW.c:2207:1: warning: (near initialization for 'ctnl_notifier') [enabled by default] /tmp/ipt-netflow/ipt_NETFLOW.c: In function 'set_notifier_cb': /tmp/ipt-netflow/ipt_NETFLOW.c:2782:13: error: dereferencing pointer to incomplete type /tmp/ipt-netflow/ipt_NETFLOW.c:2782:13: error: dereferencing pointer to incomplete type /tmp/ipt-netflow/ipt_NETFLOW.c:2782:13: error: dereferencing pointer to incomplete type /tmp/ipt-netflow/ipt_NETFLOW.c:2785:3: error: implicit declaration of function 'nf_conntrack_register_notifier' [-Werror=implicit-function-declaration] /tmp/ipt-netflow/ipt_NETFLOW.c: In function 'unset_notifier_cb': /tmp/ipt-netflow/ipt_NETFLOW.c:2801:13: error: dereferencing pointer to incomplete type /tmp/ipt-netflow/ipt_NETFLOW.c:2801:13: error: dereferencing pointer to incomplete type /tmp/ipt-netflow/ipt_NETFLOW.c:2801:13: error: dereferencing pointer to incomplete type /tmp/ipt-netflow/ipt_NETFLOW.c:2804:4: error: implicit declaration of function 'nf_conntrack_unregister_notifier' [-Werror=implicit-function-declaration] /tmp/ipt-netflow/ipt_NETFLOW.c:2806:4: error: dereferencing pointer to incomplete type cc1: some warnings being treated as errors make[2]: *** [/tmp/ipt-netflow/ipt_NETFLOW.o] Error 1 make[1]: *** [_module_/tmp/ipt-netflow] Error 2 make[1]: Leaving directory `/usr/src/linux-3.14.4' make: *** [ipt_NETFLOW.ko] Error 2 До этого сборку проводил год назад (актуальной на то время версии ipt_netflow), с ядром 2.6.34.14. Там такой ерунды не было. Нынче не собирается ни прошлогодняя версия, ни версия из гитхаба. natevents, подозреваю, мне не нужны. ipt_netflow используется на машинках без NAT. ipv6 также с этих машин выпилено. Куда копать, как пофиксить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 26 июня, 2014 · Жалоба Ставлю последнюю версию из гита - получаю количество active стремящееся к Maxflows. Т.е., ставлю 3 млн - получаю 2999000 +-, т.е. сколько потоков разрешили для ipt_netflow - столько ipt_netflow и использовал. Информирую заинтересованных, что был такой баг в новой версии (которая после 1.8) и он примерно месяц назад пофиксен (в git). Куда копать, как пофиксить? ./configure --disable-conntrack Надо будет отключить conntrack фичи по умолчанию, чтоб не было таких проблем. Из нового: ещё больше снижена нагрузка на проц - люди пишут, что теперь работает на ~10Гбит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
X3KT0 Опубликовано 2 июля, 2014 · Жалоба Добрый день. Появилась задача: слушать трафик, приходящий из mirror-порта, и генерировать по нему NetFlow, из которого помимо прочего можно бы было понять VLAN, в котором содержался интересующий пакет. То есть, насколько я понял приведённую выше ссылку на IPFIX, это vlanid и dot1qVlanId. Возможно ли экспортировать эту информацию с помощью ipt_NETFLOW? Если да, то какой коллектор под Linux может воспринять и записать такую информацию и чем её потом обрабатывать? Умеют ли это flow-tools? Заранее спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Korxif Опубликовано 19 августа, 2014 (изменено) · Жалоба Как-то закисла тема последнее время. Вобщем для начала опишу сетап. У роутера нету свободных 10G портов для миррора и он сам не тянет экспорт нетфлоу. Пришли к супер-идее, заменили оптические патчкорды на сплиттеры 1:2. В итоге получили два волокна - в одном RX, во втором TX. Воткнули это дело в двухпортовую сетевуху. Трафик видно. На eth2 видим RX, на eth3 - TX. Есть нюанс, трафик, который надо вытащить - тэгированный. VLAN 5. Делаем следующее. Создаем eth2.5, eth3.5, бриджим эти интерфейсы в br5. Если этого не делать - трафик в цепочки iptables вообще не попадает. Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 2120M 1709G NETFLOW all -- br5 * 0.0.0.0/0 0.0.0.0/0 NETFLOW 2120M 1709G DROP all -- br5 * 0.0.0.0/0 0.0.0.0/0 Счетчики бегут, трафик идет, тут все зашибись. Теперь собственно к проблеме. Сразу поставили последний релиз (2.0), (1.8 не пробовали пока). Машинка - 2 проца по 4 ядра. Аптайм порядка 40-45 минут: Топ: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 29 root 20 0 0 0 0 R 50.1 0.0 31:08.29 ksoftirqd/6 41 root 20 0 0 0 0 R 49.8 0.0 31:19.24 events/6 2115 root 20 0 15028 1360 992 R 0.3 0.0 0:00.03 top Выжрато ядро 6 в 100%. # cat /proc/net/stat/ipt_netflow ipt_NETFLOW version 2.0, srcversion (null); aggr llist Flows: active 8388608 (peak 8388610 reached 0d0h58m ago), mem 1179648K, worker delay 1/1000 (1043537 ms, 564360000 us, 6685370:0 548139 [6]). Hash: size 33554432 (mem 262144K), metric 1.02 [1.00, 1.00, 1.00]. MemTraf: 639516873 pkt, 545446637 K (pdu 73, 11635), Out 1296179830 pkt, 1096417171 K. Rate: 3236060272 bits/sec, 463781 packets/sec; Avg 1 min: 3283345621 bps, 468409 pps; 5 min: 3331017617 bps, 475227 pps cpu# stat: <search found new [metric], trunc frag alloc maxflows>, sock: <ok fail cberr, bytes>, traffic: <pkt, bytes>, drop: <pkt, bytes> Total stat: 66149293 1914345635 401704429 [1.02], 0 5403230 0 380353434, sock: 432059 20 0, 617708 K, traffic: 1935696630, 1603382 MB, drop: 380394700, 180060658 K cpu0 stat: 2915373 80791502 17704298 [1.02], 0 245531 0 16640252, sock: 0 0 0, 0 K, traffic: 81855548, 68386 MB, drop: 16640252, 8038183 K cpu1 stat: 2986425 83220187 18278036 [1.02], 0 252849 0 17208452, sock: 69325 0 0, 99112 K, traffic: 84289771, 70513 MB, drop: 17208452, 8270421 K cpu2 stat: 2822755 78549678 17225977 [1.02], 0 240272 0 16194842, sock: 0 0 0, 0 K, traffic: 79580813, 66391 MB, drop: 16194842, 7797547 K cpu3 stat: 3453036 114923126 20861532 [1.02], 0 337446 0 17775181, sock: 0 0 0, 0 K, traffic: 118009477, 96530 MB, drop: 17775181, 8561261 K cpu4 stat: 2785497 77483781 16990190 [1.02], 0 234650 0 15966125, sock: 0 0 0, 0 K, traffic: 78507846, 65492 MB, drop: 15966125, 7691030 K cpu5 stat: 3092238 86109483 18881798 [1.02], 0 263828 0 17774989, sock: 0 0 0, 0 K, traffic: 87216292, 73133 MB, drop: 17774989, 8569047 K cpu6 stat: 45055804 1308927750 273327582 [1.02], 0 3574141 0 261494774, sock: 362734 20 0, 518596 K, traffic: 1320760558, 1091455 MB, drop: 261536040, 122787723 K cpu7 stat: 3038166 84340143 18435019 [1.02], 0 254513 0 17298822, sock: 0 0 0, 0 K, traffic: 85476340, 71479 MB, drop: 17298822, 8345442 K Protocol version 5 (netflow). Timeouts: active 1800s, inactive 15s. Maxflows 8388608 sock0: x.x.x.x:3090, sndbuf 124928, filled 1, peak 125529; err: sndbuf reached 20, connect 0, other 0 Трафика, как видно, до 4Gbit. Дроп нехилый. Куда копать? p.s. пока писал, вылезли ошибки с sndbuf в messages. Увеличили вдвое. Ситуация несколько изменилась. Но основная проблема не исчезла :( Аптайм машины 6 минут. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17 root 20 0 0 0 0 R 99.3 0.0 4:08.86 ksoftirqd/3 35 root 20 0 0 0 0 S 5.0 0.0 0:11.79 events/0 38 root 20 0 0 0 0 S 0.7 0.0 0:01.52 events/3 4 root 20 0 0 0 0 S 0.3 0.0 0:00.62 ksoftirqd/0 1701 root 20 0 15028 1360 988 R 0.3 0.0 0:00.05 top # cat /proc/net/stat/ipt_netflow ipt_NETFLOW version 2.0, srcversion (null); aggr llist Flows: active 599148 (peak 627646 reached 0d0h1m ago), mem 84255K, worker delay 1/1000 (0 ms, 0 us, 288:0 0 [0]). Hash: size 33554432 (mem 262144K), metric 1.01 [1.00, 1.00, 1.00]. MemTraf: 101703658 pkt, 84540272 K (pdu 54, 8633), Out 76262730 pkt, 54314700 K. Rate: 3496815744 bits/sec, 541951 packets/sec; Avg 1 min: 3451231576 bps, 539759 pps; 5 min: 3033944030 bps, 474634 pps cpu# stat: <search found new [metric], trunc frag alloc maxflows>, sock: <ok fail cberr, bytes>, traffic: <pkt, bytes>, drop: <pkt, bytes> Total stat: 2533405 166755468 11210866 [1.01], 0 319949 0 0, sock: 353723 0 0, 505713 K, traffic: 177966334, 135600 MB, drop: 0, 0 K cpu0 stat: 100198 6064573 432780 [1.01], 0 17496 0 0, sock: 353723 0 0, 505713 K, traffic: 6497353, 5109 MB, drop: 0, 0 K cpu1 stat: 84733 5150951 370848 [1.01], 0 15036 0 0, sock: 0 0 0, 0 K, traffic: 5521799, 4291 MB, drop: 0, 0 K cpu2 stat: 93071 5658780 405349 [1.01], 0 16395 0 0, sock: 0 0 0, 0 K, traffic: 6064129, 4726 MB, drop: 0, 0 K cpu3 stat: 1884789 127550043 8401617 [1.01], 0 205825 0 0, sock: 0 0 0, 0 K, traffic: 135951660, 102809 MB, drop: 0, 0 K cpu4 stat: 97883 5905317 422811 [1.01], 0 17302 0 0, sock: 0 0 0, 0 K, traffic: 6328128, 4946 MB, drop: 0, 0 K cpu5 stat: 88348 5312464 381908 [1.01], 0 15564 0 0, sock: 0 0 0, 0 K, traffic: 5694372, 4433 MB, drop: 0, 0 K cpu6 stat: 89846 5410288 388253 [1.01], 0 15567 0 0, sock: 0 0 0, 0 K, traffic: 5798541, 4509 MB, drop: 0, 0 K cpu7 stat: 94537 5703060 407300 [1.01], 0 16764 0 0, sock: 0 0 0, 0 K, traffic: 6110360, 4773 MB, drop: 0, 0 K Protocol version 5 (netflow). Timeouts: active 1800s, inactive 15s. Maxflows 8388608 sock0: x.x.x.x:3090, sndbuf 249856, filled 1, peak 17681; err: sndbuf reached 0, connect 0, other 0 Изменено 19 августа, 2014 пользователем Korxif Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 21 августа, 2014 · Жалоба (Nag не всегда шлет уведомления на почту о новых сообщениях в треде.) Добрый день. Появилась задача: слушать трафик, приходящий из mirror-порта, и генерировать по нему NetFlow, из которого помимо прочего можно бы было понять VLAN, в котором содержался интересующий пакет. То есть, насколько я понял приведённую выше ссылку на IPFIX, это vlanid и dot1qVlanId. Возможно ли экспортировать эту информацию с помощью ipt_NETFLOW? Если да, Возможно. ./configure --enable-vlan, единственное, вам надо направить этот трафик в iptables -j NETFLOW, для этого может понадобиться включить bridge-nf или типа того. то какой коллектор под Linux может воспринять и записать такую информацию и чем её потом обрабатывать? Умеют ли это flow-tools? Заранее спасибо. Этого я не знаю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aabc Опубликовано 21 августа, 2014 (изменено) · Жалоба Топ: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 29 root 20 0 0 0 0 R 50.1 0.0 31:08.29 ksoftirqd/6 41 root 20 0 0 0 0 R 49.8 0.0 31:19.24 events/6 2115 root 20 0 15028 1360 992 R 0.3 0.0 0:00.03 top Выжрато ядро 6 в 100%. Flows: active 8388608 (peak 8388610 reached 0d0h58m ago), mem 1179648K, worker delay 1/1000 (1043537 ms, 564360000 us, 6685370:0 548139 [6]). Это грузит экспортер (такое возникает при хитрых конфигурациях с бриджами и огромном траффике), у вас он на 6м cpu. Увеличьте параметр sysctl net.netflow.scan-min на 10 и выше, это снизит нагрузку. Для этого вам придется поставить версию из git. Изменено 21 августа, 2014 пользователем aabc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...