- Вопрос по ip_conntrack, Slimm, 23:45 , 27-Мрт-07 (1)
Народ, не вериться, что с этим ни кто не сталкивался Схожие вопросы в форуме есть ответов только нет - Вопрос по ip_conntrack, bass, 07:20 , 28-Мрт-07 (2)
>Может ли кто объяснить зачем для простой маршрутизации используется этот модуль >Последнее время переполняется таблица /proc/net/ip_conntrack именно от адресов которые просто маршрутизятся, ни >какого NAT к ним не применяется (реальные адреса) >Расскажите кто как борется с этим, или хотябы отслеживает мало информации. для выяснения причины нужно хотя бы: точный лог ошибки нагрузка (кол-во соединений, срез счётчиков) в момент переполнения какие настройки sysctl касательно net/ipv4 и что у вас в kernel/shmmax и сколько памяти в системе. что в момент переполнения с arp таблицей все логи системы в временной отрезок +-2 минуты к моменту переполнения ошибки на интерфейсе до и после
- Вопрос по ip_conntrack, Slimm, 12:04 , 28-Мрт-07 (3)
таблица трассировок забита записями 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=1ip_conntrack_max = 16000 15000 записей в таблице от одного клиента в логах только сообщение ip_conntrack: table full, dropping packet. tcpdump от клиента показывает довольно таки большой поток исходящих пакетов на 80 порт которые и зависают не понятно почему в таблице трассировок arp тут как-бы ни причем, его не смотрел вчера подазрения пали на клиентский антивирус NOD32, когда его отключили активность пропала, слабо верится что это само приложение такими вещами занимается, может его какой-нибудь вирус "пропатчил"
- Вопрос по ip_conntrack, bass, 13:12 , 28-Мрт-07 (4)
>таблица трассировок забита записями >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, Slimm, 22:42 , 28-Мрт-07 (5)
спасибо за ответ, есть о чем подуматьне согласен с Вами на счет > ip_conntrack_max по умолчанию 32760 ip_conntrack_max по умолчанию расчитывается системой от объема памяти мой серверок ни когда не был высоко нагруженным, обслуживает порядка 50 клиентов, на нем стояло 64Мега оперативы и до сегоднешнего дня этого слихвой хватало, ни какого переполнения таблицы трассировки не было, в ней более 2000 записей ни когда не было происходящая ситуация с переполнением это аномалия, происходящая лишь из-за одного абонента, от которой надо просто защититься скажим фаирволом, а увеличивать таблицу или память это не решение не спорю тюнинг дело правильное но зло надо рубить в корне, а не подстраиваться под него остальные абоненты работают и посылают в сумме намного больше запросов, но они не оседают в таблице, почему? есть ли какой то параметр по которому можно было бы отбросить нежелательные пакеты? и вообще я не понимаю зачем в эту таблицу попадают пакеты проходящие сервер насквозь т.е. ни какого NAT нету, реальный IP, зачем простому маршрутизатору иметь информацию о соединениях с него, помоему он должен просто переложить на другой интерфейс и забыть.
- Вопрос по ip_conntrack, Slimm, 18:06 , 03-Сен-07 (6)
а проблема периодически всплывает, а как бороться не понятно теперь это SMTP трафик ...
- Вопрос по ip_conntrack, tanatonaut, 16:01 , 18-Окт-13 (7)
> а проблема периодически всплывает, а как бороться не понятно > теперь это SMTP трафик ...Ну как там борьба? Чем закончилась?
|