Intel vs DDoS

Всё описанное ниже нельзя рассматривать как руководство к действию и рекламу продукции описанной ниже фирмы. Это лишь результаты тестирования проведённые в один из дней когда нам понадобился очередной сервер в очередном датацентре. Основным критерием при выборе сервера была стрессоустойчивость при SYN/UDP атаках.

Зачастую при выборе сервера администратор не «заморачивается» с выбором сетевой карты, полагая, что все карты одинаковы, однако на своём опыте мы давно пришли к выводу что лучше Intel'a бывает только Intel. Но не все Intelы одинаковы, и когда датацентр предложил на выбор 3 сервера с различными Intel'ами на борту мы решили их предварительно оттестировать, дабы выяснить стоит ли платить больше, т.к. разбежка в цене составляла 300%.

Сразу стоит отметить что тесты проводились на собственных картах, а встроенные карты могут отличаться от своих «не бортовых» собратьев построенных на тех же чипах, потому о полной чистоте теста говорить не приходится, но чем богаты…

Для начала нам надо определиться с какими чипами мы имеем дело. Для этого воспользуемся утилитой pciconf, которая доступна во FreeBSD из коробки:

# pciconf -lv | grep -i device
    ...
    device     = '82541PI Gigabit Ethernet Controller'

# pciconf -lv | grep -i device
   ...
    device     = 'I350 Gigabit Network Connection'
    device     = 'I350 Gigabit Network Connection'

 
# pciconf -lv | grep -i device
   ...
    device     = '82545EM Gigabit Ethernet Controller (Copper)'
 
# pciconf -lv | grep -i device
   ...
   device     = '82576 Gigabit Network Connection'
   device     = '82576 Gigabit Network Connection'

В 4-x случаях всё решилось просто, но 5-й девайс не распознан. Идём другим путём:

# pciconf -lv | more
...
none0@pci0:1:0:0: class=0x020000 card=0x10d315d9 chip=0x10d38086 rev=0x00 hdr=0x00
...

В ряду шифровок нас интересует chip=0x10d38086, который декодируется согласно данных с сайта производителя — www.intel.com/support/network/sb/CS-012904.htm. Первые четыре цифры это DevID(10d3), вторые четыре VendorID(8086).

Итак наш пятый пациент 82574L

Собираем тестовый стенд. Атакуемая рабочая станция и три генератора флуда работающие под управлением FreeBSD 9.0 «соединяем» через коммутатор D-LINK DGS-3612.

Слегка тюнигуем систему:

# cat /boot/loader.conf
kern.ipc.nmbclusters=256000
kern.ipc.numopensockets=256000
net.inet.tcp.tcbhashsize=4096
 
hw.igb.max_interrupt_rate=256000
hw.igb.rxd=4096
hw.igb.txd=4096
hw.igb.num_queues=4
hw.igb.rx_process_limit=4096

#hw.em.rxd=4096
#hw.em.txd=4096
#hw.em.num_queues=4
#hw.em.rx_process_limit=4096

# sysctl -a net.isr.dispatch
net.isr.dispatch: direct

В качестве источника флуда будем использовать утилиту iperf.
стартуем:

# iperf -c 10.0.0.1 -t 60 -u -b100000000 -l 60 -P 16

82541PI

# netstat -w 1 -inb
                        input           (Total)           output
   packets  errs    idrops      bytes     packets  errs       bytes colls
    556487      0        0   33389220          21     0        3570     0
    575695      0        0   34541700          1      0        170      0
    682919      0        0   40975140          21     0        3570     0
    760146  50437        0   45608760          32     0        5440     0
    778946  93314        0   46736760          31     0        5270     0
    799891 142871        0   47993400          31     0        5270     0
    799912 187436        0   47994780          31     0        5270     0
    799027 200552        0   47941620          31     0        5270     0

82576

# netstat -w 1 -inb
            input        (Total)           output
   packets  errs idrops       bytes    packets  errs      bytes  colls
    962227     0      0    57655860         25     0       4730      0
   1092726    69      0    65421996         29     0       5582      0
    997903     0      0    59745752         36     0       6968      0
    885540 89130      0    53028100         89     0      20492      0
   1049650     0      0    62841000         42     0       7956      0
   1174459     0      0    70282864         40     0       7356      0
   1247436  8307      0    74639760         38     0       7212      0
   1236316 19944      0    73995244         44     0       8644      0

I350

# netstat -w 1 -inb
            input           (Total)           output
   packets   errs idrops      bytes    packets  errs      bytes colls
   1433025      0      0   85981500         32     0       6032     0
   1436316      0      0   86178960         44     0       8644     0
   1439834      0      0   86390040         37     0       7250     0
   1547262      0      0   92835720         34     0       6832     0

82545EM

# netstat -w 1 -inb
            input           (Total)           output
   packets  errs idrops      bytes    packets  errs      bytes colls
    180350   1473     0   10821000         13     0       2338     0
    290362  14374     0   17421720          9     0       2010     0
    390550 171473     0   23433000         13     0       2338     0
    390822 164374     0   23449320          9     0       2010     0
    391377 146025     0   23482620         10     0       2004     0
    386249 158581     0   23174940         11     0       2126     0

82574L

# netstat -w 1 -inb
            input        (Total)           output
   packets   errs   idrops      bytes     packets  errs       bytes colls
    697569      0        0   40975140          21     0        3570     0
    780356  49863        0   45608760          32     0        5440     0
    800464 245705        0   48027936          22     0        3740     0
    800443 246861        0   48026612          21     0        3570     0
    800462 242928        0   48027784          22     0        3740     0
    800448 237661        0   48026880          21     0        3570     0

Результаты в общем-то ожидаемые. «Старичок» 82545EM не выдерживает никакой критики. 82541PI и 82574L показали достаточно неплохие результаты для чипов, которые Intel практикует и на десктопных картах, однако использовать их на серьёзной нагрузке врядли стоит. 82576 почти справляется с миллионом пакетов, но с учётом того, что на момент появления ошибок утилизация процессора составила порядка 7%, можно считать, что это потолок адаптера. Безусловным лидером оказался i350, что и ожидалось от одного флагаманов гигабитных карт от Intel.

Автор: DDoSExpert