Verze 6.1

[Noxus28]

Keď sa tu o tom už rozpráva - nejak mi úplne neide do hlavy zmysel "TPC Estabilishet timeout - 1d 00:00:00" pre čo 1 deň? Aký to má význam n takú dlhú dobu?

[Dalibor Toman]

Keď sa tu o tom už rozpráva - nejak mi úplne neide do hlavy zmysel "TPC Estabilishet timeout - 1d 00:00:00" pre čo 1 deň? Aký to má význam n takú dlhú dobu?

TCP spojeni muze byt navazano dlohou dobu a pri tom nemusi prenest ani packet. Takze pokud nastane situace, ze informace o takovem spojeni vybehne z connection tracking tabulky a pouziva se NAT nebo 'established' ve firewallu pak pokud posle vzdaleny konec najednou nejaka data, firewall packety dal nepusti a spojeni spadne. A to zrejme jen na jedne strane protoze dovnitr site zadna informace neprijde

[Noxus28]

Ďakujem za ozrejmenie, skusim s to stiahnut na 12h - tak dlho v praci stejnak nikto nie je

[hapi]

Keď sa tu o tom už rozpráva - nejak mi úplne neide do hlavy zmysel "TPC Estabilishet timeout - 1d 00:00:00" pre čo 1 deň? Aký to má význam n takú dlhú dobu?

třeba typicky ssh spojení. Nechám otevřený, nešahám na něj a za pár hodin je odpojený. To mě může vždycky nasrat

[Majklik]

třeba typicky ssh spojení. Nechám otevřený, nešahám na něj a za pár hodin je odpojený. To mě může vždycky nasrat

Nastav si volbu ServerAliveInterval, která posílá aplikační ping přes šifrovaný kanál nebo volbu TCPKeepAlive, která aktivuje TCP keep alive na úrovni TCP protokolu a máš klid (pokud to je OpenSSH, stjené volby jsou třeba i v Putty).
Zase občas sere opačný případ, když tyhle oživovátka jsou nastaveny na moc ostré časy, tak spojení spadne při nějakém výpadku.
AspoŇ se človk naučil používat screen a donutil koupil licenci na NX.

Ďakujem za ozrejmenie, skusim s to stiahnut na 12h - tak dlho v praci stejnak nikto nie je

To je rozumná hodnota. Záleží, zda očekáváš, že by tví kolegové komunikovali s rámci Sluneční soustavy a používali TCP user timeout (zajimavé rozšíření v TCP protokolu, s ohledem na časy potřebné v rámci Sluneční soustavy), tam bych nedával míň jak cca 9,5 hodin. Pokud jsou "normální", tak většina aplikací použije buď nějaké aplikančí nakopávátko nebo protokolový TCP keep alive a ten posílá obvykle "ping" po 2 nebo 4 hodinách v defaultu. Takž i 5 hodin je ještě akceptovatelná hodnota, pokud by byl contrack plnej pořád.

Jen to nepřehnat... Vzpomínám na jednoho experta (už nedělá u ISP, už je v IBM), ten v tichosti nastavil okometricky hezky timeouty na contrack tak, že začlo vše všem zcela náhodně v určitýc intervalech padat. Technici šíleli, běhali netuše po síti, měnili/ladili rádia.... Nu, také už tam nejsou, dali hromadně výpověď.

[Noxus28]

"Okometricky" som sa s tým hral 2 dni kým ekonomka neprisla ze ju vyhadzuje z platobného portálu timeout na 1minutu - len tak ma zaujímalo čo to spraví - už viem
Ďakujem za rady

[Zbojnik]

Po prechode na 6.1 (povodne 5.22 + vymena zeleza)
prestal akokey fungovat routing mark, default route s routing mark boli neaktivne... chovali sa ako duplicitne
po prechode na 5.25 vsetko v poriadku

mal niekto podobny problem? alebo treba este v novej verzii nieco povolit?

[radek1]

mně se to stalo 2x, taky jsem se vracel na 5.25

[Dalibor Toman]

tak nam prave na trase kterou jsem pred par dny upgradnul z 5.25 na 6.1/3.07 NV2 nad MIMEm zamkla modulaci na 6mbps. Cili ani 6.1 tenhle problem neresi...

[asdewq]

mne sa vcera odmlcal jeden router postaveny na alixe so 6.1 ... bolo to tam skor zo zvedavosti, na konzole hlasi info o tom ze nieje system package. Ci je to len zhoda nahod a umrela flashka alebo 6.1... tak pre istotu pozor.

[m_dufek]

Hoj panove - me po castecnem upgdradu nekolika prvku prestaly odpovidat prvky na 6.1. Pripojeni k coreroutreu pres vpn(cela sit static route) a nektery zarizeni nevidim ani pres ping a samo se do nich nedostanu winboxem pokud se dotuneluju do sousedniho HW tak pres mac-telnet so do nich dostanu. Takze vse vracim na oblibenou 5.8 Mate podobne zkusenosti? Trosku mi to rozladilo. Doufal jsem ze se 6x verze posunou dal. Treba scaling winboxu a webboxu mi potesil - uz se to da spravovat i pres netbooky s prtavim lcd, kde nebyli videt nektere polozky...
v logu ani prd, ze by byl nejakej problem asi bug ve verzi... nejaky zkusenosti z provozu od ostatnich?

[hapi]

Zadnej takovej problem neni

[ppp76]

u 6.1 zatim zadny zasadni problemy nepozoruju

[m_dufek]

Hoj panove - me po castecnem upgdradu nekolika prvku prestaly odpovidat prvky na 6.1. Pripojeni k coreroutreu pres vpn(cela sit static route) a nektery zarizeni nevidim ani pres ping a samo se do nich nedostanu winboxem pokud se dotuneluju do sousedniho HW tak pres mac-telnet so do nich dostanu. Takze vse vracim na oblibenou 5.8 Mate podobne zkusenosti? Trosku mi to rozladilo. Doufal jsem ze se 6x verze posunou dal. Treba scaling winboxu a webboxu mi potesil - uz se to da spravovat i pres netbooky s prtavim lcd, kde nebyli videt nektere polozky...
v logu ani prd, ze by byl nejakej problem asi bug ve verzi... nejaky zkusenosti z provozu od ostatnich?

UPDATE - problem s pripojenim beru zpět. Chyba nebyla v ROSu. Pořádně jsem všechno v klidu prolezl a problem byl zakopanej jinde. Jeden z kolegů zapomněl u sebe na chatě na servru inaktivovat pptp a ono se to připojovalo do našeho tunelu (stejny ip, stejny uzivatel) a bloudili nam packety... po sestřeleni a přeheslovani vše ok. Jak to co zustalo na 6.0, 6.1 i starší verze.

Ještě by mě zajima jedna věc - nepozorovali jste nějakou změnu citlivosti u MT karet resp. r52, r52H, pripadně R52Hn. Přišlo mi že R5Hn po upgradu na 6.0 je citlivější a spoj se stal i stabilnějším (R5Hn + UBNT Rocket Dish - spoj 9km, nv2, standart 130/130 MB).

[dantasik]

Zatim jsem nemel cas to poradne debugovat, ale pri nasazeni na RB750G se me nejak rozpadalo FTP spojeni bylo nestabilni a padalo, puvodne jsem myslel ze je to strana serveru ale nebyla, po downgrade na 5.25 vse OK. Zapnuty NAT i conntrack samo.
Az bude chvili casu udelam nejakej lepsi debug...