Настройка роутинг демона 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 :)

Technical comparison of OpenVZ and commercial Virtualization Platforms from Parallels/Odin

There are bunch promotion articles about PCS (Parallels/Odin Cloud Server) and Virtuozzo. But I can't find any technical comparison between OpenVZ (open source and free) and commercial platforms.

I have 7 years experience with OpenVZ and 2 year experience with PCS in heavy production, thus I could create this comparison table manually :)

Feature	Commercial	OpenVZ
API	Yes	No
Central management	Yes, PVA (awfully buggy)	No, multiple open source solutions
Toolkit for compaction of fat ploop images	Yes, pcompact	No, but could be done in few lines of code with vzctl compact
Toolkit for migration physical servers to containers	Yes, p2c migrate	No
Rebootless kernel update (without physical server rebootm kernel reboot only)	Yes, vzreboot	No
Pure kernel live updates (without physical server reboot, no kernel reboot)	No, only with external tool KernelCare	No, only with external tool KernelCare
Repair mode for VPS	Yes	No
Live migration between servers (no zero downtime)	Yes	Yes
Live migration between servers (zero downtime)	Yes	No
Flexible container OS templates	Yes, vztemplates	No, only precreated templates
Memory deduplication for binary files	Yes, pfcache techology	No
Support for cloud storages for containers	Yes, Parallels Cloud Storage	No, only NFS
Completely isolated disk subsystem for containers	Yes, ploop	Yes, ploop
Support for fully virtualized virtual machines	Yes, bundled support for Parallels VM	No but works perfectly with KVM on same server
Fast and reliable kernel on top of RHEL 2.6.32	Yes (same version as OpenVZ)	Yes
Full backup capability	Yes	No but open source solutions exists
Incremental backup	Yes	No and no open source solutions
NUMA optimization (balancing)	Yes	No, but some open source solutions exists

Finally, you could decide what are you want and select proper product for your company.

Технология дедупликации бинарных файлов в OpenVZ - pfcache и оценка ее эффективности

Что это такое?

Это довольно грамотный и умный механизм, суть которой сводится к хешированию (SHA-1) определенных файлов в папках (стандартно /bin, /lib, /lib64, /opt, /sbin, /usr источник, стр 15) внутри контейнера и сохранению их хэшей в расширенных атрибутах ext4 (xattr).

То есть схема такая:
1) Ставится ОС в контейнер
2) User space демон pfcached забегает в контейнер и прописывает SHA-1 хэши в расширенные атрибуты ext4 для всех файлов в папках /bin, /lib, /lib64, /opt, /sbin, /usr.

В случае, когда установка идет из ранее подготовленных ploop тушек, генерации можно избежать. Также ее можно избежать, если особым образом перепаковать обычные щаблоны с download.openvz.org.

Но если кратко далее алгоритм ведет себя так — если происходит попытка открытия файла, для которого у нас есть ключевая сумма в inode, мы обращаемся к таблице, где у нас содержатся все ключевые суммы уже загруженных каким-либо иным контейнером библиотек и если мы находим файл с таким же хеэшем, то просто подменяем попытку открытия на этот самый файл.

Также подобные «общие» файлы выносятся (тупо копируются) в отдельную файловую иерархию /vz/pfcache силами специального демона (имеется лишь в проприетарной версии OpemVZ - PCS/Virtuozzo). За счет этого множественные загрузки данных бинарных файлов в память из разных контейнеров приводят к тому, что они занимают меньше места в оперативной памяти и кэшируются (в страничном кэше Linux) ровно один раз. Что дает очень весомый профит в экономии памяти и работе системы в целом. Причем, наибольшей экономии удается добиться именно в случае, когда все контейнеры максимально унифицированы по версиям ПО/дистрибутивам.

Ради интереса содержимое этого спец дескриптора можно прочесть вот так:

getfattr -ntrusted.pfcache --only-values /vz/root/51822/usr/lib/apache2/mpm-prefork/apache2 2>/dev/null

На выходе получим обычный SHA1:

563a0ab97f09171c4b5ac9bcf1602c2aeb3eab18

Насколько это эффективная штука можно провести исследование самолично: https://gist.github.com/vps2fast/eb15c7de0dd7ff38a30e

В конкретно нашем случае (довольно большой разброд в ОС - 3 версии Debian, 2 версии CentOS + немного кастомных дистрибутивов и все это в различном состоянии обновленности)экономия составила около 2.5-4%, что очень высокая цена за фактическую потерю одного ядра (используется процессом pfcached, который хэширует файлы).

Но в случае, когда у Вас везде одна и та же ОС - это может дать весьма положительный эффект.

Оценка эффективности сжатия OpenVZ ploop образов

Общее

В процессе эксплуатации наших ферм (а именно при их резервированными посредством нашего кастомного бэкап решения) мы обнаружили, что в среднем бинарные файлы ploop сжимаются в 2-4 раза (в зависимости от данных хранимых внутри). При этом используемое нами оборудование позволяет выполнять сжатие посредством многопоточного архиватора pigz на столь высоких скоростях, что время просто архивации без сжатия совпадает со временем архивации со сжатием, также при этом используется довольно малое число процессорных ресурсов.

Преимущество сжатие образов

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

Тесты

Чтобы максимально четко описать преимущества и реальную эффективность подхода мы выбрали наиболее "реальные" серверы с реальными клиентами и произвели замеры эффективности их сжатия. В процессе тестов мы попытались выполнить бинарное сжатие посредством архиватора gzip/pigz с целью показать, что внедрение функции сжатия в ploop контейнеры может дать огромный эффект по ускорению доступа к данным, а также по экономии дискового пространства. Далее приводятся результаты сжатия ploop образов от OpenVZ и Parallels Cloud Server. Сжатие осуществлялось тулкитом pigz: tar --use-compress-program=pigz -cpf

testovz1 / OpenVZ

Объем, занимаемый ploop образами до сжатия:  161G

После сжатия: 83 Gb

Итог: 1.93 раза сжатие

testpcs1 / Parallels Cloud Server

Объем, занимаемый ploop образами до сжатия:  427G

После сжатия: 258G

Итог: 1.6 раза сжатие

Выводы

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

Python: TypeError: execve() arg 3 contains a non-string value

This code will definitely produce this error:

new_env = os.environ.copy()
new_env['MY_ENV'] = 1234
subprocess.Popen( ['/bin/echo'], env=new_env)

How to fix? Add explicit conversion to str():

new_env = os.environ.copy()
new_env['MY_ENV'] = str(1234(
subprocess.Popen( ['/bin/echo'], env=new_env)

Как избавится от "No irq handler for vector (irq -1)" внутри KVM машины?

Среда - Debian 7 на железе и внутри виртуальной машины. Просто надо вырубить irqbalanced и на ноде и внутри виртуальной машины!

Если машины на systemd, то делать это так:

systemctl stop irqbalance
systemctl disable irqbalance