[SOLVED] parhuzamos kapcsolatok szamanak korlatozasa

Egy erdekes problemam van, hatha van vkinek otlete.

A topologia a kovetkezo:

officenet (privat) - officelinuxfw - internet - hostinglinuxfw - PRIVAT HALOZAT - lxchostgep --------- LXCVM-ek

Az LXC vm-ek bridged halozaton vannak.

A linux fw-rol DNAT-tal vannak bedobalva a csomagot a (problemas) containerekre. A port nem szamit, ha nem erheto el egy container, akkor egyik DNAT-olt porton sem.

A jelenseg pedig az, hogy az irodankbol nehany szolgaltatas (egyelore legalabbis nem tapasztaljuk az osszesnel) akadozik: timeout-ol, majd ujra elerheto.
A tcpdump szerint a container-be bejut a csomag, de azon belul mar nem kapja meg a szolgaltatas (strace szerint).

Mindekozben az irodan kivul vagy a privat halozaton belul barhonnan jo. Kizarolag az office halozatbol kuldott requestekkel van problema.

IP-nkenti rate limitet nem talalok sehol (mi nem allitottunk be, de a kernelben sem talalok ilyen lehetoseget).

Szivesen vennek egy jo otletet:)

[update: 2014.06.08.]
A reboot ota egyelore semmi.

[update: 2014.06.11.]
Ugy tunik, hogy ezzel kapcsolatos ez a hiba is:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1323165

Az biztos, h belefutottunk, csak az nem vilagos, h konkretan ez a basz is emiatt van-e. Az plane nem, hogy ha igen, akkor hogyan.

[update: 2014.06.21.]
Most mar szerintem kijelentheto, hogy valoban mukodik a workaround. A launchped issue fix committed statusban van. Ezzel egyutt nem ertem, mit lehet ezen ennyit tokolni.

Van viszont mas, ehhez egyebkent sokban hasonlo problema egy masik gepen, ahol a workaround nem mukodik.

[update: 2014.07.05.]
Uj szerver, HP helyett SM, minden mas ugyanaz. Az egyik kontenerrel konzekvensen elojott. A workaround nem mukodik. PAFF
A kontainert ujrahuztam, ugy tunik, a hiba ott megszunt (kopp-kopp). A problema, h van 1 masik is, amit nem nagyon tudok lecserelni, de azt meg nem is raktam at. De tuti, h elo fog jonni a gebasz..

[update: 2014.07.07.]
Nos, ugy tunik, vegre valoban megvan a hiba, egy oriasi pebkac volt (ahogy egyebkent sejtheto volt vegulis a hiba leirasabol vmelyest).
Amikor korabban kuzdottem vele, akkor kiuttem egyben a sysctl.conf-ot is es ezek szerint elfelejtettem visszarakni.
Elotte pedig beraktam a sysctl-be nehany biztonsagosnak gondolt opciot, koztuk:

net.ipv4.tcp_tw_recycle=1

Valojaban mindehol irjak, hogy gondot okozhat, de aztan amikor kiprobaltam renden volt, aztan szepen elfelejtettem.
Nagyon erdekes, hogy problemat csak es kizarolag zimbra-val es gitblit-tel tudtam elohozni. Olyan szinten, ha pl. a gitblit-et leallitottam, akkor egybol mukodott rendben minden, a tcp kapcsolatok felepultek.

Hozzászólások

Dehogy, ahhoz nagyon sok kapcsolat kellene.
Nem irtam, de az osszes szobajovo rendszeren Ubuntu 14.04 van.

# sysctl -a|grep net.nf_conntrack_max
net.nf_conntrack_max = 65536

Amit most kiegeszitettem egy 0-val. Viszont jo kerdes, h hol kellene ezt nezni. A containeren belul nincs ilyen, allitasi lehetoseg, de attol meg tudtommal kulon namespace-ben van.

Mtu-t neztel? Hasonlo szivas volt nemreg, es ott az volt a ludas...

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Értem.
Szerintem érdemes lenne összevetni a 2 gép /proc/sys/net/ipv4/* fileok tartalmát, és megnézni mi lehet a releváns különbség (ha van).
Ubuntuéknál vannak kernel szinten reszelt dolgok (https://wiki.ubuntu.com/ImprovedNetworking/KernelSecuritySettings), ki tudja mi került bele az új release-nél esetleg ...
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Szerintem túl sok a TIME_WAIT kapcsolatod és attól egy idő után besokal a host, így a guest -ekhez el sem jut a csomag.


~# netstat -plantu | grep 'TIME_WAIT'

----
올드보이
http://molnaristvan.eu/

Azoknak a hostoknak - ahonnan költöztek a guestek - a sysctl beállításairól nem tudunk semmit? Én még arra gyanakodom, hogy abban volt valami furcsa csavar ami eddig itt nem került beállításra (ez persze csak akkor releváns ha a hiba a költözés óta került elő)

Végső elkeseredésemben én a két (jól emlékszem kettő?) problémás guest újra telepítését is megpróbálnám.

----
올드보이
http://molnaristvan.eu/

Nem, a sysctl.conf-ot is atmasoltam. Esetleg annyiban lehet hasonlo teren kulonbseg, h az egyik gep upgrade-elve volt (asszem talan Saucy-rol) a masik meg alapbol Trusy-val telepitve. De egyebkent ilyen teren megegyeznek gyakorlatilag.

Ami meg kulonbseg, hogy a regi gep Supermicro az uj pedig HP.
Az ejszaka rebootoltam a gepet (+ a sysctl beallitasokat visszaraktam default-ra). Azota nem csinalja. De eredetileg is ment par napot, amig elkezdte. Szoval most varok, h ujra elojojjon. Ha igen, akkor a legjobb otletem, h vmi nem teccik neki a HP hw-ban, ill. forditva. Ha ez sem jon be, akkor sehol sem vagyok...:)

Az elobbi-t probaltam ki es bekapcsolva is, de egyebkent korabban bekapcsolva mukodott.

A martian csomagokat csak loggolni lehet, ki/be kapcsolni nem, nem? Mindenesetre loggoltam es nem mutatott semmit (es eseteben nem is oldana meg a reboot).

Ha egy megoldassal rendelkezo fejtorot raktam volna fel, biztosan tudnek valaszolni, de igy nem igazan.

Az viszont teny, hogy a sajat privat L2 halozatan es ezt az egy IP-t leszamitva mindehonnan mashonnan is megfeleloen mukodott. Ez alapjan ezek a hibak sem johetnenek elo.
A problema, hogy minden oldalrol megkozelitve van egy csak, ami alapjan kizarhato, hogy az a baj:)

Nekem jelenleg a legjobb tippjeim:
- bugos kernel, pl. network stack (a rebootkor kernelt is frissitettem, egyebkent valoszinutlen)
- a szolgaltato halozati berendezese baszakszik (lenne ertelme, vegulis ket kulonbozo host gepen is csinalta a guest a balhet, de nem magyarazza, hogy akkor miert jutott be a csomag a guestbe es ott neman elhalt..bar ha egy bugos csomag..., viszont nincs ertelme, mert akkor reboot utan is konzekvensen produkalnia kene)
- bugos halokartya v. driver (kitudja, varok, hath megint elojon)
- bugos lxc/cgroup network namespace: akar eletszeru is lenne, de hogyhogy csak ezeken a vm-eken jott elo? Sajnos azt nem tudtam kiprobalni, h a szolgaltatast atrakni egy uj guest-re, pedig jo lenne tudni.
- ... tovabbi eroltetett okok

Kozos mindegyikben, hogy hogyan lehet, hogy csak arrol abbol a forrabol volt szar (ejszaka is reprodukalhato volt, amikor az office ures, igaz nehezebben volt elohozhato).
Elkepzelheto, h megiscsak betelt vmi, pl. a conntrack tabla, de az is eleg valoszinutlen. Leszamitva a lecsaphato magaslabdakat mar csak azert is, mert nem kapnak akkora boszme nagy loadot a gepek.
Lehet meg, h vki betort es szandekosan csinalt vmi, de ennek sem lattam jelet.

Erről nekem is támadt egy hülye ötletem, ami Xen -en hasonló jelenséget eredményezett, csak éppen a hiba "permanens" volt (kb 8 - 9 nap után rendre megjelent), miszerint időnként nem küldött SYN+ACK -t a guest mert cheksum baja lett. Egész pontoson az történt, hogy az auto negotiation be volt kapcsolva (természetesen) csakhogy a szolgáltató routerében ez nem volt bekapcsolva. Miután full duplexbe állítottam a kapcsolatokat, minden rendbe jött.

Lehet egy kérdést a szolgáltatótól megérne

----
올드보이
http://molnaristvan.eu/

Még az, hogy monitoring (munin, nagios) mit mond? Grafikonokon semmi nem látszik? Valaminek a megfutása? Valami heti ütemezésű dolog elszabadulása? Beragadó processz?

----
올드보이
http://molnaristvan.eu/