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.
Hozzászólások
Ü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.
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.
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
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.
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!!
amit linkeltem, az egy MIPS panel, amiben van HWnat. Freebsd-t le lehet forgatni MIPS-re, szoval OPNsense-t sem lenne gondolom lehetetlen portolni.. Valszeg par feature-rol le kene mondani, de meg ugy sem lenne rossz!
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.
Szerintem attol hogy a Mikrotik-ben elkepeszto szabadsagod van, rendkivul feature gazdag, szinte barmit meg lehet vele valositani anelkul hogy hekkelned es/vagy lecserelned a firmware-t.
miután 2 év alatt 7 db mikrotik füstölt el (táp, ami magával vitte a lapot, port, kártya foglalat) igy a mikrotiket kerülöm, mint ördög a tömjénfüstöt.
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...
Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.
Ami eldurrant, az kb ezt a folyamatot tolta végig: Port keljfeljancsit játszik, majd lentmaradt, majd már nem is látszik, közben elkezd az eszköz rebootolgatni (log üres), aztán egy reboot végén már csak a re -ig jut.
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.
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.
a legnagyobb hibaja szerintem az, hogy neha kileakeli a switch mac cimet az uplink porton - ezert az en szolgaltatom port security beallitasa pl lelovi a linket 5 percre...
igy kenytelen vagyok egy butaswitch-el hasznalni, amibe a gepek vannak dugva, nem a belso switchet hasznalni.
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.
Mivel a Digi a Gigabitet FTTH/FTTB leginkább csak PPPoE-n adja, ezért lényeges apróság a rúterek sebességénél, h. csak sima IP-n képesek ezt kipréselni magukból, v. PPPoE-n is.
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.
Nem tudom, hogy az UPC/Voda egy darabig megy-e optikán vagy sem, hozzánk koaxon jön be, és gigabit, viszon nem pppoe. Az átlagember pedig akkor is tudja, mi az a pppoe, ha volt valaha adsl-je :)
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.
Ezzel nem sokat segítettél. Konkret tipus(oka)t keres az átlagember, nem elég a SoC neve, a köré épített "doboz" is fontos. Hacsak nem assemble-your-own-ruter a kérdés a topikban, de nem hinném.
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).
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 :)
Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.
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.
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.
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.
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.
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. :)
Hozzászólások
Ü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.
Ha a hw nat támogatást bekapcsolod, akkor simán elboldogul a Gbit natolásával.
Csak ha nem akarsz semmilyen extra cuccot rátenni, akkor használd.
Már egy mc installálása is kinyírja.
azért az az usecase érdekelne, amikor valaki egy routerre mc -t tesz.
.
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.
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.
Tudsz mondani néhányat, amit ajánlanál is?
De most tényleg, minek rá mc?
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 ?
cert based authot tud? hogyan rakod le a server certjet?
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
miert ne tudna? normalis ovpn van rajta
1- scp server.crt user@er-x:/bekonfoltpath
2- vi path/cert
:set paste
cmd-v
:wq
Még nem csináltam végig, de ez alapján menni fog
https://help.ui.com/hc/en-us/articles/115015971688-EdgeRouter-OpenVPN-S…
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.
sima commit helyett commit-confirm.
Oh bakker, hogy ezt eddig nem találtam meg. (Ja, de.)
Csak hogy ennek haszna is legyen a config.boot-nak intact-nak kell lennie.
Vagy nem ezt írtam eddig?
ha van 50 usered, meg zonak, meg vlanok, meg minden kutyafasza es ilyen igenyeid: akkor legyszi ne prosumer cuccot vegyel, hanem valami rendes vasat.
Köszönöm Óh mester!
Bizonyára csak első pár mondatot sikerült elolvasni...
tehat 70 sor omlengest kene olvasnom tartalomert? ne viccelj mar. ahol igenyek vannak, ott legyen penz is.
Igazad van.
Elég csak az első 3 szót.
Aztán lehet véleményt formálni.
pont arra reagaltam.
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!!
opnsense x86, azaz veheted alá a tápos intelt v amd-t, nincs olyan h. hw nat
amit linkeltem, az egy MIPS panel, amiben van HWnat. Freebsd-t le lehet forgatni MIPS-re, szoval OPNsense-t sem lenne gondolom lehetetlen portolni.. Valszeg par feature-rol le kene mondani, de meg ugy sem lenne rossz!
Az opnsense egy freebsd fork-on (hardenedbsd) fut, ami csak amd64-et támogat.
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
a pfsense tisztán freebsd, nem fork, szóval ott simán mehet arm mips vagy bármilyen egzotikus kenyérpirítón
A felette levo linken látszik, hogy megy arm en is.
Nem azt mondtam, hogy LEHETETLENSÉG, hanem hogy perpill az amd64 a támogatott, a többi architektura pedig ERŐSEN experimental.
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.
Celfeladatra celszerszamot. Mikrotik!
Egy Mikrotik mitol celszerszamabb, mint egy Edgerouter?
Szerintem attol hogy a Mikrotik-ben elkepeszto szabadsagod van, rendkivul feature gazdag, szinte barmit meg lehet vele valositani anelkul hogy hekkelned es/vagy lecserelned a firmware-t.
Az mc fut rajta? :D
(Nem, most nem köcsög vagyok, tényleg csak vicc.)
miután 2 év alatt 7 db mikrotik füstölt el (táp, ami magával vitte a lapot, port, kártya foglalat) igy a mikrotiket kerülöm, mint ördög a tömjénfüstöt.
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...
2 kivételével szünetmentes van (volt) alattuk.
Ami eldurrant, az kb ezt a folyamatot tolta végig: Port keljfeljancsit játszik, majd lentmaradt, majd már nem is látszik, közben elkezd az eszköz rebootolgatni (log üres), aztán egy reboot végén már csak a re -ig jut.
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.
FYI: https://help.ui.com/hc/en-us/articles/115006567467-EdgeRouter-Hardware-…
És nem, nem tudja a 1G-t. Csak majdnem.
https://www.patnotebook.com/edgerouter-x-hardware-offloading/
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.
Lassabb a v2.
De pl tudja a BGP-t jól. Míg a v1 random összefosta magát.
Tudsz linket ahol össze vannak gyűjtve ilyen és hasonló ismert hibái?
a legnagyobb hibaja szerintem az, hogy neha kileakeli a switch mac cimet az uplink porton - ezert az en szolgaltatom port security beallitasa pl lelovi a linket 5 percre...
igy kenytelen vagyok egy butaswitch-el hasznalni, amibe a gepek vannak dugva, nem a belso switchet hasznalni.
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.
defektes. nekem ez volt rajta otthon, es fos volt. igy vettem egy olcso 5 portos netgeart melle, es azota mukodik.
nem tudom EOL-e, en kb 3 eve vettem
ott van mellette a 2.0.8is, igazából az az utolsó (még akkor is, ha egy nappal korábbi)
az is bugos a forum alapjan sajnos
970 mbit atmegy rajta, ami 1500as MTU mellett az 1Gbit/s. tudja.
forras: ezen megy otthon a net (az SFP+-os valtozaton).
a WAN az PPPoE-n megy vagy szimpla IP-n?
letezik PPPoE FTTH-os kiepitesben?:) sima IP.
https://digi.hu/ajanlat/internet/lan
hat jo, nekem nem ez van otthon :)
Mivel a Digi a Gigabitet FTTH/FTTB leginkább csak PPPoE-n adja, ezért lényeges apróság a rúterek sebességénél, h. csak sima IP-n képesek ezt kipréselni magukból, v. PPPoE-n is.
Telekom is pppoe-n adja a gigabitet. Ott sem elhanyagolhato a dolog.
es? a topic nem errol szol, a kerdezo nem kerdezte bocs pppoen mennyit tud. en leirtam h rendes IP kapcsolaton mennyit tud.
Igazából de. Ha itthon az optika általában pppoet jelent, akkor erről szól. Még akkor is, ha svájcban nem ez a jellemző.
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 ;)
> nem "igazabol" van, ez egy technikai kerdes, hogy az eszkoz tud-e IPn NATolni 970 Mbitet v nem
> A net optika 1 Gb, elboldogul vele az EdgeX?
Maradjunk abban, hogy te fejben lefordítottad a kérdést arra, hogy tud-e IPn natolni.
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.
felirhatod erre a listara a storage, NIC, szerver, ... gyartokat is :-)
Nem tudom, hogy az UPC/Voda egy darabig megy-e optikán vagy sem, hozzánk koaxon jön be, és gigabit, viszon nem pppoe. Az átlagember pedig akkor is tudja, mi az a pppoe, ha volt valaha adsl-je :)
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.
Ezzel nem sokat segítettél. Konkret tipus(oka)t keres az átlagember, nem elég a SoC neve, a köré épített "doboz" is fontos. Hacsak nem assemble-your-own-ruter a kérdés a topikban, de nem hinném.
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
Szóval te sem használtad egyiket sem úgy ahogy a topikindítóban kérdezték/kérték, csak tippeled...
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 :)
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.
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.
Ugyanaz az MT7621 chip van a hex-ben mint az Edgerouter X-ben.
tenyekkel ne zavard ossze...
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
Végignéztem a videót, ez 1 katasztrófa termék. Ubiquiti cuccoknál ez az általános szoftver minőség?
Jelenlegi beta2 ben 5.6.3 as kernel fut.
Fedora 38, Thinkpad x280
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.
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 38, 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.
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. :)
CPU load látványosan különbözött a 2 speed tesztnél? Milyen SW verziót használsz?
EdgeRouter X v1.10.11.
CPU-t nem néztem, de majd megnézem.
Jött ki új szoftver pár napja:
kíváncsi lennék van aki bétateszteli...?
Szép nagyot ugrottak verziószámban.
A V1.x-et el is rejtették. :)
Én megnézem, ha vissza lehet tenni a régit. :)
Ott van a legújabb v2 alatt a gomb h. SEE PAST FIRMWARE
Net megy, VPN megy, sebesség megvan.
https://www.speedtest.net/result/c/375f91bd-78a0-4e85-8e4b-73dbd04d0384
Elég sok mindent faragtak benne.
https://dl.ubnt.com/firmwares/edgemax/v2.0.9/changenotes-v2.0.9.txt