Блокировка нежелательного DNS трафика

Это ресолвер для клиентов домашнего интернет, т е конечных потребителей. Они все приходят к DNS со своими ip адресами. Если Вам кажется, что будут жалобы из-за слишком жестких лимитов — поправьте их в соответствии с Вашими желаниями :)

Блокировка нежелательного DNS трафика

Вы можете ограничить в unbound количество запросов от каждого клиента? Насколько я знаю — нет.

Вы просто отсрочили ту же самую проблему, когда один клиент со скоростью в 100Мбит/s начинает тупо валить ваш DNS вполне валидными DNS запросами.

Блокировка нежелательного DNS трафика

Как мы все прекрасно понимаем, дело не в пользователях а в их запросах, и в отсутствии штатных средств ограничивать аппетиты конечного пользователя.

Дело в том, что например в том же bind есть только одна опция которая может быть полезна — ограничение общего количества рекурсивных запросов, но что произойдет с bind-ом когда все эти запросы сделает один клиент? Правильно. Он просто перестанет обрабатывать валидные запросы других клиентов.

На самом деле это огромная проблема.

Видео с HighLoad++: Петр Зайцев — Диагностика и исправление проблем производительности MySQL

Проклинаю mail.ru за такое качество видео.

Блокировка нежелательного DNS трафика

40k пользователей, сейчас стоит штатный bind

rndc status

recursive clients: 268/14900/15000


Блокировка нежелательного DNS трафика

Спасибо. Поправил.

Linux под нагрузкой. Высокопроизводительный шейпер

Есть кстати отличный проект sc sourceforge.net/projects/sc-tool/ работает на базе HTB, работает с БД, ночные увеличения скоростей, и пр. пр. пр.

Linux под нагрузкой. Высокопроизводительный шейпер

на Linux портирован ipfw+dummynet в котором как вы все наверное знаете шейп делается на раз, два, три. Причем правила вполне себе читаемые.

Согласитесь куда уж проще организовать масс шейп

ipfw pipe 1 config bw 200Kbit/s mask dst-ip 0x000fffff
ipfw pipe 2 config bw 200Kbit/s mask src-ip 0x000fffff

ipfw add 11 pipe 1 ip from any to 172.16.0.0/12 out
ipfw add 12 pipe 2 ip from 172.16.0.0/12 to any in

ну либо использовать таблицы для различных тарифных планов.

Верхом на… сетевом пакете

Допустим Ваш провайдер имеет два подключение к своим апстримам и анонсит им свои сети, Ваш пакет улетает через один канал а ответ возвращается совсем по другому маршруту.

Утрированно: пакет улетел через Гваделупу а вернулся через Амстердам.

Верхом на… сетевом пакете

tracert меряет среднюю температуру по больнице и ориентироваться на его данные в корне не верно.

Анонсирован выпуск Nginx 0.9

У Вас феноминальные способности к дедукции.

Анонсирован выпуск Nginx 0.9

Простите великодушно, уже посыпал себе голову пеплом.

Анонсирован выпуск Nginx 0.9

Спасибо за конструктивную критику. Картинку поправил, надуюсь, что так стало лучше.

Анонсирован выпуск Nginx 0.9

Спасибо.

Большие потоки трафика и Linux: прерывания, маршрутизатор и NAT-сервер

1. почему неправда? Аргументы?

Поставьте равным и сами увидите что нагрузка на CPU уменьшится :)

2. Разве я где-то сказал что 1500 бегать не будут? Будут, конечно. Но если включить jumbo frame, то бегать будет значительно лучше

в 2 раза быстрее? :)

Кстати что там насчет ethtool -k ethX и ethtool -g ethX на ваших интерфейсах?
Что за сетевые посоветуете приобретать под NAT?
Какое ядро использовать?

Большие потоки трафика и Linux: прерывания, маршрутизатор и NAT-сервер

1. hashsize = nf_conntrack_max / 8 не правда, на больших объемах трафика hashsize должен быть максимально приближен к nf_conntrack_max это снижает нагрузку на ЦПУ NAT сервера

2. Крутить MTU на интерфейсах ни имеет никакого смысла. Трафик у Вас транзитный и пакуеты будут бегать с MTU 1500 так что ваши 9000 никуда.

Большие потоки трафика и управление прерываниями в Linux

есть твики centos.alt.ru/?p=32, только лучше ipset.

Большие потоки трафика и управление прерываниями в Linux

Кстати про тюнинг параметров драйверов Вы тоже ни слова не написали, а тема очень обширна :)

Большие потоки трафика и управление прерываниями в Linux

irqbalance при большой нагрузке и большом кол-ве очередей сносит мозг :)

Большие потоки трафика и управление прерываниями в Linux

вообще прерывания неплохо автоматом раскидываются таким скриптиком

ncpus=`grep -ciw ^processor /proc/cpuinfo`
test "$ncpus" -gt 1 || exit 1

n=0
for irq in `cat /proc/interrupts | grep eth | awk '{print $1}' | sed s/\://g`
do
    f="/proc/irq/$irq/smp_affinity"
    test -r "$f" || continue
    cpu=$[$ncpus - ($n % $ncpus) - 1]
    if [ $cpu -ge 0 ]
            then
                mask=`printf %x $[2 ** $cpu]`
                echo "Assign SMP affinity: eth$n, irq $irq, cpu $cpu, mask 0x$mask"
                echo "$mask" > "$f"
                let n+=1
    fi
done