[XeStAiSy]

Aru me saa mis vlannidest kogu aeg räägitakse kui digiboxi pole siis ei olegi midagi vlannida ja ilma vlannita tuleb ka digiboxi see stream ära vähemalt arrise puhul. SFP pulkasid vlannitaks no milleks? Telia ühendus tuleb niisamagi püsti ja videostriim tuleb ka ilma vlannita. Ruuterile resa ja peale seda ühendus ilusti olemas ka sfp pulgaga. Tervet võrku ei ole vaja ju videostriimitada mõni topib selle ka wifisse ja siis selgub mingi jama on. Digibox saab oma striimi kui isegi talle on väline IP antud isegi ruuterit ei pea läbima.

[bladerunner]

Mõni tahab oma sisevõrku ka äkki segmenteerida? Mul on see nt. 3-ks jaotatud.

[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]