ANAT (Advanced asymmetric CG NAT) xt_ANAT module ядра для Linux

[sdy_moscow]

20 минут назад, dryukov сказал:

Так оно и так реализовано сборка и разборка.

The nf_defrag_ipv4 module will defragment IPv4 packets before they reach Netfilter's connection tracking (nf_conntrack_ipv4 module).

Я не уверен, что он будет работать с ANAT. По верхам посмотрел - специфическая вещь ну и главное - сильное падение производительности будет. У меня есть гораздо более продуктивная идея. Единственное будет требование - первый фрагмент должен прийти первым.

[sdy_moscow]

1 час назад, dryukov сказал:

Это требование не выполнимо. Первый может и потеряться, потому что вообще не пролез )))

...

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

И еще раз - я тоже считаю, что фрагментированный трафик - ЗЛО. Но если будет задача его пропустить через CGNAT (ANAT), то как "красиво" сделать это - я представляю.

[sdy_moscow]

5 часов назад, dryukov сказал:

Цензура видения заработала, понятно. Успехов тогда только пожелать.

Не Цензура. Просто, эта тема про конкретный софт - ANAT. Есть код, который всем доступен к изучению.  Автор ветки и ANAT  - я. Поэтому, и модерирую эту ветку - я.

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

 

Я готов отвечать на вопросы тут, но пускаться в длительные дискуссии - давайте в отдельных ветках или в личке.

Итак, Вы стали писать, как бы оно "должно-могло" по вашему мнению работать  с nf_defrag_ipv4. Как я уже написал, я посмотрел и не уверен, что ANAT  вообще заработает с nf_defrag_ipv4 . Если Вы настроите подобную работу на стенде, проверите и пришлете конфигурацию "в студию", я с удовольствием и благодарностью приму и обсужу этот вариант.

Что касательно отправки / не отправки ICMP -  никто не мешает написать правила в файрволе (iptables) с REJECT и отправкой ЛЮБЫХ нужных сообщений отправителю фрагментированных пакетов ДО передачи их в ANAT. Полезные ответы по этой теме - в Яндексе и Гугле. Есть рабочие конфиги - пишите!

[dryukov]

Ага и опцию с размером MTU казать, чтобы сервер знал каким размером ему следующую попытку делать.
-J REJECT fragmentation-needed mtu=1492

[AKim]

Найдено в чатах, но не тестил.

Цитата

Совместно с nft flowtable работает nat фрагментация ip, т.к. последующие пакеты проходят уже в обхоб xt_NAT

 

# Warning: table ip raw is managed by iptables-nft, do not touch!
table ip raw {
  chain PREROUTING {
    type filter hook prerouting priority raw; policy accept;
    ip saddr 100.64.0.0/18 counter packets 22 bytes 1442 notrack
    ip saddr 172.16.0.0/12 counter packets 5 bytes 160 notrack
    ip saddr xxx.xxx.xxx.64/28 counter packets 0 bytes 0 notrack
    ip daddr xxx.xxx.xxx.64/28 counter packets 4499 bytes 203092 xt target "NAT"
  }
}
# Warning: table ip filter is managed by iptables-nft, do not touch!
table ip filter {
  chain FORWARD {
    type filter hook forward priority filter; policy accept;
    ip daddr 100.64.0.0/18 counter packets 20 bytes 18072 accept
    ip daddr 172.16.0.0/12 counter packets 0 bytes 0 accept
    ip saddr 100.64.0.0/18 counter packets 22 bytes 1442 xt target "NAT"
    ip saddr 172.16.0.0/12 counter packets 0 bytes 0 xt target "NAT"
  }
}
table inet f {
  flowtable flowoffload {
    hook ingress priority filter
    devices = { enp66s0 }
  }

  chain forward {
    type filter hook forward priority filter; policy accept;
    ip protocol { tcp, udp } flow add @flowoffload
  }
}

 

Цитата

первые две таблицы добавляются iptables-nft, последняя просто с nft

 

[sdy_moscow]

 

Всем привет.

 

Тут на днях мне задали довольно интересный вопрос, по управлению таймаутами сессий в ANAT. Поскольку тема интересная, я продублирую ответ здесь:

 

Задали такой вопрос:

Скрытый текст

Доброго времени суток.

В ANAT  можно пофиксить ttl на udp соединения? В конфиге такого нет. Это нужно на уровне исходников делать.

Наблюдение:

Один тестовый ПК открывает пару страниц:

---

root@XXX:/home/XXX# cat /proc/net/ANAT/sessions | grep tcp | wc -l
17
root@XXX:/home/XXX# cat /proc/net/ANAT/sessions | grep 8.8.8.8 | wc -l
33
total 50.

---

Получается 34%  tcp и 66% udp dns
66% коннектов на dns с ttl 300. Это дичайший перерасход портов на ровном месте. Почему не выставить ttl для UDP на 10 sec ?

Я действительно не могу смириться, что для работы этого ната нужно такое количество  ip адресов и думаю что его можно оптимизировать на коннектах лучше.

Тут единственное Established можно держать 300, для остального 5-10.

 

 

Вот ответ и совет тем, кто хочет попробовать решить данную проблему сейчас "малой кровью":

Скрытый текст

Введение:

Учет TTL сессий несколько не банален в коде ANAT и привязан к проходу итератором в таймере по хэш таблицам ЧАСТЯМИ, одна запись проходится раз в 10 сек, но не с момента начала сессии, а общим циклом.

 

Конечно, изменить в исходниках можно ВСЁ, но если захочется чего-то более сложного, чем будет сказано ниже, то придется разобраться в механизме счета TTL и возможно поменять что-то не банальное (например, частоту вызова обработчиков и их синхронизацию). 

 

Я не знаю какой TTL будет оптимальным, поэтому, если хочется попробовать, то сперва можно модифицировать код всего в 2-х - 3-х местах и достаточно просто.

 

Как хранится и меняется таймаут сессии:

Таймаут TTL хранится в переменой tmt сессии, как величина *10 сек, но со сдвигом на 50 (константа AXT_TMT_SSTMT_SHS). Т.е. значение tmt = 52, означает, что таймаут сессии истечет через 10-20 секунд. О сдвиге на 50 можно особо не заботиться, в нужных местах всё уже сделано.

По таймеру, примерно раз в 10 секунд, tmt уменьшается на 1 (10 сек), и если его величина станет равной 50, и исходящего трафика не было, то сессия будет удалена.

 

Что можно быстро изменить и как:

1.  Первоначально, всем сессия ставится таймаут = 30 сек [ tmt = (3+50) ], эту величину при желании можно сократить до 20 сек (2+50), но менять здесь что-либо - БЕССМЫСЛЕННО! Т.к. в любом случае, в момент первого-же уменьшения TTL таймером, эта величина будет переустановлена! Как - сказано ниже в п.п.2.

 

Код первой операции находится в файле xt_ANAT_pc_donat.c строка 63:

        l_ses->i.tk.tmt        = ( i_static ? AXT_TMT_SSTMT_STA : (3 + AXT_TMT_SSTMT_SHS) ); //AXT_TMT_SSTMT_STA or 30sec

 

Здесь можно 3 заменить на 2. Еще раз, ставить МЕНЬШЕ Я НЕ СОВЕТУЮ - возможно будут "глюки".  И особого смысла в этом нет.

 

2.  Когда таймер уменьшает TTL на 1, то он проверяет, был ли в этом интервале ИСХОДЯЩИЙ от клиента трафик, и если он был, то таймаут будет вновь взведен: на 30 сек (3) - для всех ICMP сессий, и для других протоколов тоже, но только при условии, что не было входящего трафика к клиенту; на 300 сек (30) -  если был ответ клиенту из интернета хотя-бы 1 раз (был входящий трафик) и это не  ICMP.

 

Код второй операции находится в файле xt_ANAT_pc_htimers.c строка 168:

       l_tmt = ( ((l_flags & AXT_FLAG_REPLIED) && ((l_flags & AXT_FLAG_ITSICMP)==0)) ? 30 : 3 ); //300 sec : 30 sec

 

Здесь можно достаточно смелым попробовать заменить 30 на 6 - это будет 1 минута (прочие протоколы), и 3 на 2 или 1 (для ICMP). Но! В изменении таймаута только для ICMP нет особого смысла, т.к. слоты под сессии ICMP, как правило, "не кончаются". Уменьшать 3 есть смысл, если вы используете рекомендации из п.п.3.  Если очень хочется, то можно 300 секунд (30) и до 30 (3) уменьшить. НО! Я бы не советовал уменьшать значение меньше 13, почему - смотрите замечание про TCP ниже. Еще замечу, что итог сильно зависит от приложений. Обычно, таймауты в них могут достигать около 120-180 сек (2-3 минуты). Решать всегда вам.

 

И КОНЕЧНО! У кого есть силы, опыт и желание! То можно поколдовать со 168 строкой, добавив отдельные условия по UDP и даже по портам, но ПОМНИТЕ - это требует аккуратной отладки, одно неверное движение - и сервер будет просто наглухо виснуть - т.к. это режим ядра. И учтите, этот код будет исполняться ОООООЧЕНЬ часто, так что, если "перестараетесь" - будут проблемы с производительностью.

 

3.  Про UDP DNS и "простое" решение задачи.

Можно обрабатывать TTL быстро "как у ICMP" не только поколдовав со 168 строкой, но и изменив условие установки флага AXT_FLAG_ITSICMP  в файле xt_ANAT_pc_donat.c строка 58:

        l_ses->o.pf.flags   = (i_proto != IPPROTO_ICMP 0 : AXT_FLAG_ITSICMP);  //SDY TODO future (newly - not ready flag)

 

для уменьшения TTL для UDP DNS трафика, измените её на:

        l_ses->o.pf.flags   = ( (i_proto == IPPROTO_ICMP ) || ((i_proto == IPPROTO_UDP ) && ((i_dstport == 53 || i_userport == 53)))  ? AXT_FLAG_ITSICMP : 0 );

 

должно сработать.

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

 

Важное замечание про TCP!

Для TCP сессий изменение таймаутов не столь важно. При корректном закрытии TCP connection сессия сразу помечается как завершенная и удаляется в течении 10 секунд. Однако, если вы сильно уменьшите 30 в п.п.2 - то есть вероятность потери слабоактивных TCP connections. Напомню, минимальное рекомендованное значение tcp_retries2 - 100 секунд. Так что, снижая значение меньше 10 Вы уже реально рискуете рассинхронизацией на мало используемых и нестабильных соединениях. А так,  tcp_retries2 значение может быть аж до 15 минут.... но это конечно перебор.

https://habr.com/ru/articles/700470/

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

 

 

Вывод.

Если вы хотите оптимизировать таймауты и уменьшить TTL для UDP DNS трафика, я бы рекомендовал: в.п.п. 1 заменить 3 на 2 (для профилактики), в п.п.2 заменить 30 на 13 и 3 на 2, внести изменения согласно п.п. 3.

 

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

 

SDY.

 

[Dmitry76]

Понемногу тестирую модуль. Debian 12, используется патч для сборки на 6.х ядрах. В целом, насколько я могу судить, все в норме.

Но раз возникла проблема: по какой-то причине дебиан решил вернуться к классической схеме именования интерфейсов (eth*), а не ID_NET_NAME*. Короче, сеть не поднялась. Рабочие моменты. Бывает.

Только вот модуль начал засыпать лог ядра ошибками:

 

 

xt_ANAT ERROR: Nf9 Send error - kernel_sendmsg(..) return Error: -101 . Socket will be reset!
xt_ANAT DEBUG: Nf9 socket released. i_sock : 00000000fb720e7a.
xt_ANAT ERROR: Nf9 Send error - kernel_sendmsg(..) return Error: -101 . Socket will be reset!
xt_ANAT DEBUG: Nf9 socket released. i_sock : 0000000000eed05e.
xt_ANAT ERROR: Nf9 Send error - kernel_sendmsg(..) return Error: -101 . Socket will be reset!
xt_ANAT DEBUG: Nf9 socket released. i_sock : 000000004c30af42.
xt_ANAT ERROR: Nf9 Send error - kernel_sendmsg(..) return Error: -101 . Socket will be reset!
xt_ANAT DEBUG: Nf9 socket released. i_sock : 00000000a653f864.
xt_ANAT ERROR: Nf9 Send error - kernel_sendmsg(..) return Error: -101 . Socket will be reset!
xt_ANAT DEBUG: Nf9 socket released. i_sock : 000000000eee20bf.
xt_ANAT ERROR: Nf9 Send error - kernel_sendmsg(..) return Error: -101 . Socket will be reset!
xt_ANAT DEBUG: Nf9 socket released. i_sock : 000000004b8a93cc.
xt_ANAT ERROR: Nf9 Send error - kernel_sendmsg(..) return Error: -101 . Socket will be reset!
xt_ANAT DEBUG: Nf9 socket released. i_sock : 00000000fff0b733.
xt_ANAT ERROR: Nf9 Send error - kernel_sendmsg(..) return Error: -101 . Socket will be reset!
xt_ANAT DEBUG: Nf9 socket released. i_sock : 00000000969ecfd3.
xt_ANAT ERROR: Nf9 Send error - kernel_sendmsg(..) return Error: -101 . Socket will be reset!
xt_ANAT DEBUG: Nf9 socket released. i_sock : 00000000b2f4c31e.
xt_ANAT ERROR: Nf9 Send error - kernel_sendmsg(..) return Error: -101 . Socket will be reset!
xt_ANAT DEBUG: Nf9 socket released. i_sock : 000000000233e3b5.

 

За минуту-другую размер лога распух до 4 гигов и  скоро партиция логов забилась. Что посоветуете на будущее, если вдруг будут возникать сетевые проблемы? В документации не вижу как выключить подобного рода сообщения.

 

[sdy_moscow]

@Dmitry76

Рекомендации простые:

1. Не допускать глюков на рабочих серверах.

2. Настроить фильтрацию, ротацию и мониторинг системных логов средствами ОС.

3. Если не можете обеспечить п.п. 1 или 2, то конечно можно ещё закомментировать в исходниках ANAT соответствующие printk (поиск в модуле xt_ANAT_pc_nf9.c вам в помощь), но если у вас что-то потом опять "заглючит" и всё не будет работать, а вы об этом даже знать ничего не будете - то сами решайте кто тут "злой Буратино".

 

З.Ы.

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

[[anp/hsw]]

Полагаю, кто-то просто не поставил никакого таймаута в коде на случай такой ошибки? Даже одной секунды бы между release и повторным bind хватило бы, чтобы избежать такого.

[Dmitry76]

Спасибо, идея понятна.

Разумеется, сервер не в продакшене, это пока песочница доступная через IPMI для экспериментов с одним клиентом - моим ноутбуком.

 

[sdy_moscow]

1 час назад, [anp/hsw] сказал:

Полагаю, кто-то просто не поставил никакого таймаута в коде на случай такой ошибки? Даже одной секунды бы между release и повторным bind хватило бы, чтобы избежать такого.

Код доступен - анализируйте, предлагайте.

...

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

...

Кто осилит пишите ваши мысли.

 

З.Ы.

А вставлять слипы в обработчике ядра по таймеру - по мне, это как-то "дурно" пахнет. Надо 10 раз подумать какие последствия будут. Может просто прекратить обработку вызова в таком случае, но надо проанализировать какие переменные в каком состоянии оставлять и что куда записать. Таймаут сам по себе будет, пока след раз вызов обработчика не произойдет.

[[anp/hsw]]

Про sleep я не говорил, сейчас не 2000 год

Простым мне видится просто сохранять tsc при неудачной попытке и следующую попытку позволять только, если прошло достаточно времени. А то так не только лог, но и cpu потратить много в каких местах можно.

[sdy_moscow]

20 минут назад, [anp/hsw] сказал:

Про sleep я не говорил, сейчас не 2000 год

Простым мне видится просто сохранять tsc при неудачной попытке и следующую попытку позволять только, если прошло достаточно времени. А то так не только лог, но и cpu потратить много в каких местах можно.

TSC -  лишнее тут дергать, обработчик и так вызывается интервально, да и в линухе есть для этого get_jiffies_64().

Другой вопрос, что похоже действительно, при такой ошибке цикл начинает долбить как "дятел" повторными попытками отправки. Говорю-же, похоже, я проглядел обработку такой ошибки отправки в потоке обработчика axt_nf9_send_thr_run() ... , НО НЕ УВЕРЕН - НАДО КОВЫРЯТЬ!

[ShumBor]

@sdy_moscow 

Я тут немного подправил код для работы на 6.10.11 (на основе axt_NAT_v0_09_public_01_v6_patch делал)
+ поменял значение AXT_NF9_PK_ID_SSTART, а то биллинг не так считал это поле. Могу патчик/архив сформировать...
 

[sdy_moscow]

1 час назад, ShumBor сказал:

@sdy_moscow 

Я тут немного подправил код для работы на 6.10.11 (на основе axt_NAT_v0_09_public_01_v6_patch делал)
+ поменял значение AXT_NF9_PK_ID_SSTART, а то биллинг не так считал это поле. Могу патчик/архив сформировать...
 

Спасибо! Конечно нужно! Скиньте мне, если не трудно в почту - она есть в проекте (+ в личку кинул). Ну и описание проблемы чуть подробнее, если можно.

[sdy_moscow]

Уважаемые друзья.

 

Мне написали, что настройки netflow ANAT могут конфликтовать с UTM (при подсчете трафика). Рекомендуется в качестве решения заменить в xt_ANAT_pc_nf9.c значение AXT_NF9_PK_ID_SSTART  с 231 на 323.

 

Также рекомендуется заменить strlcpy на strscpy в xt_ANAT_pc_work.c для поздних версий ядра.

 

Код патча от @ShumBor  ниже:

Скрытый текст

diff -u axt_NAT_v0_09_public_01_v6_patch/xt_ANAT_pc_nf9.c
axt_NAT_v0_09_public_01_v6.10_patch/xt_ANAT_pc_nf9.c
--- axt_NAT_v0_09_public_01_v6_patch/xt_ANAT_pc_nf9.c        2024-07-19 13:22:54.000000000
+0300
+++ axt_NAT_v0_09_public_01_v6.10_patch/xt_ANAT_pc_nf9.c        2025-01-31
10:56:31.000000000 +0300
@@ -74,7 +74,7 @@
 
 // pdu pk not standart fields id
 #define AXT_NF9_PK_ID_EVENT                                        230                        //event: 0-depricated (internal use); 1-new
ses create; 2-ses stoped; 3-ses keepalive
-#define AXT_NF9_PK_ID_SSTART                                231
+#define AXT_NF9_PK_ID_SSTART                                323
 
 // pdu pk parts size
 #define AXT_NF9_PK_HDR_SIZE                 (sizeof(struct axt_nf9_pk_hdr_s))
diff -u axt_NAT_v0_09_public_01_v6_patch/xt_ANAT_pc_work.c
axt_NAT_v0_09_public_01_v6.10_patch/xt_ANAT_pc_work.c
--- axt_NAT_v0_09_public_01_v6_patch/xt_ANAT_pc_work.c        2024-01-25 03:28:26.000000000
+0300
+++ axt_NAT_v0_09_public_01_v6.10_patch/xt_ANAT_pc_work.c        2025-01-31
11:04:19.000000000 +0300
@@ -134,7 +134,7 @@
         if (!(l_cpz = &sf[0]-&sn[0])) return AXT_STRE_EMPTY; // it is empty
         //printk(KERN_INFO "xt_ANAT DEBUG: axt_prm_gettrimbuf sn : %s sf: %s l_cpz %ld\n",
sn ,sf, l_cpz);
         if (l_cpz > i_buf_sz-1) return AXT_STRE_NOBUF; // it is too long
-        strlcpy(v_buf, sn, l_cpz+1);
+        strscpy(v_buf, sn, l_cpz+1);
         v_buf[l_cpz] = '\0';
         return 0;
 }

 

[[anp/hsw]]

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

[sdy_moscow]

2 часа назад, [anp/hsw] сказал:

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

1. Времени особо на это нет.

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

3. Надо же форум популяризировать как-то, а то Телегу запретят и что делать будем? Кто пользуется решением, совет: подпишитесь на изменения в ветке форума.

4. Ну и Хотелось бы конечно живого общения, в т.ч. отзывы услышать, особенно по нагрузкам, кто что "выдавил". Кстати, а в гитхабе и его аналогах есть возможность возможность вести диалог как на форуме? Что-то не замечал там такую функцию. Сейчас,я стараюсь всю информацию собираемую актуализировать сразу здесь.

[[anp/hsw]]

14 минут назад, sdy_moscow сказал:

Кстати, а в гитхабе и его аналогах есть возможность возможность вести диалог как на форуме? Что-то не замечал там такую функцию.

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

Но git все-таки полезен вменяемой историей правок и возможностью откатить любую без особого копания в патчах.

16 минут назад, sdy_moscow сказал:

Надо же форум популяризировать как-то

Он заброшен, опасаюсь, как бы его не постигла участь форумов APC или фибертула...

[Easy88]

На днях запустили в продакшен на трафике около 30 гиг в ЧНН. Сервак HP DL360 gen9 с 2мя процами 2697Av4 нагрузку имеет около 40%. Т.е. по ощущением должен прожевать около 60 гиг. Не поняли почему автор рекомендовал обязательно отключать второй проц. На одном проце чувствовал себя хуже, проблем вроде не хватанули. Стоит уже 2 дня, вроде проблем не прилетает.

 

Пакетов в пике около 4млн было транзитом. Сессий 700 000 в пике, пользователей 11 000.

[sdy_moscow]

2 часа назад, Easy88 сказал:

Не поняли почему автор рекомендовал обязательно отключать второй проц. На одном проце чувствовал себя хуже, проблем вроде не хватанули. Стоит уже 2 дня, вроде проблем не прилетает.

 

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

 

Про многопроцессорность:

 

Второй процессор не обязательно отключать. Просто следите что-бы потоки обработки трафика входящего и исходящего не разложились по разным процессорам.

 

Почему: как уже писал, код АНАТ был оптимизирован под работу с кэшем процессоров "интелл-лайк" (с размером строки 64 байта). Как только обработка сессий НАТ начнёт раскладываться на разные процессоры и возникнет ситуация одновременного обновления информации о сессии и информации во внутренних буферах и счетчиках АНАТ с разных процессоров - эффективность (скорость) работы, из-за необходимости обращений к общей памяти и необходимости согласования кэшей процессоров будет существенно падать.

 

Для многопроцессорных систем желательно или привязывать обработчики трафика к одному процессору, или придумывать как распределить трафик строго по определенным процессорам, возможно с запуском "дупликата" модуля.

 

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

 

З.Ы.

Ситуацию конечно спасает наличие  QuickPath Interconnect (QPI) вместо FSB у современных процессоров, у 2697Av4 оно тоже есть. Но как оно будет работать в конкретном случае и что лучше (один или несколько процессоров) - тут нужны тесты. Эффективность QPI может зависеть как от процессора и материнской платы, так и от нагрузки (характера трафика). По хорошему, для многопроцессорных систем, может быть, нужен свой дизайн АНАТ. Но это есть смысл обсуждать на трафике от 100Gb и более. В любом случае, межпроцессорная синхронизация кэшей через QPI будет работать медленнее, чем непосредственная работа с данными в одном процессоре, думаю раза так в 3-4 минимум.

 

З.З.Ы.

Да, и еще. На производительность в многопроцессорной среде будет существенно влиять длина цепочек в хэш таблицах, поэтому рекомендую попробовать увеличивать длину хэштаблиц при старте модуля в многопроцессорной конфигурации сервера. Поглядывайте на счетчики HT_USRMX, HT_INRMX, HT_OURMX, периодически их сбрасывая "[CMD_RESET_CNT_HT]". Чем меньше там значения, тем лучше для многопроцессорной системы.

[Easy88]

Спасибо! Понаблюдаем. Поэкспериментируем.

[Easy88]

А ещё вопрос. Возможно ли как то посчитать внешний адрес ANAT присвоит внутренний?

Мы просто давно перестали хранить netflow, но для ответа органам периодически приходится считать какие адреса могли попасть на внешний адрес. 

[sdy_moscow]

1 час назад, Easy88 сказал:

А ещё вопрос. Возможно ли как то посчитать внешний адрес ANAT присвоит внутренний?

Мы просто давно перестали хранить netflow, но для ответа органам периодически приходится считать какие адреса могли попасть на внешний адрес. 

Если установить режим линейного пула, то да, посчитать какой внешний IP будет выдан можно, но что толку от этого если у Вас там куча других пользователей будет. Порты то разные выдаются фактически рандомно (по загрузке).

А нетфлоу АНАТ делать умеет + простейший сборщик для него я выложил тоже (в первом посте).

 

[Easy88]

Мы выдаём данные по пользователям которые за этим IP были, а органы сами выбирают. Т.к. у нас за 1 IP около 20-30 пользователей это не много.