Изпечатай

[VladSun]

Здравейте!

Описание на SW&HW (всичко за което се сещам):

машина: Celeron 1.4GHz, RAM 384MB.

Slackware 9
Linux 2.6.10
iptables v1.3.2

рутиране на една публична /24 мрежа,
SNAT на една частна /24 мрежа,
htb shaper

mysql  Ver 11.18 Distrib 3.23.56, for slackware-linux (i386),
Apache/1.3.27 (Unix)
BIND 9.2.2

Проблемът:

от известно време машината забива тотално и само хардуерен рестарт я оправя. Има пуснат софтуерен watchdog, който проверява за връзка през двете мрежови карти и при необходимост рестартира софтуерно, но той изобщо не сработва, т.е. машината забива зверски. Тъй като не успях да остраня проблема сложих и един хардуерен watchdog и сега се мъча да локализирам проблема според ситуацията преди забиването.
Последно почнах да следя ip_conntrack_count и ми се струва, че проблемът е свързан с conntrack.

cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
24568

Според графиката на /proc/sys/net/ipv4/netfilter/ip_conntrack_count забиването на машината е винаги, когато броят на връзките достигне стойност около 11400-11700.
Това, което също ме безпокои е, че графиката расте монотонно (с леки пикчета), и е права линия когато няма трафик. Все си мисля, че броят на следените връзки би трябвало да е горе-долу в синхрон с трафика през машината.

Някакви предложения?

ПП: И при предишната версия на ядрото  - 2.4.ХХ проблемът съществуваше.

[ray]

Здравей,
За съжаление нищо конкретно, но ми стана интересно и пробвах на моя компютър - броят на връзките расте, после намалява после пак расте (както и трябва).
Иначе като идеи: 1)може да липсва някаква настройка на "iptables"-a, но коя точно. И защо не се освобождават старите връзки, а новите само се трупат докато се препълни буфера?
2)Някой съзнателно да атакува като поддържа всички стари връзки и генерира нови докато се препълни буфера.
PS: мога да изпратя моя kernel-конфиг. (1-1 от shorewall docs)
Успех. Румен

[zarhi]

conntrack модула иска по 386 байта за всяка конекция. Това трябва да е физическа рам, достъпна и свободна в момент на нужда. В случай че няма свободна памет се налага нещо да иде във swap-а и междувременно се натрупват пакети. Възможно е да има бъг в драйвера на мрежовата карта, който води до забиване, конфликт в irq-та на дисковия контролер и лан картата или между самите лан карти....

[VladSun]

Благодаря за отговорите!
Давам още информация:
cat /proc/interrupts
           CPU0
  0:   29525058          XT-PIC  timer
  2:          0          XT-PIC  cascade
  7:          0          XT-PIC  parport0
  9:          0          XT-PIC  acpi
 11:   50452642          XT-PIC  eth0
 12:   44959263          XT-PIC  eth1
 14:      81985          XT-PIC  ide0
NMI:          0
ERR:          0

cat /var/log/debug | grep eth
kernel: eth0:  Identified 8139 chip type 'RTL-8100'
kernel: eth1:  Identified 8139 chip type 'RTL-8100'

syslog
kernel: ip_conntrack: table full, dropping packet.

Последното би трябвало да означава, че сървера не забива заради това ... след като е логнато. Защото преди забиване и syslog-a умира '>

[zarhi]

А резултата от 'cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max' ?

[VladSun]

както по-горе съм писал '> :

cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
24568

Току що инсталирах iptstate и е пълно с конекции от вида:

State             TTL
ESTABLISHED  115:57:17
ESTABLISHED  1190:23
ESTABLISHED  115:16:29
ESTABLISHED  115:21:43
ESTABLISHED  113:116
ESTABLISHED  117:11:57
ESTABLISHED  115:46:56

ip_conntrack_count непрекъснато расте с постоянна малка девиация от около 100-200 конекции (т.е. има освобождаване на конекции, но на прекалено малко).

cat ip_conntrack_tcp_timeout_established
432000
Това не е ли прекалено много?

Да не би проблемът да идва от IRC, FTP и TFTP  conntrack-инга (компилирани са в ядрото)?

[ray]

Здравей,
От това (твоят цитат по долу) би следвало да е ясно, че таблицата с "ip_conntrack" е пълна и новите заявки се "drop"-ват (едва ли и syslog-a умира, само докладва):
...
syslog
kernel: ip_conntrack: table full, dropping packet.
...
Прави ми впечатление, че използваш евтини карти (8139) сигурно знаеш че те работят главно на база софтуерен драйвер и може да има проблеми с тях.
Опитай с някоя INTEL-ска или 3COM-ска (ако имаш подръка).
Без претенции за пълнота, но от време на време тук-там се появяват оплаквания от 8139. Имах такава и си работеше, но я смених с INTEL-ска, не че е имало проблеми, просто за по-добра надеждност и производителност.
Успех. Румен

[zarhi]

Не, това е стойността по подразбиране. Имам машини с кернел 2.4.21, ip_conntrack_max = 512000 които са работили с месеци без проблем, със заредени всички възможни допълнителни модули. След 24 часа работа 'rmmod ip_conntrack' отнемаше по 20 минути и освобождаваше над 400Мбайта рам, но никога не е забивала.

Забиване без kernel panic принципно е означава сериозен хардуерен проблем ( температура? спрял вентилатор? ) или бъг в модул, който работи с irq/dma и успява така да препрограмира чипсета че да го забие.

[zarhi]

Между другото доколкото си спомням RTL-8100 е чипсет за вграждане на дъна. И наличието на 2 такива лан карти е най-малкото странно. Някак си не си спомням да съм виждал дъно с 2 вградени realtek лан карти.

RTL-8139 принципно работят доста стабилно, но са така направени, че за всеки приет/предаден пакет генерират прекъсване. И съответно с 2 ( или повече ) такива карти при трафик над 70-80 Мбит натоварването на машината става доста сериозно. Тия лан карти са bus master и могат да задържат pci шината, което при някой дъна води до недостатъчно време за опресняване на памета. Но тогава винаги следва kernel panic.

Изобщо провери първо за хардуерни проблеми ( memtest86 ). Не е нормално един и същи ефект при кернел 2.4 и 2.6. Общото май остава само хардуера.

[VladSun]

Пак, много благодаря за бързите отговори!

Но, все пак, продължава да ме мъчи проблема с неосвобождаването на следените конекции... това не ми прилича на хардуерен проблем '>

В момента подкарвам lm-sensors, пък после да видим графиката какво ще покаже ...

ПП: Трафика през сървера никога не е над 30Мбит със сигурност.

[mhydra]

Защо не попиташ за всеки случай и в форума на linuxpackages.net.
Там може и да знаят, най малкото предполагам че Jim ще се заинтересова.

[zarhi]

Цитат

рутиране на една публична /24 мрежа, SNAT на една частна /24 мрежа, htb shaper

2С мрежи, 506 ефективни ип-та, 24568 тракнати конекций. Това е по 48 конекций на ип. Няма нищо ненормално. Между другото една подробност която често се пропуска: зареди ли се conntrack модула веднага се тракват ВСИЧКИ конекций. И реални и нат-нати ип-та + трафика генериран от самия сървър. Това няма как да се промени, така работи модула. Даже и машината да е само рутер за реални ип-та, заредиш ли conntrack или nat модул ( който иска conntrack ) задължително се траква всичко, без значение дали ще ти потрябва или не.

Ами и аз да се оплача. Значи имам Slack с ядро 2.4.20 и pptp,pppd,htb,16MB RAM, 2x3c503 LAN,P60. С NAT,CONNTRACK,firewall и всички необходими неща за натване на VPN и LAN мрежа. Това нещо забиваше с Aieee, killing interupt handler. И invalid opcode ... в незнам коя програма. Помислих че е от суапа, но не след като го изключих пак си забива. След това смених машината и отново същият резултат. Най-вероятно е несъвместимост на компонентите от горният софтуер. Така си забива регулярно и до сега. Някои ако се сети нещо да подскаже.

[zarhi]

РАМ-а е прекалено малко.

Сега машината е със същия линукс, но P200 с 24MB RAM.
Резултат същият.