Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Verze 6.1
Zajimava vec s ROS 6.x.
U CHANNEL listu ikdyz vypisete vsechny frekvence tak u AP nastavene jako DFS si stejne veme tu prvni.
Jedine, co umi, je kdyz mu date do frekvence napr 5500-5540 tak, ale jede po 5 MHZ, nevite jak z tyhle pasti ven a mit zapnuty DFS??
U CHANNEL listu ikdyz vypisete vsechny frekvence tak u AP nastavene jako DFS si stejne veme tu prvni.
Jedine, co umi, je kdyz mu date do frekvence napr 5500-5540 tak, ale jede po 5 MHZ, nevite jak z tyhle pasti ven a mit zapnuty DFS??
0 x
Člvěk se vrátí pln optimismu z dovolené, s potěšením zhlédne, zkusí a ....
jo, VRRPv2/AH v 6.1 evidentně negeneruje do paketů naprosté nesmysly. Vypadá to na pohled správně. Akorát se to nebaví s ničím jiným, než dalším ROS6.1. Nefunguje proti ROS5.25 a ani jiným křápům. Oba VRRP routery naskočí jako master a druhého si nevšímají. Nějaký vtipný úklep...
A jako bonus přidali v ROS6.1 funkci, že funguje na jendom fyzickém rozhraní maximálně jeden VRRP interface (a ne 256), ostatní se nespustí. To v ROS6.0 ještě fungovalo OK.
Kvůli tomuhle mi brečel kolega, že po upgrade na ROS6.1 mu začlo blbnout místo, kde PtP linkuje RB1200 a RB493Géčka, vyapdává to a musí ručně vynutit 100 Mbps a pak to jede. Po ROS6.0 jelo bez problémů a linkovalo auto na gigu.
Tak ten bridge nastav na MAC adresu toho wlan iface, namlať ji tma jako admin-mac a mohlo by to být tím obejito.
Edit: Hele, tak on nejen ten VRRP se umí bavit proti jinéme RPS6.1, ale stejně tak i IPsec vypadá, že je ochoten komunikvat jen proti stejné verzi. Po upgrade 6.0 na 6.1 se není schopen domluvit s verzí 5.25 (RB800/ROS6.1 proti RB1100AHx2/AH s ROS5.25). Po downgrade na 6.0 to hnedka najede. Hm, hm.
*) vrrp - fixed ah authentication;
jo, VRRPv2/AH v 6.1 evidentně negeneruje do paketů naprosté nesmysly. Vypadá to na pohled správně. Akorát se to nebaví s ničím jiným, než dalším ROS6.1. Nefunguje proti ROS5.25 a ani jiným křápům. Oba VRRP routery naskočí jako master a druhého si nevšímají. Nějaký vtipný úklep...
A jako bonus přidali v ROS6.1 funkci, že funguje na jendom fyzickém rozhraní maximálně jeden VRRP interface (a ne 256), ostatní se nespustí. To v ROS6.0 ještě fungovalo OK.
*) fix 1G linking with some Cisco devices (affects RB7xx, RB9xx, RB1100, RB2011, CCR);
Kvůli tomuhle mi brečel kolega, že po upgrade na ROS6.1 mu začlo blbnout místo, kde PtP linkuje RB1200 a RB493Géčka, vyapdává to a musí ručně vynutit 100 Mbps a pak to jede. Po ROS6.0 jelo bez problémů a linkovalo auto na gigu.
Repkins píše:DHCP klient na wlan interface v režimu station bridge prostě nedostane IP adresu. Pokud je DHCP klient na bridge, tak IP dostane, ale to je mě ouplně naprd, páč MAC bridge je jiná než MAC wlan interface. A ISPAdmin umí do DHCP zapisovat jen MAC wlan iface.
Tak ten bridge nastav na MAC adresu toho wlan iface, namlať ji tma jako admin-mac a mohlo by to být tím obejito.
Edit: Hele, tak on nejen ten VRRP se umí bavit proti jinéme RPS6.1, ale stejně tak i IPsec vypadá, že je ochoten komunikvat jen proti stejné verzi. Po upgrade 6.0 na 6.1 se není schopen domluvit s verzí 5.25 (RB800/ROS6.1 proti RB1100AHx2/AH s ROS5.25). Po downgrade na 6.0 to hnedka najede. Hm, hm.
0 x
(CCR i x86)
hmm a víš co se stane když se zaplní celá conn. tracking tabulka? radši se neptej. Já nevim co tam ti idioti dělaji, neměla by se začít sama od nejmenších timeoutů umazávat? tedy tak to aspoň říká linuxovej kernel pokud se nepletu.
hmm a víš co se stane když se zaplní celá conn. tracking tabulka? radši se neptej. Já nevim co tam ti idioti dělaji, neměla by se začít sama od nejmenších timeoutů umazávat? tedy tak to aspoň říká linuxovej kernel pokud se nepletu.
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
To si nemyslím ... nová spojení bude odmítat. A v logu uvidíš něco jako "conntrack full".
Ale když už v tom rýpeš - co znamená pro MK "plno"?
Ale když už v tom rýpeš - co znamená pro MK "plno"?
hapi píše:(CCR i x86)
hmm a víš co se stane když se zaplní celá conn. tracking tabulka? radši se neptej. Já nevim co tam ti idioti dělaji, neměla by se začít sama od nejmenších timeoutů umazávat? tedy tak to aspoň říká linuxovej kernel pokud se nepletu.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
našel sem tohle
což je docela v prdely. I tak nechápu proč to sem tam vypadávalo když se ta tabulka na nic aktuálně nepoužívá.
Plno? v přehledu konexí je dole "Max entries" a vlevo od toho je počet záznamů. Tyhle čísla se rovnaly. Do logu to nic nepsalo. Jenom sem tam nebyly dostupný nějaký servery a sem tam vypadávaly pakety s hláškou "packet rejected". Na google sem našel zmínku o conn. tracking a že to pomohlo snížení timeoutů tak jsem tabulku rovnou vypnul a najednou je to čisté. Pak jsem jí zapnul a během 2 minut se naplnila znova a to samé. Takže jsem stahnul časy a zatim se to nestalo.
You can see the current size of this table using sysctl net.netfilter.nf_conntrack_count and its limit using sysctl net.nf_conntrack_max. If count crosses max, your linux system will stop accepting new TCP connections and you’ll never know about this.
což je docela v prdely. I tak nechápu proč to sem tam vypadávalo když se ta tabulka na nic aktuálně nepoužívá.
Plno? v přehledu konexí je dole "Max entries" a vlevo od toho je počet záznamů. Tyhle čísla se rovnaly. Do logu to nic nepsalo. Jenom sem tam nebyly dostupný nějaký servery a sem tam vypadávaly pakety s hláškou "packet rejected". Na google sem našel zmínku o conn. tracking a že to pomohlo snížení timeoutů tak jsem tabulku rovnou vypnul a najednou je to čisté. Pak jsem jí zapnul a během 2 minut se naplnila znova a to samé. Takže jsem stahnul časy a zatim se to nestalo.
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
To jsem si ani nevšimnul 
Ale jestli ti nestačí 524 tisíc záznamů, tak máš problémy někde jinde ... sice nevím jakou máš síť, ale pokud mám pro 2600 lidí stropy někde u 50 tisíc záznamů v conntracku, tak mám pořád desetinásobnou rezervu.
Změna timeoutu pomůže jen u nových konexí. Již existujících se netýká.
Oblíbené je totiž mít wifi a padat spojení ... konexe tam v takovém případě visí celý den (TCP timeout mikrotiku) aniž by se přenesl jediný bajt. V čistém linuxu je to 5 dnů (nebo alespoň bývalo).
A pokud u MK v6 máš něco v conntrack tabulce, tak jsou dvě možnosti: máš ji zapnutou natvrdo, nebo v případě "auto" používáš v netfilteru něco co ji potřebuje (i když nevím, jak to mikrotik vlastně detekuje, jestli to má správně - nezkoumal jsem).
Ale jestli ti nestačí 524 tisíc záznamů, tak máš problémy někde jinde ... sice nevím jakou máš síť, ale pokud mám pro 2600 lidí stropy někde u 50 tisíc záznamů v conntracku, tak mám pořád desetinásobnou rezervu.Změna timeoutu pomůže jen u nových konexí. Již existujících se netýká.
Oblíbené je totiž mít wifi a padat spojení ... konexe tam v takovém případě visí celý den (TCP timeout mikrotiku) aniž by se přenesl jediný bajt. V čistém linuxu je to 5 dnů (nebo alespoň bývalo).
A pokud u MK v6 máš něco v conntrack tabulce, tak jsou dvě možnosti: máš ji zapnutou natvrdo, nebo v případě "auto" používáš v netfilteru něco co ji potřebuje (i když nevím, jak to mikrotik vlastně detekuje, jestli to má správně - nezkoumal jsem).
hapi píše:Plno? v přehledu konexí je dole "Max entries" a vlevo od toho je počet záznamů. Tyhle čísla se rovnaly. Do logu to nic nepsalo. Jenom sem tam nebyly dostupný nějaký servery a sem tam vypadávaly pakety s hláškou "packet rejected". Na google sem našel zmínku o conn. tracking a že to pomohlo snížení timeoutů tak jsem tabulku rovnou vypnul a najednou je to čisté. Pak jsem jí zapnul a během 2 minut se naplnila znova a to samé. Takže jsem stahnul časy a zatim se to nestalo.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
když je tabulka přepnutá na auto tak se zapne vždy když přidáš JAKÝKOLIV pravidlo a to i takový který to nepotřebuje.
Interní věci neprozrazuji ale je tam server který je hooodně vytěžovaný a to předevšim UDP pakety.
Interní věci neprozrazuji ale je tam server který je hooodně vytěžovaný a to předevšim UDP pakety.
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
ludvik píše:A pokud u MK v6 máš něco v conntrack tabulce, tak jsou dvě možnosti: máš ji zapnutou natvrdo, nebo v případě "auto" používáš v netfilteru něco co ji potřebuje (i když nevím, jak to mikrotik vlastně detekuje, jestli to má správně - nezkoumal jsem).
Tedy - máš-li něco ve firewallu, je jedno co, mikrotik conntrack zapne
Tedy nedetekuje naprosto nic.Edit: jsem si nevšiml tvého postu ... Ale jinak odpovím jinak: nechceš-li prozradit, nečekej diskusi
To je jak včerejší článek o sledování provozu v Británii - tajná organizace sleduje, sama si to tajně audituje, výsledek auditu je také tajný.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
-
Dalibor Toman
- Příspěvky: 1246
- Registrován: 11 years ago
ludvik píše:ludvik píše:Tedy - máš-li něco ve firewallu, je jedno co, mikrotik conntrack zapne
ono totiz pouzivat ip firewall u MT bez zapnuteho connection tracking ani bezpecne nelze. Duvodem je to, ze fragmentovane packety je potreba v podani MT pred firewallovanim nejprve slepit apak teprve pustit do ip firewallu. Jinak MT firewall zahodi pokracovaci fragmenty pruchozich packetu a navic se to chova chvili OK chvili spatne. Cili neni prez takovy MT mozne pustit zadny tunel.
0 x
-
midnight_man
- Příspěvky: 3680
- Registrován: 13 years ago
On ten conntrack tam nie len na to aby vytazoval CPU Ak chcete, aby vam pravidla chodili korektne musite ho mat zapnuty + mozete znizit niektore timeouty aby to nedrzalo spojenia zbytocne dlho.
Ak chcete, aby vam pravidla chodili korektne musite ho mat zapnuty + mozete znizit niektore timeouty aby to nedrzalo spojenia zbytocne dlho.
0 x
Zdaleka ne všechny pravidla conntrack vyžadují ... někdy se lze bez toho obejít. Ale je fakt, že se špatně specifikuje kde. Takový znalosti má v hlavě málokdo a blbě se to hledá.
midnight_man píše:On ten conntrack tam nie len na to aby vytazoval CPU
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
Tak nějak. Ne pro vše je potřeba mít contrack aktivní. Oficiální seznam věcí vyžaujících cotrack aktivní je zde:
http://wiki.mikrotik.com/wiki/Manual:IP ... n_tracking
Ve skutečnosti je ten seznam o trošku kratší, ale tohle je oficialita...
Jinak jsem dospěl k názoru, že je potěšitelné, že Mirkotik patlá SW stejně jako naše firma.... Množství chyb je konstantní, jen v různých verzích různé chyby aktivujeme/deaktivujeme... Proč v ROS6.0 fungoval GRE6 tunel a v 6.1 to vypadá jak generátor náhodných čísel (aspoň dle toho, co z toho tunelu padá na druhé straně... Aha, ten bordel, co dělal VRRPv2/AH v 6.0 byl přepnut a padá teď z GRE6 tunelu, asi....)?
http://wiki.mikrotik.com/wiki/Manual:IP ... n_tracking
Ve skutečnosti je ten seznam o trošku kratší, ale tohle je oficialita...
Jinak jsem dospěl k názoru, že je potěšitelné, že Mirkotik patlá SW stejně jako naše firma.... Množství chyb je konstantní, jen v různých verzích různé chyby aktivujeme/deaktivujeme... Proč v ROS6.0 fungoval GRE6 tunel a v 6.1 to vypadá jak generátor náhodných čísel (aspoň dle toho, co z toho tunelu padá na druhé straně... Aha, ten bordel, co dělal VRRPv2/AH v 6.0 byl přepnut a padá teď z GRE6 tunelu, asi....)?
0 x
Co si myslet o firmě, která je schopná změnit jednu z hodnot parametru Band wifi karty z "2.4GHz-B" na "2GHz-B". Jediný důvod, který mě napadá je "přirozená" likvidace starých záloh konfigurací, co kdyby něco fungovalo jinak ...
Majklik píše:Jinak jsem dospěl k názoru, že je potěšitelné, že Mirkotik patlá SW stejně jako naše firma.... Množství chyb je konstantní, jen v různých verzích různé chyby aktivujeme/deaktivujeme...
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
-
Dalibor Toman
- Příspěvky: 1246
- Registrován: 11 years ago
Majklik píše:Tak nějak. Ne pro vše je potřeba mít contrack aktivní. Oficiální seznam věcí vyžaujících cotrack aktivní je zde:
http://wiki.mikrotik.com/wiki/Manual:IP ... n_tracking
Ve skutečnosti je ten seznam o trošku kratší, ale tohle je oficialita...
bylo to jeste na 2.9.x a 3.x (a mozna 4.x) ale od te doby jsem se naucil, ze pokud strcim neco do firewallu (a nic z toho, co je na tom seznamu to tenkrat nebylo - proste jsem jen udelal filtr na povolena IPcka = tohle IP povol a zbytek zahod), musim zapnout connection tracking. JInak zakaznikum prestavaly nahodile fungovat tunely. Nekdy stacil reboot MT nekdy nepomohl. Pak se prislo na to, ze se ztraceji nasledne soucasti fragmentovanych packetu (prosel jen prvni packet a se zbytkem si firewall nevedel rady tak ho zahodil). Po zapnuti connection tracking problem 100% zmizel. Od te doby jsem nejak nemel potrebu to znovu zkoumat na novejsich verzich ROSu (zvlast kdyz tenkrat neslo jednoznacne rict, ze je to bez CT OK, protoze problem mohl nastat nebo ne).
Ale pokud nekdo dlouhodobe plosne pouziva firewall pravidla a nezapina CT a nema problemy pak je to urcite zajimava informace
0 x