Gigabit TP-Link OpenWRT-vel

Hálózati eszközök

Melyik TP-Link router tud valóban gigabitet OpenWRT rendszerrel is?
Eléggé sok TP-Link max sebessége ugyanis visszaesik 300mbps környékére ha OpenWRT kerül rá. A NAT címfordításnál használt hw-hez nem adott ki valamit a gyártó ha jól hallottam. IPv6-tal talán ezek is tudnák a gigabitet de nekem IPv4 mellett kell.

( anthony_ v | 2018. 01. 04., cs – 20:28 )

Szia!

WDR4300 és egy (ac-s china router)ZBT3526 -ot hajtok
Fasthpath-os lede-vel.750MBit átmegy rajta ami nekem elég.A gyári firmware-ek se tudnak sokkal többet.Egyébként pont tegnap méricskéltem.

Üdv:Anthony_

Annak a gyári firmware konkrétan hibás. Talán szándékosan, ismert és javítatlan biztonsági hiba van benne. Én még lede előtti időkben használtam az akkori OpenWRT-vel és ez is csak 300mbps-ot tudott. Azóta akkor ez már felment 750mbps-re. Ez jó hír de még mindig nem gigabit.

Normális HUP-ot használok!

PPPoE-vel sem mertem, mert ahol van ott nem volt gigabites net. Normal IPv4 NAT nehany szaballyal viszi gigabitet. Elmeletben PPPoE is hardveresen gyorsitott mar, ha lesz alkalmam hazahozok egyet es kiprobalom itthon (gigabites IPv6 kepes net). Szimulalni gigabites PPPoE-t nem tudtam, mert laborban nem volt erre kepes eszkoz. RB750Gr3-at pedig nem tartunk, mert VLAN nem hardveres, hanem szoftveres (fel kell kuldeni a CPU-nak) benne es ez csak smbnek felel meg. Viszont nehany het mulva valoszinuleg telepitek parat, akkor majd merek egyet.

Igen. A 30k huf alatti kategóriában mindenképp. Persze ezek a TP-Link és ASUS téglák súrolják néha az örökké sérülékeny firmware-jeikkel, meg a "remek" Mikrotik dobozkák is az alig frissített kernellel.
A gigabit meg közben 3000Ft lett. :D

"If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe."

Ezt eddig nem ismertem, ha tényleg igazak a teszteredmények, akkor nagyon impresszív. De jól látom, hogy ez azért még nagyon nincs mainline LEDE release-ekben, illetve jár vele pár nemtriviális kompromisszum is (pl QoS nem működik)?
---
Régóta vágyok én, az androidok mezonkincsére már!

Természetesen jó, hogy van ilyen lehetőség. Nem is erre gondoltam, hanem példát akartam hozni, hogy ez természetesen nincs ingyen, feature kompromisszummal jár (mint ahogy pl HW NAT is), és jelenleg nem nagyon találni a kompromisszumokról összeszedett leírást. Lehet, hogy valakinek triviális, másnak nem feltétlenül.
---
Régóta vágyok én, az androidok mezonkincsére már!

+1
jó volna látni egy hiteles ember tolláből listát, mik azok a hálózati tulajdonságok/környezeti adottságok/paraméterek amik mind nem kompatibilisek a HW NAT-tal.

Csak 1 példa: mondjak le a tűzfalról, mint olyanról, csak mert az is CPU-ból megy(menne)? Azért az vicces így 2018-ban. Nem nagyon hallottam még ASIC-alapú tűzfalról, ahol 10Gbit-eket tűzfalaznak, ott fogják és berakják a legdrágább intel xeon-t, ami kapható adott pillanatban a piacon.

Vagy a PPPoE-el egyáltalán kompatibilis-é? --> https://www.speedguide.net/faq/what-is-nat-acceleration-495

"and you may have to disable PPPoE"

ez jó vicc, mert akkor az összes Digi-s gigabit user vehet PC-t/ x86 szervert rúternek, az olcsó(bb) Arm/Mips rúter mind megy a levesbe.

És mi egyéb mehet még a levesbe? Qos? Annak hiányát talán még túl lehet élni gigabit-nél (marad elég mindenre akkor is ha egyszerre rengeteg különféle alkalmazás is forgalmaz). Kivéve persze ha több torrent user is 1 időben kűzd a wirespeed letöltésért.

Forgalom statisztika? Vagy csak a részletes protokoll szintű? A primitív layer2 szintűt a switchport/NIC még ki tudja adni CPU nélkül is?

Megannyi kérdés, kevés válasz :-|

--

Azert sok OpenFlow-t (is) tamogato ASIC van, ahol verziotol fuggo megkotesekkel sok halozati funkciot tudsz implementalni. Igy CPU-nak forwarding plane-el nem kell torodnie, igy control-ra eleg mondjuk egy ARM CPU mikozben 10/40/100 Gbit/s forgalmak mennek at az eszkozon. Azonban ezek eleg draga eszkozok. Nagyobb sebessegeknel egyebkent sem hasznalnak iptables-t, se a kernel halozati stack-jet. Ekkor jonnek elo DPDK es tarsai.

Gondolom a 10-15 ezer jómagyarforintos kínai tplink kacatok még nem az a kategória, ahol ilyen okos ASIC-ek előfordulnak nagy számban :D

Én leginkább ennek a soho-gagyi kategóriának a HW NAT defektjeit/képességeit szerettem volna egy ide benéző orákulumtól megtudni. Jó legyen, még a Nóbel díjat is kiosztom ha vki megválaszolja! Deal?
--

Lehet, hogy nincs senki, aki innen ezt mar kiprobalta mostanaban. Nalam van aktiv szolgalatban Archer C7 es Archer C2600, viszont az elobbi helyen csak 120/10-es UPC van, a masik helyen pedig 100/100-as Digi, de itt a feltoltes nagyon ritkan tud a garantalt 50 megabit fole menni, ezert nem is gondolkodtam abban, hogy nagyobb csomagra valtsak. Ezeket a sebessegeket pedig mind a ketto eszkoz rohogve kiveri magabol.

---
Apple iMac 27"
áéíóöőúüű

A legtöbb leírás és teszt a témában itt van: https://forum.openwrt.org/t/qualcomm-fast-path-for-lede/4582
Sajnos az a helyzet, hogy ezekből mégha kerül is ki néha opensource verzió, utána a gyártó ezt már nem nagyon frissíti, a kernelek meg szépen elhúznak tőle verziószámban. Pár lelkes ember reszelgeti ezeket ha épp nem unnak bele, még akkor is ha amúgy értelmes lenne a téma.

A hangsúly szerintem a "fastpath"-on volt (bár ugye nem én írtam a megjegyzést). Az tudtommal bizonyos csipekhez van csak, de amikor utoljára néztem (1-2 hónapja), akkor nem volt a gyári OpenWRT-ben/Lede-ben. No majd talán most az egyesülés után!

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( taarzaan | 2018. 01. 05., p – 03:09 )

tl-wr1043ndv1 ment LEDE-vel, vezetéken gigabittel (917 Mbittel, ha pontos akarok lenni - mert láttam, hogy a 750 nem elég), iperf-fel teszteltem

Szia, bocs a késedelemért, engedélyezve volt az ipv6, de ipv4 címek között teszteltem, LEDE 17.01.4, nem tudom, mi az a fast path, default telepítés volt.


iperf -c 192.168.1.208 -i 2 -t 20
------------------------------------------------------------
Client connecting to 192.168.1.208, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.237 port 50912 connected with 192.168.1.208 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 2.0 sec 211 MBytes 887 Mbits/sec
[ 3] 2.0- 4.0 sec 218 MBytes 915 Mbits/sec
[ 3] 4.0- 6.0 sec 224 MBytes 938 Mbits/sec
[ 3] 6.0- 8.0 sec 221 MBytes 927 Mbits/sec
[ 3] 8.0-10.0 sec 224 MBytes 940 Mbits/sec
[ 3] 10.0-12.0 sec 218 MBytes 915 Mbits/sec
[ 3] 12.0-14.0 sec 216 MBytes 906 Mbits/sec
[ 3] 14.0-16.0 sec 223 MBytes 936 Mbits/sec
[ 3] 16.0-18.0 sec 216 MBytes 904 Mbits/sec
[ 3] 18.0-20.0 sec 215 MBytes 902 Mbits/sec
[ 3] 0.0-20.0 sec 2.14 GBytes 917 Mbits/sec

Na ácsi. Ha csak nincs perverz módon subnetelve (/27, vagy hosszabb maszkkal) a hálózatod, akkor a fenti két cím között nincs routolás, csak a switch, ami L2-ben, nem pedig L3-ban dolgozik - az meg ordenáré randa lenne, ha egy gigás switch nem tudna gigabitet áttolni a portjai között.

( freeoli v | 2018. 01. 05., p – 06:48 )

PC alapu megoldast javaslok. Egy ilyen doboz egy openwrtvel nem sokra jo, tuzfalnak meg natra meg meg sokmindenre de azert nem az igazi.

Egy pc alapu megoldassal lehetoseged lenne av szueresre, ids-re stb-re. Mindenre amire ma mar sajnos egyre nagyobb szukseg van.

Egy dual lan brix vagy hasonlo kis megoldas egy opnsensel igen jo szolgalatot tehet nem sokkal nagyobb fogyasztasert de picivrl dragabban.

Nekem a Gigabyte Dual Lan Brix fogyasztása kicsit magas egy non-stop működő routernek. Egy nagyobb irodának viszont már megéri. A fent említett kínai dual lanos Partaker B5 pc csak 6 wattot fogyaszt ha hinni lehet a gyártó specifikációjának.
Ha már pc a router pfSense vagy inkább OpenWRT?

Normális HUP-ot használok!

Ez jo lehet, de ugyanannyit fogyaszt mint egy itthon vasarolt ugyanilyen procis cucc.

Trey csinalt egy tesztet egy vassal, olvasd el es en arra szavaznek. Lehet, hogy 40k, viszont egy utm-ed lesz, nem egy nat-ra eppen kepes dobozod.

A plusz fogyasztas havi 200ft-os tetelet viszont boven megeri.

https://hup.hu/cikkek/20170327/opnsense_teszt

En erre szavaznek. Igaz, a gb nat sebesseget meg kene tudni elotte, de kellene mennie.

Nem rossz. Mondjuk mire mindent megveszel hozzá már bőven 40 felett lesz de legalább lesz egy jövőbiztos routenek használható vasad. Az opnsenset a linkelt cikknél is lehúzzák, szóval jobb a pfsense. OpenWRT-ről nem esik szó. Az is egy lehetőség pc-re is.
Az eddigiek alapján egyetlen alternatíva a fentebb említett Mikrotik RB750Gr3. Az kevesebb mint fele annyiba kerül mint egy kis fogyasztású pc legalább két eth porttal. Viszont a Mikrotik hardverből nem támogatja az OpenVPN-t csak szoftverből lassan, alacsony mbps mellett.
A PC router miatt fanyalgókat pedig nem értem. Otthonra nem csak nálam hanem sokaknál elbuknak a gyári soho routerek a gigabites kanyarnál. Juniper azért túlzás lenne és a fogyasztása különben sem alacsony. A pc router árban ugyan a drágább otthoni routerekkel van egy szinten, viszont valóban tudja a gigabitet és extraként valóban tud gyors openvpn-t is.

Normális HUP-ot használok!

Nem az IPsec a lényeg. Van benne 450Mbps képességű cryptoengine avagy cryptodev, ami nem a vpn, ipsec, stb. megvalósítására, hanem azon belül a tetszőleges chiper() gyorsítására jó. Ebből a szempontból az IPsec, vpn, ssl, ssh "csak egy szoftver", amelyeknek belül az egyes blokkok titkosítását végzi el a cryptodev().

Nem tudja, mert OpenVPN nehezen gyorsithato hardveresen + Mikrotik implementacio nem tul jo (UDP mod nem tamogatott). Ennek ellenere nekem van Mikrotik OpenVPN halozatom >10 telephelyes. Csak alacsony forgalmu HTTP kapcsolat megy rajta es kitunoen mukodik mindig. IPsec-es halozatom tobb is van, de sajnos idonkent vannak problemak veluk (dinamikus IP, NAT miatt), ugyhogy tobb scriptem intezi hogy a kapcsolattal ne legyen problema.

( bennyh | 2018. 01. 05., p – 12:52 )

A mai routerek, már amelyikben van támogatás, jobban bírnák IPv6-al az iramot mint szoftveresen NATolva? Mármint lehet IPv6-on meg tudnák lépni a gigabitet, ha v4-en le vannak maradva pár százassal?

Vagy legalábbis elég jól megközelítenék.

Gondolj bele, IPv6-on nem kell natolni, (címet cserélni) csak útválasztani,
továbbpasszolni a következő routernek, ami nem számításigényes történet,
de ne feledd, PPPoE, még akkor is szoftverből megy, ami 100-200Mbit-ben korlátozza a maximumot!

"PPPoE, még akkor is szoftverből megy, ami 100-200Mbit-ben korlátozza a maximumot"

Na ez, így, ebben a formában nem igaz. PPpoE, IPv4/IPv6 dual stack, de a mérés IPv4-en megy, és biza' 7-800 Mbit/s bármikor megvan. Nem top kategóriás router (Asus RT-N18U), gyári firmware.
Ha a NAT is CPU-ból menne mindenestől, akkor valóban ilyen khm. híg fos kategória lenne a sebessége. A régi TP-Link is tud 350-400Mbit/s-ot gyári firmware-rel - 3rd party gányware-rel valóban 100-200mbit/s megy át rajta.