The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]




Версия для распечатки Пред. тема | След. тема
Новые ответы [ Отслеживать ]
Вопрос по ip_conntrack, !*! Slimm, 26-Мрт-07, 11:11  [смотреть все]
Может ли кто объяснить зачем для простой маршрутизации используется этот модуль
Последнее время переполняется таблица /proc/net/ip_conntrack именно от адресов которые просто маршрутизятся, ни какого NAT к ним не применяется (реальные адреса)
Расскажите кто как борется с этим, или хотябы отслеживает
  • Вопрос по 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=1

      ip_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, зачем простому маршрутизатору иметь информацию о соединениях с него, помоему он должен просто переложить на другой интерфейс и забыть.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру