Перейти к содержимому
Калькуляторы

Linux NAT оптимизация для 10G+ трафика

Ответить

roysbike   

roysbike
Опубликовано (изменено) · Жалоба

Коллеги, посоветуйте как лучше натить и выгодно по ресурсам? Сразу подсетью ? NAT организован вот так. На каждую сеть /24 один реальный IP. Есть 126 реальных IP.

Может можно что то вроде

IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.0.0/24 -j SNAT --to-source 93.157.x.0/25 ?

 

Сейчас сделано так 

$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.0.0/24 -j SNAT --to-source 93.157.x.1
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.1.0/24 -j SNAT --to-source 93.157.x.1
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.2.0/24 -j SNAT --to-source 93.157.x.2
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.3.0/24 -j SNAT --to-source 93.157.x.3
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.4.0/24 -j SNAT --to-source 93.157.x.4
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.5.0/24 -j SNAT --to-source 93.157.x.5
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.6.0/24 -j SNAT --to-source 93.157.x.6
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.7.0/24 -j SNAT --to-source 93.157.x.7
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.8.0/24 -j SNAT --to-source 93.157.x.8
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.9.0/24 -j SNAT --to-source 93.157.x.9
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.10.0/24 -j SNAT --to-source 93.157.x.10
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.11.0/24 -j SNAT --to-source 93.157.x.11
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.12.0/24 -j SNAT --to-source 93.157.x.12
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.13.0/24 -j SNAT --to-source 93.157.x.13
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.14.0/24 -j SNAT --to-source 93.157.x.14
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.15.0/24 -j SNAT --to-source 93.157.x.15

 

и тд

Изменено пользователем roysbike

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Tamahome   

Tamahome
Опубликовано · Жалоба

Кто подскажет причины роста rx_csum_offload_errors ? Чего может не хватать, куда смотреть?

Деградации не видно, однако бывает по паре штук в секунду растут.

 

    multicast: 19741
    rx_pkts_nic: 90633937823
    tx_pkts_nic: 70185725425
    rx_bytes_nic: 99410833120479
    tx_bytes_nic: 30748496165710
    lsc_int: 3
    rx_csum_offload_errors: 261187
    fdir_match: 53145314472
    fdir_miss: 39088236258
    fdir_overflow: 45221
    tx_queue_0_packets: 17479756826
    tx_queue_0_bytes: 7635433763886
    tx_queue_1_packets: 17534520598
    tx_queue_1_bytes: 7622669983696
    tx_queue_2_packets: 17480844454
    tx_queue_2_bytes: 7492357099791
    tx_queue_3_packets: 17690603545
    tx_queue_3_bytes: 7595077037699
    rx_queue_0_packets: 22633701658
    rx_queue_0_bytes: 24720019370595
    rx_queue_1_packets: 22510233259
    rx_queue_1_bytes: 24577714299975
    rx_queue_2_packets: 22794349207
    rx_queue_2_bytes: 24843900675331
    rx_queue_3_packets: 22695653701
    rx_queue_3_bytes: 24906663019280

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Dark_Angel   

Dark_Angel
Опубликовано (изменено) · Жалоба

Коллеги, посоветуйте как лучше натить и выгодно по ресурсам? Сразу подсетью ? NAT организован вот так. На каждую сеть /24 один реальный IP. Есть 126 реальных IP.

Может можно что то вроде

 

Ну еще можно использовать тарегет SAME с ключем --persistent. И тем самым дать возможность системе самой рулить пулом.

 

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

 

Кто подскажет причины роста rx_csum_offload_errors ? Чего может не хватать, куда смотреть?

Деградации не видно, однако бывает по паре штук в секунду растут.

 

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

Изменено пользователем Dark_Angel

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Tamahome   

Tamahome
Опубликовано · Жалоба

Dark_Angel, тогда почему эти счётчики не растут?

rx_over_errors: 0

rx_crc_errors: 0

rx_frame_errors: 0

rx_fifo_errors: 0

rx_missed_errors: 0

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Dark_Angel   

Dark_Angel
Опубликовано · Жалоба

Потому что это другие типы ошибок.

 

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

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

aabc   

aabc
Опубликовано · Жалоба

Dark_Angel, тогда почему эти счётчики не растут?

rx_over_errors: 0

rx_crc_errors: 0

rx_frame_errors: 0

rx_fifo_errors: 0

rx_missed_errors: 0

 

Может быть такова логика подсчета - если учли ошибку в одном счетчике не увеличивают другой счетчик (кто-то решил так считать, кто-то эдак). Вот тоже в очередях csum растёт, а "общий" нет или почти нет (на igb):

 

root@x:~# ethtool -S eth0|grep sum

rx_queue_0_csum_err: 2597

rx_queue_1_csum_err: 2649

rx_queue_2_csum_err: 3707

rx_queue_3_csum_err: 2929

root@x:~# ethtool -S eth0|grep crc

rx_crc_errors: 0

 

root@y:~# ethtool -S eth0|grep sum

rx_queue_0_csum_err: 3043

rx_queue_1_csum_err: 1971

rx_queue_2_csum_err: 1758

rx_queue_3_csum_err: 1706

root@y:~# ethtool -S eth0|grep crc

rx_crc_errors: 3

 

Эти счетчики, на сколько я понимаю, считает сама карта, а драйвер лишь считывает его значение. rx_csum_offload_errors считается драйвером, только для некоторых типов пакетов для которых карта посчитала csum offload всего пакета (как tcp, обычный csum же только хедер).

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Dark_Angel   

Dark_Angel
Опубликовано (изменено) · Жалоба

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

 

Но в данном случае всё просто: rx_csum_offload_errors - это стопудово железная проблема бьющихся кадров. Я с ней сталкиваюсь периодически, особенно на 1Г по меди. Обратите внимание, что это счетчик без очереди, т.е. кадр отбрасывается еще до конвеера, где на него выставляется указатель, который определяет его движение в очереди. Рост ошибок в таких счетчиках как правило всегда проблемы с железом.

 

Пруф по данному счетчику: http://comments.gmane.org/gmane.linux.drivers.e1000.devel/9507

Изменено пользователем Dark_Angel

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

dazgluk   

dazgluk
Опубликовано · Жалоба

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

 

Но в данном случае всё просто: rx_csum_offload_errors - это стопудово железная проблема бьющихся кадров. Я с ней сталкиваюсь периодически, особенно на 1Г по меди. Обратите внимание, что это счетчик без очереди, т.е. кадр отбрасывается еще до конвеера, где на него выставляется указатель, который определяет его движение в очереди. Рост ошибок в таких счетчиках как правило всегда проблемы с железом.

 

Пруф по данному счетчику: http://comments.gmane.org/gmane.linux.drivers.e1000.devel/9507

Из данного пруфа никак не следует что проблема с кабелем.

У нас три ната на X520, два на SR оптике, один на LR, расстояние - соседняя стойка.

На всех трех растут данные счетчики, причем только на внешних интерфейсах. Для себя сделали вывод, что просто часть пакетов прилетает из Интернета битыми.Что совпадает с инженером интела в вашем треде

My guess is that a certain percentage

of internet traffic will always have bad checksums, due to lots of

causes, some due to DoS style attacks, others just due to normal signal

issues.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

nuclearcat   

nuclearcat
Опубликовано · Жалоба

А давайте подойдем к проблеме цифрами:

rx_queue_3_packets: 242466165852

rx_queue_3_bytes: 113426741507687

rx_queue_3_drops: 0

rx_queue_3_csum_err: 5722467

rx_queue_3_alloc_failed: 0

Каждые 42370 пакетов - одна ошибка (.00236010949399553000%)

Средний размер пакета: 468 байт (округляем)

42370*468=каждый 19829160 байт ошибочен

 

В ethernet допустимый BER 1E-10 или 1E-12 (лень искать точно)

1E-10 = 10,000,000,000 - превышение этой нормы в 504 раза.

Проверил еще один сервер, который частично проходит линукс роутер (значит ошибки "из инета" отсекаются):

.00029951716668756300% ошибок, в 10 раз меньше.

 

А у вас какой процент ошибок?

 

Сорри, все таки BER - bit error rate, значит не в 504 раз, а в 63 раза.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

aabc   

aabc
Опубликовано · Жалоба

А у вас какой процент ошибок?

root@x:~# for e in eth{0,1,2,3};do echo $e: `ethtool -S $e|awk '/rx_q.*bytes/ {b=$2*8} /rx_q.*csum_err/ {print $2/b}'`;done
eth0: 1.36608e-10 1.48959e-10 2.07459e-10 1.17628e-10
eth1: 2.79281e-10 2.10744e-10 1.82452e-10 1.89348e-10
eth2: 1.34656e-08 1.27902e-08 1.3089e-08 1.30636e-08
eth3: 1.27678e-08 1.24502e-08 1.26139e-08 1.2142e-08

Это rx_queue_N_csum_err / (rx_queue_N_bytes * 8) для каждой queue N. Здесь eth0 и eth1 смотрят в локалку, eth2 и eth3 в инет (у них в 100-200 раз больше csum_err).

 

 

Пример raw чисел, если захотите проверить рассчеты:

eth0:

rx_queue_0_packets: 5079193910

rx_queue_0_bytes: 2431373303505

rx_queue_0_drops: 0

rx_queue_0_csum_err: 2658

rx_queue_0_alloc_failed: 0

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

dazgluk   

dazgluk
Опубликовано · Жалоба

nuclearcat

Вот от абонентов

    rx_csum_offload_errors: 241622
    rx_queue_0_packets: 273874619939
    rx_queue_1_packets: 274245821725
    rx_queue_2_packets: 260404955547
    rx_queue_3_packets: 260986572190
    rx_queue_4_packets: 260679919811
    rx_queue_5_packets: 260843583458

Вот из интернета

    rx_csum_offload_errors: 4494374
    rx_queue_0_packets: 340311234575
    rx_queue_1_packets: 339977539742
    rx_queue_2_packets: 325558774509
    rx_queue_3_packets: 325195807611
    rx_queue_4_packets: 324085914315
    rx_queue_5_packets: 325090012195

 

Да, от абонентов они тоже есть, что не исключает теорию что часть трафика в принципе бегает ошибочной по сети

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Tamahome   

Tamahome
Опубликовано (изменено) · Жалоба

http://img.tamahome.ru/scr_nat_err_csum.png (на графиках хоть и пишется что бпс, на самом деле это ошибки/сек)

Сомневаюсь что проблема в sfp/оптике.

Linux nat78 3.14.14-gentoo #1 SMP YEKT 2014 x86_64 Intel® Xeon® CPU X3440 @ 2.53GHz GenuineIntel GNU/Linux

ixgbe version: 3.22.3

module_ixgbe_args="allow_unsupported_sfp=1,1 DCA=2,2 FCoE=0,0 LRO=0,0 FdirPballoc=3,3"

C с левой стороны пара без FdirPballoc=3,3.

Изменено пользователем Tamahome

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Dark_Angel   

Dark_Angel
Опубликовано · Жалоба

Из данного пруфа никак не следует что проблема с кабелем.

У нас три ната на X520, два на SR оптике, один на LR, расстояние - соседняя стойка.

На всех трех растут данные счетчики, причем только на внешних интерфейсах. Для себя сделали вывод, что просто часть пакетов прилетает из Интернета битыми.Что совпадает с инженером интела в вашем треде

 

А я и не говорил, что проблема только с кабелем. Замена кабеля - это самое простое что можно сделать. В некоторых ситуациях помогает. Когда не помогает пристально смотрим на свитч - не дает ли ошибок на других портах. Если нет, то можно поменять порт ( иногда помогает ), иногда приходится перепаивать конденсаторы цепи питания, но это уже хардкор.

 

 

 

Не знаю, парни. У меня на здоровых инсталляциях ошибок - либо очень мало ( не видно, как увеличиваются ), либо 0. Битые пакеты из Интернета - будут отсекаться свитчем, т.к. это L2 и он тоже не будет принимать битые фреймы. Так что до роутера они даже не будут долетать. Если конечно роутер не подключен напрямую во внешку.

 

В ситуации с оптикой не знаю что сказать. Битые фреймы и там могут быть, но как такое лечить, я не знаю. Вполне вероятно, что так же как и на меди. Одно я знаю точно - ошибки на интерфейсе - это не нормально в тех объемах которые мы тут обсуждаем. E-10, E-12 еще можно допустить, но 0.002% или 0.0002% - это много. Их быть не должно. Наличие ошибок свидетельствует о том, что какое-то оборудование функционирует не нормально.

 

Другой вопрос, что ошибки находятся в допустимых для вас пределах.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

nuclearcat   

nuclearcat
Опубликовано · Жалоба

Dark_Angel, эти ошибки - частенько в т.ч. CRC и в TCP/UDP, которые свитч не отсекает.

А, еще, L2 это ошибки уровня ethernet, FCS, а не те, которые мы показывали и выше.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

nuclearcat   

nuclearcat
Опубликовано · Жалоба

for e in eth{0,1,2,3};do echo $e: `ethtool -S $e|awk '/rx_q.*bytes/ {b=$2*8} /rx_q.*csum_err/ {print $2/b}'`;done

Скриптец классный, чуть подправил, иначе на busybox не едет:

for e in `seq 0 3`;do echo eth$e: `ethtool -S eth$e|awk '/rx_q.*bytes/ {b=$2*8} /rx_q.*csum_err/ {print $2/b}'`;done

 

У меня на нате (один из клиентов с кучей хреновых каналов):

eth0: 1.09314e-07 1.09245e-07 1.1117e-07 1.09656e-07 1.08797e-07 1.10316e-07 1.09277e-07 1.09636e-07

eth1: 1.06853e-07 1.06165e-07 1.05069e-07 1.0527e-07 1.05978e-07 1.0777e-07 1.06247e-07 1.0585e-07

eth2: 1.05916e-07 1.06383e-07 1.07482e-07 1.06482e-07 1.05512e-07 1.05026e-07 1.04983e-07 1.06491e-07

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Dark_Angel   

Dark_Angel
Опубликовано · Жалоба

Да, csum_err - это ошибки L3/L4. Посыпаю голову пеплом.

 

Решение рисовать графики, по-моему наиболее информативное. Всегда можно понять, когда началось.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

aabc   

aabc
Опубликовано (изменено) · Жалоба
root@y:~# ethtool -S eth0|grep sum

rx_queue_0_csum_err: 3043

rx_queue_1_csum_err: 1971

rx_queue_2_csum_err: 1758

rx_queue_3_csum_err: 1706

root@y:~# ethtool -S eth0|grep crc

rx_crc_errors: 3

 

Эти счетчики, на сколько я понимаю, считает сама карта, а драйвер лишь считывает его значение. rx_csum_offload_errors считается драйвером, только для некоторых типов пакетов для которых карта посчитала csum offload всего пакета (как tcp, обычный csum же только хедер).

 

Посмотрел исходники драйвера igb и 82576eb-gigabit-ethernet-controller-datasheet.pdf, чтоб окончательно прояснить где L2, а где L3/L4 checksum.

 

L2 CRC попадают в регистр карты CRCERRS, в ethtool -S он виден как rx_crc_errors или напрямую как ethtool -d eth0|grep CRCERRS.

 

rx_*_csum_err считает драйвер, если включен checksum offload (ethtool -k) и карта дала в дескрипторе пакета флаги ошибки IPE и TCPE (ошибка checksum для IP и TCP соотв., т.е. это L3/L4).

 

У ixgb отличие, что rx_*_csum_err теперь называется rx_csum_offload_errors и в нем только TCPE (L4).

 

У ixgbe, rx_csum_offload_errors, в котором IPE и TCPE.

Изменено пользователем aabc

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

shamani   

shamani
Опубликовано · Жалоба

 

Сейчас сделано так 

$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.0.0/24 -j SNAT --to-source 93.157.x.1
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.1.0/24 -j SNAT --to-source 93.157.x.1
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.2.0/24 -j SNAT --to-source 93.157.x.2
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.3.0/24 -j SNAT --to-source 93.157.x.3
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.4.0/24 -j SNAT --to-source 93.157.x.4
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.5.0/24 -j SNAT --to-source 93.157.x.5
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.6.0/24 -j SNAT --to-source 93.157.x.6
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.7.0/24 -j SNAT --to-source 93.157.x.7
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.8.0/24 -j SNAT --to-source 93.157.x.8
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.9.0/24 -j SNAT --to-source 93.157.x.9

 

Коллеги.

 

Roysbike в одном из постов спрашивал про правила NAT, как оптимизировать т.п.

 

c версии iptables 1.4.10 правила можно отрабатывать на разных процах.

получается

 

$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.0.0/24 -m cpu --cpu 0 -j SNAT --to-source 93.157.x.1
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.1.0/24 -m cpu --cpu 1 -j SNAT --to-source 93.157.x.1
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.2.0/24 -m cpu --cpu 2 -j SNAT --to-source 93.157.x.2
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.3.0/24 -m cpu --cpu 3 -j SNAT --to-source 93.157.x.3
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.4.0/24 -m cpu --cpu 4 -j SNAT --to-source 93.157.x.4
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.5.0/24 -m cpu --cpu 5 -j SNAT --to-source 93.157.x.5
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.6.0/24 -m cpu --cpu 6 -j SNAT --to-source 93.157.x.6
...

 

Вот у меня и возник вопрос, а даст это прироста производительности и/или более равномерно распределит нагрузку про процам, может кто так делал?

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Dark_Angel   

Dark_Angel
Опубликовано · Жалоба

Правила и так обрабатываются на разных процессорах. Данная опция позволяет, судя по всему, прибить обработку на конкретный процессор. Не совсем понятно в каком сценарии такое может понадобится, но это явно не оптимизация.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

aabc   

aabc
Опубликовано · Жалоба

shamani

Не даст. Так как список правил остается таким как был (длинным), а добавляется лишь дополнительное сравнение.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Igor Diakonov   

Igor Diakonov
Опубликовано · Жалоба

c версии iptables 1.4.10 правила можно отрабатывать на разных процах.

Можно не "правила обрабатывать на разных процах", а "применять разные правила в зависимости от того на какой процессор прилетел трафик"

Фил зе дифференс :)

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

aabc   

aabc
Опубликовано · Жалоба

Коллеги, посоветуйте как лучше натить и выгодно по ресурсам? Сразу подсетью ? NAT организован вот так. На каждую сеть /24 один реальный IP. Есть 126 реальных IP.

Может можно что то вроде

IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.0.0/24 -j SNAT --to-source 93.157.x.0/25 ?

 

Сейчас сделано так 

$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.0.0/24 -j SNAT --to-source 93.157.x.1
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.1.0/24 -j SNAT --to-source 93.157.x.1
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.2.0/24 -j SNAT --to-source 93.157.x.2
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.3.0/24 -j SNAT --to-source 93.157.x.3
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.4.0/24 -j SNAT --to-source 93.157.x.4
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.5.0/24 -j SNAT --to-source 93.157.x.5
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.6.0/24 -j SNAT --to-source 93.157.x.6
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.7.0/24 -j SNAT --to-source 93.157.x.7
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.8.0/24 -j SNAT --to-source 93.157.x.8
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.9.0/24 -j SNAT --to-source 93.157.x.9
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.10.0/24 -j SNAT --to-source 93.157.x.10
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.11.0/24 -j SNAT --to-source 93.157.x.11
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.12.0/24 -j SNAT --to-source 93.157.x.12
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.13.0/24 -j SNAT --to-source 93.157.x.13
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.14.0/24 -j SNAT --to-source 93.157.x.14
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.15.0/24 -j SNAT --to-source 93.157.x.15

 

и тд

 

Как правильно говорит Dark_Angel, очевидно, что одна строчка лучше чем 15. В 15 раз меньше нагрузки.

 

Но "--to-source 93.157.x.0/25" не тождественная замена 15 строкам, так как в этом случае клиент будет получать разное ип в зависимости от разных сайтов куда ходит. Говорят "видео VK перестаёт работать и так далее." Поэтому, надо добавить опцию --persistent, это сделает внешние адреса (93.157.x.0/25) зависимыми только от локального адреса (172.30.0.0/24), и не зависимыми от сайта назначения. То есть, как в случае 15 строчной схемы, у клиенте всегда будет один внешний ип адрес ("случайный" из пула).

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Dark_Angel   

Dark_Angel
Опубликовано · Жалоба

Ну и если уже говорить, про нарезку, то лучше резать /25, а то, говорят гугл /24 не любит. А вообще не вижу ниодной причины не юзать SAME с --persistent как описал это aabc.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

roysbike   

roysbike
Опубликовано (изменено) · Жалоба

Коллеги, посоветуйте как лучше натить и выгодно по ресурсам? Сразу подсетью ? NAT организован вот так. На каждую сеть /24 один реальный IP. Есть 126 реальных IP.

Может можно что то вроде

IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.0.0/24 -j SNAT --to-source 93.157.x.0/25 ?

 

Сейчас сделано так 

$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.0.0/24 -j SNAT --to-source 93.157.x.1
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.1.0/24 -j SNAT --to-source 93.157.x.1
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.2.0/24 -j SNAT --to-source 93.157.x.2
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.3.0/24 -j SNAT --to-source 93.157.x.3
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.4.0/24 -j SNAT --to-source 93.157.x.4
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.5.0/24 -j SNAT --to-source 93.157.x.5
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.6.0/24 -j SNAT --to-source 93.157.x.6
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.7.0/24 -j SNAT --to-source 93.157.x.7
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.8.0/24 -j SNAT --to-source 93.157.x.8
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.9.0/24 -j SNAT --to-source 93.157.x.9
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.10.0/24 -j SNAT --to-source 93.157.x.10
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.11.0/24 -j SNAT --to-source 93.157.x.11
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.12.0/24 -j SNAT --to-source 93.157.x.12
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.13.0/24 -j SNAT --to-source 93.157.x.13
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.14.0/24 -j SNAT --to-source 93.157.x.14
$IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.15.0/24 -j SNAT --to-source 93.157.x.15

 

и тд

 

Как правильно говорит Dark_Angel, очевидно, что одна строчка лучше чем 15. В 15 раз меньше нагрузки.

 

Но "--to-source 93.157.x.0/25" не тождественная замена 15 строкам, так как в этом случае клиент будет получать разное ип в зависимости от разных сайтов куда ходит. Говорят "видео VK перестаёт работать и так далее." Поэтому, надо добавить опцию --persistent, это сделает внешние адреса (93.157.x.0/25) зависимыми только от локального адреса (172.30.0.0/24), и не зависимыми от сайта назначения. То есть, как в случае 15 строчной схемы, у клиенте всегда будет один внешний ип адрес ("случайный" из пула).

 

Спасибо, попробуй и сравню .

 

Верно?

IPTABLES -t nat -A POSTROUTING -o $OUT_IFACE2 -s 172.30.0.0/17 -j SNAT --to-source 93.157.x.1-93.157.x.126 --persistent

Изменено пользователем roysbike

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Megas   

Megas
Опубликовано · Жалоба

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

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

×
Перейти к списку тем Программное обеспечение, биллинг и *unix системы