IIJ飯田橋オフィスでDFSはどれくらいおきているのか？
2019年12月14日 土曜日
CONTENTS
Twitterフォロー&条件付きツイートで「バリーくんぬいぐるみ」を抽選で20名にプレゼント！
応募期間は2019/11/29～2019/12/31まで。詳細はこちらをご覧ください。
今すぐツイートするならこちら→
フォローもお忘れなく！
【IIJ 2019 TECHアドベントカレンダー 12/14（土）の記事です】
こんにちは、IIJ 金子です。
本日は、無線LAN 5GHz帯でのDFSの発生状況を可視化してみようというお話をします。
はじめに
無線LANを運用していると気になるのは、外来レーダー波により引き起こされるDFS、そしてそれに起因してAPが行うチャネルの移動です。
「今自分がいる場所で、無線LANのDFSを引き起こすようなレーダーはどれくらい打ち込まれているのかしら？」とそんな疑問がふと沸いてきたので、ものは試しにと実際に測ってみることにしました。
無線LANとDFSについて
無線LAN(802.11)にはDFS(Dynamic Frequency Selection)というレーダーとの周波数帯共用の仕組みが存在します。
無線LANが用いている周波数帯の一部、いわゆるW53やW56といった周波数の範囲は気象レーダーや無線標定その他と同居しています。立場の弱い無線LANは、それらの社会的に重要なシステムを邪魔しないように「他のシステムが電波を使っていないか監視する」「他のシステムからの電波を受信したら帯域を明け渡す」といった挙動をするように定められています。DFS対象のチャネルを使うときにはサービス開始までに1分待たなければならない、DFSが発生するとチャネルが切り替わるといった、いわゆる「運用ではDFSに気をつけろ」といった無線LANのノウハウはこういった事情に基づくものです。
上図はDFSが発生した際のチャネルの移動を、Wi-Fi用スペクトラムアナライザで捉えた時のスクリーンショットです。横軸が周波数帯(MHz表記)、縦軸が時間経過を表しています。15:57頃までは敷設したAPが5620MHz(104チャネル)、5700MHz(140チャネル)のそれぞれを使っていたようですが、レーダー波を検知したためかそのチャネルの使用を停止し、別のチャネルに移動しているのが見て取れます。またこれに伴ってチャネル配置の最適化が行われたためか、ほとんどのAPがこの時間を境にチャネルを変えているようです。
さて気になるのは、このDFSが自分たちが使っている・作っているインフラでどれくらい発生しうるかです。こればっかりは「運用してみないとわからない」というのが正直なところです。これまでさまざまなイベントにて無線LAN提供を行ってきた経験から「海に近いと起きやすいらしい」「都内でも窓辺だと起きることがあるらしい」といったふわっとした感触はあります。この感触が外れる事もあれば大当たりのこともあります。たとえば以前「12/2 Maker Faire Tokyo 2019でイベント無線LANを提供してきましたレポート」で紹介させていただいたMaker Faire Tokyo 2019では、特定のチャネル、特定の場所において頻発している傾向がありました。以下はその頻度を時間軸上にプロットしたものです。
日本国(総務省)においては以下の資料のように、このDFSの対象となる周波数帯を無線LANを含む各システムに分配しています。しかしその詳細、たとえばどこのだれがいつ頃使うか、については(ほぼ)どこにも記載されていません。他のシステムから見た場合にも、どこでだれが無線LAN APを立てるか分からないということを考えればお互い様ではありますが…。
たとえば気象レーダーのように場所や利用する周波数帯の情報が公開されている分かりやすいシステムであれば、APの位置からW53帯のレーダー源としてなんとなくの憶測を立てることはできます。
しかし気象レーダーにおいても周波数を網羅した情報がどこかにまとまっているわけではありません。この地図においても一部の局では周波数が判明していますが、大多数では場所が分かる程度です。また実際に発射されるタイミングについて記載があるわけでもありません。
W56帯では、小電力データ通信システム(無線LAN)と「海上無線航行」「移動(航空移動を除く)」「地球探査衛星(能動)」「宇宙研究(能動)」「無線標定」といったシステムが同居している、という記載があります。気象レーダーについては最低限場所だけは分かっていましたが、これらについては陸海空のどこからいつ飛んでくるか予想もつきません。
このように「実際にやってみないとわからない」のであれば、実際にやってみるしかありません。
ということでその場で発生したDFSを可視化してみようと仕組みを作ってみたというのが今回のお話です。これにあたってIIJが開発している無線LAN機能搭載サービスアダプタ SA-W2、それらをコントロールするSACMサービス、そしてメトリック監視・可視化サービスである Machinist を組み合わせてすべてのチャネルをくまなく監視できるようにしてみました。名付けて「DFSゼッタイ検知君」です。
SA-W2 x SACM x Machinist
SA-W2はIIJが開発している無線LAN機能がついたルータアプライアンスです。その大きな特徴は「サービスアダプタ」として、これまたIIJが開発しているSACMというマネジメントシステムで集中管理が可能な仕組みを搭載しているという点です。SACMを利用することで、全国津々浦々に分散した大量の機器でもコントロールパネルから一括して設定・監視・管理を行うことが可能です。以前に紹介させて頂いた Maker Faire Tokyo 2019でのイベント無線LAN提供でもこの機能をフルに活用していました。
この集中・一括管理機能そしてテンプレート機能を使って、用意した大量のAPを設定&制御しDFSの発生を漏れなくキャッチできる環境を構築します。
さてせっかく手広くキャッチできる環境を作ったとしても、その情報を集約し蓄積しかっこいい画面・UIで可視化できないことには「その場のDFSの発生状況を完全に把握した」とは言えないのではないでしょうか。
そこで今回はDFSの発生状況を、IIJが開発しているMachinistサービスに集めることで蓄積と可視化を行うことにしました。Machinistについては本ブログの「Machinistでメトリクスを管理する」や「Vim で起きているイベントを Machinist で可視化する」でもご紹介してきました。時系列データの可視化が得意なMachinistサービスを用いることで「データの溜め」と「見映え」をどうするかといった悩ましい部分を自分で構築せずにアウトソースすることができます。
今回、DFSの発生からこのMachinistへの可視化へと繋げていく部分にはfluentdを用いました。このfluentdとMachinistとの組み合わせを行うための、fluent-plugin-machinist のgemパッケージおよびソースコードも併せて公開しました。
Machinistを用いた可視化にご興味がありましたら是非こちらをご活用ください。
インストール方法は以下の通りです。
% fluent-gem install fluent-plugin-machinist
DFSゼッタイ検知君
DFSを「漏れなく検知」するために今回は以下のような環境を作りました。
普通にSA-W2をAPとして動作させた場合でもDFSの発生を引っ掛けることは可能です。しかしここで必要なのはそれぞれのチャネルではなく、全てのチャネルを見ての傾向を知ることができるということです。時分割多重で一つ一つチャネルを舐めていく程度では「漏れなくキャッチ」できているとはいえません。そこで全てのチャネルを同時にカバーできるように、大量のSA-W2を並べることにしました。
オレンジ色のラベルが貼ってある黒い機材一つ一つがSA-W2です。これらはもともとJANOG41やMaker Faire Tokyo 2019といったイベント無線LAN提供用に確保してある部材です。そういったお外での出番がない時は、さまざまなテストを行う環境として上図のようにラックに常備されています。上図では1列10台、4列で計40台のSA-W2が搭載されています。
5GHz帯にてDFSの対象となるチャネルは52〜140チャネルまでの合計15個のチャネルです。上記40台のSA-W2のそれぞれにシーケンシャルにチャネルを割り振り全てのチャネルを1台以上でカバーできるようにします。
(なおここではきちんとチャネルがアサインされていることの確認のためにSSIDが見えるようにしていますが、実際の観測の際にはその必要はないため「ステルスSSID」機能を有効にしています)
SACMではこういった”ベースは同じだけれどちょっとずつパラメータが違う大量の機器の設定”も下図のようなテンプレート機能を使うことで簡単に実現することができます。
DFSの発生を検知するには、APが出力したログを収集・検査することで行います。SA-W2は、レーダー波を検知すると”Radar found on channel #{チャネル番号}”といった書式のログを出力します。fluentdにてこのログをsyslogで受信、フィルタでこねくり回してMachinistに送信します。Machinistに投げ込む部分については先にご紹介した fluent-plugin-machinist を利用しました。
syslog文字列そのままではMachinistに投げ込めないため、syslog文字列を受けてgrepフィルタで選別 → parserフィルタでチャネル番号の抽出 → record_transformerフィルタでevent = 1 となるようなキーバリュー形式に変換しPOST、といったひねり方をしています。実際に使ったfluentd.confについてはAppendixをご参照ください。
これらを組み上げることでMachinistのUI(下図)上でチャネルごとのグラフが生成されます。
個々のチャネルのグラフは以下の通りです。折れ線グラフだと横一直線になってしまい見づらいですが、棒グラフにするとDFSの発生時刻にパルスのように見えるようになり便利です。
一つ一つ見ていくのは大変なので、「カスタムチャート」機能を使って全てのチャネルのグラフを通しで見られるようにしてみました。
実際に動かしてみる＠IIJ飯田橋オフィス
さて作ったからには動かしてみましょう、ということで弊社飯田橋オフィス内にてしばらく動かしてみました。観測場所は地図上の以下のポイントにあたります。
地上高80mあたりのオフィスフロアの窓際に、先のラックを設置し観測を行いました。
1週間ほど観測し続けたところ、稀に下図のように56や60チャネルといったW53帯でのレーダーを検知していたことがありました。周波数帯からすると気象レーダーなどでしょうか。
また別日では下図のように116チャネルでのDFSイベントが数回発生していました。先にも述べたようにW56帯の場合、何がこの帯域でレーダー波を発射しているかは不明です。
しかしこのような観測を中期的に続けていくことで「このチャネルはなにかありそうだな」「このチャネルは何も飛んでこなくて、この場所では平和そうだ」といった傾向を知ることはできました。
APを対象としたサーベイと併せることで、より環境に”悩まされない”無線LAN設計のための事前情報の一助としてこういった情報も役立ちそうです。
おわりに
本稿ではSA-W2、SACMそしてMachinistを組み合わせることでDFSの発生状況を可視化する取り組みについてご紹介しました。
環境がそれなりに大きいため、実際の無線LAN環境敷設前のサーベイでこういった綿密なチェックをするのは難しいでしょう。
しかしいつどこで発生するか分からない「ガチャ」要素のあるDFSを少しでも知るにあたり、こういったやりかたもあるといったアイディアの参考になれば幸いです。
Appendix: fluentd.confの例
今回の観測にあたり用いたfluentd.confを記載します。ここでは以下の流れでログからMachinistのメトリック形式への変換を行っています。
- syslogを20514ポートで受信
- grepフィルタでレーダー受信イベントのログのみを抽出
- parserフィルタでレーダー受信イベント発生チャネルを”channel”として取り出し
- record_transformerフィルタでevent=1のレコードに変換 (Machinistのメトリックとして1を投げ込むため)
- machinistプラグインで先ほどのevent=1をメトリックとしてPOST、ネームスペースとして先に取り出したチャネル番号(channel)を指定
<source>
@type syslog
port 20514
bind 0.0.0.0
tag syslog
</source>
<filter syslog.**>
@type grep
<regexp>
key message
pattern /Radar found on channel/
</regexp>
</filter>
<filter syslog.**>
@type parser
key_name message
<parse>
@type regexp
expression /Radar found on channel (?<channel>\d+)/
</parse>
</filter>
<filter syslog.**>
@type record_transformer
<record>
event 1
tag dfs.value
</record>
</filter>
<match syslog.**>
@type copy
<store>
@type machinist
endpoint_url https://gw.machinist.iij.jp/endpoint
agent_id XXXX-XXXX-XXXX-XXXX
api_key XXXXXXXXXXXXXXXX
use_ssl true
verify_ssl true
value_key event
namespace_key channel
</store>
<store>
@type stdout
</store>
</match>
