[XeStAiSy]

[bladerunner]

Mikrotik ja tavakasutaja ei käi nagunii ühes lauses koos

[jaakjaak22]

[kaabakas]

Ma olen ka seda meelt, et kui mina aru ei saa, siis pole kellelgi teisel ka vaja...

[XeStAiSy]

[Etz]

[RassK]

Mis keyword'e Mikrotikil teadma peab, et seadistada 2 porti üheks nii, et throughput liitub? ... kasvõi vähemalt, et SMB3 multichannel suudaks maksimeerida ühenduse.

[hunger]

[RassK]

Vabandused, väike ebatäpsustus jäi sisse. "et throughput liitub per klient". LAG / LACP puhul ma saan aru, et 2x1G annab ikka 1G per klient (kuigi smb3 multichannel vist saab ikka 2G?).

ChatGPT'd piinates ma saan aru, et parima tulemuse saaks siiski LACP load balancing hashing määrates L2 asemel L3 & L4 peale? Kuivõrd seda usaldada saab?

[Etz]

LACP ja SMB3 multichannel koos väga ei tomi, või noh tomib, kui sul on mitu LACP’i.
Kui sa tahad SMB3 multi-channelit kasutada, peab sul olema kaks võrguliidest, serveri pool otsas ja erinevate IP’dega.
Seda ei konfita võrguseadme poolel ja seega on see siin teemas ka OT.

Olen mõlemat testinud ja koduses võrgus on efekt suht olematu.
Selleks, et SMB3 multi-channel toimiks on laias laastus sama eeldus, mis LACP’i puhul.
Et sul on mõlemas otsas, 2 võrguliidest, mida sa omavahel kombineerid.
Sedasi toimetas küll, ehkki nii hästi see ei skaleeru, et sa päris 2x saaks, pigem 1.5-1.7x.

LACP’ist on reaalne kasu siis, kui sul on palju kliente, mis seda serverit haamerdavad.
Aga isegi siis ei anna see sulle 2x throughputti per klient, et sul on ühes otsas kliendil näiteks 10G liides ja teises serveri otsas 2x5G liides, LACP’iga 10G liideseks liidetud. Ühe kliendi läbilase on ikkagi endiselt 5G max. efekt saabub, kui sul on mitu klienti ja ka siis ainult serveri pool otsas, et mõlemad selle 5G sirgu saaks tõmmata.

[RassK]

OK, see tuletab meelde, miks synos ma 4x1G bondingu ära likvideerisin.
Kodustes tingimustes oleks jah huvi rohkem per klient toru oleks suurem kuna massiliselt kliente nagunii pole. Ühesõnaga ma saan aru, et bondingu puhul hetkel ei olegi viisi, mis round robin viisil pakette jagaks, pigem jagatakse siis torusid per connection

[Etz]

RassK, sõltub protokollist ja rakendusest, SMB puhul kahjuks mitte.

[RassK]

Selge, rakenduse tase hetkel väga ei paku huvi, kuna siis jääb kõik liiga spetsiifiliseks nagu see SMB3 multichannel siiski tagantjärgi uuesti aru saades.

Aga vähemalt switch to switch (mõlemad L3 switchid) LACP ilmselt siis tasub teha koos chatgpt poolt mainitud L3 + L4 hashinguga? Siis vähemalt erinevad teenused saavad kokku suurema toru ja single stream SMB3'le jääks ikka rohkem resu.
Praktiline kasu saab ilmselt väike olema. Aga miks üldse plaanis, siis kontoris jäi auke väheseks seinas ja pidi eraldi 8p switchi panema. Teoreetiliselt saaks 2x10G lingi kontori ja racki vahel, mis praktikas oleks 2x5-7G.

[kaabakas]

Põhjusmõtteliselt ühte paketistriimi üle kahe toru ajada ei ole hea mõte, sest pakettide saabumise järjekorda pole võimalik üle kahe toru sünkroonis hoida, ja see tekitab lisatööd. Tcp puhul tuleb kõik pärast sassi läinud paketti saadetud paketid uuesti saata. See võtab hoo maha. Udp puhul sõltub vastu võtvast tarkvarast kuidas ta lahendab, aga etem on eeldada et ega ta arukas ei ole. Lisaks, võttes arvesse udp kasutamise põhjusi, siis kõik, mis sassi läks, ilmselt haihtus õhku ja keegu huvi enam ei tunne.

Seetõttu ühe striimi üle kahe toru ajamine pole minu teada kuskil toetatud.

Seega kui sa tahad kliendi läbilaset tõsta, pead kasutama softi, mis oskab andmeid mitmes striimis välja saata ja vastu võtta. Nagu smb multichannel. Ja siis tuleb ühendus kliendi ja serveri vahel ära korraldada. On switchid L2 või L3, pole oluline. Sama L2 peal võib vabalt mitu erinevat ip vahemikku joosta. Või kui bondida, siis L4 hashimine (mac, ip, port) kindlasti, L3 hash (mac ja ip) ei suuda samast masinat pärinevat kahte erinevat tcp striimi eristada.

Üldiselt, kuna läbilase kliendi pool tõepoolest kahekordseks ei kasva, siis on kaheldav, kas villad seal kisa väärt on. Rääkimata sellest, et isegi kahekordne kiiruse kasv tegelt kuigi palju ei aitaks. Pigem kui vaja on, siis 10G jne kiirem võrk korraldada.
Asutuse tasemel tõesti, kui serveri port umbes on, siis tuld. Kuigi ka seal ma mõtleks kõigepealt kiirema võrgu peale.

[RassK]

Kui teooriat jätkata, siis ma olekski pigem oodanud, et pigem proprietary feature. Nagu mainitud võivad paketid sassi minna aga kahe sama tootja seadme vahel võib alati paketti edasi wrappida / unwrappida ja lisada kasvõi cache jaoks metadata, et millal pakett cachest edasi läheks, tagamaks järjekorra.

[kaabakas]

Ainuke koht, kus selline proprietary featuur eksisteerida saab, on lõppseade. Ja vägagi tõenäoliselt, tarkvaras. Mis on täpselt see asi, mis smb multichannel ongi.

Sest et teoreetiliselt sa võiks ju tee peal switchis või ruuteris pakette puhverdada ja ümber laduda, aga viimases sammus lõppseadmesse lähevad nad ikka segamini. Nii et lõppseade peab ka oskama. Ja kui juba lõppseade peab sellega hakkama saama, pole tarvis, et tee peal olevad seadmed asja vastu huvi tunneks.
Ma pole ka üldse kindel, et see ülesanne oleks piisavalt kitsalt määratletud, et seda saaks switchikiibi või võrgukaardi peal lahendada. Switchikiibid on kõrgelt spetsialiseeritud väga konkreetsete ülesannete jaoks. Pakett tuleb sisse, kukub seitsmest sõelast läbi, ja läheb torust välja. Neti aluspõhimõte on hoida infra võimalikult rumal, sest sa ei saa terve maailma tarkuse vajadusi ennustada ja rauaks teha. Tarkus kuulub lõppseadme tarkvarasse, kes ise teab ja korraldab, mida tahab.

Juhtmed seina sees... Segane veits oli, aga arvasin, et umbes nii ta on. Et 10G üle vase? Kui tõesti midagi muud üle ei jää, siis selline ta suht ongi, jah. Kui ta sul sfp pulkadega on, siis neil on ka erinevad võimsused, üks võib parema tulemuse anda kui teine. Eks see kehtib tegelikult kõigi seadmete kohta.
Aga mida ma kiirema võrgu all silmas pidasin, oli see, et ehitada uus ja ehitada nii, et töötab praegu ja tulevikus ka. Kui tööandjal on vaja, maksab kinni. Istuda määramatu aja poolpiduse lahenduse otsas, mis on juba praegu ebapiisav, see on kõige kehvem võimalik variant.

[SKG]

Hei, kuidas ma sinna reale veel ühe IP aadressi saaks? Komaga eraldamine nagu ei toimiks?
Sooviks, et seal oleks 192.168.88.9-192.168.88.10 ja ka 192.168.88.24

Spoiler

Või saab seal määrata ainult vahemikku ja mitte järjest aadresse ei saa defineerida. Tuleb teha eraldi reegel?

[Etz]

Ei saagi, dst-nat käib ikka konkreetse aadressi pihta.
Ime et sul üldse vahemikku lubatakse sinna sisestada.

Mida sa seal hetkel saavutada üritad on natuke ebaselge.
Kui load-balancingu üritad teha, siis ka selleks tehakse mitu ruuli.

[SKG]

Jah, hetkel 9 ja 10 mõlemad toimivad, seal ju on konkreetselt kirjas ka mitmuses "To Addresses", mitte "To Address". Miks ei peaks vahemik toimima?

Soovin avada sama pordi eri seadmetele, mida samaaegselt ei kasutata.

[Etz]

[SKG]

[kaabakas]

Mapid vahemiku vahemikuks, toimib nagu nalja. Tänapäeval kus ka avalikud serverid sisevõrgu vahemikes istuvad, muudmoodi kuigi kaugele ei jõuaks.
Hetkel ei õnnestu otsest viidet leida, mida see väli sööma peaks peale - ja /
Proovi 9,10,24 ja 9-10,24. Kui nendest tolku pole pead mitu reeglit tegema.

[pppd]

[SKG]

[avrn]

Tervist.
On ilmnenud üks isevärki probleem ruuteriga RB5009UPr+S+.
Selline:
https://mikrotik.com/product/rb5009upr_s_in
Sai see võetud põhiliselt seetõttu, et tollel POE-pordid, mille kaudu hea toita ja hallata WiFi-AP-sid. ( https://mikrotik.com/product/cap_xl_ac )
Probleem seisneb selles, et aegajal mõni port nagu hangub. AP-le toidet antakse, aegajalt mõni bitt ka nagu liiguks ruuteri ja AP vahel, aga Wifist netti ei saa, AP pingile ei vasta, veebist ligi ei pääse, hallata ei saa. Aga tulukesed näitavad, et ühendus on. Tõstan selle AP teise porti, hakkab kohe tööle.
Ja nii need pordid tõrguvad, kord üks, kord teine. Nagu port põleks maha. Aga ei põle. Järgmine päev katsetades toimib jälle, samas paari tunni pärast proovides ei toimi. Ka lihtsalt ethernet pordina ei toimeta.
Mõnes pordis POE on välja lülitatud, need pole kunagi tõrget andnud. Ruuter on toimetanud umbes pool aastat.
Oskate sellest asjast midagi arvata?
Kas võib olla tegu trafode magnetiseerumise või küllastumisega?

[newarvuti]

[RassK]

avrn, üle ei kuumene midagi? Ma üksaeg avastasin, et CRS328-24P-4S+ SFP+ moodul kuumeneb üle, siis lülitab ka pordi välja niikauaks kuni maha jahtub piisavalt. Mingi aeg tegin tolle lahti ja asendasin vente, siis vaatasin, et SFP+ kanalid kõik ilma korraliku passivjahutuseta.

[avrn]

Restart ei muuda midagi, ka terve ruuteri restart. POE toite välja-sisselülimine ja lahtiühendamine mõeks ajaks samuti mitte.
Logis ei ole minu silmale midagi ebanormaalset.
Ruuteri tarkvara on 7.18.1, AP-d 6.49.17
POE portide koormuseks 5-10W per port. Lubatud on kogu seadmele 130W.
CPU temperatuuriks näitab hetkel 40 kraadi Celsiust. On seda vähe või palju, ei tea. Kuigi hetkel mingit koormust pole.
Käega katsudes on korpus leige.

[Lynx]

Kui toiteallika võib probleemi põhjusena välistada, siis antud kirjelduse järgi pakuks, et viga võib olla ruuteri switch kiibis. Mul oli analoogne probleem cisco switch'iga, mille ühe kiibi taga olevad pordid kõik jamasid.

[hode]

Kodulehel küll reklaamivad uusi 5G LTE seadmeid, aga osta neid küll hetkel ei saa või vähemalt mina ei leidnud.

https://mikrotik.com/products/group/lte-5g-products

[Maldur]

Kõik on ära ostetud, ATL'i oli korraks alla nädalase laoseisuga võtta, aga seegi on täna ettetellimisel.

[avrn]

Mina enda ATL 5G R16 sain kätte juba enne jaanipäeva vahetult, kuigi algne lubadus oli juuli algusesse tarne.
Kahjuks on elu nii kiireks läinud, et katsetamiseni pole veel jõudnud, ehk saab siiski lähitulevikus seda ka teha.
Niipalju on siiski juba selgunud, et see "Mikrotik Connectivity" on esialgu "coming soon" staatuses.
Ühe Poolamaa mehe ülevaade ka seadmest, kui kedagi peaks huvitama:
https://www.youtube.com/watch?v=T9G8YYmJGJE

[Maldur]

See poolamaa lugu ongi seni ainuke kasutajaülevaade. Ja seejuures suht õpetlik, sest ta näitas ära kuhu see toode enam ei sobi, mastide lähiväli.Tekib sisendi ületüürimine ja ühendus muutub päris kehvaks. Üks lugu on veel aga ma pole seni aega saanud seda läbi vaadata, st algus oli vähelubav...

Itaalia poiss MioNonno sai oma ATL'i kätte eelmisel nädalal, aga nüüdseks on tal ka video oma tulemustest väljas. https://www.youtube.com/watch?v=FqEs1sYvp1I Ta on selline katsetaja tüüp, pole vist ühtki moblaruuterit mida ta poleks testinud

[dex]

Minul oleks tarvis hAP AX3 tekitatud 2,4 wifit pikendada õue. Mingit erilist kiirust ja pingi õue vaja pole, aga võiks levida igasse krundi nurka 5000 m3. Mina kedagi ja keegi mind ei sega, sest naabreid lihtsalt pole. Vajadus kerkis üles peamiselt seoses robotmuruniidukiga. Mis oleks selleks kõige kuluefektiivsem moodus?

[kaabakas]

30x30m plats? Aja omale üks wAP räästa alla õiges suunas ja valmis.

[dex]

Pigem 60 m x 80 m ja maja on enam vähem keset platsi. Majal on küljes üks mast (mille tipust saabub 5G, aga see seade ise wifit kahjuks ei jaga).

[kaabakas]

Ahjaa ma jõudsin enne arvutamist juba selle viie sealt ära unustada... Pmst algus on ikkagi sama, piirama jääb alati klientseadme, mitte ap levi. Kui üle platsi välja ei võta, siis pole muud teha kui kaablit matma hakata. Majast läbi ei kosta, tuleb mitmele poole purgid panna.

[dex]

Ühesõnaga, mingi selline odav purk õue katuse kohale masti ei õigusta ennast või hakkab 5 G-d segama: https://arvutitark.ee/en/network-devices/tp-link-wlan-300mbit-access-point-24ghz-eap110-outdoor-1139303

[kaabakas]

Kui keset platsi, siis sellel võib täitsa jumet olla. Räästa taha jääb pime nurk, aga selle katab ehk toast ära. Kui väga vastu korstent läheb, siis jääb selle taha ka kahtlane.
Ära ainult pane sinna mingit tplingi vms jampsi, sul juba korralikud tikud on, lase samas võtmes edasi. 5Gd kindlasti ei sega, sagedused on erinevad.

[dex]

Kust soetasid, kas Telia võrgus toimib ja kas saab N78 peale lukustada?

[avrn]

Ostsin siit:
https://www.getic.ee/product/mikrotik-atl-5g-r16
Super kõnekaardiga toimetas, korra sai katsetatud. Operaatori osas ei tohiks sel asjal mingeid piiranguid olla, kui just opekas ise sikku tegema ei hakka. Telia pole seni teinud. Senine võrgulahendus samuti Mikrotik asjadega tehtud ja toimib Telia võrgus küll.
Kindlale sagedusele lukustamine peaks võimalik olema küll, kuid kas see hea mõte on, peab igaüks ise kaaluma. Kaob siis ju mitme sageduse korraga kasutamine, mis sellise seadme suur eelis.
Teises teemas sai poole suuga mainitud testitulemuste avaldamist, no ehk jõuab nädalalõpuks midagi valmis.
Mastikinnitust vaja veel korraldada ja nipet-näpet ümberkorraldusi teha.
Ehk saab RCC siis ka oma uudishimu rahuldatud.

[avrn]

Nii, tegin siis mõned katsed.
Selguse mõttes viide jutu algusele ka:
https://foorum.hinnavaatlus.ee/viewtopic.php?p=11639631#11639631
Hetkel siis käigus paralleelselt RBM33 Telia F4G ühendusega ja ATL 5GR16 Super kõnekaardiga.
ATL on mastis kahe Iskra vahel, aga see on ajutine. Tahaks tema paar meetrit kõrgemale saada, kui abijupid valmis saan.
Tegin siis LTE sagedustele võrdluse signaali osas, nii nagu Mikrotikud seda näitavad. Spoileris.
5G sagedusi ei hakanud välja kirjutama, need ilmuvad ja kaovad. Signaalide osas minu silm väga drastilisi erinevusi ei näe, küll aga kiirustestis.
Aga vaadake ise:

Spoiler

RBM33+FG621-EA+2xIskra P58

Primary Band: B1@15Mhz, CA Band: B3@20Mhz, RSSI: -72 dBm, RSRP: -94 dBm, SINR: 20 dB, RSRQ: -7.5 dB, Speedtest: 30ms, D: 67Mbps, U: 15Mbps

Band: B1@15Mhz, RSSI: -74 dBm, RSRP: -97dBm, SINR: 17dB, RSRQ: -8,0 dB
Band: B3@20Mhz, RSSI: -83 dBm, RSRP: -109dBm, SINR: 8dB, RSRQ: -16,0 dB
Band: B7@20Mhz, RSSI: -85 dBm, RSRP: -108dBm, SINR: 18dB, RSRQ: -6,0 dB
Band: B20@10Mhz, RSSI: -56 dBm, RSRP: -80dBm, SINR: 10dB, RSRQ: -7,5 dB

ATL 5G R16

Band: B1@15Mhz, RSSI: -66 dBm, RSRP: -100dBm, SINR: 19dB, RSRQ: -8,0 dB
Band: B3@20Mhz, RSSI: -70 dBm, RSRP: -103dBm, SINR: 14dB, RSRQ: -8,0 dB
Band: B7@20Mhz, RSSI: -61 dBm, RSRP: -89dBm, SINR: 13dB, RSRQ: -10,0 dB
Band: B20@10Mhz, RSSI: -62 dBm, RSRP: -91dBm, SINR: 11dB, RSRQ: -8,0 dB

Speedtest LTE: 36ms, 187Mbps, 12 Mbps

Speedtest LTE+5G: 27ms, 333Mbps, 17Mbps

[Maldur]

Ma pole kindel kas Mikrotik oskab eelistada järjekorda, aga enamasti nad sindrid võtavad lubatud kombinatsioonist ise oma tarkuses, ehk et see pole raudnael, et kui B7 on võetud esimeseks, siis et ta õhtul ka on esimene, kuid mingil hetkel hommikul võib jälle olla.

Kui cell infos on N78 aegajalt olemas siis võib arvata et asud selle/nende sektorist kuhugi ääre peale.

Eraldi tahaks tervitada lillatäpimeest ja küsida avalikku selgitust - mis sulle Mikrotiki teemas ei meeldi, kui siin räägitakse Mikrotikist...?! Ja rõhutan veelkord, et vastus olgu avalik. Et kui keegi räägib kuidas MT pordikiirust manageerida, siis on ok aga kui selleks pordiks on LTE/5G siis on lilla...?

[HVhuvilinefoorumis]

Soetasin ATL 5G R16 smartechist.

Olen mastist umbes 5 km kaugusel. Operaatoriks on TELIA. Kasutan eSIM.
ATL näiteb selliseid numbried

Speedtest download sain 370 ja upload 70

Üle jäi nüüd Mikrotik ATL LTE18 kit

[Maldur]

Kuniks lillal täpil julgus kasvab, ehk HVhuviline kirjeldab kuidas kiiruste vahe välja kukkus, võrreldes LTE18'ga samades tingimustes.

[HVhuvilinefoorumis]

[Maldur]

See võrdlus muidugi on ebaõnnestunud, sest tegemist ei ole samade oludega - isegi kui T2 saatjad asuks samas mastis kus Teliagi. Aga annab aimu olulisest kasutajakogemuse paranemisest, seda küll.

Lillatäpilisel on täpid püksi vist tulnud, sest mehemoodi vastust ei näi tulevat mitte kuidagi. Seltsimehed, see on hale........

[Dirty Harry]

[jaakjaak22]

Värskest infokirjast uudiseid AX-seadmetele:

Significantly improved Wi-Fi 6 Performance with RouterOS v7.19.3 (stable)
If you’ve been waiting for a sign to explore MikroTik’s Wi-Fi 6 solutions - this is it. With RouterOS v7.19.3, we’ve introduced significant improvements to 802.11ax (Wi-Fi 6) device performance. This update enhances range, stability, and overall wireless experience, making it the best time yet to deploy Wi-Fi 6 in your home, office, or enterprise setup.

[Maldur]