WiFi MESH场景下配置同步探讨

0 话题背景

  近1年来,随着大厂家持续发力推出WiFi MESH产品,MESH突然成了WiFi领域的又一个热点,导致如果WiFi设备不支持MESH,不无缝承接IoT,都不能称WLAN产品了。

  在流行的MESH产品技术中,本人持续研究过QCA的SON技术和Realtek的802.11s技术,相对来说,SON更易用些,所以从众众多,包括eero、netgear、TP Link、Ubiquiti、Linksys以及google的产品都是选用此技术;而国内的tengda选用的是RTL的MESH技术。

  无论是SON还是802.11s,在消费级场景下,都是通过多个(一般是3个)同等级设备自组网,从而实现目标区域内全覆盖、漫游无感知、线路备份以及开通傻瓜化。

  但是,无论是原始的SON技术,还是802.11s技术,都未能解决运营中配置同步问题。SON的原版实现中,通过按键操作方式,可以实现无线设备参数和VAP级(SSID名/认证方式/加密方式/PSK)参数同步。而RTL的MESH实现中,除了要求MESH ID,加密方式和PSK值完全一致外,还需要参与MESH 链路的射频口的工作模式、带宽、信道以及40+/40-完全配置一致,但根本未涉及到业务VAP的配置。然而,在实际使用场景中,用户希望配置了其中一台设备后,其它设备能自动同步这份新配置,而不要一台台去配置。

1 话题分析

  无论是SON还是802.11s的MESH中,设备可分为2大类:中心设备(CAP/ROOTAP)和从设备(RE/AP),其中,前者一般通过有线口接入上游网络,后者通过WiFi或有线口接入终端用户;中心设备和从设备一起组成L2网络。由此,我们可以将配置分解为A L3及上层、B L2层和C 系统级。其中L3及上层主要是一些防火器规则(QoS规则可以看出是种特殊的防火墙规则),它们适合在中心设备上生效;L2层配置主要是无线MAC地址过滤与限速,网桥参数,射频和VAP参数,此类参数需要在中心设备和从设备上均生效,方能达成预期目标;而系统级参数主要是用户密码管理、固件管控、配置参数文件管控以及远程集中管控,此类参数适宜在中心设备和从设备上独立生效。

  由上分析可知,L2层配置参数,是需要全网统一的,否则,将导致网络中断或性能浪费或功能失效,典型的如针对终端用户的限速,如果直接在从设备上实现,则可有效减轻中心设备的负载,从而提供整个网络性能;再如无线MAC地址过滤或无线接入鉴权,如果只在中心设备上实施,则依然无法阻挡未授权用户接入从设备,这与预期目标不符,属于功能失效。

  公版的SON实现中,在CAP端更改了无线参数配置后,需要按下CAP设备和RE设备的WPS按键(WPS按键与RESET按键可复用),从而实现网络恢复,达成SON联通的预期目标。公版的RTL MESH实现中,没有这样的机制,必须登陆到每台设备修改。

  按键方式在具体使用中存在诸多不便,如安装距离较远,需要楼上楼下跑,这定能引起用户投诉;同时,按键操作还会引发如下风险:按键过短无效,过长又会导致设备重启或恢复出厂默认配置。当然,按键操作可以通过WEB页面或APP方式软触发,但具体使用中,可能修改造成了SON中断,无法通过WEB页面或APP方式控制设备。

  登录到每台设备,然后按照ROOTAP配置参数来修改每台MESH设备,这个重复操作对大部分消费者来说要求过高,而且一旦出错,MESH网络就联通不来。

2 具体实施

  在综合SON实现技术和MESH实现技术基础上,我们开发了一种L2层配置参数同步机制,其核心限制是:中心设备的L2层配置同步到从设备,从设备间的配置不能同步到其他设备。此限制主要是为了简化实现模型,同时,让中心设备控制从设备的方式,对大部分消费者来说也是可以接受的。

  中心设备启动后,定期收集L2层配置信息,一旦发现配置被更改,则往指定组播地址发送加密后的配置报文;在固定的端口上侦听,一旦有配置请求,则立即往预设的组播地址发送配置报文。从设备启用后,首先检查MESH网络是否联通,如果未联通,则发起“MESH”扫描,将扫描到同一个"MESH ID"的SSID/信道记录下来(加密方式不记录,因为扫描不到PSK值的),然后将MESH链路的SSID配置为扫描到的SSID,将工作信道切换到扫描到的工作信道,不断调整工作模式(N+AC,N,AC或N/N+G)、信道带宽(80M/40M/20M)以及(40+/40-/auto),尝试关联到中心设备。因为“MESH ID”在出厂时预设值,最终用户在“工程师模式”下可以在每台设备上更改此配置,所以每次扫描到的中心设备不会很多,一般尝试2-3次,即可成功建立MESH网络。从设备一旦发现MESH网络正常,立即加入预设组播组,并向该组播组发送配置请求消息。

  中心节点在收到配置请求后,将当前的配置信息加密后发送到预设组播IP;从节点设备收到报文后,首先检查签字码;然后解密消息;最后将配置信息内容与当前配置信息条目比较,如果不同,则更新并生效本地配置。

  为了提高安全性,用户可在“工程师模式下”,修改加密密钥,这样,即使被第3方捕获到了配置报文,短期间内也无法解密该报文,只要在系统推荐的期限内更新密钥,安全性还是有保障的。

3 结果

  我们让中心节点以30秒间隔处理处理配置请求和检测配置更新(配置更新后,从节点关联上来,一般需要30秒左右),从节点以15秒周期检测MESH网络连接状况。在3台设备组网的场景下,可实现从节点主动连上配置更新后的中心节点、最长60s内L2层配置同步而无需用户干预。

  当然,我们可以这类周期缩小得更短,这主要是为了遵循管理功能尽可能不影响网络承载目标;而且在实际使用中,用户在开通后,修改此类配置的操作非常少。


本文章由作者:佐须之男 整理编辑,原文地址: WiFi MESH场景下配置同步探讨
本站的文章和资源来自互联网或者站长的原创,按照 CC BY -NC -SA 3.0 CN协议发布和共享,转载或引用本站文章应遵循相同协议。如果有侵犯版权的资 源请尽快联系站长,我们会在24h内删除有争议的资源。欢迎大家多多交流,期待共同学习进步。

相关推荐