Hirdetés
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Geri Bátyó: Agglegénykonyha 22 – Unortodox rakott krumpli
- Elektromos rásegítésű kerékpárok
- sziku69: Fűzzük össze a szavakat :)
- bobalazs: Artcraft - Az Adobe/Microsoft/egyéb termékek trónfosztója
- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- Luck Dragon: MárkaLánc
- Ketogén étrend
- Yézi: Forza Horizon 2, már PC-n is
-
LOGOUT
LOGOUT
Új hozzászólás Aktív témák
-
Sziasztok!
Gondoltam megosztom veletek egy nemrég megoldott hálózati rejtélyemet, hátha megkímélek pár embert az őszüléstől és a felesleges hibakereséstől. Régebben írtam ide is hátha valaki már belefutott és tud segíteni, SŐT már sensitive nélkül benyomtam a Gemininek és a ChatGPT-nek is, nem találtak hibát.A jelenség: Adott egy MikroTik RB4011 (RouterOS v7.23.5). Azt vettem észre, hogy közvetlenül a bootolás után az 1 GB RAM-ból kapásból le van foglalva majdnem a fele (csak kb. 550 MB volt szabad). A konfigom patyolattiszta: Szerintem jó tűzfal,6 WireGuard tunnel, egy kis Source NAT/Hairpin NAT, semmi olyan extrém dolog, ami indokolná ezt a masszív, azonnali memória pazarlást.
Változás: Azóta változtattam a hálózaton, és az SFP+ -ba egy DAC-al összekötöttem egy 2.5GbE switchet, amik a Jumbo Frames portokon voltak átkerültek a switch-re.
Ezek után: Mindent (is) átnéztem, kiderült, hogy a tettes a Jumbo Frame (MTU beállítás) volt, méghozzá olyan portokon is, amikbe kábel sem volt dugva!
3 ethernet port MTU-ját és L2MTU-ját 9014-re megemeltem. Gyorsulást nem vettem észre de örültem a buta fejemnek hogy mekkora terhelést levettem a routerről és a PC-kről...Megette a RAM-ot a 3üres port... A RouterOS v7 drivere a hardveres puffereket statikusan, már a bootolás pillanatában lefoglalja, nem pedig dinamikusan osztja ki. Az RB4011-ben egy négymagos (AL21400) proci van. A router a beállított 9014 bájtos csomagméretet beszorozza a hardveres tárolóhelyek számával (RX/TX Queues, ami portonként több száz leíró), majd ezt megszorozza a 4 processzormaggal.
A kernel ezt a hatalmas memóriablokkot fixen lezárja magának, hogy gigabites tempónál ne legyen csomageldobás. Mivel 3 porton is bekapcsoltam a 9K MTU-t, a router kapásból levágott kb 300 MB RAM-ot, függetlenül attól, hogy volt-e egyáltalán forgalom a porton.A megoldás: Visszaállítottam a kérdéses portokon az MTU-t a szabványos 1500-ra. A szabad RAM reboot után 840-850MB.
Tanulság: Ha RouterOS v7-et (főleg többmagos vason) használtok, és indokolatlanul magas az alap memóriafoglalásotok, csekkoljátok az Interfaces menüben az MTU értékeket! Ha Jumbo Frame-re nincs feltétlenül szükség, hagyjatok mindent a szabvány 1500-on, mert a router RAM-ja fogja bánni.
Remélem segít valakinek!
-
lionhearted
őstag
-
-
Belső hálózaton használtam nagy fájlok adatátvitelére.
Az RB4011 meg sem érezte, csak a PC-k és a szerver CPU terhelése csökkent, mert nem kell levágni a csomagot 1472-re, kevesebb csomag, kevesebb CPU terhelés. Gyorsulás nem volt, az 1GbE-t ugye nem lehet átlépni, csak a kíváncsiság hajtott, és a digitális "férfinemiszerv" méregetés, amiről le kell szoknom
-
Sziasztok!
Gondoltam megosztom veletek egy nemrég megoldott hálózati rejtélyemet, hátha megkímélek pár embert az őszüléstől és a felesleges hibakereséstől. Régebben írtam ide is hátha valaki már belefutott és tud segíteni, SŐT már sensitive nélkül benyomtam a Gemininek és a ChatGPT-nek is, nem találtak hibát.A jelenség: Adott egy MikroTik RB4011 (RouterOS v7.23.5). Azt vettem észre, hogy közvetlenül a bootolás után az 1 GB RAM-ból kapásból le van foglalva majdnem a fele (csak kb. 550 MB volt szabad). A konfigom patyolattiszta: Szerintem jó tűzfal,6 WireGuard tunnel, egy kis Source NAT/Hairpin NAT, semmi olyan extrém dolog, ami indokolná ezt a masszív, azonnali memória pazarlást.
Változás: Azóta változtattam a hálózaton, és az SFP+ -ba egy DAC-al összekötöttem egy 2.5GbE switchet, amik a Jumbo Frames portokon voltak átkerültek a switch-re.
Ezek után: Mindent (is) átnéztem, kiderült, hogy a tettes a Jumbo Frame (MTU beállítás) volt, méghozzá olyan portokon is, amikbe kábel sem volt dugva!
3 ethernet port MTU-ját és L2MTU-ját 9014-re megemeltem. Gyorsulást nem vettem észre de örültem a buta fejemnek hogy mekkora terhelést levettem a routerről és a PC-kről...Megette a RAM-ot a 3üres port... A RouterOS v7 drivere a hardveres puffereket statikusan, már a bootolás pillanatában lefoglalja, nem pedig dinamikusan osztja ki. Az RB4011-ben egy négymagos (AL21400) proci van. A router a beállított 9014 bájtos csomagméretet beszorozza a hardveres tárolóhelyek számával (RX/TX Queues, ami portonként több száz leíró), majd ezt megszorozza a 4 processzormaggal.
A kernel ezt a hatalmas memóriablokkot fixen lezárja magának, hogy gigabites tempónál ne legyen csomageldobás. Mivel 3 porton is bekapcsoltam a 9K MTU-t, a router kapásból levágott kb 300 MB RAM-ot, függetlenül attól, hogy volt-e egyáltalán forgalom a porton.A megoldás: Visszaállítottam a kérdéses portokon az MTU-t a szabványos 1500-ra. A szabad RAM reboot után 840-850MB.
Tanulság: Ha RouterOS v7-et (főleg többmagos vason) használtok, és indokolatlanul magas az alap memóriafoglalásotok, csekkoljátok az Interfaces menüben az MTU értékeket! Ha Jumbo Frame-re nincs feltétlenül szükség, hagyjatok mindent a szabvány 1500-on, mert a router RAM-ja fogja bánni.
Remélem segít valakinek!
-
user12
őstag
Szeptemberi newsletter
https://mt.lv/news135 -
E.Kaufmann
veterán
7.25-ben jön rengeteg javítás és:
*) wifi - improve stability;
*) wifi - add fast transition support for MLD devices;
*) wifi-qcom - fix disconnects during fast transition roaming;
*) wifi-qcom-be - upgrade driver and firmware;Talán utána már szabadon engedik árulni a be3-at.
De jó, hogy lényegében csak a Wifi-t nem használom a RouterOS alatt
-
-
-
Hali!
Ma reggelre nem volt net elérés.
Első körben beléptem a saját MikroTik router felületére és kiderült mi a gond:"DoH server connection error: SSL: ssl: no trusted CA certificate found (6)"
és
"DoH server connection error: SSL: ssl: no trusted CA certificate found (6) [ignoring repeated messages]"
üzenetekkel volt tele a Log lista.
Tegnapig ez működött szépen.
RB4011 ROS 7.23.5
Első körben kikapcsoltam a "Verify DoH Certificate" opciót.
Ettől megnyugodott.
DoH Server-nek "https://security.cloudflare-dns.com/dns-query" volt beállítva.
Mindenesetre frissítettem 7.23.7 verzióra, amit nem javította meg a "Verify DoH Certificate" problémát. Mivel indulnom kellett, maradt kikapcsolva.
Most beléptem megint, és egy adag "dns, warning" üzenetet találtam:"DoH server response not OK: 502: <html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
<hr><center>cloudflare</center>
</body>
</html>"Mi törpénhetett?
-
Próbáltam átállni a
"https://dns.google/dns-query"
"https://8.8.8.8/dns-query"
"https://8.8.4.4/dns-query"
DoH címekre, de ilyenkor
"DoH server connection error: timeout waiting data
és
DoH server connection error: timeout waiting data [ignoring repeated messages]"
"dns,error" hibaüzeneteket kapok
-
Hali!
Ma reggelre nem volt net elérés.
Első körben beléptem a saját MikroTik router felületére és kiderült mi a gond:"DoH server connection error: SSL: ssl: no trusted CA certificate found (6)"
és
"DoH server connection error: SSL: ssl: no trusted CA certificate found (6) [ignoring repeated messages]"
üzenetekkel volt tele a Log lista.
Tegnapig ez működött szépen.
RB4011 ROS 7.23.5
Első körben kikapcsoltam a "Verify DoH Certificate" opciót.
Ettől megnyugodott.
DoH Server-nek "https://security.cloudflare-dns.com/dns-query" volt beállítva.
Mindenesetre frissítettem 7.23.7 verzióra, amit nem javította meg a "Verify DoH Certificate" problémát. Mivel indulnom kellett, maradt kikapcsolva.
Most beléptem megint, és egy adag "dns, warning" üzenetet találtam:"DoH server response not OK: 502: <html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
<hr><center>cloudflare</center>
</body>
</html>"Mi törpénhetett?
Próbáltam átállni a
"https://dns.google/dns-query"
"https://8.8.8.8/dns-query"
"https://8.8.4.4/dns-query"
DoH címekre, de ilyenkor
"DoH server connection error: timeout waiting data
és
DoH server connection error: timeout waiting data [ignoring repeated messages]"
"dns,error" hibaüzeneteket kapok -
Azt szarul írtam, mert már azt se tudom hol áll a fejem, annyi féle verziót próbáltam az elmúlt napokba / héten.
Annál a mérésnél ahol 2.3G van ott ez volt a konfig:
ether1 → közvetlenül a PPPoE kliens
vlan-filtering ki volt kapcsolva
az ether1 nem volt a bridge-ben
PPPoE → ether1
eredmény: ~2300/2000 Mbit/s
ether1 → bridge1
bridge1 → VLAN 10
PPPoE → vlan10-WAN
vlan-filtering=yes
sfp1 pedig trunkként viszi a VLAN10/20-at
eredmény: ~85/2000 Mbit/s -
-
Erre kukkants már rá pls, hogy így van-e állítva:
(bridge-en belül, vlan fül, én webguiból fotóztam ki)
A pvid érték nem lényeg, igazabol a hw offload jutott eszembe
-
Jerry311 kollegát idézném: “DAC esetén is ott van két modul a két végén, csak nem tudod kihúzni belőle a kábelt. (egynél többször
)”A modulcserére én se gondoltam első körben, de megoldottad
Ezt leszámítva egyebként jók a kínai modulok? En még nem mertem bevállalni. Van itthon egy Mikrotik XS+DA001 meg pár Ubi SFP+ kábelem, azokat hasznaltam összeköttetésre; meg a cégnél origi Dell kábeleket. -
Semmilyen, 1db utp kábel, 2db DAC.
UTP megy közvetlen a Kaon-ból az 5009 ether1-es 2.5G-s portjába, az SFP+ pedig a CRS felé.Jerry311 kollegát idézném: “DAC esetén is ott van két modul a két végén, csak nem tudod kihúzni belőle a kábelt. (egynél többször
)”A modulcserére én se gondoltam első körben, de megoldottad
Ezt leszámítva egyebként jók a kínai modulok? En még nem mertem bevállalni. Van itthon egy Mikrotik XS+DA001 meg pár Ubi SFP+ kábelem, azokat hasznaltam összeköttetésre; meg a cégnél origi Dell kábeleket. -
Nos akkor megoldva
A kínai réz modul a probléma. Nem mondanám hogy hibás, mert amúgy meg nincs vele gond ha VLAN nélkül használom, akkor tökéletes.
Ígértek már korábban is egy mikrotik 10G modult, de még mindig nem ért el hozzám.
Azzal majd végérvényesen tudom majd megerősíteni, vagy cáfolni. -
Direktbe (ha nincs VLAN) gyönyörűen van internet, korábban is ezt az 5009-et használtam amíg 2000/1000 volt azt vitte gyönyörűen.
Amúgy összességében nem nagyon terveztem ezzel az eszközzel hosszú távon, mert DIY router lesz ahol nem kell VLAN meg egyéb vacakolás, csupán érdekelt volna, hogy hol a teteje ennek az eszköznek és hajtott a kíváncsiság.
De per pill egyre jobban nyűg már ez az egész, és bár ritkán szoktam beletörődni a dolgokba, és legtöbbször ha hagyok is szünetet a végén azért addig csinálom, amíg ki nem derül de ezt most lehet el fogom engedni.
Alapból is azt hittem mostanára már rég elérhető lesz az MWC-n beharangozott hex pro, de annak se híre se hamva, és ebből kifolyólag szerintem idén már nem is igen fog jönni, így jött az, hogy akkor kellemest a hasznossal majd jön CHR alapon épített router, ami több mindent is el fog látni a router funkciókon kívül.Nos akkor megoldva
A kínai réz modul a probléma. Nem mondanám hogy hibás, mert amúgy meg nincs vele gond ha VLAN nélkül használom, akkor tökéletes.
Ígértek már korábban is egy mikrotik 10G modult, de még mindig nem ért el hozzám.
Azzal majd végérvényesen tudom majd megerősíteni, vagy cáfolni. -
En nem ertek a mikrotikhez, de ha a gyarto sem tud semmit, akkor valoszinuleg a valaszt egy wireshark hamarabb adja meg, mint a support. Szerintem egyelore engedd el a 4G dolgot, es fokuszalj arra, hogy legalabb a 2.5 gbitet kellene tudnod hozni az sfp-n at is. Es nyilvan nem hozod, mert <100 mbit van. En azt gondolom, hogy a ket dolog osszefugg. Ha rajossz, hogy mitol csokken le a sebesseg amikor vlan van, ahhoz kepest, mint amikor nincs, akkor szerintem kozelebb kerulsz ahhoz a valaszhoz is, hogy az eredeti felallasban miert nem tudod a 4gbitet kihajtani. Keszits ket wiresharkot, a 2.5 gbit felallasban (vlannal es anelkul) es hasonlitsd ossze, hogy mi a kulonbseg. Nem az eszkozben, hanem a rogzitett forgalomban. Ha megtalalod, akkor valoszinuleg meglesz a valasz a 4G kerdesre is.
-
Azóta írtak még egyet az még annyit segítség se volt mint elsőre.
Hello,
MTU has been a mere suggestion.
Supout review has been conducted, no hardware/software issues are visible: no link errors, no dropped packets, and the CPU was idle during the measurements.
Troubleshoot the configuration/layout locally.
Szóval boldogulj magadnak kb.
Délután még kipróbáltam, hogy 0-ról építettem fel újra az 5009-et, és ezúttal a VLAN az SFP+ -ra került nem a bridgre, de ugyanúgy nem jó. -
"Először azt írtad, hogy fragmentált lesz, ami felesleges terhelés, majd azt, hogy eldobálja. IPv6 dobál, IPv4 meg nem (feltétlenül, DF bit alapján)."
Valoban, az eldobas v4 eseten opcionalis. Vannak tuzfalak amik eldobjak mindenkeppen, vannak amik nem - beallitas kerdese. Normal esetben egy fragmentalt csomag nem lenne problema, siman ossze lehet rakni. A problema az, hogy mivel a kommunikalo felek mindent megtesznek a fragmentalas elkeruleseert, altalaban DF bitet is beallitjak (implementacio fuggo).Namost ha egy DF bites csomag eldobasra kerult, arrol menne egy ICMP uzenet a feladonak. Azonban a sok "okos" vegfelhasznalo, illetve az eszkozuk ezt nem engedi at, igy aztan a kommunikacio szimplex lesz, majd timeout-ol.
Lenyeg a lenyeg: a mikrotik support-tol kapott valasz szerintem nem valid.
-
blt-blog
tag
Először azt írtad, hogy fragmentált lesz, ami felesleges terhelés, majd azt, hogy eldobálja. IPv6 dobál, IPv4 meg nem (feltétlenül, DF bit alapján).
TCP oldalról teljesen valid leírás.
-
lionhearted
őstag
Nekem ez az MTU valasz egy kicsit bullshitnek tunik, szerintem nem lehet ez az oka. Egy pillanatra tegyuk felre a vlanokat, a pppoe-t, meg mindent ami vagy csokkenti vagy nem csokkenti az MTU-t. Mert ez mind lenyegtelen.
A meres egy weboldalon at tortenik, http(s) -en at. Ami azt jelenti, hogy TCP-t hasznal. Ami ugy mukodik, hogy kezdodik egy TCP handshake-kel, amiben a kezdemenyezo fel mindenfele parametert megoszt a masik fellel, hogy ezeket tamogatja. Ezek kozott van az MSS is, ami az MTU unokatestvere: MSS = MTU - 40 byte.
Egy atlagos vegpont tehat ugy fog 1500 byte-tal kommunikalni, hogy abbol 1460 a hasznos tartalom es 20 + 20 a ket fejlec, igy jon ki az 1500 MTU. Ezt az MSS erteket pedig le is kommunikalja a TCP fejlecben a handshake soran. Eloszor a kapcsolat kezdemenyezo elkuldi, hogy mekkora az a legnagyobb szegmens, amit egyszerre fogadni tud. Etherneten log a laptopom, tehat az MTU 1500, tehat az ertek 1460 lesz. Lathato, hogy egy SYN flag-es csomagban ez benne is van.
A valasz a handshake soran egy SYN+ACK, es a tuloldal is elkuldi, hogy mennyi az MSS ertek maximuma amit o tud tamogatni. Lathato, hogy ez csak 1250 byte. Miert van ez? Azert, mert valahol utkozben a forras es a cel kozott van egy halozat aminek ez a maximuma. Ez a halozat barhol lehet, a sajatodon kivul is, nincs rahatasod. Viszont a TCP a ket ertek kozul a kisebbet fogja hasznalni azert, hogy elkerulje az ip fragmentalast. A tordelt csomagokat eroforras nyilvantartani es osszerakni a vegen, tovabba lelassitjak a kommunikaciot tehat mindenki igyeszik elkerulni, ezert allapodnak meg a kapcsolat elejen a felek abban, hogy mekkora az a legnagyobb payload meret amit el lehet kuldeni anelkul, hogy valakinek utkozben tordelnie kellene.
Honnan tudod, hogy ez tenyleg igy van? Onnan, hogy megnezed, hogy a teljes parbeszed soran mekkora a TCP segment size ertek minden egyes szegmensben. Wiresharkban ki is rakhatod onallo oszlopba es rendezhetsz sorba, hogy lasd a legnagyobbat. Mint a lenti kepen lathato, a legnagyobb szegmens 1250 byte, eppen annyi, mint amit a szerver a kapcsolat legelejen megadott, mint maximalis kezelheto meretet. A teljes tovabbi TCP session soran nincs olyan csomag, aminek a L4 payloadja ennel nagyobb lenne.
Miert erdekes ez? Azert, mert a sebessegmeres is egy TCP kapcsolaton keresztul tortenik, hiszen egy weboldalon mert. Tehat az is egy handshake-kel kezdodik, tehat abban is lesz MSS ertek, ahol mindket fel elmondja a masiknak, hogy mekkora a max amit o tamogat.Ha tehat a PC 1500-at tamogat (miert tamogatna mast), de a mikrotikon ott van az MSS clamping szabaly, amit valaki mar korabban javasolt, hogy irja be (es allitolag nem segitett) akkor az MSS erteket at fogja irni, a tuloldal (a meroszerver) ezt a csokkentett erteket fogja latni, tehat mindig kisebb csomagokat fog kuldeni, mint amennyit a PC magatol reportolt. Tehat sosem lesz MTU problema, mert az MSS ertek mindig a csokkentett lesz, tehat nem lesz eldobott csomag sem, mert nem lesz mit eldobni.
En tehat ugy gondolom, hogy amennyiben a mar korabban javasolt MSS clamping tuzfal szabaly helyesen volt beallitva, akkor a mikrotik support valasza bullshit.
Ha nem volt helyesen beallitva, akkor pedig wireshark megmutatja, hogy vannak-e fragmentalt csomagok, illetve azt is, hogy mi tortenik ezekkel a csomagokkal.
A mikrotik support valasz viszont akkor is BS-nek tunik hanem volt jol beallitva, mivel az MTU erteke nem fog ugralni. A szerver a sebessegmeres soran a mindenkor maximalis MSS ertekkel fogja kuldeni a payloadot, hiszen maximalis sebessegre torekszik. Azaz ha MTU problema van, akkor minden csomag eldobasra kerulne valahol, nem tudnal 80-90 megabitet merni sem. Nincs olyan session, hogy tolom a csovon a max adatot amit csak birok es nehanyat eldobok MTU problema miatt, nehanyat meg nem.
Először azt írtad, hogy fragmentált lesz, ami felesleges terhelés, majd azt, hogy eldobálja. IPv6 dobál, IPv4 meg nem (feltétlenül, DF bit alapján).
TCP oldalról teljesen valid leírás. -
blt-blog
tag
Azt írta a support, hogy a PPPoE overhead az L2MTU... lehetne akár, ha 1500-as PPPoE lenne idehaza, de 1492 az MTU rajta, szóval pontosan ugyanannyit eszik az interfészen, 1500at, nincs "overhead". A VLAN tag valóban 4 bájt, látható a képen ahogy csökkenti a bridget.
Plusz nincs droppolt csomag.Na, majd a következő körre kitalálják mi a gond.
Nekem ez az MTU valasz egy kicsit bullshitnek tunik, szerintem nem lehet ez az oka. Egy pillanatra tegyuk felre a vlanokat, a pppoe-t, meg mindent ami vagy csokkenti vagy nem csokkenti az MTU-t. Mert ez mind lenyegtelen.
A meres egy weboldalon at tortenik, http(s) -en at. Ami azt jelenti, hogy TCP-t hasznal. Ami ugy mukodik, hogy kezdodik egy TCP handshake-kel, amiben a kezdemenyezo fel mindenfele parametert megoszt a masik fellel, hogy ezeket tamogatja. Ezek kozott van az MSS is, ami az MTU unokatestvere: MSS = MTU - 40 byte.
Egy atlagos vegpont tehat ugy fog 1500 byte-tal kommunikalni, hogy abbol 1460 a hasznos tartalom es 20 + 20 a ket fejlec, igy jon ki az 1500 MTU. Ezt az MSS erteket pedig le is kommunikalja a TCP fejlecben a handshake soran. Eloszor a kapcsolat kezdemenyezo elkuldi, hogy mekkora az a legnagyobb szegmens, amit egyszerre fogadni tud. Etherneten log a laptopom, tehat az MTU 1500, tehat az ertek 1460 lesz. Lathato, hogy egy SYN flag-es csomagban ez benne is van.
A valasz a handshake soran egy SYN+ACK, es a tuloldal is elkuldi, hogy mennyi az MSS ertek maximuma amit o tud tamogatni. Lathato, hogy ez csak 1250 byte. Miert van ez? Azert, mert valahol utkozben a forras es a cel kozott van egy halozat aminek ez a maximuma. Ez a halozat barhol lehet, a sajatodon kivul is, nincs rahatasod. Viszont a TCP a ket ertek kozul a kisebbet fogja hasznalni azert, hogy elkerulje az ip fragmentalast. A tordelt csomagokat eroforras nyilvantartani es osszerakni a vegen, tovabba lelassitjak a kommunikaciot tehat mindenki igyeszik elkerulni, ezert allapodnak meg a kapcsolat elejen a felek abban, hogy mekkora az a legnagyobb payload meret amit el lehet kuldeni anelkul, hogy valakinek utkozben tordelnie kellene.
Honnan tudod, hogy ez tenyleg igy van? Onnan, hogy megnezed, hogy a teljes parbeszed soran mekkora a TCP segment size ertek minden egyes szegmensben. Wiresharkban ki is rakhatod onallo oszlopba es rendezhetsz sorba, hogy lasd a legnagyobbat. Mint a lenti kepen lathato, a legnagyobb szegmens 1250 byte, eppen annyi, mint amit a szerver a kapcsolat legelejen megadott, mint maximalis kezelheto meretet. A teljes tovabbi TCP session soran nincs olyan csomag, aminek a L4 payloadja ennel nagyobb lenne.
Miert erdekes ez? Azert, mert a sebessegmeres is egy TCP kapcsolaton keresztul tortenik, hiszen egy weboldalon mert. Tehat az is egy handshake-kel kezdodik, tehat abban is lesz MSS ertek, ahol mindket fel elmondja a masiknak, hogy mekkora a max amit o tamogat.Ha tehat a PC 1500-at tamogat (miert tamogatna mast), de a mikrotikon ott van az MSS clamping szabaly, amit valaki mar korabban javasolt, hogy irja be (es allitolag nem segitett) akkor az MSS erteket at fogja irni, a tuloldal (a meroszerver) ezt a csokkentett erteket fogja latni, tehat mindig kisebb csomagokat fog kuldeni, mint amennyit a PC magatol reportolt. Tehat sosem lesz MTU problema, mert az MSS ertek mindig a csokkentett lesz, tehat nem lesz eldobott csomag sem, mert nem lesz mit eldobni.
En tehat ugy gondolom, hogy amennyiben a mar korabban javasolt MSS clamping tuzfal szabaly helyesen volt beallitva, akkor a mikrotik support valasza bullshit.
Ha nem volt helyesen beallitva, akkor pedig wireshark megmutatja, hogy vannak-e fragmentalt csomagok, illetve azt is, hogy mi tortenik ezekkel a csomagokkal.
A mikrotik support valasz viszont akkor is BS-nek tunik hanem volt jol beallitva, mivel az MTU erteke nem fog ugralni. A szerver a sebessegmeres soran a mindenkor maximalis MSS ertekkel fogja kuldeni a payloadot, hiszen maximalis sebessegre torekszik. Azaz ha MTU problema van, akkor minden csomag eldobasra kerulne valahol, nem tudnal 80-90 megabitet merni sem. Nincs olyan session, hogy tolom a csovon a max adatot amit csak birok es nehanyat eldobok MTU problema miatt, nehanyat meg nem.
-
lionhearted
őstag
Az SFP interface-n a képen latható 1596 értékkel próbáltad?
Nekem azt írja, hogy Max L2 MTU 9796, írj be neki 2000-et, abba biztos belefér, persze a másik eszközön is.Azt írta a support, hogy a PPPoE overhead az L2MTU... lehetne akár, ha 1500-as PPPoE lenne idehaza, de 1492 az MTU rajta, szóval pontosan ugyanannyit eszik az interfészen, 1500at, nincs "overhead". A VLAN tag valóban 4 bájt, látható a képen ahogy csökkenti a bridget.
Plusz nincs droppolt csomag.Na, majd a következő körre kitalálják mi a gond.
-
Ennyit írt a support.
We reviewed the configurations and supout files. The Router-on-a-Stick design is correct, and your tests already rule out the WAN, ONT, links and end devices.
The likely cause is configuration: on the RB5009 every port — including the 10 Gbps trunk to the CRS317 — has L2MTU manually fixed at 1514, while the switch keeps its larger default. Tagged-VLAN + PPPoE traffic needs a little extra for the tag and PPPoE overhead, so frames slightly over 1514 bytes are dropped. This produces exactly your symptom: a ~90 Mbps download ceiling with no link errors, while upload (smaller packets) stays at full speed. CPU/FastTrack are not the bottleneck.
Otherwise proceed with local testing.
Sajnos ez sem oldotta meg, úgy hogy várom a visszajelzésüket.
-
Shkiz0
nagyúr
Miért lenne kisebb a VLAN max csomagméret? Nem a PPPoE fejléc/payload része, ethernet fejlécet meg azonfelül kezeli a Mikrotik (L2 MTU), amiben általában elfér a tag az 1500 default payload felett. Azért mondom, hogy általában, mert több eszközömön más a default L2 MTU, de VLANozással nem volt ilyen gondom.
Van nekem is egy ilyen VLANozott PPPoE WAN megoldás (hex S és ax2), gigabit teljesen stabilan jön, önmagában ez nem tűnik problémának. Persze teljesen más liga a két eszközpár, de ez csak növeli az esélyét, hogy a kollégának menjen.
Korábban DHCP netet is megoldottam így, gigabites net volt az is lefelé, de az még gyengébb eszköz volt.Szóval az alap elgondolás jó, csak légy van a palacsintában.
Ennyit írt a support.
We reviewed the configurations and supout files. The Router-on-a-Stick design is correct, and your tests already rule out the WAN, ONT, links and end devices.
The likely cause is configuration: on the RB5009 every port — including the 10 Gbps trunk to the CRS317 — has L2MTU manually fixed at 1514, while the switch keeps its larger default. Tagged-VLAN + PPPoE traffic needs a little extra for the tag and PPPoE overhead, so frames slightly over 1514 bytes are dropped. This produces exactly your symptom: a ~90 Mbps download ceiling with no link errors, while upload (smaller packets) stays at full speed. CPU/FastTrack are not the bottleneck.
Otherwise proceed with local testing.
Sajnos ez sem oldotta meg, úgy hogy várom a visszajelzésüket.
-
Reggie0
titán
Miért lenne kisebb a VLAN max csomagméret? Nem a PPPoE fejléc/payload része, ethernet fejlécet meg azonfelül kezeli a Mikrotik (L2 MTU), amiben általában elfér a tag az 1500 default payload felett. Azért mondom, hogy általában, mert több eszközömön más a default L2 MTU, de VLANozással nem volt ilyen gondom.
Van nekem is egy ilyen VLANozott PPPoE WAN megoldás (hex S és ax2), gigabit teljesen stabilan jön, önmagában ez nem tűnik problémának. Persze teljesen más liga a két eszközpár, de ez csak növeli az esélyét, hogy a kollégának menjen.
Korábban DHCP netet is megoldottam így, gigabites net volt az is lefelé, de az még gyengébb eszköz volt.Szóval az alap elgondolás jó, csak légy van a palacsintában.
-
lionhearted
őstag
user12 és Shkiz0:
Első körben én is MTU-ra gondoltam volna, a VLAN miatt kisebb lehet a max csomagméret. A másik ok maga a PPPOE lehet, mert az nehezen párhuzamosítható, többnyire csak egy magot terhel - azaz a processzor egy magos teljesítménye lesz mérvadó. Kérdés, hogy az alacsony terhelés vajon magonként nézve is alacsony volt, vagy csak átlagosan?
x86 esetén is érdemes lehet olyan procit választani aminek az egy magra eső teljesítménye is jó, és persze kellően alacsony a TDP-je.Miért lenne kisebb a VLAN max csomagméret? Nem a PPPoE fejléc/payload része, ethernet fejlécet meg azonfelül kezeli a Mikrotik (L2 MTU), amiben általában elfér a tag az 1500 default payload felett. Azért mondom, hogy általában, mert több eszközömön más a default L2 MTU, de VLANozással nem volt ilyen gondom.
Van nekem is egy ilyen VLANozott PPPoE WAN megoldás (hex S és ax2), gigabit teljesen stabilan jön, önmagában ez nem tűnik problémának. Persze teljesen más liga a két eszközpár, de ez csak növeli az esélyét, hogy a kollégának menjen.
Korábban DHCP netet is megoldottam így, gigabites net volt az is lefelé, de az még gyengébb eszköz volt.Szóval az alap elgondolás jó, csak légy van a palacsintában.
-
Ha nincs vlan és az 5009 építi a pppoe-t akkor rendben van. (ilyenkor ugye a 2.5G RJ45 miatt 2.3/2G-t tudok max mérni)
Nem ezen részével lesz gond, és írtam is hogy a ha csak átengedem az egész rendszeren a netet és a Kaon ad IP-t akkor ugyanezen cuccokon gyönyörűen átmegy a 4/2G.
De az egész teszt lényege pont az lenne, hogy mennyit tud maga az 5009.
Csak ugye mivel 1db SFP+ van rajta és nincs még egy SFP+ vagy 10G port csak router on stick-be lehet ezt megoldani. Igazából a terv épített pc volt, csak úgy voltam vele, hogy megnézem azért mit tud az 5009 és ha amúgy tudná a 4G-t (kétlem) akkor lehet maradt volna így egy darabig, mert amúgy a hex pro csikarná a fantáziám, de annak meg se híre se hamva, és ebből ítélve hogy nincs semmi újabb infó róla az MWC óta nem valószínű, hogy idén kijön. -
Ha nincs vlan és az 5009 építi a pppoe-t akkor rendben van. (ilyenkor ugye a 2.5G RJ45 miatt 2.3/2G-t tudok max mérni)
Nem ezen részével lesz gond, és írtam is hogy a ha csak átengedem az egész rendszeren a netet és a Kaon ad IP-t akkor ugyanezen cuccokon gyönyörűen átmegy a 4/2G.
De az egész teszt lényege pont az lenne, hogy mennyit tud maga az 5009.
Csak ugye mivel 1db SFP+ van rajta és nincs még egy SFP+ vagy 10G port csak router on stick-be lehet ezt megoldani. Igazából a terv épített pc volt, csak úgy voltam vele, hogy megnézem azért mit tud az 5009 és ha amúgy tudná a 4G-t (kétlem) akkor lehet maradt volna így egy darabig, mert amúgy a hex pro csikarná a fantáziám, de annak meg se híre se hamva, és ebből ítélve hogy nincs semmi újabb infó róla az MWC óta nem valószínű, hogy idén kijön. -
-
Az rendben, de nyilván egy asztalin jóval több minden is futhat.
Konkrétan nekem költözne rá a webserver, nas, router funkció, stb.
Egy 2116 is már horror áron megy, és konkrétan 8/8-at már nem hajt ki, volt itt a topicba is róla teszt, meg szó.
Nekem nagyker áron kb annyiba jönne ki a hw a géphez, mint amennyibe a CCR kerül.
Hex pro-ra mondanám azt, hogy ha lenne akkor bepróbálnám ha 100k alatt maradna az ára, de az is valószínüleg a 8/8-ra pl ugyanúgy kevés lenne. Nem arról van szó, hogy most lenne 8G, de nyilván ha már veszek / rakok össze valamit akkor már picit a jövőre is gondolnék.
De függetlenül ettől, hogy mit kéne venni vagy mit nem, ennek amit most próbálok kéne működjön rendesen. Nem az a megoldás rá, hogy ez van vegyél mást -
Az rendben, de nyilván egy asztalin jóval több minden is futhat.
Konkrétan nekem költözne rá a webserver, nas, router funkció, stb.
Egy 2116 is már horror áron megy, és konkrétan 8/8-at már nem hajt ki, volt itt a topicba is róla teszt, meg szó.
Nekem nagyker áron kb annyiba jönne ki a hw a géphez, mint amennyibe a CCR kerül.
Hex pro-ra mondanám azt, hogy ha lenne akkor bepróbálnám ha 100k alatt maradna az ára, de az is valószínüleg a 8/8-ra pl ugyanúgy kevés lenne. Nem arról van szó, hogy most lenne 8G, de nyilván ha már veszek / rakok össze valamit akkor már picit a jövőre is gondolnék.
De függetlenül ettől, hogy mit kéne venni vagy mit nem, ennek amit most próbálok kéne működjön rendesen. Nem az a megoldás rá, hogy ez van vegyél mást -
Ha nincs vlan és az 5009 építi a pppoe-t akkor rendben van. (ilyenkor ugye a 2.5G RJ45 miatt 2.3/2G-t tudok max mérni)
Nem ezen részével lesz gond, és írtam is hogy a ha csak átengedem az egész rendszeren a netet és a Kaon ad IP-t akkor ugyanezen cuccokon gyönyörűen átmegy a 4/2G.
De az egész teszt lényege pont az lenne, hogy mennyit tud maga az 5009.
Csak ugye mivel 1db SFP+ van rajta és nincs még egy SFP+ vagy 10G port csak router on stick-be lehet ezt megoldani. Igazából a terv épített pc volt, csak úgy voltam vele, hogy megnézem azért mit tud az 5009 és ha amúgy tudná a 4G-t (kétlem) akkor lehet maradt volna így egy darabig, mert amúgy a hex pro csikarná a fantáziám, de annak meg se híre se hamva, és ebből ítélve hogy nincs semmi újabb infó róla az MWC óta nem valószínű, hogy idén kijön. -
Bedobom ide is hátha valaki tud rá okosat.
A rendszerem:
- Telekom 4 Gbps download / 2 Gbps upload Internet
- Telekom Kaon ONT with a 10 Gbps RJ45 LAN
- MikroTik RB5009UG+S+ router, PPPoE kapcsolattal
- MikroTik CRS317-1G-16S+RM fő switch
- Davuaz unmanaged 10G switch
- Fő PC 5 Gbps Ethernet hálózati kártyával
- HTPC 2,5 Gbps Ethernet hálózati kártyávalÍgy van összekötve:
Kaon → CRS317 SFP16 (10G RJ45 SFP+) → CRS317 SFP1 → DAC → RB5009 SFP+1 CRS317 SFP2 → Davuaz → PC
Router-on-a-Stick konfigurációt használok:
VLAN 10 = WAN
VLAN 20 = LAN
CRS317 SFP1 ↔ RB5009 SFP+1 = tagged trunk
PPPoE VLAN 10-en fut
DHCP/LAN IP VLAN 20-on futA probléma az, hogy amikor az RB5009 ebben a VLAN-os konfigurációban a hálózatban van, a letöltési sebesség körülbelül 80–90 Mbps-ra korlátozódik, miközben a feltöltés körülbelül 2 Gbps.
A hiba felderítése során több különböző konfigurációt is kipróbáltunk. A PPPoE klienst áthelyeztük a fizikai SFP+ interfészre, illetve VLAN interfészre is, valamint teszteltük a Router-on-a-Stick konfigurációt VLAN 10 WAN és VLAN 20 LAN használatával. A körülbelül 80–90 Mbps-os letöltési korlátozás a VLAN/Router-on-a-Stick konfiguráció használatakor továbbra is fennmaradt.
Egy teljesen tiszta, nulláról felépített RB5009 konfigurációt is létrehoztunk, hogy kizárjuk a korábbi konfigurációból eredő problémákat. Amikor a Kaon közvetlenül az RB5009-re volt csatlakoztatva, a kapcsolat körülbelül 2,2-2,3 Gbps letöltési / 2 Gbps feltöltési sebességet ért el. (RJ45 port ugye itt limitál)Amikor az RB5009-et teljesen megkerültük, és a forgalom a CRS317-en és a Davuaz switchen keresztül hardveresen volt kapcsolva, a letöltési sebesség körülbelül 4,17 Gbps, a feltöltés pedig 2 Gbps volt.
További elvégzett tesztek:
PC → HTPC belső iperf3 teszt: körülbelül 2,36 Gbps. A HTPC 2,5 Gbps-os Ethernet interfésszel rendelkezik, ezért ez összhangban van a hálózati kártya sebességkorlátjával. Az összes releváns 10G kapcsolat 10 Gbps full duplex sebességen működik. Nem tapasztaltunk jelentős RX hibát, FCS hibát, collisiont vagy TX dropot. Az RB5009 CPU-terhelése nagyon alacsony sebességteszt közben. A FastTrack ki- és bekapcsolását is teszteltük, ez nem változtatott az eredményen.
Ez alapján a probléma kifejezetten az RB5009 + VLAN/PPPoE konfigurációhoz vagy a csomagfeldolgozási útvonalhoz kapcsolódónak tűnik, nem pedig az ISP-kapcsolathoz, a fizikai 10G kapcsolatokhoz vagy a végpontokhoz.Valakinek van ötlete mi lehet?
Ma kaptam kölcsönbe tesztre egy RJ45 10G réz modult mert bár nekem van 2db de az egyforma. A kölcsönkapott modullal is megvan a probléma.
Szóval ha valaki találkozott már hasonlóval akkor szívesen várom az ötleteket.
Elküldtem a supout fájlokat a mikrotiknek is, a csatolt export fájlokkal, de egyelőre még nem válaszoltak rá. -
Bedobom ide is hátha valaki tud rá okosat.
A rendszerem:
- Telekom 4 Gbps download / 2 Gbps upload Internet
- Telekom Kaon ONT with a 10 Gbps RJ45 LAN
- MikroTik RB5009UG+S+ router, PPPoE kapcsolattal
- MikroTik CRS317-1G-16S+RM fő switch
- Davuaz unmanaged 10G switch
- Fő PC 5 Gbps Ethernet hálózati kártyával
- HTPC 2,5 Gbps Ethernet hálózati kártyávalÍgy van összekötve:
Kaon → CRS317 SFP16 (10G RJ45 SFP+) → CRS317 SFP1 → DAC → RB5009 SFP+1 CRS317 SFP2 → Davuaz → PC
Router-on-a-Stick konfigurációt használok:
VLAN 10 = WAN
VLAN 20 = LAN
CRS317 SFP1 ↔ RB5009 SFP+1 = tagged trunk
PPPoE VLAN 10-en fut
DHCP/LAN IP VLAN 20-on futA probléma az, hogy amikor az RB5009 ebben a VLAN-os konfigurációban a hálózatban van, a letöltési sebesség körülbelül 80–90 Mbps-ra korlátozódik, miközben a feltöltés körülbelül 2 Gbps.
A hiba felderítése során több különböző konfigurációt is kipróbáltunk. A PPPoE klienst áthelyeztük a fizikai SFP+ interfészre, illetve VLAN interfészre is, valamint teszteltük a Router-on-a-Stick konfigurációt VLAN 10 WAN és VLAN 20 LAN használatával. A körülbelül 80–90 Mbps-os letöltési korlátozás a VLAN/Router-on-a-Stick konfiguráció használatakor továbbra is fennmaradt.
Egy teljesen tiszta, nulláról felépített RB5009 konfigurációt is létrehoztunk, hogy kizárjuk a korábbi konfigurációból eredő problémákat. Amikor a Kaon közvetlenül az RB5009-re volt csatlakoztatva, a kapcsolat körülbelül 2,2-2,3 Gbps letöltési / 2 Gbps feltöltési sebességet ért el. (RJ45 port ugye itt limitál)Amikor az RB5009-et teljesen megkerültük, és a forgalom a CRS317-en és a Davuaz switchen keresztül hardveresen volt kapcsolva, a letöltési sebesség körülbelül 4,17 Gbps, a feltöltés pedig 2 Gbps volt.
További elvégzett tesztek:
PC → HTPC belső iperf3 teszt: körülbelül 2,36 Gbps. A HTPC 2,5 Gbps-os Ethernet interfésszel rendelkezik, ezért ez összhangban van a hálózati kártya sebességkorlátjával. Az összes releváns 10G kapcsolat 10 Gbps full duplex sebességen működik. Nem tapasztaltunk jelentős RX hibát, FCS hibát, collisiont vagy TX dropot. Az RB5009 CPU-terhelése nagyon alacsony sebességteszt közben. A FastTrack ki- és bekapcsolását is teszteltük, ez nem változtatott az eredményen.
Ez alapján a probléma kifejezetten az RB5009 + VLAN/PPPoE konfigurációhoz vagy a csomagfeldolgozási útvonalhoz kapcsolódónak tűnik, nem pedig az ISP-kapcsolathoz, a fizikai 10G kapcsolatokhoz vagy a végpontokhoz.Valakinek van ötlete mi lehet?
Ma kaptam kölcsönbe tesztre egy RJ45 10G réz modult mert bár nekem van 2db de az egyforma. A kölcsönkapott modullal is megvan a probléma.
Szóval ha valaki találkozott már hasonlóval akkor szívesen várom az ötleteket.
Elküldtem a supout fájlokat a mikrotiknek is, a csatolt export fájlokkal, de egyelőre még nem válaszoltak rá. -
Shkiz0
nagyúr
!!! Óvatosan a 7.24.2-vel !!! , most downgradelek, mert állandóan szakadozik a wireguard kapcsolat, miközben elvileg a router mögötti gép rendesen kilát és a túloldalon is elvileg rendben van az internet elérés.
Na közben visszajött a Router a 7.24.1-el, majd látjuk, hogy az volt-e a gond, otthoni gépről távoli asztalról a rádiót hallgatva.
PS: egy Getta Dávid szám már stabilan átjött otthonról, eddig jó a régi fw... Kopp-kopp...
-
Amikor a laptop az asztalon/töltőn van, akkor 5 gigas usb adapterrel megy egy dokkolóként használt usb hub-on keresztül.
Ha 3 sávos mlo-t állítottam be, akkor az egy 6-os eszköznek csak a ft elvesztését jelentette. A már említett mozgás közbeni 5 Ghz sáv-vesztés a wifi 7-es telefont ugyanúgy sújtotta ilyenkor is. Mivel a telefon oldalán nincs valódi mlo, így a részleteit nem teszteltem ki.
Ha minden wifi 7 és van valódi mlo, akkor ugye mindegy, hogy kiesik 1-2 sáv, az átviteli sebesség csökkenése lenne az egyetlen érzékelhető következmény. Leghamarabb akkor hoznék létre mlo interfészt, amikor minden kliens 7-es, de annál még a wifi 8-as router is előbb érkezik…
-
jerry311
nagyúr
Értem, de azt állítod, hogy senkinek se mehet. Pedig működik simán.
-
lionhearted
őstag
Mindegy hova kapcsolom a gyári CA-kat, ez nem működik. HTTPS update letöltés megy, ha nincs CRL ellenőrzés.
Meanwhile...
Ezt hogy sikerült összehozni??????
What's new in 7.23.7 (2026-09-16):
*) lte - prevent the modem firmware from being deleted for RBSXTLTE3-7, EC25-EU&KNe, EG25-G&KNe, EC25-EU&SXTsq, EG25-G&SXTsq (introduced in 7.23.6);
If you have already upgraded to 7.23.6 or 7.24.3, follow these steps to restore LTE functionality on affected devices:
1. Upgrade RouterOS to version 7.23.7 or 7.24.4
2. Update the modem firmware:
/interface/lte/firmware-upgrade [find] upgrade=yes3. Reboot the router.
For more details, see:
https://forum.mikrotik.com/t/warning-lte-interface-stops-working-after-upgrade-to-7-23-6-7-24-3Értem, de azt állítod, hogy senkinek se mehet. Pedig működik simán.
-
Mindegy hova kapcsolom a gyári CA-kat, ez nem működik. HTTPS update letöltés megy, ha nincs CRL ellenőrzés.
Meanwhile...
Ezt hogy sikerült összehozni??????
What's new in 7.23.7 (2026-09-16):
*) lte - prevent the modem firmware from being deleted for RBSXTLTE3-7, EC25-EU&KNe, EG25-G&KNe, EC25-EU&SXTsq, EG25-G&SXTsq (introduced in 7.23.6);
If you have already upgraded to 7.23.6 or 7.24.3, follow these steps to restore LTE functionality on affected devices:
1. Upgrade RouterOS to version 7.23.7 or 7.24.4
2. Update the modem firmware:
/interface/lte/firmware-upgrade [find] upgrade=yes3. Reboot the router.
For more details, see:
https://forum.mikrotik.com/t/warning-lte-interface-stops-working-after-upgrade-to-7-23-6-7-24-3 -
jerry311
nagyúr
Bekapcsoltad a gyári beépített CAkat? Vagy anno kézzel adtál hozzá.
Mindegy hova kapcsolom a gyári CA-kat, ez nem működik. HTTPS update letöltés megy, ha nincs CRL ellenőrzés.
Meanwhile...
Ezt hogy sikerült összehozni??????
What's new in 7.23.7 (2026-09-16):
*) lte - prevent the modem firmware from being deleted for RBSXTLTE3-7, EC25-EU&KNe, EG25-G&KNe, EC25-EU&SXTsq, EG25-G&SXTsq (introduced in 7.23.6);
If you have already upgraded to 7.23.6 or 7.24.3, follow these steps to restore LTE functionality on affected devices:
1. Upgrade RouterOS to version 7.23.7 or 7.24.4
2. Update the modem firmware:
/interface/lte/firmware-upgrade [find] upgrade=yes3. Reboot the router.
For more details, see:
https://forum.mikrotik.com/t/warning-lte-interface-stops-working-after-upgrade-to-7-23-6-7-24-3 -
lionhearted
őstag
Valami valtozott valahol, mert eddig is be volt kapcsolva a CRL es mukodott minden.
Aztan ugye mostanaban jott, hogy "updatelj mert meghalsz azonnal!!!". Akkor felment az uj firmware es azzal egyutt jott a CRL hiba is ujabb update keresesnel vagy letoltesnel.
Kikapcsoltam a CRL ellenorzest, igy megy, de...
Új hozzászólás Aktív témák
- Apple iPhone 16 Pro 128GB Natural Titanium Akku: 90% - Makulátlan hibátlan állapot!
- Gamer PC eladó! Asus ROG B450, Ryzen 5 3600X, 16GB DDR4, RX 6600 XT
- NVIDIA QUADRO RTX 4000 8Gb GDDR6
- Lenovo IdeaPad Slim 3 - 15.6" FullHD - Ryzen 3 7320U - 8GB DDR5 - 512GB SSD - Win11 - MAGYAR - Gari
- LG G4 OLED 55'4k 140HZ TV ELADÓ
- Keresek Xbox Series S / Series X / Playstation 5 konzolokat
- BESZÁMÍTÁS! Intel Corei i9 13900K 24 mag 32 szál processzor garanciával hibátlan működéssel
- 27% - Seasonic Prime PX-1600W 80 PLUS Platinum (PRIME-PX-1600)
- Új Dobozos DELL 16 Multimédiás Laptop 16" -40% Intel Core 5 120U 16GB RAM/1TB SSD FHD+
- Apple MacBook Air 15 M3 , 16GB Memória , 256GB SSD, Újszerű 12 Hónap Garanciával