Jump to content
Как правильно добавить self-test и прочую отладку в тему
Где взять тестовые сборки
  • 0

зачем вы загоняете в conttrack весь локальный трафик?

umka

Asked by umka,

 Share

Question

umka Member

umka

Posted
Posted

Поставил 2.07 бету из официалной, ушла проблема с запуском opkg, но остался вопрос - зачем вы загоняете в conttrack весь локальный трафик? ладно бы из локалки наружу - а так между клиентами в локалке, только лишний CPU тратить..

Link to comment
Share on other sites

14 answers to this question

Recommended Posts

  • 0
ndm Honored Flooder

ndm

Posted
Posted
Поставил 2.07 бету из официалной, ушла проблема с запуском opkg, но остался вопрос - зачем вы загоняете в conttrack весь локальный трафик? ладно бы из локалки наружу - а так между клиентами в локалке, только лишний CPU тратить..
В conntrack попадает весь транзитный L3 трафик, но между хостами в локалке L2. Поясните, пожалуйста, с примером, что загоняется конкретно.
Link to comment
Share on other sites
  • 0
umka Member

umka

Posted
  • Author
Posted
Поставил 2.07 бету из официалной, ушла проблема с запуском opkg, но остался вопрос - зачем вы загоняете в conttrack весь локальный трафик? ладно бы из локалки наружу - а так между клиентами в локалке, только лишний CPU тратить..
В conntrack попадает весь транзитный L3 трафик, но между хостами в локалке L2. Поясните, пожалуйста, с примером, что загоняется конкретно.

как минимум там трафик к самой точке, мультикаст из локалки, и был трафик от NAS подключенного по зернету (сейчас нету, но видел)

root@Keenetic_Giga:/opt/root# grep src=192.168.1. /proc/net/nf_conntrack | grep dst=192.168

ipv4 2 udp 17 16 src=192.168.1.36 dst=192.168.1.1 sport=57476 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=57476 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 12 src=192.168.1.36 dst=192.168.1.1 sport=57458 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=57458 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 14 src=192.168.1.36 dst=192.168.1.1 sport=52105 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=52105 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 431 src=192.168.1.36 dst=224.0.0.2 [uNREPLIED] src=224.0.0.2 dst=192.168.1.36 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 582 src=192.168.1.2 dst=224.0.0.22 [uNREPLIED] src=224.0.0.22 dst=192.168.1.2 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 4 src=192.168.1.36 dst=192.168.1.1 sport=55056 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=55056 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 28 src=192.168.1.36 dst=192.168.1.1 sport=50030 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=50030 mark=0 nfm_marker = 0 use=2

ipv4 2 tcp 6 1199 ESTABLISHED src=192.168.1.34 dst=192.168.1.1 sport=50850 dport=22 src=192.168.1.1 dst=192.168.1.34 sport=22 dport=50850 [ASSURED] mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 20 src=192.168.1.36 dst=192.168.1.1 sport=50763 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=50763 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 20 src=192.168.1.36 dst=192.168.1.1 sport=57699 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=57699 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 10 src=192.168.1.34 dst=192.168.1.1 sport=58345 dport=53 src=192.168.1.1 dst=192.168.1.34 sport=53 dport=58345 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 12 src=192.168.1.33 dst=192.168.1.1 sport=57291 dport=53 src=192.168.1.1 dst=192.168.1.33 sport=53 dport=57291 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 9 src=192.168.1.1 dst=192.168.1.255 sport=138 dport=138 [uNREPLIED] src=192.168.1.255 dst=192.168.1.1 sport=138 dport=138 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 3 src=192.168.1.36 dst=192.168.1.1 sport=49447 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=49447 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 11 src=192.168.1.36 dst=192.168.1.1 sport=54243 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=54243 mark=0 nfm_marker = 0 use=2

скорее всего в конфете ядра забыто проверять локальный трафик. А это потребление памяти - которого можно избежать без потери функциональности.

Link to comment
Share on other sites
  • 0
Le ecureuil Honored Flooder

Le ecureuil

Posted
Posted
Поставил 2.07 бету из официалной, ушла проблема с запуском opkg, но остался вопрос - зачем вы загоняете в conttrack весь локальный трафик? ладно бы из локалки наружу - а так между клиентами в локалке, только лишний CPU тратить..
В conntrack попадает весь транзитный L3 трафик, но между хостами в локалке L2. Поясните, пожалуйста, с примером, что загоняется конкретно.

как минимум там трафик к самой точке, мультикаст из локалки, и был трафик от NAS подключенного по зернету (сейчас нету, но видел)

root@Keenetic_Giga:/opt/root# grep src=192.168.1. /proc/net/nf_conntrack | grep dst=192.168

ipv4 2 udp 17 16 src=192.168.1.36 dst=192.168.1.1 sport=57476 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=57476 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 12 src=192.168.1.36 dst=192.168.1.1 sport=57458 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=57458 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 14 src=192.168.1.36 dst=192.168.1.1 sport=52105 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=52105 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 431 src=192.168.1.36 dst=224.0.0.2 [uNREPLIED] src=224.0.0.2 dst=192.168.1.36 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 582 src=192.168.1.2 dst=224.0.0.22 [uNREPLIED] src=224.0.0.22 dst=192.168.1.2 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 4 src=192.168.1.36 dst=192.168.1.1 sport=55056 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=55056 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 28 src=192.168.1.36 dst=192.168.1.1 sport=50030 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=50030 mark=0 nfm_marker = 0 use=2

ipv4 2 tcp 6 1199 ESTABLISHED src=192.168.1.34 dst=192.168.1.1 sport=50850 dport=22 src=192.168.1.1 dst=192.168.1.34 sport=22 dport=50850 [ASSURED] mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 20 src=192.168.1.36 dst=192.168.1.1 sport=50763 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=50763 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 20 src=192.168.1.36 dst=192.168.1.1 sport=57699 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=57699 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 10 src=192.168.1.34 dst=192.168.1.1 sport=58345 dport=53 src=192.168.1.1 dst=192.168.1.34 sport=53 dport=58345 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 12 src=192.168.1.33 dst=192.168.1.1 sport=57291 dport=53 src=192.168.1.1 dst=192.168.1.33 sport=53 dport=57291 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 9 src=192.168.1.1 dst=192.168.1.255 sport=138 dport=138 [uNREPLIED] src=192.168.1.255 dst=192.168.1.1 sport=138 dport=138 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 3 src=192.168.1.36 dst=192.168.1.1 sport=49447 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=49447 mark=0 nfm_marker = 0 use=2

ipv4 2 udp 17 11 src=192.168.1.36 dst=192.168.1.1 sport=54243 dport=53 src=192.168.1.1 dst=192.168.1.36 sport=53 dport=54243 mark=0 nfm_marker = 0 use=2

скорее всего в конфете ядра забыто проверять локальный трафик. А это потребление памяти - которого можно избежать без потери функциональности.

В этом нет ничего страшного, и это необходимо для работы ip hotspot.

Link to comment
Share on other sites
  • 0
Padavan Honored Flooder

Padavan

Posted
Posted

Никто специально локальный трафик не загоняет в conntrack, так работает Linux.

Предвидя вопрос - "а как-же NOTRACK", отвечу - никакого профита на локальном трафике от NOTRACK нет, только лишние хуки в RAW таблице iptables. И лишние проблемы, если требуется сNAT-тить что-то для локального трафика (например сменить внешний порт на внутренний).

Сейчас в 2.07 на девайсах с 64 и 128МБ RAM установлен лимит в 8K соединений, на 256МБ - 16K соединений. Если вы обновляли прошивку поверх, лимиты могли остаться старые, но выставятся по умолчанию после сброса настроек. Либо если сами добавите руками в конфигурацию требуемый лимит, например

set net.netfilter.nf_conntrack_max 16384

Link to comment
Share on other sites
  • 0
umka Member

umka

Posted
  • Author
Posted
Никто специально локальный трафик не загоняет в conntrack, так работает Linux.

Предвидя вопрос - "а как-же NOTRACK", отвечу - никакого профита на локальном трафике от NOTRACK нет, только лишние хуки в RAW таблице iptables. И лишние проблемы, если требуется сNAT-тить что-то для локального трафика (например сменить внешний порт на внутренний).

Сейчас в 2.07 на девайсах с 64 и 128МБ RAM установлен лимит в 8K соединений, на 256МБ - 16K соединений. Если вы обновляли прошивку поверх, лимиты могли остаться старые, но выставятся по умолчанию после сброса настроек. Либо если сами добавите руками в конфигурацию требуемый лимит, например

set net.netfilter.nf_conntrack_max 16384

вопрос больше не к памяти. 16к соединений много - но к примеру один торрент на NAS + 2 ноута в держат 2k соединений на роутере. То есть роутер даже в этих настройках потянет с десяток клиентов - не более.

Сколько больше вопрос к CPU. Текущие настройки будут вынуждать прогонять весь мультикаст/броадкаст/мултикаст прокси через все iptables input правила. Пока трафик не большой - это ладно, а с ростом - получим съедание CPU. Достаточно лишь 4-5 клиентам начать смотреть видео через igmp proxy.

К примеру - сейчас копирование файла с wifi на eth - съедает 30-32% в ksoftirqd (точнее не скажу - perf отсутствует в репозитории).

А это время от iptables в том числе.

Link to comment
Share on other sites
  • 0
zyxmon Honored Flooder

zyxmon

Posted
Posted
....точнее не скажу - perf отсутствует в репозитории....

Есть iperf

opkg list iperf*
iperf - 2.0.5-1 - Iperf is a modern alternative for measuring TCP and UDP bandwidth
performance, allowing the tuning of various parameters and
characteristics.
This package is built with single thread support.
iperf-mt - 2.0.5-1 - Iperf is a modern alternative for measuring TCP and UDP bandwidth
performance, allowing the tuning of various parameters and
characteristics.
This package is built with multithread support.

Link to comment
Share on other sites
  • 0
umka Member

umka

Posted
  • Author
Posted
....точнее не скажу - perf отсутствует в репозитории....

Есть iperf

opkg list iperf*
iperf - 2.0.5-1 - Iperf is a modern alternative for measuring TCP and UDP bandwidth
performance, allowing the tuning of various parameters and
characteristics.
This package is built with single thread support.
iperf-mt - 2.0.5-1 - Iperf is a modern alternative for measuring TCP and UDP bandwidth
performance, allowing the tuning of various parameters and
characteristics.
This package is built with multithread support.

iperf и perf это 2 очень большие разницы.

iperf служит для тестирования сетевых соединений. perf служит для анализа производительности ядра linux.

имелось ввиду второй.

https://perf.wiki.kernel.org/index.php/Main_Page

к слову

root@Keenetic_Giga:/opt/root# opkg update

Downloading http://opkg.keenopt.ru/all/Packages.gz.

Inflating http://opkg.keenopt.ru/all/Packages.gz.

Updated list of available packages in /opt/var/opkg-lists/all.

Downloading http://opkg.keenopt.ru/mipsel/Packages.gz.

Inflating http://opkg.keenopt.ru/mipsel/Packages.gz.

Updated list of available packages in /opt/var/opkg-lists/mipsel.

Downloading http://opkg.keenopt.ru/kng_re/Packages.gz.

Inflating http://opkg.keenopt.ru/kng_re/Packages.gz.

Updated list of available packages in /opt/var/opkg-lists/kng_re.

root@Keenetic_Giga:/opt/root# opkg list | grep perf

root@Keenetic_Giga:/opt/root# opkg list iperf*

root@Keenetic_Giga:/opt/root#

этого тоже нету... понятно что можно подтянуть что-то из openwrt .. но..

Link to comment
Share on other sites
  • 0
Le ecureuil Honored Flooder

Le ecureuil

Posted
Posted
Никто специально локальный трафик не загоняет в conntrack, так работает Linux.

Предвидя вопрос - "а как-же NOTRACK", отвечу - никакого профита на локальном трафике от NOTRACK нет, только лишние хуки в RAW таблице iptables. И лишние проблемы, если требуется сNAT-тить что-то для локального трафика (например сменить внешний порт на внутренний).

Сейчас в 2.07 на девайсах с 64 и 128МБ RAM установлен лимит в 8K соединений, на 256МБ - 16K соединений. Если вы обновляли прошивку поверх, лимиты могли остаться старые, но выставятся по умолчанию после сброса настроек. Либо если сами добавите руками в конфигурацию требуемый лимит, например

set net.netfilter.nf_conntrack_max 16384

вопрос больше не к памяти. 16к соединений много - но к примеру один торрент на NAS + 2 ноута в держат 2k соединений на роутере. То есть роутер даже в этих настройках потянет с десяток клиентов - не более.

Сколько больше вопрос к CPU. Текущие настройки будут вынуждать прогонять весь мультикаст/броадкаст/мултикаст прокси через все iptables input правила. Пока трафик не большой - это ладно, а с ростом - получим съедание CPU. Достаточно лишь 4-5 клиентам начать смотреть видео через igmp proxy.

К примеру - сейчас копирование файла с wifi на eth - съедает 30-32% в ksoftirqd (точнее не скажу - perf отсутствует в репозитории).

А это время от iptables в том числе.

Вообще-то у вас какая-то каша в голове.

Во-первых, 2к соединений на хост это _ОЧЕНЬ_ много, говорить что десяток клиентов и все - это совершенное безумие. У вас на всех 10 клиентах запущен торрент с огромным числом раздач и пиров?

Во-вторых, для multicast есть отдельный ускоритель, и пакеты с видео не идут через netfilter.

В-третьих, при копировании с WiFi на Eth ЦПУ сильно грузится именно из-за полусофтовой реализации WiFi в драйверах, и мы плавно работаем над улучшением ситуации. iptables тут погоды не делает.

В-четвертых не путайте iptables, netfilter и conntrack. Это разные вещи, они вступают в действие на разных этапах обработки пакетов и несут на себе разную нагрузку. Отключать conntrack на роутере - это стрельба из пушек по воробьям.

Link to comment
Share on other sites
  • 0
umka Member

umka

Posted
  • Author
Posted

Вообще-то у вас какая-то каша в голове.

Во-первых, 2к соединений на хост это _ОЧЕНЬ_ много, говорить что десяток клиентов и все - это совершенное безумие. У вас на всех 10 клиентах запущен торрент с огромным числом раздач и пиров?

это копейки. Простейший тест вам покажет что для загрузки одной странички с картинками любого сайта - надо 50-70 соединений.

запустите скрипт

$ while [ 1 ]; do lsof -n -i TCP | grep -v '*:*' | wc -l; lsof -n -i UDP | grep -v '*:*' | wc -l; sleep 0.5; done

и походите по страничкам. news.yandex.ru дает 40 конектов, newsru.com - дает 80,

открыл 3 страницы подряд - получил 120 конектов, открыл 4ю - получил 150... Открыл одноклассники еще прыжок на 120 соединений. И того активных 500 соединений, просто так. Дальше начинаем вспоминать что большинство браузеров не закрывают сразу сокеты и держат "а вдруг еще что-то потребуется". Это без всяких торрентов замечу.

У вас и ваших клиентов точно только одна вкладка открыта и они открывают странички раз в минуту/две? Они никогда не ходят по соц сетям, и пользуются только страницами со статическим HTML? Они никогда не сохраняли открытыми вкладки - в которых иногда включено автообновление?

Что там говорилось о безумии?..

Во-вторых, для multicast есть отдельный ускоритель, и пакеты с видео не идут через netfilter.

Точно?

ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2

224.0.0.0 является сетью для muticast если верить RFC. видимо у нас с вами разные multicast.

В-третьих, при копировании с WiFi на Eth ЦПУ сильно грузится именно из-за полусофтовой реализации WiFi в драйверах, и мы плавно работаем над улучшением ситуации. iptables тут погоды не делает.

Вы не пытались проанализировать контекст выполнения всех этих операций? Linux kernel так и не научился обрабатывать пакеты в параллель, во всяком случае не в той версии ядра что у вас используется. Как раз таки по этому наличие второго CPU на этой железке никого не спасет.

И как раз таки по этому

В-четвертых не путайте iptables, netfilter и conntrack. Это разные вещи, они вступают в действие на разных этапах обработки пакетов и несут на себе разную нагрузку. Отключать conntrack на роутере - это стрельба из пушек по воробьям.

ЭЭ.. вы не пытались систематизировать свои знания? iptables это утилита управления.

Подсистема в ядре давно называется NetFilter, в данной подсистеме есть 2 части. xtables, и conntrack.

В этом легко убедится если глянуть в конфигурацию ядра

config NF_CONNTRACK

tristate "Netfilter connection tracking support"

и

config NETFILTER_XTABLES

tristate "Netfilter Xtables support (required for ip_tables)"

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

PS. мое желание было лишь вам подсказать что можно исправить что бы сделать продукт лучше, но не смею навязывать вам свои знания. Видимо проще дождаться пока поддержка этого железа будет в openwrt и перейти туда. или просто убрать все ваши правила - и поставить свои. К сожалению создание собственных ядер для этой железки будет отложено пока не появится openwrt.

Link to comment
Share on other sites
  • 0
Le ecureuil Honored Flooder

Le ecureuil

Posted
Posted

Вообще-то у вас какая-то каша в голове.

Во-первых, 2к соединений на хост это _ОЧЕНЬ_ много, говорить что десяток клиентов и все - это совершенное безумие. У вас на всех 10 клиентах запущен торрент с огромным числом раздач и пиров?

это копейки. Простейший тест вам покажет что для загрузки одной странички с картинками любого сайта - надо 50-70 соединений.

запустите скрипт

$ while [ 1 ]; do lsof -n -i TCP | grep -v '*:*' | wc -l; lsof -n -i UDP | grep -v '*:*' | wc -l; sleep 0.5; done

и походите по страничкам. news.yandex.ru дает 40 конектов, newsru.com - дает 80,

открыл 3 страницы подряд - получил 120 конектов, открыл 4ю - получил 150... Открыл одноклассники еще прыжок на 120 соединений. И того активных 500 соединений, просто так. Дальше начинаем вспоминать что большинство браузеров не закрывают сразу сокеты и держат "а вдруг еще что-то потребуется". Это без всяких торрентов замечу.

Это в случае использования http/1.0, которые плюс ко всему сразу же закрываются, а не висят постоянно.

А вслучае использования http/1.1 к каждому из серверов создается одно отдельное перманентное соединение, а никак не 500.

Link to comment
Share on other sites
  • 0
Le ecureuil Honored Flooder

Le ecureuil

Posted
Posted

Во-вторых, для multicast есть отдельный ускоритель, и пакеты с видео не идут через netfilter.

Точно?

ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2

ipv4 2 unknown 2 575 src=192.168.1.1 dst=224.0.0.1 [uNREPLIED] src=224.0.0.1 dst=192.168.1.1 mark=0 nfm_marker = 0 use=2

224.0.0.0 является сетью для muticast если верить RFC. видимо у нас с вами разные multicast.

То, что это мультикастные адреса, не делает их автоматически используемыми для передачи video-трафика.

Этот адрес - 224.0.0.1 - вообще-то означает "Все хосты", и скорее всего используется для сигнализации mDNS, Zeroconf или miniDLNA.

Link to comment
Share on other sites
  • 0
Le ecureuil Honored Flooder

Le ecureuil

Posted
Posted

В-третьих, при копировании с WiFi на Eth ЦПУ сильно грузится именно из-за полусофтовой реализации WiFi в драйверах, и мы плавно работаем над улучшением ситуации. iptables тут погоды не делает.

Вы не пытались проанализировать контекст выполнения всех этих операций? Linux kernel так и не научился обрабатывать пакеты в параллель, во всяком случае не в той версии ядра что у вас используется. Как раз таки по этому наличие второго CPU на этой железке никого не спасет.

Пакеты в параллель обрабатываются на ура, в 3.4 уже есть RPS.

Тут дело именно в драйвере WiFi от Mediatek.

Если вы реально умеете анализировать контексты и профилировать драйверы, то почему вам не прийти бы к нам на работу, вместо бестолкового флуда на форуме?

Link to comment
Share on other sites
  • 0
Le ecureuil Honored Flooder

Le ecureuil

Posted
Posted

В-четвертых не путайте iptables, netfilter и conntrack. Это разные вещи, они вступают в действие на разных этапах обработки пакетов и несут на себе разную нагрузку. Отключать conntrack на роутере - это стрельба из пушек по воробьям.

ЭЭ.. вы не пытались систематизировать свои знания? iptables это утилита управления.

Подсистема в ядре давно называется NetFilter, в данной подсистеме есть 2 части. xtables, и conntrack.

В этом легко убедится если глянуть в конфигурацию ядра

config NF_CONNTRACK

tristate "Netfilter connection tracking support"

и

config NETFILTER_XTABLES

tristate "Netfilter Xtables support (required for ip_tables)"

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

Я смотрел не только в конфигурацию, но в и код, и не только смотрел, но и писал (ц)

Потому мне не нужно рассказывать как там что устроено.

Последний профайлинг был сделан в начале июня, и дал некоторое улучшение.

А вообще мы не гонимся именно за суперпроизводительностью netfilter, поскольку у нас есть огромный арсенал средств программного и аппаратного ускорения трафика, который постоянно пополняется.

Еще вопросы?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to question listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...