Egy SSID két frekvencián, hogyan lépjünk túl a roaming problémán 4 comments


Frissítettem pár hete az itthoni hálózatomat: kidobtam a régi TP-LINK AP-t (a router már régóta Cisco volt, egy régi 1841-est használok) és beizzítottam helyette a CCNA Wireless laborozásra vásárolt AIR1242-t. Meg amúgy is a suszter cipője, nehogy már TP-LINK legyen itthon… 🙂

Csak 802.11a/b/g-t tud szegény AP de nekem ez is elég (a 1841-es router eleve szűk keresztmetszet az internet felé mert 35 Mbps körül tud továbbítani, (W)LAN-on belüli forgalom pedig nem nagyon van itthon, ezért az 54 Mbps WiFi korlát nem zavar).

Mivel elég sok Skype/Webex megy munka közben ezért meg kellett szabadulnom a 2.4 GHz frekvenciától és mindenképpen 5 GHz-en akartam használni a WiFi-t amelyik kliensen csak tudom hogy élvezhessem a kiristálytiszta kép- és hangminőséget (kivéve ha recsegős Aliexpress-es mikrofonnal csatlakozik be valaki a konfba). Ha rendben van a WiFi kapcsolatom akkor mi baj lehet, minden másra ott a routeren a QoS (és a Mastercard).

Hogy miért tűztem ki vérdíjat a 2.4 GHz-re?

Nagyon leegyszerűsítve: mint tudjuk ezen a frekvencián három (bizonyos esetekben négy) darab egymást nem zavaró csatorna van, ami egy társasházban nagy zavart okoz a (tér)erőben. Igazából az 1,6,11 csatornákra kellene konfigurálni az AP-kat, bizonyos esetekben az 1,5,9,13 is szóba jöhet, de a CH13-t sok kliens nem szereti, volt már ilyen ticketem pár éve mikor a TP-LINK azt nézte ki magának (és sajnos Prio 0 volt mert az asszony nyitotta, SLA: 5 perc). Anno a CCIE labor felkészülés alatt hányszor volt az ISP a hibás pedig csak én konfiguráltam el a routeren valamit 🙂 … “reload in 1”, konfig beüt, SSH kifagy, router reboot, és mindig az ISP-re fogtam hogy nincs net 🙂 . Jó mondjuk mikor MP-BGP, Multicast, IPv6 meg ZBFW is volt itthon azért az durva volt.

Nálunk pl. így néz ki jelenleg a WiFi “térkép”, szörnyű. Láthatjuk hogy “Huginet” beült a CH9-re, így garantáltan boldogságot okoz a CH6 és CH11 csatornákon üzemelő WiFi hálózatoknak, van közös metszetük bőven. CH11-en az én “legacy” 2.4 GHz-es cuccom van de mivel alig van használva ezért nem izgat HugiNet piszkos akciója. HPeti sem tudhat stabil kapcsolatot magának mert szintén az 1-es csatornát szemelte ki magának egy másik AP, szóval verekedhetnek a levegőért 🙂 . Közben meg fizeti a drága netet ami valószínűleg este csúcsidőben a legrosszabb (mikor máskor, collision csúcsjáratás), ha esetleg olvasol keress meg és megoldjuk a problémát 🙂

Az “access_denied_2.4 GHz” SSID az enyém (és az “access_denied_guest” is – nehogy már a vendég kliensek a belső hálózatomra csatlakozzanak  🙂 . Régebben VRF-be voltak pakolva, most már csak ACL-lel tiltom őket, KISS elv)

 

 

Ott van még a bluetooth eszközök zavaró hatása, szeret a teljes spectrumon ugrálva kommunikálni, ami okozhat problémát főleg “discovery” fázisban. A vezeték nélküli fülhallgatók ugyebár…

 

 

Ha pedig a mikrohullámú sütő ha be van kapcsolva akkor is boldogság önti el a WiFi klienseim szívét… Vagyis TCP retransmission for president, ha meg UDP forgalom van akkor szaggat a youtube-ról az aktuális Armin van Buuren – A State of Trance epizódból a hang/video – ne mááár 🙂 . Akkor már inkább eszem hidegen az ebédet minthogy packet loss legyen. 🙂

 

 

Azt sajnos nem tehettem meg hogy a 2.4 GHz-et teljesen kikapcsolom mert vannak itthon olyan kliensek (Apple Watch, Nokia Body+ okosmérleg) amely csak 2.4 GHz-et tud. Botrány hogy még gyártanak ilyeneket.

Na szóval eredetileg azt gondoltam hogy csinálok egy SSID-t és kiszórom a 2.4 GHz (Dot11Radio0) és az 5 GHz (Dot11Radio1) rádiókon aztán jó napot Pista bácsi.

Ennek az AP-n ilyen konfigurációja volt:

dot11 ssid access_denied
vlan 100
authentication open
authentication key-management wpa version 2
mbssid guest-mode
wpa-psk ascii 7 XXXXXXXXXXXXXXXXXXXX
!
interface Dot11Radio0
!
encryption vlan 100 mode ciphers aes-ccm
!
ssid access_denied
!
!
!
interface Dot11Radio0.100
encapsulation dot1Q 100
no ip route-cache
bridge-group 100
bridge-group 100 subscriber-loop-control
bridge-group 100 block-unknown-source
no bridge-group 100 source-learning
no bridge-group 100 unicast-flooding
bridge-group 100 spanning-disabled
!
!
interface Dot11Radio1
!
encryption vlan 100 mode ciphers aes-ccm
!
ssid access_denied
!
!
interface Dot11Radio1.100
encapsulation dot1Q 100
no ip route-cache
bridge-group 100
bridge-group 100 subscriber-loop-control
bridge-group 100 block-unknown-source
no bridge-group 100 source-learning
no bridge-group 100 unicast-flooding
bridge-group 100 spanning-disabled
!
!
interface FastEthernet0.100
encapsulation dot1Q 100
no ip route-cache
bridge-group 100
no bridge-group 100 source-learning
bridge-group 100 spanning-disabled
!

 

Fel is tudtam csatlakozni, működött szépen de azt vettem észre hogy a notebook időnként visszaáll 2.4 GHz-re. Ennek megértéséhez meg kell vizsgálnunk a kliensek viselkedését, infrastruktúra oldalról nem lehet mindent megoldani (sajnos). Annyira jó hálózatokat lehetne csinálni ha nem lennének rajtuk kliensek. 🙂

 

Windows 10

Elvileg az 5 GHz a preferált, ezt be is lehet állítani hogy tuti fix legyen. Ennek ellenére (!) gondolt sokszor egyet és visszament a 2.4 GHz-re (gondolom az IOS-nél is jelen lévő RSSI kritérium miatt, lásd alább). Mi lenne ha nem lehetne preferálni hogy 5 GHz-re csatlakozzon?!

 

 

IOS

Szintén az 5 GHz a preferált, ezekkel az eszközökkel nem is volt gond, maradtak stabilan 5 GHz-en. Annyi pénzért amennyibe kerülnek mondjuk elvárható 🙂 . Imádom a képen a kendővel betakart kijelzőjű iPhone-t.

 

 

Ez eddig oké. Viszont nem hagyhatjuk figyelmen kívül a fizika törvényeit: a 2.4 GHz jele messzebbre terjed mint az 5 GHz-é. Ezért előfordulhat hogy a kliens átáll 2.4 GHz-re mert bizonyos távolságra az AP-tól annak erősebb a RSSI-je. Lásd alábbi kép (2.4 GHz: 400 feet, 5 GHz csak 268, a szürke zónáról nem is beszélve)

 

 

Az alábbi dia az IOS romaingról szól:

 

 

A CiscoLive! fóliák a “WiFi God”, Jerome Henry előadásából származnak (akit bővebben érdekel: “Optimize your WLANs for iPhones and iPads (and welcome other mobile devices too) – BRKEWN-2003”).

A fenti okok (“Expect frequent 5 GHz -> 2.4 GHz roams”) miatt a legtöbben azt javasolták hogy érdemes két SSID-t csinálni, ezzel megelőzhetjük a problémát. Így tettem én is: felrántottam egy új VLAN-t, hozzádobtam az új SSID-t és új subnetet csináltam a routeren. Szeretem ha az SSID-k külön subnetben vannak, áttekinthetőbb számomra.

Ja és 5 GHz-en ezt mutatja a Spectrum Analyzer 🙂 . Szárazabb tisztább érzés. Az én AP-m a király a társasház 5 GHz-es univerzumában.

 


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

4 thoughts on “Egy SSID két frekvencián, hogyan lépjünk túl a roaming problémán

  • Cs. Dávid

    SLA: 5 perc 🙂 Következő lépésként WiFi Jammert kell építeni vagy rouge ap-nak kell minősíteni a szomszédokat 😀
    Jó lett a cikk, több hasonló tartalmat!

    • Kuris Ferenc Post author

      Ne mondd hogy nem volt még otthon olyan hogy este rád nézett az asszony és csak ennyit szólt: “nincs net”. És hozzá a gyilkos tekintet 🙂

  • IDSx

    Cisco APkon a band steering messze a legjobban működik, volt egy HD tesztünk (~90 kliens, mindenféle vegyesen), a Cisco AP-i tényleg a csak 2.4-es klienseket hagyták 2.4-n. (Persze a környezethez igazítva a band steering tresholdok)

    wifi témákban rengeteg dolog a kliensre vezethető vissza – nálunk a cégnél fel van írva, melyik Intel/Qualcomm chipsethez melyik a jó driver verzió, ami stabil az itteni wifi környezettel. 😀 érdemes még játszani a data ratekkel/MCS-kkel is.

    Otthon én is próbáltam kiírtani a 2.4 Ghz-t (a 4 éves, alap samsung smarttv is már tudja az 5 Ghz-t), kértem dualbandes céges mobilt…végül a Garmin sportóra miatt bukott meg a kísérlet, szégyen, hogy 600 eurós smart eszközbe csak 2.4-es chipet raknak.