Может ли кто объяснить зачем для простой маршрутизации используется этот модуль
Последнее время переполняется таблица /proc/net/ip_conntrack именно от адресов которые просто маршрутизятся, ни какого NAT к ним не применяется (реальные адреса)
Расскажите кто как борется с этим, или хотябы отслеживает

• Вопрос по ip_conntrack,Slimm, 23:45 , 27-Мрт-07
• Вопрос по ip_conntrack,bass, 07:20 , 28-Мрт-07
  • Вопрос по ip_conntrack,Slimm, 12:04 , 28-Мрт-07
    • Вопрос по ip_conntrack,bass, 13:12 , 28-Мрт-07
      • Вопрос по ip_conntrack,Slimm, 22:42 , 28-Мрт-07
        • Вопрос по ip_conntrack,Slimm, 18:06 , 03-Сен-07
          • Вопрос по ip_conntrack,tanatonaut, 16:01 , 18-Окт-13

Народ, не вериться, что с этим ни кто не сталкивался
Схожие вопросы в форуме есть ответов только нет

>Может ли кто объяснить зачем для простой маршрутизации используется этот модуль
>Последнее время переполняется таблица /proc/net/ip_conntrack именно от адресов которые просто маршрутизятся, ни
>какого NAT к ним не применяется (реальные адреса)
>Расскажите кто как борется с этим, или хотябы отслеживает

мало информации. для выяснения причины нужно хотя бы:
точный лог ошибки
нагрузка (кол-во соединений, срез счётчиков) в момент переполнения
какие настройки sysctl касательно net/ipv4 и что у вас в kernel/shmmax и сколько памяти в системе.
что в момент переполнения с arp таблицей
все логи системы в временной отрезок +-2 минуты к моменту переполнения
ошибки на интерфейсе до и после

таблица трассировок забита записями
tcp      6 157 ESTABLISHED src=[реальный IP клиента] dst=[разные IP] sport=61015 dport=80 src=64.40.146.234 dst=194.88.205.186 sport=80 dport=61015 [ASSURED] use=1

ip_conntrack_max = 16000
15000 записей в таблице от одного клиента

в логах только сообщение ip_conntrack: table full, dropping packet.

tcpdump от клиента показывает довольно таки большой поток исходящих пакетов на 80 порт
которые и зависают не понятно почему в таблице трассировок

arp тут как-бы ни причем, его не смотрел

вчера подазрения пали на клиентский антивирус NOD32, когда его отключили активность пропала, слабо верится что это само приложение такими вещами занимается, может его какой-нибудь вирус "пропатчил"

>таблица трассировок забита записями
>tcp      6 157 ESTABLISHED src=[реальный IP клиента]
>dst=[разные IP] sport=61015 dport=80 src=64.40.146.234 dst=194.88.205.186 sport=80 dport=61015 [ASSURED] use=1
>
>ip_conntrack_max = 16000
>15000 записей в таблице от одного клиента
>
>в логах только сообщение ip_conntrack: table full, dropping packet.
>
>tcpdump от клиента показывает довольно таки большой поток исходящих пакетов на 80
>порт
>которые и зависают не понятно почему в таблице трассировок
>
>arp тут как-бы ни причем, его не смотрел
>
>вчера подазрения пали на клиентский антивирус NOD32, когда его отключили активность пропала,
>слабо верится что это само приложение такими вещами занимается, может его
>какой-нибудь вирус "пропатчил"

вы так и не предоставили и половины данных.

ip_conntrack_max по умолчанию 32760. для высоконагруженного роутера увеличивают в 2\4 раза. зачем у вас стоит так мало непонятно. когда увеличивается ip_conntrack_max необходимо также увеличить физическую память, если её мало (я тупо ставлю на каждые 32k в таблице 16Mb памяти) и увеличить kernel/shmmax (167772160 будет достаточно для 128k в ip_conntrack_max).

провести тюнинг сетевой части в контексте "высокая нагрузка - вменяемая скорость обслуживания". Разобраться в каждом параметре из /proc/sys/net/ipv4
например можно снизить нагрузки начав с таких параметров
net/ipv4/tcp_fin_timeout=30                                                                                            
net/ipv4/tcp_keepalive_intvl=120                                                                                        
net/ipv4/tcp_keepalive_probes=4                                                                                        
net/ipv4/tcp_keepalive_time=3600
net/ipv4/tcp_max_syn_backlog=1280                                                                                      
net/ipv4/tcp_orphan_retries=1                                                                                          
net/ipv4/tcp_sack=0                                                                                                    
net/ipv4/tcp_timestamps=0                                                                                              
net/ipv4/tcp_window_scaling=0

спасибо за ответ, есть о чем подумать

не согласен с Вами на счет
> ip_conntrack_max по умолчанию 32760
ip_conntrack_max по умолчанию расчитывается системой от объема памяти

мой серверок ни когда не был высоко нагруженным, обслуживает порядка 50 клиентов,
на нем стояло 64Мега оперативы и до сегоднешнего дня этого слихвой хватало, ни какого переполнения таблицы трассировки не было, в ней более 2000 записей ни когда не было

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

не спорю тюнинг дело правильное
но зло надо рубить в корне, а не подстраиваться под него

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

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

а проблема периодически всплывает, а как бороться не понятно
теперь это SMTP трафик ...

> а проблема периодически всплывает, а как бороться не понятно
> теперь это SMTP трафик ...

Ну как там борьба? Чем закончилась?