Másik kérdés: mitől függ az, hogy egy adott Windows verzió/konfiguráció látja MAC Address alapján a hozzá kötött Miki eszközt, vagy sem?
Sőt azt is tapasztalom, hogy az sem mindegy, milyen/melyik hálózati kártyával próbálom.
Pl USB-s kártyákkal (általában) nem műxik :-(
Gondolom valamilyen beállítás kérdése lehet, pl ARP / IPv4 Checksum / NS / TCP Checksum / UDP Checksum Offload

/interface bridge port
add bridge=bridge1 interface=ether24
add bridge=bridge1 interface=ether1 pvid=123
add bridge=bridge1 interface=ether2 pvid=321
/interface bridge vlan
add bridge=bridge1 tagged=ether24 untagged=ether1 vlan-ids=123
add bridge=bridge1 tagged=ether24 untagged=ether2 vlan-ids=321
/interface bridge vlan
add bridge=bridge1 tagged=ether24 untagged=ether123,ether321 vlan-ids=123,321

Ez valami tuzfalas (esetleg driver) problema lehet. ARP-nak barmilyen fizikai ethernet interfeszen kene mennie.

Utolso ket sort elirtam, azok nem kellenek.(ez az interfesz neveket is elirtam az untaggednel).

[ Szerkesztve ]

Forgalomszabályozást szeretnék csinálni pcq és Queue Tree használatával, amihez először mangle szabályokat kell felvenni. Igazából csak egyenlő mértékben szeretném elosztani a hálózati sávszélességet a gépek között.
Tudnátok abban segíteni, hogy ezt lehetne-e ennél hatékonyabban megoldani? Sajnos a CPU, mintha nem bírná, kb. 300Mbit/s a letöltésem az 510Mbit/s helyett, amikor csak egyetlen gép tölt a hálózatban.
A MikroTik RB750Gr3 bizonyos magjai, 85-95%-ig is kiterhelődnek letöltéskor.

chain=forward action=jump jump-target=out::in in-interface=ether2 out-interface=all-vlan packet-mark=no-mark log=no log-prefix=""

chain=forward action=jump jump-target=in::out in-interface=all-vlan out-interface=ether2 packet-mark=no-mark log=no log-prefix=""

chain=out::in action=mark-connection new-connection-mark=Download_MC passthrough=yes log=no log-prefix=""

chain=out::in action=mark-packet new-packet-mark=Download_MP passthrough=no connection-mark=Download_MC log=no log-prefix=""

chain=in::out action=mark-connection new-connection-mark=Upload_MC passthrough=yes log=no log-prefix=""

chain=in::out action=mark-packet new-packet-mark=Upload_MP passthrough=no connection-mark=Upload_MC log=no log-prefix=""

[ Szerkesztve ]

''A szíved szabad! Légy bátor és kövesd!''

Simple queue, advanced pcq type-al, is megfelelhet a feladatra, hogy egyenlően elossza a sávszélességet, semi extra nem kell hozzá. Így talán "több marad" a prociból, ki kellene próbálni.

Kipróbáltam a Simple queue-val és pcq-val is, de talán így még lassabb lett a letöltés.
Nem tudom, hogy én állítok be optimalizálatlanul valamit, vagy tényleg ennyit tud az eszköz?

''A szíved szabad! Légy bátor és kövesd!''

Csak egy ötlet volt az ARP
Tűzfal természetesen letiltva

"/interface bridge vlan
add bridge=bridge1 tagged=ether24 untagged=ether1 vlan-ids=123
add bridge=bridge1 tagged=ether24 untagged=ether2 vlan-ids=321

/interface bridge vlan
add bridge=bridge1 tagged=ether24 untagged=ether123,ether321 vlan-ids=123,321"

Gyakorlatilag a két parancs sorozat ugyan azt csinálja.
Forrás:
https://wiki.mikrotik.com/wiki/Manual:Bridge_VLAN_Table

Szerk.: túl gyorsan válaszoltam :-)

[ Szerkesztve ]

Ebben a konfigban csináltál egy Trunk port-ot (ether24) VLAN 123-ra és 321-re.
Az ether1 ebből a VLAN-123-hoz, ether2 ebből a VLAN-321-hez tartuzik "Untagged" formában.
Nekem viszont nem ez kellene :-(
Sajnos úgy látom, hogy a Bridge/VLAN-ban nem lehet egy Access Port-ot több VLAN-hoz rendelni, ugyanis nekem ez kellene :-(

Szóval nekem valami ilyesmi kéne:

/interface bridge port
add bridge=bridge1 interface=ether23
add bridge=bridge1 interface=ether24
add bridge=bridge1 interface=ether1 pvid=123,321
add bridge=bridge1 interface=ether2 pvid=123,321
/interface bridge vlan
add bridge=bridge1 tagged=ether23 untagged=ether1 vlan-ids=123
add bridge=bridge1 tagged=ether24 untagged=ether2 vlan-ids=321

Csakhát ilyet nem lehet, nem enged :-(

Most mit akarsz konkrétan egyébként? Mert én eléggé benne vagyok a VLAN témába, még otthon is az van (mondjuk az túl van bonyolítva a buzi TP-Link switch miatt és eleve 3 bridge van, egy külön a trunk-nek), de nem tudok kijönni abból, hogy mit is akarsz pontosan.
Az Access port általában egy VLAN-hoz van hozzárendelve, melyre általában egy végponti eszköz megy, vagy egy olyan eszköz, amely azt a vlan-t osztja tovább (pl. switch, ap stb..., gyakorlatilag ez az "untagged"), de ugyan így baszhatsz mondjuk Trunk portra is switch-et vagy AP-t, csak annak tudnia kell kezelni a "gerincen" (ugye tagged-ről beszélünk) és később szétbontani Access portokra, azaz a konkrét VLAN-okra, persze címkézetlen formában, de ezért is nem értem, hogy mit is akarsz most.

[ Szerkesztve ]

Csak egy pvid lehet egy interfeszen. A PVID lenyege, hogy a bejovo untagged csomagot taggolja. Ha belegondolsz, honnan tudna, hogy melyik tag-ot rakja ra? Ha duplazod a csomagokat es az untaggedbol csinalsz egy-egy taggedet, akkor duplajara no a kihasznalt savszel a bridgen.

Ha azt akarod, hogy mindket vlan-nal legyen mindket portrol, akkor mert nem egy vlan-ba rakod oket? Ha azt szeretned, hogy a ket accessporton ne legyen forgalom egymas kozott, akkor rakd egy vlanba oket es bridge filtert dobjal a ket port koze.

#15009 Zwodkassy: Nem, a ket konfig nem ugyanaz. Az utobbi az 123,321-et mind a ket interfeszhez hozzarendeli, az elobbi pedig egyiket az egyik interfeszhez, masikat a masik interfeszhez.

[ Szerkesztve ]

Juteszembe: bridge filter helyett port isolation-t is hasznalhatsz, peldaul crs3xx switcheken.

Mint azt már próbáltam leírni, de nem sikerült, vagy nem ment át.
Van egy 26 por-os switch, bár a feladat szempontból ez mindegy is.
Két port kivételével minden port-on Untagged forgalom van. Kettőn viszont Tagged, de életerő VLAN-ID :-)
Így érkezik hozzánk. Evvan.
És mindegyik port-on lévő eszközöknek tudnia kell "beszélgetnie" egymással.

[ Szerkesztve ]

"Csak egy pvid lehet egy interfeszen"
Ja, hát ez az :-)

"Nem, a ket konfig nem ugyanaz. Az utobbi az 123,321-et mind a ket interfeszhez hozzarendeli, az elobbi pedig egyiket az egyik interfeszhez, masikat a masik interfeszhez"
Igazad vala, bocsi!

Gondolom az feltetel, hogy a ket tagged portot pedig ne hurkold ossze a switchen.

Milyen switch ez? CRS326?
Melyik portjain jonnek a tagged csomagok?

[ Szerkesztve ]

Esetleg egy konfigot nem tudnál bedobni, mert akkor érthetőbb lenne mondjuk a mostani állapot, mert nem tudom, hogy most a 2 tagged port az végül is trunk port, vagy mi, mert egyébként nem feltétlen látom értelmét a tagged-nek sem, mert másképp felesleges a címzés, untagged esetén is csak azért raksz hozzá pvid-t, hogy tudja a port, hogy melyik vlan-ból érkező forgalmat irányítsa a portra és ugye utána eltávolítja a címkézést, ha csak nem tovább megy tagged-ként egy másik trunk portra a forgalom.
De ha meg minden porton lévő eszköznek tudnia kell kommunikálnia egymással, rakd be mindegyiket egy vlan-ba, akár a vlan1-be amibe alapértelmezetten van, vagy resetelheted is a a switch-et akár, mondjuk attól függ milyen switch-ről van szól.
Ha meg az a feladat, hogy legyenek külön hálózatban egyes eszközök, de tudjanak beszélgetni egymással, akkor a routeren létrehozol annyi hálózatot, ahányra szét kell bontani a switch-en lévő eszközöket, trunk porton átlököd őket a switch-re, ott szétosztod a megfelelő vlan-okra a portokat, azt kész, még csak tűzfalszabály sem kell, mert alapértelmezetten a mikrotik átjárást biztosít a rajta létrehozott hálózatok között és akkor a 192.168.0.0/24-ből tudnak kommunikálni az eszközök a 192.168.1.0/24-es hálóval és fordítva, na de egyébként a pontos koncepciót még mindig nem értem, mert azt akarod hogy mindegyik eszköz kommunikálni tudjon mindegyikkel, de hogy most hogyan is akarod megvalósítani, azt nem értem, mert ugye belementél a VLAN témába, de ehhez alapértelmezetten nem kell VLAN, az pont a szegmentáció miatt van, bár mondjuk mint fentebb írtam, a szegmentált hálózatokat is lehet összekötni a fent említett példával, mert ugye a VLAN-okat nem csak azért hozták létre, hogy adott eszközök ne tudjanak kommunikálni egymással, hanem hogy sok eszköz egy hálózatot úgymond ne "szemeteljen tele", ha már szakmaiatlanul fogalmazunk, csak ugye egyébként a forgalomirányítási/kommunikációs terhet így átrakod a routerre.

"Gondolom az feltetel, hogy a ket tagged portot pedig ne hurkold ossze a switchen"
???
"A" eszköz csoporttól jön VLAN-10-en a kapcsolat.
"B" eszköz csoporttól jön VLAN-20-en a kapcsolat.
És középen vagyunk mi. Ennyi. Nekünk mindkét irányba tudni kéne beszélgetni.

"Milyen switch ez? CRS326?"
Jelen esetben igen.

"Melyik portjain jonnek a tagged csomagok?"
Amelyikre (sikerül) beállítjuk :-)
Szabadon választhatsz (még).

[ Szerkesztve ]

"Esetleg egy konfigot nem tudnál bedobni, mert akkor érthetőbb lenne mondjuk a mostani állapot"
A mostani állapot egy sima switch : minden port egy Bridge alatt. Gyakorlatilag alap konfig.
Ha már kész lenne a konfig, nem kellene segítséget kérnem :-)

"Ha meg az a feladat, hogy legyenek külön hálózatban egyes eszközök, de tudjanak beszélgetni egymással, akkor a routeren létrehozol annyi hálózatot, ahányra szét kell bontani a switch-en lévő eszközöket"
Egy subnet-en van mindenki, de külön épületekben, helyszínen vannak, és csak így tudták hozzánk eljuttatni a kapcsolatot. Mivel tudják, hogy nálunk MikroTik van, így az volt a kiindulási alap, hogy "a MikroTik tud VLAN-t kezelni" :-)

[ Szerkesztve ]

Egyébként ez a feladat sotfware-s VAN kezeléssel nem nagy feladat:

/interface vlan add interface=ether1 name=Vlan-123-ether1 vlan-id=123
/interface vlan add interface=ether2 name=Vlan-321-ether2 vlan-id=321

/interface bridge port add bridge=Br-Lan interface=Vlan-123-ether1
/interface bridge port add bridge=Br-Lan interface=Vlan-321-ether2
/interface bridge port add bridge=Br-Lan interface=ether3
/interface bridge port add bridge=Br-Lan interface=ether4
/interface bridge port add bridge=Br-Lan interface=ether5
stb-stb

Csakhogy ilyenkor prociból oldja meg az adott eszköz a VLAN kezelést :-(
De mindegy is! Jó van az úgy :-) :-)

A Mikrotik tud VLAN-t kezelni, csak szerintem akik ezt kitalálták, azok nem tudják hogy mit akarnak, vagy csak én nem értem még mindig, de akkor lebontom magyarul, hogy mi van:

Szóval van A épület, ahonnan jön egy kábel 10-es VLAN-on és ott mondjuk 192.168.0.0/24 hálózat van, aztán van B épület, ahonnan szintén jön egy kábel, de már 20-as VLAN-on és a hálózat ugyan úgy 192.168.0.0/24, mert ugye azt írtad, egy "subnet"-en van mindenki, csak külön külön épületekben, na már most akkor ennek így mi értelme van? Az a két épület kommunikál egymással, mert ha igen, akkor hozzátok a 3. épületbe miért megy ugyan az a hálózat két különböző VLAN-on?
Tehát vagy ilyen hülyén van megoldva (mert ez tényleg az, de ezek szerint akkor valószínűleg két internet előfizetés is van, már ha a két épület ugyan azon a hálózaton nem kommunikál egymással, bár egyébként miért érkezne hozzátok két külön VLAN-on ugyan az a hálózat), vagy még én nem értem mindig.
Először ezt kellene pontosan tisztázni, aztán tudnék megoldásokat javasolni, mert egyébként ha ugyan azt a két hálózatot összehozod egybe a ti 3. hálózatotokon, akkor ott lesznek majd IP ütközések meg egyebek, már ha jól értelmeztem a jelenlegi állapotot, meg hogy hogy akarod megvalósítani, bár megmondom őszintén, számomra ez így nem túl érthető, mert vagy rosszul mondod el, vagy tényleg ilyen hülyén van megoldva, viszont akkor talán mást kellene kitalálni.

Hat, csunya megoldast csipobol tudok:

/interface
vlan add interface=ether23 name="v20" vlan-id=20
vlan add interface=ether24 name="v30" vlan-id=30
bridge add name="bridge1"
bridge port add bridge="bridge1" interface=ether1
bridge port add bridge="bridge1" interface=ether2
bridge port add bridge="bridge1" interface=ether3
bridge port add bridge="bridge1" interface=ether4
bridge port add bridge="bridge1" interface=ether5
bridge port add bridge="bridge1" interface=ether6
bridge port add bridge="bridge1" interface=ether7
bridge port add bridge="bridge1" interface=ether8
bridge port add bridge="bridge1" interface=ether9
bridge port add bridge="bridge1" interface=ether10
bridge port add bridge="bridge1" interface=ether11
bridge port add bridge="bridge1" interface=ether12
bridge port add bridge="bridge1" interface=ether13
bridge port add bridge="bridge1" interface=ether14
bridge port add bridge="bridge1" interface=ether15
bridge port add bridge="bridge1" interface=ether16
bridge port add bridge="bridge1" interface=ether17
bridge port add bridge="bridge1" interface=ether18
bridge port add bridge="bridge1" interface=ether19
bridge port add bridge="bridge1" interface=ether20
bridge port add bridge="bridge1" interface=ether21
bridge port add bridge="bridge1" interface=ether22
bridge port add bridge="bridge1" interface=v20
bridge port add bridge="bridge1" interface=v30
bridge filter add chain=forward in-interface=v20 out-interface=v30 action=drop
bridge filter add chain=forward in-interface=v30 out-interface=v20 action=drop

Viszont ez procibol fog menni, az meg nem valami combos a switchen. A vlanozas nem erre van kitalalva alapvetoen. Ha kell savszel is, akkor inkabb a switchet meghagynam sima switchnek es a vlanok valamint a switcheiden levo cuccok osszehuzasat egy routerre biznam.

[ Szerkesztve ]

Nem én csináltálam, nem mi csináltuk a hálózatot, de szana szét vannak a telephelyen kontrollerek, és egyéb eszközök. Új kábelt német fűzhetünk, stb-stb.
Mindegy is! Ebből kell főzni.
Ez csak egy apró megoldandó feladat a sok (száz) közül.
Ettől sokkal nagyobb horderejű megoldandó is van.
Csupasz arra volta kíváncsi, hogy ez megoldható-e MikroTik RouterOS alatt switch chip szintjén, a Bridge-Vlan konfigurációval. Ha nem, hát nem.

"bridge filter add chain=forward in-interface=v20 out-interface=v30 action=drop
bridge filter add chain=forward in-interface=v30 out-interface=v20 action=drop"

Ezek minek? Az itt lévő eszközök így hogyan fognak egymással beszélgetni?
Mondjuk VLAN-20 = A épület ,
VLAN-30 = B épület,
és a többi legyen C épület.
És még lesz több is.
Így tudtak nekünk kábelt, kapcsolatot "adni" és kész.
Szóval ezeken keresztül kell nekünk beszélgetni, úgymond a "saját" eszközeinkkel.
És hogy miért így vannak megcsinálva?
Ki a *** érdekel. Nem ez a feladat.
Na mindegy is!

[ Szerkesztve ]

A vlan interfesz az azt csinalja, hogy a hozza parositott interfeszen fogadja es kuldi a tagged csomagokat, de maga a vlan interfeszen folyo forgalom mar untagged. Ha ezt berakod a bridge-be portkent, akkor az lesz, hogy minden a bridgen folyo forgalom ki tud menni a vlan interfeszhez rendelt interfeszen taggelve. Ennek hatranya, hogy ha ket kulonbozo vlan interfeszt osszehuzol egy bridgeben, akkor lenyegeben a vlan id-t forditja a ket vlan kozott, azaz a ket forgalom atmegy.

Peldanak:
Ha bejon a bridgere egy untagged, pl ether2 portrol egy csomag, akkor az kimehet a v20-ra es akkor a v20 interfesz felrakja ra a 20-as vlan id-t es kikuldi ether23-on. De kimehet a v30 fele is, es akkor a v30 interfesz felrakja ra a 30-as vlan id-t es kikuldi az ether24-en.
A ket vlan-t igy koti ez ossze:
Bejon egy packet az ether23 interfeszen 20-as vlan idvel, akkor a v20 interfesz fogadja azt, leszedi rola a vlan tagot, es bemegy a bridge 1-be sima natur untagged csomagkent. Onnan a bridge tovabbiranyitja a v30 interfesz fele, ami megtaggeli a csomagot a 30-as vlan id-vel es kikuldi az ether24 interfeszen. Tehat lenyegeben ami bejott az ether23-ason 20-as vlanban, az kimegy a 24-esen 30-as vlanba. Es visszafele is. Ezert kell a bridgen keresztuli forwardot megtiltani a ket vlan interfesz kozott.

Mivel az ott levo eszkozok az ether1-ether22 portokon vannak igy a ket szabaly kozul egyik sem fog lefutni rajuk, tehat ezek az eszkozok egyaran kilatnak a 20-as es a 30-as vlanba. A szabaly csak azt akadalyozza meg, hogy a 20-as vlanbol a 30-as vlanba atlasson es forditva a 30-as vlanbol a 20-as vlanba atlasson.

[ Szerkesztve ]

Nem azért mondtam, hogy esetleg megsértselek vagy ilyesmi, csak sajnos ez így akkor is hülyeség, ugye fentebb taglaltam, hogy miért.
Ugye meg lehet oldani azzal a konfigurációval amit Reggie0 is írt, mondjuk én lehet módosítanék rajta, de nem az a lényeg, hanem hogy konkrétan nem erre találták ki a VLAN-t, másrészt további problémák fognak felmerülni.
Ugye nem mondtad a hozzászólásomra, hogy nem úgy van ahogy nekem lejött az egész és leírtam, ezért ugye az lesz a probléma, hogy ha te összefűzöl két "ugyan olyan" hálózatot (két ugyan olyan IP hálózatot), akkor még ha 1-1 hálózatban dinamikus fix IP címek is vannak, a harmadik hálózatban, ahol te össze akarod fűzni őket, ott kérdés hogy melyik kliens honnan kapja majd az IP címet, meg ugye melyik átjáró fele megy a forgalom és ha csak simán fűzöd össze, akkor már csak az átjárók IP címe kapcsán is ütközés lesz és a többi problémáról nem is beszélek.
Vagy eleve a két hálózatot össze kellene vonni egy hálózattá, ha már úgy is össze lesznek kötve a 3. épületben lévő switch-en keresztül, vagy meg kellene változtatni legalább az egyiken lévő IP tartományt, főleg ha mindkét telephely külön internethozzáféréssel rendelkezik és akkor a 3. telephelyen routing-al meg lehetne oldani a dolgot, ott lenne egy 3. hálózat, a 3 hálózatot meg összeroute-olod, azt mindegyik elér mindent, viszont ha a 3. telephelyen nem lesz internet hozzáférés, akkor ugye el kell dönteni, hogy onnan hova megy a netforgalom, vagyis a 2 telephely közül melyiken megy majd ki.
Tehát nem az a konkrét baj, legalább is szerintem, hogy megoldható-e ez MikroTik alatt, mert megoldható, a gond inkább az, hogy további problémák lennének, amiket megint meg kell oldani, ezért érdemes lenne valahogy az egészet átszervezni, legalább is szerintem, bár ez a tényleges helyzettől van, mert ugye most sem erősítetted meg, de éppen le sem tagadtad, hogy úgy van-e ahogy én gondolom a hálózatot az általad leírtak alapján, viszont ha úgy van, akkor ez így eléggé problémás, legalább is szerintem.
Persze ugye felvázoltam, hogy össze kellene vonni a 3 telephelyet 1 hálózattá a 3. helyen keresztül ha már van kapcsolat, na de ugye csak annyit tudok, hogy van egy kapcsolat mire van VLAN létrehozva, na de hogy az most stabil kábeles kapcsolat-e vagy mondjuk mikrós stb... azokat megint nem tudom, így ez is csak egy ötlet, ami nem biztos hogy hálózat stabilitás, illetve redundancia szempontjából megfelelő, ezért esetleg maradna a routing és a 3. helyen is külön netkapcsolat, vagy valami hasonló, hogy el is érje egymást az összes eszköz, de mondjuk szakadás esetén mindenhol maradjon internet és így tovább.
Na de lényeg, hogy csak leírtam mi a probléma, meg alapjában véve mire van a VLAN, meg ugye meg lehet azt csinálni amit kérdeztél, csak a fent leírt tények alapján ha úgy van ahogy én elgondoltam a leírásod alapján, kérdés hogy érdemes-e ezt így megcsinálni.

"A szabaly csak azt akadalyozza meg, hogy a 20-as vlanbol a 30-as vlanba atlasson es forditva a 30-as vlanbol a 20-as vlanba atlasson"
Már pedig ha nem látnak át, akkor hogyan fog egy eszközünk beszélgetni a VLAN-20-ból a VLAN-30-ba?
Minden eszköznek, minden irányba tudnia KELL beszélgetni. Pont ez lenne a cél.
Nem akarunk semmit, semmitől elszigetelni.

Hat, akkor nem kell az a ket szabaly. En ugy ertettem, hogy ether1-ether22-es portokon lognak a helyi eszkozok, amelyek ellatnak a 20-as es 30-as vlanban, de a 20-as es a 30-as vlan nem lehet osszekotve egymassal, mert az ket tavoli hely.
Ha a 20-as es 30-as vlan osszekotheto, akkor az egyik site-on at kene szamozni, hogy egyezzen, vagy megszuntetni az egesz vlanozast.

Sajnos a mac learning tabla a switch ic-ben kozos, igy a port isolationnal nem lehet trukkozni, pedig ugy meg lehetne oldani switch ic-n belul, ha 2x 1-1 portot visszahurkolsz.

[ Szerkesztve ]

Először is nincs harag, természetesen 😁
Nincs kettő, három, meg több hálózat.
Neki futok újra másképpen.
Van mondjuk 30 eszköz, 3 épületben (talán így a legegyszerűbb leírni).
Alap esetén ezeket összekötnénk mi magunk egy hálózatba.
Az egyszerűség kedvéért mondjuk, hogy ez épületenként (területenként) igaz is.
Viszont az épületek (területek) között már nem csinálhattunk semmit. Azt egy másik csapat csinálja (csinalhatta csak) meg nekünk.
Szóval nekünk ebből KELL gazdálkodni.
És hogy, hogyan valósította meg?
Passz. Nem is akarom, akarjuk tudni, van ezer más dolgunk is. Az egész melóban ez csak egy részlet a sok közül.
Nincs se több (egy sem) internet kapcsolat, DHCP szerver, meg kutyafüle 😁

[ Szerkesztve ]

Mindenkinek köszönet a segítő szándékért, és bocsánat, ha nem tudtam jól elmondani, átadni a szitut!

Elvileg lehet vlan-t is transzlatalni, de csak 2 port kozott, meg nem latom, hogy hogyan lehetne rahuzni a helyi eszkozoket:
[link]

Ezen holnap elgondolkodom, majd kiprobalom egy hurokkal a switchen belul.

[ Szerkesztve ]

Érdekesnek tűnik. Majd ha lesz időm, meglesem én is 😁
Köszi a tippet!

Nem olvastam az egészet, úgyhogy csak bekérdezem a fentiekrre, hogy Port isolation?

Pont nem az izoláció a cél :-)

Sziasztok,

Ipari területen szeretnénk mobilnetet "fogni" elég közeliek az antennák 300-1500 méteren belül több adóállomás is található.
Mivel korábban említve lett, hogy a tornyokon a roamingért a szolgáltató felel ezért kérdezném mivel járnék jobban?
- LHGG a legközelebbi toronyra
- LTAP kültérre a házfalra
- egyéb?

Köszönöm!

A szolgáltatód fix, vagy még nem eldöntött?
Ha még nem döntöttél, szerintem teszteld mindegyiket, mekkora sávszél van napközben, este, vagy amikor használni akarod.
Amelyik a legjobb eredményt adja, arra a toronyra fókuszálj és keress antennát.

300-1500 meter azert nem nagy dolog, de LHGG-vel jobban jarsz, mivel az iranyitott antenna 17dBi nyereseggel, ellenben az LTAP pedig korsugarzot hasznal 4dBi nyereseggel.

Az LtAP-t inkabb akkor jo, ha valtogatni kell a tornyok kozott, peldaul azert mert mozog, vagy valtozoak a terep/terjedesi viszonyok stb. ami miatt tornyot kell valtogatni, vagy szukseg van lehetove tenni a toronyvaltast uzembiztonsag miatt.

[ Szerkesztve ]

Rendben, köszönöm!

Fix. csak a telenor ad ma mo-n public ip-t korlátlan mobilnettel.

7.1rc6 megjelent!

Sziasztok!

Vettem egy SXTLAT6 készüléket. Sim be, reset, adtam neki ip címet, nat. DHCP kikapcsolva. PC-én ha megadom az IP címet, subot, dns, tökéletes net. Következő a hiba:
Ha az Rb3011en beállítom, hogy 192.168.0.251-től (ez SXT ip címe) kapja a netet, onnantól kezdve nincs net az Rb3011hez csatlakozott eszközökön, de a saját gépen (ami közvetlen SXThez csatlakozik továbbra is van net.)
Mit állítsak be neki még?
Az SXT-nem szeretném, ha DHCP-t osztana.
Köszönöm!

[ Szerkesztve ]

IPhone 15 Pro Max, Iphone 13

Probald meg pingelni a 8.8.8.8-at valamelyik eszkozrol. Ha mukodik, akkor a default gateway-t irtad at csak az rb3011-en, akkor valoszinuleg a nevszerverekkel lesz gond, ird at a nevszervereket 8.8.8.8 es 8.8.4.4 -re az /ip/dns -ben (webfigen dns client).

Igen, Gateway írom át, mert a DNS 8.8.8.8, és 8.8.4.4 (RB3011)
SXT (dynamic Servers 84.2.46.1 Telekom)
Pingeli a 8.8.8.8, de weblap nem tölti be. Olyan ideges vagyok már, hogy tuti az orrom előtt van a megoldás.
Ha megy a telekommal, akkor mellé kerül még egy telenor kártya is...

[ Szerkesztve ]

IPhone 15 Pro Max, Iphone 13

Ha az Rb3011en beállítom, hogy 192.168.0.251-től (ez SXT ip címe) kapja a netet,

Ez pontosan mit jelent nálad? Pontosan mit állítottál át 192.168.0.251-re?

gateway résznél adom meg SXT ip címét.
Alatta DNS Server 8.8.8.8, 8.8.4.4

IPhone 15 Pro Max, Iphone 13