Zadání bylo poměrně jednoduché - zajistit bezdrátový přístup pro zhruba 400 lidí v jedné místnosti s tím, že někteří budou pravděpodobně používat více zařízení najednou. Můžeme očekávat, že hlavním provozem budou sociální sítě, program na webu konference a maily. Dále bude potřeba zajistit prioritní připojení pro “řídicí” pult a oddělenou wi-fi jen pro stánky.
Tento článek by měl sloužit především jako zhodnocení zvoleného technického řešení a jako základní návod, jak se s podobným problémem vypořádat a na co se vlastně připravit. Důvodem proč jsme tuto výzvu přijali, je naše nadšení pro pořádání podobných skvělých akcí a také to, že máme mnoho zkušeností s návrhem a budováním především větších korporátních sítí. Pustili jsme se tedy do plánování.
Pro zajištění kvalitního wi-fi připojení pro účastníky je potřeba mít splněné zejména 3 body:
- použít kvalitní přístupové body (AP - access-pointy)
- mít kvalitní a výkonný router
- zajistit kvalitní spojení do internetu (poskytovatel internetu)
Selhání i jediného bodu skončí katastrofou.
První otázka je, jak rychlou linku budeme potřebovat. Orientačně potřebujeme zhruba 100 kb/s na jednoho účastníka a cca 10-15% navíc, pokud je pravděpodobné, že budou aktivně používat více zařízení najednou. 100 kb/s se může zdát jako velmi málo, ale je potřeba uvědomit si, že po většinu času jej nebudou všichni používat v přesně ten samý okamžik. Pokud zajistíme rovnoměrné a férové přidělování pásma, tak by měla pro každého zůstat k dispozici dostatečná rychlost pro běžnou práci.
Pro 400 lidí s více zařízeními nám tedy vychází cca 44-46 Mb/s + něco navíc pro řídící pult a stánky - minimálně tedy 50 Mb/s.
Dále je potřeba vybrat vhodný router. Router bude síť připojovat do internetu - bude především provádět překlad vnitřních adres na vnější (NAT), řídit spravedlivé přidělování pásma, sloužit jako DHCP server pro přidělování adres a jako lokální DNS. V případě výkonu routeru je potřeba, aby byl schopen zpracovat určitý počet síťových packetů za vteřinu (pps - což je možná i zajímavější údaj než samotná rychlost). Z měření víme, že uživatel procházející sociální sítě generuje průměrně 50-200 pps. Bohužel toto je hodnota, kterou výrobci často neuvádí a velmi se liší dle toho, jaké funkcionality jsou na routeru zapnuté a kolik pravidel zpracovává - zde často záleží na hrubém výkonu procesoru routeru. Stanovili jsme si, že router by měl zvládat alespoň 40 000 pps při použití několika pravidel ve firewallu, NATu, značkování packetů a jejich rozdělování do několika front.
Výběr AP záleží především na dispozici prostor. Pokud se konference koná v několika oddělených místnostech, je situace poměrně jednoduchá - stačí rozmístit dostatečný počet AP tak, aby se vzájemně nerušily. V případě jedné velké místnosti, je situace složitější - v pásmu 2.4 GHz je možné použít maximálně 3-4 AP a je zabráno kompletně celé rádiové pásmo (kanály se překrývají). K jednomu běžnému AP lze běžně připojit maximálně cca 60-80 stanic (opět se počítá, že nebudou komunikovat všechny současně), ideální počet je však kolem 20. Bylo tedy jasné, že s 2.4 GHz rozhodně nevystačíme a bude potřeba využít i 5GHz pásmo, které však nepodporují všechna zařízení. Z dřívějších zkušeností jsme odhadovali, že by zhruba 20 % zařízení mohlo podporovat tuto frekvenci.
Vyšlo tedy, že bychom měli mít 4 AP v 2.4GHz a další 2 v 5GHz + 1 AP pro stánky v odděleném prostoru.
Protože v tomto případě není dosah bezdrátové sítě problémem, rozhodli jsme se použít modulární access point Xirrus XR-4000. Jedná se o zařízení, do kterého se vkládají moduly s jednotlivými access pointy - je tak potřeba pouze jediná “krabice”. Nechali jsme jej osadit 6 moduly - 4x běžný modul 802.11n, který umí pracovat buď v 2.4GHz nebo 5GHz, a 2x modul podporující i nejnovější normu 802.11ac v 5GHz. Toto řešení je určeno právě pro podobná využití s velkou hustotou stanic.
Jako router jsme vybrali Mikrotik RB2011, který máme běžně na skladě a víme, že poskytuje požadovanou funkcionalitu i výkon.
Pro wi-fi pro stánky jsme počítali s cca 10 uživateli. Proto jsme zvolili pouze malý Xclaim Xi-1 s cloudovým kontrolérem, který v nových verzích už velmi dobře funguje.
Jedinou věcí, kterou jsme neměli pod kontrolou, bylo samotné internetové připojení. Dle poskytovatele by připojení mělo požadovanou zátěž vydržet, ale upozornil nás, že to bude na hraně… Protože to nebylo jisté, rozhodli jsme se na routeru učinit několik dalších nastavení, která by měla lince trochu pomoci. V kompletní konfiguraci routeru jsme počítali v základu s následujícím, s tím, že ji doladíme podle reálných potřeb:
- 40 Mb/s spravedlivě rozdělovaných mezi všechny účastníky pomocí funkcionality PCQ (pokud by komunikovala jedna stanice, dostane celé pásmo, 2 stanice po 20Mb/s ... 400 stanic po 100kb/s)
- 4 Mb/s vyhrazených na přístup na webové stránky konference, Twitter a Slido
- 4 Mb/s vyhrazených pro řídicí pult a stánky s oddělenou sítí
- lokální cachující DNS server, aby nebylo potřeba pro překlad doménových jmen tolik komunikovat do internetu
- zákaz P2P sítí
- transparentní cachující HTTP proxy server - opět z důvodu, aby se některé zdroje z internetu stahovaly pouze lokálně (obrázky, javascriptové knihovny, ...)
- hotspot se “splash screen” s přihlašovacím portálem s programem konference a odkazy na nejdůležitější zdroje - aby pro tyto informace nebylo potřeba jít na internet
- další výhodou hotspotu je i blokace neaktivních zařízení - telefon pohozený v kapse, který je na wi-fi připojen a nebyla na něm otevřena webová stránka hotspotu, nemůže komunikovat do internetu
Další omezení jsme nastavili přímo na AP, kde jsme limitovali propustnost na maximálně 2 Mb/s pro každou stanici - tento limit měl být složen z pásma férově rozdělovaného podle počtu uživatelů a možnosti prioritního přístupu na vybrané služby. Byl také zakázán provoz mezi jednotlivými stanicemi, a to jak z důvodu bezpečnosti, tak pro eliminaci zbytečného provozu v síti.
Takový byl tedy plán.
Realita však byla trochu odlišná.
Večer před konferencí jsme provedli měření reálné propustnosti internetového připojení, které bylo realizováno pojítkem v nelicencovaném pásmu 5GHz z nedalekého hotelu. Nástroj iperf nám ukazoval cca 30-32 Mb/s. To bylo o dost méně než požadované minimum. Bohužel s tím nešlo moc udělat… Na tyto hodnoty jsme tedy nastavili nové rozdělování provozu a doufali, že to bude fungovat alespoň trochu použitelně. Problémem také byly další rušivé sítě z přilehlého nákupního centra. Nejsilnější vysílala na kanálu 1 a mohla způsobovat komplikace. Rozhodli jsme tedy o použití pouze 3 AP v pásmu 2.4GHz na kanálech 5,9 a 13 - tak, aby docházelo k minimálnímu překryvu. Uvolněný AP modul jsme prozatím využili k analýze rádiového spektra.
V den konference jsme hned po příchodu několika účastníků narazili na další problém. V tomto případě se jednalo o hotspot. Mobilní zařízení správně po připojení do sítě ukázala “přihlašovací” stránku se základními informacemi a následně byl přístup k internetu plně funkční. Notebooky však samy uvítací stránku nezobrazily a bylo potřeba, aby návštěvník otevřel v prohlížeči libovolnou stránku na protokolu HTTP - tím byl automaticky přesměrován na náš portál. Problém nastal v případě, když měl návštěvník nastavenou domovskou stránku na protokolu HTTPS - v tomto případě nedošlo k automatickému přesměrování, jelikož nelze s platným certifikátem upravit šifrovaný provoz. Internet mu proto nefungoval, dokud se nepokusil otevřít nešifrovanou stránku, což pro většinu návštěvníků nebylo zřejmé. Z tohoto důvodu jsme po pár minutách funkci hotspotu s přihlašovacím portálem vypnuli.
Během dopoledne jsme měli opravdu velké problémy s konektivitou, propustnost linky nám klesla na cca 4 Mb/s, což je pro 400 lidí opravdu velmi málo. Zároveň v této chvíli došlo i k několika kompletním výpadkům linky, čehož důsledkem byl při úplné ztrátě spojení restart AP. Museli jsme žádat poskytovatele linky o přeladění. Kolem oběda se tak situace zlepšila, ale dosahovali jsme pouze rychlostí mezi 10 Mb/s - 20 Mb/s a s tím jsme se bohužel nedokázali pořádně poprat. Kolísání rychlosti byl velký problém, protože tak nebylo možné dobře použít férové přidělování pásma pomocí PCQ, u kterého je třeba znát maximální rychlost.
Nekvalitní připojení mělo další důsledek: mnoho návštěvníků začalo využívat osobní wi-fi hotspoty z mobilních telefonů, čímž zarušili pásmo pro své sousedy, takže ani samotné připojení k našemu AP nebylo pro někoho jednoduché. Omezit funkčnost těchto osobních hotspotů by nám umožnilo použití funkce Rogue AP Detection, to bychom si však dovolili pouze v případě, že by námi nabízená síť fungovala bezchybně...
Pro druhý den konference jsme se rozhodli pro jiný, drastičtější typ omezování - už na AP jsme limitovali pásmo pro každou stanici v intervalu 200 - 500 kb/s podle aktuálního počtu připojených zařízení a stavu linky. To mělo za následek mnohem pomalejší připojení pro účastníky, ale přineslo větší stabilitu, především pro prioritizované sítě a služby. Dalším důvodem zlepšení bylo i to, že mnoho uživatelů používání wi-fi jednoduše vzdalo a využívalo mobilní internet - první den jsme měli připojeno průměrně zhruba 240 zařízení a druhý pouze cca 170. Také jsme zjistili, že 5GHz podporuje mnohem více zařízení, než jsme očekávali: zhruba 40 % stanic si vybralo připojení právě přes tuto frekvenci. AP pro monitoring spektra jsme proto překonfigurovali na další AP v pásmu 5GHz. Linkou se nám tento den dařilo protlačovat stabilně kolem 8 Mb/s se špičkami k 25 Mb/s.
ESS16 wi-fi v číslech (v relaci k více než 400 účastníkům):
- maximální počet najednou připojených zařízení: 320
- běžný počet najednou připojených zařízení: 200
- běžný počet najednou komunikujících zařízení: 90
- běžný počet najednou navázaných spojení: 9000
- běžný počet packetů za vteřinu: 2000 pps
- běžný generovaný datový tok (bez špiček a omezeno rychlostí linky): 8 Mb/s
- špičky, když řečník ukázal zajímavý odkaz (omezeno rychlostí linky): 22 Mb/s
- stažená data za 2 dny konference: 88 GB
- počet různých zařízení, která se alespoň jednou připojila na 5GHz: 160
- velikost dat načtených z lokální proxy cache: 800 MB
- běžné vytížení procesoru routeru: 30 %
- běžné využití RAM routeru s PCQ: 100 MB
- běžné využití RAM routeru bez PCQ: 35 MB
- délka natažené kabeláže: 200 m
Složení provozu (data z hodinového měření - konec přednášky, přestávka, začátek další přednášky):
Co se osvědčilo:
- lokální cachující DNS server
- omezování provozu už na straně AP
- férové rozdělování provozu pomocí PCQ, v případě známé, stabilní a dostatečné rychlosti linky (což však bylo jen minimum času)
- izolace klientů
- alespoň základní blokace P2P (byly zablokovány desítky pokusů)
- blokace Windows update (to jsme zjistili až v průběhu konference)
Co bylo zbytečné:
- lokální proxy server - velká část komunikace je šifrovaná (tvořily ji především přístupy na sociální sítě) a nelze tak cachovat, aby anonymní návštěvník nic nepoznal a nemusel nic nastavovat
Co se neosvědčilo:
- HTTP hotspot s přihlašovacím portálem (problémy s přihlášením z některých zařízení)
Co bychom dále zlepšili:
- více AP v 5GHz - pokud cílová skupina používám moderní zařízení, je podpora této frekvence velmi dobrá
- pokusit se zařídit garantovanou konektivitu
Víme, že kvalita připojení z pohledu návštěvníka nebyla dobrá a změny k lepšímu nastaly pouze díky poměrně drastickému omezování uživatelů a soustavnému vyhodnocování aktuálního stavu. Nicméně jsme získali alespoň užitečná data, která snad pomohou dalším konferencím. Držte palce ;-).
Akce samotná byla skvělá a těšíme se na další ročník!
Díky za pro mě velmi zajímavý článek. Zaujala mě zmínka o využití "Rogue AP Detection", tato funkce se dá použít i pro omezení uživatelských AP (např. sw access point na mobilu)?