Бордер на Linux

[inxs]

2.6.23.14, q6600, 4G, 2x E1000 в транке, quagga, nat.

 

Периодически вечерами ksoftirqd съедает полностью два ядра, при этом сам сервер начинает подтормаживать и задержка вырастает до 8-10мс. От количества пакетов практически не зависит, т.е. такая ерунда может начаться и при 95к и при 105к. Видимо кто-то флудит.

netstat -s

Ip:
    16002647 total packets received
    101635611 with invalid headers
    4034600619 forwarded
    38662 with unknown protocol
    0 incoming packets discarded
    74087958 incoming packets delivered
    544071112 requests sent out
    335 dropped because of missing route
    6612377 fragments dropped after timeout
    1376315865 reassemblies required
    111618970 packets reassembled ok
!!    1079311284 packet reassembles failed
    49453240 fragments received ok
    151210801 fragments created
Icmp:
    5995677 ICMP messages received
    3010449 input ICMP message failed.
    ICMP input histogram:
        destination unreachable: 126198
        timeout in transit: 966993
        wrong parameters: 11
        source quenches: 38
        echo requests: 1899805
        echo replies: 10669
        timestamp request: 5
        timestamp reply: 7
        address mask request: 3
        address mask replies: 47
    3207479363 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        time exceeded: 101631372
        echo replies: 1899805
        timestamp replies: 5
Tcp:
    1024711 active connections openings
    1142609 passive connection openings
    756598 failed connection attempts
    94188 connection resets received
    16 connections established
    65877418 segments received
    60260680 segments send out
    73322 segments retransmited
    877 bad segments received.
    450374 resets sent
Udp:
    1695763 packets received
    481918 packets to unknown port received.
    4 packet receive errors
    1697547 packets sent
UdpLite:
TcpExt:
    744 resets received for embryonic SYN_RECV sockets
    1176 packets pruned from receive queue because of socket buffer overrun
    27 ICMP packets dropped because they were out-of-window
    9 ICMP packets dropped because socket was locked
    71441 TCP sockets finished time wait in fast timer
    211 time wait sockets recycled by time stamp
    199 packets rejects in established connections because of timestamp
    2422014 delayed acks sent
    642 delayed acks further delayed because of locked socket
    Quick ack mode was activated 45027 times
    9219988 packets directly queued to recvmsg prequeue.
    223822056 of bytes directly received from backlog
    1669071583 of bytes directly received from prequeue
    31217598 packet headers predicted
    10223256 packets header predicted and directly queued to user
    6400145 acknowledgments not containing data received
    8152998 predicted acknowledgments
    271 times recovered from packet loss due to SACK data
    Detected reordering 1 times using time stamp
    16 congestion windows partially recovered using Hoe heuristic
    TCPDSACKUndo: 10
    8668 congestion windows recovered after partial ack
    2393 TCP data loss events
    326 timeouts after reno fast retransmit
    422 timeouts after SACK recovery
    877 timeouts in loss state
    4423 fast retransmits
    32 forward retransmits
    83 retransmits in slow start
    52317 other TCP timeouts
    11 sack retransmits failed
    1 times receiver scheduled too late for direct processing
    111297 packets collapsed in receive queue due to low socket buffer
    31149 DSACKs sent for old packets
    3620 DSACKs sent for out of order packets
    13098 DSACKs received
    65705 connections reset due to unexpected data
    91929 connections reset due to early user close
    458 connections aborted due to timeout
IpExt:
    InTruncatedPkts: 69580
    InMcastPkts: 38661
    InBcastPkts: 120676

 

ethtool -S eth0

NIC statistics:
     rx_packets: 818691546870
     tx_packets: 817733606761
     rx_bytes: 562829984869843
     tx_bytes: 562252162029210
     rx_broadcast: 132861752
     tx_broadcast: 4885056
     rx_multicast: 12639724
     tx_multicast: 14603368
     rx_errors: 4
     tx_errors: 0
     tx_dropped: 0
     multicast: 12639724
     collisions: 0
     rx_length_errors: 178
     rx_over_errors: 0
     rx_crc_errors: 4
     rx_frame_errors: 0
!!     rx_no_buffer_count: 1265916200
!!     rx_missed_errors: 454590997
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
!!     tx_restart_queue: 6620253
     rx_long_length_errors: 178
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 0
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 0
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0
     rx_long_byte_count: 562829984869843
     rx_csum_offload_good: 814763097746
     rx_csum_offload_errors: 659897395
     rx_header_split: 0
     alloc_rx_buff_failed: 0
     tx_smbus: 0
     rx_smbus: 0
     dropped_smbus: 0

 

немного смущают выделенные значения.

 

Собственно, какие крутилки стоит покрутить, и сильно ли это поможет?

Edited September 4, 2008 by inxs

[nuclearcat]

rx_no_buffer_count :

 

ethtool -g eth0

и начинаем плавненько увеличивать

ethtool -G eth0 rx NNNN

УЧТИТЕ - карта отвалится ненадолго (пока рестартанет negotiation), так что аккуратнее. В транке на сиське при передергивании порта STP долго тоже чухается...

 

Шейперы, iptables, nat на роутере есть?

Прерывания сетевух привязаны жестко к процессорам? (smp_affinity)

Если можно закиньте куда-нить .config ядра посмотреть.

[inxs]

Шейперов нет, nat есть, iptables есть, smp_affinity не трогали.

 

config.txt

[nuclearcat]

CONFIG_IRQBALANCE=y - плохо

После того как поправите - прерывания лучше раскидать по физическим процессорам.

 

в dmesg пусто?

CONFIG_PREEMPT_BKL лучше в n (некритично)

CONFIG_SECCOMP в n (немного кушает ресурсов)

Включить MSI прерывания

CONFIG_NF_CT_ACCT если не нужно - отключить (некритично)

Если много роутов - попробуйте CONFIG_IP_FIB_TRIE

 

 

К вечеру и в нормальное время сделайте

sysctl -a|grep conntr

Покажете их... если флудят - обычно резко растет net.netfilter.nf_conntrack_count = 202170

 

[inxs]

Да, в dmesg есть крики про conntrack

 

nf_conntrack: table full, dropping packet

 

Сейчас вот что:

 

net.ipv4.netfilter.ip_conntrack_generic_timeout = 600
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10
net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans = 300
net.ipv4.netfilter.ip_conntrack_tcp_loose = 1
net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 0
net.ipv4.netfilter.ip_conntrack_tcp_max_retrans = 3
net.ipv4.netfilter.ip_conntrack_udp_timeout = 30
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 180
net.ipv4.netfilter.ip_conntrack_icmp_timeout = 30
net.ipv4.netfilter.ip_conntrack_max = 1548576
net.ipv4.netfilter.ip_conntrack_count = 1533818
net.ipv4.netfilter.ip_conntrack_buckets = 16384
net.ipv4.netfilter.ip_conntrack_checksum = 1
net.ipv4.netfilter.ip_conntrack_log_invalid = 0
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_max = 1548576
net.netfilter.nf_conntrack_count = 1533819
net.netfilter.nf_conntrack_buckets = 16384
net.netfilter.nf_conntrack_checksum = 1
net.netfilter.nf_conntrack_log_invalid = 0
net.netfilter.nf_conntrack_expect_max = 256
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_loose = 1
net.netfilter.nf_conntrack_tcp_be_liberal = 0
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
net.nf_conntrack_max = 1548576

[nuclearcat]

Поставьте утилитку conntrack.

Затем conntrack -L >file

Доеду до работы - напишу скриптик который отсортирует dst / src пары - если кто-то занимает слишком много значений. Или сами попробуйте наваять.

 

Пока временно можно , если есть свободная память, задрать значение net.netfilter.nf_conntrack_max чуть повыше, но аккуратно. Скажем на 100000 (вообще желательно чтоб это значение было кратно 2^n, т.е. скажем net.netfilter.nf_conntrack_max=2097152). И посмотреть насколько быстро оно растет.

[inxs]

# conntrack -L

Operation failed: sorry, you must be root or get CAP_NET_ADMIN capability to do this

 

Гугля говорит что-то невнятное по этому поводу.

 

А скриптик-то я и сам написать смогу..

[nuclearcat]

Собрано из сырцов на текущее ядро и текущие iptables (которые в системе) ?

[inxs]

ээ.. нет %)

anyway, оно в отрытом виде в проке (/toc/net/ip_conntrack) лежит, счас поковыряю..

[nuclearcat]

если смотреть через /proc рискуете положить ваш border

[inxs]

Даже если интеллигентно cat'нуть с минимальным nice'ом?

 

Среди первых же записей есть какие-то чудеса

tcp      6 380800 ESTABLISHED src=88.223.20.163 dst=170.128.169.15 sport=443 dport=19741 packets=1 bytes=40 [UNREPLIED] src=170.128.169.15 dst=88.223.20.163
sport=19741 dport=443 packets=0 bytes=0 mark=0 use=1
tcp      6 380761 ESTABLISHED src=166.27.93.156 dst=170.128.169.15 sport=443 dport=41683 packets=1 bytes=40 [UNREPLIED] src=170.128.169.15 dst=166.27.93.156
sport=41683 dport=443 packets=0 bytes=0 mark=0 use=1
tcp      6 380676 ESTABLISHED src=14.25.173.228 dst=170.128.169.15 sport=443 dport=46639 packets=1 bytes=40 [UNREPLIED] src=170.128.169.15 dst=14.25.173.228
sport=46639 dport=443 packets=0 bytes=0 mark=0 use=1
tcp      6 380609 ESTABLISHED src=158.3.123.95 dst=170.128.169.15 sport=443 dport=11530 packets=1 bytes=40 [UNREPLIED] src=170.128.169.15 dst=158.3.123.95 sp
ort=11530 dport=443 packets=0 bytes=0 mark=0 use=1
tcp      6 380267 ESTABLISHED src=196.154.124.72 dst=170.128.169.32 sport=80 dport=27217 packets=1 bytes=40 [UNREPLIED] src=170.128.169.32 dst=196.154.124.72
sport=27217 dport=80 packets=0 bytes=0 mark=0 use=1
tcp      6 380205 ESTABLISHED src=156.203.19.22 dst=170.128.169.32 sport=80 dport=52696 packets=1 bytes=40 [UNREPLIED] src=170.128.169.32 dst=156.203.19.22 s
port=52696 dport=80 packets=0 bytes=0 mark=0 use=1

Это не мои адреса..

Edited September 4, 2008 by inxs

[nuclearcat]

Даже если... там коряво сделан код для вывода в proc. Я ругался по этому поводу уже в kernel maillist, исправлять не хотят.

 

Поставьте фильтры от спуфинга в iptables. Для начала хотя бы с LOG

Похоже из вашей сети кто-то делает SYN flood с проспуфленными src адресами на 170.128.169.x.

Ловите засранца...

 

[inxs]

Спасибо, будем искать.

[inxs]

Опять фигня началась.. :(

 

net.ipv4.netfilter.ip_conntrack_generic_timeout = 600
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10
net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans = 300
net.ipv4.netfilter.ip_conntrack_tcp_loose = 1
net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 0
net.ipv4.netfilter.ip_conntrack_tcp_max_retrans = 3
net.ipv4.netfilter.ip_conntrack_udp_timeout = 30
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 180
net.ipv4.netfilter.ip_conntrack_icmp_timeout = 30
net.ipv4.netfilter.ip_conntrack_max = 1548576
net.ipv4.netfilter.ip_conntrack_count = 1529804
net.ipv4.netfilter.ip_conntrack_buckets = 16384
net.ipv4.netfilter.ip_conntrack_checksum = 1
net.ipv4.netfilter.ip_conntrack_log_invalid = 0
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_max = 1548576
net.netfilter.nf_conntrack_count = 1529805
net.netfilter.nf_conntrack_buckets = 16384
net.netfilter.nf_conntrack_checksum = 1
net.netfilter.nf_conntrack_log_invalid = 0
net.netfilter.nf_conntrack_expect_max = 256
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_loose = 1
net.netfilter.nf_conntrack_tcp_be_liberal = 0
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
net.nf_conntrack_max = 1548576

 

 

rp_filter на доступе, кстати, не помог. Видимо, придётся ещё костылей навешивать.

[nuclearcat]

В iptables повесить правила на те ip которые не ваши и отследить откуда идет.

Если не очень много адресов, то лучше их описать, а все что не должно приходить - в -j LOG и теребить источник.

[inxs]

А стоит ли трогать вот это:

 

net.ipv4.tcp_mem = 390144 520192 780288

net.ipv4.tcp_wmem = 4096 16384 4194304

net.ipv4.tcp_rmem = 4096 87380 4194304

 

?

[nuclearcat]

Нет, абсолютно не поможет, если conntrack dropping packet.

Временно ситуацию можно решить заблокировав ip который боты атакуют, и добавив еще атакуемые ip в raw таблицу

т.е. например по инфе приведенной выше

 

типа такого

iptables -t raw -I PREROUTING -d 170.128.169.0/24 -j NOTRACK

 

Тогда эта фигня не будет попадать в conntrack и переполнять его.

 

[inxs]

Поблокировали на доступе гадость, но в таблице conntrack по прежнему полно левых записей. Видимо, придётся ждать пока они стаймаутятся..

[nuclearcat]

conntrack -F сбросит все записи

или можно -D -s ip напимер удалить все записи по определенному ip-шнику

советую все-таки заставить работать эту утилиту

[martin74]

а кстати, чем чревато использование NOTRACK ?

я так у себя на выходящем роутере маскарадный диапазон и диапазон раздаваемых реалок сделал - NOTRACK.

До поры до времени помогало от conntrack dropping packet.. Пару дней назад опять началось. Задрал по примеру из поста - посмотрим, что будет...

[nuclearcat]

Ничем, только что если в правилах ошибешься и попадет в NOTRACK пакет предназначенный нату - просто дропнется.

Ну и правил нежелательно много толкать.

Еще кстати если траффика много и юзаете шейперы и прочие потребители таймеров - КРАЙНЕ желательно наличие TSC как таймера.

Проверять тут

/sys/devices/system/clocksource/clocksource0/current_clocksource

 

[inxs]

советую все-таки заставить работать эту утилиту

Подожду, пожалуй, до понедельника. Делать что-то с критичными сервисами в пятницу - плохая примета.. ;)

[inxs]

Conntrack почистили, но ерунда с загрузкой процессора продолжается.

 

Можно ли сделать что-нибудь ещё без пересборки ядра и перезагрузки?

[nuclearcat]

вы нашли того кто флудит?

если он флудит проспуфленными ip - в этом хорошего мало

более детально искать нужно через oprofile, что именно жрет процессор...

[inxs]

Флудило несколько человек (и, видимо, продолжают это делать), но на аксессе понавешено костылей и спуфленные пакеты до бордера не долетают.

 

А, собственно, бордер не загнётся от подсовывания ему профайлера под нагрузкой?