Кратко об общем или что нужно видеть не вставая с дивана.
Для начала нужно понимать, что мониторинг сетей – штука довольно щепетильная и тонкая, и внедрить её в уже работающий проект, не спроектированный с учётом требований и возможностей мониторинга является очень затратной статьей расходов, которая далеко не всегда может, в конечном итоге, удовлетворить требованиям заказчика. Зачастую, потребность в мониторинге появляется у довольно прилично разросшейся инфраструктуры, и потом начинаются танцы с бубном в борьбе за рациональный бюджет и максимальную эффективность сбора данных.
Поэтому best practice является планирование и внедрение мониторинга на стадии проектирования и продажи её вместе с проектом.
NetFlow — проприетарный открытый протокол, разработанный Cisco для мониторинга трафика в сети. Netflow предоставляет возможность анализа сетевого трафика на уровне сеансов, делая запись о каждой транзакции TCP/IP.
Архитектура системы строится на сенсоре, коллекторе и анализаторе:
1) Сенсоры имеет смысл ставить в «узловых точках» сети, например, на граничных маршрутизаторах сегментов сети
2) Коллектор осуществляет сбор информации от сенсоров. Полученные данные он помещает в хранилище для дальнейшей обработки. Различные коллекторы сохраняют данные в различных форматах.
3) Анализатор, или система обработки, считывает данные из хранилища и генерирует отчеты в форме, более удобной для человека. Эта система должна быть совместима с форматом данных, предоставляемых коллектором. В современных системах коллектор и анализатор часто объединены в одну систему для избежания разногласий в форматах работы.
Сенсор выделяет из проходящего трафика потоки, характеризуемые следующими параметрами:
Это очень важный момент — при настройке сенсора мы сами решаем, по каким параметрам отосланная на коллектор информация будет объединена в отчетах.
Notes:
Преимущество Netflow над остальными способами мониторинга, такими как SNMP и RMON, в том, что в ней существует программные пакеты, предназначенные для различного анализа трафика, которые существуют для получения данных от Netflow-пакетов и представления их в более дружелюбном для пользователя виде.
Рассмотрим вначале самую простую ситуацию, пригодится для оперативного режима (DIN)
1. Обе команды можно выполнить или в глобальном режиме или в режиме конфигурации интерфейса.
ip flow ingress - собирает статистику по входящему трафику
ip flow egress - собирает статистику по исходящему трафику
R1(config)# int fa 0/0
R1(config-if)# ip flow ingress
R1(config-if)# ip flow egress
2. Настройка примитивного отчета в глобальном режиме.
ip flow-top-talkers
top 30
sort-by bytes
cache-timeout 30000
R1(config)#ip flow-top-talkers
R1(config-flow-top-talkers)#top 30
R1(config-flow-top-talkers)#sort-by bytes
R1(config-flow-top-talkers)#cache-timeout 30000
R1(config-flow-top-talkers)#exit
3. Настроим таймеры в глобальном режиме:
ip flow-cache timeout inactive 10
ip flow-cache timeout active 5
R1(config)#ip flow-cache timeout inactive 10
R1(config)#ip flow-cache timeout active 5
После этого командами
show ip flow top-talkers
sh ip cache flow
можно увидеть наиболее активные хосты и типы трафика.
R1#sh ip cache flow
IP packet size distribution (90 total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .588 .277 .033 .000 .000 .033 .033 .000 .011 .000 .000 .000 .011 .000
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .011 .000 .000 .000 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 278544 bytes
2 active, 4094 inactive, 13 added
126 ager polls, 0 flow alloc failures
Active flows timeout in 5 minutes
Inactive flows timeout in 10 seconds
IP Sub Flow Cache, 21640 bytes
0 active, 1024 inactive, 0 added, 0 added to flow
0 alloc failures, 0 force free
1 chunk, 1 chunk added
last clearing of statistics never
Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
TCP-WWW 2 0.0 4 115 0.0 7.8 1.7
TCP-other 4 0.0 4 80 0.0 0.0 1.6
UDP-other 3 0.0 5 140 0.0 5.4 10.6
ICMP 2 0.0 3 60 0.0 4.6 10.5
Total: 11 0.0 4 104 0.0 3.7 5.7
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Fa0/1 10.0.2.2 Fa0/0* 10.0.1.2 06 0015 0413 20
Fa0/0 10.0.1.2 Fa0/1 10.0.2.2 06 0413 0015 22
R1#
-----------------------------------------------------
Ситуация номер два, она же штатный режим работы
Разберем конфигурацию сенсора при настройке на Cisco:
Наконец дошло до интерфейса:
Или
По основной настройке все, полезные ссылки для более полного просветления [1], [2] и [3].
Если есть необходимость хранить историю загрузки или есть иные условия можно воспользоваться таким инструментом, как PRTG, Nagios...
Для начала нужно понимать, что мониторинг сетей – штука довольно щепетильная и тонкая, и внедрить её в уже работающий проект, не спроектированный с учётом требований и возможностей мониторинга является очень затратной статьей расходов, которая далеко не всегда может, в конечном итоге, удовлетворить требованиям заказчика. Зачастую, потребность в мониторинге появляется у довольно прилично разросшейся инфраструктуры, и потом начинаются танцы с бубном в борьбе за рациональный бюджет и максимальную эффективность сбора данных.
Поэтому best practice является планирование и внедрение мониторинга на стадии проектирования и продажи её вместе с проектом.
NetFlow — проприетарный открытый протокол, разработанный Cisco для мониторинга трафика в сети. Netflow предоставляет возможность анализа сетевого трафика на уровне сеансов, делая запись о каждой транзакции TCP/IP.
Архитектура системы строится на сенсоре, коллекторе и анализаторе:
1) Сенсоры имеет смысл ставить в «узловых точках» сети, например, на граничных маршрутизаторах сегментов сети
2) Коллектор осуществляет сбор информации от сенсоров. Полученные данные он помещает в хранилище для дальнейшей обработки. Различные коллекторы сохраняют данные в различных форматах.
3) Анализатор, или система обработки, считывает данные из хранилища и генерирует отчеты в форме, более удобной для человека. Эта система должна быть совместима с форматом данных, предоставляемых коллектором. В современных системах коллектор и анализатор часто объединены в одну систему для избежания разногласий в форматах работы.
Графическая схема работы протокола
Описание протокола
NetFlow использует UDP или SCTP для передачи данных о трафике коллектору. Как правило, коллектор слушает порт 2055, 9555 или 9995 (или тот, который Вы укажете при настройке коллектора и сенсора).Сенсор выделяет из проходящего трафика потоки, характеризуемые следующими параметрами:
- Адрес источника;
- Адрес назначения;
- Порт источника для UDP и TCP;
- Порт назначения для UDP и TCP;
- Тип и код сообщения для ICMP;
- Номер протокола IP;
- Сетевой интерфейс (параметр ifindex SNMP);
- IP Type of Service.
Это очень важный момент — при настройке сенсора мы сами решаем, по каким параметрам отосланная на коллектор информация будет объединена в отчетах.
Notes:
Преимущество Netflow над остальными способами мониторинга, такими как SNMP и RMON, в том, что в ней существует программные пакеты, предназначенные для различного анализа трафика, которые существуют для получения данных от Netflow-пакетов и представления их в более дружелюбном для пользователя виде.
Рассмотрим вначале самую простую ситуацию, пригодится для оперативного режима (DIN)
1. Обе команды можно выполнить или в глобальном режиме или в режиме конфигурации интерфейса.
ip flow ingress - собирает статистику по входящему трафику
ip flow egress - собирает статистику по исходящему трафику
R1(config)# int fa 0/0
R1(config-if)# ip flow ingress
R1(config-if)# ip flow egress
2. Настройка примитивного отчета в глобальном режиме.
ip flow-top-talkers
top 30
sort-by bytes
cache-timeout 30000
R1(config)#ip flow-top-talkers
R1(config-flow-top-talkers)#top 30
R1(config-flow-top-talkers)#sort-by bytes
R1(config-flow-top-talkers)#cache-timeout 30000
R1(config-flow-top-talkers)#exit
3. Настроим таймеры в глобальном режиме:
ip flow-cache timeout inactive 10
ip flow-cache timeout active 5
R1(config)#ip flow-cache timeout inactive 10
R1(config)#ip flow-cache timeout active 5
После этого командами
show ip flow top-talkers
sh ip cache flow
можно увидеть наиболее активные хосты и типы трафика.
R1#sh ip cache flow
IP packet size distribution (90 total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .588 .277 .033 .000 .000 .033 .033 .000 .011 .000 .000 .000 .011 .000
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .011 .000 .000 .000 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 278544 bytes
2 active, 4094 inactive, 13 added
126 ager polls, 0 flow alloc failures
Active flows timeout in 5 minutes
Inactive flows timeout in 10 seconds
IP Sub Flow Cache, 21640 bytes
0 active, 1024 inactive, 0 added, 0 added to flow
0 alloc failures, 0 force free
1 chunk, 1 chunk added
last clearing of statistics never
Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
TCP-WWW 2 0.0 4 115 0.0 7.8 1.7
TCP-other 4 0.0 4 80 0.0 0.0 1.6
UDP-other 3 0.0 5 140 0.0 5.4 10.6
ICMP 2 0.0 3 60 0.0 4.6 10.5
Total: 11 0.0 4 104 0.0 3.7 5.7
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Fa0/1 10.0.2.2 Fa0/0* 10.0.1.2 06 0015 0413 20
Fa0/0 10.0.1.2 Fa0/1 10.0.2.2 06 0413 0015 22
R1#
-----------------------------------------------------
Ситуация номер два, она же штатный режим работы
Разберем конфигурацию сенсора при настройке на Cisco:
Router_NF# conf tВ конфигурационном режиме указываем адреса коллектора и порты, куда отправлять статистику, указываем версию протокола NetFlow. В сложной сети можно иметь два интерфейса коллектора, если есть какие-то ограничения маршрутизации между сегментами
Router_NF(config)# ip flow-export destination 192.168.0.1 9996
Router_NF(config)# ip flow-export destination 10.10.0.1 9996
Router_NF(config)# ip flow-export version 9
Router_NF(config)# ip flow-cache timeout active 1Указываем, как часто обновлять кэш NetFlow данными о трафике еще активной сессии
Router_NF(config)# ip flow-cache timeout inactive 15Указываем время, в течение которого если в существующем потоке не передаются данные, то он закрывается, и информация о нем записывается в кэш, а затем передается на коллектор
Router_NF(config)# ip flow-export source FastEthernet 0/0Источники отчета о трафике, статистика будет собираться с них. На стороне анализатора будут отдельно промониторены и интерфейс, и VLAN, и Port-channel
Router_NF(config)# ip flow-export source vlan4
Router_NF(config)# ip flow-export source Port-channel1.2
!Настраиваем snmp для правильного распознавания имен интерфейсов
snmp-server group snmp v1 access iacl-snmp
snmp-server group snmp v2c access iacl-snmp
snmp-server community ******** **** iacl-snmp
snmp-server ifindex persist
snmp-server trap-source Loopback0
snmp-server enable traps tty
!
Наконец дошло до интерфейса:
Router_NF(config)# interface FastEthernet 0/0Указываем, какой трафик будет учитываться, входящий в интерфейс или исходящий из него? Если исходящий, то ip flow egress, если входящий, то ip flow ingress
Router_NF(config-if)# ip flow egress
Router_NF(config-if)# ip flow ingress
Или
Router_NF(config-if)# ip route-cache flow«ip route-cache flow» может использоваться только для основного интерфейса, а «ip flow ingress» — это расширение для использования для сабинтерфесов. Функционал NetFlow Subinterface Support позволяет включать NetFlow для каждого сабинтерфейса. В сценарии, когда ваша сеть содержит множество сабинтерфейсов, а вам необходимо собирать записи только с некоторых, вы можете тонко настроить сбор информации только с определенных сабинтерфейсов
Что можно посмотреть на сенсоре:
Router_NF# show ip cache flowИнформация о трафике, ожидающая отправки на коллектор
Router_NF# show ip cache verbose flowДетальная информация о трафике, ожидающая отправки на коллектор
Router_NF# show ip flow interfaceИнтерфейсы, являющиеся сенсорами NetFlow
Router_NF# show ip flow exportsource и destination отчетов NetFlow, сколько отправлено дэйтаграмм, сколько ошибок
Router_NF# show ip flow top-talkersИнформация о чемпионах, представлена категорийно, вплоть до самых посещаемых интернет — ресурсов
По основной настройке все, полезные ссылки для более полного просветления [1], [2] и [3].
Если есть необходимость хранить историю загрузки или есть иные условия можно воспользоваться таким инструментом, как PRTG, Nagios...
| Категория трафика | Порты | Протокол прикладного уровня |
| 25, 109, 110, 113, 143 | smtp, pop2, pop3, ident, imap | |
| Web | 80, 8080, 443 | http, https |
| data | 20, 21, 3306, 66, 1521, 1526, 1524 | ftp, MySQL, sqlnet, Oracle, Ingres |
| Network management | 53, 137, 138, 139, 445, 161, 123, 783, 8200 | domain, netbios, snmp, ntp, spamassassin, GoToMyPC |
| Interactive | 22, 23, 513, 543 | ssh, telnet, rlogin, klogin |
| nntp | 119 | nntp |
| Chat | 194, 6891–6901, 1863, 5050, 5190 | irc, msn messenger, yahoo messenger, ICQ |
| streaming | 554, 1755, 1220, 8000–8005, 7070, 7071, 6970 | rtsp, ms-streaming, Apple quicktime, internet radio (shoutcast), Real Audio & Video |
| Malware & games | 1433, 1434, 666, 1999, 31337, 12345, 12346, 20034, 1024, 1025, 31338, 31339, 3127, 27015, 27016, 26000, 27001, 27960, 3724 | Ms-sql-s, ms-sql-m, backdoor, Back Orifice, NetBus, netspy, myDoom, HalfLife, Quake, QuakeWorld, QuakeIII, WarCraft |
| p2p | 411, 412, 1214, 3531, 4111, 4661–4665, 4672, 6346, 6347, 6669,6881–6889, 23302, 32285, 59049, 41170, 57990 | Direct Connect, Fasttrack, Kazaa, eDonkey, Gnutella, Napster, BitTorrent, Ares, Mp2p, Azureus |
| Others | - | - |
Известные проблемы
С течением времени доля трафика, попадающего в раздел «Other», растет, в связи с ростом числа приложений, использующих динамические, случайно сгенерированные порты.
В презентационном документе cisco, обозревающем NetFlow, вскользь упоминается проблема, хорошо проиллюстрированная на рисунке
Эффективного решения дающего хотя бы 5-10% долю Other-трафика вне зависимости от времени -- на данный момент я не знаю, поскольку проблема чаще всего имеет концепт погони "осла за морковкой". Cisco рекомендует использовать NBAR (Network Based Application Recognitio) -- в разных системах она может иметь различный коэффициент эффективности. Очень желательно, чтобы регламент мониторинга сетей имел чётко прописанную процедуру работы с ним. Например, я использовал процедуру снятия данных данных каждый месяц и оформления её в архив -- каждый новый месяц данные обнулялись и сбор начинался заново. У этого регламента есть минусы, сложно проводить годовой отчёт по трафику.
Использованы материалы:
http://xgu.ru/wiki/NetFlow
http://habrahabr.ru/post/175359/
http://ciao-cacao.blogspot.ru/2011/08/cisco.html
http://www.paessler.com/ru/prtg
http://habrahabr.ru/post/154747/
http://ru.wikipedia.org/wiki/PRTG
Комментариев нет:
Отправить комментарий