Задача переноса отдельно стоящего nat сервера на BRAS сервер
На BRAS accel-ppp был отключен connection tracking для абонентских сетей, который нужен для NAT
1) Нужно либо переписать правило NOTRACK all 0.0.0.0/0 на ACCEPT, либо удалить его. Оптимальнее всего убрать все правила из цепочки RAW.
Выполним через консоль:
iptables -t raw -F PREROUTING
iptables -t raw -F OUTPUT
2) согласно схемы L3switch(pbr на интерфейсе для серых адресов)<–>NAT было прописано правило
l3#ip route 91.197.0.0 255.255.254.0 192.168.1.1 нужно переписать в сторону bras l3#ip router 91.197.0.0 255.255.254.0 192.168.1.2
в моем случае я забрал не все адреса из пула 91.197.0.0-91.197.0.127, а только часть изменив iptables -t nat -R PREROUTING 47 -to-source 91.197.0.0-91.197.0.63 –persistent так как на стороне BRAS еще не все готово. обязательно сделать conntrack -F , так как соединения будут висеть на всем диапазаное указанном ранее 91.197.0.0-91.197.0.127 (к примеру можно проверить через conntrack -L | grep 91.197.0.120)
3) на bras создать sub интерфейсы в файле interfaces.
eth0.2000:1 91.197.0.64
eth0.2000:2 91.197.0.65
eth0.2000:3 91.197.0.66
и так далее.
3.1) подождем пока все абоненты отключаться telnet 127.0.0.1 2000 shutdown soft
4) правило NAT iptables -t nat -A POSTROUTING -s 10.1.0.0/19 -o ens6f1.2004 -j SNAT –to-source 91.197.0.64-91.197.76.0.127 –persistent
5) за одно можно обновить сервер :-)
w
12:16:40 up 608 days, 3:15, 1 user, load average: 0,09, 0,04, 0,06
lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 7.11 (wheezy)
Release: 7.11
Codename: wheezy
Сохраним все изменеия в скриптах который подгружает правила при старте.
-
best practics https://fasterdata.es.net/host-tuning/linux/
-
best practics https://habr.com/company/mailru/blog/314168/
Если сервер работает только маршрутизатором, то тюнинг TCP стека особого значения не имеет, кроме тюнинга параметров касаемых производительности сетевой карты (буфера, очередей, распределения прерывайни и т.д.)
Планируемая нагрузка будет в районе 2Gbit, стандартные параметры ядра на это не расчитаны, они выбраны средние между nat/web-server/gw. Нам нужно все это оптимизировать под наши задачи.
Будет рассмотрена два этапа.
1) тюнинг сетевого стека
https://opensourceforu.com/2016/10/network-performance-monitoring/
2) тюнинг работы системы касаемо cpu, а производительность самой системы нам не важа. cpu governor
Этап 1
1) Interrupt Coalescence
После того как сетевой адаптер получает пакеты, драйвер устройства выдает одно жесткое прерывание, за которым следуют программные прерывания (обрабатываются NAPI). Объединение прерываний - это количество пакетов, которые сетевой адаптер получает до выдачи жесткого прерывания. Изменение значения для быстрого прерывания может привести к большим накладным расходам и, следовательно, к снижению производительности, но высокое значение может привести к потере пакетов. По умолчанию ваши настройки находятся в режиме адаптивной ИС, который автоматически балансирует значение в соответствии с сетевым трафиком. Но поскольку новые ядра используют NAPI, что делает быстрые прерывания гораздо менее затратными (с точки зрения производительности), вы можете отключить эту функцию.
ethtool -c eth0
ethtool -C eth0 adaptive-rx off
ethtool -c eth0
Coalesce parameters for eth0:
Adaptive RX: off TX: off
stats-block-usecs: 0
sample-interval: 0
2) Пауза кадров
Кадр паузы - это длительность паузы в миллисекундах, которую адаптер выдает сетевому коммутатору для остановки отправки пакетов, если кольцевой буфер заполнен. Если включен режим паузы, потеря пакетов будет минимальной.
ethtool -a eth0
Pause parameters for eth0:
Autonegotiate: off
RX: off
TX: off
ethtool -A eth0 tx on rx on
3) Изменение параметров Offload feature через ethtool.
Часть статей готоврит что сетевые карты затрудительно работают с этими включенными параметрами.
ethtool -K eth1 tx off rx off sg off tso off ufo off gso off lro off rxvlan off txvlan off
4) Некоторые сетевые карты и их драйверы
поддерживают настройку размера очереди приёма. Конкретная реализация зависит от оборудования, но, к счастью, ethtool обеспечивает стандартный метод настройки. Увеличение размера позволяет предотвратить отбрасывание сетевых данных при большом количестве входящих фреймов. Правда, данные ещё могут быть отброшены на уровне ПО, так что для полного исключения или снижения отбрасывания необходимо будет провести дополнительную настройку.
Проверка текущего размера очереди сетевой карты с помощью ethtool –g:
$ sudo ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX: 4096
RX Mini: 0
RX Jumbo: 0
TX: 4096
Current hardware settings:
RX: 512
RX Mini: 0
RX Jumbo: 0
TX: 512
Выходные данные показывают, что оборудование поддерживает 4096 дескрипторов приёма и передачи, но в данный момент используется 512.
Увеличим размер каждой очереди до 4096:
$ sudo ethtool -G eth0 rx 4096
5) Количесвто очередей можно настривать разными способами.
если сетевая карта поддерживает передачу параметров через ethtool - l то вывод будет:
ethtool -l eth0
Channel parameters for eth0:
Pre-set maximums:
RX: 0
TX: 0
Other: 1
Combined: 63
Current hardware settings:
RX: 0
TX: 0
Other: 1
Combined: 24
ethtool -l eth0
Channel parameters for eth0:
Cannot get device channel parameters
: Operation not supported
Для того, чтобы равномерно распределить прерывания на сетевом интерфейсе необходимо изменить количество очередей.Например, у нас имеется 6-ти ядерный процессор, а сетевая карта поддерживает 8 очередей.(Очень важно! Для того чтобы установить именно то значение, которое требуется, необходимо сбросить значение количества очередей до 1. Так как ethtool -L прибавляет количество очередей.http://docs.carbonsoft.ru/ )
ethtool -L eth1 rx 1 tx 1
ethtool -L eth1 rx 5 tx 5
Получаем (в поле Combined):
ethtool -l eth1
Channel parameters for eth1:
Pre-set maximums:
RX: 16
TX: 16
Other: 1
Combined: 16
Current hardware settings:
RX: 0
TX: 0
Other: 1
Combined: 6
6) распределение прерыванйи между ядрами ,
в инете есть скрипт который привязывает прерывания к ядрам smp_affinity но можно сделать и вручную.
Предпочтительнее использовать прерывания MSI-X, особенно для сетевых карт, поддерживающих несколько очередей приёма. Причина в том, что каждой очереди присвоено собственное аппаратное прерывание, которая может быть обработано конкретным CPU (с помощью irqbalance или модифицирования /proc/irq/IRQ_NUMBER/smp_affinity). Как мы скоро увидим, прерывание и пакет обрабатывает один и тот же CPU. Таким образом, входящие пакеты будут обрабатываться разными CPU в рамках всего сетевого стека, начиная с уровня аппаратных прерываний(https://habr.com/company/mailru/blog/314168/).
Пример распределение прерываний вручную : При подготовке в эксплуатацию сервера с Intel Xeon E5520 (8 ядер, каждое с HyperThreading) я выбрал такую схему распределения прерыванийв(зято с https://habr.com/post/108240/ :
#CPU6
echo 40 > /proc/irq/71/smp_affinity
echo 40 > /proc/irq/84/smp_affinity
#CPU7
echo 80 > /proc/irq/72/smp_affinity
echo 80 > /proc/irq/85/smp_affinity
#CPU8
echo 100 > /proc/irq/73/smp_affinity
echo 100 > /proc/irq/86/smp_affinity
#CPU9
echo 200 > /proc/irq/74/smp_affinity
echo 200 > /proc/irq/87/smp_affinity
#CPU10
echo 400 > /proc/irq/75/smp_affinity
echo 400 > /proc/irq/80/smp_affinity
#CPU11
echo 800 > /proc/irq/76/smp_affinity
echo 800 > /proc/irq/81/smp_affinity
#CPU12
echo 1000 > /proc/irq/77/smp_affinity
echo 1000 > /proc/irq/82/smp_affinity
#CPU13
echo 2000 > /proc/irq/78/smp_affinity
echo 2000 > /proc/irq/83/smp_affinity
#CPU14
echo 4000 > /proc/irq/70/smp_affinity
#CPU15
echo 8000 > /proc/irq/79/smp_affinit
Распределение с помощью скрипта
я использую скрипт https://gist.github.com/SaveTheRbtz/8875474 с параметрами
/usr/local/sbin/set_irq_affinity.sh -x 1,2,4,6,8,10,12,14,16,18,20,22 eth2
в моем случаея два процессора 6 ядерных по 2 потока , итого 24 потока . привязыват очереди к разным процессорам нет смысла. так как мы тогда будет еще и передавать часть пакеты принадлежащие к одному пакеты на разные процессоры . вывод из пакета netitils
NUMA node(s): 2
NUMA node0 CPU(s): 1,2,4,6,8,10,12,14,16,18,20,22
NUMA node1 CPU(s): 0,3,5,7,9,11,13,15,17,19,21,23
Какой номер ядра принадлежит какому cpu можно узнать выполнив
lscpu -p
# The following is the parsable format, which can be fed to other
# programs. Each different item in every column has an unique ID
# starting from zero.
# CPU,Core,Socket,Node,,L1d,L1i,L2
0,0,0,0,,0,0,0
1,1,1,0,,1,1,1
2,2,0,0,,2,2,2
3,3,1,0,,3,3,3
4,4,0,0,,4,4,0
5,5,1,0,,5,5,1
6,6,0,0,,6,6,2
7,7,1,0,,7,7,3
Визульано представить связь между pci-cpu-numa.
Пример вывода
lstopo --logical --output-format png > `hostname`.png
lstopo входит в пакет hwloc
После обновления драйверов для igb/ixgb перестал писать кол. потоков/очередей при загрузке модуля (/etc/modprode.d/ixgb.conf options igb IntMode=2,2 RSS=4,4). раньше были параметры InterruptThrottleRate IntMode RSS, но сейчас их нет .Но на одной из карт поддержки нет и через ethtool -l .
Получается что по умолчанию у меня 8 очередей на 2 cpu / по 4 потока.
filename: /lib/modules/3.2.0-4-amd64/kernel/drivers/net/ethernet/intel/ixgb/ixgb.ko
version: 1.0.135-k2-NAPI
vermagic: 3.2.0-4-amd64 SMP mod_unload modversions
parm: TxDescriptors:Number of transmit descriptors (array of int)
parm: RxDescriptors:Number of receive descriptors (array of int)
parm: FlowControl:Flow Control setting (array of int)
parm: XsumRX:Disable or enable Receive Checksum offload (array of int)
parm: TxIntDelay:Transmit Interrupt Delay (array of int)
parm: RxIntDelay:Receive Interrupt Delay (array of int)
parm: RxFCHighThresh:Receive Flow Control High Threshold (array of int)
parm: RxFCLowThresh:Receive Flow Control Low Threshold (array of int)
parm: FCReqTimeout:Flow Control Request Timeout (array of int)
parm: IntDelayEnable:Transmit Interrupt Delay Enable (array of int)
parm: copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm: debug:Debug level (0=none,...,16=all) (int)
64: 1388811 37523023 37121220 12979080 36422018 37399840 13902475 38582741 PCI-MSI-edge cciss0
68: 4111931200 40442814 41129363 38146147 43957327 36241924 42664243 35142543 PCI-MSI-edge eth0-TxRx-0
69: 17637913 145926613 14680315 15605848 12290519 19817252 10551118 19846568 PCI-MSI-edge eth0-TxRx-1
70: 9943951 19936292 1324475156 17126835 15995107 14101462 21042158 11678913 PCI-MSI-edge eth0-TxRx-2
71: 19385777 10269389 17160019 1816592674 14383590 15722375 12047918 19636239 PCI-MSI-edge eth0-TxRx-3
72: 11729115 20677828 10012525 20474639 3461855270 17560992 15708121 14319310 PCI-MSI-edge eth0-TxRx-4
73: 19673810 12010188 19357842 10238283 17271863 3371117118 14462045 15707642 PCI-MSI-edge eth0-TxRx-5
74: 14272599 15911616 11798962 20360337 10190675 20238526 426848144 17544489 PCI-MSI-edge eth0-TxRx-6
75: 16343183 14722220 20381173 12285766 20122065 10600197 17668610 2267346210 PCI-MSI-edge eth0-TxRx-7
UPD Все примеры привожу для карт построенных на чипах с поддержкой драйверов igb, ixgb.
Если мы не хотим разбираться со всем этим идем на https://habr.com/post/331720/ и скачиваем скрипт netutils-linux
6.1 ) при перераспределении прерывайний не совсем было понятно по какой причине нужно использовать RPS(RFS) при работе bras в качестве pppoe сервера.
echo "0" > /sys/class/net/ens2f0/queues/rx-0/rps_cpus
echo "1" > /sys/class/net/ens2f0/queues/rx-0/rps_cpus
echo "2" > /sys/class/net/ens2f0/queues/rx-1/rps_cpus
echo "4" > /sys/class/net/ens2f0/queues/rx-2/rps_cpus
echo "8" > /sys/class/net/ens2f0/queues/rx-3/rps_cpus
echo "10" > /sys/class/net/ens2f0/queues/rx-4/rps_cpus
echo "20" > /sys/class/net/ens2f0/queues/rx-5/rps_cpus
echo "40" > /sys/class/net/ens2f0/queues/rx-6/rps_cpus
echo "80" > /sys/class/net/ens2f0/queues/rx-7/rps_cpus
sysctl -w net.core.rps_sock_flow_entries=32768
echo 2048 > /sys/class/net/ens2f0/queues/rx-0/rps_flow_cnt
echo 2048 > /sys/class/net/ens2f0/queues/rx-1/rps_flow_cnt
echo 2048 > /sys/class/net/ens2f0/queues/rx-2/rps_flow_cnt
echo 2048 > /sys/class/net/ens2f0/queues/rx-3/rps_flow_cnt
echo 2048 > /sys/class/net/ens2f0/queues/rx-4/rps_flow_cnt
echo 2048 > /sys/class/net/ens2f0/queues/rx-5/rps_flow_cnt
echo 2048 > /sys/class/net/ens2f0/queues/rx-6/rps_flow_cnt
echo 2048 > /sys/class/net/ens2f0/queues/rx-7/rps_flow_cnt
Сетевые параметры ядра описаны на странице : https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt
sysctl.conf intel ixgb 10 https://downloadmirror.intel.com/5874/eng/README.txt
### IPV4 specific settings
# turn TCP timestamp support off, default 1, reduces CPU use
net.ipv4.tcp_timestamps = 0
# turn SACK support off, default on
# on systems with a VERY fast bus -> memory interface this is the big gainer
net.ipv4.tcp_sack = 0
# set min/default/max TCP read buffer, default 4096 87380 174760
net.ipv4.tcp_rmem = 10000000 10000000 10000000
# set min/pressure/max TCP write buffer, default 4096 16384 131072
net.ipv4.tcp_wmem = 10000000 10000000 10000000
# set min/pressure/max TCP buffer space, default 31744 32256 32768
net.ipv4.tcp_mem = 10000000 10000000 10000000
### CORE settings (mostly for socket and UDP effect)
# set maximum receive socket buffer size, default 131071
net.core.rmem_max = 524287
# set maximum send socket buffer size, default 131071
net.core.wmem_max = 524287
# set default receive socket buffer size, default 65535
net.core.rmem_default = 524287
# set default send socket buffer size, default 65535
net.core.wmem_default = 524287
# set maximum amount of option memory buffers, default 10240
net.core.optmem_max = 524287
# set number of unprocessed input packets before kernel starts dropping them; default 300
net.core.netdev_max_backlog = 300000
- END sysctl_ixgb.conf
Resolving Slow UDP Traffic
If your server does not seem to be able to receive UDP traffic as fast as it can receive TCP traffic, it could be because Linux, by default, does not set the network stack buffers as large as they need to be to support high UDP transfer rates. One way to alleviate this problem is to allow more memory to be used by the IP stack to store incoming data.
For instance, use the commands: sysctl -w net.core.rmem_max=262143 and sysctl -w net.core.rmem_default=262143 to increase the read buffer memory max and default to 262143 (256k - 1) from defaults of max=131071 (128k - 1) and default=65535 (64k - 1). These variables will increase the amount of memory used by the network stack for receives, and can be increased significantly more if necessary for your application.
network/interfaces
up ethtool -K ens2f1 tx off rx off sg off tso off gso off gro off rxvlan off txvlan off ntuple on
up ethtool -G ens2f1 rx 4096 tx 4096
up ip link set ens2f1 txqueuelen 10000
up ethtool -A ens2f1 rx off tx off adaptive-rx off
up ethtool -L ens2f1 combined 4 # default combined 8
/etc/init.d/cpufrequtils
GOVERNOR="performance"
прописал правила ip_set для оптимизации скорости работы
#!/bin/sh
ipset -N bogons nethash
ipset -A bogons 224.0.0.0/4
ipset -A bogons 240.0.0.0/4
ipset -A bogons 198.18.0.0/15
ipset -A bogons 192.88.99.0/24
ipset -A bogons 192.0.2.0/24
ipset -A bogons 198.51.100.0/24
ipset -A bogons 203.0.113.0/24
ipset -A bogons 192.0.0.0/24
ipset -A bogons 169.254.0.0/16
ipset -A bogons 100.64.0.0/10
ipset -A bogons 10.0.0.0/8
ipset -A bogons 172.16.0.0/12
ipset -A bogons 192.168.0.0/16
ipset -N tarpit_limit nethash
ipset -A tarpit_limit 10.1.0.0/19
-A PREROUTING -s 10.1.0.0/19 -m set --match-set bogons dst -j DROP
при написании правил рекомедуется писать их по очереди к примеру правила tcp идут следом за tcp, также и udp udp.
Generated by iptables-save v1.6.0 on Wed Jan 9 15:16:08 2019
*raw
:PREROUTING ACCEPT [83547165651:91759375064762]
:OUTPUT ACCEPT [222632359:280636653477]
-A PREROUTING -s 91.197.76.0/22 -m set --match-set bogons dst -j DROP
-A PREROUTING -s 10.1.0.0/19 -m set --match-set bogons dst -j DROP
COMMIT
# Completed on Wed Jan 9 15:16:08 2019
# Generated by iptables-save v1.6.0 on Wed Jan 9 15:16:08 2019
*nat
:PREROUTING ACCEPT [2700167709:208611542910]
:INPUT ACCEPT [2381611:143690845]
:OUTPUT ACCEPT [46736935:10250023123]
:POSTROUTING ACCEPT [422649522:37978347663]
-A PREROUTING -s 10.10.10.0/24 -p tcp -m tcp --dport 80 -j DNAT --to-destination 91.197.0.254
-A POSTROUTING -s 10.1.0.0/19 -o ens2f0.2004 -j SNAT --to-source 195.178.0.64-195.178.0.127 --persistent
COMMIT
# Completed on Wed Jan 9 15:16:08 2019
# Generated by iptables-save v1.6.0 on Wed Jan 9 15:16:08 2019
*filter
:INPUT DROP [13666139:974350046]
:FORWARD ACCEPT [45357769:5088365309]
:OUTPUT ACCEPT [4225370:5268721732]
:tcpchk - [0:0]
-A INPUT -s 127.0.0.1/32 -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.0.0/24 -m state --state NEW -j ACCEPT
-A INPUT -s 10.2.1.0/24 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m multiport --dports 33435:33525 -m limit --limit 1/sec -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A INPUT -p icmp -m limit --limit 1/sec -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp -m limit --limit 1/sec -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m limit --limit 1/sec -m icmp --icmp-type 11 -j ACCEPT
-A INPUT -p icmp -j DROP
-A FORWARD -o ens2f0.2004 -j NETFLOW
-A FORWARD -i ens2f0.2004 -j NETFLOW
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p tcp -m set --match-set tarpit_limit src -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 3000 --connlimit-mask 32 --connlimit-saddr -j TARPIT --tarpit
-A FORWARD -p udp -m set --match-set tarpit_limit src -m udp -m connlimit --connlimit-above 3000 --connlimit-mask 32 --connlimit-saddr -j DROP
-A FORWARD -p udp -m udp -m multiport --dports 67:68,512:514,111,161:162,445 -j DROP
-A FORWARD -p tcp -m tcp -m multiport --dports 445,137:139,512:514,11,111 -j DROP
-A tcpchk -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A tcpchk -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A tcpchk -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG SYN,PSH -j DROP
-A tcpchk -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG SYN,PSH,ACK -j DROP
-A tcpchk -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j DROP
-A tcpchk -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,PSH,URG -j DROP
-A tcpchk -p tcp -m tcp --tcp-flags SYN,ACK NONE -j DROP
-A tcpchk -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j DROP
-A tcpchk -p tcp -m tcp --tcp-flags SYN,URG SYN,URG -j DROP
-A tcpchk -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j DROP
-A tcpchk -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j DROP
-A tcpchk -p tcp -m tcp --tcp-flags FIN,ACK FIN -j DROP
-A tcpchk -p tcp -m tcp --tcp-flags PSH,ACK PSH -j DROP
-A tcpchk -p tcp -m tcp --tcp-flags ACK,URG URG -j DROP
-A tcpchk -p tcp -m tcp --tcp-flags FIN,RST FIN,RST -j DROP
-A tcpchk -j RETURN
COMMIT
# Completed on Wed Jan 9 15:16:08 2019
----
/etc/sysctl.conf минимальные изменения
#net.netfilter.nf_conntrack_tcp_timeout_established = 900 (default 432000 = 120 часов )
помнить сессию 5 дней если даже если по ней пробежал один байт
#для работы GRE тунелей добавим в debian stretch
net.netfilter.nf_conntrack_helper = 1
Проверим что бы были строки :
net.ipv4.ip_forward=1 #
net.nf_conntrack_max=262144 #увеличение максимальноко колличества сейссий conntrack_buckets * 4
#для избежания сообщений nf_conntrack: table full, dropping packet в dmesg
#при ddos или flood от абонента
net.netfilter.nf_conntrack_buckets = 65536
Вот полный systl
s.file-max=1645766
kernel.msgmax = 65536
kernel.msgmnb = 65536
kernel.msgmni=16384
kernel.panic = 5
kernel.printk = 4 4 1 7
net.core.default_qdisc = fq
net.core.dev_weight = 16
net.core.netdev_budget = 50000
net.core.netdev_max_backlog = 100000
net.core.optmem_max = 524287
net.core.rmem_default = 56623104
net.core.rmem_max = 56623104
net.core.somaxconn = 65535
net.core.wmem_default = 56623104
net.core.wmem_max = 56623104
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.icmp_ratelimit = 100
net.ipv4.ip_forward = 1
net.ipv4.ip_local_port_range = 1000 65535
net.ipv4.neigh.default.gc_interval = 3600
net.ipv4.neigh.default.gc_stale_time = 3600
net.ipv4.neigh.default.gc_thresh1 = 2048
net.ipv4.neigh.default.gc_thresh2 = 4096
net.ipv4.neigh.default.gc_thresh3 = 8192
net.ipv4.tcp_congestion_control = htcp
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_max_syn_backlog = 30000
net.ipv4.tcp_max_tw_buckets = 2000000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 10000000 10000000 10000000
net.ipv4.tcp_rmem = 10000000 10000000 10000000
net.ipv4.tcp_sack = 0
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_wmem = 10000000 10000000 10000000
net.ipv4.udp_rmem_min = 8192
net.ipv4.udp_wmem_min = 8192
net.netfilter.nf_conntrack_helper = 1
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 10
net.netfilter.nf_conntrack_tcp_timeout_established = 900
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 20
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 20
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 20
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 10
net.netflow.natevents = 1
net.nf_conntrack_max = 500000
для тюнинга параметров conntrack_max и hash size нужно воспользоваться инструментом.
nf_conntrack_max
https://manpages.debian.org/unstable/iproute2/ctstat.8.en.html
lnstat -f nf_conntrack -i 1 -c 1000
nf_connt|nf_connt|nf_connt|nf_connt|nf_connt|nf_connt|nf_connt|nf_connt|nf_connt|nf_connt|nf_connt|nf_connt|nf_connt|nf_connt|nf_connt|nf_connt|nf_connt|
entries|searched| found| new| invalid| ignore| delete|delete_l| insert|insert_f| drop|early_dr|icmp_err|expect_n|expect_c|expect_d|search_r|
| | | | | | | ist| | ailed| | op| or| ew| reate| elete| estart|
44341| 0| 7460959| 0|2375671414|310597499| 0| 0| 0| 4| 4| 0|31828632| 1883358| 5377411| 5377394|2081137785|
44283| 0| 0| 0| 174| 3| 0| 0| 0| 0| 0| 0| 5| 0| 1| 1| 99|
44254| 0| 0| 0| 174| 2| 0| 0| 0| 0| 0| 0| 0| 0| 1| 1| 91|
44083| 0| 1| 0| 227| 60| 0| 0| 0| 0| 0| 0| 2| 0| 0| 0| 134|
43908| 0| 0| 0| 220| 2| 0| 0| 0| 0| 0| 0| 9| 0| 0| 0| 113|
43740| 0| 0| 0| 140| 5| 0| 0| 0| 0| 0| 0| 6| 0| 0| 0| 113|
UPD tcp congestion reno cubic и т.д. https://habr.com/ru/post/168407/
Оставить комментарий