Border + NAT. Периодически высокая загрузка CPU.

[911 140]

можно пппое на один сервак кинуть на один канал, а на второй канал dhcp

как вариант...

[fet4 46]

Вчера купил новый проц из того что было по месту и поставил. Надеюсь это решит проблему.

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 158
Model name:            Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
Stepping:              9
CPU MHz:               4000.122
CPU max MHz:           4200,0000
CPU min MHz:           800,0000
BogoMIPS:              7200.00
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              8192K
NUMA node0 CPU(s):     0-3
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp

Так же при возможности сделал lacp из двух интерфейсов. Но нормального баланса между сетевыми не увидел видимо потому что там уже L3 трафик. Можно ли это как-то улучшить? Или как правильно с аггрегировать два интерфейса в данном случае?

На стороне сервера

ip link add name bond0 type bond
ip link set dev bond0 type bond mode 802.3ad
ip link set dev enp1s0f0 master bond0
ip link set dev enp1s0f1 master bond0
ip link set dev bond0 up

На свитче просто lacp на интерфейсах. port-channel появился.

 

Так же при загрузке система конфигурируется командами. Подскажите все ли они нужны и правильные значения.

ethtool -K enp1s0f0/enp1s0f1 rx off
ethtool -K enp1s0f0/enp1s0f1 tx off
ethtool -K enp1s0f0/enp1s0f1 tso off
ethtool -K enp1s0f0/enp1s0f1 ufo off
ethtool -K enp1s0f0/enp1s0f1 gso off
ethtool -K enp1s0f0/enp1s0f1 gro off
ethtool -K enp1s0f0/enp1s0f1 lro off
ethtool -K enp1s0f0/enp1s0f1 rxvlan off
ethtool -K enp1s0f0/enp1s0f1 txvlan off
ethtool -K enp1s0f0/enp1s0f1 rxhash off
ethtool -G enp1s0f0/enp1s0f1 rx 2048 tx 2048
ethtool -C enp1s0f0/enp1s0f1 adaptive-rx off adaptive-tx off rx-usecs 0 tx-usecs 0
ethtool -A enp1s0f0/enp1s0f1 autoneg off rx off tx off

echo 409600 > /proc/sys/net/netfilter/nf_conntrack_buckets
echo 1638400 > /proc/sys/net/netfilter/nf_conntrack_max
echo 1638400 > /proc/sys/net/nf_conntrack_max
echo 600 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established

for x in 0 1 2 3; do echo performance > /sys/devices/system/cpu/cpu${x}/cpufreq/scaling_governor; done

echo 250000 > /proc/sys/net/core/netdev_max_backlog
echo 4194304 > /proc/sys/net/core/rmem_max
echo 4194304 > /proc/sys/net/core/wmem_max
echo 4194304 > /proc/sys/net/core/rmem_default
echo 4194304 > /proc/sys/net/core/wmem_default
echo 4194304 > /proc/sys/net/core/optmem_max

echo 0 > /proc/sys/net/ipv4/tcp_timestamps
echo 1 > /proc/sys/net/ipv4/tcp_sack
echo "4096 87380 4194304" > /proc/sys/net/ipv4/tcp_rmem
echo "4096 65536 4194304" > /proc/sys/net/ipv4/tcp_wmem
echo 1 > /proc/sys/net/ipv4/tcp_low_latency
echo 1 > /proc/sys/net/ipv4/tcp_adv_win_scale

echo 0 > /sys/block/sda/queue/add_random
echo 2 > /sys/block/sda/queue/nomerges

echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6

echo 1 > /proc/sys/net/ipv4/ip_forward

Прерывания раскинуты так. По ядрам загрузка одинаковая.

# cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3

 25:          1          0          0          0   PCI-MSI 524288-edge      enp1s0f0
 26:          2          0  311210732          0   PCI-MSI 524289-edge      enp1s0f0-rx-0
 27:          2  401254667          0          0   PCI-MSI 524290-edge      enp1s0f0-rx-1
 28:  357244949          0          0          0   PCI-MSI 524291-edge      enp1s0f0-rx-2
 29:          2          0          0  332343761   PCI-MSI 524292-edge      enp1s0f0-rx-3
 30:          2          0  503810318          0   PCI-MSI 524293-edge      enp1s0f0-tx-0
 31:          2  632697195          0          0   PCI-MSI 524294-edge      enp1s0f0-tx-1
 32:  568941065          0          0          0   PCI-MSI 524295-edge      enp1s0f0-tx-2
 33:          2          0          0  610190740   PCI-MSI 524296-edge      enp1s0f0-tx-3
 34:          0          0          0          0   PCI-MSI 327680-edge      xhci_hcd
 35:      30998          0          0          0   PCI-MSI 376832-edge      ahci[0000:00:17.0]
 36:          1          0          0          0   PCI-MSI 526336-edge      enp1s0f1
 37:          2   91729771          0          0   PCI-MSI 526337-edge      enp1s0f1-rx-0
 38:   85566388          0          0          0   PCI-MSI 526338-edge      enp1s0f1-rx-1
 39:          2          0          0   81042615   PCI-MSI 526339-edge      enp1s0f1-rx-2
 40:          2          0   93399072          0   PCI-MSI 526340-edge      enp1s0f1-rx-3
 41:          2   51965963          0          0   PCI-MSI 526341-edge      enp1s0f1-tx-0
 42:   51814256          0          0          0   PCI-MSI 526342-edge      enp1s0f1-tx-1
 43:          2          0          0   58165807   PCI-MSI 526343-edge      enp1s0f1-tx-2
 44:          2          0   55823007          0   PCI-MSI 526344-edge      enp1s0f1-tx-3

Oct 24 21:11:05  kernel: [    0.720422] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.4.0-k
Oct 24 21:11:05  kernel: [    0.720586] igb: Copyright (c) 2007-2014 Intel Corporation.
Oct 24 21:11:05  kernel: [    0.765113] igb 0000:01:00.0: added PHC on eth0
Oct 24 21:11:05  kernel: [    0.765248] igb 0000:01:00.0: Intel(R) Gigabit Ethernet Network Connection
Oct 24 21:11:05  kernel: [    0.765391] igb 0000:01:00.0: eth0: (PCIe:5.0Gb/s:Width x4) f4:ce:46:a6:57:38
Oct 24 21:11:05  kernel: [    0.765530] igb 0000:01:00.0: eth0: PBA No: Unknown
Oct 24 21:11:05  kernel: [    0.765671] igb 0000:01:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)
Oct 24 21:11:05  kernel: [    0.809537] igb 0000:01:00.1: added PHC on eth1
Oct 24 21:11:05  kernel: [    0.809759] igb 0000:01:00.1: Intel(R) Gigabit Ethernet Network Connection
Oct 24 21:11:05  kernel: [    0.810002] igb 0000:01:00.1: eth1: (PCIe:5.0Gb/s:Width x4) f4:ce:46:a6:57:39
Oct 24 21:11:05  kernel: [    0.810241] igb 0000:01:00.1: eth1: PBA No: Unknown
Oct 24 21:11:05  kernel: [    0.810415] igb 0000:01:00.1: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)
Oct 24 21:11:05  kernel: [    0.853916] igb 0000:01:00.2: added PHC on eth2
Oct 24 21:11:05  kernel: [    0.854120] igb 0000:01:00.2: Intel(R) Gigabit Ethernet Network Connection
Oct 24 21:11:05  kernel: [    0.854319] igb 0000:01:00.2: eth2: (PCIe:5.0Gb/s:Width x4) f4:ce:46:a6:57:3a
Oct 24 21:11:05  kernel: [    0.854534] igb 0000:01:00.2: eth2: PBA No: Unknown
Oct 24 21:11:05  kernel: [    0.854732] igb 0000:01:00.2: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)
Oct 24 21:11:05  kernel: [    0.898870] igb 0000:01:00.3: added PHC on eth3
Oct 24 21:11:05  kernel: [    0.899047] igb 0000:01:00.3: Intel(R) Gigabit Ethernet Network Connection
Oct 24 21:11:05  kernel: [    0.899262] igb 0000:01:00.3: eth3: (PCIe:5.0Gb/s:Width x4) f4:ce:46:a6:57:3b
Oct 24 21:11:05  kernel: [    0.899458] igb 0000:01:00.3: eth3: PBA No: Unknown
Oct 24 21:11:05  kernel: [    0.899652] igb 0000:01:00.3: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)
Oct 24 21:11:05  kernel: [    0.901747] igb 0000:01:00.2 enp1s0f2: renamed from eth2
Oct 24 21:11:05  kernel: [    0.939336] igb 0000:01:00.1 enp1s0f1: renamed from eth1
Oct 24 21:11:05  kernel: [    0.963379] igb 0000:01:00.3 enp1s0f3: renamed from eth3
Oct 24 21:11:05  kernel: [    1.023273] igb 0000:01:00.0 enp1s0f0: renamed from eth0
Oct 24 21:11:09  kernel: [    5.247550] igb 0000:01:00.0 enp1s0f0: igb: enp1s0f0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Oct 24 21:11:09  kernel: [    5.315550] igb 0000:01:00.1 enp1s0f1: igb: enp1s0f1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

 

В сети читал что если NAT происходит на пул адресов, то нужно все эти ip вешать алиасами куда-то для меньшей нагрузки на проц. Так ли это? Сейчас и без это работает.

Відредаговано 2017-10-25 09:58:35 fet4

[KaYot 3 710]

Ничего не надо вешать.

НАТ может работать или на адресах висящих на интерфейсе, или на подсети смаршрутизированной на этот сервер другим роутера, обычно BGP-бордером.

Разницы в производительности в принципе быть не может, но второй вариант проще и правильнее.

[Ромка 567]

Ничего не надо вешать.

НАТ может работать или на адресах висящих на интерфейсе, или на подсети смаршрутизированной на этот сервер другим роутера, обычно BGP-бордером.

Разницы в производительности в принципе быть не может, но второй вариант проще и правильнее.

А если брас одновременно и бордер, то где-то же нужно всё таки адреса терминировать...

Обычно на lo это делаю...

Відредаговано 2017-10-25 23:09:21 Ромка

[KaYot 3 710]

нужно всё таки адреса терминировать

Вовсе не обязательно.

Весь блок IP уже смаршрутизирован на ваш бордер аплинкером, а может сервер работать без прописанных адресов или нет - сугубо ограничение софта и вашей конфигурации.

[fet4 46]

 

нужно всё таки адреса терминировать

Вовсе не обязательно.

Весь блок IP уже смаршрутизирован на ваш бордер аплинкером, а может сервер работать без прописанных адресов или нет - сугубо ограничение софта и вашей конфигурации.

 

 

Допустим аплинкер смаршрутизировал блок 192.168.1.0/24 на 192.168.0.1, на 192.168.0.1 натится этот блок.

-A POSTROUTING -o vlan2000 -j SNAT --to-source 192.168.1.1-192.168.1.254 --persistent 

Как аплинкер понимает что сначеный блок прилетает именно от 192.168.0.1 если весь трафик с интерфейса натится в блок ? Или где-то в пакете есть адрес маршрутизатора ?

[sv-lex 38]

Аплинк знает что для всей сети 192.168.1.0/24 следующий хоп  192.168.0.1. Ему не важно что там дальше будет с маршрутизацией трафика, будет на след хопе NAT или часть адресов смаршрутизируется еще куда-то. Его задача передать пакет на next hop согласно собственной таблице маршрутизации. 

[KaYot 3 710]

Как аплинкер понимает что сначеный блок прилетает именно от 192.168.0.1 если весь трафик с интерфейса натится в блок ?

Для вашего аплинкера нет разницы, после НАТа этот пакет или нет. Для него есть только ваш блок IP(192.168.1.0/24) и адрес куда его маршрутизировать(192.168.0.1).

 

Больше ему действительно ничего знать не нужно, требование вешать NAT-адреса на интерфейс не более чем костыль для кривых систем, в windows 2003 такое требование видел в последний раз. Может еще микротику какому нужно.

[fet4 46]

Чего боялся то и произошло. nf_conntrack_tuple_taken снова вылез в 100% загрузки нового проца. На брасе все окей никаких аномалий не видно.

Даже не знаю уже что и думать. Может ядро обновить/откатить?

[911 140]

может быть это из-за балансировки трафика?

[KaYot 3 710]

Попробуйте таки ядро обновить, похоже на какие-то косяки новой ветки 4.9.

[fet4 46]

Все оказалось гораздо проще.

Сравнив показания conntrack -C на бордере и брасе, разница была огромна примерно 300 000/30 000 соответственно в тот момент, я понял что нужно искать проблему где-то в транзите.

Т.к. фаервол был не дописан, ограничив на бордере FORWARD исключительно клиентам, сразу же количество conntrack -C выровнялось. Вот уже 3-ий день все тихо.

:FORWARD DROP [24852758:1686709141]
:forward_new - [0:0]
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -p tcp -m set --match-set blacklist dst -j REJECT --reject-with tcp-reset
-A FORWARD -m set --match-set blacklist dst -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m conntrack --ctstate NEW -j forward_new
-A forward_new -i vlan10 -m set --match-set ip_pools src -j ACCEPT
-A forward_new -o vlan10 -m set --match-set ip_pools dst -j ACCEPT

[Sоrk 48]

В 15.10.2017 в 13:44, Sоrk сказал:

 

в процессе тестов, но боевую нагрузку не запускали, жду релиза 17.10

из того с чем столкнулся:

* в режиме CGNAT поддерживается только TCP, UDP, ICMP (тот же GRE уже не работает), возможно не всем актуально

* в режиме nat44 нет возможности указать отдельному пулу внутренних адресов пул внешних, это можно в CGNAT, но там нет поддержки GRE

* нет никаких ALG для FTP, PPTP в nat44 (в версии 17.10 обещают доделать нормальную поддержку GRE в режиме nat44, возможно заработает без ALG)

* очень странный концепт того что можно всё настроить из CLI, но сохранить текущий конфиг нельзя, приходится писать и в CLI и в файл из скриптов одновременно

* так и не смог заставить IPFIX из VPP нормально отображаться в NFSEN, но в 17.10 обещают логи НАТа в syslog

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

 

так что решение как бы и хорошее, но требует смелости и энтузиазма

 

если кому-то интересно, то есть результаты попытки запустить NAT на VPP 18.10.

пробовал режим nat44 - неудачно:

- из-за невозможности привязать пул к внешнему IP пользователи постоянно получают разный IP (по мере использования портов).

- PPTP VPN, FTP так и не работает через nat44

- и самое главное - постоянно падает под нагрузкой ~ 5-6 Gbit/s