Есть шлюз с Linux ядром 2.6.10 и iptables v1.2.11
На котором пару сотен вланов (N штук) для каждого из которых задано правило
iptables -t nat -A POSTROUTING -s 192.168.N.0/24 -o vlanN -j SNAT --to-source 82.34.x.N

Когда сотни внутренних сетей транслируются в сотни реальных IP load average доходит до 20, все тормозит хуже некуда. По top от процессов загрузки нет, не успевает обрабатывать на уровне ядра.

В какую сторону копать, нет ли под Linux NAT масок, чтобы не перечислять правила отдельно, а сразу сопоставить
192.168.N.0/24 > 82.34.x.N

• Скорость работы большого числа SNAT правил в iptables,Koba_LTD, 11:55 , 19-Окт-05
  • Скорость работы большого числа SNAT правил в iptables,Koba_LTD, 11:56 , 19-Окт-05
    • Скорость работы большого числа SNAT правил в iptables,den, 11:59 , 19-Окт-05
      • Скорость работы большого числа SNAT правил в iptables,den, 12:15 , 19-Окт-05
        • Скорость работы большого числа SNAT правил в iptables,Антон, 17:40 , 19-Окт-05
• Проблема найдена !,Антон, 10:52 , 24-Окт-05

>Есть шлюз с Linux ядром 2.6.10 и iptables v1.2.11
>На котором пару сотен вланов (N штук) для каждого из которых задано
>правило
>iptables -t nat -A POSTROUTING -s 192.168.N.0/24 -o vlanN -j SNAT --to-source
>82.34.x.N
>
>Когда сотни внутренних сетей транслируются в сотни реальных IP load average доходит
>до 20, все тормозит хуже некуда. По top от процессов загрузки
>нет, не успевает обрабатывать на уровне ядра.
>
>В какую сторону копать, нет ли под Linux NAT масок, чтобы не
>перечислять правила отдельно, а сразу сопоставить
>192.168.N.0/24 > 82.34.x.N

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

>>Есть шлюз с Linux ядром 2.6.10 и iptables v1.2.11
>>На котором пару сотен вланов (N штук) для каждого из которых задано
>>правило
>>iptables -t nat -A POSTROUTING -s 192.168.N.0/24 -o vlanN -j SNAT --to-source
>>82.34.x.N
>>
>>Когда сотни внутренних сетей транслируются в сотни реальных IP load average доходит
>>до 20, все тормозит хуже некуда. По top от процессов загрузки
>>нет, не успевает обрабатывать на уровне ядра.
>>
>>В какую сторону копать, нет ли под Linux NAT масок, чтобы не
>>перечислять правила отдельно, а сразу сопоставить
>>192.168.N.0/24 > 82.34.x.N
>
>нет таких правил нет
>тормозит - а что за машина и что на ней еще висит.
>
>ты уверен что тормозит ядро(если да то собери с мултикастом)
>пересмотри структуру сети (если у тебя столько подсетей то это либо очень
>много машит - тогда выход цизка, а если машин мало то
>я считаю неправельно спланированна структура.)

и еще зачем тебе "пару сотен" вланов.

первый раз слышу чтобы от пару сотен правил тормозило ядро (если бы пару десятков тысяч...)

может тормозит не SNAT, а совместная работа такого количества виланов?

Какая у вас сетевая карта ? Может проблема в драйвере ?

>может тормозит не SNAT, а совместная работа такого количества виланов?

Пинаю SNAT, потому-что load average вырос до небес, после того как вместо одного SNAT правила на всех, вписали отдельные правила выделив каждому клиенту по реальному IP. До этого LA был в пределах 0.1, пользовательских прграмм нам нет, только vlan и NAT

>Какая у вас сетевая карта ? Может проблема в драйвере ?

Дело не во vlan и карте, до SNAT все было OK.

$mpstat
CPU   %user   %nice %system %iowait    %irq   %soft   %idle    intr/s
all   19.17    0.01    3.46    0.08    0.00    8.27   69.01    422.53

$iostat
avg-cpu:  %user   %nice    %sys %iowait   %idle
          19.17    0.01   11.73    0.08   69.01

$cat /proc/loadavg
11.57 10.36 9.70 3/283 18065

Бага была в ядре !!!

В конце концов рутер встал с завалом логов "kernel: dst cache overflow".
Ребутнули - LA опять около нуля.
Полез читать рассылки и нашел, что была бага, которую пофиксили в 2.6.11 ядре.