Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: OP_wifi 14. 07. 2015, 18:02:35
-
Ahoj, nereversoval jste nekdo princip fungovani wifi kontroleru typu unify od ubnt a obdobnych toolu od cisca a spol?
Pokud vim, tyto zarizeni/sw resi:
* vykopavaji klienty kdyz maji nizky signal a soucasne jsou v dosahu jineho AP ktere je klientovi bliz
* nastavuji optimalni kanal/vykon jednotlivych AP
* hromadna konfigurace AP
* nejake sitovani typu NAT, DHCP atd.
* "bezpecnost" (IDS, firewall.)
prosim o pripadne doplneni - z meho pohledu by toto melo byt datelne na urovni skriptu komunikujicich napric OpenWRT.. Nebo je toho vic?
-
unify ale nic takovyho neumi, to ma jen appku, ktera pres ssh konfiguruje hromadne vsechny asociovany krabky.
Co se tyce cisco, motorola ... tak predevsim to musi taky umet to APcko, takze SW je ti bez prislusnyho HW na kulovy. Aktualni stav je pak takovej, ze se to da koupit jak v podobe "HW", tak v podobe hotovyho virtualu, tak v podobe "chytryho APcka" = jedno z APcek prevezme funci kontroleru.
-
..tak predevsim to musi taky umet to APcko..
no, moje AP = openwrt@routerboard, staticke konfigurace bych resil puppetem, dynamicke pres ssh..
Jde mi o to, co vsechno potrebuju mit pod kontrolou, aby mi dobre fungoval roaming mezi AP..
-
IDS? Na WiFi krabičce? Ty jsi patrně zešílel... Jinak viz UBNT. Samodomo řešení určitě nedoporučuju.
-
Jde o to, zda chceš mi pseudo bezproblémový roaming, který závisí hlavně na schopnostech koncových wifi klientech rychle přejít na jiné AP, pak ti stačí UniFi nebo od Mikrotiku APčka řízená přes CAPsMAN. Tyto věci jen zpříjemňukíé správu, že hromadně nastavuji X rádií, politiky atd.
Nebo to má opravdu fungovat naprosto bezproblémově, kdy je použit ten controller a APčka jsou řízena jako jeden celek a ne samostatných X. Což dělají ty Cisco, HP, Aruba řešení.
V druhém případě jsou celé L2 rámce datové i řídící od koncových rádií předávány na kontroler, který si rozhoduje o co a kam a ty rádia jsou jen tupý media konvertor, kdy veškerá logika a rozhodováníse děje v kontroleru. v prvním případě se vše řeší lokálně v tom APčku.
Jinak si prostuduj CAPWAP protokol (RFC5415), to je protokol pro řízení APček z kontroleru. Exisutje i pár zařízení, co jej podporuje, takže ty pak můžeš použít jako ty koncové rádia. Nejlevnější jsou asi ty Mikrotiky, pokud je nainstlaován wireless-ap balíček, nicméně ho neumí celej (pozor, wireless-cm2 balíček používá privátní Mikrotik protokol a funguje jen mezi Mikrotiky v roli řadiče/APček). Uplná podpora by měla být v některých Arubách.
-
wireless-ap balíček
Překlep, ne wireless-ap, ale wireless-fp.
-
@M
diky za nakopnuti, capwap bylo klicove slovo dostal jsem se k paperu Current Status and Overview of the CAPWAP Protocolhttp://www.cse.wustl.edu/~jain/cse574-10/ftp/capwap/ (http://www.cse.wustl.edu/~jain/cse574-10/ftp/capwap/), kde se pise vice. Kdosi uz na open reseni pracuje, opencapwap - https://github.com/vollero/openCAPWAP (https://github.com/vollero/openCAPWAP).
-
Kdosi uz na open reseni pracuje, opencapwap - https://github.com/vollero/openCAPWAP (https://github.com/vollero/openCAPWAP).
Tak jistě. Vypadá to vyloženě živě, doufám, že to máš pro nějaké produkční použití, to bude velká paráda. ;D ::)
-
Nu, třeba si koupí pár APček s podporou CAPWAP protokolu a když svůj soft neuchodí, tak nasadí Cisco WLC (wireless LAN controller) , ten také už nějakou dobu používá CAPWAP protokol pro ovládání koncových APeček.
Takže nevyhodí aspoň investice do APček. A pokud bude chudej, tak si tam pustí ten CAPsMAN od Mikrotiku (CAPsMAPv1, ten používá CAPSMAN protokol). :-)
-
+1 to M.
Skutecne funkcni roaming musi byt udelan na L1, je to z principu navrhu normy 802.11 ktera nepocita s inteligenci APcka, o vsem (vcetne asocicace/deasociace pri spatnem signalu) si rozhoduje klient. Jakekoliv reseni na vyssich vrstvach bude jen do urcite miry funkcni bastl s packetlossem pri handoveru.