0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

WLANトラブル再現環境の作り方 - ネットワークエミュレーター

0
Last updated at Posted at 2026-07-13

WLANトラブル再現環境の作り方(全体構成編)- 遅延・パケロス・帯域制限を家庭用機材で再現する

はじめに

この記事は、WLAN(Wireless LAN)機器のトラブルを手元で再現するためのネットワーク環境(ネットワークエミュレーション環境)を、家庭用・小型機材で組んだ話をまとめたものです。
※ WLAN はワイヤレスLAN(Wireless LAN)の略で、現場では「ワイラン」と読む(呼称する)ことが多いです。

現場でWLAN機器を扱っていると、「お客様先のネットワークでだけ発生する」タイプの不具合に出会うことがあります。
社内の高速で安定した回線では再現せず、現地の低速・高遅延・パケットロスのある環境でだけ症状が出る、というものです。

そのたびに現地へ行くわけにもいかないので、「品質の悪い回線」を意図的に作り出して、手元で再現・観測できる環境を用意しました。

このテーマは全3回に分けて書く予定です。

  1. 全体構成編(本記事):設計要件と全体構成、機材の役割
  2. エミュレーション編:Orange Pi R1 と tc/netem で回線品質を落とす
  3. 観測編:ミラーポートと Wireshark で通信を見える化する

この記事でお伝えしたいこと

結論から書くと、次の3点です。

  1. 遅延・パケロス・帯域制限は、2ポートの小型Linuxボードを「透過ブリッジ」にして経路へ挟むだけで注入できる
  2. 検証対象の端末には一切設定を入れずに済む構成にできる(ここが重要)
  3. ミラーポート対応スイッチを1台入れておくと、Wireshark での観測が後からいつでもできる

いずれも特別な商用エミュレーター(数十万円〜のアプライアンス)を買わずに、家庭用機材と数千円のシングルボードコンピュータで実現しています。

なぜ再現環境が必要か

WLAN機器のトラブルで厄介なのは、症状の原因候補が複数のレイヤーにまたがることです。

  • 無線区間の問題(電波強度、干渉、ローミング)
  • 有線区間・WAN回線の問題(帯域不足、遅延、パケットロス)
  • 機器側ソフトウェアの問題(タイムアウト設計、再送処理、輻輳時の挙動)

このうち「WAN回線の品質が悪いときだけ機器側ソフトが変な挙動をする」というケースは、良い回線の上ではどうやっても再現できません。
再現できなければ、修正の確認もできません。

そこで、回線品質だけを意図的に悪化させ、それ以外の条件は普段どおりという環境が必要になります。

設計要件

今回の環境は、次の要件で設計しました。

# 要件 実現手段
1 遅延・パケロス・帯域制限を自由に設定できる Orange Pi R1 上の tc / netem
2 検証対象の端末に設定変更を入れない 劣化注入装置を「透過ブリッジ」として経路に挟む
3 通信をパケットレベルで観測できる ミラーポート対応スイッチ + Wireshark
4 実際の回線品質と見比べられる 品質の違う実回線(光・モバイル)も同居させる
5 安価に済ませる 家庭用機材+小型Linuxボードのみで構成

特に要件2は実務上のポイントです。
検証対象にプロキシ設定や特殊なルートを入れてしまうと、「その設定のせいで挙動が変わったのでは」という疑いが残ります。
経路の途中に透過的に挟む方式なら、端末から見える世界は普段とまったく同じです。

全体構成

まず、構成の考え方を役割ベースのブロック図で示します。お手元の機材で組む場合は、この役割が満たせれば同等品で置き換え可能です。

図1: WLANトラブル再現環境(汎用ブロック図)

この図は役割ベースの整理なので、実際の型番やIPアドレスは出てきません。「基準回線」「モバイル回線」「シミュレート回線」という3系統がどこで分岐し、どこで合流するのかという骨格だけを、まず頭に入れてください。

劣化注入とミラー観測という2つの役割は、後述するとおりどちらも1台の小型Linuxボードとスイッチで実現しています。

次に、この役割を実際に使った機材名・IPアドレスへ落とし込んだ、実機構成図です。

図2: WLANトラブル再現環境(実機構成図)

※ SSID・パスワード類は省略しています。IPアドレスはすべてプライベートアドレスです。検証対象の端末は以降「DUT(Device Under Test)」と表記します。

通信経路の骨格

検証対象の端末から見ると、通信は次の経路をたどります。

DUT(検証対象のWLAN端末)
  → (Wi-Fi) YAMAHA WLX-212(検証用AP、192.168.0.80)
  → NETGEAR ミラーポート対応スイッチ(192.168.0.239)
  → Orange Pi R1(透過ブリッジ、br0: 192.168.0.101)★ここで劣化を注入
  → GbE有線ハブ
  → NEC ONU + Aterm(GW: 192.168.0.1)
  → インターネット(AWS上のサービス)

Orange Pi R1 は2つのNIC(eth0 と USB-LAN)をブリッジ(br0)で束ねてあり、L2的にはただの「通り道」です。
この通り道の上で tc / netem を使って遅延・パケロス・帯域制限をかけます(詳細は第2回)。

3系統の回線品質

この環境の面白いところは、品質の異なる回線を3系統用意して切り替えられる点です。
いずれも Fast.com による実測の平均値です。

回線 Down Up 用途
大元の回線(キャリア光10G) 500Mbps 800Mbps 正常系の基準。劣化なしの比較用
モバイル回線(キャリアメーカのモバイル回線ルーター) 15Mbps 6Mbps 「実物の」不安定な低速回線
シミュレート回線(netem経由) 6Mbps 4Mbps 遅延・ロス・帯域を自由に調整できる再現用回線

シミュレート回線は数値を自由に変えられるのが強みですが、「本物のモバイル回線の癖」までは作り込めません。
そこでスイッチのポートにブリッジモードの Buffalo WHR-300HP2/N をぶら下げて、キャリアメーカのモバイルルーター経由(192.168.179.x 系)へ抜ける実回線も選べるようにしています。
シミュレートで再現できた事象が実回線でも起きるか、を突き合わせて確認できます。

機材と役割

使った機材の一覧です。すべて家庭用途で入手できるものです。

機材 役割 ポイント
Orange Pi R1 劣化注入(透過ブリッジ) NICを2つ持てる小型Linuxボード。tc/netemが動けば代替可
NETGEAR ミラーポート対応スイッチ 経路の集約+ミラー観測 ポート2/3の通信をポート1へコピーし、キャプチャPCで受ける
YAMAHA WLX-212 検証用AP兼DHCPサーバー 検証対象へ 192.168.0.152-180 を払い出し
Buffalo WHR-300HP2/N(ブリッジモード) モバイル回線への出口 実物の低速回線へ経路を切り替えるための橋渡し
キャリアメーカのモバイル回線ルーター 実物の低速WAN 192.168.179.x 系。実測 Down 15Mbps / Up 6Mbps
NEC ONU + Aterm 大元のゲートウェイ キャリア光(10G)。実測 Down 500Mbps / Up 800Mbps
ノートPC キャプチャ+実測 USB-LAN(192.168.0.151)でミラー受け、Wi-Fi(192.168.0.150)でFast.com実測

キャプチャPCは、ミラーポートを受けるUSB-LANと、AP配下に入って実測するWi-Fiの2つの顔を持たせています。
USB-LAN側はキャプチャ専用なので、通信に影響を与えません。

構成上の工夫

劣化注入は「ブリッジ」で挟む

Orange Pi R1 をルーターではなくブリッジにしたのは、要件2(検証対象に手を入れない)のためです。
ルーターにするとセグメントが分かれ、DHCPやゲートウェイの設定を検証環境用に変える必要が出てきます。
ブリッジなら、Orange Pi を経路から抜き差ししても他の機器の設定は一切変わりません。「劣化あり/なし」の比較が物理的な差し替えだけでできます。

観測ポイントはAPの外に置く

Wireshark を検証対象の端末やAPの中で動かすのではなく、スイッチのミラーポートで観測しています。
これも「観測行為が検証対象の挙動を変えない」ためです。
無線区間そのもののキャプチャは別の手段が必要ですが、まずは「APから先の有線区間で何が起きているか」が見えるだけでも、切り分けは大きく前進します。

実は最初、スイッチの帯域制限だけでやろうとした

実はこの環境の初期バージョンは、NETGEARスイッチのポート帯域制限機能(512kbps〜512Mbpsを約2倍刻みで設定可能)だけで「遅い回線」を作っていました。
帯域を絞るだけならこれで十分ですし、設定も管理画面でポチポチするだけです。

ただ、それでは遅延とパケットロスが作れません
WLAN機器のトラブルは「帯域は足りているのに遅延が大きい」「たまにパケットが落ちる」ケースが多く、帯域制限だけでは再現できないことが分かり、netem方式へ移行しました。
この経緯と使い分けは第2回で詳しく書きます。

今回の範囲と次回以降

この記事で扱ったこと

  • 再現環境の設計要件と全体構成
  • 3系統の回線品質と機材の役割

次回以降で扱うこと

  • 第2回:Orange Pi R1 のブリッジ設定と tc / netem による遅延・パケロス・帯域制限の実際
  • 第3回:ミラーポートの設定と Wireshark での観測、Fast.com による実測確認

まとめ

  • WLAN機器の「現地でしか起きない」トラブルは、回線品質を劣化させた再現環境があると調査効率が大きく変わります。
  • 劣化注入は、2ポートの小型Linuxボードを透過ブリッジにして経路へ挟むのが、検証対象へ影響を与えない点でおすすめです。
  • ミラーポート対応スイッチを1台入れておくと、観測ポイントを後からいつでも確保できます。
  • 商用エミュレーターがなくても、家庭用機材の組み合わせで実用レベルの環境が作れます。

同じようにWLAN機器やIoT機器の「回線品質起因のトラブル」に悩んでいる方の参考になれば幸いです。

関連記事

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?