Cisco Meraki、HPE Aruba 和 Ruckus 上的 DFS 雷达事件：信道变更的诊断清单

要在按照 IEEE 802.11h 标准运行的 Cisco Meraki、HPE Aruba 或 Ruckus WiFi 网络上诊断和解决 DFS 雷达事件，请分析您的控制器日志以查找雷达检测。一旦检测到，接入点必须在 10 秒内腾出 5GHz 信道，并保持离开状态 30 分钟。

5GHz 网络上的 DFS 雷达事件是什么样的？

动态频率选择 (DFS) 允许 WiFi 与雷达共享 5GHz 频段的一部分。IEEE 802.11h 定义了该机制。监管机构设定了时间：在美国，FCC 依据 47 CFR Part 15.407，而在整个欧洲，依据 ETSI EN 301 893。在 ETSI 地区，52 至 64 信道和 100 至 140 信道是 DFS 信道。FCC 规则增加了 144 信道。

当接入点 (AP) 检测到雷达时，步骤是固定的：

1. 检测。 无线电将其工作信道上的脉冲模式与雷达特征进行匹配。
2. 信道切换公告 (CSA)。 AP 在其信标中添加 CSA 元素，告知客户端新信道以及移动的倒计时。
3. 信道移动。 无线电必须在 10 秒内停止在该信道上发送信号。
4. 非占用期。 该信道在至少 30 分钟内禁止使用。
5. 信道可用性检查 (CAC)。 在 DFS 信道投入使用之前，无线电会至少倾听 60 秒。在 ETSI 地区，120、124 和 128 信道（5600 - 5650 MHz）与气象雷达共享，该检查需要持续 10 分钟。

宾客的体验取决于他们的设备。遵守 CSA 的客户端会紧随 AP 切换，仅有短暂的停顿。忽略它的客户端则会丢失连接、重新扫描并重新关联，通常会连接到 2.4GHz 或相邻的 AP。如果 AP 移动到未通过检查的 DFS 信道，5GHz 无线电可能会保持静默一分钟或更长时间。

需要注意的特征模式：

• 一个 AP 或一组相邻 AP 上的所有客户端都在同一时刻掉线。
• AP 在不同的信道上恢复，通常是 36 到 48 之间的非 DFS 信道。
• 更改发生的时间超出了您计划的信道优化窗口。
• 相同的 AP 重复此模式，有时在一天中的相似时间段。
• 2.4GHz 负载激增，而 5GHz 客户端消失。

通常是什么原因导致 DFS 信道更改？

真实雷达

欧洲常见的真实来源是 5600 - 5650 MHz 范围内的气象雷达。在美国，主要机场的终端多普勒气象雷达 (TDWR) 使用相同的范围。视线比距离更重要。室外 AP、高楼层和玻璃幕墙会检测到一楼 AP 永远看不到的雷达。

仅凭距离难以预测。许多机场监控雷达和海上导航雷达在其他频段运行，远在 5GHz 之外。港口旁边的场所可能永远不会记录一次雷达事件。您的事件日志才是证据，而不是地图。

误报

DFS 误报是指在没有雷达存在的情况下检测到雷达。无线电将突发的能量解读为雷达脉冲模式。典型的触发因素包括：

• 来自无线视频链路或故障设备的脉冲式非WiFi干扰；
• 来自相邻信道上附近AP或点对点链路的强发射；
• 无线电或固件缺陷，厂商会在软件版本中予以纠正。

其特征在于孤立性。一个AP在不同的信道上记录了重复的事件，而具有相同天空视角的邻近AP则没有记录任何事件。

宽信道会增加遭受真实和虚假检测的风险。一个80 MHz信道跨越四个20 MHz子信道，在其中任何一个子信道上的检测都会移动整个信道。

看起来相同的非雷达变化

信道规划器会因干扰和负载而移动无线电。Meraki Auto RF、Aruba ARM和AirMatch，以及Ruckus ChannelFly和BackgroundScanning都会在没有雷达的情况下改变信道。AP重启和功率变化也会导致客户端掉线。这些故障需要不同的修复方法，因此在排除任何因素之前，请先确认原因。

您如何确定是雷达导致了中断？

请按顺序执行以下检查清单：

1. 锁定投诉。 确定到具体分钟的时间以及房间、楼层或区域。
2. 拉取为该区域提供服务的AP在前后一小时内的信道变化事件。
3. 阅读记录的原因。 雷达或DFS原因可确认起因。而干扰、噪声或优化原因则可将其排除。
4. 注意信道。 集中在120、124和128信道上的事件指向天气雷达。
5. 统计受影响的AP数量。 几个邻近的AP同时出现该情况表明存在真实的雷达。单个AP单独出现该情况则表明是误报。
6. 寻找每周规律。 定期重复出现表明雷达具有固定的时间表或扫描周期。
7. 检查信道宽度。 仅在80或160 MHz信道上出现的事件表明宽度是问题的一部分。
8. 阅读固件版本说明以获取针对您AP型号的DFS检测修复程序。

如果您运行Purple Guest WiFi，按场馆划分的登录量可以为您提供交叉核对。某个站点与雷达事件吻合的急剧下降确认了对访客的影响。

您如何修复Meraki、Aruba和Ruckus上的DFS事件？

厂商	雷达事件出现的位置	信道规划器	您限制信道的位置
Cisco Meraki	针对DFS事件过滤的无线事件日志；每个AP的RF频谱页面	Auto RF	应用于受影响AP的RF配置文件信道列表
HPE Aruba	控制器或Instant集群上的ARM历史记录；AOS 8和Aruba Central中的AirMatch事件	ARM (AOS 6, Instant), AirMatch (AOS 8, AOS 10)	AP组的无线电配置文件中的允许信道列表
Ruckus	SmartZone雷达检测事件和告警	ChannelFly或BackgroundScanning	专用区域或AP组的无线电设置

Cisco Meraki

Meraki 会将雷达检测作为 DFS 事件记录在事件日志中，并指明 AP 和信道。可通过事件类型和投诉时间窗口进行过滤。每个 AP 的 RF 频谱页面会显示利用率和干扰情况，从而将雷达干扰与拥堵区分开来。要防止再次发生，请在 RF 配置文件中从 Auto RF 里移除有问题的信道。仅将该配置文件应用于受影响的 AP。Meraki 官方的 DFS 文档涵盖了确切的步骤。

HPE Aruba

ARM 历史记录列出了每次信道更改及其原因，其中雷达检测会作为一个独立的原因出现。AirMatch 会在中心构建信道计划，但雷达触发会迫使 AP 立即移动。因此，DFS 信道上在下午三点左右发生的非计划更改是一个强烈的线索。在仅包含受影响 AP 的 AP 组的射频配置文件中限制信道。如果访客在重新连接后被送回登录页面，那是一个单独的故障：请参阅 HPE Aruba captive portal troubleshooting: redirect, certificate and walled garden checklist。

Ruckus

SmartZone 会在 AP 检测到雷达时触发事件，并指明 AP 和信道。检查该时间窗口内的事件和告警，然后将其与 ChannelFly 或 BackgroundScanning 活动进行对比。如果没有雷达事件背景的 Ruckus DFS 信道更改是规划器的决策，而非 DFS。在专用区域或 AP 组的射频设置中移除有问题的信道。

在这三个平台上，都只需更改受影响的 AP。全站点的排除会消耗那些从未检测到雷达的 AP 的容量。

您是否应该在机场、港口或天气雷达附近禁用 DFS 信道？

默认情况下不需要。在 ETSI 区域内排除每个 DFS 信道后只会留下四个 20 MHz 信道：36、40、44 和 48。FCC 规则会留下九个，增加了 149 到 165。在高密度场所中，四个信道会迫使 AP 共享空口时间并降低每个客户端的速度。让日志来决定。

您的日志显示什么	可能的原因	建议	剩余的 20 MHz 信道 (ETSI / FCC)
多个相邻 AP 上的事件，集中在 120 - 128	天气雷达	在受影响的 AP 上排除 120、124 和 128	16 / 22
许多 AP 上大多数 DFS 信道每天都发生事件	附近有强雷达	仅在受影响的 AP 上排除 DFS；在其他地方保留	受影响 AP 上为 4 / 9
单个 AP 上重复发生事件，信道各异	误报	更新固件、测试或更换射频模块，保留 DFS	19 / 25
仅在 80 或 160 MHz 信道上发生事件	频宽暴露	降至 40 或 20 MHz，保留 DFS	19 / 25
信道发生更改但没有雷达记录	规划器或干扰	解决干扰和功率问题，保留 DFS	19 / 25

实战场景：区域机场附近的一家酒店

在欧洲电信标准协会（ETSI）地区，一家拥有 180 间客房的酒店距离配有气象雷达的机场 3 公里。入住朝西高楼层客房的宾客反映大多数下午都会出现连接中断。事件日志显示，在 46 个 AP 中的 11 个上，一周内共发生了 63 次雷达事件，全部集中在 120 至 128 信道。团队将这 11 个 AP 移至排除气象信道的配置文件中，并将频宽设置为 40 MHz。在接下来的四周内，该酒店记录的雷达事件降为零。前台收到的 WiFi 投诉从每周 14 起降至 2 起。其他 35 个 AP 则保留了所有 DFS 信道。欲了解更多关于酒店部署的信息，请参阅 酒店。

案例分析：拥有一个高噪 AP 的零售连锁店

一家拥有 120 家门店的零售连锁店发现，其中一家门店在两周内于信道 52、100 和 116 上记录了 30 次雷达事件。该门店内的相邻 AP 未记录任何事件，这表明存在误报。该 AP 型号的发布说明中列出了 DFS 检测修复，因此团队升级了固件。然而事件仍在继续，随后该 AP 在保修期内被更换。此后，该门店的雷达事件降至零，顾客在收银区不再断开连接。整个门店保留了所有 19 个信道。关于多站点访客接入，请参阅 零售。

案例分析：港口旁的市政办公室

一个市政 IT 团队计划关闭紧邻商业港口办公室的 DFS。三十天的日志显示完全没有雷达事件。信道变更是由于规划人员对邻近租户网络做出反应而引起的。团队最终保留了 DFS，降低了发射功率，并修正了信道规划。每周的中断报告从 9 起降至 1 起。

如何防止 DFS 事件再次干扰宾客？

• 在高密场所使用 20 或 40 MHz 信道。较窄的信道可减少暴露并增加复用率。
• 仅在受影响的 AP 上，针对事件集中的 120 至 128 信道精确排除气象信道。
• 保持固件为最新版本，并阅读每个发布说明中的 DFS 修复内容。
• 每月审查 DFS 事件，并对每周记录超过少数几次的任何 AP 发出警报。
• 规划 6GHz。 6GHz 频段没有 DFS 要求，因此 WiFi 6E 和 WiFi 7 客户端可完全避免雷达避让移动。
• 将射频与访客接入分离。 Purple 在 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme Networks 和 Fortinet 上作为与硬件无关的云端覆盖运行。您的控制器掌控信道规划，而 Purple 负责访客登录。在 2024 年，Purple 在 80,000 多个活跃场所中支持了 4.4 亿次登录（Purple 数据）。

常见问题解答

Purple 访客 WiFi 能否在我们现有的 Meraki、Aruba 或 Ruckus 接入点上运行？

是的。Purple 访客 WiFi 是一种与硬件无关的云端覆盖，可在 Cisco Meraki、HPE Aruba 和 Ruckus，以及 Juniper Mist、Ubiquiti UniFi、Cambium、Extreme Networks 和 Fortinet 上运行。您无需更换接入点、控制器和射频配置。Purple 在此基础上增加了访客登录、知情选择同意和一手数据收集。无需进行设备替换，且您的 DFS 设置仍由您控制。

Purple 会更改我们的 DFS 或信道设置吗？

不。Purple 不会设置射频信道、信道宽度或发射功率。这些设置仍由 Meraki Auto RF、Aruba ARM 或 AirMatch，以及 Ruckus ChannelFly 或 BackgroundScanning 管理。Purple 在射频层之上处理访客认证和数据捕获。这种分离使您可以在供应商控制面板中修复 DFS 问题，而无需修改访客登录体验；同样，修改登录设置也不会影响射频。

禁用 DFS 信道是否合规？

是的。ETSI EN 301 893 和 FCC Part 15.407 要求在您使用的任何 DFS 信道上进行雷达检测。这两项标准均未要求您必须使用 DFS 信道。排除这些信道始终是合规的。您绝对不能做的是在禁用检测的情况下在 DFS 信道上运行。排除 DFS 信道的实际代价是容量减少：在 ETSI 地区，移除所有 DFS 信道后将仅剩下 4 个 20 MHz 信道，而不是 19 个。

我们是否需要新的接入点来避免 DFS 问题？

通常不需要。大多数 DFS 问题都可以通过配置来修复：在受影响的 AP 上排除气象信道、收窄信道宽度或更新固件。只有当某个射频在固件更新后仍然持续产生误报，或者当您增加 6GHz 容量时，更换设备才具有合理性。6GHz 频段没有 DFS 要求，因此 WiFi 6E 和 WiFi 7 接入点可以为支持这些协议的客户端消除雷达避让移动。

排除 DFS 信道会损害繁忙场馆的访客 WiFi 体验吗？

是的，如果您在整个场所内排除它们。在 ETSI 地区，4 个 20 MHz 信道无法在体育场、会议中心或大型酒店中隔离数十个 AP。AP 最终会共享空中时间，导致每位访客的吞吐量下降。建议仅在记录了雷达信号的 AP 上排除信道，并在其他所有地方保留 DFS。这种方法既能控制问题，又不会损失容量。

英国、欧洲和美国之间的 DFS 规则是否有差异？

是的。英国和欧盟遵循 ETSI EN 301 893，该标准将 DFS 应用于信道 52 至 64 以及信道 100至 140。它还要求对气象信道 120、124 和 128 进行 10 分钟的可用性检查。美国遵循 FCC Part 15.407，该标准增加了信道 144 并留出了 9 个非 DFS 信道。两者都要求在检测到雷达后至少进行 30 分钟的静默不占用。

MSP 能否诊断多品牌混合设备环境中的 DFS 事件？

可以，但雷达事件记录在每个供应商自己的工具中：Meraki 事件日志、Aruba ARM 历史记录或 AirMatch 事件，以及 SmartZone 事件和告警。MSP 应当标准化检查清单，而不是工具本身，并记录每次事件的时间、信道、AP 数量和原因。Purple 为您跨所有这些供应商提供统一的访客接入平台，而射频诊断仍保留在各自的控制器中。