Cisco自立型APのWiFi不安定を調査・解決した話 〜Nest MiniとMeraki MR44の干渉地獄〜

はじめに

自宅のWiFiが不安定になりました。具体的には、5GHz帯に接続しているデバイスで断続的にスループットが落ちる。体感で「遅いな」と思う頻度が増えた程度でしたが、APのカウンターを見て目が覚めました。

output drops が100万超、interface resets が16回。 静かに壊滅していました。

結論から言うと、原因は2つ。Google Nest Mini 2台による再送ストームと、同室に置かれた会社支給 Meraki MR44 との5GHzチャンネル干渉です。この記事では、Cisco自立型APのCLIから問題を切り分け、Cast APIやOUI調査で原因デバイスを特定し、チャンネル変更で解決するまでの全過程を書きます。

環境

自宅のWiFiは Cisco AIR-CAP1702I-Q-K9（IOS 15.3(3)JI1）を自立型モード（Autonomous）で運用しています。WLCなし、単体APです。

そしてこのAPと同じ部屋に、会社支給の Meraki MR44 が鎮座しています。業務用なので設定変更は不可。存在は認識していたものの、「まあ大丈夫だろう」と放置していました。これが後に地獄の元凶だったと判明します。

Phase 1: AP側からクライアント状態を確認する

再送ストームの発見

まずAPにSSHして、接続中クライアントの状態を確認します。

show dot11 associations all-client

このコマンドは、APに接続している全クライアントのMAC、SSID、SNR（Signal-to-Noise Ratio）、そして各種カウンター（Data Retries、RTS Retries等）を一覧表示します。出力を見て、血の気が引きました。

Data Retries が数百万。正常なクライアントは数千〜数万程度なので、2桁以上おかしい。SNRは35〜36dBと悪くないので、電波強度の問題ではありません。何か別の要因で、この2台のクライアントがフレームの再送を繰り返し、APのエアタイムを食い潰しています。

APのインターフェースカウンターも確認します。

show interfaces Dot11Radio1

show interfaces Dot11Radio0

Radio1（5GHz）で100万以上のドロップ、16回のリセット。Radio0（2.4GHz）も120万ドロップ。APが悲鳴を上げている状態です。

問題の2台は5GHz側。MACアドレスはわかったので、次は「こいつら何者だ」を突き止めます。

Phase 2: MACアドレスからデバイスを特定する

ARP + OUI でメーカーを絞る

ルーターのARPテーブルでMAC→IPを引きます。

次に、MACアドレスの先頭3オクテット（OUI）でメーカーを調べます。

curl -s https://api.macvendors.com/F0:EF:86
# → "Google, Inc."

curl -s https://api.macvendors.com/D4:F5:47
# → "Google, Inc."

2台ともGoogleデバイス。うちにあるGoogleデバイスといえば、スマートスピーカーの Nest Mini が2台。ただ、MACアドレスだけでは「どのNest Miniか」まではわかりません。

Cast APIで正体を暴く

ここで使えるのが Google Cast API です。 Google Home / Nest 系デバイスは、ローカルネットワーク上でポート8008にHTTPサーバーを立てています。認証なしでデバイス情報を取得できます。

curl -s http://192.168.1.19:8008/setup/eureka_info?params=name,device_info

{
  "device_info": {
    "model_name": "Google Nest Mini",
    "manufacturer": "Google Inc."
  },
  "name": "リビングNest"
}

curl -s http://192.168.1.18:8008/setup/eureka_info?params=name,device_info

{
  "device_info": {
    "model_name": "Google Nest Mini",
    "manufacturer": "Google Inc."
  },
  "name": "Nest Mini"
}

ビンゴ。「リビングNest」と「Nest Mini」。Google Home アプリで設定した名前がそのまま返ってきます。

この Cast API（/setup/eureka_info）は Chromecast、Google Home、Nest Hub など Google Cast 対応デバイス全般で使えます。params に name, device_info, net, wifi などを指定すると、デバイス名、モデル、ネットワーク情報、接続中のSSIDやBSSIDまで取れます。トラブルシューティングの武器として覚えておいて損はありません。

Nest Mini が再送ストームの犯人だとわかりました。 ただ、SNRが35〜36dBもあるのに再送が起きるのは不自然です。電波環境側に問題がある可能性が高い。次は干渉源を探します。

Phase 3: 同室の Meraki AP を見つける

ARPテーブルからOUIを一括調査

「同室にMerakiがある」ことは知っていましたが、IPアドレスは把握していませんでした。ルーターのARPテーブル全件をダンプして、OUIを片っ端から調べます。

show ip arp

ARPテーブルから全MACアドレスを抽出し、OUIを macvendors API で確認していきます。その中に一つ、見覚えのないエントリーがありました。

curl -s https://api.macvendors.com/E4:55:A8
# → "Cisco Meraki"

E4:55:A8 = Cisco Meraki。IPは 192.168.1.12 でした。

Meraki のローカル情報を確認

Meraki MR44 はクラウド管理型APですが、ローカルのステータスページにアクセスできます。ブラウザで http://192.168.1.12 にアクセスすると、以下の情報が確認できました。

• モデル: MR44
• 使用帯域: 2.4GHz + 5GHz
• 5GHz チャンネル: CH36〜48 のいずれか（UNII-1帯域）

ここで嫌な予感がしました。自宅APの5GHzは CH44。Merakiの5GHzと完全に同じ帯域ブロックです。

干渉を定量化する

show controllers で電波環境を可視化

Cisco APのCLIには、無線コントローラーの詳細情報を表示するコマンドがあります。

show controllers Dot11Radio1

この出力に含まれる2つの値が重要です。

• p-chan（Preferred Channel）: APが「ここが良い」と判断しているチャンネル候補のスコア
• QBSS Load: チャンネルの混雑度をパーセンテージで示す値。IEEE 802.11e で定義されている指標で、ビーコンフレームに含まれる

変更前の5GHz（CH44）では、p-chan のスコアが 25 と高め（数値が大きいほど干渉が多い）でした。MerakiのCH36〜48と同じブロックで電波が衝突していたことが裏付けられます。

2.4GHz側（CH13）も確認しました。

show controllers Dot11Radio0

QBSS Load は 約8%。後述しますが、これは2.4GHz帯としてはかなり優秀な値でした。

解決策の実施

5GHz: CH44 → CH116（DFS W56帯）へ変更

Merakiとチャンネルが被っている5GHzを、DFS帯域の W56 に逃がします。

configure terminal
interface Dot11Radio1
 channel 5580
end
write memory

channel 5580 は周波数指定で、5580MHz = CH116 です。DFS（Dynamic Frequency Selection）帯域は気象レーダーとの共用帯のため、レーダー検出時にチャンネルを自動退避する仕組みが必要ですが、逆に言えば 一般的なAPやデバイスが避ける帯域なので空いています。

変更後の QBSS Load: 約1.6%。ほぼ干渉なし。劇的な改善です。

2.4GHz: CH13 が最良だった

2.4GHzも最適化を試みました。日本で使える2.4GHzの非重複チャンネルは CH1 / CH6 / CH11 / CH13（CH14は802.11b専用なので実質使わない）。順番に試した結果がこちらです。

CH1 が37%という惨状。2.4GHzのデフォルトチャンネルとして多くのAPが使うため、集合住宅では地獄になりがちです。CH6 もそこそこ混雑。

CH13 が最も空いている理由は、日本の電波法に関係があります。 CH13（2472MHz）は日本を含む一部の国でのみ使用可能で、北米の規制では使えません。そのため、北米向けファームウェアで動作するデバイス（特に安価なIoT機器や一部のスマートホームデバイス）はCH13に対応していないことが多く、結果的にこのチャンネルが空くのです。

元々の CH13 設定が正解だったので、そのまま維持します。

変更前後のまとめ

5GHz の干渉が解消されたことで、Nest Mini の再送ストームも収束に向かうはずです。再送の根本原因は Nest Mini 側のドライバー実装にもある可能性がありますが、干渉環境の改善だけで実用上の問題は解決しました。

学んだこと

今回の調査で得られた知見を整理します。

• WiFi不安定の原因は「見えないデバイス」にあることが多い。 スマートスピーカーのような常時接続IoTデバイスは、ユーザーが意識しない裏で大量の再送を発生させうる。show dot11 associations all-client の Data Retries は最初に見るべきカウンター
• Google Cast API（ポート8008）はローカル調査の強い味方。 /setup/eureka_info で認証なしにデバイス名やモデルを取得できる。MACアドレスだけでは「どのデバイスか」がわからないとき、これで一発
• OUI調査で未知のネットワークデバイスを炙り出せる。 ARPテーブルのMAC全件を macvendors API に通すだけで、ネットワーク上の「知らないAP」が見つかる
• 日本の CH13 は意外と穴場。 北米非対応デバイスが使えないため、QBSS Load が他チャンネルより明らかに低い。日本で2.4GHz帯を使うなら検討する価値がある
• 5GHz の DFS帯（W56）は空いていて効果的。 レーダー検出による退避リスクはあるが、住宅環境では滅多に起きない。干渉に悩んでいるなら試す価値は大きい

WiFiの問題は「なんとなく遅い」で片付けがちですが、APのCLIを叩けば数字で見えます。Cisco APを自宅で使っている方は、たまにカウンターを眺めてみてください。静かに壊滅している可能性があります。