Пользователь
0,0
рейтинг
1 июля 2013 в 16:09

Разработка → Бесшовный роуминг Wi-Fi

Начальник позвал в переговорку, сказал захватить с собой ноутбук. Вроде бы ничего — и там, и на рабочем месте у нас офисная беспроводная сеть. Приходим — а загрузка поставленного на скачивание большого файла оборвалась, SSH-сессии закрылись, заботливо набранная веб-форма при отправке почему-то сбросилась. Знакомо?
Сегодня мы поговорим о бесшовном роуминге устройств в беспроводных сетях Wi-Fi.


Роумингом называется процесс переподключения устройства к беспроводной сети при перемещении его в пространстве. Принимаемая мощность радиосигнала ослабевает с расстоянием до передатчика, в результате чего падает эффективная скорость передачи информации, растут канальные ошибки вплоть до обрыва беспроводного соединения. При наличии в радио-сети с одним именем (SSID) более чем одной точки доступа перемещение мобильного абонента из зоны уверенной работы в пределах первой точки доступа в зону, где сигнал от второй точки доступа качественнее (выше мощность, больше отношение сигнал/шум) может произойти такое переподключение.

Решение об осуществлении переподключения всегда принимает клиентское устройство (драйвер Wi-Fi адаптера). Точка доступа может только «подсказать» устройству о желательности данного действия. Иногда можно указать в настройках драйвера параметр «агрессивности» принятия решения. Однако при первоначальном подключении абонента централизованно управляемая система может «заставить» абонента подключиться к предпочтительной (с точки зрения загрузки) точке, и на желаемом канале/диапазоне.

Бесшовным называют такой механизм роуминга, при котором потери передаваемых данных, возникающие в момент переключения с точки на точку, минимальны либо равны нулю, а стек TCP/IP клиентской операционной системы даже не замечает факт переключения. Такой механизм важен при эксплуатации чувствительных к задержкам и потерям приложений, таких как передача голоса по радио-сети (Voice over Wireless), потокового видео, больших объемов данных и вообще всех случаев, где протокол TCP не в состоянии «переварить» временное пропадание канала передачи данных.

Мы поставим эксперименты и подсмотрим за процессом бесшовного роуминга, реализованного средствами централизованно управляемой беспроводной сети, построенной на оборудовании Juniper Wireless, о котором шла речь во вводной статье. Это система корпоративного класса, специально спроектированная для решения задач обеспечения бесшовного роуминга. Затем мы «сломаем» бесшовность и продемонстрируем, к чему это приводит и какого поведения можно ожидать от устройств «бытового класса».

В нашей сети будет обычный Windows7 ноутбук со встроенной карточкой Intel WifiLink 5100abg, два контроллера беспроводных сетей Juniper MX8 в одном сегменте ЛВС, две точки доступа WLA532, каждая настроена на свой контроллер. Трафик до ноутбука будем создавать с Linux-сервера утилитой ping -f -s 1000 либо ping -s 100 -i 0.05. Тот же ноутбук будет заниматься анализом спектра (Wi-Spy DBx/Channelyzer Pro) и захватом 802.11 кадров (OmniWiFi/OmniPeek).



Для авторизации абонентов (правильно, WPA2 Enterprise) по механизму 802.1x поднимем FreeRADIUS-сервер и настроем его на PEAP/MSChapV2. При этом мы сможем наблюдать за потоком трафика «беспроводный контроллер — RADIUS-сервер» при запуске последнего через freeradius -X и отслеживать события полной авторизации и передачи сообщений аккаунтинга. В качестве локальной базы пользователей — текстовый файл с паролями.
Настройки контроллеров для авторизации в нашей сети "DOT1X" идентичны и просты:

set service-profile Secure-DOT1X ssid-name DOT1X
set service-profile Secure-DOT1X 11n short-guard-interval disable
set service-profile Secure-DOT1X rsn-ie cipher-ccmp enable
set service-profile Secure-DOT1X rsn-ie enable
set service-profile Secure-DOT1X attr vlan-name default
set radius server debian64 address 172.16.130.13 timeout 5 retransmit 3 deadtime 5 encrypted-key 0832494d1b1c11
set radius server debian64 mac-addr-format colons
set server group debian64-group members debian64
set accounting dot1x ssid DOT1X ** start-stop debian64-group
set authentication dot1x ssid DOT1X ** pass-through debian64-group
set radio-profile default service-profile Secure-DOT1X
Полный конфиг первого контроллера
# Configuration nvgen'd at 2013-6-28 22:18:27
# Image 8.0.2.2.0
# Model MX-8
# Last change occurred at 2013-6-28 19:56:52
set ip route default 172.16.130.1 1
set ip dns enable
set ip dns server 8.8.8.8 PRIMARY
set log server 172.16.130.100 severity error
set system name WLC-1
set system ip-address 172.16.130.30
set system countrycode RU
set timezone MSK 4 0
set service-profile Secure-DOT1X ssid-name DOT1X
set service-profile Secure-DOT1X 11n short-guard-interval disable
set service-profile Secure-DOT1X rsn-ie cipher-ccmp enable
set service-profile Secure-DOT1X rsn-ie enable
set service-profile Secure-DOT1X attr vlan-name default
set radius server debian64 address 172.16.130.13 timeout 5 retransmit 3 deadtime 5 encrypted-key 0832494d1b1c11
set radius server debian64 mac-addr-format colons
set server group debian64-group members debian64
set enablepass password…
set accounting dot1x ssid DOT1X ** start-stop debian64-group
set authentication dot1x ssid DOT1X ** pass-through debian64-group
set user anton password encrypted…
set radio-profile default 11n channel-width-na 20MHz
set radio-profile default service-profile Secure-DOT1X
set ap auto mode enable
set ap 2 serial-id mg0211508096 model WLA532-WW
set ap 2 name WLA-2
set ap 2 blink enable
set ap 2 fingerprint 1a:fb:2e:d2:ab:e0:59:87:a7:3c:2a:20:ec:2a:9b:cc
set ap 2 time-out 900
set ap 2 remote-ap wan-outage mode enable
set ap 2 remote-ap wan-outage extended-timeout 10h
set ap 2 radio 1 tx-power 5 mode enable
set ap 2 radio 2 mode disable
set ap 2 local-switching mode enable vlan-profile default
set ap 5 port 5 model WLA532-WW
set ap 5 radio 1 tx-power 5 mode enable
set ap 5 radio 2 mode disable
set ip snmp server enable
set port poe 5 enable
set snmp protocol v1 disable
set snmp protocol v2c enable
set vlan 1 port 1
set vlan 1 port 2
set vlan 1 port 3
set vlan 1 port 4
set vlan 1 port 6
set vlan 1 port 7
set vlan 1 port 8
set interface 1 ip 172.16.130.30 255.255.255.0
set snmp community name CommunityRO access read-only
set mobility-domain mode seed domain-name LocalMobilityDomain
set mobility-domain member 172.16.130.31
Полный конфиг второго контроллера
# Configuration nvgen'd at 2013-6-28 18:05:38
# Image 8.0.2.2.0
# Model MX-8
# Last change occurred at 2013-6-28 17:56:28
set ip route default 172.16.130.1 1
set system name WLC-2
set system ip-address 172.16.130.31
set system idle-timeout 0
set system countrycode RU
set service-profile Secure-DOT1X ssid-name DOT1X
set service-profile Secure-DOT1X 11n short-guard-interval disable
set service-profile Secure-DOT1X rsn-ie cipher-ccmp enable
set service-profile Secure-DOT1X rsn-ie enable
set service-profile Secure-DOT1X attr vlan-name default
set radius server debian64 address 172.16.130.13 timeout 5 retransmit 3 deadtime 5 encrypted-key 0832494d1b1c11
set radius server debian64 mac-addr-format colons
set server group debian64-group members debian64
set enablepass password…
set accounting dot1x ssid DOT1X ** start-stop debian64-group
set authentication dot1x ssid DOT1X ** pass-through debian64-group
set user anton password encrypted…
set radio-profile default wmm-powersave enable
set radio-profile default 11n channel-width-na 20MHz
set radio-profile default service-profile Secure-DOT1X
set ap auto mode disable
set ap auto blink enable
set ap 2 serial-id mg0211508096 model WLA532-WW
set ap 2 name WLA-2
set ap 2 fingerprint 1a:fb:2e:d2:ab:e0:59:87:a7:3c:2a:20:ec:2a:9b:cc
set ap 2 time-out 900
set ap 2 remote-ap wan-outage mode enable
set ap 2 remote-ap wan-outage extended-timeout 10h
set ap 2 radio 1 channel 11 tx-power 5 mode enable
set ap 2 radio 2 mode disable
set ap 2 local-switching mode enable vlan-profile default
set load-balancing mode disable
set port poe 5 enable
set port poe 6 enable
set vlan 1 port 1
set vlan 1 port 2
set vlan 1 port 3
set vlan 1 port 4
set vlan 1 port 5
set vlan 1 port 7
set vlan 1 port 8
set interface 1 ip 172.16.130.31 255.255.255.0
set mobility-domain mode member seed-ip 172.16.130.30
set security acl name portalacl permit udp 0.0.0.0 255.255.255.255 eq 68 0.0.0.0 255.255.255.255 eq 67
set security acl name portalacl deny 0.0.0.0 255.255.255.255 capture
commit security acl portalacl

Расположим ноутбук так, чтобы принимаемый им сигнал от обеих точек доступа (на 6 и 11 каналах диапазона b/g, 2.4 ГГц) был примерно одинаковым, подключимся к сети, запустим пинг, посмотрим на распределение энергии в эфире:



Для проверки работоспособности роуминга необходимо, чтобы ноутбук стал получать от точки доступа, с которой он в настоящий ассоциирован, сигнал существенно худший, чем от другой точки с тем же SSID и настройками шифрования. Можно переносить ноутбук, но мне было так не удобно, поэтому я носил одну из точек доступа (на длинном Ethernet кабеле) поближе либо за бетонный угол, а сигнал второй ослаблял, накрывая её тремя вложенными стальными кастрюлями, как матрешку. Каждая кастрюля давала ослабление в 3-4 dB. В результате в какой-то момент времени клиент «соскакивал» на другую точку доступа:



При этом анализ пакетов в эфире показывает такую картину (для того, чтобы OmniPeek мог видеть весь трафик, мне пришлось повторить все эксперименты с точками, жестко завязанными на 11й канал, иначе при сканировании по {6,11} я бы потерял самое интересное).
Ноутбук пытается найти более предпочтительную точку доступа (probe request, фрейм 79086), и получает ответы от обоих, с уровнем сигнала 23% (текущая) и 63% (кандидат).
Последний полезный кадр 79103 передан до сервера через ap2, после чего кадрами 79122-79136 произведено быстрое переключение на ap1, включая авторизацию, реассоциацию, обмен EAPOL.



В запросе на реассоциацию в кадре 79126 содержится ключ PMKID (Pairwise Master Key), который определяет, грубо говоря, идентификатор данной беспроводной сессии. Если точки доступа работают коллективно (под управлением одного контроллера, либо контроллеры общаются между собой), «новая» точка доступа проверяет полученный идентификатор по своим таблицам и, если таковой найден, пропускает этап авторизации и тут же разрешает обмен данными.



В нашем случае первый полезный кадр 79138 через новую точку доступа, ap1, пошел через 90 миллисекунд после последнего через старую. RADIUS-сервер получил только промежуточное сообщение аккаунтинга от точки, которую оставили в покое:
rad_recv: Accounting-Request packet from host 172.16.130.30 port 20000, id=143, length=264
Подробнее
Acct-Status-Type = Interim-Update
Acct-Multi-Session-Id = «SESS-30-d44e4b-437681-7f4d10»
Acct-Session-Id = «SESS-30-d44e4b-437681-7f4d10»
User-Name = «test»
Event-Timestamp = «Jun 28 2013 20:56:42 MSK»
Trapeze-VLAN-Name = «default»
Calling-Station-Id = «00-21-5D-C8-06-8A»
NAS-Port-Id = «AP5/1»
Called-Station-Id = «78-19-F7-7C-6A-40:DOT1X»
Trapeze-Attr-19 = 0x77696e646f777337
Trapeze-Attr-21 = 0x77696e646f7773
NAS-Port = 33
Framed-IP-Address = 172.16.130.128
Acct-Session-Time = 921
Acct-Output-Octets = 246429867
Acct-Input-Octets = 238261281
Acct-Output-Packets = 232900
Acct-Input-Packets = 247341
NAS-Port-Type = Wireless-802.11
NAS-IP-Address = 172.16.130.30
NAS-Identifier = «Trapeze»
Acct-Delay-Time = 0
# Executing section preacct from file /etc/freeradius/sites-enabled/default
+- entering group preacct {...}
++[preprocess] returns ok
[acct_unique] Hashing 'NAS-Port = 33,Client-IP-Address = 172.16.130.30,NAS-IP-Address = 172.16.130.30,Acct-Session-Id = «SESS-30-d44e4b-437681-7f4d10»,User-Name = «test»'
[acct_unique] Acct-Unique-Session-ID = «c1a67d40e7b54bea».
++[acct_unique] returns ok
[suffix] No '@' in User-Name = «test», looking up realm NULL
[suffix] No such realm «NULL»
++[suffix] returns noop
++[files] returns noop
# Executing section accounting from file /etc/freeradius/sites-enabled/default
+- entering group accounting {...}
[detail] expand: /var/log/freeradius/radacct/%{Client-IP-Address}/detail-%Y%m%d -> /var/log/freeradius/radacct/172.16.130.30/detail-20130628
[detail] /var/log/freeradius/radacct/%{Client-IP-Address}/detail-%Y%m%d expands to /var/log/freeradius/radacct/172.16.130.30/detail-20130628
[detail] expand: %t -> Fri Jun 28 20:56:16 2013
++[detail] returns ok
++[unix] returns noop
[radutmp] expand: /var/log/freeradius/radutmp -> /var/log/freeradius/radutmp
[radutmp] expand: %{User-Name} -> test
++[radutmp] returns ok
++[exec] returns noop
[attr_filter.accounting_response] expand: %{User-Name} -> test
attr_filter: Matched entry DEFAULT at line 12
++[attr_filter.accounting_response] returns updated
Sending Accounting-Response of id 143 to 172.16.130.30 port 20000
Finished request 269.

Всё это работало так быстро только потому, что обе точки доступа (вернее, обслуживающие их контроллеры) имеют общую базу подключенных активных клиентских устройств. Для этого контроллеры объединены в «группу мобильности». Выбирается имя, задается начальный «кандидат на роль главного»:

WLA-1:
set mobility-domain mode seed domain-name LocalMobilityDomain
set mobility-domain member 172.16.130.31

WLA-2:
set mobility-domain mode member seed-ip 172.16.130.30

Пример функционирующей группы мобильности:
WLC-1# show mobility-domain 
Mobility Domain name:  LocalMobilityDomain
Flags: u = up[2], d/e = down/config error[0], c = cluster enabled[0],
       p = primary seed, s = secondary seed (S = cluster preempt mode enabled),
       a = mobility domain active seed, A = cluster active seed (if different),
       m = member, y = syncing, w = waiting to sync, n = sync completed,
       f = sync failed 
Member: * = switch behind NAT
Member            Flags  Model     Version     NoAPs  APCap
----------------  -----  --------  ----------  -----  -----
172.16.130.30     upa--  MX-8      8.0.2.2         1     12
172.16.130.31     um---  MX-8      8.0.2.2         1     12


При роуминге абонентов между точками доступа контроллеры обмениваются контекстом абонента, включая историю его перемещений:

Roaming history:
  Switch          AP/Radio     Association time  Duration
  --------------- -----------  ----------------- -------------------
 *172.16.130.30   5/1          06/28/13 22:12:22 00:06:34            
  172.16.130.31   2/1          06/28/13 21:57:28 00:14:54            
  172.16.130.30   5/1          06/28/13 22:08:56                     
Детали полностью
WLC-1# sh sessions network verbose

1 sessions total

Name: test
Session ID: 42
Global ID: SESS-41-d44e4b-442936-c9f222
Login type: dot1x
SSID: DOT1X
IP: 172.16.130.128
MAC: 00:21:5d:c8:06:8a
AP/Radio: 5/1 (Port 5)
State: ACTIVE
Session tag: 1
Host name: Cartman
Vlan name: default (AAA)
Device type: windows7 (AAA)
Device group: windows (AAA)
Up time: 00:09:59

Roaming history:
Switch AP/Radio Association time Duration
— — — — *172.16.130.30 5/1 06/28/13 22:12:22 00:06:34
172.16.130.31 2/1 06/28/13 21:57:28 00:14:54
172.16.130.30 5/1 06/28/13 22:08:56

Session Start: Fri Jun 28 22:08:57 2013 MSK
Last Auth Time: Fri Jun 28 22:08:57 2013 MSK
Last Activity: Fri Jun 28 22:18:56 2013 MSK ( <15s ago)
Session Timeout: 0
Idle Time-To-Live: 179
EAP Method: PASSTHRU, using server 172.16.130.13
Protocol: 802.11 WMM
Session CAC: disabled
Stats age: 0 seconds
Radio type: 802.11g
Last packet rate: 54.0 Mb/s
Last packet RSSI: -52 dBm
Last packet SNR: 43
Power Save: disabled
Voice Queue: IDLE

Packets Bytes
— — Rx Unicast 44824 21023372
Rx Multicast 249 31159
Rx Encrypt Err 0 0
Tx Unicast 22615 7289459
Rx peak A-MSDU 0 0
Rx peak A-MPDU 0 0
Tx peak A-MSDU 0 0
Tx peak A-MPDU 0 0

Queue Tx Packets Tx Dropped Re-Transmit Rx Dropped
— — — — — Background 17015 0 1641 0
BestEffort 5745 0 495 0
Video 0 0 0 0
Voice 11 0 1 0

11n Capabilities:
Max Rx A-MSDU size: 0K
Max Rx A-MPDU size: 0K
Max Channel Width: 20MHz
SM power save: none
TxBeamformer: All
TxBeamformee: NonComp-Unknown, Comp-Unknown



Теперь самое время промоделировать типичный офисный случай, когда точки доступа предоставляют одну сеть, но друг о друге не знают. Ломать-не строить: уберем на одном из контроллеров членство в группе мобильности (clear mobility-domain mode member). Аналогично вызванное событие роуминга приводит к более серьезным последствиям:



Хоть в сообщении реассоциации (27818) клиент и передают верный PMKID, новая точка доступа подтверждает ассоциацию (27820) и тут же запрашивает полную повторную авторизацию по 802.1 (EAP, 27823). Это приводит к длинной цепочке событий, включая отправку сообщений деассоциции «старой» точке доступа (27887) и
Полный цикл авторизации на RADIUS-сервере
rad_recv: Access-Request packet from host 172.16.130.31 port 20000, id=132, length=139
NAS-Port-Id = «AP2/1»
Calling-Station-Id = «00-21-5D-C8-06-8A»
Called-Station-Id = «78-19-F7-75-5F-80:DOT1X»
Service-Type = Framed-User
EAP-Message = 0x020100090174657374
User-Name = «test»
NAS-Port = 19
NAS-Port-Type = Wireless-802.11
NAS-IP-Address = 172.16.130.31
NAS-Identifier = «Trapeze»
Message-Authenticator = 0xaf02c98034a727ae8cc5063bcda80c39
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = «test», looking up realm NULL
[suffix] No such realm «NULL»
++[suffix] returns noop
[eap] EAP packet type response id 1 length 9
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
[files] users: Matched entry test at line 206
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING: Auth-Type already set. Not setting to PAP
++[pap] returns noop
Found Auth-Type = EAP
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group authenticate {...}
[eap] EAP Identity
[eap] processing type md5
rlm_eap_md5: Issuing Challenge
++[eap] returns handled
Sending Access-Challenge of id 132 to 172.16.130.31 port 20000
и так далее три экрана логов
В результате эффективный перерыв в передаче данных составил 332 миллисекунды. Причем в нашем эксперименте RADIUS-сервер пользовался локальной базой данных, т.е. не обращался к медленному SQL серверу, не спрашивал разрешения в Active Directory и не занимался пересылкой, верификацией и сравнением Х.509 сертификатов.

В данной статье мы не рассмотрели различные имеющиеся стандартные либо вендор-зависимые механизмы «помощи» клиентского роуминга, такие как WPA2 Fast BSS Transition (FT) 802.11r, Neighbor Reports и т.п. Желающие могут изучить эту серию статей.

Подведем итог:
  • Бытовые точки доступа, работающие автономно друг от друга, заставят клиента произвести полный цикл авторизации при перемещении от одной точки к другой. Это чревато серьезными задержками в передаче полезного трафика, особенно при использовании централизованных баз пользователей (вы же не применяете общий пароль/PSK в корпоративной среде) и как следствие — обрывом коннектов.
  • Бюджетные, но централизованные системы (Mikrotik, UniFi) возможно и обеспечат бесшовный роуминг, но это зависит от реализации. Например, хоть UniFi и имеет «контроллер», он служит только для общей настройки набора точек доступа одним интерфейсом, и по крайней мере в версии софта 2.х точки доступа далее работают автономно и роумингу не помогают (буду рад предложению протестировать эти устройства аналогичным образом).
  • Беспроводные системы корпоративного класса (Juniper, Cisco, Aruba и т.д.) изначально проектировались для поддержки бесшовного роуминга; на них в первую очередь и реализуют нововведения вроде 802.11r. Но за это приходится платить, и зачастую немало.
Антон Винокуров @antonvn
карма
44,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (46)

  • +2
    А какова тогда цена вопроса Juniper Wireless с 2 точками доступа?
    • +4
      Нет никакого смысла покупать Juniper/Cisco/Aruba/Motorola etc ради двух точек доступа. От 10 — смысл начинает появляться.
      Сколько стоит денег — не в курсе.
      • 0
        У aruba networks имеются Instant точки. Они работают без контроллера — виртуальный контроллер поднимается на одной из точек. При это работает большинство фишек типа бесшовного роуминга, сканирование радиопространства, распознавание устройств — в дальнейшем эти точки можно перевести в режим работы с физическим контроллером. Две точки будут стоить окало 1000$ по gpl.
        • 0
          А есть где взять потестить?
          • –1
            На какой срок? Для баловства или выбирается оборудование под проект?
            • +1
              На неделю. Чтобы написать похожую статью (т.е. для баловства).
    • 0
      За Джунипер не скажу, но средненький вариант на Циске (пару точек+контроллер) будет в районе $2000.
      Но смысла особого нет, да
    • 0
      Если Вас интересует небольшое кол-во точек, то лучшим вариантом будет SMB линейка CISCO WAP321/121. Указанные точки умеют кластиризовываться, то есть дружно работать вместе без контроллера. Конечно, это не замена контроллера с точками, но для SMB сектора — функционала за глаза. Присутствует хороший роуминг. Да и цена не такая большая.
      • +1
        Теперь уже belkin, а по сути linksys с отвратительным ПО, к aironet и cisco отношения эти точки никакого не имеют к сожалению.
  • 0
    в UniFi v3.x есть Seamless Roaming — Zero-Handoff, но сам софт c начала года в бете и вообще жутко глючный. мне пришлось откатиться до 2.х в продакшене и я никому не рекомендую использовать v3.x, кроме как случаев «поиграться»
    • 0
      Что я делаю не так? Версия 3.х. Точек доступа порядка 15. Ежедневная нагрузка примерно 70 юзеров. Пара ssid, на одной из которых публичный инет. На другой в основном wifi voip. Проблемы есть только с голосом (ну не преспособлен вайфай для голосового трафика в отличие от DECT). А зоопарк компов, планшетов, смартфонов и прочих гаджетов ваще не замечает деградаций при перемещениях. :-)
      • 0
        70 юзеров на 15 точек доступа-это не нагрузка. Сколько пользователей дата-влана действительно перемещаются? Каков основной профиль пользователей, твиттер и фейсбук? Тогда видимо им роуминг никакой не и нужен.
        Voice over WiFi отлично работает. Просто UniFi для этой цели-плохой выбор.
      • 0
        у меня всего 5 точек, но нагрузка на 2х из них — по 20-25 пользователей на точку. на точке 4 SSID в разных VLAN и они ежедневно сходят с ума, помогает только рестарт точек. согласно спидтесту — скорость колеблется на уровне ~0.5Mbit/s как RX, так и TX, а пинги (даже 32 байтные пакеты!) на разные ресурсы просто астрономические (2000-3000 мс) и часть пакетов просто теряется, а из всех девайсов особенно чувствительны макбуки, хотя и другие ноуты страдают, но не так сильно.
        полистайте форумы ubiquiti — там целая кипа жалоб и проблем с Apple.
        кстати, заметил еще 1 интересную особенность — UDP multicast в одной из подсетей в которой находиться SSID кладет точку наглухо. не помогают даже рестарты.
        это было на 3.1.2. сейчас 2.4.3 (да, знаю, есть 2.4.4, но пока не рискую апгрейдится) таких проблем не наблюдается.
        профиль пользователей — СЕОшники, контент-менеджеры и несколько сисадминов.
        торентов нет — это тут же отслеживается и карается. хочешь торент — садись на шнурок :)
        • 0
          Как, не секрет если, отслеживаете торренты? Разрешаете только заведомо известные протоколы?
          • 0
            NetFlow Traffic Analyzer
            просто анализируем трафик и и делаем атата кому надо )
        • 0
          Ничего удивительного. Если все 25 пользователей сидят в одном частном диапазоне — 2.4 Ггц, то это в принципе предел точки с одним радиомодулем. Нужно ставить точку с двумя радиомодулями и принудительно переводить на 5 Ггц устройства, которые поддерживают работу в этом диапазоне.
          • 0
            тогда почему то же железо с теми же пользователями уже вторую неделю стабильно работает с v.2.x если круг задач не менялся?
            • 0
              Думаю потому-что 25 пользователей это в принципе физический предел — пиковая нагрузка для точки, а новое ПО на точке больше ресурсов отжирает на точке, т.к. в версии 3 есть принципиальные изменения вплане работы. Поэтому точка и встает в позу.
              • 0
                конкретно в этом случае врятли это физический предел. потому что есть еще 3 менее загруженые точки, где порой работает 1-2 пользователя и наблюдаются те же проблемы при использовании точек вместе с контроллером v3.x
                еще было замечено, что LA на самой точке резко выростает до ~1.0 и так же резко падает до прежнего состояния, в момент когда точка начинает выделываться.
                • 0
                  У меня на 3-ей версии глюк был — точки автоматически выбрали для работы самый зашумленный канал. Работало не более 5ти пользователей а скорость каждого упала до мегабита и пинг плясал до 100. Посканил анализатором и вручнуюу перевел на менее зашумленные. Недавно пробовал 3.1.3 — контроллер опять все точки перевел на первел канал ужс ТТ
      • 0
        Нужен Call admission control для Wi-Fi, тогда под голос будет резервироваться % радиополосы. Unifi к сожалению этого не умеет, хотя WMM у него есть.
        • 0
          Спасибо за наводку на Aruba-овскую утилитку. Вообщем, 3-4 секунды затык при роуминге. В принципе, не сильно критично. При разговоре клиент в наших трубках слышит «бип-бип». Ну и ладно :-)
          А насчет резервирования… дешевле/проще получается DECT. :-(
      • 0
        скорее всего, не используете RADIUS :)
  • 0
    А " заботливо набранная веб-форма" почему сбросилась, расскажите, это важно :)
    • 0
      Это аллегория. Вообще-то речь шла о сброшенной TCP-сессии.
  • 0
    У Mikrotik есть возможность создать Mesh сеть, но из статьи в их wiki не совсем ясно возможно ли это использовать как «роуминг» без контроллеров и дёшево. Никто не пробовал?
    • +1
      Пробовал, получается. По поводу контроллера — wiki.mikrotik.com/wiki/Manual:Wireless_Controller
      • 0
        Если сделать только mesh с линком не по WiFi, а по кабелю это ведь получается единая сеть с роумингом?
    • 0
      То же очень сильно интересует вопрос, причем сделать передачу wds по проводу HWMP plus если не ошибаюсь.
  • 0
    Как-то заморочено все.
    Мы когда встречали Медведева, была задача сделать бесшовный роуминг wifi на 2 этажах административно бытового корпуса станции.
    Мы отделались 3 ubiquiti nanostation loco m2, которые работают в частоте 2.4 ГГц и CISCO 2960. Вывели их в отдельный vlan, дали доступ в интернет на шлюзе. Все было ровно. Без танцев.

    Естественно для таких гостей сеть была без пароля.
    • 0
      Еще бы. Нанотехнологии же.
    • 0
      Nanostation M2 не поддерживают бесшовный роуминг. В теории его можно сделать, если прошить firmware от unifi и запустить контроллер версии 3.
      • 0
        Не знаю не знаю. Специально проверял. Запускал видео в youtube, ходил и следил как ноутбук переключается от точки к точке при этом загрузка видео продолжалась.
  • +1
    Кстати для отслеживания роуминга рекомендую хорошую бесплатную утилиту для андройда Aruba Utilities play.google.com/store/apps/details?id=com.arubanetworks.arubautilities&hl=ru
    • 0
      а для linux/osx/win есть что то?
  • 0
    Сейчас тоже рассматриваю варианты увеличения покрытия. Как насчёт расширителей Wi-Fi, есть от них какой-то прок?
    Наподобие TL-WA830RE.

  • 0
    Во-первых. Статья очень хорошая — разобрано всё довольно детально. Побольше бы таких. Жаль, не показан обмен на проводной стороне.
    А вот некоторые выводы — интересные :)

    Бесшовный роуминг достигается на потребительских устройствах еще проще, чем на корпоративных — потребительские устройства не поддерживают EAP. А для PSK любой роуминг чист и гладок (если PSK совпадают, конечно). Так что тут автор палку перегнул немного :)

    Большинство проблем роуминга — из-за кривого покрытия или косяков на клиенте. Тут ни один вендор не поможет, но некоторые могут подсластить пилюлю за счет алгоритмов Radio Resource Management (RRM/ARM/SMART RF/etc) или балансировки нагрузки. Кстати, как с этим у Juniper?

    Контроллеры — старО. Aruba MOVE/Instant или Motorola WING5 делают то же самое без контроллера (и еще куча вендоров Tier 2). Тем более, ставить два контроллера в группу. Понимаю, хотелось поиграться :)

    Напрягает роуминг — переходите на Meru — у них вообще роуминга нет. ВООБЩЕ. :) :)

    Во-вторых. Если еще хотите поиграться:
    * посмотрите как работает OKC (Opportunistic Key Caching, если он поддерживается на Juniper) — при правильной настройке будет роумить еще быстрее, т.к. никаких запросов к контроллеру не будет.
    * найдите устройство с поддержкой 802.11r (FT) и посмотрите, как происходит роуминг там.
    • 0
      Для роуминга с PSK есть такой момент — клиент должен найти новую точку доступа. Значит, он должен сканировать остальные каналы (вы же не вешаете все точки на один канал, верно?). Это занимает время, особенно в -a диапазоне. Соответственно, перескочить на новую точку доступа он может поздно (когда сигнал сильно ослабнет), будет оттягивать до последнего. В «нормальном» роуминге о новой точке доступа (и ее канале) ему скажут, ничего сканировать не надо.
      У Juniper все отлично с балансировкой и RRM, ничем не хуже циски. А вот 802.11r пока нету.
      • 0
        В каком таком «нормальном» роуминге? Покажите, где в ваших пакетах есть указание новой точки? Это не имеет никакого отношения к кешированию PMK — это уже фишка 802.11r/v. :) И, более того, она должна поддерживаться клиентом. Именно поэтому я и сделал акцент на клиентах. Кстати, именно поэтому я вам и порекомендовал поиграться с 802.11r — там идет обмен по WNM по воздуху с клиентом.

        В вашей ситуации (с обычным кешированием) клиент будет сканировать каналы точно также. На некоторых клиентах можно ограничить список каналов, что позволяет сократить время сканирования.

        Буду признателен за документальное опровержение :)
        • 0
          Я и говорю, Juniper 802.11r не поддерживает. О новой точке сообщает циска, но я пока не смог поймать соответствующие пакеты (сниффер не успевает :) )
          • 0
            Ну вот видите, теперь, оказывается, это конкретно Cisco делает. Я так понимаю, речь идет об AP Assisted Roaming, использующем 802.11k, что опять же требует поддержки на клиенте (без поддержки на клиенте фича будет только увеличивать задержку). Так вот, ничего общего с дискуссией PSK vs EAP эта технология не имеет и будет работать и там и там одинаково успешно. С массовым внедрением 802.11r и Voice Enterprise фича будет вообще неактуальной. Кроме того, фича имеет кучу ограничений (форматирование мое)
            Guidelines and Limitations
            • This feature must be implemented only if you are using one controller. The assisted roaming feature is not supported across multiple controllers.
            • This feature is supported only on 802.11n capable indoor APs
            • Because both load balancing and assisted roaming are designed to influence the AP that a client associates with, it is not possible to enable both the features at the same time on a WLAN.


            По поводу сниффера: попробуйте собирать пакеты прямо на точке (на радиоинтерфейсе). Циска такое умеет?
            • 0
              Я не спорю, 802.11к это зло. Я про CCX assisted roaming, вот к примеру: expertwireless2be.blogspot.ru/2011/12/why-wireless-80211-roaming-is-nightmare.html
              ССХ сейчас поддерживают все клиенты, естественно Juniper этими фичами не пользуется.
              Цискина точка доступа умеет быть сниффером, но при этом она клиентов не обслуживает :)
              • 0
                Не понял, почему 802.11k — это зло. Как раз, это стандарт, в отличие от CCX. Просто, нужна поддержка на клиенте (как и для CCX). В статье, на которую вы ссылаетесь 802.11k не упоминается (во всяком случае, я не нашел). 802.11r на него опирается, кстати. Объясните.

                Вам тут не полный режим сниффера нужен. Я не работал с дебагом на Cisco, но на Motorola можно просто написать service pktcap on radio 1 ... и получить дамп всех пакетов, которое это радио посылает. Получается некий аналог span port. Если клиент роумится — можно даже распределенную команду послать remote-debug live-pktcap on rf-domain NAME… и все точки, приписанные к RF-Domain NAME аккуратно сольют дампы в один файл. Очень удобно отсматривать, что происходит при роуминге, и не нужен сниффер (не то, чтобы СОВСЕМ не нужен, но зачастую не нужен). Я вот про такое говорил. Думаю, Cisco и Juniper должны что-то подобное иметь.

                А блог интересный — подписался, спасибо!
                • 0
                  Статья-то 2011 года, тогда стандартов особо не было…
                  Да, дебаг есть конечно, просто на живой сети включать его не хочется (застрелишься потом фильтровать).

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.