Документация NetAMS

Запускается этот скрипт через

./netams–netgraph.sh start

останавливается через

./netams–netgraph.sh stop

Для настройки самого NeTAMS необходимо добавить соответствующий сервис в /usr/local/etc/netams.cfg:

service data–source 1

type netgraph

source netams: divert

При этом 'netams:' - это имя модуля NETGRAPH, совпадающее с тем, что написано в скрипте netams–netgraph.sh. Не забываем про двоеточие!

Модуль ядра должен быть запущен ДО демона. В противном случае демон не заработает, как следует. Однако, в процессе работы допускается останавливать и запускать демон NeTAMS, равно как и выгружать и загружать снова модуль ядра (при этом будет 20–секундная задержка в приеме статистики).

Если что–то будет идти совсем не так, упадет ядро :) или блокируется весь трафик!

Работу демона netams можно проверить через просмотр состояния сервиса data–source:

netamsctl show ds

Data–source ID=1 type NETGRAPH source netams::9 loop 0 average 0 mcsec

Perf: average skew delay 0 mcsec, PPS: 0, BPS: 0

IP tree: 7 nodes [12] + 4 dlinks [1024] + 4 unodes [24] = 4276 bytes

Flows: 0/0 act/inact entries (0 bytes), 3 flows sent

HASH: size=65536, 0 flows hashed, 0 nodes used, max chain= 0

FIFO: 0/2 used/ready messages, each 108, total 216 bytes

ds_netgraph data messages: 3

netams: mode=2, pkt_rx=201, pkt_tx=169

flows: active(now)=3, queued(now)=0, blocked(total)=0, total=4

Работа модуля ядра видна через ngctl:

ngctl msg netams: info

Rec'd response «info» (1) from «[3bb]:":

Args: { packets/in=254 packets/out=202 mode=2 debug=1 active_flows=3 total_flows=9 default_policy=2 }

При включенной отладке модуля (через ngctl msg netams: debug 1) на консоли и в dmesg видно много подобных строк:

info/1109893460: sent to daemon [961] with error=0

callout/1109893461+ active 1, checked 1, queued=0, flushed 0

callout/1109893462+ active 1, checked 1, queued=0, flushed 0

callout/1109893463+ active 1, checked 1, queued=0, flushed 0

callout/1109893464+ active 1, checked 1, queued=0, flushed 0

callout/1109893465+ active 1, checked 1, queued=0, flushed 0

callout/1109893466+ active 1, checked 1, queued=0, flushed 0

callout/1109893467+ active 1, checked 1, queued=0, flushed 0

callout/1109893468+ active 1, checked 1, queued=0, flushed 0

callout/1109893469+ active 1, checked 1, queued=0, flushed 0

netams: created flow record id=14, hash=00766, time=1109893469, proto=6

netams: created queue 0xc1a15250 for id=14, hash=00766

netams fwreply for entry id=14, flags=0, queue 1/102

netams: flush queue for entry id=14, hash=766, size=1, action=1

netams: created flow record id=15, hash=00254, time=1109893469, proto=6

netams: created queue 0xc1355240 for id=15, hash=00254

netams fwreply for entry id=15, flags=0, queue 1/102

netams: flush queue for entry id=15, hash=254, size=1, action=1

Зачем все это нужно? Чтобы быстрее работало! Ниже приведены результаты небольших стендовых испытаний.

Все работы проводились с ОС FreeBSD 5.3–RELEASE, которая работала внутри виртуальной машины VmWare 4.5.2. Сама виртуальная машина работала на компьютере DUAL P4 Xeon 3.4GHz, 4Gb RAM под управлением Windows Server 2003. Виртуальная машина и хост–машина связаны через виртуальный адаптер vnmat (хотя в тестах трансляции адресов не было).

Скорость передачи данных измерялась при помощи iperf 1.7.0

На самой машине с Windows Server 2003 запущен сервер iperf, там же запускаем клиента:

C:\>iperf.exe–c 192.168.56.1–t 10–i 1

— -----------------------------------------------------------

Client connecting to 192.168.56.1, TCP port 5001

TCP window size: 8.00 KByte (default)

— -----------------------------------------------------------

[1948] local 192.168.56.1 port 3027 connected with 192.168.56.1 port 5001

[ ID] Interval Transfer Bandwidth

[1948] 0.0–1.0 sec 97.8 MBytes 821 Mbits/sec

[1948] 1.0–2.0 sec 96.1 MBytes 807 Mbits/sec

[1948] 2.0–3.0 sec 97.7 MBytes 820 Mbits/sec

[1948] 3.0–4.0 sec 93.0 MBytes 780 Mbits/sec

[1948] 4.0–5.0 sec 93.2 MBytes 782 Mbits/sec

[1948] 5.0–6.0 sec 96.9 MBytes 813 Mbits/sec

[1948] 6.0–7.0 sec 98.4 MBytes 825 Mbits/sec

[1948] 7.0–8.0 sec 97.4 MBytes 817 Mbits/sec

[1948] 8.0–9.0 sec 96.0 MBytes 806 Mbits/sec

[1948] 9.0–10.0 sec 98.2 MBytes 824 Mbits/sec

[1948] 0.0–10.0 sec 965 MBytes 808 Mbits/sec

Как видим, скорость передачи данных через локальный виртуальный интерфейс просто гигантская. Пробуем, как передаются данные между Windows и установленной FreeBSD, через VmWare, безо всяких побочных эффектов (NeTAMS и модуль ядра выключены):

freebsd–vm:~/netams#iperf–c 192.168.56.1–t 10–i 1

— -----------------------------------------------------------

Client connecting to 192.168.56.1, TCP port 5001

TCP window size: 32.5 KByte (default)

— -----------------------------------------------------------

[ 3] local 192.168.56.17 port 51925 connected with 192.168.56.1 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0–1.0 sec 27.6 MBytes 232 Mbits/sec

[ 3] 1.0–2.0 sec 28.4 MBytes 238 Mbits/sec

[ 3] 2.0–3.0 sec 28.1 MBytes 236 Mbits/sec

[ 3] 3.0–4.0 sec 28.3 MBytes 237 Mbits/sec

[ 3] 4.0–5.0 sec 28.4 MBytes 238 Mbits/sec

[ 3] 5.0–6.0 sec 28.3 MBytes 237 Mbits/sec

[ 3] 6.0–7.0 sec 28.0 MBytes 235 Mbits/sec

[ 3] 7.0–8.0 sec 28.1 MBytes 236 Mbits/sec

[ 3] 8.0–9.0 sec 28.7 MBytes 240 Mbits/sec

[ 3] 9.0–10.0 sec 28.3 MBytes 237 Mbits/sec

[ 3] 0.0–10.0 sec 282 MBytes 237 Mbits/sec

Естественно, медленнее. Теперь запустим NeTAMS и модуль ядра вместе, в режиме divert и убедимся, что это была не подстава:

freebsd–vm:~/netams#iperf–c 192.168.56.1–t 10–i 1

— -----------------------------------------------------------

Client connecting to 192.168.56.1, TCP port 5001

TCP window size: 32.5 KByte (default)

— -----------------------------------------------------------

[ 3] local 192.168.56.17 port 56639 connected with 192.168.56.1 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0–1.0 sec 20.9 MBytes 175 Mbits/sec

[ 3] 1.0–2.0 sec 23.4 MBytes 196 Mbits/sec

[ 3] 2.0–3.0 sec 23.5 MBytes 197 Mbits/sec

[ 3] 3.0–4.0 sec 23.5 MBytes 197 Mbits/sec