Ajánljatok GIGABIT képes router-t

Hálózati eszközök

Hamarosan beköti hozzám a szolgáltató a gigabites kapcsolatot.

Jelenleg egy Mikrotik RB750G-vel használom, el is érem a jelenlegi 100Mbit-es sebességet.
Viszont szerintem ez nem lesz elég gigabitre.

Elvárásaim:
- Gigabit (vagy legalábbis minimum 950Mbit) átvitele WAN-LAN között kábelen. (Kaphatnék 500Mbit-es netet is, ezért nem szeretném, ha a router lenne a gyenge pont.)
- Jó lenne hw támogatott IPSec funkció.
- Frissíthető (nem csak a jövő héten) firmware.
- Nem zavar, ha linux közeli a felület, sőt! Mikrotik is megfelel!
- Wifi funkció nem fontos, de ha van, akkor az 5Ghz-es csatorna fontos nekem. 2.4-et már kikapcsoltam.

  • 10705 megtekintés

Én is pont ezzel szemeztem, de úgy, hogy openwrt-t tennék rá. Ami elbizonytalanít, hogy a hw NAT-ot nem támogatja rajta az openwrt.

Furthermore, please be aware that OpenWrt firmware does not support the hardware NAT capability of these routers. Hence, the throughput between WAN↔LAN will be slower than with stock firmware.

https://openwrt.org/toh/tp-link/archer-c5-c7-wdr7500

Nem tudom neked mit jelent az elmaradott, épp a héten raktam fel egy gbit netre egy HAPac2-őt kedves barátomnál 980/980MB/s ethernet és 490/490MB/s wifi sebességet mért speedtest-el. Persze az a 490 az a teljes csatorna és nem duplex de tényleg nem tudom mit vársz többet.

Igen igazad van. Az rb4011 wifis verziója állítólag 4 chain-es 5Ghz-en, de arról is csak rosszakat hallottam. Ami a klienseket illeti: van ilyen, pl. a laptopom fél éves, ax modul van benne és a megfelelő helyen már mértem vele 600+ Mbps-t wifin. Persze nyilván akinek nincs megfelelő kliense, az ne akarjon nagy sebességget.

Konkrétan ax módot támogató chip már 2016-ban létezett. A nagy gyártók már wifi 6 e módra fejlesztenek (6Ghz), a MikroTik meg még a 802.11k -t se támogatja. Kb. 5 évvel vannak lemaradva, ami wifi téren már történelemnek számít. Ezeket úgy mondom, hogy MikroTik fan vagyok, mindenhova azt telepítek és szinte mindenkinek ezt ajánlom. De a tényeket nem szabad elhallgatni, és aki azon aggódik hogy vajon ki tudja-e nat-olni az 1 gigabitet, annak nem való az AC mód....

( andrej_ v | 2019. 02. 27., sze – 19:29 )

"but also a new 680MHz Atheros 7161 CPU for increased throughput. Up to 580Mbps throughout with larger packets, and up to 91500pps with small packets!"

Elsőre szerintem várd meg, hogy mit hoz nálad és az mennyire lesz elég. Gyanítom, hogy otthon nem fogod a Gbit-et 24/7-ben koppantani.

Ha cserélnél, akkor érdemes ezt megnézned: https://mikrotik.com/product/hap_ac2#fndtn-testresults

( exciplite | 2019. 02. 27., sze – 19:43 )

Mikrotik RB4011iGS+5HacQ2HnD-IN-t ajánlom, én ezt vettem 1000Mbit Digi nethez. Ágyúval verébre, de legalább így nincsenek korlátok. Wifi-je is meglepően jó, TP-Link Archer C2-t váltotta le.

( zrubi v | 2019. 02. 27., sze – 20:02 )

Linksys WRT1200AC, -> 1900AC -> 3200ACM

A gyári firmware is elég jó, ha nincsenek extra igényeid.
Ha vannak, akkor meg OpenWRT ready.

--
zrubi.hu

( p2pking | 2019. 02. 27., sze – 20:21 )

Asus RT-AC66U_B1 van es eddig egeszen jonak tunik.
Wifi resze nagyon ok, jelenleg is log rajta 20+ eszkoz.
Kellemes csalodas volt.
5GHz van.
openvpn az biztos, pptp, l2tp ezeket nem probaltam, klienskent.

( Bodri v | 2019. 02. 27., sze – 20:28 )

Akkor Mikrotik HEX, jobb teljesítmény, több RAM, IPsec hw enc támogatás.

( Sanya v | 2019. 02. 27., sze – 21:15 )

Synology rt2600ac? Tudom horror, de akkoris jó. Nekem 1900ac van, de annak már nem sokáig van támogatása, már csak 2 év..

( PunishR v | 2019. 02. 27., sze – 21:40 )

ubnt er-x
- olcso
- linux kozeli a felulete (debian+Vyatta/VyOS=edgeos)
- van ra update
- szerintem jo a forum/kozosseg/support
- kicsi es PoE-rol is lehet taplalni
- giga nat nem problema neki (HWNAT)
- IPSec tamogatas is van benne

Na ezt megszivtam... Kikapcsolom a hwnat-ot megy simman az 500Mb (ilyen a netem). Hmm... Megnezem a dokumentaciot, hogy csak az ipsec-nel kell ujrainditani. Meg par be/ki kapcs, semmi. Ujrainditom es mar van is kulombseg, hwnat nelkul 360Mb-vel megy.
Ugy latszik mindegy mit ir az admin feluleten, nem biztos, hogy ki van kapcsolva. :)
Amikor megvettem jatszottam ezzel es ugy remlet, hogy tobbet tud hwnat nelkul... de lehet, hogy akkor meg nem volt tufal meg vlan...

valaki már belefutott itt múltkor:
https://dl.ubnt.com/firmwares/edgemax/v2.0.9/changenotes-v2.0.9.txt

Known issues:
DPI - Sometimes DPI is reporting wrong rx/tx counters
Offloading - L2TP IPSec traffic is not being offloaded on Mediatek-based routers (ER-X, ER-X-SFP, EP-R6)
Offloading - VLAN traffic is not being offloaded on ER-12

Software is like sex, it's better with a penguin. :D (r)(tm)(c) آكوش

( answ | 2019. 02. 27., sze – 23:22 )

Diginél átlagban olyan 800-900 Mbit/s érhető el. Ezt ma már szinte bármelyik szappantartó támogatja. Például egyik legolcsóbb AC-s, nagy hatótávolságú a Tenda AC10U. Tesztjeim alapján kb 10%-al lassabb csak az 5 GHz-es wifije, mint egy Asus AC66U-nak, a 2.4 GHz pedig sokkal távolabb is megy (itthon nappaliban elhelyezve a kb 25m-re lévő szomszéd kapujában is 20-30 MBit/s volt 2.4 GHz-en a letöltés, közben egy 40+ cm-es téglafallal).

Ha Mikrotikben gondolkodsz, akkor hAP ac2 visz 800-900 Mbit/s-ot, de felette még nem láttam, mivel Digi itt nem is megy addig.
A legjobb választás persze az RB4011, ha az ár nem probléma (de arról csak olvastam, nem adtam el belőle).

Azonban figyelj arra, hogy Mikrotik nem tud normális wifit tervezni, azt inkább szerezd be Ubiquiti-től (UAP-AC-LR)!

( zitev v | 2019. 02. 27., sze – 23:41 )

"2.4-et már kikapcsoltam."
- majd visszakapcsolod, ha bővül az "internet of things" otthon is... :)

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( Dwokfur v | 2019. 02. 28., cs – 09:06 )

Nem olcsó: Netgear R7800 Nighthawk X4S. Openwrt-vel is van HW nat.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Van már angol nyelv rajta legalább? Ennyi pénzért, ilyen tudással mondjuk el lehet neki nézni, hogy csak kínaiul tud. Nekem a sima 3 van, az nem Gbit.
Mostanában nálam az 5GHz hálózat néha eltűnik. Lehetséges, hogy a nem szokványos felállás miatt akad ki szegényem. Földszinten lévő Digis routerrel van wifi bridge-ben.

( Jo_OKerR | 2019. 02. 28., cs – 18:40 )

Nekem egy ZBT-WG3526 -om van. Gyárilag OpenWRT-vel jön, de én fordítottam rá saját Padavan-t. Nagyon meg vagyok vele elégedve.

Vajon miért használja Padavannal? Mennyire vannak arra frissítések? Egyébként van rá OpenWRT.

Árát nézve szerintem nem túl jó vétel most a ZBT-WG3526. A specifikációja csak alig jobb mint a Xiaomi Mi 3G v1 ami negyedannyiba került, sőt akciósan még annyiba se. Ami ma 2022-ben kellene rá legalább 2.5GBASE-T de csak gigabites van rajta. De jövőállóságot nézve 10 Gigabites Ethernet sem túlzás. 

( Swifty v | 2019. 03. 01., p – 15:58 )

Turris Omina-ja van valakinek? :)

--
Debian Linux rulez... :D
RIP Ian Murdock

( kleinie | 2019. 03. 01., p – 16:15 )

Esetleg egy pfSense vagy OPNsense képes cucc. PC Engines APU?

Ha PPPoE, akkor felejtős. Én magam nem próbáltam, de sok helyen lehet olvasni, hogy az problémás.

( arpi_esp v | 2019. 03. 02., szo – 11:13 )

vegyel GIGABYTE-ot. az 8x tobb, mint a GIGABIT! :)

( djsilas | 2019. 03. 02., szo – 15:15 )

Asus N18U volt korabban otthon, ami az 5G-s Wifi hianya miatt lett cserelve AC68U-ra. Siman viszi mindketto a Digis PPPoE-s gigabitet. AC1200+ is volt, az is vitte. Meg TP Link Archerek is... Igazabol szerintem manapsag mar-mar "barmi" elviszi a gigabitet...

( Swifty v | 2019. 03. 03., v – 20:44 )

Köszönöm az eddigi hozzászólásokat!

Ami felett a legtöbben elsiklottatok, az az IPSec...
Szóval ha valaki ismer ebben erős router-t, akkor azt ne tartsa magában! :)

--
Debian Linux rulez... :D
RIP Ian Murdock

( eleinor v | 2019. 04. 08., h – 14:49 )

Nem nyitnék új topicot, mert passzol ehhez. Telekom-os optikás netem volt, ezt bővítették most eszközcserével. Az eredeti Huawei eszközt kellett lecserélni egy Sagemcom f@st 5655v2 ONT-vel. Cserébe rögtön el is szállt minden szolgáltatásom, amihez port nyitás kellett volna (pl plex elérhetőség, saját nas elérhetőség). Az eszközön eddig semmilyen módon nem tudtam portnyitást megoldani, a beépített uPnP nem működik. Igaz, ezzel nem futottam még egy kört a Telekom technikusaival, de a minimalista felületen több kombinációt már nem tudtam kipróbálni. DMZ, uPnP, port nyitás, se együtt, se külön-külön nem működnek.

Annyi jöhet szóba, hogy bridge módba átrakatom az eszközt, és mögé rakok egy routert, ami minél többet átenged nat-tal a gigabitből, ami speedtest alapján olyan 950/940, és lehetővé teszi a szolgáltatások ki-beengedésének konfigurálását.

Jelenleg van egy TP-Link Archer c5-ös routerem, ami még c7-es belsős (arra is van flash-elve), OpenWrt megy rajta. Jelenleg ez AP módban a wifit szórja. Ez az eszköz akár be is fogható költséghatékonyságból a Telekom eszköz mögé, mert be tudom úgy kábelezni.

A leendő eszköz paraméterei:

- rendes port forwarding megoldás, vagy a kényelmes uPnP normális működése
- Gigabitből átjöjjön/menjen, ami csak tud
- frissíthető legyen
- elég egy wired-only eszköz
- 20e kb a max keret

Az ajánlott eszközöket megnéztem itt a hozzászólásokban, és ezzel kapcsolatban lenne pár kérdésem:

- Nem tudom mi igaz abból, amit emlegettetek, hogy OpenWrt alatt a nat-olási sebessége leesik 300 környékére, ez egyelőre elbizonytalanított. Zrubi ezt megkérdőjelezte, csak nem tudom, ebben mi a valóság. Így az Archer kérdéses lett.

- MikroTik RB750GR3 hEX: Milyen ennek a felülete? Végül is ha egyszer bekonfiguráltam, utána nem igazán kellene hozzányúlni. Egyébként nagyon jókat írtak róla.

Szerk: PPPoe van jelenleg.

- Nem tudom mi igaz abból, amit emlegettetek, hogy OpenWrt alatt a nat-olási sebessége leesik 300 környékére, ez egyelőre elbizonytalanított. Zrubi ezt megkérdőjelezte, csak nem tudom, ebben mi a valóság. Így az Archer kérdéses lett.

Az a valóság, hogy azokban a routerekben amik "hardveres NAT" támogatással rendelkeznek, általában NEM adják ki az ehhez szükséges kernel modulokat, ami nélkül pedig durván leeseik az áteresztő képessége open-source firmware használata esetén.

Amit én megkérdőjeleztem az kizárólag az általam javasolt/használt router(ek)re vonatkozik. Ugyanis azok a modellek eleve úgy lettek tervezve, hogy "open-source ready" legyen. Azaz, nem hasznltak benne semmilyen zárt modulokat. Tehát nincs is ilyen limitációjuk.

De ez nem router gyártó vagy épp OpenWRT, hanem konkrét típus függő.
Tehát, a kiszemelt modellt kell ellenőrizni, hogy OpenWRT firmware esetén is megmarad-e a gyárilag ígért áteresztőképesség.

--
zrubi.hu

Oké, kibékültek, és újra egyesültek, de a Qualcomm procikra a LEDE projektből elvileg van hardveres nat, ezt tesztelném majd le.

https://forum.openwrt.org/t/qualcomm-fast-path-for-lede/4582

Eszerint a LEDE projektben oldották meg, feltételezem bekerült onnan az OpenWrt-be.

Az nem hardver NAT, azért is fast path a neve.
Mindenesetre jót tesz a sebességnek.
Openwrtben nem a kernelmodulok hiánya miatt nincs még hardver NAT (jó a broadcom zárt, de a qualcomm biztosan open, szerintem mediatek is hozzáférhető), hanem mert ahhoz a tűzfalat kellene alaposan átdolgozni.

A Qualcom-os eszközök egy részénél sikerült megtalálni a megfelelő beállításokat a hardware-es NAT-hoz (gyári firmware forráskód, stb.). A TP-Link Archer C5 variációkat nem ismerem, de nekem is olyan router-em van, amihez hasonló módon van hardware-es NAT támogatás. Szóval nem kizárt, amit írt.

Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Az Archer C5-nek a v1.2-es verziója Qualcomm-os chipset-es, de a mérések alapján 300-nál tetőzik. Lehet, hogy külön kellene valami patch-et rátenni, vagy honnan lehet megtudni, hogy melyik verziójú OpenWrt az, ami feloldja a limitációt?

Neked konkrétan milyen eszközöd van, ami hardware nat-ot tud? Milyen rendszerrel megy?

Egyelőre hajlok a MikroTik felé, csak szeretnék biztos lenni benne, hogy nem csücsül nálam olyan eszköz, ahol egy firmware cserével megoldható lenne a dolog.

Akkor lehet csak a gyári szoftverrel tudja csak a gigabitet? A gyáriban van rendes port forwarding beállítás? És meddig tartják frissen? Mondjuk az előző TP-Link routerben is volt a gyári szoftverben nyomtatószerver, csak épp az én Xerox-omat nem kezelte. Az OpenWrt meg csuklóból megoldotta.

Gyári FW-t használok, RT-AC68U-n. 1 TB USB3 HDD (ext2) és nyomtatószerver is szépen megy, port forward van, de nem használom. ISO-k torrent letöltése és feltöltése gyors, de nem mértem külön. Ma pont mértem vele egy 920/320-at, PPoE-n keresztül, speedtest-tel.
--
https://naszta.hu

Nah, en vagyok a balfasz. Tegnap este egy masik geprol ellenorizve megvan a 528Mbps down, ugyhogy azzal a geppel van gebasz, amin rendszeresen csekkoltam...

--
hálókártya driver és kábelcsere megvolt, a hiba viszont még mindig.
--
Realtek® 8112L - még a gyártó is letagadja, nincs hozzá semmi, lehet hogy ő lesz a ludas...

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Nem tudom, hogy most melyik a jó áru routerük, régebben az RT-N18U volt az (ez most is van, gigabit és nyomtatószerver is kényelmesen megy, de egy ideje nem frissül a FW). Arra akartam kifuttatni a dolgot, hogy Asus-ok között lehet neked jó gyári FW-el.
--
https://naszta.hu

Ismerek egy R7800-at - leánykori nevén TP-Link NightHawk X4S. Ez belül Qualcomm Atheros. Csak mondjuk egy drágább árkategória.
https://openwrt.org/toh/hwdata/netgear/netgear_r7800
https://openwrt.org/toh/netgear/r7800

Itt van az a fórum, ahol dolgoztak a HW NAT-on:
https://forum.openwrt.org/t/hardware-nat-for-lede/1094
Először belehakkolták a QCA shell-t. Csákó itt talált érdekes részeket az OEM firmware source kódban:
https://forum.openwrt.org/t/hardware-nat-for-lede/1094/83
Aztán ez a másik csákó újraírta:
https://forum.openwrt.org/t/hardware-nat-for-lede/1094/168

Bizonyos router-ekkel megy elvileg. A pontos lista nem tiszta számomra.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Leteszteltem a leírásnak megfelelően, és elég érdekes dolgok jöttek ki.

Archer C5 LAN-WAN tesztek:
1 szálon tesztelve a nat-olás 170-180 MBit között ingadozott.
10 szálon tesztelve a nat-olás 280-350 MBit között ingadozott. OpenWrt-vel kb ez a 300 Mbit a limit, ha nincs HW nat. Ez a sebesség több szállal sem ment feljebb.

Archer C5 LAN-LAN tesztek:
1 szálon tesztelve a lan-lan forgalom 300 MBit.
10 szálon tesztelve a lan-lan forgalom 800-900 MBit között ingadozott, ami megfelel a gigabites switch elvárásoknak.

Ezek a tesztek a fiam gépén és egy laptopon mentek, gigabites lan mindkettőn, i3, i5 procik. Eddig rendben is van. Csakhogy belefutottam valami furcsaságba:

Fiam gépe --- gigabites switch (Nem az Archer) --- speedtest.net = hajszálpontosan 500/500 MBit.
Én gépem --- speedtest.net = 940/940 (nincs köztünk switch)

Fiam gépe --- gigabites switch (Nem az Archer) --- belső szerver = 800-900 Mbit, tehát a switch bírja. Az Archer LAN-LAN tesztek is ezzel a géppel mentek, tehát a gép is bírja. Akkor mi limitálja le 500-ra az ő gépét a speedtest-nél?

Az a UPNP orbitális security risk, ha volt esze a router gyártónak, bele se rakta. (lefordítom mit csinál: bármilyen eszközön bármilyen runtime-ból bármilyen alkalmazás kér egy direkt port forwardot magára - vagy másra a helyi hálózaton az Internet felől, és meg is kapja, anélkül hogy ezt bármilyen módon bárki vagy bármi szabályozná vagy értesülne róla).

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/motog4_athene

Tegnap beszéltem velük, bridge lesz az egyetlen megoldás. A jelenlegi eszközön ez nem oldható meg. A bridge viszont általam is megoldható, csak előtte fizikailag (nyomógombbal, és nem szoftverből) resetelni kell az eszközüket, és bekapcsolni a pppoe passthrough-t, aztán mehet mögé a saját eszköz.

Arra mondjuk kíváncsi leszek, hogy mi lesz az IPTV-vel. Ők azt mondták, hogy az maradhat a HGW-n, mert más rétegben dolgozik, mint a net. 2018-as fórumban viszont találtam olyat, hogy bridge módban a HDW lan portjaiból csak az az egy működik, amelyikből megy tovább a kábel a saját routerbe. Majd az otthoni tesztnél kiderül.

A MikroTik RB750GR3 hEX felülete:
- szoftver (WinBox)
- ugyanaz MAC-en keresztül
- ugyanaz webes eléréssel, ami egy hajszállal gyengébb
- terminálos (ssh, rossz esetben telnet)

Kinézetre nem egy broadband router felület, nem pfSense, nem iptables...
Rövid tanulás után a NAT/forward rule könnyedén, precízen létrehozható.
Előnye a szkriptelhetőség, jó néhány beépített lehetőség. Ami kifejezetten gyenge, az az NTP kliens - ebben a pfSense egy űrhajó.

A lényegi eltérés - még mindig a pfSense az etalon - a kényelem. Pl. a pfSense a gateway-t a létrehozás után figyeli és jelzi az állapotát, illetve naplózza. Itt meg ugyan meg tudod nézni az állapotát, de a figyeléshez egy watchdog rule + script kell. A script viszont akármit csinálhat: naplóz, ledet gyújt, emailt küld. Ezeket viszont bármihez drótozhatod, nem csak a felületen megadott dolgokhoz. (Na, most aztán elmagyaráztam a script lényegét! ;))
Hasonlóan nincs dyndns kliens, hanem keresned kell egy/több megoldást a neten, amit átírhatsz ízlés szerint.

Szóval bármit találsz ki, meg tudod vele csinálni.

Nem tudom jól értelmeztem-e az információt, ezért kérdezek. Találtam két block diagramot a MikroTik oldalán, ami azt mutatja, hogy disabled switching esetén az Eth1 port egy 1 Gb/s kapcsolaton megy a cpu-hoz, az Eth2-Eth4 pedig egy másikon.

Ez mit jelent pontosan? Router módban az Eth2-Eth4 külön kapcsolaton megy a proci felé, és nem megy az Eth1 WAN felé, vagy csak külön dedikált kapcsolatra vannak téve, így nagyobb az átviteli teljesítmény? Az Eth2-Eth4 portokra kötött eszközök látják egyáltalán egymást?

Ravasz fogós kérdés. ;)

A szerkezet a MT7621A SOC képességeit tudja kihasználni.

Az egyik ábra szerint pl. 3 WAN és 2 LAN között lehet routert kiépiteni. Ekkor a specifikáció szerint:
Internal Hardware Features
Network Accelerator:
2Gbps IPv4/6 routing, NAT, NAPT+HQoS
Azaz a router össz teljesítménye 1Gbps (összes WAN) + 1Gbps (összes LAN).

A másik ábra szerint bekapcsolt switch teljesítménye:
Bundled Platform
MT7621A:
embedded 5p GbE Switch
Mint az előző esetben, 1Gbps a WAN-hoz rendelt - non switched - portok összesített sebessége.
A router kimenetén a switched LAN portok felé 1Gbps összes routeren keresztülmenő forgalom sebessége.
Az egyes LAN portok sebessége 1 Gbps/port egymás között, mert a switch "backplane" tudja az 5Gbps sebességet. (5GE - az adatlap szerint)

Tehát vagy max. 5 portot kötsz a switch-hez és akkor keletkezik egy switch, vagy egyik port helyett a CPU felé menő kapcsolatot, amivel összerakhatsz egy routert.

Összehasonításképp olyan különbség van, mint egy régi occsó broadband router és egy "rendes" között. Az előbbinél vagy statikus wan címed van, vagy dhcp. Az utóbbinál meg meg akárhány + a szolgáltató által dhcp-vel megadott is. Ezeket párhuzamosan kérdezi, vizsgálja és rangsorolja. Az ilyen fícsőr ;) aranyat ér, mert az utóbbi 10 év UPC DNS problémáiból egyet sem érzékeltem.

Ezt képzeld el az NTP kliensnél! Egyet tudsz beállítani és azt is alig. A pfSense meg sokat és sokfélét kezel - pl. a dcf77 soros típusokat is - amelyeket rangsorol, ellenőriz és kezel. Alább a [0123].hu.pool.ntp.org állapotát láthatod. (Azt, hogy mit keres ott egy ipv6-os cím, még én sem tudom. ;)) Szóval a time.kfki.hu-n kívül, még rengeteg paraméterét lehet állítani az NTP-nek. ;)

Network Time Protocol Status
Server		 Ref ID		Stratum		 Type	 When 		Poll	Reach	Delay	Offset Jitter
Candidate 	162.159.200.1 	10.123.8.141 	3 	u 	55 	512 	377 	9.370 	2.414 	8.098
Candidate 	84.2.46.19 	10.20.75.140 	2 	u 	66 	512 	377 	9.273 	-1.365 	2.729
Unreach/Pending 2001:738:0:860: 	.STEP. 	16 	u 	- 	512 	0 	0.000 	0.000 	0.000
Active Peer 	84.2.44.19 	10.20.75.140 	2 	u 	504 	512 	377 	9.835 	-1.717 	1.323

UPC DNS ledöglései miben érintik az NTP szinronizálást? Ha az a cél hogy legyen pontos idő, akkor nem time.kfki.hu-t kell megadni, hanem 148.6.0.1-et. Illetve felvenni egy másodlagos NTP peer-t is.

Az ISP DNS szervereit pedig ahol lehet ki kell hagyni, van helyette millió más megbízhatóbb és free alternatíva is. Pl ha a te DNS szervered nem szimplán egy buta forwarder a UPC DNS-e felé, hanem recursive-ra állítod.

Összehasonításképp olyan különbség van, mint egy régi occsó broadband router és egy "rendes" között.

Magyarázom: Ez csak egy példa volt a ficsörök különbségének nagyságrendjére.

A time.kfki.hu-t egy másik hozzászóló adta meg.

A beállításaim:

Servers:    195.184.180.4 195.184.181.4 8.8.4.4 8.8.8.8 129.250.35.250 129.250.35.251 156.154.70.1
Dynamic Servers:   213.46.246.53 213.46.246.54
Primary NTP Server: 192.168.1.2
Secondary NTP Server: 148.6.0.1

A 192.168.1.2 egy pfSense proxy szerver, amin az idézett NTP konfigurácíó van.

Sikerült megoldani a problémám. A Telekom ONT PPPoE passthrough-val átengedi a mögötte lévő Archer-t, ami mögött ott van a teljes saját hálózatom. A második routerben aktív a PPPoE. Az ONT dhcp szerverét is meghagytam, ami kell az IPTV dobozaihoz, különben azok nem kapnának címet. Ez az eszköz egyelőre a 192.168.1.0/24-ből osztja a címeket. Itt Internet egyébként nincs, konfigurálni is csak úgy tudnám, ha fizikailag rádugok egy konkrét eszközt.

A saját router mögötti hálózatot 192.168.2.0/24-re állítottam. A belső hálózaton az OpenWrt-ben kellett a dhcp force, mert egyébként a belső eszközök nem kaptak címeket. (nem tudom miért nem, az ONT dhcp tartománya elvileg teljesen más) A két hálózat miatt az IPTV eszközök legalább külön kerültek, így nem szemetelik a belső hálózatot, a forgalmuk nem is jön át belülre.

Ja, és a poén, hogy az ONT-t nem kellett bridge módba tenni (nem is tudtam megtenni, hiába állítottam át, a felület nem engedte menteni a beállítást), a PPPoE passthrough elég volt, és töröltem a bejelentkezési adatokat. Előtte egy menün belüli resetet nyomtam.

Már csak egyetlen szépséghiba van, hogy az Archer gyenge, 200-300 MBit-et képes route-olni (ami megfelel az előzetes méréseimnek), vagyis mindenképpen kell egy erősebb eszköz. Még mindig a MikroTik az esélyes, az Archer meg megy vissza a helyére AP-nak.

Egyébként nem találtam meg OpenWrt-ben, hogy miért működik újra a plex webes elérhetősége, külön port forward-ot nem állítottam be, uPnP meg Nat-PMP beállításokat meg nem találtam sehol. Erre van ötletetek, hogy mitől működnek újra? Ennyire szigorú lett volna a Telekom tűzfala, az OpenWrt meg alapból ennyire engedékeny lenne?

Kipróbáltam a frissebb verzióval, és valóban állat gyors lett :) 920/720 jön át Speedtest szerint. Annyi szépséghibája van csak a dolognak, hogy ez 17.01-es OpenWrt. Remélem valami magasabb verzióban talán belekerülhet a fősodorba ez a Fast-Path, és a teljes rendszer frissebb lehet. Majd meglátjuk hogy vizsgázik, egyelőre akkor a MikroTik elnapolva.

Esetleg kipróbálom a Flow offload-os image-et is, bár nem tudom, hogy alapvetően mi a különbség. Szerintem hasonló lehet a hatás, és jó eséllyel az OpenWrt verzió is ugyanaz.

Köszönöm mindenkinek a segítséget :)

( zwt | 2019. 04. 08., h – 14:21 )

Amplifi-t (amplifi.com) miért nem mondta senki? Ubiquiti otthoni megfelelője, designos és simán viszi gigabitet.

( elod v | 2019. 04. 08., h – 16:47 )

Ha Digi akkor nem biztos hogy el kell sietni a váltást. Nálam is egy 750G futkos jópár éve. Most mértem vele 127/62Mbps-ot 300-as csomagon. Nem a router miatt, az biztos.

Nálam Digi FTTH gigabites csomag speedtestje most:

Ping ms
1
Download Mbps
635.11
Upload Mbps
326.29

Úgy hogy a Mikrotik routerem vág sajnos. Mindegy, RB2011 szoftvere így is sokat javult, 1 éve kb felét sem tudta ennek.
Ja és mérés közben futott rajta egy OpenVPN is (néhány Mbit/s forgalommal).

RB750G nagyon régi router, de elvileg FastPath azon is támogatott, de csak a RouterOS 6.35 verziótól gyorsítja PPPoE-r.

Igen, tudok a FastTrack/Path-ról, aktív is. 60% a maximális terhelés, ennek ellenére 130Mbps jön lefele.
Digi hálózatán felugrik 100%-ra, 200Mbps körül jár, ez már egyértelműen RouterBoard limit lesz, csak épp elég irreleváns számomra amíg kifele nem hajtja ki.
Ezek egyébként jó értékek, mértem már 60Mbps körüli letöltést is vasárnap este amikor nyilvánvalóan mindenki otthon van.

Vagány a mérésed, csak nem stimmel azzal amit ők publikálnak (890Mbps) :)
https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack

( szilard_ v | 2020. 04. 03., p – 16:22 )

Többen emlegették itt az AC1750 Archer C7-et

A lenti oldal szerint ha openwrt-t teszek rá, akkor a hw NAT nem él. Változott valami a 19.07.2-es kiadásra?

Illetve nem tiszta, hogy ez a ma kapható v5-re is igaz-e?

NAT performance

The WLAN↔LAN throughput of Archer C7 2.0 with OpenWrt Chaos Calmer RC3 was measured to be substantially lower than that of the native firmware. (450 to 500Mbps with OpenWrt vs. 750 to 800Mbps with native firmware, both measured under conditions close to ideal). See this thread for details.

Furthermore, please be aware that OpenWrt firmware does not support the hardware NAT capability of these routers. Hence, the throughput between WAN↔LAN will be slower than with stock firmware. This is only important for users with highspeed internet connections, like e.g. a 1G fibre connection. If your internet connection is ⇐200Mbps you don't need to worry about this (maybe even up to 300Mbps). But if you need faster NAT throughput, consider buying faster hardware.

https://openwrt.org/toh/tp-link/archer-c5-c7-wdr7500

Ez kernel verziótól függ (hogy melyiket használja) és hogy ahhoz van-e Fastpath patch. Mert nincs a mainline kernelben (és valószínűleg nem is lesz).

Lásd: https://github.com/gwlim/openwrt-sfe-flowoffload 
List of Routers (Supported added base on suitability & request)
TP-Link Archer C7v5

De semmit nem garantálok :)

Ez az SFE hw hw-nat mennyivel jobb mint a hivatalos buildban levő sw-os flow offload ? SFE-vel PPPOE mellett elérhető a 900mbit?

A C7-esen sw flow offloaddal elérhető a 700mbit (előzmény hsz) ennél sokkal több az MT7621-es AC1200GU/57Uv1-en sem érhető el pedig 7621-re van hivatalosan hw flow offload, na jó, néha néha belekarcol a 800mbitbe, de legtöbbször csak ~700mbit jön át. Cserébe instabil, nekem több random rebootom volt, 57U-m és 1200GU-m van, mindkettőn volt fenn openwrt, de mindkettőn instabil volt, emiatt váltottam padavanra, padavanban van hwnat(Csak MT7620/21 SoC-s routerekre készül) állítólag gyári bináris mtk drivereket használ, a kernele 3.4x-es.

Gondolkodok egy QCA-s router beszerzésén mert állítólag ezek ideálisak OpenWrt-re.

Az Mt7621-es Openwrt instabilitás nem szűnt meg?

Nekem lekopogom a Xiaomi 3G a 19.07.5-el most stabil 6 napja semmi probléma. A 19.07.4-ben volt egy regresszió dobálta a wan kapcsolatot. A 19.07.3 az jó volt. Az előtte levők pedig használhatatlanok :). a 19.07.3-ban volt egy jó adag mt76 wifi driver javítás.

Van rajta 2-3 5G és 6-7 2.4G kliens.

Csak a 19.07.3 és a 19.07.4 volt fenn, 19.07.3 stabil volt, 19.07.4 egy határ sz*r volt, random rebootok, wan eldobálás, egy idő után a WAN-ra nem volt hajlandó kapcsolódni(PPPOE, egy reset után nyilván kapcsolódott volna de ahhoz nem volt kedvem) itt lett elegem és ment vissza a padavan, bár ez sem teljesen 100-as, kb havonta csontra fagyott eddig szinte mindig, de most elég sok javítást commitoltak alexey repójába, bizakodó vagyok. Gyári asus wrt egy kapap sz*r, a sebesség a teszteken megvan, de az oldalak betöltésével gondok adódtak rendszeresen. A PH-n dchard leírta a telekom topikba, rá lehet keresni, hogy az MT7621 egy elbaltázott SoC, az Owrt fejlesztői kemény workaroundokra kényszerülnek a chip hibái miatt. Próbáltam a snapshotot is, az is sz*r volt, legalábbis azok snapshotok amik a 19.07.4 idejében aktuálisak voltak, tudtak kb 300mbit-et, mert éppen valamit variáltak a DSA-val.

Az AC57U v1 biztosan mondhatom hogy gigabites és hozza is a ~900-940mbit-et gyári fw és padavan alatt, Owrt alatt ~700mbit-et tud. Biztos a kábeledet nem szerette vagy kifogtál egy hibás darabot. Gyári fw alatt a linksebességet nem lehet állítani, padavan alatt lehet állítani a portok link sebességét, meg próbálhattad volna a padavan-t, fw-t buildelni a prometheussal lehet. Van topikja a PH-n, a tagok időnként forgatnak fw-ket(én is) 57U/1200GU/MiR3G/Archer C5v4-re.

Hmm... Most láttam ezt a padavan-t először, csinos/okos-nak tűnik. Keresgéltem kicsit (igaz csak max 15 perce) és nem találok arról semmit, hogy talán MT7623-ra is lenne. Konkrétan Banana R2 routerre. Lehetséges erre lefordítani? Van esetleg valami tapasztalat vele?

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

Akkor beszoptam egy hibás darabot, mert emlékszem, 5G wifin nem is ment a net, vagyis nagyon akadozott. Pedi minden eszközöm tudja az 5G -t wifin.

Emlékeim szerint sem a WAN, sem a LAN portok nem tudtak 100 Mbit-nél többet (utóbbit tutira mondom, tesztelve), úgyhogy odaadtam öcsémnek, mert neki jó hangosítani vele.

Tégy jót a fogyatékkal élőkért Alapítvány

( Xterm v | 2020. 12. 14., h – 22:13 )

pár hónap és aktuális lesz. addig is sub :)

xterm

( ricsip v | 2020. 12. 15., k – 06:19 )

sub

kíváncsi vagyok mik teljesítik csak papíron a gigabitet

( _ventura_ v | 2020. 12. 15., k – 08:23 )

Most, hogy FTTH lett othton, kevés lett a virtualizált owrt egy Microserver N36L-en, főleg ha torrent is megy mellette :D Amúgy olyan ~700mbit kijöm maxon belőle. 

Elővettem a régi 1043NDv2 es routeremet, rátettem az legfrisebb openwrt-t 19.07.x -est. Amennyiben bekapcoslom a hw gyorsítást, sima DHCP + NAT-al 900mbit felett jött ki belőle. PPPoE-val + NAT már csak ~700 környékén.

Mivel nem fogok még egy dobozt tolni, ezért a N36L lesz lecserélve erősebb vasra, aztán nem lesz gond a gigabit routing.

Fedora 41, Thinkpad x280

( airween v | 2021. 01. 23., szo – 10:31 )

Szerkesztve: 2021. 01. 23., szo – 10:32

Nem akarok új témát nyitni, a "probléma" ugyanaz, mint fent: "szolgáltatás-minőség javulásból" kifolyólag 1Gbps a sebesség (ebből a valós most épp 950Mbps), és ha már ez itt van, tényleg jó lenne kihasználni ebből valamit.

Most egy ilyen lapból épített Linux végzi a NAT-ot:

https://ark.intel.com/content/www/us/en/ark/products/39942/intel-deskto…

Ezen van ugyan egy gigabites interface, de másik hálókártyát nem nagyon tudok beletenni a hátlap korlátjai miatt - most egy USB-ethernet átalakító a második IF. Van rajta egy mini PCIe, ill egy PCIe aljzat, de attól tartok maga a gép nem lesz képes pár száz Mbps-nél nagyobb sebességre.

Én mindenképp maradnék a PC-n futó Linux alapú megoldásnál - túl kényelmes volt ez eddig, hogy lemondjak róla :).

Ami kell: IPv4-en NAT, néhány iptables szabály... Fut egy PPTP, de az nagyon ritkán van használva. A mostani gépben a mini PCIe aljzatban van egy WiFI kártya, ami tudja az AP módot, ez egy bridge interface része az ethernettel, így kvázi WiFI AP-ként is működik, de ez már nem annyira fontos. Ja, és DNS, DHCP.

Nézegettem passzív hűtésű mini ITX lapokat, pl.

Kinek milyen tapasztalata van ezekkel Gb-es környezetben? Képes egy otthoni hálózatot kiszolgálni? Mire érdemes figyelni?

A 480 Mbps az elméleti maximum. A gyakorlatban nyilván számít, hogy milyen jellegű eszközökhöz használják. Más lesz a sebesség egy öreg pendrive és egy gyors SSD esetében, továbbá az sem mindegy, hogy egy USB/Ethernet adapter esetén milyen beállításokkal működünk. Egy 10/100-as adapter kisebb maximális keretmérettel dolgozik, mint egy gigabites, ahol a jumbo frame mérete 2000 byte helyett 9-10 ezer is lehet, és így az L2/L1 sebességarány is más és más lehet (nagyon nem mindegy, hogy 64, 512, 1024, 1500, 2000 vagy pl. 9600 byte a keretméret). Az USB 2.0 esetében további probléma, hogy egyetlen érpár van adásra és vételre. Firewire esetén jobb a helyzet, mert ott lehet full duplex átvitelt megvalósítani, pedig ott "csak" 400 Mbps az átviteli sebesség maximuma (feltehetően erre az értékre emlékeznek többen is, innen lehet a keveredés).

Köszi.

A PPPOE itt nem játszik, sima ethernet van (Telekom).

Az USB2 hátránya világos volt, azon gondolkodtam, hogy a mini PCIe-be tennék USB3-as kártyát, azt valahogy kivezetném, és arra tennék Gigás USB/eth átalakítót - ez vajh' működne?

Vagy érdemes lenne abba az aljzatba gigás ethernetet tenni? Bár azt csak úgy tudom kivezetni, ha hullik a fémforgács...

Ill van még opcióként az egy darab alaplapi PCI aljzatba egy gigás kártya valamilyen módon történő beapplikálása, bár ezt végképp nem tudom, hogy vezetném ki - max ház csere, ami lehet, hogy olcsóbb, mint új alaplap.

Ilyen CPU van rajta amúgy.

 

Méregettem most gigás switchen keresztül, de a gigabites interface-en keresztül sem tudok (jóindulattal) 240-250Mbps fölé menni:

$ dd if=/dev/zero of=tmpfile bs=10240 count=40960
40960+0 beolvasott rekord
40960+0 kiírt rekord
419430400 bájt (419 MB, 400 MiB) másolva, 5,21453 s, 80,4 MB/s
$ pv tmpfile > /mnt/tmpfile
 400MiB 0:00:56 [7,09MiB/s] [=========================>] 100%
$ pv /mnt/tmpfile > tmpfile2
 400MiB 0:00:14 [27,6MiB/s] [=========================>] 100%

A gépben egy 10+x éves SSD van, a 80MB írás mondjuk elmegy - de ez most nem számít.

A /mnt alatt egy NAS van felcsatolva SMB-n keresztül. Az írás olyan, amilyen, de az olvasás más gépen 50MB/s körül szokott lenni elég tartósan, 2-3 GB-os fájloknál is.

Ezért nem vagyok biztos benne, hogy ezen átmegy a Gb.

Hogy lehetne másképp ellenőrizni ezt?

Oh, nagyon köszi.

$ iperf -c 172.20.10.2
------------------------------------------------------------
Client connecting to 172.20.10.2, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[  3] local 172.20.10.254 port 38604 connected with 172.20.10.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   433 MBytes   363 Mbits/sec

Szóval szerintem ez nem fog nekem gigabitet routolni :).

Hmm... megnéztem a másik irányt is, az eredmény meglepett:

$ iperf -c 172.20.10.254
------------------------------------------------------------
Client connecting to 172.20.10.254, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 172.20.10.2 port 35998 connected with 172.20.10.254 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.08 GBytes   924 Mbits/sec

A tegnapi mérés a fordított irányban ua.

Mi okozhatja az eltérést?

A mérést az is befolyásolja, hogy mellette milyen egyéb forgalom zajlik.

 

Az iperf (ami tkp. iperf2) tud mindkét irányban mérni (akár egyszerre is), így nem szükséges megcserélni a szerepeket.

Az iperf feltehetően már nem nagyon fog fejlődni, inkább iperf3 javasolt helyette (tudom, írhattam volna előbb is, de csak most lett világos, hogy annak, aki nem nagyon használja ezeket, ez nem egyértelmű). Ez pl. ugyan nem tud egyidejűleg mindkét irányban mérni, és nem is tervezik, hogy ezt beleteszik, viszont minden másban jobbnak mondják a fejlesztők, az iperf esetében szerzett tapasztalatok alapján írták újra ezt. Iperf3 esetében változott az alapértelmezett port (5001 helyett 5201), meg kicsit a paraméterezés és az alapértelmezett megjelenítés is. Itt is lehet mérni szerepcsere nélkül a másik irányú sebességet (-R vagy --reverse).

A mérést az is befolyásolja, hogy mellette milyen egyéb forgalom zajlik.

Mondjuk azon a gépen nincs sok futó folyamat - a load 0.05, forgalom valamennyi van, de most épp minimális. És emellett van ez az asszimmetria - gondolom ha nagyon bekavarna más, akkor az mindkét irányban megjelenne.

Az iperf (ami tkp. iperf2) tud mindkét irányban mérni (akár egyszerre is), így nem szükséges megcserélni a szerepeket.

Közben megtaláltam én is - bár azt hittem, az iperf már a 3-as verzió, valóban csak a v2 volt. A `-r` kapcsolót is megtaláltam, használtam is, de így is aszimmetrikus az eredmény. (Megj.: a 3-asban nincs `-r`, csak `-R` - de lejjebb láttam, hogy írtad.)

Az iperf feltehetően már nem nagyon fog fejlődni, inkább iperf3 javasolt helyette (tudom, írhattam volna előbb is, de csak most lett világos, hogy annak, aki nem nagyon használja ezeket, ez nem egyértelmű).

Semmi gond, már azt tök jó, hogy van eszköz objektívebb vizsgálatra (nem ismertem korábban) :).

Ez pl. ugyan nem tud egyidejűleg mindkét irányban mérni, és nem is tervezik, hogy ezt beleteszik, viszont minden másban jobbnak mondják a fejlesztők, az iperf esetében szerzett tapasztalatok alapján írták újra ezt. Iperf3 esetében változott az alapértelmezett port (5001 helyett 5201), meg kicsit a paraméterezés és az alapértelmezett megjelenítés is. Itt is lehet mérni szerepcsere nélkül a másik irányú sebességet (-R vagy --reverse).

Ezeket is megtaláltam, köszi még egyszer. Sajnos az eredmény ua: ATOM -> kliens 360-370Mbps, kliens -> ATOM 970Mbps.

Okozhatja ezt a jelenséget az, hogy az Atomos gépen egy bridge interface van, ami összefog egy WiFI eszközt is? (A másik oldali kliensen is bridge-ben van az eth if amúgy... de ott a virtuális gépeknek van "csak".)

Nem lehet, hogy a kliens a gyenge láncszem a történetben? Úgy gondolom, küldeni egyszerűbb, mint venni, és az látszik, hogy amikor a kliens küld, akkor azt az ATOM CPU fel tudja dolgozni, viszont amikor az ATOM CPU küld, akkor a kliens nem tudja ezt megfelelő sebességgel "elkapkodni".

Az jutott még eszembe, hogy megpróbálhatod a küldést meghatározott sebességgel, mondjuk 200 Mbps-mal, majd ezt emeled addig, amíg a másik oldal már nem tudja azt fogadni. Alapértelmezésben TCP-vel megy a teszt, ha átkapcsolsz UDP-re, akkor egyszerűbb a dolga mindkét oldalnak, mert nem kell foglalkozni a nyugtázással.

Nem lehet, hogy a kliens a gyenge láncszem a történetben? Úgy gondolom, küldeni egyszerűbb, mint venni, és az látszik, hogy amikor a kliens küld, akkor azt az ATOM CPU fel tudja dolgozni, viszont amikor az ATOM CPU küld, akkor a kliens nem tudja ezt megfelelő sebességgel "elkapkodni".

Nem. A kliens jóval combosabb minden paraméterében: i3-7100 (4 core), 16G RAM, M2 SSD... Ill. az Atom gép switch-ének egy másik portjára tettem egy laptopot (i5, 8G RAM), és ott a mostani kliens, ill. a laptop között simán megvolt a 970Mbps, mindkét irányban. A laptopról az Atom felé ua, mint a mostani kliens felé: Atom -> laptop 970Mbps (tehát a laptop a kliens), laptop -> Atom 360Mbps (Atom a kliens).

Az jutott még eszembe, hogy megpróbálhatod a küldést meghatározott sebességgel, mondjuk 200 Mbps-mal, majd ezt emeled addig, amíg a másik oldal már nem tudja azt fogadni. Alapértelmezésben TCP-vel megy a teszt, ha átkapcsolsz UDP-re, akkor egyszerűbb a dolga mindkét oldalnak, mert nem kell foglalkozni a nyugtázással.

Az UDP önmagában elég katasztrofális eredményeket hozott (1Mbps körül volt mindkét irányban), most megnéztem az általad írt bandwiith kapcsolóval, így udp-n 650Mbps-t mért (1G-t adtam meg):

# iperf3 -R -c 172.20.10.254 -u -b 1G
Connecting to host 172.20.10.254, port 5201
Reverse mode, remote host 172.20.10.254 is sending
[  4] local 172.20.10.2 port 53057 connected to 172.20.10.254 port 5201
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-1.00   sec  69.8 MBytes   585 Mbits/sec  0.136 ms  0/8932 (0%)  
...
[  4]   9.00-10.00  sec  78.0 MBytes   655 Mbits/sec  0.062 ms  0/9990 (0%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec   766 MBytes   642 Mbits/sec  0.070 ms  24/98020 (0.024%)  
[  4] Sent 98020 datagrams

iperf Done.
root@basil:~# iperf3 -c 172.20.10.254 -u -b 1G
Connecting to host 172.20.10.254, port 5201
[  4] local 172.20.10.2 port 41006 connected to 172.20.10.254 port 5201
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec   102 MBytes   854 Mbits/sec  13038  
...
[  4]   9.00-10.00  sec   113 MBytes   948 Mbits/sec  14466  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  1.09 GBytes   938 Mbits/sec  0.087 ms  95757/143139 (67%)  
[  4] Sent 143139 datagrams

TCP-n nem megy 360-370M fölé.

Még egy furcsaságot láttam az Atomos gépen:

# mii-tool eth0
eth0: negotiated 1000baseT-HD flow-control, link ok

# ethtool eth0
Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Half 1000baseT/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: pumbg
	Wake-on: g
	Current message level: 0x00000033 (51)
			       drv probe ifdown ifup
	Link detected: yes

Tehát az mii-tool szerint half duplexben van, az ethtool szerint FD-ben :). A kernel szerint is FD:

# cat /sys/class/net/eth0/duplex
full

Szóval így elfogadom az FD-t, viszont egyelőre nincs tippem, mi lehet a szűk keresztmetszet.

viszont egyelőre nincs tippem, mi lehet a szűk keresztmetszet.

Nos, elkezdtem nézegetni, hogy lehetne a kernel modult paraméterezni, hátha az segít valamit, és belefutottam ebbe. Nálam detto ez volt a szitu:

# lsmod |grep 816
r8169                  77824  0

egyébként

# lspci | grep Eth
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03)

Szóval

# apt-get install build-essential linux-headers-`uname -r` r8168-dkms
...
# make
# make install
# init 6

és most ezt használja.

# lsmod |grep 816
r8168                 475136  0

Ill. most hasít, ahogy köll':

root@basil:~# iperf3 -c 172.20.10.254 -b 1G
Connecting to host 172.20.10.254, port 5201
[  4] local 172.20.10.2 port 37188 connected to 172.20.10.254 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   101 MBytes   845 Mbits/sec    0    233 KBytes       
...
[  4]   9.00-10.00  sec   110 MBytes   923 Mbits/sec    0    272 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.06 GBytes   907 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.05 GBytes   906 Mbits/sec                  receiver

iperf Done.
root@basil:~# iperf3 -R -c 172.20.10.254 -b 1G
Connecting to host 172.20.10.254, port 5201
Reverse mode, remote host 172.20.10.254 is sending
[  4] local 172.20.10.2 port 37192 connected to 172.20.10.254 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   101 MBytes   845 Mbits/sec                  
...
[  4]   9.00-10.00  sec   112 MBytes   941 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.08 GBytes   929 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.08 GBytes   928 Mbits/sec                  receiver

Ezzel már asszem' megbékélek :).

Valszeg bővítem a memóriát (most 512M van benne), és kipróbálom ezt.

 

Köszi mindenkinek.

Az UDP önmagában elég katasztrofális eredményeket hozott (1Mbps körül volt mindkét irányban)

:)  UDP esetén ez az alapértelmezett sebesség (TCP-nél meg alapesetben nincs korlátozás)

man iperf3

-b, --bandwidth n[KM]
              set target bandwidth to n bits/sec (default 1 Mbit/sec for UDP, unlimited for TCP).  If there  are  multiple  streams  (-P
              flag),  the  bandwidth  limit  is applied separately to each stream.  You can also add a '/' and a number to the bandwidth
              specifier.  This is called "burst mode".  It will send the given number of packets without pausing, even if that temporar‐
              ily  exceeds the specified bandwidth limit.  Setting the target bandwidth to 0 will disable bandwidth limits (particularly
              useful for UDP tests).  On platforms supporting the SO_MAX_PACING_RATE socket option (currently only Linux), fair-queueing
              socket-level pacing, implemented in the kernel, will be used.  On other platforms, iperf3 will implement its own rate con‐
              trol.

 

Tehát az mii-tool szerint half duplexben van, az ethtool szerint FD-ben :). A kernel szerint is FD

A mii-tool elavult, csak 10/100-as kártyák esetében tájékoztat jól (használok olyan beágyazott rendszert, ahol van a mii-tool mellett gmii-tool, az tudja a gigabitet is, és ott nem érhető el az ethtool), normál esetben ezt már régóta nem is használom, mindig ethtoollal nézem, hogy hogyan állt össze a link.

( airween v | 2021. 01. 24., v – 11:37 )

Találtam egy ilyet:

http://espressobin.net/

Itt lehet rendelni, 113 USD (postaköltséggel együtt, ehhez még egy SD kártya kell, és egy táp - szintén rendelhető ott).

Ezzel találkozott már valaki a gyakorlatban?

ha jol latom ez usabol jon, szoval picit dragabb lesz az (vam+afa+vamugyintezes)

Igen, valóban - köszi.

raadasul ketlem hogy ez erosebb lenne a mostani Atom-odnal:  1.2GHz- 64bit Dual Core ARM

Nem tudom, mennyire számít csak a CPU, ebben nem vagyok annyira otthon. Bár FSB meg egyéb paraméterek is elegendőek lennének a mostani gépben.

Találtam egy leírást, most ezt emésztgetem:

How to achieve Gigabit speeds with Linux

az ilyen pici "szappantarto" routerek ugy szoktak tudni gigabitet, hogy offloadolja, hardverbol csinalja a nehezet. altalaban olyan switch chip van benne, ami egyszerubb layer3/4 muveleteket (routing, nat, esetleg pppoe, ipsec) is tud, ha megfeleloen fel van programozva a regisztereivel.

es itt kezdodnek a bajok, mert a gyari fw-ben van valami zart driver/modul ami ezt megoldja, de pl. openwrt eseten ezt altalaban bukod, es tisztan szoftverbol meg a cpu/busz korlatai miatt a toredeket fogja csak tudni, es kozben jol melegszik is majd...

nem mindegy, hogy a cpu csak iranyitja, hogy mit merre kuldjon, vagy pedig minden packet atmegy rajta, sot szetszedi es ujra osszerakja...

ha megy is az offload/hwaccel, akkor meg a tuzfalad lesz korlatozott, mivel a forgalom kikeruli a cpu-t, a csomagokba se tud belenezni, jobb esetben is csak az egyes connectionok elso packetjet latja csak.

egy atlag x86 cpu megoldja izombol ezt, ott nem kell hwaccel, esetleg a checksum szamolashoz jo ha van offload, de azt pl. az intel halokartyak tudjak is eleg melyen (nem csak layer2). a mi egyik tuzfalunkban core2 proci megy 965 chipsettel es 2x10G intel kartyaval, anno teszteltunk 8 parhuzamos 1gbps ftp-t rajta keresztul es ment, kb 60% cpu terhelessel.

meg az intel kartyak mar regen is tudtak olyat, hogy szetkapta a bejovo csomagokat es kulon memoria teruletre gyujtotte a headereket es a payloadot, igy eleg volt a cpu-nak a headeres buffert neznie/modositania, majd a kartya ujra osszerakta, raszamolta a checksumokat es kikuldte.

Azért ez még sajnos csak a jéghegy teteje, mint minden az elbaszott informatikában, a részletekben rejtőzik el.

Mint pl. az x86 alapú többmagos rúterek teljesítményproblémái. Mert amíg annyival elintézzük a kérdést, hogy: áá, gond 1 szál se, az ARM-on ott van a fastpath meg a dedikált ASIC hardver a rútolás cpu-függetlenítéséhez, x86-on meg azt mondjuk az csípőből/izomból fogja bírni". Aztán megveszel egy embedded x86 boardot, mert nehogymár egy nagy asztali gép zúgjon, mert "csak" rútolni, "csak" tűzfalnak kell, elég lesz oda egy mini x86/x64 SBC (Single board computer). Csak aztán az olyan "egyszerű" dolgok, mint NAT, QoS, neadjisten vmi suricata IDS/IPS, na ezek Gigabit internet sebességnél már megeszik az embedded 1-2Ghz-es x86 CPU-t reggelire.

Aztán jön a marketing, hogy ugyan valóban csak gyenge szar 1-1.5-2Ghz a cpu, de van belőle 4 mag, azok együtt elbírnak a melóval! Meg intel IGB 200 chip-es a LAN, azon van 4 hardveres TX/RX queue, vagy ha megaloman vagy akkor IGB300 azon meg már 8 TX/RX queue van!  Akkor a csomagütemező Receive Side Scaling-el (RSS) szét tudja osztani 4 cpu-ra a forgalmat, megoldott a gond!

Igen, csak azt sehol nem írják, hogy a Gbit internet-elérés a végfelhasználónak a PPPoE protokollon jön be (azaz amikor username+password kell az internetre "betárcsázáshoz" pl. Digi-nél), na ez az RSS szabvány whitepaper-ben is a szokásos ködösítéssel nincs kimondva egyértelműen, de végül csak nem kompatibilis az RSS-el. Ilyenkor minden pppoe forgalmat a hash algoritmus csak a default ID 0  queue-ba fog küldeni, tehát ilyenkor hajadra kenheted az RSS-t, meg a multi-queue NIC-et, meg a sokmagos processzort: 1 mag 100% koppon ki van hajtva, a másik 3 vagy 7 meg 0%-ob unatkozik.

VPN pont ugyanez a téma, azok is a többség 1 szálúra vannak korlátozódva. A crypto-t CPU-ban hardveres AESNI-vel gyorsítást pedig elvileg 1 időben ugyancsak 1 proceszormag futtathatja, pont azért h. ne legyenek mindenféle cach-timing jellegű hibák kihasználhatóak a párhuzamosan többi magon is futó AESNI-nél.

Az interneten népszerű benchmarkoknak az a fix becsípődése (BSD router Project pl.) hogy ők nagy szolgáltatói rúter szemléletű méréseket végeznek. Nem az 1 gép esetén elérhető bandwidth maximalizálást! Azaz ahol sok kis felhasználó forgalmát szimulálják egy rúteren átfolyatva. Ahol a rúter csak buta csomagtovábbító robot. Így megvan a kényelmes feltételezés, hogy a rúternek az a dolga h. a csomagot a bejövő interfészéről egy kimenő interfészére dobja tovább. QoS, tűzfal, NAT, IDS/IPS, ez mind nem létezik, ilyesmi nem része az ideális tesztkörnyezetüknek. Továbbá megvan a kényelmesen sok egymástól független (egyenként amúgy elég alacsony sávszélességű) network flow, amit a spéci ilyen felhasználásra tervezett hardver+szoftver szépen szét tud osztani multi-queu NIC, multi-core processzor. Így a mérésük máris hozza azokat az átviteli sebességeket, amiket te egy kis hálózatban, ha a célod csupán 1-2 v. pár kliens, már nem fogsz tudni soha hozni. Értsd a különbséget a mért teszt-eset és a te valós felhasználási modelled között! Bónusz pont h. a BSD router project szerint A-ról B gép-re küldött 1Gbit/sec forgalom az a mért rúteren 2Gbit/s teljesítményt jelent: 1gbit/s a bejövő interfészen+1gbit/sec a kimenő interfészen.

Szóval a végén ugyanoda lyukadunk ki: csak a legdrágább legbikább processzorral felszerelt vas fogja tudni a teljesítményt, ha akármit is be akarsz kapcsolni egy rúteren.

nagyjabol egyetertek, de azt azert tegyuk hozza, hogy a routeolashoz nem igazan van szukseg cpu powerre, ott az ilyen pici/embedded x86 lapok az i/o teljesitmenyuk miatt buknak el (irq kezeles, dma, busz sebesseg stb). meg mert ezeken jellemzoen valami filleres buta realtek nic van, vagy megrosszabb esetben usb-s atalakitassal (ras.pi ilyen asszem)

masreszt az intel nic-ek mar nagyon sok eve is tudtak olyat, hogy szetszedi a packetet headerre es payload-ra, es csak a headerrel kellett a cpu-nak foglalkoznia, a data vegig a nic buffereben marad, kuldeskor osszerakja, ujraszamolja a checksumokat es tx.  az egyik nagy egyetem telephelyen egy core2-es embedded pc routeolja es tuzfalazza (layer4 filter, nat) 2x10G-n a teljes forgalmat! (https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c02536759)

ahogy a cryptot is tudja mar minden normalis NIC hardveresen, persze ahhoz az kell, hogy szabvanyos protokollal hasznald (pl. ipsec), es ne ilyen ganyolt-takolt szoftveres megoldasokkal, mint openvpn meg wireguard...

suricatat es a layer7 szureseket ne keverjuk ide, az armon is lassu meg kb mindenen, ahhoz tenyleg durva vas kell, vagy 10+ millios celhardver, foleg ha min. gigabites sebesseged is van melle.

Wireguardot nem kell szídni, egy relatív lassú ARM Cortex A53 (Odroid C2) is képes 1 Gbps titkosítására WG-vel. J1900 Celeron szintén kikoppantotta nálam a gigás vonalat.
Ellenben ha vannak 10G interfészes szervereid, kíváncsi vagyok hogy WG közöttük + iperf3 mennyit visz és közben milyen mértékben zabálja a sokmagos vasat?
Ne lepődj meg, a WG kernelben fut és sok szálon.

Egy blogban láttam, ott a szerző valami Linixot tett fel (Arch? - de ez mindegy), nekem az jobban kézre állna :). A lényeg, hogy fut rajta Linux is - mondjuk az, hogy ARM, nem tudom miben korlátozhat (pl a mostani gépen egy fut egy unify szerver egy Ubiquity AP-nek - nem tudom, ennek van-e ARM-es portja, de ez csak egy példa.)

Semmilyen hátrányt nem jelent az, hogy ARM. Teoretikus elég elméleti érveket hallottam bigendian mellett, mert routernél a nagy átfolyó adatok miatt előnyös, de ebben sincs egyetértés. Ezért a little- big-endian örök vita egyik fejezetének tartom csak. Különben az x86 is little-endian. Az ennél gyengébb MIPS cpu magokkal működő routerem szépen teljesíti a Gigabitet. Máig nagyon népszerű a MIPS a routergyártóknál valószínűleg azért, mert a teljesítményarányos árazása a legkedvezőbb. 

Valszeg félreérthető voltam: nem a *endian vita érdekel, hanem ha van valami XYZ szoftver, aminek nincs forráskódja (nem tudom, a unify proginak van-e publikus forrása), vagy van de szívás saját binárist csinálni, akkor az elérhető-e erre az architektúrára? Azért az x86/amd64 vonal elég támogatott most már Linuxon (még egy példa eszembe jutott: VPN kliensek), de hogy az ARM hogy áll, az passz.

( nagylzs v | 2021. 07. 30., p – 23:11 )

Van egy új üdvöske. https://mikrotik.com/product/rb5009ug_s_in néhány napja jelentették be. Itthon még talán nem lehet kapni. A CPU gyorsabb mint az rb4011. Van benne 2.5 gbps réz port és sfp+ port is. Viszont csak routeros 7 fut rajta. Nem tudom mennyire stabil. A CSS610 fiaskó óta szkeptikus vagyok az újdonságokkal...