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.
- 6791 megtekintés
Hozzászólások
Első körben iptables irányba keresgélnék, szerintem le lehet benne korlátozni a kapcsolatok számát is.
===============================================================================
// Hocus Pocus, grab the focus
winSetFocus(...)
http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation
- A hozzászóláshoz be kell jelentkezni
Le lehet, de abban nincs ilyen, iptables -F utan is ez a helyzet.
A cel az, h _NE_ legyen lekorlatozva. Valamint csak egy sejtes, h vmi ilyesmi limit van. Inkabb csak ugy nez ki, mintha..
- A hozzászóláshoz be kell jelentkezni
Nem telt be a conntrack tabla?
--
Pásztor János
Üzemeltető Macik
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
dmesg + syslog mit mond?
--
Pásztor János
Üzemeltető Macik
- A hozzászóláshoz be kell jelentkezni
Nagy budos semmit.
Viszont eszembe jutott meg vmi.
Ha a container a firewall-on van, akkor minden popec.
Persze azokon a host gepeken is vannak remekul mukodo vm-ek, ahol ez a ketto gep egyebkent rosszul mukodik.
Teljes talany:/
- A hozzászóláshoz be kell jelentkezni
Nekem anno volt olyan problemam meg a XEN-el, hogy a TCP offloading bekapcsolt allapota korrupt checksumokat eredmenyezett, ami miatt a masik gep eldobalta a csomagokat. LXC-nel nem valoszinu, de azert nezd meg.
--
Pásztor János
Üzemeltető Macik
- A hozzászóláshoz be kell jelentkezni
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"
- A hozzászóláshoz be kell jelentkezni
Ugy gondoltam, h kizart, h az okozza a gondot, aztan azert kiprobaltam (atallitottam a host-on es a guest-en is).
Egy ideig ugy tunt, h jujjdejo, aztan megsem..
- A hozzászóláshoz be kell jelentkezni
É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"
- A hozzászóláshoz be kell jelentkezni
Mar nincsenek meg a regi gepek.
- A hozzászóláshoz be kell jelentkezni
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/
- A hozzászóláshoz be kell jelentkezni
Eljut a SYN csomag a guest-re. Arra mar nem megy SYN+ACK.
- A hozzászóláshoz be kell jelentkezni
A SYN+ACK lehet a hoston TIME_WAIT -ben, vagy azt mondod, hogy a guest már nem mond SYN+ACK -t?
----
올드보이
http://molnaristvan.eu/
- A hozzászóláshoz be kell jelentkezni
A guest nem mond synackot.
A mondat elso felet nem ertem, szerintem nincs is ertelme, bridge-ed halozatot hasznal a guest.
- A hozzászóláshoz be kell jelentkezni
A guest -eken IP failover nincsen, amin megakadhat a csomag?
----
올드보이
http://molnaristvan.eu/
- A hozzászóláshoz be kell jelentkezni
Nincs.
- A hozzászóláshoz be kell jelentkezni
MAC address ütközéssel szívtam LXc-nél, mivel másolgattam a configokat több containerre, azt is érdemes ellenőrizni
- A hozzászóláshoz be kell jelentkezni
Tuti nem.
Nem irtam korabban, de az egesz rendszer egy masik szolgaltatotol koltozott at. A host gepek ujak, azok installva voltak, de a guestek masoltak. Igy ez gyakorlatilag kizart.
- A hozzászóláshoz be kell jelentkezni
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/
- A hozzászóláshoz be kell jelentkezni
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...:)
- A hozzászóláshoz be kell jelentkezni
Ha a jelenség, újra indítástól megszűnik, akkor csak valami elfogy ezeken a gépeken. Azt az ip_conntrack modult csak meg kellene nézni és ha nem kell akkor unload -olni és letiltani!
----
올드보이
http://molnaristvan.eu/
- A hozzászóláshoz be kell jelentkezni
Nem a conntrack fogy el.
Vmi elfogy, eddig en is eljutottam. Aztan jottem ide...:)
- A hozzászóláshoz be kell jelentkezni
Bassza meg rendes ufo tevékenység
----
올드보이
http://molnaristvan.eu/
- A hozzászóláshoz be kell jelentkezni
Egyelore varakozo allasponton vagyok, h mit tortenik 1 heten belul.
- A hozzászóláshoz be kell jelentkezni
Kiváncsi vagyok mi lesz a megoldás.
- A hozzászóláshoz be kell jelentkezni
Még az jutott az eszembe, hogy tcpdumpolni kellene, óránként 1-10 perceket, külön külön pcap fileokba pár napon keresztül, aztán annak nekifeküdni drótcápával, hátha kiokosodnál abból.
----
올드보이
http://molnaristvan.eu/
- A hozzászóláshoz be kell jelentkezni
Ezt nem ertem, milyen eredmenyt varsz?
Ahogy irtam felul, amikor gebasz van (volt), akkor 1 db syn csomag bement es annyi.
- A hozzászóláshoz be kell jelentkezni
Hulye kerdes: rp filter vagy martian checks? Ezek eldobaljak a csomagokat anelkul hogy a tuzfaladhoz jutna.
--
Pásztor János
Üzemeltető Macik
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
Ize, a masiknak esetleg vannak routing / ARP problemai? Esetleg packet loss miatti ARP vesztes? Tenyleg mar szalmaszalak utan kapkodok en is.
--
Pásztor János
Üzemeltető Macik
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Te egy hulye otlet: probald mar meg kiuttetni a switchbol a gep MAC / IP cimet.
--
Pásztor János
Üzemeltető Macik
- A hozzászóláshoz be kell jelentkezni
Ha ujra elojon, kiprobaljuk. A guest-ere gondoltal?
- A hozzászóláshoz be kell jelentkezni
Igen.
--
Pásztor János
Üzemeltető Macik
- A hozzászóláshoz be kell jelentkezni
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/
- A hozzászóláshoz be kell jelentkezni
00,000000001%-ot latok ra, de ha (amikor?) ujra elojon, meg fogom kerdezni.
Kosz.
- A hozzászóláshoz be kell jelentkezni
Amolyan utolsó szalmaszál...
Valamint látszana a probléma kialakulása
----
올드보이
http://molnaristvan.eu/
- A hozzászóláshoz be kell jelentkezni
Abbol szerintem nem.
Ill. amugy volt ilyen, futott a tcpdump es kozben egyszer mukodott, majd nem. Amikor mukodott, minden OK volt. Lattam, h utaznak a csomagok odavissza, amikor nem, akkor meg egy syn erkezett es semmi tobb.
- A hozzászóláshoz be kell jelentkezni
esetleg meg kellene nézned hogy a file descriptorok elfogynak e, ugye az /etc/security/limits veszi fel PAM-on keresztül
ha elfogy a dmesg-ből nem derül ki, csak akkor ha az applikációd tudja loggolni.
- A hozzászóláshoz be kell jelentkezni
Neztem, nem fogyott el.
De ha igy is lenne, a 3-way handshake-nek akkor is meg kellene tortennie (szerintem).
- A hozzászóláshoz be kell jelentkezni
nem nem :(
- A hozzászóláshoz be kell jelentkezni
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/
- A hozzászóláshoz be kell jelentkezni