воскресенье, 8 августа 2010 г.

Pktgen — тестирование сети с помощью генератора пакетов

Я уже писал, что когда тестировал первые сборки своего LiveCD, то столкнулся со странными зависаниями компьютера при высокой нагрузке на ethernet-канал. Тогда я решил проблему поменяв материнскую плату, блок питания и сетевой адаптер. Зависания исчезли и я спокойно выпустил первые две сборки LiveCD. Проблема наложила свой отпечаток на релизы и в первую консольную версию LiveCD вошел полный комплект сетевых утилит Linux включая сниффер и сканер портов. Единственное чего мне не хватало — это генератора пакетов. Вещь это не совсем безопасная и видимо поэтому Патрик не включает этот модуль в ядра Slackware. Ситуация со «спасательным» LiveCD выглядела таким образом: мне нужна была возможность загружаться с 32-bit и 64-bit ядер, но оба ядра в Slackware имеют имя 2.6.33.4, что означает что они используют один каталог для модулей в директории /lib/modules. В результате я пересобрал 32-битное ядро generic с суффиксом «_32» и включил генератор пакетов. В рунете есть описание первой версии генератора, например на ресурсе securitylab.ru, но я ничего не нашел по актуальной второй версии. Я решил описать его использование на примере тестирования своего глючного железа.

Мои подозрения падали на материнскую плату и сетевой адаптер. Материнскую плату — старушку GA-6OXT, было от чего подозревать, на ней был нерабочий AGP-слот, в свое время была попытка замены полевого транзистора управляющего питанием слота, но к результатом не привела. И хотя теоретически на другие системы это сказаться не должно было, практически неисправность могла задеть PCI шину через которую работал сетевой адаптер. План тестирования такой: если при другой сетевой карте материнка будет нормально работать, то значит проблема в сетевой карте, иначе M/B придется пустить на запчасти. Генератор пакетов позволяет генерировать сетевой трафик с максимальной пропускной способность канала, что мне и надо. Здесь мне нужно сделать предупреждение. В сети я встречал посты, что при некоторых параметрах генератора якобы все компьютеры с виндуз враз зависают, а сетевые принтеры «сходят сума» и начинают беспорядочно хлопать лотками. Сетевых принтеров и компьютеров с виндуз у меня нет, поэтому не могу подтвердить и опровергнуть это, но когда разбирался с опциями генератора моя локальная сеть «подвисала» на несколько минут, а точка доступа Wi-Fi ушла в оффлайн. Будьте внимательны.

Итак я загружаю на тестируемой машине спасательный livecd: SlavankaOS Recovery Edition, ввожу логин и пароль.

Загружаю модуль генератора

# modprobe pktgen

в /proc появляется директория /proc/net/pktgen c двумя файлами kpktgend_0 и pgctrl.


Выводим их значения:

# cat /proc/net/pktgen/pgctrl

pktgen 2.72: Packet Generator for packet performance testing.


# cat /proc/net/pktgen/kpktgend_0

Running:

Stopped:

Result: NA


Добавляем сетевой интерфейс:

# echo "add_device eth0" > /proc/net/pktgen/kpktgend_0


в /proc/net/pktgen появляется файл устройства eth0

Настраиваем генератор устройства.

Число пакетов:

echo "count 1000000" > /proc/net/pktgen/eth0


адрес назначения:

# echo "dst 192.168.1.3" > /proc/net/pktgen/eth0


размер пакетов:

# echo "pkt_size 1400" > /proc/net/pktgen/eth0

здесь значение не должно превышать MTU


задержка между пакетами 50

# echo "delay 50" > /proc/net/pktgen/eth0


Проверяем состояние:

# cat /proc/net/pktgen/eth0

Params: count 1000000 min_pkt_size: 1400 max_pkt_size: 1400

frags: 0 delay: 50 clone_skb: 0 ifname: eth0

flows: 0 flowlen: 0

queue_map_min: 0 queue_map_max: 0

dst_min: 192.168.1.3 dst_max:

src_min: src_max:

src_mac: 00:e0:50:15:09:a7 dst_mac: 00:00:00:00:00:00

udp_src_min: 9 udp_src_max: 9 udp_dst_min: 9 udp_dst_max: 9

src_mac_count: 0 dst_mac_count: 0

Flags:

Current:

pkts-sofar: 0 errors: 0

started: 0us stopped: 0us idle: 0us

seq_num: 0 cur_dst_mac_offset: 0 cur_src_mac_offset: 0

cur_saddr: 0x0 cur_daddr: 0x301a8c0

cur_udp_dst: 0 cur_udp_src: 0

cur_queue_map: 0

flows: 0

Result: OK: delay=50


Теперь на машине адресате 192.168.1.3 включаем «сборщик пакетов»

# tcpdump -vv host 192.168.1.3

при этом в dmesg появится строка

device eth0 entered promiscuous mod

что означает, что сетевая карта переведена в режим когда может принимать пакеты ей не предназначенные


на испытуемой машине смотрим статистику:

# ip -s link list eth0

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000

link/ether 00:e0:50:15:09:a7 brd ff:ff:ff:ff:ff:ff

RX: bytes packets errors dropped overrun mcast

152912 1650 0 0 0 0

TX: bytes packets errors dropped carrier collsns

124546 953 0 0 0 0


и включаем генератор:

# echo "start" > /proc/net/pktgen/pgctrl


tcpdump начинает показывать строчки:

192.168.1.34.discard > 192.168.1.3.discard: [no cksum] UDP, length 1358

09:32:50.513096 IP (tos 0x0, ttl 32, id 33426, offset 0, flags [none], proto UDP (17), length 1386)

192.168.1.34.discard > 192.168.1.3.discard: [no cksum] UDP, length 1358

09:32:50.513198 IP (tos 0x0, ttl 32, id 33427, offset 0, flags [none], proto UDP (17), length 1386)

192.168.1.34.discard > 192.168.1.3.discard: [no cksum] UDP, length 1358

09:32:50.513321 IP (tos 0x0, ttl 32, id 33428, offset 0, flags [none], proto UDP (17), length 1386)

192.168.1.34.discard > 192.168.1.3.discard: [no cksum] UDP, length 1358

09:32:50.513425 IP (tos 0x0, ttl 32, id 33429, offset 0, flags [none], proto UDP (17), length 1386)

192.168.1.34.discard > 192.168.1.3.discard: [no cksum] UDP, length 1358

09:32:50.513541 IP (tos 0x0, ttl 32, id 33430, offset 0, flags [none], proto UDP (17), length 1386)


после завершения еще раз смотрим статистику и статус генератора:

# ip -s link list eth0

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000

link/ether 00:e0:50:15:09:a7 brd ff:ff:ff:ff:ff:ff

RX: bytes packets errors dropped overrun mcast

174326 1894 0 0 0 0

TX: bytes packets errors dropped carrier collsns

1400140480 1001075 0 0 0 0


# cat /proc/net/pktgen/eth0

Params: count 1000000 min_pkt_size: 1400 max_pkt_size: 1400

frags: 0 delay: 50 clone_skb: 0 ifname: eth0

flows: 0 flowlen: 0

queue_map_min: 0 queue_map_max: 0

dst_min: 192.168.1.3 dst_max:

src_min: src_max:

src_mac: 00:e0:50:15:09:a7 dst_mac: 00:00:00:00:00:00

udp_src_min: 9 udp_src_max: 9 udp_dst_min: 9 udp_dst_max: 9

src_mac_count: 0 dst_mac_count: 0

Flags:

Current:

pkts-sofar: 1000000 errors: 0

started: 1595815029us stopped: 1709701811us idle: 10414us

seq_num: 1000001 cur_dst_mac_offset: 0 cur_src_mac_offset: 0

cur_saddr: 0x2201a8c0 cur_daddr: 0x301a8c0

cur_udp_dst: 9 cur_udp_src: 9

cur_queue_map: 0

flows: 0

Result: OK: 113886782(c113876367+d10414) nsec, 1000000 (1400byte,0frags)

8780pps 98Mb/sec (98336000bps) errors: 0


параметры генератора можно менять, полный список команд можно посмотреть в официальной документации

http://www.linuxfoundation.org/collaborate/workgroups/networking/pktgen



В случае с моим железом я заметил, что ошибки/errors появлялись в графе RX т.е. принятых пакетов. В итоге я поставил сетевой адаптер на компьютер который работал на прием пакетов и в результате получил такую статистку:

eth0 Link encap:Ethernet HWaddr 00:e0:50:15:09:a7
inet addr:192.168.1.7 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::2e0:50ff:fe15:9a7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:753600 errors:27 dropped:369 overruns:0 frame:3
TX packets:1340 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1054322872 (1005.4 MiB) TX bytes:115058 (112.3 KiB)
Interrupt:21 Base address:0xd800


то есть машина после приема какого-то количества пакетов просто перестала принимать их и связаться с ней по ssh было невозможно и компьютер выглядел как-будто зависшим хотя оказала только сетевая карта.

Комментариев нет:

Отправить комментарий