idealni hodnoty v connection tracking ?

[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.

[Viktor Novotný]

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.

[keksik]

Ja mam roky nastavene napr. na koncovom routri (NAT) 1min. a menej. Vid obrazok.

[Viktor Novotný]

no jo, ale my se zde bavime o brane pro cca tisic lidi ... teda aspon ja treba

[tom-tom]

ty woe, 1 minuta je už dost extrém ne? U klienta jsem to navíc stejně nikdy neřešil, pokud tam nebyla teda ta 133. Takový koncový router pro jednu domácnost asi nemá smysl nějak nastavovat, tady jde hlavně o routery, přes které toho teče podstatně víc.

[keksik]

Ja mam roky nastavene napr. na koncovom routri (NAT) 1min. a menej. Vid obrazok.

Bezi tam okolo 160Mbps..tisicka klientov.

[aliney]

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

cca kazdych tech 10 min (nenapadlo me kontrolovat cas) to rozpojilo spojeni na terminaly (testovano pres winbox, ten ti jasne rekne, ze doslo k preruseni spojeni, protoze se jednoduse vypne) a po cca 10sekundach internet zase bezel normalne. Nicmene mi to rozpojovalo spojeni na servery, kde se to stavat nesmi. Nastavil jsem 10min a pak to vratil zpet na 1d (default)
Na druhou stranu co se tyce vytizenosti cpu tak ani jedna z hranicnich RB800 podle grafu nejak extra netrpi, malokdy se to dostane pres 50% . Mam tam cca 150 queues, 150 fw, 200 natu, 300 manglu (na kazde), takze nic extra co by me trapilo, proste jsem to chtel zkusit a vono nic z toho

[Majklik]

Nastavovat časové okno pro otevřené TCP spojení na míň jak cca 2 a čtvrt hodiny považuji za profesionální selhání toho, kdo to konfiguruje. Pánové, občas to chce třeba číst RFC,očas tam bývá i něco užitelčného ( např RFC 1122, 4.2.3.6 TCP Keep-Alives).
U TCP pro protokolový keepalive platí, že se nemá v defaultu posílat častěji, jak jednou za 2 hodiny a vše mé osobě známé OS toto nastavení dodržují. Je pravda, že řada aplikací používá aplikační keep-alive, který je kratší, ale potkávám řadu aplikací, co si zapnou jen protokolový a datově opravdu přenesou třeba jeden-dva pakety za den.

[douby]

my nastavujeme už několik let 1h a pro úplnost dodám, že pokud nepoužíváte některou z následujících funkcí můžete tracking úplně disablovat:

NAT
firewall:

connection-bytes
connection-mark
connection-type
connection-state
connection-limit
connection-rate
layer7-protocol
p2p
new-connection-mark
tarpit

p2p matching in simple queues