Ubnt vagy Mikrotik

Hálózatok általános

Szisztok,

Otthonra akarok venni egy kis routert (min ethernet 10/100, n WiFi, ~80$ körül) és két márka között dilemmázok.

Ubiquiti airRouter --> http://www.ubnt.com/airrouter

Mikrotik routerek --> http://www.wireless-bolt.hu/products.php?prcategory=6819&PHPSESSID=d059…

A kérdés egyszerű: kinek mi a tapasztalata ezekkel a routerekkel? Melyiket választanátok és miért?

Ha valaki már jobban benne van az airOS-be és tudna részletesebb véleményt mondani, az is érdekelne.

  • 19449 megtekintés

( _ventura_ v | 2013. 02. 08., p – 13:14 )

Airrouter alap szoftvere kb egy sima dsl router tudásával ér fel.
Persze openwrt vel "bármi" rárakható.

Mikrotik meg egy full router funkcióval bírós eszköz, értem ezalatt hogy pppoe koncentrátort is faraghatsz belőle de akár BGP routert stb.

Fedora 17, Thinkpad x61s

( Seaweed | 2013. 02. 08., p – 14:25 )

Ha kicsit komolyabb kell RouterBOARD 751G-2HnD-nél akkor én a RB2011UAS-2HnD-IN ajánlanám, bár ez többe kerül mint a belőtt pénzkeret.

Ahogy elnézem mind a RB751G-2HnD és a RB2011UAS-2HnD-IN is tud b/g/n wifit, legalábbis adatlapja szerint, mert én a RB751G-2HnD-t csak G-s wifivel tudtam kipróbálni. Azzal az 54Mbit megvan.
Meg kapni is lehet a 2011-et: http://www.wireless-bolt.hu/detailproduct.php?productid=537702

( subscope | 2013. 02. 08., p – 15:46 )

Utobbi pár hónap tapasztalata.

Mikrotiket sok helyen használjuk, de az utobbi pár hónap rossz tapasztalatai miatt felfüggesztettük a beszerzésüket és telepítésüket. ROS tényleg nagyon jó és szeretjük, de wirelessben nagyon gyatra teljesítményt produkálnak házon belül. 4 hónap szenvedés után feladtuk, hogy Mikrotik eszközökkel építsünk wireless hálózatot. Az alábbi eszközöket nem ajánlom a wireless problémáik miatt:
- RB2011UAS-2HnD-IN
- RB951-2n (<-- Ez a cucc amúgy is egy vicc!)
- RB751G-2HnD
- RB751U-2HnD
- RB711UA-2HnD

Más gyártók (Apple, TP-Link, Ubiquiti) wireless eszközei megfelelően működtek ugyanabban a közegben, ahol a fenti RB-k nem.

Hat nalunk pl elegge szar a hatotavolsag. Egy idoben ledobalta az embert, a a ping neha neha megugrik eleg magasra es a voip hivasok pl nem mindig hasznalhato minoseguek wifin keresztul. Az igazsaghoz az is hozza tartozik, hogy kb 20 wifit latok szoval elegge telitett a dolog.
8.8.8.8 pingtesztje wifirol min/avg/max/stddev 53.3/83.3/379.1/64.5
8.8.8.8 pingtesztje lanrol min/avg/max/mdev 42.9/45.5/77.8/3.5

És mennyi wireless klienst szolgál ki egyidőben?

Amúgy az 30dbm teljesítményű adót sem látom indokoltnak ezekben az eszközökben.
Mi is azzal kezdtünk mindig, hogy beállítottuk a frequency mode-ot regulatory domain-re és utána kezdődött a finomhangolás. Jobbára felemás eredménnyel.

Ez csak 5-t jelenleg (bár ebből 3 N-es eszköz azokon gyakorlatilag 10MB/s sebességet tud maximum, ugye nem 5GHz-es).
Előző cégnél 433-asok voltak, azon 10-15 kliens volt egyidőben, azzal sem volt gond, bár az az r52-es kártya egy foshalmaz ami volt benne (attól függetlenül, hogy működött).

Én a 2011-est 17-re vettem le, de még az is erős néha (főleg, hogy ezeken logitech "minőségi" hangfalaimon lehet hallani néha :) ).
A konfigba annyira nem mászok bele inkább, minél kevesebb dolgot állítgat rajta az ember annyival kevesebb hibalehetőséggel lehet találkozni.
Mekkora területen van ez amit használnál? Vagy közvetlen közelben az összes eszközzel is szarakodik?

Otthonra elmennek ezek az eszközök 4-5 klienssel, de nagyobb méretű wireless hálózatnál (itt 802.11-re gondolok) már bajos.

Nálunk viszonylag egyszerű volt a konfig: ap bridge, multi ssid/vlan.

Tapasztalat:
- kliens csatlakozott, CCQ jó, de a csatornán forgalom egyszer csak megtorpan, majd egy kis idő elteltével megindul a forgalom
- Virtual AP-t használva a wireless kapcsolatt stabilitása tovább romlott, így használhatatlan
- WDS/mesh lassan áll össze és kegyetlen instabil
- több órán keresztül elfogadható teljesítménnyel működik az eszköz, majd egyszer gondol egyet és belassul; nem enged fel klienseket; újraindítás után megszünik a jelenség átmenetileg;
- a legrosszabb, hogy folyamatosan ingadozik a wireless teljesítménye (késleltetés, sávszélesség/kliens)

Még a fentieket el is tudnám fogadni, ha az ugyanebbe az árkategóriába tartozó eszközök esetében is ezeket tapasztalnám. Ellenben azokkal nem volt ilyen gond.

Továbbá érdemes átfutni a Mikrotik forumot, mert hegyben állnak a wireless-szel kapcsolatos problémákkal foglalkozó post-ok.
Régebben sokkal jobbak voltak az RB-k. Szomorúan vettem én is tudomásul a fentieket...

Ahova mi raktunk ilyen eszközöket még anno nem volt gond, mondjuk legtöbb helyen ugye sima routing-ra lettek kihelyezve, semmi bridge (arról hallottam ódákat, hogy sz.r). Én nekem itthon tökéletes, mint írtam, és volt cégnél is meg volt vele mindenki elégedve. Amit észre vettem, hogy néhány intel kliens nem szerette ezeket az r52-es wifi kártyákat a mikrotikekben (kb amit te írsz a belassulásról), viszont a mikrotik eszközök egymás között mindig megfelelően működtek (mondjuk valszeg te kicsivel több helyre telepítesz ilyet, így valszeg relevánsabb a te tapasztalatod ).

Más szemszögből. A bride-ing a Mikrotik-ben nem szar. Teljesen jó. A probléma az hogy a MT-ék a soho irányába most(3éve) nyitnak, és eddig saját pályán fociztak. Eddig is sok kliens kompatibilitási probléma volt. Az "n" rendszerű wifi megoldásuk pedig egyszerűen csapnivaló (mixed környezetben). A problémák forrása ez.

Köszi, nem árt tudni az ilyeneket. Ilyen szintű wifi hálózattal nem foglalkozom/tam. Ezen a szinten(pl.vlan) én "be vagyok gyöpösödve", ha lehet inkább a kábel/optika-t (ha kell a sávszél) forszírozom. Illetve nem hozta még úgy hogy kénytelen voltam wifivel megoldani.

Es azt meg lehet kerdezni, hogy te milyen eszkozoket ajanlanal *belterre*, ha mar nem mikrotik?

Mondjuk egy 5 vagy 10-es listat irhatnal, amik szerinted betonstabilak.

En most szeretnek egy tenyleg popec wifi routert venni, es mar ugy vagyok vele, hogy inkabb raaldoznek egy nagyobb osszeget, mert szivni mar szivtam eleget (volt mar vagy 10 fele router itt. Egyiknek a hatotavolsagaval volt gond (konyhaban meg jo, szobaban mar nem), a masik pedig 2-3 hetente kifagyott, es fizikailag ki kellett huzni a konnektorbol).

Szoval erdekelne, hogy egy kis irodas kornyezetbe, vagy otthonra te milyet ajanlanal. En a RB2011UiAS-2HnD-IN -t neztem ki, de teljesen elbizonytalanitottal.

Udv.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nekem a fogy.védők azt mondták, a 8 nap független az átvétel módjától. Ha webáruházban vásárolsz, személyes átvétel esetén is élhetsz az elállási joggal. Persze ahány bolt, annyi értelmezés, szóval nem árt előtte rákérdezni.
A 30 nap az mi? Olyanról még nem hallottam.

Megpróbálom értelmezni a jogszabályokat...

Ha minden tájékoztatást megkapsz (írásban), akkor a termék kézhezvételétől számított 8 munkanap van az elállásra.
Ha nem kaptál tájékoztatást (ami nem csak az elállási időt tartalmazza!), akkor 3 hónap.
Ezt nem írhatja felül semmilyen szállítási feltétel. Ellenben vannak olyan termékcsoportok amikre nem vonatkozik az elállás joga.

Az új PTK március 15-i hatályba lépésével 14 napra módosul az elállási határidő.

A pénzvisszafizetésre van 30 napja az eladónak.

Viszont van egy érdekes rész a 17/1999. (II. 5.) Korm. rendelet 3. § (1) pontjában, miszerint
„A vállalkozás köteles a ... tájékoztatást írásban - papíron vagy más, a fogyasztó számára hozzáférhető tartós adathordozón - a fogyasztó rendelkezésére bocsátani.”
Nos, kérdés, hogy mi minősül tartós adathordozónak.

Ilyen alapon akkor sem vagyok távollevő, ha futár hozza ki.
Nem tökmindegy ilyen szempontból, hogy én megyek az átvételi pontra a készülékért vagy a futár?
A lehetőségeim az áru ellenőrzésével kapcsolatban azonosak. Nagyon ritka, ha egy webáruház átvételi pontján a csomagolás sértetlenségén túl bármit is meg tudok nézni vásárlás előtt, az elállási jog meg azért lett kitalálva, mert gyakorlatilag látatlanba vásárolsz, sok esetben nagy értékű műszaki cikket.

Közben megtaláltam a forrásomat is: http://www.nfh.hu/magyar/hasznos/panaszintezes/onnelis/onnelis_1

Megkaptad a mail-t amit kuldtem nem reg! 6 eszkoz egy mikrotik rb532-on (vagy 6 eves cucc), fejenkent a 35 megabol 5-6 mega ment at, amikor egyszerre terheltuk. Most akkor mert mondod, hogy szar? :)
Nalunk jol mukodnek a mikrotikek, unifi is jo, sot egyre jobban tetszik. :) De mikrotik se szar. :)

--
http://szolarenergia.hu

Pedig sajnos egyre több a probléma az MT-s cuccokkal, mind HW, mind SW oldalon. A régi HW-kel sokkal kevesebb probléma volt, ha volt. SW is kevesebbet tudott, de azt legalább jól.
A baj ott kezdődik, hogy ha nincs support sem kereskedői oldalon, sem gyártói oldalon.
Továbbá az MT-s forum hűen tükrözi, hogyan fogják fel a QA-t a gyártónál.
Szerintem ha így folytatják, akkor szépen lassan leépítik az MT eszközökbe vetett bizalmat és sokan inkább más gyártók felé veszik majd az irányt.

Régebben csak 450G-t használtam. A kondi cseréken kívül semmi gond nem volt velük.
Wifinek beltérre 411+R52nM ment.
Abban igazat adok az előttem adónak, hogy a kis szériás(SOHO-nak is árult) wifis eszközök nem az igaziak. Viszont szerintem nem kell összehasonlítani a kis szappantartókat a RB1xxx vagy CCR sorozattal, noha mindkettőn Mikrotik felirat van. (Cisco vs. Linksys-Powered by Cisco)

Amiket most használok:
RB-2011-UAS-RM
Unifi AP LR (beltérre wifinek csak ez)

Ezek, amiket még a cégek talán megfizetnek és működnek is.
Szoftveresen a Mikrotik egyre instabilabb.

de te is lattad hogy naluk meg mennyire nem mukodott, 3-4 eszkoztol is lehasalt... az meg hogy korlatozzam be 1 mbit/user hat minden csak nem megoldas :)
amugy is azt javasoltad kapcsoljuk ki az N-t es legyen csak G-s wifi, mert ugy stabilabb. 2013-ban ez mar egy kicsit sovany, 10g-s neten plane...

az elso mikrotitek meg jok voltak, az egyik a mai napig mukodik (a masik elfustolt), sot kb az az egyetlen ami jol mukodik, a kesobbi beszerzesekkel van gond. es vszinu nem szoftveres, mert egyre raktam openwrt-t es azzal is ugyanolyan szar volt, szerintem a wifi kartya benne nem jo, vagy inkabb ptp kapcsolatra valo es nem ap-nek.

A'rpi

( Kitsune | 2013. 02. 08., p – 22:29 )

Köszönöm a válaszokat. Az eddigiek alapján úgy tűnik, hogy Mikrotik lesz :-) Még a wireless ellenére is.

( willy v | 2013. 02. 09., szo – 08:33 )

Az a kérdés mennyire szereted lekötni magad:
Mikrotik: alapvetően jó szoftver, ipari minőséghez közeli hw.
Problémák: Support: szinte 0. Az a probléma amit 20-an jeleznek legalább és adnak róla sup-out-ot! Itt nem arról van szó, hogy a javításhoz ismerni kell a problémát, mivel a bejelentések általában két fajtába tartozik (95% a support requesteknek). Első: nem érti hogy működik a szoftver (mindegy hogy az elégtelen doksi, vagy vagy az hogy a kliens nem olvassa el). Második: pontosan tudja hogy kellene működni, és default beállításokkal tesztelve leadott hibajelenségről a "support" "műveltetés" jogcímen (időhúzás) kér különböző adatokat, ahelyett hogy a részletes hibát saját eszközein tesztelné. Mikor ezeket megkapja, közli hogy a hiba nála nem jelentkezik. Jön a videó dokumentáció. Erre hosszú csend, és néha (fél/egy év is akár) csendes módosítással javítják a hibát amiről tudják hogy létezik.
Ez a zárt és rossz supporttal működő OS problémája.
Tanács: ha megveszed, működik, "nempiszkálod örülszneki". Ha nem működik, eladod és váltasz. Supportot nem kifizetődő kérni.
A HW: néhány rossz széria kivételével nagyon korrekt.
AIR: sajnos kevés tapasztalatom van vele, viszont az jelentősen negatív. Support: kicsi tapasztalat, az alapján korrekt.

Otthoni megoldásnak mindkettő jó lehet. Otthoni felhasználásra az RB-751G típusból van tapasztalat(50+). Kielégítően működik, de wifi kompatibilitási problémáid a kliens eszközökkel lehetnek.

Arra gondoltam, hogy olyat veszek amire a legrosszabb esetbe is rá lehet tenni OpenWRT-t és akkor ha a sw nem is jönne be, ezzel kiküszöbölhető.

EDIT:
A vége OpenWRT lett. Valóban rengeteg funkció van a Mikrotik eszközökben, azonban, ahogy az előttem szóló is írta support elég gyenge. Konkrétan van, hogy napokig nem válaszolnak egy VPN problémára. Az eszköz sw részébe pedig nem lehet belenyúlni.

Picit olyan érzést kelt ez az egész, hogy mindent bele akarnak tenni az eszközükbe, viszont ez még messze nem az igazi.

( Semir | 2013. 12. 23., h – 01:54 )

Mikrotik:
jó, ha jó.
Én nagyon megégettem vele magam. Igaz a CCR miatt 6-os verzióval és veszett instabil volt. Support nyomta az fw frissítéseket, volt, ami rosszabb volt az előzőnél. Jelenleg épp utazik vissza a gyártóhoz.
DE! Akinél/akinek megy, annak stabil és megy. És rendkívül kényelmes, az tény.

A 36magos CCR-t már használjuk egy ideje, pppoe koncentrátornak. Aztán másfél hónapja megjöttek a 10GbE portos ccr-ek, akkor 6.4 nél járt a mikrotik. beállítottam koncentrátornak, asszem 2 órát ment és összeszakadt. Aztán kijött a 6.5 verzió, itt már javították 10GbE drivert. Azóta is megy szépen. Csúcsidőben vagy 1000 usert szolgál ki akár 6-700Mbit-el. CPU meg olyan 20% csúcsterhelésnél.

Ez az első olyan termékük amire azt merem mondani jó a teljesítménye. 8 magos 6128as opteronokat váltottunk ki velük.

A régebbi 4SFP-s CCR routernek szar a tápja, nálunk is pukkant már el, persze RMA ban cserélték.

Fedora 19, Thinkpad x61s

hali,
én láttam rajta Gbit dost átrouteolódni. Tyű, nem emlékszem már, hogy az mennyi packet volt, de pár millió packetig nagyon jól bírta. Queue nélkül, kb 25 nem alap tűzfal szabállyal.
Az ipv6 jobban megfogja a procit, 600-700Mbit már teljesen 100-ra tette.

mikrotik fórumon láttam bondolt 2x10Gbitet, amin átküldtek rajta 20Gbitet full duplex. Szóval van benne szufla, de ez az instabilitáson nem segít.

Nálam egyébként HW hibának tűnt a bizonytalanság, de nem erősítette meg a gyártó. Kb pont úgy tűntek a restartok, mint egy hibás memória esetén, vagy rossz CPU hűtésnél.

A 6.4-es pár órát volt fent nálam is, kritikán aluli volt.

csak hiszed :D
Hányszor csinált nekünk olyat hogy felvettünk 1 vlan-t és összeszarta magát. Szóval az hogy server semmit se számít. Max teljesítményben, bár ez már megvan a CCR sorozatban. Miután lecseréltük az x86 szervereket CCR-re semmivel nem lett jobb vagy rosszabb a stabilitás. Viszont energiahatékonyság sokkal jobb :>

Fedora 19, Thinkpad x61s

mini itx + 44ge "kicsit" olcsóbb, igaz biztos elmarad ccr-től teljesítményben (habár iperfel full gben 800mb tudtam kihúzni 100tcp szálon,10%cpu mellett ami nem egy laborteszt nyilván..) mindenesetre elgondolkodtató a ccr!
Teljesítménybe meg itx 35-40w.

Agyalós melyiket éri meg...

van, ahol HP microservert használok (az csak apróság, h pont a fenti - Mikrotik gyártású - 44GE kártyával többször újraindult naponta) intel PCI-E (dualport) server kártyával.
az RB1100AH(x2)-t simán túlteljesíti (és sokkal nem több a fogyasztása sem).

Nyilván van jó cucc a CCR, de ahol ekkora teljesítmény kell, ott (szerintem) inkább az a fontos, h stabilan menjen, mint az, h 20W vagy 200W a fogyasztás.

Egyébként egész biztos vagyok benne, hogy teljesítményben jobb, mint egy PC-s megoldás.

A stabilitásáról még annyit, hogy nem sokak jártunk így. A fórumon is max 1 v 2 hasonló eset volt, és a viszonteladó is azt mondta, hogy nem találkoztak még ilyennel.

De ha nem tudod tesztelni, élőben ez nagyon kellemetlen tulajdonság, ha pont te leszel MO-n a második :)

pár millió packetig egy E3 CPU-val bíró PC is nagyon jól bírja, sőt! egy tisztességes PCI-E server NIC az multiqueue, uezt emlékeim szerint a CCR nem mondhatja el magáról.
A másik, hogy a PC-ben ketyeg egy 2-3GHz CPU (ami többmagos) a CCR-ben pedig 1.2GHz (sokmagos) CPU van.
Nem minden esetben skálázható a feladat, van ahol a GHz a számít (és a lekezelhető interruptok száma). Ha jól tudom, akkor ilyen a firewall és a queueing is.

Stabilitás: a CCR-t kiszállították egy csomó hibával, amit a telepített és élesben futó rendszerekben álltak neki orvosolni, mert az adott hiba laborban nem jött elő. Erről tudtommal elég sokat írtak a fórumban is.

Ja, junosban csinálták meg juniperék, hogy az egészet ráültették freebsdre, majd -- nem tudok másra gondolni, mint hogy szar az irq kezelés az OSben -- odatettek egy processzt, ami izomból pörgeti a procit, és pollozza a queuet, hogy "Vanújpacket?Vanújpacket?Vanújpacket?Vanújpacket?"

Csudi :)

Sajna vissza kell vonnom ezt az állítást.Ma kiderult hogy egy rakat szar :D

Persze valszeg nem a hw a hibás hanem az sw maga.

Ma DDoS oltak minket mint gép, gondoltam, hogy legyen valami jó is a dologban, elkezdtem tesztelni. egyik gigabites portot fullra tolták, kb 100e packet/sec el. Gondoltam beteszek egy CCR 36 magos router 2 portjat sima bridgkent majd ip->firewall nal szurok ezt azt.

ether1 en bejött a 100e pps, ether2 meg kiment ugye tovább, eddig szép és jó. Ekkor fogtam egy sima firewall szabályt, ami kb annyi volt hogy a forward láncon minden csomagra accept. Ekkor jött a gond ugyanis ether1 en bejött 100e pps de ether2 már csak 5-800mbit ment át ami 60-80e pps, tehát valahol eltünk majd a forgalom fele, gondolom dropolta stb franc tudja. CPU használat alig volt 20%. Mondom hát akkor ennyit tud CCR.

Elővettem egy HP DL szervert 8magos 6128as opteronnal, hasonló volt a helyzet. Akkor elővettem egy másik vasat amiben 2db X5690 es xeon van ez ugye 6 mag/cpu. Ez még rosszabb volt mint a 8 magos opteron. Mondom ennyire tuti nem szar a hw. Fogtam erre a 2 cpu-s vasra rament egy sima linux + bridge utils. Megcsináltam a bridget, hasonló iptables -I FORWARD -j ACCEPT szabállyal és láss csodát, nem tűntek el a csomagok, ami bejött ehther1-en az kiment ether2-n.

Magyarán a mikrotik OS valahol nagyon el van rontva, de nagyon.

Fedora 20, Thinkpad x61s

haha. én nem akartam erősködni... :-)
a hw tényleg ígéretesnek tűnik, de kéne valami, ami meghajtja...

én iperf-el próbálgattam miket tud a mikrotik RB1100AH (akkor még az volt az aktuális topmodell) vs PC (intel 1U server, alap i3).

Az 1100AH ~1.3 gbps-nél elfogyott (nem, nem volt firewall szabály SEM) - ellenben a PC röhögve vitt (összesen) 2 millió packet/sec-t. (1gbps fullduplex egyik lábon be, másik lábon ki - 500k pps/irány)

Sajnos a te problémád is olyan, hogy nehéz reprodukálni - pláne nem akarod éles hálózaton - és a mikrotik support kérdése pedig:
- újraindítás volt?
- sw a legújabb?
- netinstall esetén is ezt csinálja?

Mi működik? Mikor leírsz ilyet légy szíves fogalmazz már egyértelműen, és legalább azt olvasd el mi van az előzmény írásban. A slendriánság (nehogy személyesre vedd, rohadt sokan így írják) az kiütközik itt is. Az iptables egy frontend és egy userland rész a kernelben lévő netfilter nevezetű csomagszűrő tűzfalnak nevezett kódhoz.
A bridge-lt csomagok nem minden esetben mennek át a netfilter routingra felállított részén, ezért a filter table FORWARD chainben deklarált szabályok általában nem vonatkozhatnak rájuk (bridge nf hook pl kivétel). Pláne hogy ha nem tudod pontosan mit akarsz, akkor nem célszerű nekiállni iptables frontend-el konfigurálni a bridge szűrést.
Ha úgy állsz neki megfogni egy DDOS-t, vagy legalább tesztelni, hogy nem tudod mit csinálsz, a kapott eredmény is igen homályos lesz.
Figyelmedbe ajánlanám a következő két linket:
A linux bridge/routing tűzfal együttműködéséről és a csomagkezelésről ezt
különös tekintettel erre az ábrára.
A fenti leírások a netfilter eb (ethernet bridges) kódjára vonatkozó hivatkozások.
A 2.6-os kernel óta Létezik lehetőség, hogy átvezesd a bridge-nf kódon is a bridgelt csomagokat, ha a sysctl net.bridge.bridge-nf-call-iptables
ha 1-et ad, akkor tapasztalhatod hogy a filter table a bridgelt csomagokra is vonatkozik ezért tapasztalhatod a fenti működést. (továbbra is ajánlott az ebtables és az ott található filter)
Komplett NF ip flow
Hogy örülhessen mindenki, és ha nem szakad teljesen félbe akkor a mostani ip/arp/ebtables frontendeket le fogja cserélni az nftables frontend...
Mikrotik esetén különösen igaz a fenti, mint írtam a terméktámogatásuk csapnivaló, de a legtöbbször a hiba oka hogy a felhasználó nem ismeri a szoftvert. Néha ez azért van, mert nincs is dokumentálva, néha csak szarul van dokumentálva, de a legtöbbször csak az user nem ismeri, ezért a fenti példához hasonlóan ezt a linket ajánlom sokat segít terhelési tervezésnél. Persze azt sem árt, hogy ha tudod, hogy a mikrotik mögött is ugyanaz a megoldás működik mint amit fenti link is taglal, csak más a konfig felület, van néhány extra driver és modul.

Az volt teszt célja, hogy alkalmas-e a mikrotik transparens proxynak.

Áthajtjuk bridgen a forgalmat és ha kell iptables-el manipulálunk, nem pedig az ebtables-el. 6.7 es mikrotikban ugye külön kapcsoló, hogy a bridge forgalmát áttoljuk-e a filter láncon.

Nem DDoS megfgása volt a cél, hanem a mikrotik tesztelése. Az hogy az a 100e packet miből jött össze szerintem lényegtelen a lényeg, hogy ha bejön ether1 en 100e packet akkor ha van FORWARD -j ACCEPT az IP->Firewall-ban akkor ott 200e pps nek kell lennie, és ether2 is kell lennie 100e pps nek. Ezzel szemben az volt hogy mind a filteren mind az ether2 50-80e pps volt, mikrotik esetében, míg linuxnál kijöttek a számok.

Szóval nem tudom mit ronthatnék el, ami miatt a mikrotiknél nem jönnek ki a számok, de ha tudsz ilyet szívesen fogadom.

Fedora 20, Thinkpad x61s

Most már többet értek. Alapvetően nem javaslom az eszközt erre, mivel nem erre tervezték (itt gondolok a DDoS esetekre is). Alternatív javaslat: DDoS-ra is felkészülve kell valami egyszerű első védelmi vonal ami a leggyorsabban képes szűrni IP forrás/cél alapján a bejövő csomagokat erre valamilyen switch/router ajánlott a bejövő interfészen ahol a switchportra telepíthető egyszerű IP szabály. Gondolom IP forrás/cél szűrésen kívül nem akarsz más szabályt használni DDoS esetén. Erre bejövő forgalom és persze elmaradt jövedelem alapján 7ezer-70millió forintig elérhető hw. Ekkora forgalomra akár még a 7e Ft-os is elég lehet, persze én nem terveznék vele szolgáltatási célra. Mivel írtad, alapvetően nem a DDoS védelem a cél, arra alkalmas lehet az az eszköz(CCR1036) sőt alap konfig alapján még a DDoS védelemre is képes lehet. Azaz vázolt esetet elvileg és gyakorlatilag is bírnia kell ennek a konfignak.
A vállalt performancia a gyártó részéről:

CCR1036-8G-2S+(ROS v6.x)

64byte kpps Mbps
Bridging(fp) 41636 27313.2
Bridging(filter 5817 3816.0
Routing (fp) 41636 27313.2
Routing (filter) 3081 2021.1

512byte kpps Mbps
Bridging(fp) 6574 27873.8
Bridging(filter 5630 23871.2
Routing (fp) 6574 27873.8
Routing (filter) 2796 11855.0

Az hogy 1500 byte-os csomagokat tudja mindenképp wirespeed-el azt most hagyjuk ki, minthogy az is látható hogy max 42M pps-t tud szűrés nélkül max.
A kiemelt két mérési eredmény alapján az is látható, hogy routingban kb a felét tudja a router.
Természetesen interfész queue-val még rontható a fenti statisztika, de ezt most hagyjuk.
Ahogy fent látható a legrosszabb konfig esetén 2800e pps jut az adott eszközre és ez 512byte csomagméret alapján jön létre, ami ha súlyozva elosztjuk (azaz nem csak 2 interfésszel számolunk) az 100e pps/port a 8 beépített és 1m pps a 2 SFP+ interfészen, összesen ~11Gbyte/s forgalommal ami ugye annyi hogy még a két SFP+ port esetén se lenne elég azaz nem tud wirespeed routingot a két SFP+ interfész között, ha IP routingot használnál, mivel azonban bridge konfigról lenne szó, az is látható, azt kb wirespeed-el tudja, azaz átlag alatti normál forgalom maximális terhelés esetén szűrést tudnál bridge szűréssel.
Alapvetően tehát ebben az esetben az a kérdés, az adott csomag eljut e a kernelig, és ha igen milyen bonyolult a feldolgozás, mennyi megszakítást generál. Azonban maga a gép, az igényelt konfigra alkalmas.
A fentiekből kiderül, hogy bőven alatta van az általad említett esemény az eszköz natív képességeinek. Itt gyakorlatilag a MT elemzést befejezném mert bőven túlmegyünk ezen a kereten ami ide elfér a többi olyan meló ami általában teljesen üzleti alapú és ha kell segítség megoldod olvasással, support requestel (bocs ennél azért felröhögtem, sajnos elég sok tapasztalatom van, de talán...), ha esetleg nem menne keress meg privátban...
Visszatérve, az MT ugyanazt a kernelt használja jó eséllyel amit te is használnál ?ubuntu? alatt.
Ezért igaz az is, hogy kb ugyanazokat az eredményeket kell kapnod ugyanolyan beállítások esetén. Én javaslom még egyszer nézd át amit fent linkeltem wikipédiás képet és az MT packet flow-ját. Nézd meg hol hibáztál, a monitoring, statisztikai lehetőségeket is célszerű lenne használni.
Valamint még egyszer kiemelném, hogy ethernet csomagot akarj szűrni, jóval olcsóbb a feldolgozás.

Mint mondtam az én célom a tesztelés volt. Az hogy mire fogjuk tudni használni. Számomra eddig annyi derült ki, transparens layer3 tűzfalnak alkalmatlan. Nem csak a CCR hanem az egész mikrotik OS. Használjuk őket PPPoE koncentrátornak. Viszont ezek után kezdenek kétségeim támadni. Ugyanis pont amióta beraktuk jönnek az ügyfél jelzések hogy lassú a net. Eddig nem nagyon hittünk nekik, mert a CCR cpu-ja 20%-25% ot mutatott csúcsidőben. Úgyhogy jövőhéten meglesem mi a helyzet.

Mennyi az annyi, mert sajna mikrotiknál nem nagyon jöttek ki azok a számok amiket ők mondtak. :>

Fedora 20, Thinkpad x61s

Ezt nem igazán értem. Hol függ össze az ebtables és az iptables?
Egyik L2, másik L3 rétegben működik, amennyire tudom.
(illetve az ebtables elég felemás, mert alapjában véve L2-ben lenne a helye, de beleüti az orrocskáját az IP témába is :) )

Volt olyan, hogy az iptables-ben beállított szabályok nem működtek, ha bridge-en jött a hálózat?
Vagy valamit szokás szerint félreértek?

( tomeeSAN | 2013. 12. 24., k – 10:18 )

Egy alternatív vélemény...
Nekem nem jött be a RouterOS. Valahogy nem olyan logikával működik amit könnyen megértettem volna. Egy rb2011uas-2hnd-in volt az áldozatom. Sokmindent meg tudtam csinálni vele, de sosem voltam készen vele.
Váltottam ubiquiti-re.
Edgerouter Lite...
Vyatta alapú akár beismeri hivatalosan akár nem. Ezt a logikát már felfogtam. Megy minden mint a karikacsapás. A dokumentáció egyértelmű. ( mármint a Vyatta-é =D ) Nem utolsó sorban debian az alapja.

Ha a/n-es wifi-t akarsz akkor az AP mellé egy kisebb fajta vagyon. vagy egy olcsó tp-link router openwrt-vel :)