idealni hodnoty v connection tracking ?

viktornovotny

Zdravim, ve spolek, resim zahadny problem, ze kdyz odpojim urcitou cast site, tak se rozbehne kopa broadcastu do zbytku ... jedna z moznych pricin je, ze spojeni pres routery jsou stale otevrene a tim padem to hrne do site i kdyz uz o tyto data nikdo nestoji .... takze kdo se v tom vyznate, jak dlouhe maji byt idealni casy v tomto nastaveni ??

diky

midnight_man

no som zvedavy, tiez som rozmyslal co tam nastavit

viktornovotny

tak ja mam treba na stare brane co byla pro 2,4 Ghz treti polozku kde byva den a vic ... jen hodinu ... ale uz si nevzpominam zda to delalo nejaky problem ...

midnight_man

no ja tam mam 1d, akurat rozmyslam o tom ci netreba menej...co poviete?

tom-tom

V conntracku TCP Established Timeout bývá defaultně 1d, což se mi zdá zbytečně moc. Taky to semnou kdysi pěkně vypeklo. Měl jsem klienta s jedním PC, kterému jsem musel omezovat počet spojení kvůli torrentu. Po nějaké době ok, ale na pravidlo jsem zapomněl. Pak si připojil další 2 PC, wifinu a notebook a pravidelně mi furt volal, že ping na seznam má, ale nejede mu net. Pořád mi to nešlo do hlavy. Až jsme mu vyměnili zařízení, router a kabeláž v domě (kterou si dělal sám, taky prasárna) a beztak to nepomohlo, tak mě napadlo se podívat do firewallu, kde jsem našel to zapomenuté pravidlo.

Samozřejmě, že s 1d v conntracku to dělalo svoje. Jak si naplnil denní příděl v conntracku, tak měl utrum. Od té doby si na routerech už ze zvyku nastavuju 10 minut.

midnight_man

dal som tam dal 3 hodiny :)

viktornovotny

a tech 10 minut staci ? nerozpadaji se nejake spojeni treba VPNky ?

darklogic

Já tam dávám 1 hodinu a žádné problémy nepozoruju.

tom-tom

a tech 10 minut staci ? nerozpadaji se nejake spojeni treba VPNky ?

no, toť otázka, ale doma na svém routerboardu jsem zkoušel i 5 minut, sice teda vpn jsem tehdy používal zřídka, ale nepociťoval jsem žádný problém, na to že jsem to tam měl zapomenuté cca čtvrt roku. Ale těch 10 miň :) používám už docela dlouho, tak snad by se za tu dobu snad někdo ozval, když se někteří umí ozvat s problémem 1% packetlossu na 2,4... :)

hocimin1

JA tam mam uz 2 roky nastaveno 10 minut a uplne v pohode

maxik

tez 10 min. VPN bez problemu.

reset

10min vice mene od zacatku site, problemy asi zadne

aliney

No, nastavil jsem to na routerech kde mam queues, tak jsem zvedav jestli to bude mit nejaky pozitivni efekt...

Akorat teda bylo nutne je restartovat, protoze cca kazdych 10min odpadlo a po chvili se znova spojilo pripojeni do netu (streamy vypadavaly, web v pohode) ted uz ok. Asi nejaky mishmash mezi starymi connectiony na 1d a novymi na 10min.

Predpokladam, ze pokud to u klienta nebo na routerech nekde po ceste necham zatim na 1d, tak by to nemelo delat neplechu, kdyz nemam limitovany pocet connectionu.

Chvili potrva, nez to prenastavim postupne vsude u vsech.

Edit: tak beru zpet, dela to bordel, zmeny vraceny ... na co si dat jeste pozor u takove zmeny?

maxik

pozitivni efekt to ma urcite na load routeru, protoze jinak mu tam visi nasobne vice spojeni.

viktornovotny

to aliney prosimte jaky bordel to delalo ? a na jake hodnoty jsi se teda vracel ? diky

hapi

umim si představit že to bude zavírat různá spojení která se nevyužívají delší čas než ten co je nastavenej. Vim že kdysi ještě na linuxu sem si s tim hrál a pak se mi sshčko odpojovalo po tý době nečinnosti. Člověk se de najíst a přijde k rozpojenýmu terminalu. Dál to může ovlivnit voipy obzvlášť ty který maji nastavenou delší dobu obnovování natu než ten čas v mkčku nebo třeba ani obnovování natu neumí a podobný věci. Dokonce by to mohlo zavírat i nějaký jiný jednosměrný streamy.

viktornovotny

hmm a jaka je tak cca dobra doba ? hodina ? dve ... 12 ... ?

tom-tom

SSHčko mám občas otevřené přes noc (když u toho usnu) a ráno terminál normálně žije. VoIP u nás lidi používají hlavně od 802.cz, který doporučuje keep_alive 15s a registration_ttl 600s. Jenom u jednoho převodníku jsem řešil problém, že se nechtěl vůbec připojit k SIPu, ale to byla nějaká mrdka, půjčená po dobu reklamace původního převodníku, co nechtěla chodit jinak než na veřejce.

Pro klid duše si tam nastav klidně hodinu, ale držet connecty 24 hodin v paměti je podle mě zbytečné. Ale zas, jestli je to AP někde v Horní Dolní, kde proteče 6 paketů za hodinu :) tam to asi nemá smysl, že. Apropo, u klientských RB133 jsme upravovali celý conntrack.

ludvik

Není problém ani 5 dnů timeoutu (pro TCP). Ale počítá to jaksi s tím, že každá konexe skončí správně. Což se na wifi stát nemusí. Zvlášť když je to vylepšený domácí wifinou a třeba mobilem. A ani to nemusí vadit, pokud se nepoužívá počítání konexí (connlimit v netfilteru) a jejich omezování. Nemusí vadit ani množství záznamů v conntrack tabulce, nijak extra paměť to nevyžaduje a výkonu to také moc nesebere - i když u RBček apod. to už někdy znát může být. Větší problém stejně je, když se někdo/něco zblázní a vygeneruje těch konexí mnoho za krátký okamžik. A to většinou stejně alespoň nejbližší routřík zboří ...

Najít optimum nemusí být až tak snadné, zvlášť když je potřeba myslet na ty klidně desítky routříků po cestě. Já na MK apod používám 6 hodin. Přehánět by se to nemělo ... oběma směry.

miract

Ja mam vsude na mikrotiku 2 hodiny a nikdy s tim nebyl zadny problem.

Další stránka »