How to scale graphite up to X times and reduce cpu consumption twice?

So much customers who are working with Graphite could highlight two significant issues with Graphite:
1) It's coded with Python which pretty slow
2) It's bundled to single CPU core and need clustering for using all cores

I have hit first issue. I'm using Graphite with FastNetMon for awesome visual reports and I'm storing about 40 000 records per second.

So carbon daemon eat so much cpu:

top - 13:58:37 up 128 days, 19:32,  1 user,  load average: 3.88, 3.80, 3.76
Tasks: 150 total,   1 running, 149 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.5 us,  8.8 sy,  0.0 ni, 66.2 id, 11.6 wa,  0.1 hi,  0.8 si,  0.0 st
KiB Mem:  32933416 total, 31923200 used,  1010216 free,   697700 buffers
KiB Swap:  3905532 total,   564568 used,  3340964 free. 26169476 cached Mem
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAN  
20598 root      20   0 5343724 619232 543572 S 179.0  1.9  80770:18 fastnetmon            
22981 _graphi+  20   0  250300 128484   4756 S  21.3  0.4   0:06.81 carbon-cache          

So We could hit limit with about 200 000 records per second and it's not so fine.

I have found awesome product Go-Carbon. It's drop-in replacement for carbon daemon and it's implemented in Golang (very fast and reliable!).

So I have replaced my existing carbon with go-carbon this way. I'm using Debian 8 and all guide will be about it.

Install it:

wget https://github.com/lomik/go-carbon/releases/download/v0.6/go-carbon_0.6_amd64.deb
dpkg -i go-carbon_0.6_amd64.deb

Then we need to change path to original graphite data files (it's completely back compatible but please keep backup):

Then open file /etc/go-carbon/go-carbon.conf

And change following options:

schemas-file = "/etc/carbon/storage-schemas.conf"
data-dir = "/var/lib/graphite/whisper/"
user = "_graphite"
max-updates-per-second = 500 (because it's standard configuration for graphite: MAX_UPDATES_PER_SECOND = 500)

Then switch off python carbon and start go-carbon:

 /etc/init.d/carbon-cache stop
/etc/init.d/go-carbon start

So you still can use graphite web for reading data! And feed data with pickle of text protocol.  It's completely back compatible.

And it's lightning fast:

top - 13:57:44 up 128 days, 19:32,  1 user,  load average: 3.85, 3.78, 3.75
Tasks: 149 total,   1 running, 148 sleeping,   0 stopped,   0 zombie
%Cpu(s): 13.6 us, 12.5 sy,  0.0 ni, 62.0 id, 10.7 wa,  0.1 hi,  1.0 si,  0.0 st
KiB Mem:  32933416 total, 31888556 used,  1044860 free,   697680 buffers
KiB Swap:  3905532 total,   564568 used,  3340964 free. 26161116 cached Mem
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
20598 root      20   0 5343724 619232 543572 S 208.1  1.9  80768:40 fastnetmon  
21882 _graphi+  20   0  446480 102512   8028 S  10.7  0.3   6:59.83 go-carbon   

As you can see we got two times CPU usage reduction!  But you could use workers = X and max-cpu = X option for scaling go-carbon over all available cores!

We have awesome picture from author:

Эффективность работы антивирусов на платформе Linux

В течение последних 2-3 недель (с конца апреля до 8го мая 2014) с помощью Antidoto и в процессе его отладки мною было обнаружено большое число зловредного ПО на различных Linux машинах. Оно по-разному пробиралось на серверы, но было обнаружено и удалено с машин с исправлением исходных причин заражения. В процессе этого было изъято большое число исполняемых файлов, которые были тщательным образом проанализированы в запущенном виде и после этого нейтрализованы. Наиболее интересные экземпляры исследованы здесь.После изъятия все файлы были проверены ведущими антивирусами и результаты проверок приведены ниже.

• apache2_rootkit_from_srv_277274 ced2ebfccfe2d52f362908020acd5831 0/51
• apache_rootkit_from_srv_277274 614ad37e6755ef7443addd2df27256c2 0/51
• atd_virus_ovz17 36f6c1169433cc8a78498d54393132ed 1/51 только Kaspersky, после репорта
• fake_sshd_mc e3305c8ae035d81d75cf0d4ea2ba1131 0/52
• irc_bouncer_hidden_as_ssh_from_5560 d7cb8d530dd813f34bdcf1b6c485589b 1/52только Avast, ELF:PsyBNC-A [PUP]
• jawa 36c97cdd3caccbacb37708e84b22a627 0/52
• libworker.so a6765b7ab914e042a6f8e1adb59c08b9 2/52 Kaspersky Avast
• pine_virus_from_2441 88cc70e9f07654d5afc392bf4e135d87 0/52
• ps_virus_ct_6205 21f9a5ee8af73d2156333a654130f3f8 1/49 Kaspersky, после нашего репорта.
• sfewfesfs f9ad37bc11a4f5249b660cacadd14ad3 3/52 Avast, Gdata, Qihoo-360
• sfewfesfsh 9b6283e656f276c15f14b5f2532d24d2 5/52 DrWeb, Kaspersky, Qihoo-360, TrendMicro-HouseCall, ViRobot
• sshd_32_bit_fake_from_2453 0c0dc04b427e8e2bf90fcc4e6dc6cbc9 0/52
• virus_from_43165 a6752df85f35e6adcfa724eb5e15f6d0 1/52 Только Kaspersky, после нашего репорта
• named_bitcoin_virus 99ca61919f5afbdb3c0e07c30fad5bb1 9/52 Avast, Bkav, DrWeb, ESET-NOD32, Fortinet, Kaspersky, TrendMicro, TrendMicro-HouseCall, VBA32

Все вирусы были отправлены на Virustotal и могут быть найдены по хэшам (в том числе сотрудниками AV компаний), все вирусы были перданы в компанию ClamAv, часть вирусов была передана в компанию Kaspersky.

Итого, 14 типов подтвержденно зловредного ПО:

• 6 из них не определяются никаким антивирусным ПО
• 3 определяются антивирусом Касперского только после получения багрепорта от нас
• 1 определяется только антивирусом Avast
• 4 типа зловредного ПО определяются более чем одним антивирусом.

Победителей я бы распределил так:

• Avast (безоговорочная победа)
• Kaspersky (более-менее, наши посылки не учиытвались в анализе)
• DrWeb (2 вируса, мало, но лучше, чем что-то)

Хочется обратить внимание на то, что все указанное зловредное ПО было обнаружено с помощью пакета Antidoto, которое имеет эвристические алгоритмы обнаружения каждого из них.

Update: в данный момент все вирусы были полностью отправлены в DrWeb и Kaspersky, ClamAV. Остальным отправлять очень лениво.

Выводы

А они печальные - даже от базовых очень стандартных вирусов (многие из приведенных мною загружались на VirusTotal еще несколько лет назад и до сих пор никем не определяются) антивирусы не предоставляют НИКАКОЙ ЗАЩИТЫ вообще.

Что же делать? Иметь очень хорошего системного администратора и использовать проверенные диагностические утилиты - netstat, ss, lsof и другие в дополнение к тулкиту Antidoto :)

Источник, моя же публикация. 

Отличный доклад про фрагментацию ploop

Рекомендую всем, что работает с OpenVZ! 

Бесплатный журнал Интернет изнутри от MSK-IX

Прошу любить и жаловать всех, кто так или иначе связан с сетью Интернет.

Сетевикам прочтение крайне обязательно: http://www.ccni.ru/download/InternetInside/InternetInside_N1.pdf

Реалии использования динамических библиотек скомпилированных силами Go из С/С++

Всем известно, что начиная с версии 1.5 Golang научился делать бинарные динамические .so библиотеки (go build -buildmode=c-shared -o libgobgp.so *.go), которые можно прилинковать к православному C коду.

Но если копнуть дальше, на деле это не совсем .so библиотека и привычного нам машинного кода там нету.

А есть обертки, которые вызывают код из Golang и подставляют себя С функциями.

Дада, Вы верно догадываетесь, Go's runtime запускается рядом. Не заметить это сложно - появляется 5ка тридов рядом с вашей программой Смайлик «smile»

Но это пол беды - этот рантайм запускается в момент запуска Вашего С-приложения, автоматически.

И если оно форкается или форкается и потом использует popen - горевать Вам очень долго, потому что многопоточное приложение, которым с момента запуска int main стал Ваш любимый софт из-за Go рантайма нельзя форкать, будет все крайне плохо Смайлик «smile»

Я даже молчу, что этот самый Го рантайм подменяет обработчики привычных нам сигналов и заворачивает их на себя, что может вызвать серьезный баттхерт у любителей поиграться с сигналами.

Как чинить? Линковаться динамически в рантайме, силами dlopen/dlsym, как сделал я - тут.

Вот так вот друзья - не все так просто, за все нужно платить Смайлик «smile»После этого фикса все стало работать решительно приличнее, но совершенно никаких гарантий, что так будет и впредь.

Недостатки используемых в данный момент способов доставки приложений и библиотек

Меня всегда удивлялся идиотическая черта пропагандируемая всеми без исключения дистрибутивами, построенными на бинарных пакетах.

Кто эти люди, кто считает, что старый, неактуальный код полутора летней давности НАДЕЖНЕЕ того же самого кода, который был выправлен от пары-тройки критичных багов, скажем, неделю назад?

Я изо дня в день выбиваю баги, которых нету в актуальной версии библиотеки/программы, но они есть и цветут в красе в той версии, которую сунул чудесный дистрибутиво-собиратель.

Единственные, кто хотя бы отчасти радует в этом мире идиотизма - это Ubuntu LTS, которые нарушили все кармические запреты и обновляют ядро до разумных версий!

Red Hat со своим чудо-ядром класса 2.6.32 на стероидах с тыщей бэкапорт патчей сверху (да пропади оно пропадом сто раз - баголовище и багокостылище) не просто задрал, а задрал - нисказанно Смайлик «smile»

Алсо, друзья, какие выходы из этой патовой ситуации Вы видите?

Мы уже местами упоролись в конец и собираем то-что-нам-нужно (на богобоязныенных Го и Си Плас Плас) вручную и нужных-нам-версий, используя от дистрибутива лишь базовые вещи (хотя под час там даже базовый компилятор - старье и им просто-напросто не собрать актуальный проект, скажем, на С++ 11).

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

Gentoo/LFS это кому-то может быть и вариант, но не для продакшена явно. Радуют в вопросе CoreOS - но там богобоязнныенне конейнеры и нарушение многих привычных мне парадигм.

Хочется дистибутив, который использует в меру стабильное, но актуальное ядро, имеет полный арсенал языков программирования и ключевых библиотек актуальных стабильных версий (с соотвествующим обновлением).

Но при этом хочется возможности фиксировать библиотеки. Скажем - я опираюсь на xxx, yyy, zzz и просто не хочу получать обновления на их следующие версии, а только обновления, скажем, безопасности.

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

Также вместо докера с его огромным ворохом проблем рекомендую посмотреть на CoreOS + Rocket (годная и адекватная замена Doker спроектированная инженерами, а не хипстерами).

А что думаете Вы?

Остерегайтесь! Криптеры файлов дошли до мира Linux серверов

Кажется эре наплевательского отношения к безопасности в сфере хостинга наступает конец.

Буквально несколько дней назад столкнулись с о взломами клиентских выделенных серверов и VPS, когда вместо очередного ботнет-контроллера, спам-скрипта или же флудера гостевых книг (c) (tm) появилось нечто новое.

Это "нечто" заимев root полномочия на машине (отдельный вопрос - как, но в целом данный вектор атаки работает даже без рутания) зашифровало к чертям все от начала до конца файлы (а это - десятки гигабайт) на сервере относящиеся к сайтам (текст скриптов) и базам данных (все внутренности mysql) и услужливо разложило везде файлик info с указанием Bitconin кошелька куда класть выкуп если вдруг образовалось желание вернуть свои файлы обратно.

Друзья, искренне рекомендую всем иметь надежный бэкап!

Effectiveness of ZFS usage for OpenVZ

This article is a detailed answer to conversation about simfs vs ploop vs ZFS from OpenVZ maillist.

Because I have finished very detailed tests of ZFS for VPS storage I would like to share they with my Dear Community. 

Source data (real clients, real data, different OS templates, different OS templates versions, server running for ~1year, production server full copy):

Size: 5,4T
Used: 3,5T
Avail: 1,7T
Usage:69%

This data from HWN with OpenVZ with ploop.

Our internal toolkit fastvps_ploop_compacter show following details about this server:

Total wasted space due to ploop bugs: 205.1 Gb

Wasted space means difference between real data size and ploop disks size, i.e. ploop overhead.

gzip compression on ZFS

We have enabled ZFS gzip compression and move all data to new created ZFS volume.

And we got following result:

NAME          SIZE   ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT data  8,16T  3,34T  4,82T    40%  1.00x  ONLINE  -

As you can see  we save about 160 GB of data. New ZFS size of this data is: 3340 GB, old size: 3500 GB.

lz4 compression on ZFS

So, ZFS developers do not recommend gzip and we will try lzr4 compression as best option.

We copy same data to new ZFS storage with lz4 compression enabled and got following results:

ALLOC: 2,72Tb

Wow! Amazing! We save about 600 Gb of data!  Really!

ZFS deduplication

As you know, ZFS has another killer feature - deduplication! And it's best option when we store so much containers with fixed number of distributions (debian, ubuntu, centos).

But please keep in mind, we have disabled compression on this step!

We have enabled deduplication for new storage and copy all production data to new storage with deduplication.

When data copy was finished we got this breath taking results:

zpool list

NAME         SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOTdata  8,16T  2,53T  5,62T    31%  1.33x  ONLINE  -

We have saved 840 GB of data with deduplication! We are really close to save 1Tb!

For very curious readers I could offer some internal data regarding ZFS dedup:

zdb -D data
DDT-sha256-zap-duplicate: 5100040 entries, size 581 on disk, 187 in core
DDT-sha256-zap-unique: 27983716 entries, size 518 on disk, 167 in core
dedup = 1.34, compress = 1.00, copies = 1.02, dedup * compress / copies = 1.31

ZFS compression and deduplication simultaneously

So, ZFS is amazingly flexible and we could use compression and dedulication in same time and got even more storage save. And this tests is your own home task :) Please share your results here!

Conclusion

That's why we have only single file system which ready for 21 century. And ext4 with derivative file systems should be avoided everywhere if possible.  

So, will be fine if you help ZFS on Linux community with bug reporting and development! 

How to enable Autonomus System Lookup for tshark/wireshark?

In article http://www.stableit.ru/2015/04/how-to-enable-geoip-support-in-tshark.html we discuss GeoIP feature. If you interested in AS numbers of client hosts, please execute this reference.

Install GeoIP:

apt-get install -y geoip-database

Then download ASN database:

wget http://geolite.maxmind.com/download/geoip/database/asnum/GeoIPASNum.dat.gz
gunzip GeoIPASNum.dat.gz
mv GeoIPASNum.dat  /usr/share/GeoIP/

Then you should specify folder with GeoIP databases to Wireshark:

mkdir -p ~/.wireshark
echo '"/usr/share/GeoIP"' > ~/.wireshark/geoip_db_paths

Let's start:

tshark -i eth0 -n -T fields -e ip.geoip.src_asnum -o "ip.use_geoip: TRUE"

And you will get following output:

AS60781 LeaseWeb B.V.
AS34757 Sibirskie Seti Ltd.
AS60781 LeaseWeb B.V.
AS60781 LeaseWeb B.V.
AS60781 LeaseWeb B.V.
AS60781 LeaseWeb B.V.
AS60781 LeaseWeb B.V.
AS60781 LeaseWeb B.V.
AS60781 LeaseWeb B.V.
AS60781 LeaseWeb B.V.
AS60781 LeaseWeb B.V.
AS200000 Hosting Ukraine LTD
AS60781 LeaseWeb B.V.
AS23947 PT.Mora Telematika Indonesia
AS60781 LeaseWeb B.V.
AS2914 NTT America, Inc.
AS60781 LeaseWeb B.V.
AS18881 Global Village Telecom

Селективный блэкхол

Видимо, пошло оно от selective blackhole. На удивление недавно (на ENOG9) обнаружил, что термин частенько не понимается многими и вовсе не является обще принятым :)

Что же он означает? Речь идет о RTBH (remote triggered black hole), который обычно висит на BGP комьюнити 666. При его активации он блокирует весь трафик с/на узел.

Селективный же блокирует либо заданный протокол (часто - UDP) либо же набор протоколов по определенным параметрам (например, популярные UDP амплификаторы).

Операторы, кто поддерживает это дело - редки, делимся в комментах :)

Настройка роутинг демона BIRD для экспорта содержимого локальной роутинг таблицы по BGP

Все тесты будут вестись на CentOS 6 :)

Итак, установим Bird:

yum install -y bird

Откроем его конфиг:

vim /etc/bird.conf 

И закомментируем там все, что нам не закомментировано дабы избежать конфликтов.

После этого забиваем следующий конфиг:

protocol kernel {
    persist;                # Don't remove routes on bird shutdown
    learn;                  # Learn all alien routes from the kernel
    export none;            # Default is export none
    import all;
    scan time 20;           # Scan kernel routing table every 20 seconds
    device routes yes;
}

protocol device {
    scan time 10;           # Scan interfaces every 10 seconds
}

filter test_filter {
    # filter out private subnets
    if net ~ 10.0.0.0/8 then reject;
    if net ~ 192.168.0.0/16 then reject;
    if net ~ 172.16.0.0/12 then reject;

    # filter link local for IPv4
    if net ~ 169.254.0.0/16  then reject;

    accept;  
}


protocol bgp {
    local as 65000;

    source address 10.0.131.2;
    # do not connect to remote peers, work as route server now!
    # passive;

    import all;
    export filter test_filter;
    neighbor 10.0.129.2 as 65000;
}

Данный конфиг приводит к тому, что будет установлена BGP сессия с заданным узлом и в нее будут проанонсированы все маршруты из локальной таблицы Linux (в моем случае это маршруты до OpenVZ VPS).

После этого применяем изменения (в лоб, потому что тесты. В продакшене нужно делать через birdc):

/etc/init.d/bird restart

Убеждаемся, что BGP сессия поднялась:

show protocols all bgp1
name     proto    table    state  since       info
bgp1     BGP      master   up     15:07:32    Established  
  Preference:     100
  Input filter:   ACCEPT
  Output filter:  test_filter
  Routes:         0 imported, 27 exported, 0 preferred
  Route change stats:     received   rejected   filtered    ignored   accepted
    Import updates:              0          0          0          0          0
    Import withdraws:            0          0        ---          0          0
    Export updates:             29          0          2        ---         27
    Export withdraws:            0        ---        ---        ---          0
  BGP state:          Established
    Neighbor address: 10.0.129.2
    Neighbor AS:      65000
    Neighbor ID:      10.0.129.2
    Neighbor caps:    AS4
    Session:          internal multihop AS4
    Source address:   10.0.131.2
    Hold timer:       109/180
    Keepalive timer:  2/60

Все! :)

Аггрегация огромных сетей

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

Итак, выдернем все их сети с помощью BGPq3:

/opt/bgpq3/bin/bgpq3 AS-DATAIX|awk '{print $5}' > /root/dataix_networks_list.dat

Наберется очень много - 251 тыща сетей:

wc -l /root/dataix_networks_list.dat
251009 /root/dataix_networks_list.dat

Посчитаем, сколько это в хостах:

cat  /root/dataix_networks_list.dat | sed 's#/# #' |awk '{print $2}'|perl -e 'my$total=0; do{ $_ = int($_); next unless $_; $total += 2**(32-$_) } for <>; print "Total networks size: $total\nTotal Internet size: " . 2**32 . "\n"'
Total networks size: 410 650 370
Total Internet size: 4 294 967 296

Согласитесь, смотрится совершенно неплохо даже на фоне размера всего адресного пространства IPv4.

Но что если там есть дублирующиеся сети или сети вложенные друг в друга? Это реально сложно проверить и еще сложнее починить "в лоб".

Но есть чудесная тулза - aggregate.

Устанавливаем ее:

apt-get install -y aggregate

И запускаем аггрегацию:

cat /root/dataix_networks_list.dat| aggregate > /root/dataix_networks_list_aggregated_new.dat

Она будет потреблять приличное количество CPU ресурсов и будет работать несколько минут:

real    2m29.608s
user    2m29.564s
sys    0m0.012s

Но на выходе мы получим просто потрясающие результаты! Число сетей сократится в 10 раз:

wc -l  /root/dataix_networks_list_aggregated_new.dat
24628 /root/dataix_networks_list_aggregated_new.dat

А число хостов вдвое:

Total networks size: 232866112
Total Internet size: 4294967296

Это особенно актуально, когда Вы сильно стеснены в аппаратных ресурсах (число ACL на свиче, число route префиксов l3 свиче).

Такой же способ оптимизации можно использовать и для FastNetMon, чтобы зазря не выделять память для сетей, которые вложены друг в друга :) 

Generate BGP filters with BGPQ3

Build it:

cd /tmp
wget http://snar.spb.ru/prog/bgpq3/bgpq3-0.1.31.tgz
tar -xvzf bgpq3-0.1.31.tgz
cd bgpq3-0.1.31/
./configure --prefix=/opt/bgpq3
sudo mkdir -p /opt/bgpq3/bin
sudo make install

Generate filter list by ASN (actually you could use AS-SET here too):

 /opt/bgpq3/bin/bgpq3 AS24940
no ip prefix-list NN
ip prefix-list NN permit 5.9.0.0/16
ip prefix-list NN permit 46.4.0.0/16
ip prefix-list NN permit 78.46.0.0/15
ip prefix-list NN permit 85.10.192.0/18
ip prefix-list NN permit 88.198.0.0/16
ip prefix-list NN permit 91.220.49.0/24
ip prefix-list NN permit 91.233.8.0/22
ip prefix-list NN permit 136.243.0.0/16
ip prefix-list NN permit 138.201.0.0/16
ip prefix-list NN permit 144.76.0.0/16
ip prefix-list NN permit 148.251.0.0/16
ip prefix-list NN permit 176.9.0.0/16
ip prefix-list NN permit 176.102.168.0/21
ip prefix-list NN permit 178.63.0.0/16
ip prefix-list NN permit 185.12.64.0/22
ip prefix-list NN permit 185.50.120.0/23
ip prefix-list NN permit 188.40.0.0/16
ip prefix-list NN permit 193.25.170.0/23
ip prefix-list NN permit 193.28.90.0/24
ip prefix-list NN permit 193.110.6.0/23
ip prefix-list NN permit 193.223.77.0/24
ip prefix-list NN permit 194.42.180.0/22
ip prefix-list NN permit 194.42.184.0/22
ip prefix-list NN permit 194.145.226.0/24
ip prefix-list NN permit 195.248.224.0/24
ip prefix-list NN permit 197.242.84.0/22
ip prefix-list NN permit 213.133.96.0/19
ip prefix-list NN permit 213.169.144.0/22
ip prefix-list NN permit 213.239.192.0/18

This toolkit supports so much options for diffrent vendors (and even json!).

Great thanks to author, Alexander Snarski.

Official site: here.

В случае ошибки:

FATAL ERROR:Partial write to radb, only 7 bytes written: Connection reset by peer

На Linux делаем вот так:

sysctl -w net.ipv4.tcp_window_scaling=1
sysctl -w net.core.rmem_max=33554432
sysctl -w net.core.wmem_max=33554432
sysctl -w net.ipv4.tcp_rmem="4096 87380 33554432"
sysctl -w net.ipv4.tcp_wmem="4096 65536 33554432"

How to run netmap on single queue and use another queues for Linux stack

Hello, folks!

I will do some ixgbe magic here! Please stay tuned =)

Here I could provide short reference about netmap compilation with patched ixgbe driver.

First of all you should get my patched driver. In this driver I have assigned first (0) queue to netmap and assigned another queues to Linux network stack.

Get driver sources and put they to "fake" Linux kernel source tree (netmap build system expect this):

cd /usr/src
mkdir -p /usr/src/fake_linux_kernel_sources/drivers/net/ethernet/intel
cd /usr/src/fake_linux_kernel_sources/drivers/net/ethernet/intel
git clone https://github.com/pavel-odintsov/ixgbe-linux-netmap-single-queue.git ixgbe_temp
mv ixgbe_temp/ixgbe-3.23.2.1/src/ ixgbe

Let's get netmap:

cd /usr/src
git clone https://github.com/luigirizzo/netmap.git -b next
cd netmap/LINUX/

Do some netmap patching:

sed -i 's/#define ixgbe_driver_name netmap_ixgbe_driver_name/\/\/\0/'  ixgbe_netmap_linux.h
sed -i 's/^char ixgbe_driver_name\[\]/\/\/\0/'  ixgbe_netmap_linux.h
sed -i '/$t\s\{1,\}if \[ \-f patches/d' configure

Let's compile it:

./configure --kernel-sources=/usr/src/fake_linux_kernel_sources --drivers=ixgbe
make

Unload old ixgbe not patched driver:

rmmod ixgbe

Load netmap:

insmod /usr/src/netmap/LINUX/netmap.ko
insmod /usr/src/netmap/LINUX/ixgbe/ixgbe.ko

Well, we have netmap which could process only first NIC hardware queue.

We should check it. For tests I will use flow director and flow all udp packets to 53 port to first queue:

ethtool -K eth5 ntuple on
ethtool --config-ntuple eth5 flow-type udp4 dst-port 53 action 0

Then we should built test environment.

Please compule test netmap receiver:

cd /usr/src/netmap/examples/
make

Yes, we are ready for tests!

Please run linux network stack receiver app in one console session:

tcpdump -n -i eth5

And netmap reciver app in another console session:

/usr/src/netmap/examples/pkt-gen -f rx -X -i netmap:eth5

Actually, we need external machine and please start pinging of target host from it and let's send udp packet to it from another session.

For udp packets generation you could use nc:

echo asdasda| nc -u 10.10.10.221  53

And you will saw:

 ./pkt-gen -f rx -i netmap:eth5 -X
689.290532 main [1651] interface is netmap:eth5
689.290977 extract_ip_range [288] range is 10.0.0.1:0 to 10.0.0.1:0
689.291015 extract_ip_range [288] range is 10.1.0.1:0 to 10.1.0.1:0
689.517212 main [1848] mapped 334980KB at 0x7fcf508ea000
Receiving from netmap:eth5: 1 queues, 1 threads and 1 cpus.
689.517331 main [1910] --- SPECIAL OPTIONS:

689.517345 main [1934] Wait 2 secs for phy reset
691.517508 main [1936] Ready...
691.517870 nm_open [456] overriding ifname eth5 ringid 0x0 flags 0x1
691.522007 receiver_body [1184] reading from netmap:eth5 fd 4 main_fd 3
692.523020 main_thread [1448] 0 pps (0 pkts in 1001104 usec)
692.525560 receiver_body [1191] waiting for initial packets, poll returns 0 0
693.524487 main_thread [1448] 0 pps (0 pkts in 1001468 usec)
693.528806 receiver_body [1191] waiting for initial packets, poll returns 0 0
694.525850 main_thread [1448] 0 pps (0 pkts in 1001363 usec)
694.532073 receiver_body [1191] waiting for initial packets, poll returns 0 0
695.526988 main_thread [1448] 0 pps (0 pkts in 1001137 usec)
695.535358 receiver_body [1191] waiting for initial packets, poll returns 0 0
696.528438 main_thread [1448] 0 pps (0 pkts in 1001450 usec)
696.538669 receiver_body [1191] waiting for initial packets, poll returns 0 0
697.529608 main_thread [1448] 0 pps (0 pkts in 1001170 usec)
697.542189 receiver_body [1191] waiting for initial packets, poll returns 0 0
698.530749 main_thread [1448] 0 pps (0 pkts in 1001141 usec)
698.545628 receiver_body [1191] waiting for initial packets, poll returns 0 0
699.531875 main_thread [1448] 0 pps (0 pkts in 1001126 usec)
699.549208 receiver_body [1191] waiting for initial packets, poll returns 0 0
700.532999 main_thread [1448] 0 pps (0 pkts in 1001124 usec)
700.552431 receiver_body [1191] waiting for initial packets, poll returns 0 0
ring 0x7fcf50954000 cur     0 [buf   4611 flags 0x0000 len    60]
    0: 90 e2 ba 83 3f 25 90 e2 ba 78 26 8d 08 00 45 00 ....?%...x&...E.
   16: 00 24 ce 85 40 00 40 11 43 49 0a 0a 0a 0a 0a 0a .$..@.@.CI......
   32: 0a dd ed 13 00 35 00 10 4f 47 61 73 64 61 73 64 .....5..OGasdasd
   48: 61 0a 00 00 00 00 00 00 00 00 00 00
701.534128 main_thread [1448] 1 pps (1 pkts in 1001129 usec)
702.535260 main_thread [1448] 0 pps (0 pkts in 1001132 usec)
703.536380 main_thread [1448] 0 pps (0 pkts in 1001120 usec)

And in tcpdump window:

tcpdump -n -i eth5
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth5, link-type EN10MB (Ethernet), capture size 262144 bytes
08:01:36.520074 IP 10.10.10.10 > 10.10.10.221: ICMP echo request, id 6581, seq 21, length 64
08:01:36.520114 IP 10.10.10.221 > 10.10.10.10: ICMP echo reply, id 6581, seq 21, length 64
08:01:37.519971 IP 10.10.10.10 > 10.10.10.221: ICMP echo request, id 6581, seq 22, length 64
08:01:37.520009 IP 10.10.10.221 > 10.10.10.10: ICMP echo reply, id 6581, seq 22, length 64
08:01:38.520028 IP 10.10.10.10 > 10.10.10.221: ICMP echo request, id 6581, seq 23, length 64
08:01:38.520060 IP 10.10.10.221 > 10.10.10.10: ICMP echo reply, id 6581, seq 23, length 64
08:01:39.520091 IP 10.10.10.10 > 10.10.10.221: ICMP echo request, id 6581, seq 24, length 64
08:01:39.520130 IP 10.10.10.221 > 10.10.10.10: ICMP echo reply, id 6581, seq 24, length 64
08:01:40.520096 IP 10.10.10.10 > 10.10.10.221: ICMP echo request, id 6581, seq 25, length 64
08:01:40.520134 IP 10.10.10.221 > 10.10.10.10: ICMP echo reply, id 6581, seq 25, length 64
08:01:41.520030 IP 10.10.10.10 > 10.10.10.221: ICMP echo request, id 6581, seq 26, length 64
08:01:41.520064 IP 10.10.10.221 > 10.10.10.10: ICMP echo reply, id 6581, seq 26, length 64
08:01:42.520016 IP 10.10.10.10 > 10.10.10.221: ICMP echo request, id 6581, seq 27, length 64
08:01:42.520053 IP 10.10.10.221 > 10.10.10.10: ICMP echo reply, id 6581, seq 27, length 64
08:01:43.520086 IP 10.10.10.10 > 10.10.10.221: ICMP echo request, id 6581, seq 28, length 64
08:01:43.520125 IP 10.10.10.221 > 10.10.10.10: ICMP echo reply, id 6581, seq 28, length 64
^C
16 packets captured
16 packets received by filter
0 packets dropped by kernel

As you can see. Linux haven't saw UDP packets to 53 port but still process icmp packets. Everything works well! Hurra!

 Folks, be aware. This patch is very rude and not tested well. And we need some way for detaching this queue from Linux side because for ICMP packets case Linux try to send reply packets over detached queue. Haha, actually, we could do it very simple. We could disable tx queue detaching and use it for Linux.

And we need do some custom RING number tuning for ixgbe driver.

Finalyly, this approach working but need some enhancements :) 

Сборка libbgpdump на Debian 8 Jessy

Офсайт: http://www.ris.ripe.net/source/bgpdump/

apt-get install -y libbz2-dev zlib1g-dev
cd /usr/src
wget http://www.ris.ripe.net/source/bgpdump/libbgpdump-1.4.99.15.tgz
tar -xf libbgpdump-1.4.99.15.tgz
cd libbgpdump-1.4.99.15
./configure --prefix=/opt/libbgpdump
make install

Добавляем:

echo "/opt/libbgpdump/lib" > /etc/ld.so.conf.d/libbgpdump.conf

ldconfig

Вызываем:

 /opt/libbgpdump/bin/bgpdump

Самый простой способ использовать новое ядро в Debian Jessie - взять из Sid

Друзья! Этот вариант для суровых экспериментаторов, которые знают, как починить систему после такого вандализма! Если Вы не знаете - то и ядро Вам обновлять не нужно, честно говорю! 

Скачать отсюда:  https://packages.debian.org/sid/amd64/linux-image-4.0.0-2-amd64/download

Так:

wget http://ftp.us.debian.org/debian/pool/main/l/linux/linux-headers-4.0.0-2-amd64_4.0.5-1_amd64.deb
wget http://ftp.us.debian.org/debian/pool/main/l/linux/linux-image-4.0.0-2-amd64_4.0.5-1_amd64.deb
wget http://ftp.us.debian.org/debian/pool/main/l/linux/linux-compiler-gcc-4.9-x86_4.0.5-1_amd64.deb
wget http://ftp.us.debian.org/debian/pool/main/l/linux/linux-headers-4.0.0-2-common_4.0.5-1_amd64.deb
wget http://ftp.us.debian.org/debian/pool/main/l/linux-tools/linux-kbuild-4.0_4.0.2-1_amd64.deb

И поставить через:

dpkg -i linux-compiler-gcc-4.9-x86_4.0.5-1_amd64.deb  linux-kbuild-4.0_4.0.2-1_amd64.deb
dpkg -i linux-image-4.0.0-2-amd64_4.0.5-1_amd64.deb
dpkg -i linux-headers-4.0.0-2-common_4.0.5-1_amd64.deb
dpkg -i linux-headers-4.0.0-2-amd64_4.0.5-1_amd64.deb

How to run netmap on ixgbe Virtual Function on Debian 8 Jessie

UPDATE: folks, please be AWARE! In this mode netmap working only in single-copy mode and will not work enough fast (1-2 mpps is a limit). For full support we need another patch for ixgbevf driver.

If you want zero copy support, please poke netmap guys here: https://github.com/luigirizzo/netmap/issues/63

First of all, install Netmap and ixgbe module: http://www.stableit.ru/2014/10/netmap-debian-7-wheezy-intel-82599.html

Please add this code to /etc/rc.local (please remove -e flag from /bin/sh in first line of /etc/rc.local):

insmod /usr/src/netmap/LINUX/netmap.ko
modprobe mdio
modprobe ptp
modprobe dca
insmod /usr/src/netmap/LINUX/ixgbe/ixgbe.ko max_vfs=2,2
insmod /lib/modules/3.16.0-4-amd64/kernel/drivers/net/ethernet/intel/ixgbevf/ixgbevf.ko

And reload server!

 Then, I have physical NIC eth6 which represented as 2 virtual NICs (ip link show):

8: eth6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 90:e2:ba:4a:d8:e8 brd ff:ff:ff:ff:ff:ff
    vf 0 MAC 90:e2:ba:55:aa:bb, spoof checking on, link-state auto
    vf 1 MAC 90:e2:ba:55:bb:cc, spoof checking on, link-state auto
15: eth10: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 90:e2:ba:55:aa:bb brd ff:ff:ff:ff:ff:ff
16: eth11: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 90:e2:ba:55:bb:cc brd ff:ff:ff:ff:ff:ff

Then, I configure MAC's for both virtual functions:

ip link set eth6 vf 0 mac 90:e2:ba:55:aa:bb
ip link set eth6 vf 1 mac 90:e2:ba:55:bb:cc

And reload ixgbevf driver (required for configuration):

rmmod ixgbevf
modprobe ixgbevf

After this operations all interfaces become ready:

ethtool eth6
Settings for eth6:
    Supported ports: [ FIBRE ]
    Supported link modes:   1000baseT/Full
                            10000baseT/Full
    Supported pause frame use: No
    Supports auto-negotiation: Yes
    Advertised link modes:  1000baseT/Full
                            10000baseT/Full
    Advertised pause frame use: Symmetric
    Advertised auto-negotiation: Yes
    Speed: 10000Mb/s
    Duplex: Full
    Port: FIBRE
    PHYAD: 0
    Transceiver: external
    Auto-negotiation: on
    Supports Wake-on: d
    Wake-on: d
    Current message level: 0x00000007 (7)
                   drv probe link
    Link detected: yes
root@filteredclient ~ # ethtool eth10
Settings for eth10:
    Supported ports: [ ]
    Supported link modes:   10000baseT/Full
    Supported pause frame use: No
    Supports auto-negotiation: No
    Advertised link modes:  Not reported
    Advertised pause frame use: No
    Advertised auto-negotiation: No
    Speed: 10000Mb/s
    Duplex: Full
    Port: Other
    PHYAD: 0
    Transceiver: Unknown!
    Auto-negotiation: off
    Current message level: 0x00000007 (7)
                   drv probe link
    Link detected: yes
root@filteredclient ~ # ethtool eth11
Settings for eth11:
    Supported ports: [ ]
    Supported link modes:   10000baseT/Full
    Supported pause frame use: No
    Supports auto-negotiation: No
    Advertised link modes:  Not reported
    Advertised pause frame use: No
    Advertised auto-negotiation: No
    Speed: 10000Mb/s
    Duplex: Full
    Port: Other
    PHYAD: 0
    Transceiver: Unknown!
    Auto-negotiation: off
    Current message level: 0x00000007 (7)
                   drv probe link
    Link detected: yes

And run pkt-get example app on ixgbe VF:

./pkt-gen -f rx -i netmap:eth10
361.732713 main [1651] interface is netmap:eth10
361.733491 extract_ip_range [288] range is 10.0.0.1:0 to 10.0.0.1:0
361.733506 extract_ip_range [288] range is 10.1.0.1:0 to 10.1.0.1:0
361.734155 main [1848] mapped 334980KB at 0x7f5f9804f000
Receiving from netmap:eth10: 1 queues, 1 threads and 1 cpus.
361.734182 main [1934] Wait 2 secs for phy reset
363.734288 main [1936] Ready...
363.734328 nm_open [456] overriding ifname eth10 ringid 0x0 flags 0x1
363.734384 receiver_body [1184] reading from netmap:eth10 fd 4 main_fd 3
364.735415 main_thread [1448] 3 pps (3 pkts in 1001042 usec)
365.736481 main_thread [1448] 1 pps (1 pkts in 1001065 usec)
366.737542 main_thread [1448] 1 pps (1 pkts in 1001061 usec)
^C367.134692 main_thread [1448] 0 pps (0 pkts in 397151 usec)

10 го июня выступаю на Enog9 в Казани

Всем хай! Буду рассказывать про отражение DDoS атак силами FastNetMon, живу в гранд отеле, пишите координаты ;)

Linux CPU Info Intel(R) Xeon(R) CPU D-1540

Very interesting CPU:

processor    : 15
vendor_id    : GenuineIntel
cpu family    : 6
model        : 86
model name    : Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz
stepping    : 2
microcode    : 0x7
cpu MHz        : 800.390
cache size    : 12288 KB
physical id    : 0
siblings    : 16
core id        : 7
cpu cores    : 8
apicid        : 15
initial apicid    : 15
fpu        : yes
fpu_exception    : yes
cpuid level    : 20
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap
bogomips    : 4000.14
clflush size    : 64
cache_alignment    : 64
address sizes    : 46 bits physical, 48 bits virtual
power management:

kernel BUG at /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/iscsi.c:392!

Выбили вот такой мерзопакостный баг на Debian 7 попытавшись с машины,

где примонтирован LUN сделать smartctl -all:  

[184269.064497] device eth3 left promiscuous mode

[186412.825825] iscsi_trgt: BUG at /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/iscsi.c:392 assert(req->tio)

[186412.825876] Pid: 2488, comm: istiod2 Tainted: G O 3.2.0-4-amd64 #1 Debian 3.2.54-2

[186412.825879] Call Trace:

[186412.825888] [<ffffffffa01cd3f1>] ? send_data_rsp+0x45/0x1f4 [iscsi_trgt]

[186412.825893] [<ffffffffa01d60df>] ? ua_pending+0x19/0xa5 [iscsi_trgt]

[186412.825898] [<ffffffffa01d4db4>] ? disk_execute_cmnd+0x1cf/0x22d [iscsi_trgt]

[186412.825903] [<ffffffffa01d0a3d>] ? worker_thread+0xfd/0x255 [iscsi_trgt]

[186412.825908] [<ffffffff8103f6ba>] ? try_to_wake_up+0x197/0x197

[186412.825912] [<ffffffffa01d0940>] ? nthread_stop+0x35/0x35 [iscsi_trgt]

[186412.825947] [<ffffffff8105f681>] ? kthread+0x76/0x7e

[186412.825956] [<ffffffff81356ef4>] ? kernel_thread_helper+0x4/0x10

[186412.825963] [<ffffffff8105f60b>] ? kthread_worker_fn+0x139/0x139

[186412.825971] [<ffffffff81356ef0>] ? gs_change+0x13/0x13

[186412.825995] ------------[ cut here ]------------

[186412.826011] kernel BUG at /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/iscsi.c:392!

[186412.826072] invalid opcode: 0000 [#1] SMP

[186412.826130] CPU 1

[186412.826138] Modules linked in: iscsi_trgt(O) crc32c loop snd_pcm coretemp snd_page_alloc crc32c_intel ghash_clmulni_intel aesni_intel snd_timer aes_x86_64 acpi_cpufreq mperf aes_generic sb_edac snd processor i2c_i801 iTCO_wdt ioatdma soundcore iTCO_vendor_support cryptd edac_core joydev i2c_core thermal_sys pcspkr evdev wmi container button ext3 mbcache jbd usbhid hid sg sd_mod crc_t10dif ehci_hcd ahci libahci libata usbcore igb dca usb_common megaraid_sas scsi_mod [last unloaded: scsi_wait_scan]

[186412.826712]

[186412.826749] Pid: 2488, comm: istiod2 Tainted: G O 3.2.0-4-amd64 #1 Debian 3.2.54-2 Intel Corporation S2600CP/S2600CP

[186412.826857] RIP: 0010:[<ffffffffa01cd3f1>] [<ffffffffa01cd3f1>] send_data_rsp+0x45/0x1f4 [iscsi_trgt]

[186412.826948] RSP: 0018:ffff88022a547e10 EFLAGS: 00010286

[186412.826997] RAX: 0000000000000000 RBX: ffff8802216b1ae0 RCX: 0000000000001d05

[186412.827079] RDX: 0000000000001d05 RSI: ffff88022a547f58 RDI: ffff88022a547f58

[186412.827160] RBP: 0000000000000000 R08: 0000000000000002 R09: 00000000fffffffe

[186412.827242] R10: 0000000000000000 R11: 0000000000000002 R12: ffff880230281160

[186412.827323] R13: ffff880071534000 R14: ffff88022d5dde58 R15: ffff88022d5dde68

[186412.827405] FS: 0000000000000000(0000) GS:ffff880235820000(0000) knlGS:0000000000000000

[186412.827490] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b

[186412.827541] CR2: 00007fff65423ba8 CR3: 0000000001605000 CR4: 00000000000406e0

[186412.827623] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

[186412.827705] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400

[186412.827787] Process istiod2 (pid: 2488, threadinfo ffff88022a546000, task ffff880230281160)

[186412.827871] Stack:

[186412.827908] ffff880200000000 ffff88023421c0c0 0000000000013780 ffffffffa01d60df

[186412.828005] ffff88022a547fd8 ffff8802216b1ae0 ffff880230281160 ffff880230281160

[186412.828102] ffff880071534000 ffff88022d5dde58 ffff88022d5dde68 ffffffffa01d4db4

[186412.828198] Call Trace:

[186412.828241] [<ffffffffa01d60df>] ? ua_pending+0x19/0xa5 [iscsi_trgt]

[186412.828298] [<ffffffffa01d4db4>] ? disk_execute_cmnd+0x1cf/0x22d [iscsi_trgt]

[186412.828382] [<ffffffffa01d0a3d>] ? worker_thread+0xfd/0x255 [iscsi_trgt]

[186412.828437] [<ffffffff8103f6ba>] ? try_to_wake_up+0x197/0x197

[186412.828491] [<ffffffffa01d0940>] ? nthread_stop+0x35/0x35 [iscsi_trgt]

[186412.828546] [<ffffffff8105f681>] ? kthread+0x76/0x7e

[186412.828596] [<ffffffff81356ef4>] ? kernel_thread_helper+0x4/0x10

[186412.828650] [<ffffffff8105f60b>] ? kthread_worker_fn+0x139/0x139

[186412.828703] [<ffffffff81356ef0>] ? gs_change+0x13/0x13

[186412.828752] Code: 48 85 ed 75 28 48 c7 c1 38 7d 1d a0 ba 88 01 00 00 48 c7 c6 a7 79 1d a0 48 c7 c7 df 79 1d a0 31 c0 e8 5c c1 17 e1 e8 8b a6 17 e1 <0f> 0b 48 89 df e8 d0 fa ff ff 8b 55 14 39 d0 0f 46 d0 85 d2 0f

[186412.829173] RIP [<ffffffffa01cd3f1>] send_data_rsp+0x45/0x1f4 [iscsi_trgt]

[186412.829232] RSP <ffff88022a547e10>

[186412.829825] ---[ end trace e43aba698581fccf ]---

[186413.508062] general protection fault: 0000 [#2] SMP

[186413.508324] CPU 0

[186413.508403] Modules linked in: iscsi_trgt(O) crc32c loop snd_pcm coretemp snd_page_alloc crc32c_intel ghash_clmulni_intel aesni_intel snd_timer aes_x86_64 acpi_cpufreq mperf aes_generic sb_edac snd processor i2c_i801 iTCO_wdt ioatdma soundcore iTCO_vendor_support cryptd edac_core joydev i2c_core thermal_sys pcspkr evdev wmi container button ext3 mbcache jbd usbhid hid sg sd_mod crc_t10dif ehci_hcd ahci libahci libata usbcore igb dca usb_common megaraid_sas scsi_mod [last unloaded: scsi_wait_scan]

[186413.512625]

[186413.512730] Pid: 2486, comm: istd2 Tainted: G D O 3.2.0-4-amd64 #1 Debian 3.2.54-2 Intel Corporation S2600CP/S2600CP

[186413.513108] RIP: 0010:[<ffffffff81036280>] [<ffffffff81036280>] __wake_up_common+0x3d/0x77

[186413.513336] RSP: 0018:ffff88022ab73ce0 EFLAGS: 00010083

[186413.513451] RAX: ffff88022a547e90 RBX: 0000000000000001 RCX: 0000000000000000

[186413.513599] RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffff88022a547e90

[186413.513746] RBP: 0000000000000003 R08: 0000000000000000 R09: ffffffff81406060

[186413.513894] R10: 0000000000013780 R11: 0000000000003428 R12: ffffffffffffffe8

[186413.514042] R13: 0000000005010500 R14: 0000000000000000 R15: ffff88022d5dde70

[186413.514191] FS: 0000000000000000(0000) GS:ffff880235800000(0000) knlGS:0000000000000000

[186413.514342] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b

[186413.514459] CR2: 00007f7bd8ca9594 CR3: 0000000001605000 CR4: 00000000000406f0

[186413.514607] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000

[186413.514755] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400

[186413.514903] Process istd2 (pid: 2486, threadinfo ffff88022ab72000, task ffff88022b5b6ea0)

[186413.515053] Stack:

[186413.515157] 00000000000008d0 0000000000000000 0000000000000246 ffff88022d5dde68

[186413.515593] 0000000000000286 000000000000dba9 000000000000dbaa ffff880135ee0098

[186413.516028] 0000000000000001 ffffffff81037f81 0000000000000009 0000000000000000

[186413.516464] Call Trace:

[186413.516573] [<ffffffff81037f81>] ? __wake_up+0x35/0x46

[186413.516693] [<ffffffffa01ce20c>] ? iscsi_session_push_cmnd+0x1ba/0x24f [iscsi_trgt]

[186413.516845] [<ffffffffa01cfcca>] ? istd+0x500/0x101e [iscsi_trgt]

[186413.516966] [<ffffffff812ddf60>] ? inet_dgram_connect+0x72/0x72

[186413.517087] [<ffffffff8134ea11>] ? __schedule+0x5f9/0x610

[186413.517205] [<ffffffffa01cf7ca>] ? nthread_wakeup+0x2c/0x2c [iscsi_trgt]

[186413.517328] [<ffffffff8105f681>] ? kthread+0x76/0x7e

[186413.517446] [<ffffffff81356ef4>] ? kernel_thread_helper+0x4/0x10

[186413.517566] [<ffffffff8105f60b>] ? kthread_worker_fn+0x139/0x139

[186413.517685] [<ffffffff81356ef0>] ? gs_change+0x13/0x13

[186413.517800] Code: 53 89 d3 48 83 ec 18 48 8b 57 08 4c 8b 22 48 8d 42 e8 49 83 ec 18 eb 35 44 8b 28 4c 89 c1 4c 89 44 24 08 44 89 f2 89 ee 48 89 c7 <ff> 50 10 85 c0 4c 8b 44 24 08 74 0a 41 80 e5 01 74 04 ff cb 74

[186413.522659] RIP [<ffffffff81036280>] __wake_up_common+0x3d/0x77

[186413.522849] RSP <ffff88022ab73ce0>

[186413.522959] ---[ end trace e43aba698581fcd0 ]---

Как починить:  https://www.vaspects.com/2013/11/01/esxi-5-5-crashes-linux-iscsi_trgt/ коротко - обновляйтесь версию айскази модуля на ту, что поставляется в сорцах либо переходите на Jessie :)