CLOUD CORE ROUTER (CCR1036)

net_work

na reseni tohohle problemu musi podle me z jejich strany vyjit update (ktery tady mimochodem davno mel byt)....

ppp76

Doufejme ze bude bez nej pro me nema cenu dalsi ccrka nakupovat :(

david2006

Hapi, Tvému řešení to při zápisu vadí nebo nevadí?

hapi

myslíš s4i? vadí. Dopsal jsem tam vyjímku pro v6 pro jednoho zákazníka kterej jí používá. Právě proto jsme přišly na změnu ve v6 v global. V další release to bude pro všechny. Dá se to řešit i jinak ale furt je to na tom že se to musí upravit v systemu.

david2006

OK, díky.

radekulehla

Uvědomte si taky, že v6 je pořád rc, ohledně QT může být ve stable verzi vše jinak.

Kolobok

+1 asi to není takovej pruser.. v kazdym pripade to je vitana vzpruha do site

hapi

Uvědomte si taky, že v6 je pořád rc, ohledně QT může být ve stable verzi vše jinak.

no tak vo ton dost pochybuju. Proč by to rušily? technicky neni mezi global in a out rozdíl.

radekulehla

Uvědomte si taky, že v6 je pořád rc, ohledně QT může být ve stable verzi vše jinak.

no tak vo ton dost pochybuju. Proč by to rušily? technicky neni mezi global in a out rozdíl.

Tak ne. V changelogu ros6 je toto popsáno, takže to je opravdu záměr. V tom případě jsou narážky na mikrotik, že nikomu nic neřekne bezpředmětné.

ppp76

Tak co se tyce global tak ispadmin by to uz mel mit poreseny v poslednim update

jap

tak jsem zkusil udp flood na ccr a celkem to ustal :-)

udp flood z linuxu

./udpflood_multithread.pl 192.168.88.1 0 64 300 5 0

[x]Valid IP check...

[x]Port Check...

[x]Packet Size Check...

[x]Valid Seconds check...

[x]Valid Threads check...

[x]Valid "Show Each Packet" variable...

Continue?[y/n]

[UDP Flooding] 192.168.88.1 | PORT:random PacketSize:64-byte Seconds:300 Threads:5

Thread:0

Thread:1

Thread:2

Thread:3

Thread:4

Thread:5

a co na to ccr?

[admin@MikroTik] > /system health print

fan-mode: auto

use-fan: main

cpu-overtemp-check: yes

cpu-overtemp-threshold: 100C

cpu-overtemp-startup-delay: 1m

active-fan: main

fan-speed: 5448RPM

fan-speed2: 5211RPM

temperature: 40C

cpu-temperature: 53C

[admin@MikroTik] > /system resource monitor

cpu-used: 87%

cpu-used-per-cpu: 90%,85%,90%,86%,89%,88%,88%,88%,90%,78%,86%,90%,90%,87%,88%,89%,87%,90%,87%,88%,91%,90%,87%,88%,90%,90%,88%,89%,90%,89%,86%,88%,88%,88%,90%,75%

free-memory: 3620480KiB

[admin@MikroTik] > /interface monitor-traffic ether1

name: ether1

rx-packets-per-second: 350 300

rx-drops-per-second: 0

rx-errors-per-second: 0

rx-bits-per-second: 297.0Mbps

tx-packets-per-second: 116

tx-drops-per-second: 0

tx-errors-per-second: 0

tx-bits-per-second: 127.2kbps

[admin@MikroTik] >

zatez cpu vyletela na chvilku jen na zacatku floodu. fllod sel na ip adresu ccrka.

radekulehla

Na CCRku byl DROP, REJECT nebo ACCEPT?

jap

Na CCRku byl DROP, REJECT nebo ACCEPT?

nebylo tam nic, ale muzu tam zkusit dat nejake pravidlo nebo pravidla..

takze nova zkouska, 200 pravidel:

[admin@MikroTik] > /ip firewall filter print

Flags: X - disabled, I - invalid, D - dynamic

0 chain=input action=drop protocol=udp dst-address=192.168.88.1 dst-port=1

1 chain=input action=drop protocol=udp dst-address=192.168.88.1 dst-port=2

2 chain=input action=drop protocol=udp dst-address=192.168.88.1 dst-port=3

3 chain=input action=drop protocol=udp dst-address=192.168.88.1 dst-port=4

4 chain=input action=drop protocol=udp dst-address=192.168.88.1 dst-port=5

...

195 chain=input action=drop protocol=udp dst-address=192.168.88.1 dst-port=196

196 chain=input action=drop protocol=udp dst-address=192.168.88.1 dst-port=197

197 chain=input action=drop protocol=udp dst-address=192.168.88.1 dst-port=198

198 chain=input action=drop protocol=udp dst-address=192.168.88.1 dst-port=199

199 chain=input action=drop protocol=udp dst-address=192.168.88.1 dst-port=200

a ted je to zajimavejsi:

./udpflood_multithread.pl 192.168.88.1 200 64 300 5 0

[x]Valid IP check...

[x]Port Check...

[x]Packet Size Check...

[x]Valid Seconds check...

[x]Valid Threads check...

[x]Valid "Show Each Packet" variable...

Continue?[y/n]

[UDP Flooding] 192.168.88.1 | PORT:200 PacketSize:64-byte Seconds:300 Threads:5

Thread:0

Thread:1

Thread:2

Thread:3

Thread:4

Thread:5

[admin@MikroTik] > /interface monitor-traffic ether1

name: ether1

rx-packets-per-second: 313 760

rx-drops-per-second: 0

rx-errors-per-second: 0

rx-bits-per-second: 266.0Mbps

tx-packets-per-second: 2

tx-drops-per-second: 0

tx-errors-per-second: 0

tx-bits-per-second: 4.4kbps

[admin@MikroTik] > /system resource monitor

cpu-used: 100%

cpu-used-per-cpu: 100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%,100%

free-memory: 3765888KiB

hapi

skuz nějakej normální test. Pro začátek třeba 100, 200, 500 nebo 1000 manglů a skrz to pust jenom FTPčko co to udělá. Někde vyhrabu jak to mávalo s atomem.

radekulehla

Když už bych to testoval UDP floodem, tak bych tam dal jedno pravidlo na všechny UDP na input, nevím proč tam máš dst-nat.

A hlavně bych to testoval vždy při stejném floodu, třeba 200Mbps a z pak bych reportoval výsledky celkového zatížení CPU vůči jiným platformám. Ale tak jako tak je UDP flood test dobrý max. na zjištění, jak se to bude chovat, když někdo bude ten flood dělat.

90% lidí si už díky grafům, co posílal kolega, dokáže zhruba představit, co CCRko utáhne. Zbytek, včetně hapiho si to musí otestovat jinak :)

PS: Hapi, když pošleš konfiguraci, která půjde do CCRka naimportovat, tak při dalším nákupu CCRka, tu konfiguraci můžeme otestovat. Nedělám to, že bych Ti chtěl pomoct, ale aby si viděl, že x86 v podobné cenové relaci tohle prostě nedá :)

hapi

fajny, importy ti mohu poslat abych ti ukázal jak tomu xeon natře :-) připravím je. Můžu pak skusit nějaký testy co ty na reálnym železe a můžeme to porovnat. Akorát tam nemám v6 a pokud xeon neuspěje tak jsem ochotnej v6ku na GW risknout :-)

majklik

Hapi, V6 bych se možná na GW ještě bál, ale pokud ti to jen NATuje/shapuje, tka asi OK. Comám testovací sestavu nkolika routerů, tak je aktuálně u rc6 ta střední doba vytuhnutí 4 dny (ale je v tom nacpáno vše možné - OSPFv2/v3, BGP, IPsec, GRE tunely, SSTP, VRRP, DHCP, NAT, ...).

Add CCR, nezkoušel jste náhodou někdo, kolik to dokáže dát při šifrování IPsecu? Potřeboval bych nějak aktuálně pořešit něco, co dá aspoň 1 Gpbs (ideálně 7 tunelů po 1 Gpbs). Škoda, že to CCR nemá aspoň jeden (ideálně 2) 10 Gbps porty. Pokud by to dalo aspoň 1 Gpbs jeden port dovnitř data, druhým portem zašifrováno, tak jich bednu/dvě uživím. :-)

Ten procák má hardwarovou podporu pro IPsec, ale Mikrotikové přiznávají, že ji v této chvíli nepoužívají, že časem, ale kolik to umlátí jen v CPU softwarově neuvádí. :-(

radekulehla

Tak si domluv zápůjčku, každý solidní prodejce to udělá.

jap

Když už bych to testoval UDP floodem, tak bych tam dal jedno pravidlo na všechny UDP na input, nevím proč tam máš dst-nat.

je to na inputu, ne dst-nat. dobre na tom aspon je, ze to ten udp flood ustoji a da se to stale ovladat..

0 chain=input action=drop protocol=udp dst-address=192.168.88.1 dst-port=1

radekulehla

Špatně jsem se podíval, ale i tak stačí jedno pravidlo pro udp.

« Předchozí stránka Další stránka »