classic.ISPforum.cz

Ahoj, dobrý den,
prosím o radu se školní sítí. Poměrně rozlehlá historická budova o 3. patrech. Na každém patře jsou dvě dualbandové wAP. Jak hlavní router, firewall, NAT, CAPsMAN, DHCP server je použitý RB3011. Switche jsou řady D-LINK DGS-1210. V síti jsou nastavené VLAN pro jednotlivé segmenty sítě. cAP komunikují s hlavním routerem skrze management VLAN, v CAPsMAN mají pak v datapath nastaveno do jaké VLAN patří datový tok. Toliko ke stručnému popisu a teď moje dotazy:

1) Potřebuji udělat rozumný roaming mezi AP - jak nastavím, aby to klienta vykoplo, pokud bude mít signál horší než dejme tomu -75 dBm a přehodilo ho to na AP, které má lepší signál? Zkusil jsem jednoduchá dvě pravidla do Access Listu, ale nejsem uplně přesvědčenej, že je to správně

/caps-man access-list
add action=accept allow-signal-out-of-range=1s disabled=no signal-range=-75..120 ssid-regexp=""
add action=reject allow-signal-out-of-range=10s disabled=no ssid-regexp=""
2) Ve sborovně se o přestávkách hromadně (hodně notebooků v jedné místnosti) připojují učitelé k systému Bakaláři a jak jsem zjistil, tak to dělá velké peaky v přenosech. Trvalý datový tok není velký, ale když udělají nějakou akci (zapnou modul, uloží záznam apod...), vystřeluje to mezi 10-40 Mbps na jednoho klienta. Takže si dokáži představit, že to dokáže APčko slušně zadřít. Poradíte mi prosím vhodný queue type, který by toto řešil?

3) Pokud bych došel k závěru, že do sborovny je potřeba přidat další AP, jak docílím nějakého load balancingu mezi jednotlivými cAP (za předpokladu, že se k nim klienti připojí se slušným signálem)?

Děkuji za rady a přeji hezký den i nastávající víkend.

Access list je asi jediná rozumná metoda jak donutit klienta zkusit si vyhledat jiné AP. Nevýhoda je ta, že pokud ten klient už je na AP s nelepším signálem ale ty ho dle access listu stále odpojuješ tak to taky není úplně dobře.


Load balancing mezi AP asi nevymyslíš, přidat wAPko do sborovny můžeš, klient by se ti teoreticky měl připojit na AP s nejsilnějším signálem. Peaky pak řešit skrze queue tree.

load ballancing vyřešíš přes capsman. Dají se tam zvolit groupy APček a pak nedovolí připojit se k jednomu pokud druhý má o jednoho klienta méně atd.. to prý údajně funguje.

To kopání klientů podle signálu, to funguje jenom při připojení, nepřipojí se pokud nesplňuje minimální signál. Po připojení už ho to nekopne. A ještě mám ten pocit že se to musí zapisovat jinak.

já teda nevím, ale dělal jsem měsíc zpátky pokrytí jednoho penzionu s asi 8x cAP (ty plnotučné), řízeno capsmanem a ten roaming fungoval naprosto skvěle aniž bych cokoliv nastavoval. Prostě jsem s mobilem šel od sklepa až na půdu a bez výpadku se mě to přepojilo mezi 4 AP...

to je zásluha telefonu. Já s tím taky nemám problém.

Máš to tunelovaný nebo local forward?

Problem "asistovaneho" vykopavani je, ze je pak klient musi znovu provest 4way handshake, coz muze nejakou chvilku trvat - zejmena pri overovani pres radius. V podstate se tim eliminuji funkce 802.11r/v/k ale netusim jestli, nebo jak je ma Mikrotik naimplementovane.

Osobne bych snizil minimalni podporovane data rate APcek, tim padem se budou klienti prepojovat mnohem drive. - Tzn. uplne zakazat 1,2,5.5 a11 Mbps

Napriklad u Aruby pred asistovanym vykopavanim varuji.

Handoff Assist

The AP monitors the RSSI for every associated client. If the RSSI for a specific client falls below "low-rssi-threshold" and continues to fall for the "rssi-falloff-wait-time", then the AP will send a de-auth to the client.

The de-auth is meant to kick the client away from the current AP and get it to re-authenticate to a nearby AP. This will have the effect of helping a client handover between 2 APs.

BUT (Big But), if the client gets de-authed and takes a while to re-authenticate (if it even does re-authenticate automatically after a de-auth), then this will have the effect of destroying communication instead of helping it -- mostly found with legacy clients.

hapi píše:to je zásluha telefonu. Já s tím taky nemám problém.

Máš to tunelovaný nebo local forward?

obyc local forward

Salamander píše:Osobne bych snizil minimalni podporovane data rate APcek, tim padem se budou klienti prepojovat mnohem drive. - Tzn. uplne zakazat 1,2,5.5 a11 Mbps

Toto by mělo způsobit, že když přenosová rychlost klesne pod nastavenou úroveň, že to daného klienta odpojí od AP, nebo jaký je smysl této volby? Proč jsou ty rychlosti ve Winboxu uspořádané tak nějak napřeskáčku - 5,5, 11, 6, 9, 12Mbps?

Bčko se vynechává tak že se nastaví pouze G/N. Tím odpadnou ty spodní. Vynechávat 6 a 12 může způsobit nefunkčnost jednoduších IoT zařízení.

Kde jsou jinak uspořádaný? Nevidim na výběr 5.5 a 11.

To pořadí rychlostí, jak jsem to napsal, se mi zobrazuje v Capsmanovi když otevřu nějaký konfig nebo přímo interface, tak na záložce Rates pod volbou Supported rates - předpokládám, že o těch Salamander psal. Mě tam zaujalo, že to nejde po sobě, tedy od nejmenší k nejvyšší rychlosti.

Ještě mám dotaz, zda došlo k nějakým změnám při posledních aktualizacích u Capsmana co se týká logiky automatického nastavení kanálů. Zjistil jsem, že zatímco předtím mi dvě AP jeli někde kolem 8. kanálu (obě měli shodný kanál a bylo to bez problému) při 20 MHz šířce kanálu, tak po nějaké aktualizaci a rebootu routeru se automaticky změnily na 1. kanál (který je tady v místě celkem zarušený) a šířka kanálu se nastavila na 40 MHz. Je tato šířka kanálu vůbec vhodná do zarušeného centra města?

Tak nakonec jsem musel dát do konfigurace toto, abych Capsmanovi zatrhl ty 40Mhz kanály:


Zajímavé je, že následující příkaz s tím nic neudělal, byl zcela bez efektu:

to není zajímavý,

40MHz kanály přece neexistují. Existují pouze další kanály v násobcích takže 2x 20MHz což je těch tvých 40MHz a to je sakra rozdíl. Proto se to jmenuje extension channel jako že to přidává další 20MHz kanály. 160MHz je pak 8x20MHz. Všechno má 20MHz krát X. Pokud se v capsmanu nic nenastaví tak nastaví plnou palbu co zařízení podporuje tedy standardní šířku 20MHz na kanál a max počet dalších kanálů co zařízení podporuje.

To jsem nevěděl, že 40MHz kanál neexistuje, protože používám Wifi info view od Nirsoftu a tam to mají takto popsané. Navíc, co potom přímo v Mikrotiku znamená ta volba šířky kanálu 40MHz turbo, když takový kanál neexistuje?

turbo existuje pouze v 802.11a a na 802.11a kartách. Na Nkových a AC kartách takový režim není možný a navíc to není žádný standard a proto se k tomu připojí pouze jiný klienti kteří mají nastaveno 40MHz také. Pak se ale nepřipojí k 20MHz AP.

Proto existuje běžný 20MHz kanál který umí všichni. Jak 802.11a tak 802.11n, ac, ax. Pak se pouze rozšiřují funkce a počet přídavních kanálů atd.. ale vždy je základ 1x20MHz. Proto se může obyč klient 802.11a připojit na nejmoderenější AP s 802.11ax a bude fungovat. S turborežimem tohle nebylo možné.

Jo je blbý že většina výrobců ukazuje 40MHz a ne 2x 20MHz.