Ubiquiti EdgeRouter X mit tud?

Hálózati eszközök

Aki használ ilyet, mi a tapasztalat vele? Otthoni hálózatba menne 3 AP elé, egyszerre 4-6 kliens lenne rajta. A net optika 1 Gb, elboldogul vele az EdgeX? Az ára alapján vannak kétségeim.

  • 1972 megtekintés

( viraadam | 2020. 10. 30., p – 21:23 )

Szerkesztve: 2020. 11. 02., h – 10:50

Üdv!

 

Tegnap előtt vettem egyet (tanulás céljából), eddig egészen jók vele a tapasztalatok.

1 gbit menni fog valószínűleg (nálam csak 150 mbit van, kísérletezni hálózatok között pedig még nem volt időm).

Ha CISCO, Juniper cli nem gond, akkor szerintem ez tetszeni fog, de a GUI-ban a legtöbb általános feladathoz van wizard.

Update:
Kezdő vagyok a témában, bár a cli ismerős volt cisco/juniper vonalról.
Szerintem a GUI felejtős, legfeljebb addig lesz rá szükséged, amíg ismerkedsz a dologgal.
1gbit megy, 2 vlan között HW offload nélkül 250 mbit/s, hw offload-al 950 mbit/s körül. Szerintem arra bőven elég, amit írtál. PPPOE+NAT tempóra én is kíváncsi lennék, ha valaki próbálta, megírhatá, bár ha nem tudja, nekem nem bottleneck. :)

Szükségem van L2TP/IPSec VPN-re, a beállítása triviális, egyébként az egész EdgeOS nagyon jól körül van dokumentálva, legalábbis kezdők számára tökéletesen érthető példákat lehet találni.

Megtáplálás: Mivel már van egy UBI AP AC Lite is otthon, így POE adapter -> ER-X -> AP, POE passthru tökéletes és kényelmes.

commit ; save lehetőség szerint sose, commit-confirm viszont mindig ismerkedés alatt. :)

Ez az én kezdeti tapasztalatom, remélem, tudtam segíteni.

( KoPe | 2020. 10. 30., p – 22:20 )

 Ha a hw nat támogatást bekapcsolod, akkor simán elboldogul a Gbit natolásával.

( STP | 2020. 10. 31., szo – 08:39 )

Csak ha nem akarsz semmilyen extra cuccot rátenni, akkor használd.

Már egy mc installálása is kinyírja.

( csabyka v | 2020. 10. 31., szo – 08:59 )

rengeteg helyen használom, tökéletesen teszi a dolgát, ügyfelek imádják, mert nincs vele gond. 

Ahova picit nagyobb kell, oda az sfp-t teszem. 

( laysoft v | 2020. 10. 31., szo – 09:14 )

Szerkesztve: 2020. 10. 31., szo – 09:17

Ugyanezzel a SOC-al hasonló áron, vagy olcsóbban léteznek WIFI-s modellek is, de tegyél rá OpenWrt-t és mindent fog tudni! Pl. nem döglik bele, ha mc-t teszel rá...

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

J4F

De mondjuk 200K-s config kezelése is valamivel 1xűbb ezzel.

Mert hát ez ER-ben is van olyan fícsör, amit GUI-ról nem érsz el (pl OVPN). És sokkal könnyebb egy - nem vi - editorral szerkeszteni, mint CLI-vel.

Egyébként tehetsz rá VIM-et is, ugyan úgy kinyírja, mint az mc.

omfg. 

ugye egy ciscora is teszel mc -t? 

ovpn beallitas: 

ssh router, configure

set interfaces openvpn vtun0 mode server
set interfaces openvpn vtun0 server subnet 172.16.1.0/24
set interfaces openvpn vtun0 server push-route 192.168.1.0/24
set interfaces openvpn vtun0 server name-server 192.168.1.1

erre minek bármi ? 

Tud, én most kattogtattam össze hirtelen valamelyik eset. Fel kell másolni a certeket, és file path alapján behivatkozni a konfigba. A doksiban levő pathot szerintem viszi magával jól, mert mikor eltypoztam, akkor közölte, hogy az ott nincs jó helyen, nem fogja magával vinni valami backup/fw update hasonlónál.

A doksi azt mondja, hogy generáld a certeket rajta, erre természetesen nincs szükség, csinálhatod máshol.

Mondjuk menedzselj 50 RW usert akiket egy tucat zónára kell leszabályozni és akkor már nem ilyen 1xű. (Hozzá még VLAN, blbalbla)

De a legfontosabb érv, hogy tapasztalatom szerint nem célszerű az éles config-ot (amit a CLI is állít) basztatni (már persze, ha nem móricka példákból áll), mert bár látszólag minden rendben van, de a commit után van, hogy integethetsz.

És ez pár száz km távolságból nagyon fájdalmas tud lenni.

Így első körben a proba.conf-ot módosítom, load proba.conf, compare, commit és ha müxik, akkor save. Még arra is van mód (értelem szerűen save előtt), ha committal kirúgnám magam alól az 'ssh interfészt' és T idő belül nem férek hozzá a routerhez, visszatöltse az utolsó, még garantáltan működő config.boot-ot. Ezért célszerű, ha a config.boot garantáltan el tud indulni.

Lehet CLI only is használni, csak egy 200k-s konfignál elég sok időt lehet spórolni egy vim vagy mc használatával.

És mielőtt felteszed a kérdést, hogy miért akarok ilyen bonyolult konfigot egy ilyen kis xaron futtatni. Mert volt idő,amikor SFP csak a ER-Pro -ban meg az X-SFP -ben volt. Ma már ER4-et használunk branch-office eszközként.

Szóval amit GUI-n össze lehet kattintani (csak) arra jó az X. Szerintem.

( Vamp | 2020. 10. 31., szo – 11:43 )

En ezzel szemezek egy ideje: https://www.asiarf.com/shop/wifi-wlan/wifi_ap_router/wifi-router-board-…

 

OpenWRT-vel megy is, azzal nincs gond, de en OPNsense-el hasznalnam... Ami bajos, mert ugye arra hivatalosan nincs is ARM tamogatas, bar elv. Pi szeru board-okra mar sikerult felrakni...

 

Egy OPNsense tudasu tuzfal, olyan hardverrel, ami tud HWnat-ot, meg hardveresen gyorsitott VPN-t... nem lenne rossz!!

Hivatalosan igen, de azert elmegy az mason is :) (pl ARM-en)

 

https://forum.opnsense.org/index.php?topic=12186.195

 

https://github.com/opnsense/tools#cross-building-for-other-architecures

 

Sot, a Pfsense-nek (ot forkolta anno az opnsense) meg van is ARM alapu tuzfala: https://www.netgate.com/solutions/pfsense/sg-3100.html

Az úgy szokott lenni, hogy fogja a gyártó a freebsd-t. Javít egy sor hibát, hogy csak a saját hardverén fusson aminek minden módosítása a hardveréhez kötődik majd elkezdi árulni mint XC OS ahol a freebsd csak alacsony szintű dolgokért és a vállalat alkalmazásának futtatásáéért felel, mindezt egyetlen .bin-be gyűrve.

Ha a gyártó nem az Apple, IBM, Oracle ... stb harácsbanda. Akkor a saját termékétől független javításokat lehet, hogy visszaküldni.

( Sixday v | 2020. 10. 31., szo – 12:46 )

Celfeladatra celszerszamot. Mikrotik!

Az azért már művészi mennyiség! Nálunk a hálózatban van kb. 1000 db különböző Mikrotik eszköz, és jellemzően csak a 10+ évesek állnak meg kiszáradó kondi miatt, meg amit a villám utolér. A többi megy gond nélkül. Ultra ritkán van 1-1 táphiba, jellemzően áramkimaradás utáni fesz. ingadozás miatt, de azok tápcsere után mennek tovább.

Olyan meg még sose volt, hogy a táp megölte volna az alaplapot. Soha.

Én csak 50+ Mikrotikkel dolgozom, kb 15 éve, de eddig egy sem, azaz nulla, durrant el táphibával. Villám, túlfesz, porthiba előfordult, de csak úgy elhalálozás nem. Én szétnéznék áram téren, mert ott valami nem stimmel...

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

( hzsolt94 v | 2020. 10. 31., szo – 14:38 )

Nen rossz, de mikor én próbáltam akkor az 1Gbit még csak reklám volt, a közelébe sem ért ennek egy NAT+PPPoE kapcsolaton. HWNAT elvileg létezett már akkor is, de a PPPoE kombinációjával nem ment, és a PPPoE gyorsításra a google és a lereskedő sem tudott mit mondani. Azóta nem tudom változott-e a helyzet.

Azért nem egyértelmű a teljesítménye:

https://www.servethehome.com/ubiquiti-er-x-review-getting-into-the-edge…

For $59, the Ubiquiti ER-X is an incredible device. It provides a lot of flexibility by allowing users to choose between smart L2 switch, bridge, router on a per-port basis, with reasonable performance for typical home or small office deployment. In addition, it offers a wide range of advanced features like QoS, DPI, VPN, Firewall, and support for advanced routing protocols. These features come at a cost of performance.

We think the ER-X could be a great device for home users looking to migrate from a basic/ flat network to a more complex segmented setup with WAN connection up to 300-400Mbps. It could also be great for a network enthusiast who is looking to get their hand on a more advanced network technology with the understanding that effective maximum WAN bandwidth may drop below 100Mbps, depending on the configuration. Again, in a $1000 100W device, this performance would be unacceptable, but for a $59 and 3W device, we think this is reasonable.

Ezt tudja valaki árnyalni, v. szimplán csak cáfolni (a linkelt review eleje ír arról is hogy a szoftver V1-hez képest jött ki újabb V2 ami viszont mérhetően lassabb.

Legutolsó szoftver:

https://www.ui.com/download/edgemax/edgerouter-x/default/edgerouter-er-…

v1.10.11

2020-03-11

1) Ez is defektes vajon még?

2) Ez az edgerouter x már kifutó termék, vagy még bőven az életciklusán belül jár? Csak mert 2015-ös doksik vannak fent hozzá, azaz legalább 5 éves termék lehet. Az meg a mai initinite-beta-shit korában annyit tesz h. bármelyik nap jöhet az EOL bejelentés.

nem "igazabol" van, ez egy technikai kerdes, hogy az eszkoz tud-e IPn NATolni 970 Mbitet v nem. ha teged kifejezetten az erdekel h pppoen mennyi megy at, majd nyitsz masik topicot, v ebben a topicban egy masik threadet, es megigerem, oda nem fogom beirni hogy atmegy rajta, mert nincs olyanom ;)

Magyarorszagon az optikai gigabit internet nagy eséllyel Digi, vagy most mar Telekom is lehet .Talan Vodafone is jön lassan. De nagy eséllyel PPPoE lesz, amiről csak a szakmabelieknek van lövésük, hogy mit jelent és mivel jár. 100-ból 100 nemszakmabelinek fingja sincs milyen a WAN protokolja otthon. De pl. a webdeveloperek fele sem biztos hogy tudja mi a PPPoE buktatója. Mint ahogy az sem triviális, hogy az RSS sem működik 100-ból 99 NIC IC-vel PPPoE esetén. Szerintem talalnék CCIE-t is, aki nem tudná ezt. Az átlag internetező pedig aztan hol van a CCIE szinttől ugye..

Atlagember azutan ismerkedik meg a PPPoE kifejezéssel, miután beszopta a rútervásárlást.

A rútergyártók mikor NAT nélküli, bekapcsolt tűzFalszabályok nélküli, 1500 MTU-s csomogméretű, PPPoE nélküli áteresztőképesseg tesztek eredményét adják meg, akkor pontosan abba a pokolbugyorba valók, mint az autógyártók által a katalógusban megadott figyasztási és CO kibocsátás értékek. Annyi a különbség, hogy az autós esetben már az átlagember fejébe is belevésődött, hogy ezek hazug számok, amiket a jelenlegi törvényi szabályozások kiskapuként tálcán nyújtottak a gyártóknak, és ennel megfelelően kezelik az emberek. A rútergyártók ezzel szembeb jelenleg még a szabályozatlan 1800-as évekbeli vadnyugaton helyezkednek el, ahol mindent szabad es kell is hazudni csúsztatni.

( Vamp | 2020. 11. 04., sze – 10:22 )

Sztm egy mt7621a chipsetes router + OpenWRT jobb valasztas ennel. (Ebben is ez a chipset van amugy) Viszont OpenWRT-vel tobbet lehet sztm kihozni a cuccbol. Ilyen chipsetel viszont olcsobban is kapsz.

Akar ezzel a tipussal is ki lehet probalni. OpenWrt oldalon fel vannak sorolva a supportalt tipusok.

 

Mas:

 

Esetleg espressobin v7? Elv ki lehet belole hozni 1Gbit-et. (pppoe-vel nem tudom, de gyanitom, h igen, nem gyenge a hardver) esetleg egy ClearFog Base? https://shop.solid-run.com/product/SRM6828S00D01GE000B02CH/

 

Opnsense felepitheto vele. kerdes persze, hogy kihajt-e gigbit PPPoE-t. 

 

https://github.com/opnsense/tools/issues/158

( ggallo | 2020. 11. 08., v – 20:22 )

Ha a többiek nem győznek meg az EdgeRouter-X jóságáról továbbra sem, akkor én a Mikrotik hEX-et (RB750Gr3) javasolnám helyette. Árban ugyan ott van.

Rendesen beállítva menni fog PPPoE-n is a 1Gb NAT-olva, kellően erős a CPU-ja (HW AES is van IPsec-hez, ha kell). Ami eszedbe jut egy router-rel kapcsolatban, azt mindent tud (plusz még sok dolgot ami eszedbe sem jut). Persze szokni kell a logikáját (mondjuk Linux IPtables ismeretével nem egy nagy dolog), de szerintem sokkal könnyebben konfigurálható úgy GUI-ból, mint CLI-ből az UBNT router-ekhez képest. Nem mellesleg nagyon jól dokumentált (ami az Ubi router-ekről nem mondható el sajna).

Köszi mindenkinek, hát nem győzött meg a Edge...

Mikrotikkel napi szinten dolgozom, és szeretem is, csak az ügyfél kérésére merült fel, hogy legyen Edge és mivel még nem láttam működni sosem, ezért kérdeztem. Végül sikerült rádumálnom az ügyfelet egy RB4011-re, az lesz végül, így mindenféle sw turpisság nélkül izomból mehet a net :)

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Az RB4011-ről annyit azért tudj, hogy mi próbáltuk használni olyan helyen, ahová túl sok és drága egy CCR, de a hEX meg kevés (főleg portszámban, nem teljesítményben), és nem jó tapasztalatunk van az SFP+ portjával. Konkrétan eddig egyik RB4011 példányban sem tudtuk hiba nélkül használni azt a portot sem sima SFP sem SFP+ modullal (Mikrotik gyártmányúval sem, sőt, Mikrotik RJ45-ös SFP modullal sem).

Alapból mindig működik a port és megy is át rajta forgalom, de voltak olyan anomáliák, amikre nem találtunk sem magyarázatot, sem megoldást. Pl. OSPF nem állt össze ezen keresztül (nem jöttem rá, mi köze a porthoz), miközben bármely másik RJ45 porton jó volt, vagy épp az MPLS nem ment MTU miatt, pedig jó volt beállítva (és az is ment bármely RJ45 portra váltva), vagy egyszerűen csak egy csomó mindenféle error gyűlt és érződött. SFP modul esetében ugyan az a modul, ugyan az a konfig RB3011-be áttéve tökéletes lett. Persze próbáltunk régebbi-újabb-legújabb FW-eket minden esetben, de nem volt változás, így abban maradtunk, valami hardveres gond van ezzel a modellel, vagy még nem jutottak el a FW-rel az RB4011 SFP+ baj megjavításához.

Szóval mi RB3011-et használunk a hEX és a CCR között emiatt.

Köszi, ezt jó tudni, most nekem nem kell SFP. Ezt tesztelni fogom. Nem jeleztétek ezt a Mikrotik-nek? Kíváncsi lennék mint mondnak.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Bevallom, nem nyitottam hibajegyet rá, mert nem hagyhattuk egyik berendezést sem ott, ahol produkálta a hibát, megoldás kellet. De a hibajegy nyitása után általában supout-ot kérnek, meg még ezt-azt, és azt úgy sem tudtam volna produklálni asztalon.

Mivel azonnali megoldás kellett, és azt nem csak ez az egy modell jelentette, egyszerűbb volt nekünk másikat próbálni. Az megoldotta a gondot, az RB4011-et pedig elhasználtuk olyan helyre, ahol nem kell SFP csatlakozás.

Majd egyszer, ha sok időm lesz, összerakok egy teszt-szettet, és nyitok hibajegyet.

Azt azért mindenki beláthatja 10-20 IT iparban lehúzott év után, hogy látszólag teljesen azonos vasak tudnak homlokegyenest ellentétesen működni az eltérő szoftvernek "köszönhetően". Ezért nem érdemes xyz SoC / IC-t csak úgy magában ajánlani, a teljes körítést (azaz a szoftver részét is) kell megnézni.

Ez igaz. Mondjuk nem tudom melyik a jobb a Mikrotik 6.xx a 3.3-as kernellel amit 10-en sok éve tákolnak, vagy az Edgerouter X-ben lévő 4.14-es ( 2.xx firmware) kernel ami legalább még a mai napig támogatott az LTS ágon.

A soha meg nem jelenő? Mikrotik ROS7-ben már állítólag modern kernel lesz.

Mert sejtésem szerint nem a CLI-n meg a GUI-n fog múlni a pppoe sebessége.

Hát az UBNT és tákolás összefüggéseiről ez is elég sokat elmond:

https://www.youtube.com/watch?v=vFVIDwJ1FF8

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Szerintem a régi kernel egyedül akkor okoz gondot, ha a felhasználó is tehet(ne) rá SW-t, csak a régi kernel miatt nem sikerül. Amíg egy zárt rendszerben van, addig max. a fejlesztőknek okozhat fejfájást, hogy nehéz frissebb dolgokat implementálni a régi kernel miatt.

Amíg a MT által igért funkciók működnek megbízhatóan és könnyen kihasználható sérülékenység nincs, addig engem nem zavar, hogy milyen a kernel verziója.

Egy dolgot szeretnék csak (ami valószínűleg viszont összefügg a kernel verzióval), hogy az OpenVPN megvalósítás is tudja használni a HW AES gyorsítást a megfelelő modellekben, és legyen OpenVPN UDP. Én személy szerint sehol máshol nem érzem a régi kernel korlátait (nincs nagy BGP tábla, amivel belassul, lehal a router pl.).

A ROS7 meg inkább sokára jelenjen meg, minthogy kétnaponta kelljen az eszközön frissítgetni óriási szarvashibák miatt. Azért a MT csak egy kis cég, gondolom nincs annyi fejlesztői erőforrásuk, hogy a régi rendszert is újítsák, meg mellette őrült tempóban fejlesszék a friss kerneles verziót.

Egyébként egy jó régi cikkben azt olvastam, hogy a frisebb kerneles fejlesztést azért nem kezdték el érdemben sokáig, mert a CCR-ekben használt Tile processzort nem támogatta a valamenyiknél újabb kernel, és a CPU gyártója nem igazán törte magát a támogatás megvalósításában. Aztán - lehet épp a MT nyomására - csak előre léptek ezen a téren.

A ROS7 meg inkább sokára jelenjen meg, minthogy kétnaponta kelljen az eszközön frissítgetni óriási szarvashibák miatt"

Ugyan, ehhez nem kell 7es routerOS, simán elég a mostani is.  Legutóbb 6.46.x ről frissítettem 6.47 -re, vissza kellett tennem a régit, mert a hAP^ac2 es AP-re nem regeltek fel a régebbi kliensek.

Szóval ha meg is jelenik 1x a ROS7 min fél vagy inkább 1 év mire használható lesz. Annó 6os se volt másképp. Új hw-ek meg még inkább. Elsők között vettünk CCR eket 2013 ban, kb fél évig használhatatlanok voltak. Sok helyen ahol kell a kraft, cseréltünk sima linux-ra ég és föld, még majd 10 éves vassal összehasonlítva is. Bár a CCR se fiatal, de valszeg sose tudtak normális SW-t írni rá.

Ui: az új kernelnek ott (is) van jelentősége, hogy az elmúlt sok évben iszonyat sok fejlesztést toltak bele, főleg network terén is. Aztán vagy backportolta vagy nem a mikrotik, de inkább ez utóbbi.

Fedora 41, Thinkpad x280

Most én mondom, hogy nem olvastál alaposan, mert az "ugyan az MT7621A SoC van benne" kijelentés a Mikrotik RB750Gr3-ra (hEX) vonatkozott, miközben az "izomból mehet a net" meg már a Mikrotik RB4011-re, amiben egy AL21400 típusú ARM alapú 4 magos proci van, és valóban sokkal erősebb a HW, nem csak papíron.

( szilard_ v | 2020. 11. 10., k – 09:17 )

Egy hete üzemeltem be magamnál otthon. 500/300-as digi PPPoE netem van.

Csak összerakva a speedtest max 300-at mért letöltéseben. Aztán megtaláltam, hogy a offload-ot kell engedélyezni (ezzel lemondasz az forgalom analízisről) és onnantól 540/330. A fórumokban 930-950-et írnak ha van giganet.
Beállítottam egy L2TP/ipsec VPN-t és megy mint a karikacsapás. Ipsec-et is lehet hw gyorsítani, de ha be akarom kapcsolni, akkor az írja, hogy problémát okozhat, amit majd javítani fognak.

Az idegen volt elsőre, hogy a webes felületen mennyire kevés dolgot lehet beállítani, illetve a config tree is olyan béna kacsa lett, de van bőven videó és leírás a parancssori ügyeskedéshez. Mostanra nagyjából megbarátkoztam vele. Egy UAP-AC-Lite még jól jönne a boldogsághoz. :)