Sziasztok!
Keresgéltem mindenfelé, de nem nagyon találtam megoldást.
A következő lenne a problémám:
Adott 2 db hálózat. Mindegyik hálózat VLAN-t használ(na). Eddig rendben is van a dolog. A 2 hálózatot egynek kellene kezelni(ez nem is lenne gond).
A 2 hálózat össze van kötve wireless eszközökkel. Itt a probléma. A wireless nem képes továbbítani a VLAN-al megnövelt kereteket. A wireless eszközön nem lehet állítani semmit, frissítés nincsen hozzá. Cserére nincsen lehetőség.
A wireless 2 végén 1-1 Linuxot futtató szerver van amik bridge funkciót látnak el. Hogyan lehetne azt megoldani, hogy az egyik szerver feldarabolná a hálózatból a belső interfészén beérkező csomagokat kisebb csomagokra, majd a másik oldalon a másik szerver összerakná újra nagyokra és így a másik irányból is?
Esetleg még megoldás lenne ha valahogy az MTU-t lehetne csökkenteni 1400-ra a csomagoknál, de nincsen lehetőség minden gépen egyenként beállítani. Nem tudom van-e mód, hogy az egyik szerver valahogy lecsökkentse az MTU-t amíg átér a csomag, majd újra megnövelje a másik.
Van valakinek valami jó ötlete?
A válaszokat előre is köszönöm szépen.
lzoli
- 4003 megtekintés
Hozzászólások
Senkinek semmi ötlete?
- A hozzászóláshoz be kell jelentkezni
Ha a vlan-taget lestrippeled, akkor azt onnantól imho b*szhatod. Vagy bridge-szinten eldobálod a vlan-tageket, ha nincs szükség rá, vagy pedig egy decensebb, vlan tageket is átvinni képes wireless eszközben gondolkodj.
--
'Please, just tell people to use Windows.' - Linus Torvalds on KDE and GNOME
- A hozzászóláshoz be kell jelentkezni
Nem egészen tiszta amit írsz...
tehát 2 wlan háló van, wlan1 és wlan2 két külön gép csoport, külön ip tartományban. A két csoportot akarod össekötni de nem megy. Erről lenne szó???
- A hozzászóláshoz be kell jelentkezni
Bocs, hogy zavarosra sikerült. 2 épület van, 2 gépcsoport, amit egy hálózatnak kellene kezelni. Egy IP tartomány van, egy alhálózatban. Az épületek Wireless-el vannak összekötve. Az nem megy, hogy a VLAN információval "meghízlalt" keretek nem "férnek át" a wireless eszközön.
- A hozzászóláshoz be kell jelentkezni
openvpn (vagy valami tunnel) a ket gep koze? Az openvpn tud bridge modban is menni, es meg lehet neki adni kulon a fizikai link MTU-jat, es kulon a kapcsolat MTU-jat.
- A hozzászóláshoz be kell jelentkezni
Alapból nem jó!
Ua ip tarományt használsz, akkor mi a netmask??? Valszeg azért nem megy a kapcsolat, nem azért mert 'nem fér át'! Ilyen nincs,h nem fér át! A wlanbridge eldarabolja a kereteket, a jobbaknál állítható a keret darabolás mértéke, a többinél automatikus.
Mi a netmask? ird le a háló beáálítasokat, h mit használsz.
- A hozzászóláshoz be kell jelentkezni
En is talalkoztam olyannal, hogy nem fer at a csomag. A normal Ethernet frame maximum 1514 byte, minden (drotos) halokartya eldobja az ennel nagyobb csomagokat, driverbol kell neki megmondani, hogy fogadja az 1518 byte-os csomagokat is (a VLAN tag az plusz 4 byte).
A 100-as kartyak kozul csak az Intel es a 3Com kartyak tudjak, vagy legalabbis a kernelben levo driverek kozul csak ezekben lattam tamogatast.
- A hozzászóláshoz be kell jelentkezni
A trükk ott van, h Fragmentation Threshold, és RTS Threshold.
Mindegyik darabol, csak van amelyikben ez nem állítható! Fix!
- A hozzászóláshoz be kell jelentkezni
Tudtommal a Fragmentation Threshold az arra jo, hogy tobb darabban kuldi at az ennel az erteknel nagyobb frame-eket azert, hogy ha valami halozati zavar van, akkor csak azt az egy reszletet kell ujrakuldeni, nem az egesz csomagot.
Az RTS Threshold pedig azt csinalja, hogy az ennel az erteknel nagyobb csomagok elott kikuld egy RTS frame-et, es megvarja a CTS-t (ugymond lefoglalja maganak a csatornat).
- A hozzászóláshoz be kell jelentkezni
Nem!
Az FR.th. az adatot ekkora csomagokra mondjuk úgy összevárja, és ekkora keretméretben továbbítja az ellen állomás felé. Zavar esetén valóban újra küldi mert ilyen a tcpip. De! Ennek a méretét szabályozva tudod zavartatás esetén csökkenteni a hibaarányt v. növelni a sebességet.
Minél nagyobb az érték az eszköz beállítási lehetőségétőltől függőn, annál nagyobb az átviteli sebesség. Minél kisebb, csökken(het) a sebesség, és/vagy javul az átvitt keretek száma. Ha csökkented az értékét, értelemszerűen a fejlécek és az rts-ek értékével csökken a sávszél, viszont csökken az újraadások darabszáma.
Ehhez viszont állítani kell az rts-t is, mert különben a csomag küldése előtt rts-értéket vár, tehát kihasználatlan a csatorna aennyi ideig Bacon lesz csak a csatin.
- A hozzászóláshoz be kell jelentkezni
Nyilvan a TCP/IP is ujrakuldi, ha hibat talal, de itt konkretan a WLAN altali ujrakuldesre gondoltam, es ilyenkor nem az egesz (mondjuk 1500 byte-os) csomagot, hanem csak a FragThresh meretu csomagot kell ujrakuldeni.
Ez mind szep es jo, de ettol hogy fog atmenni rajta a maximalisan megengedettnel 4 byte-tal nagyobb csomag?
- A hozzászóláshoz be kell jelentkezni
kojot megpróbálom jobban kifejteni a problémát.
Az IP címek a 10.10.x.x-es tartományból kerülnek ki. A netmask 255.255.0.0. Az IP címeket nem én találtam ki, és beleszólásom sincsen.
Megpróbálom neked felvázolni a teljes hálózatot mert kicsit ki van forgatva. Hátha úgy körülbelül képben leszel.
A két épület között lézeres adatátvitel van. Backup célokra van fenntartva a wireless mikor a lézer nem működik(köd pl). A Linuxot futtató gépek amik a híd funkciót látják el nem közvetlenül vannak csatlakoztatva a wirelesshez és a lézerhez, hanem egy-egy layer 3-as switch-be vannak dugva, a lézerek és a wirelessek is azokba a switch-ekbe csatlakoznak. A switch elvileg spanning tree protocol segítségével állapítja meg, hogy melyiket kell használni.(pl ha a lézeres kapcsolat megszakad) Ez a része nem tiszta nekem sem, mert nem én csináltam és nem is láttam még a hálózatot. A lézeres része működik jól, a wireless résszel meg az a gond, hogy a VLAN infóval megnövelt keretek nem jutnak át rendesen. Állítólag nem lehet állítani a wirelessen, nincsen hozzá frissítés.
Ezért kellene valahogy csökkenteni az MTU-t valahogy központilag mikor a wireless aktív, vagy eltördelni és újra összerakni a csomagokat.
Remélem valamennyire sikerült elmagyaráznom a problémát. Ha valami még nem tiszta akkor megpróbálom újra.
Üdv: lzoli
- A hozzászóláshoz be kell jelentkezni
Ha köd van akkor a wireless sem fog működni. Persze ez távolságfüggő, de ha megy is, a sebessége elég visszafogott lesz...
- A hozzászóláshoz be kell jelentkezni
Állítólag ha nem használnak VLAN-t akkor elfogadhatóan működik még ködben is.
- A hozzászóláshoz be kell jelentkezni
No igen, itt a bibi!
A netmaskot nem véletlenül találták ki.
a 255.255.255.0 esetén ugye 255 gépet címzel meg a hálóban. No és 255.255.240.0 esetén???
A Te esetedben meg 255.255.0.0, 65535 gépet címezhetsz meg. De mivel nincs ennyi, nem fog átkerülni a wlan bridge túloldalára semmi, mert azt mondod neki, h ebben az al hálóban keress. Vagyis ezzel a netmaskkal azt mondtad a wlannak, h ezen az oldalán ennyi gép van. De ez nem igaz, mert a háló fele odaát van, tehát oda nem is adja tovább a keretet. A wlant úgy képzeld el, h az ethernet vége itt van a rádió frekis vége meg a másik hálóig átér, oda van 'bevezetékelve' . A netmaskkal megértheted vele pl, h hány darabban van a tartományod.
Itt egy link nagyon ügyesen
http://www.ceenet.org/workshops99/George_Macri/1day/labs/Netmask_Table…
/24 255.255.255.0 0xffffff00 11111111 11111111 11111111 00000000 vagyis 255 gép van ezen az oldalon amit közvetlenül elérsz
/32 255.255.255.255 0xffffffff 11111111 11111111 11111111 11111111 esetén viszont csak 1 db
ha pontosan 2db ra van vágva a hálód, akkor neked ez segít(het). Ip kiosztástól függ.
/25 255.255.255.128 0xffffff80 11111111 11111111 11111111 10000000
vagyis 2x 128 db gép, ahol lejön egy a gw-re, egy a netmaskra, vagyis 126 ip-t használhatsz oldalanként.
HA mindenáron ragaszkodsz azonos ip tartományhoz mindkét oldalon akkor viszont baromi lassú lesz a dolog. Ui minden alkalommal a jel lekérdezésre kerül akkor is, ha nincs ott a keresett ip. Magyarán terheli a hálót feleslegesen, amiről a bridge visszajelzést küld, tehát dupán foglalod a sávszélt ua adattal.
De ahhoz, h átkerüljön a túloldalra is, és ezt megértesd a wlan eszközzel, ezt a tudomására kell hoznod a netmask értékével. Neked nem bövíteni, hanem szűkíteni kell a netmaskkal a keresést, és ha nincs ezen az oldalon válasz, akkor a bridge továbbítani fogja és megkérdezi a túloldalt is. Ha ott van, akkor elvileg megjegyzi és a továbbiakban eszerint fog eljárni.
nézd meg ezt is
http://jodies.de/ipcalc?host=192.168.100.1&mask1=25&mask2=
- A hozzászóláshoz be kell jelentkezni
Bocsi, de eleg sok zagyvasagot osszeirtal a netmaskokrol.
Abban igazad van, hogy erdemes lenne route-olni brige helyett, mert az kiszurne egy csomo folosleges forgalmat, de a kerdezo azt irta, hogy nincs beleszolasa az IP cimek kiosztasaba, tehat ez sajnos nem jarhato ut.
- A hozzászóláshoz be kell jelentkezni
Akkor nem fog működni és passz!
Hol a zagyvaság???? Olvass róla kicsit. ld Tannembaum piros könyve. Ez a bibliám :)))
- A hozzászóláshoz be kell jelentkezni
Hol a zagyvaság????
Hat itt:
A Te esetedben meg 255.255.0.0, 65535 gépet címezhetsz meg. De mivel nincs ennyi, nem fog átkerülni a wlan bridge túloldalára semmi, mert azt mondod neki, h ebben az al hálóban keress. Vagyis ezzel a netmaskkal azt mondtad a wlannak, h ezen az oldalán ennyi gép van.
A netmask azt mondja meg, hogy a subnetben hany gep lehet, nem azt, hogy hany van. Egy bridge pedig akkor tovabbitja a csomagot, ha ugy tudja, hogy a celallomas a masik oldalon van (vagy ha nem tudja, hogy hol van a celallomas, vagy broadcast csomag volt). Mi koze egy Layer 2-n mukodo eszkoznek a felsobb protokollokhoz (esetunkben az IP-hez, ami Layer 3)? A WLAN bridge-et ugy kepzeld el, mint egy switchet, es egybol rajossz, hogy miert zagyvasag.
Ha mindenáron ragaszkodsz azonos ip tartományhoz mindkét oldalon akkor viszont baromi lassú lesz a dolog. Ui minden alkalommal a jel lekérdezésre kerül akkor is, ha nincs ott a keresett ip.
Ez megint nem igy van. Amikor ket gep kommunikalni akar (es nem ismerik egymas MAC cimet), akkor az elso broadcast-el egy ARP kerest, amire a masodik valaszol a sajat MAC cimevel (ezeket a switch/bridge is megtanulja), es innentol a bridge nem fogja foloslegesen tovabbkuldeni a csomagokat.
ld Tannembaum piros könyve. Ez a bibliám :)))
Meg olvasgasd... :-)))
- A hozzászóláshoz be kell jelentkezni
Egy bridge pedig akkor tovabbitja a csomagot, ha ugy tudja, hogy a celallomas a masik oldalon van (vagy ha nem tudja, hogy hol van a celallomas, vagy broadcast csomag volt).
Ez sem igaz.
--
'Please, just tell people to use Windows.' - Linus Torvalds on KDE and GNOME
- A hozzászóláshoz be kell jelentkezni
Mit hagytam ki?
- A hozzászóláshoz be kell jelentkezni
Igen érdemes lenne routolni, de hát abba sincsen beleszólásom. :)
Elvileg a rendszergazda a következő dolgot csinálta a jobb sávszélesség kihasználás végett(idézem): "LACP aggregalt csatornan keresztuli adatatvitel jumbo frames modszerrel van osszefogva" Így kevesebb fejlécinfó utazik az épületek között szerinte.
- A hozzászóláshoz be kell jelentkezni
B@sszus! Mondjon le! :) Erre nem lehet mit mondani, ha nem megy és csodálkozik. Néha a drágább az olcsóbb...
http://www.cisco.com/en/US/tech/tk389/tk213/tk833/tsd_technology_suppor…
- A hozzászóláshoz be kell jelentkezni
Csak a lézernél használ LACP-t(2x100 megabites lézer). A wirelessnél nem.
- A hozzászóláshoz be kell jelentkezni
Ez a topológia eddig OK, csak kérdés, hogy mi a túrónak kellenek a VLAN-tagek, mikor két épületet kötsz össze egy wifivel?
STP meg emlékeim szerint nem erre való.
--
'Please, just tell people to use Windows.' - Linus Torvalds on KDE and GNOME
- A hozzászóláshoz be kell jelentkezni
Azért kell VLAN, mert a rendszergazda így választ külön nem publikus, csak néhány gépnek elérhető szervereket, IP telefonokat, IP kamerákat.
- A hozzászóláshoz be kell jelentkezni
Akkor várjunk csak. Tehát mindkét oldalon vannak olyan végpontok, amelyek A vlanhoz tartoznak, és ezeknek a tageknek kell átmenni, hogy ugyanazon vlanban elérhető kamerákon lássák az 4m4t3ur-v0y3ur cuccokat. A B vlanosok pedig nem láthatják. Így már világos.
De akkor sincs mit csinálni, ha a wifi eszköz eldobálja.
--
'Please, just tell people to use Windows.' - Linus Torvalds on KDE and GNOME
- A hozzászóláshoz be kell jelentkezni
Pontosan. Arra kellene valami megoldást keresnem, hogy mégis átjusson a Wireless-en, de beletört a bicskám az ügybe. Ezért kérdeztem itt, hogy hátha valaki tapasztalt találkozott már ilyennel/oldott meg már ilyet. Írták az OpenVPN-es megoldást, hogy ott lehet állítgatni az MTU-t. Még annak utánanézek.
- A hozzászóláshoz be kell jelentkezni
Írod, hogy a linuxos gép nincs a wireless-hez kapcsolva. De akkor minek van wireless interfésze? Szerintem, ha az adott eszköz wireless drivere nem támogatja a 802.1q-t, akkor nincs esély. Le kell cserélni olyanra, ami tudja. (Vsz. van ilyen.) IMHO a problémán MTU beállítással nem lehet segíteni.
Egyébként mi a szerepe a Linux gépeknek? A leírás alapján a switch-ek az "érdemi" bridge-ek (azok futtatják az STP-t).
- A hozzászóláshoz be kell jelentkezni
Idézem: "MAC-cim alapjan szuri a LAN oldalrol erkezo csomagokat, illetve egyeb allitasokat is vegez, pl.: TTL. szuri a forgalmat"
- A hozzászóláshoz be kell jelentkezni