[photon]

Ошибку в readme исправил, версию менять не буду, т.к. изменение не принципиальное. Надо бы bugtracker настроить под сообщения об ошибках. Раньше на Sourceforge они автоматом создавались.

[zevgen]

Можно добавить поддержку ceil и prio? Цены бы вам не было.

[SokolovS]

Про приоритет я уже писал ранее, было бы неплохо на самом деле. А еще бы неплохо сделать общий коэффициент повышения/понижения скорости. Удобно нарпимер под Новый год, ставишь множитель 1.5 и все ))

[photon]

Можно добавить поддержку ceil и prio? Цены бы вам не было.

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

Изменено 10 октября, 2010 пользователем photon

[photon]

Сделал поддержку коэффициента между скоростями в правилах и базе. В README написано, как его периодически менять с помощью заданий cron.

Изменено 17 октября, 2010 пользователем photon

[red_neon]

Проблема. Сервер работает ИДЕАЛЬНО 8-48 часов, а потом зависает, в логах - ничего. Пробовали так 5 раз, всё повторяется. Также переустанавливали линукс, тестировали память, ставили последнюю версию iproute2 (2.6.35) всё равно виснет.

ОСь - Дебиан 5(lenny) - 64битный, со всеми последними обновлениями.

Сервер: Intel Core 2 Quad 2.5 \ 8Gb RAM

Сетёвки: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)

sc v1.2

метод u32, shaping

dblist 4к

ip_conntrack_count в пиках ~ 405к

 

---------------------------------------------------------------------------------------------------------------

 

rc.local:

 

/usr/sbin/ethtool -K eth0 tso off tx off sg off

/usr/sbin/ethtool -K eth1 tso off tx off sg off

 

/usr/sbin/ethtool -G eth0 rx 4096 tx 4096

/usr/sbin/ethtool -G eth1 rx 4096 tx 4096

 

sleep 3

 

/sbin/ifconfig eth0 txqueuelen 10000

/sbin/ifconfig eth1 txqueuelen 10000

/bin/echo "400000" > /proc/sys/net/core/netdev_max_backlog

/bin/echo "1000448" > /proc/sys/net/ipv4/netfilter/ip_conntrack_max

/bin/echo "1000448" > /sys/module/nf_conntrack/parameters/hashsize

/bin/echo "0" > /proc/sys/net/ipv4/tcp_sack

/bin/echo "1" > /proc/sys/net/ipv4/tcp_window_scaling

/bin/echo "1" > /proc/sys/net/ipv4/tcp_timestamps

 

/bin/echo "33554432" > /proc/sys/net/core/rmem_max

/bin/echo "33554432" > /proc/sys/net/core/wmem_max

/bin/echo "8388608" > /proc/sys/net/core/rmem_default

/bin/echo "4194394" > /proc/sys/net/core/wmem_default

/bin/echo "4096 8388608 16777216" > /proc/sys/net/ipv4/tcp_rmem

/bin/echo "4096 4194394 16777216" > /proc/sys/net/ipv4/tcp_wmem

 

/bin/echo "10000" > /proc/sys/net/unix/max_dgram_qlen

/bin/echo "1" > /proc/sys/net/ipv4/tcp_syncookies

/bin/echo "400000" > /proc/sys/net/ipv4/tcp_max_syn_backlog

/bin/echo "400000" > /proc/sys/net/core/somaxconn

 

/bin/echo "10" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent

/bin/echo "10" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_recv

/bin/echo 14400 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established

/bin/echo "15" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait

/bin/echo "30" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait

/bin/echo "180" > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout

/bin/echo "30" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait

/bin/echo "15" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack

/bin/echo "10" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close

 

/bin/echo "10" > /proc/sys/net/ipv4/tcp_fin_timeout

/bin/echo "1440000" > /proc/sys/net/ipv4/tcp_max_tw_buckets

/bin/echo "1" > /proc/sys/net/ipv4/tcp_tw_recycle

/bin/echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse

/bin/echo "15" > /proc/sys/net/ipv4/tcp_keepalive_intvl

/bin/echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes

/bin/echo "1800" > /proc/sys/net/ipv4/tcp_keepalive_time

/bin/echo "2" > /proc/sys/net/ipv4/tcp_synack_retries

/bin/echo "1" > /proc/sys/net/ipv4/tcp_syn_retries

/bin/echo 1 > /proc/sys/net/ipv4/tcp_orphan_retries

/bin/echo "16384 61000" > /proc/sys/net/ipv4/ip_local_port_range

/bin/echo "1" > /proc/sys/net/ipv4/tcp_no_metrics_save

 

 

 

 

Продолжение:

[photon]

Проблема. Сервер работает ИДЕАЛЬНО 8-48 часов, а потом зависает, в логах - ничего. Пробовали так 5 раз, всё повторяется. Также переустанавливали линукс, тестировали память, ставили последнюю версию iproute2 (2.6.35) всё равно виснет.

ОСь - Дебиан 5(lenny) - 64битный, со всеми последними обновлениями.

Предполагаю, что виснет ядро (больше нечему, если железо в порядке). Проблема скорее всего в драйвере для сетевухи, т.к. Кузнецову и Хэммингеру я больше доверяю, чем интеловским индусам. А какая версия ядра? 2.6.26-2-amd64? Может тогда стоит скачать последнюю ваниллу с kernel.org, собрать пакет с помощью make-kpkg и установить? Если сбои повторятся, то будет о чем говорить с разработчиками ядра, т.к. они обычно отшивают сообщения об ошибках в старых версиях. Кроме того, настраивать TCP, сокеты, netfilter и conntrack не нужно (если машина выполняет только функцию шейпера). Iptables при использовании u32 лучше вообще не загружать от греха подальше, чтобы он не создавал лишних блокировок. Еще один момент:

/usr/sbin/ethtool -G eth0 rx 4096 tx 4096

/usr/sbin/ethtool -G eth1 rx 4096 tx 4096

 

не уверен, что во всех интеловских сетевухах rx/tx rings могут быть такими большими, попробуйте начать с 1024.

Изменено 19 октября, 2010 пользователем photon

[wtyd]

Вопрос немного не в тему, но он связан с HTB и фильтром:

 

Есть ли способ классифицировать не-ip трафик ? В частности ARP.

 

проблема в том, что неклассифицированный трафик сливается в умолчальный класс, ширину которого следует сделать близкой к нулю, потому что если нет класса для ip-адреса, то значит либо доступа не должно быть, либо ошибка в конфигурации - трафик нужно дропать. ARP попадает в умолчальный класс и сеть перестаёт работать либо периодически перестаёт.

 

Если можно, то хотелось бы пример.

 

P.S. подобный вопрос я где-то уже встречал, наверное даже на этом форуме, но приемлемого решения предложено не было.

[photon]

Вопрос немного не в тему, но он связан с HTB и фильтром:

проблема в том, что неклассифицированный трафик сливается в умолчальный класс, ширину которого следует сделать близкой к нулю, потому что если нет класса для ip-адреса, то значит либо доступа не должно быть, либо ошибка в конфигурации - трафик нужно дропать. ARP попадает в умолчальный класс и сеть перестаёт работать либо периодически перестаёт.

Если использовать фильтры u32, то это можно сделать без уменьшения полосы для default class. Я ставлю в конец правил фильтр для IP-трафика c policy drop.

tc fitler add dev $dev parent 1:0 protocol ip pref 20 u32 match u32 0x0 0x0 at 0 police mtu 1 action drop

Таким образом, неклассифицированный IP-трафик не проходит, а все остальное (ARP в том числе) попадает в класс по умолчанию. Другое решение -- разрешать IP-трафик по спискам с помощью iptables и ipset. Кроме того, никто не мешает создать отдельный класс для ARP и написать tc filter add dev eth0 parent 1:0 protocol arp ...

Изменено 20 октября, 2010 пользователем photon

[wtyd]

Да, в самом деле. Написал фильтр для протокола arp - работает. Раньше я делал то же самое, но проверял утилитой arping (не из состава iproute) с машины, на которой был htb, и у меня арп попадал в класс по умолчанию, судя по счётчикам. Но сегодня я вдруг вспомнил, что этот arping использует raw socket :-).

 

Повторил эксперимент с той лишь разницей, что слал arp с другой машины в тачку с шейпером. Судя по счётчикам, арп стал попадать в класс для арп пакетов.

 

Для потомков:

 

tc qdisc add dev eth1 root handle 1 htb default 30

...

# class for arp

tc class add dev eth1 parent 1: classid 1:50 htb rate 120000

tc filter add dev eth1 protocol arp prio 10 u32 match u32 0 0 flowid 1:50

...

 

# tc -s class sh dev eth1 | grep "1:50" -A5

class htb 1:50 root prio 0 rate 120000bit ceil 120000bit burst 1599b cburst 1599b

Sent 6762 bytes 161 pkt (dropped 0, overlimits 0 requeues 0)

rate 336bit 1pps backlog 0b 0p requeues 0

lended: 161 borrowed: 0 giants: 0

tokens: 1616656 ctokens: 1616656

 

Спасибо за наводку :-).

[SokolovS]

2wtyd: а для каких целей вы выделяете ARP в отдельный класс? У вас что юзеры с шейпером в одном broadcast сегменте?

[SokolovS]

Кстати такой вопрос, по приоритету у фильтров. Как эффективней приоритеты расставлять по количеству трафика в pps или по важности трафика.

Т.е. например основной трафик генерируют юзеры и есть важный трафик, скажем DNS. Как эффективней проставить prio/pref для этих фильтров?

 

Вроде по логике нужно по кол-ву трафика ставить prio, т.к. основнй трафик будет проходить только по хэш фильтру, а все остальные фильтры типа ARP, DNS и прочего уже будут после него. Как у вас?

 

Я к тому что есть ли смысл для правил у которых статистика (rule hit 52517063 success 19963), ставить значение prio побольше, чтобы по ним в последнюю очередь проверка шла?

Изменено 22 октября, 2010 пользователем SokolovS

[photon]

Кстати такой вопрос, по приоритету у фильтров. Как эффективней приоритеты расставлять по количеству трафика в pps или по важности трафика.

Т.е. например основной трафик генерируют юзеры и есть важный трафик, скажем DNS. Как эффективней проставить prio/pref для этих фильтров?

 

Вроде по логике нужно по кол-ву трафика ставить prio, т.к. основнй трафик будет проходить только по хэш фильтру, а все остальные фильтры типа ARP, DNS и прочего уже будут после него. Как у вас?

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

Изменено 22 октября, 2010 пользователем photon

[SokolovS]

Т.е. если идет 10 фильтров, без хэшей, то лучше приоритет фильтра выставлять в зависимости от объема трафика, так?

[photon]

Т.е. если идет 10 фильтров, без хэшей, то лучше приоритет фильтра выставлять в зависимости от объема трафика, так?

Да. Можно даже просто создать их в нужном порядке, не изменяя значение pref. Упорядочивая фильтры по частоте их срабатывания (часто используемые -- в начале, редко используемые -- в конце), мы снижаем среднее значение количества правил, которые проходит пакет. Это очевидно из теории вероятностей.

Изменено 23 октября, 2010 пользователем photon

[red_neon]

Предполагаю, что виснет ядро (больше нечему, если железо в порядке). Проблема скорее всего в драйвере для сетевухи, т.к. Кузнецову и Хэммингеру я больше доверяю, чем интеловским индусам. А какая версия ядра? 2.6.26-2-amd64? Может тогда стоит скачать последнюю ваниллу с kernel.org, собрать пакет с помощью make-kpkg и установить? Если сбои повторятся, то будет о чем говорить с разработчиками ядра, т.к. они обычно отшивают сообщения об ошибках в старых версиях. Кроме того, настраивать TCP, сокеты, netfilter и conntrack не нужно (если машина выполняет только функцию шейпера). Iptables при использовании u32 лучше вообще не загружать от греха подальше, чтобы он не создавал лишних блокировок. Еще один момент:

/usr/sbin/ethtool -G eth0 rx 4096 tx 4096

/usr/sbin/ethtool -G eth1 rx 4096 tx 4096

 

не уверен, что во всех интеловских сетевухах rx/tx rings могут быть такими большими, попробуйте начать с 1024.

Установили дистрибутив Дебиана "Squeeze" (тестируемый):

 

# uname -a

Linux sc 2.6.32-5-amd64 #1 SMP Fri Oct 15 00:56:30 UTC 2010 x86_64 GNU/Linux

 

# ethtool -i eth0

driver: e1000e

version: 1.0.2-k2

firmware-version: 5.11-2

bus-info: 0000:01:00.1

 

# ip -V

ip utility, iproute2-ss100519

 

работает 5 дней при тех же нагрузках, не ругается. Видимо проблема была в драйвере сетевой, т.к. в состоянии простоя (без трафика) сервер не подвисал на Debian "Lenny". Там версия драйвера e1000e: 0.3.3.3-k2

 

Ринги по 4096, в данном случае могут быть:

 

# ethtool -g eth0

Ring parameters for eth0:

Pre-set maximums:

RX: 4096

RX Mini: 0

RX Jumbo: 0

TX: 4096

Current hardware settings:

RX: 4096

RX Mini: 0

RX Jumbo: 0

TX: 4096

 

 

Из этого нужно ли что-то включить или выключить?:

# ethtool -k eth0

Offload parameters for eth0:

rx-checksumming: on

tx-checksumming: off

scatter-gather: off

tcp-segmentation-offload: off

udp-fragmentation-offload: off

generic-segmentation-offload: on

generic-receive-offload: off

large-receive-offload: off

ntuple-filters: off

receive-hashing: off

 

 

[photon]

Установили дистрибутив Дебиана "Squeeze" (тестируемый):

# uname -a

Linux sc 2.6.32-5-amd64 #1 SMP Fri Oct 15 00:56:30 UTC 2010 x86_64 GNU/Linux

 

работает 5 дней при тех же нагрузках, не ругается. Видимо проблема была в драйвере сетевой, т.к. в состоянии простоя (без трафика) сервер не подвисал на Debian "Lenny". Там версия драйвера e1000e: 0.3.3.3-k2

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

 

Из этого нужно ли что-то включить или выключить?:

# ethtool -k eth0

Offload parameters for eth0:

rx-checksumming: on

tx-checksumming: off

scatter-gather: off

tcp-segmentation-offload: off

udp-fragmentation-offload: off

generic-segmentation-offload: on

generic-receive-offload: off

large-receive-offload: off

ntuple-filters: off

receive-hashing: off

Если все работает, то лучше оставить offload как есть, т.к. настройки, отключенные по умолчанию, как правило не оттестированы и только подрывают стабильность.

[SokolovS]

Оффлоад так то не нужен для роутеров и шейперов. Им обрабатываются только пакеты идущие от самого сервера, например с 80 порта.

[photon]

Оффлоад так то не нужен для роутеров и шейперов. Им обрабатываются только пакеты идущие от самого сервера, например с 80 порта.

Максимум что на шейпере надо оффлоадить -- это rx и tx checksumming, т.к. MAC-адреса все же меняются. А всякие segmentation и fragmentation не нужны, конечно.

Изменено 26 октября, 2010 пользователем photon

[shicoy]

Что делать если аплинков и даунлинков несколько?

[photon]

Это мост или маршрутизатор? Если мост, то делать interface bonding и сводить задачу к двум интерфейсам. Если маршрутизатор, то надо видимо переписать часть кода, чтобы параметры o_if и i_if были массивами строк, и правила создавались на нескольких интерфейсах.

Изменено 28 октября, 2010 пользователем photon

[shicoy]

увы маршрутизатор, пока проблему решил двумя копиями скриптов под каждый интерфейс, но как мы понимаем это совсем не правильно.

[photon]

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

foreach my $oif (@o_if) { ... }

foreach my $iif (@i_if) { ... }

и заменить в правилах $o_if на $oif, $i_if на $iif.

 

Я сейчас весьма занят, поэтому некогда этим заниматься, да и незачем.

Изменено 28 октября, 2010 пользователем photon

[shicoy]

ну это же будет просто распаралеливание правил на два интерфейса?

т.е. скажем если есть

ifout1 и ifout2, и на IP повесили скорость 2Мбит.

И так получилось что трафик от этого IP удачно балансируется между ifout1 и ifout2 соотвественно IP сможет разогнаться до 4Мбит или все таки ограничиться на уровне 2Мбит?

 

[photon]

ну это же будет просто распаралеливание правил на два интерфейса?

т.е. скажем если есть

ifout1 и ifout2, и на IP повесили скорость 2Мбит.

И так получилось что трафик от этого IP удачно балансируется между ifout1 и ifout2 соотвественно IP сможет разогнаться до 4Мбит или все таки ограничиться на уровне 2Мбит?

Я не совсем понял задачу. Балансирование можно сделать и на канальном уровне с помощью LACP.

Изменено 28 октября, 2010 пользователем photon