APに異常はないのに「無線LANが遅い」――2万人会場に学ぶ“Wi-Fi低速化の思わぬ要因”：「Wi-Fi 7」機を150台設置

Ciscoは、Black Hat USA 2026のネットワーク運用センターで発生した2件の無線ネットワークの不調と、その原因を突き止めた手順を公開した。いずれもインフラ側の監視では「正常」に見えていたという。

[＠IT]

　無線LANアクセスポイント（以下、AP）などのネットワーク機器が正常に稼働していても、ユーザーが快適に通信できているとは限らない。APやスイッチが正常に動作し、クライアント側からの接続も問題なくできているように見えても、実際に利用する際のパフォーマンスが低下していることがある。その見えにくい問題をどう見つけ、原因を切り分ければいいのか。

　そうした事象は、2万人を超える参加者が集まったセキュリティカンファレンス「Black Hat USA 2026」のネットワークでも発生していた。Cisco Systems（以下、Cisco）は2026年9月7日（米国時間）、会場で無線LAN接続が遅くなった2つの事象と、AP側の監視では見えなかった原因を突き止めるまでの過程をブログで公開した。

通常監視では見えなかったWi-Fi接続の盲点

　Black Hat USA 2026のNOC（ネットワークオペレーションセンター）は複数のネットワーク関連企業が共同で運営した。会場には150台を超える「Wi-Fi 7」のAPを設置し、カンファレンス全体向けの無線LANと、各トレーニング向けの無線LANを提供した。

　2万人を超える参加者を支えるため、ネットワークが正常に動いているかどうかを継続的に確認する必要があった。CiscoとBlack Hatは、クライアント側から通信品質を測定することで、通常では異常に気付きにくい2つの“不調の要因”を特定した。

異常だとは気付きにくかった2つの問題

　CiscoとBlack Hatは、会場内に30台を超える「ThousandEyes」エージェントを配置。トラフィックが多くネットワークの信頼性が特に重要な場所を選んで設置した。

　これらの機器とカスタムのダッシュボードにより、DNS（ドメインネームシステム）、スループット、クラウドサービスの応答時間といった主要指標を把握できる。NOCのチームは、ユーザーから申告が上がる前に無線と有線の問題に先回りして対処できるようになった。

ダウンロード速度の低下、原因はローミング設定

　カンファレンス前半の3日間は、ThousandEyesの各ノードが単一のAPのSSIDに接続していたため、ローミングはほとんど考慮しなくてよかった。この構成では、ローミング先となる複数のBSSID（APの無線ごとに割り当てられる識別子）が存在しないためだ。後半3日間のブリーフィングでは教室ごとのSSID構成を廃止し、各ノードを一般向けのWi-Fiへ移した。

　この期間に、1台のノードでダウンロード速度が低下していることが分かった。ThousandEyes上では、ダウンロードテストの1つでクライアントのスループットが急落していた。

ダウンロードテストでスループットが急落したノード（提供：Cisco Systems）

　スループット低下の理由を判断するには追加の情報が必要だった。そこでNOCチームは、ネットワーク機器ベンダーであるArista Networks側の情報を確認した。NOCのID基盤である「Duo Directory」を経由して「Arista CloudVision」のダッシュボードにログインし、ホスト名またはMACアドレスでクライアントを検索したところ、このクライアントがローミングして別のAPへ移動していたことが分かった。

　そこでThousandEyesエージェント自体を調べると、ログからクライアントでビーコン喪失が発生していたことが分かった。接続していたAPのビーコンを一定時間受信できなくなり、より信号品質の良いAPへ移動していた。

　Aristaのダッシュボードでも同じ時刻にトラフィック量の増加と、データレートおよびRSSI（受信信号強度）への影響が確認でき、この所見を裏付けた。何らかの事象によって当該BSSIDがThousandEyesノードから一時的に利用できなくなったと考えられる。その後スキャンを実行した時点では、そのBSSIDは-45dBmで健全な状態に戻っており、APで一時的な事象が起きたという見方と整合する。

　一方、エージェント側で「iw」コマンドを使って周囲のAPをスキャンすると、さらに別の問題が見つかった。より条件の良いAPが存在するにもかかわらず、クライアントが比較的信号の弱いBSSIDに接続したままになっていた。

　接続先のRSSIは-69dBmだったのに対し、より条件の良いAPは-45dBmで、その差は24dBに達していた。それでもクライアントが移らなかったのは、より良いAPを探すためのスキャンが実行されていなかったためだった。

　ThousandEyesエージェントには、出荷時に「bgscan="simple:30:-70:86400"」という変数が設定されている。bgscanは「wpa_supplicant」のバックグラウンドスキャン用モジュールで、エージェントではNetworkManagerがこの値を設定する。各値の意味は次の通り。

• simple：使用するバックグラウンドスキャンのモジュール名
• 30：信号強度がしきい値を下回った場合のスキャン間隔（秒）
• -70：頻繁にスキャンを実行するかどうかを決めるRSSIのしきい値（dBm）
• 86400：信号強度がしきい値以上の場合のスキャン間隔（秒）。24時間に相当する

　問題のノードのRSSIは-69dBmで、このしきい値をわずかに上回っていた。このため、より良いAPが近くに存在していても頻繁なスキャンが実行されず、条件の悪いAPに接続し続ける状態になっていた。

　Ciscoが得た教訓は、bgscanの信号強度のしきい値を-70dBmから-65dBmへ引き上げることだった。これにより、信号強度が低下した段階でより早くスキャンを開始し、条件の悪いBSSIDに接続し続ける状況を避けやすくする。

教室のスループット低下、有線側は100Mbpsでリンクしていた

　もう一件は、有線側のリンク速度が原因だった。

　Mandalay Bay Convention Center内の教室の一つで、ThousandEyesのダッシュボード上、無線クライアントのスループット低下が長時間続いていた。この教室はトレーニング用にAPが1台、BSSIDも1つだけという構成だった。

　ThousandEyesのクライアントとAPに接続していた他のクライアントは、いずれも午後遅くに大きな性能低下を示していた。現地でも速度を計測したところ、期待される性能に達していないことを確認した。

現地で実施した速度計測。ダウンロードが8.89Mbpsまで落ちていた（提供：Cisco Systems）

　Arista CloudVisionのダッシュボードでAPが接続されたスイッチポートの詳細を確認すると、原因が見つかった。リンクが本来の1Gbpsではなく、100Mbpsでネゴシエートされていた。

　Aristaのチームに連絡すると即座に対応が始まり、ケーブルを交換したことで受講者への影響は解消し、本来のサービスが回復した。

スイッチポートの詳細。リンク速度が100Mbpsでネゴシエートされていた（提供：Cisco Systems）

インフラのテレメトリーだけでは分からないもの

　Ciscoは、いずれの問題も通常のインフラ監視では障害として捉えにくいものだったと指摘する。

　ローミング後のエージェントはAPとの接続を維持し、再送率も0.06％だった。もう一方の教室でもAPのリンクはアクティブで、認証に成功し、PoE（Power over Ethernet）のネゴシエーションも完了していた。インフラ側から見れば、どちらも「正常」だった。

　異常を示していたのは、クライアント側から実際に通信して測定したスループットだった。

　Ciscoは、ここに外形監視（シンセティック監視：実際の利用を模した通信を定期的に発生させ、サービスの品質を測る手法）が必要になる理由があると説明する。インフラのテレメトリーから分かるのは、機器やネットワークが正常に動作しているかどうかだ。一方、クライアント側から継続的にテストすることで、ユーザーが実際にネットワークを正常に利用できているかどうかを確認できる。

　今回の切り分けでは、ThousandEyesが「どのクライアントで、いつ問題が起きたのか」を捉え、Arista側の情報から「なぜ起きたのか」を突き止めた。Ciscoは、どちらか一方の情報だけでは問題の全体像を把握できなかったとしている。