JANOG41 Wi-Fiチーム報告書2(当日の様子) | IIJ Engineers Blog

JANOG41 Wi-Fiチーム報告書2(当日の様子)

2018年07月10日 火曜日


【この記事を書いた人】
金子 直矢

IIJ ネットワーク本部IoT基盤開発部 デバイス技術課所属。 802.11(無線LAN)技術を中心に、ルータ/AP製品の開発に従事しています。 電波が好物なのでイベント無線LANの構築をしたり、キャプチャ箱持って電波吹いてそうなところをうろうろしています。

「JANOG41 Wi-Fiチーム報告書2(当日の様子)」のイメージ

JANOG41 Wi-Fi 会期の運用

こんにちは、JANOG41 NOC(Wi-Fi)チームの金子です。

さて、前回の記事”準備編”に引き続きここでは、当日の無線LANの様子をご紹介します。
JANOG史上最大の登録者ならびに来場者数とのことで、ホストであるIIJとしては嬉しい悲鳴です。が、同じく無線LANでも悲鳴が上がっており現地の皆様には大変ご迷惑をお掛けいたしました。
ここでは会期における会場無線LANの概況と、構築・運用で発生していたトラブルをピックアップして紹介します。中には「当たり前だろ」というお恥ずかしいトラブルもあるのですが、今後の糧ということで率直に記載しております。また本稿で挙げさせて頂いた以外にも裏でいろいろと起きているのですが、全てを列挙すると結構なボリュームとなるためここではその主要なものをご紹介します。

JANOG41Wi-Fiの概況

今回提供させて頂いたJANOG41 Wi-Fiは統計値としては以下の様な結果となりました

  • 来場者数: 1171人 (公式発表より)
  • ユニーク無線LAN端末数: 1559台 (1.42台/人)
  • 最大同時接続数: 849台 (1/25 14:20時点、72.5%)
  • eduroamユニーク利用者数: 44人 (3.8%)
  • eduroamユニーク利用端末数: 75台 (全端末中 4.8%、1.7台/人)
  • eduroam認証利用ユーザ所属組織数: 23組織
  • 会場内LANケーブル総延長: 1.77km (69本、10m以下の短尺系および追加部材を除く)

ダウンロードトラフィックおよび会場全体での無線LANクライアント端末同時接続数は各日で以下の様に遷移していました。ここで掲載するグラフはIIJが開発しているMachinistを用いて記録・描画したデータです。トラフィック量については 以前の記事「JANOG41 BBチーム報告書 (当日の模様)」 でも紹介させて頂いていますので、是非併せてご覧下さい。

トラフィック(ダウンロードのみ) 無線LAN端末同時接続数
Day1
Day2
Day3

これまでWi-Fiチーム(およびそのコアとなっているSEILチーム)で手がけたイベント無線ネットワークでは、ユニーク端末数ではコミケットスペシャル6の2000端末弱、同時接続数ではJICS2017での450端末強が最大でした。特にJANOG41では同時接続数においてこれまでにない規模だったこともあり、設計の不備やトラブル等でご迷惑をお掛けいたしました。

eduroamについては「eduroam、吹きます@JANOG41会場」でも紹介させて頂いたようにセキュア公衆無線LANローミング研究会 (NGHSIG)様のご協力で提供させて頂きました。参加登録者の一覧から学術機関の数を調べるとおおよそeduroam認証利用ユーザ所属組織数と一致し、一通りアカウントをお持ちの皆様にはご利用頂けたようです。ありがとうございました。

なお、今回のeduroam提供に関してはNGHSIG様を通して学術機関のみならずANYROAMの認証基盤にも接続しておりました。このため、実はプロファイルさえANYROAMで取得(SMSが必要)していただければどなたでも使うことが可能でした。特に無線LANレベルでの盗聴を気にされる方にはこちらのご利用がお薦めだったのですがあまり告知ができておらず、テスト用に繋いでいた自分の端末以外の接続はありませんでした。

JANOG41 会場無線LAN 事件簿

これまでにもいくつかのイベントにて無線LAN提供をしてきたWi-Fiチームですが、毎度何かしら「想定外」が起き一筋縄では行かない中、様々な新しい発見や学びを得てきました。今回もその例に漏れず、広島という遠隔地、1000人を優に超えるネットワークのプロである皆様のご来場、グローバルIPv4アドレス配布といった新要素によりこれまた様々な「想定外」が発生しました。

ここではそのうちのいくつかについて事件簿といった体裁を取ってご紹介します。

不足した道具・工具

特に遠隔地におけるイベント無線LAN構築・運用にあたっては、ネットワーク以前にそのための各種道具・工具・機材を揃えたりパッキングしたり運搬といった物理的なお膳立てが重要です。そして大抵の場合、万全を期して準備をしたつもりであっても現地で「想定外」が発生し調達に走るといったことが起きる場合があります。

今回の「想定外」はショックレスハンマーと、S字フックでした。

まずはショックレスハンマーについてです。今回、機材類の運送にはヤマト運輸のJITBOXチャーター便を利用したのですが、前日現地入りした際にそのカーゴが開かず荷物が取り出せないというトラブルがありました。

JITBOXの前面のパネルががっちりと歪んだフレームと噛み合っており、人力ではどうにも外せないという状態でした。また今回は指定の場所にカーゴごと残置して納品という形態だったため運送してきてくださった方はすでに撤収済み。
こんなことはあろうかと我々が持ってきたショックレスハンマーは、当の開かないカーゴの中というありさまでした。

幸いにして会場の方からハンマーをお借りできたため無事開梱および荷物チェックと翌日の構築作業に向けての下準備を進めることができましたが、やれハンドキャリーした部材で叩けるものはないかホームセンターまでいくっきゃないぞなどと、こういったこともあるのだと新しい知見を得ることができました。ダンボールに詰めてそのまま送付する場合を想定して、はさみやカッターなどは別途ハンドキャリーしていくようにしていましたが、JITBOXを利用する場合にはショックレスハンマーがあるとよい場合があるようです(着荷次第その場で降ろしてカーゴは回収といった流れが多いので大抵の場合は不要そうですが…)。

S字フックについては、APの高さ確保のために現地で調達しに走った部材でした。

B1F展示スペースに設置していたAPは隠れやすい位置にあり特に人が多い場合に遮蔽されやすく、スペース中央付近にて通信がしづらい場合がありました。特にこのエリアには椅子&机が設置され、ちょっとしたお仕事をしていただけるような場所として提供しておりました。

これを改善するために高さを稼ぐべく譜面台から、展示社各社様にご協力頂きパネルの裏やポスタースタンドへの釣り下げといった変更を行いました。

 

この際に必要になったのがS字フックです。今回部材としては事前に用意していなかったため急遽近隣の100円ショップに走り必要数を調達しました。

今回の会場ではケーブル養生時に出番はなさそうだったため、部材からS字フックあるいはマグネットフックは省いていました。が、なんらかの事情で変更が走りつり下げが必要になる場合というのを想定して一定数は持っておくと良いようです。

今回のように、緊急で調達に走る可能性を考慮して特に遠隔地でのイベント無線LAN提供の場合は調達先のリストを作成しています。以下の様に近隣の電化製品店、100円ショップやホームセンターなどをマップとしてまとめておくと便利です。また、会場下見の際はこれらの近隣設備についても道中で見ておくと後々役に立つことがあります。

設備既設LANの断?

Day3の17:30頃、もうそろそろ閉会宣言が始まり次回JANOG42のホストであるZTV様へのバトンタッチができようやっと肩の荷が下ろせそうだというその時に事件は起きました。フェニックスホールへの疎通が完全に失われてしまったのです。その時の発生事象を端的に図示しているsmokepingと、トラフィックグラフのキャプチャを以下に記載します。

smokepingの方ではどうやらsw-p01なるホストとの疎通が17:25~17:40あたりに掛けて失われていたらしい、トラフィックグラフの方では同じ頃にUp/Downともにトラフィックが激減しているらしいというのが見て取れるかと思います。

このsw-p01と名付けられたホストはフェニックスホールを収容していたスイッチであり、smokepingの結果から以下のネットワーク図において×印が付いていたリンクがこの時間に突如として疎通不可となったのでした。

スケジュール上最終セッションであったため、ほぼ全ての方がフェニックスホールに集まっていらした時間帯でした。幸いにして2階席の系統は生きていたのですが、来場者の方の大半は1階席にいらっしゃることに加え配信設備もそちらに属していたため、トラフィックグラフ上では流量が激減し、以前のブログ「JANOG41 中継の模様」にて触れた配信トラブルに至ってしまいました。

Wi-Fiチームでは、この事象を検知後すぐにこのスイッチおよびリンクの両端に駆けつけトラブルシュートを開始しました。が、結局のところ両端のどちらのスイッチにも異常はおろかリンクダウンした形跡すらないという状態でした。そうこうしている内に結果としては「何もしてないのに壊れ」、そして「何もしていないのに直」り17:40に正常復旧を確認しました。その後、改めて機器のログを参照しつつ原因調査を行いましたがやはりスイッチ側には手がかりはありませんでした。

ケーブル不良やスイッチのバグなど様々な可能性が考えられますが、原因の候補としてスイッチ間に挟まっていたメディアコンバータおよびファイバーケーブルの不調の可能性を考えています。

ルータやコアスイッチが置かれているダクトスペースはB1F、フェニックスホールのコア設備はB2Fに置かれており、その間は構内既設ファイバーを経由して結線しています。この間には上記の様にメディアコンバータおよびローゼット(おそらく裏にメディアコンバータがある)が挟まっています。

本番前に行った現地調査時でもこの光のリンクの不調が発生していたため、すぐ回復していたとは言え注視しておくべきだったかもしれません。迂回策としては、2箇所ほど別の場所から似たような構内既設LANが出ていたためそちらをLAGまたはSTPで束ねて冗長化して使うという案もあったのですが構築時間の制約からシングル構成で行くこととしました。

大盛況だったダリア、の無線LAN

設計時の想定の甘さと、あまりの大盛況さにもっとも悲鳴をあげていたのがBoF会場となっていたB2Fのダリアでした。

特にDay1は立ち見がでるほどだったとのことで、ホストとしては嬉しい悲鳴、ネットワークとしては楽しい悲鳴が上がりました。会場無線LANで通信出来ない、リモートプレゼンを予定していたができなかったとのことで大変にご迷惑をお掛けいたしました。

以降ダリアにおける収容設計、配置設計、有線LAN提供においての反省点を見ていきます。

まず収容設計の点です。APの配置にあたってはカバレッジと収容者数の2軸を上手く両立させる必要があります。今回の設計では、主軸としてカバレッジに寄せすぎた一方でその方向性においても不十分だったという反省点があります。

席数ベースで考えると、ダリアの各部屋のそれぞれでセミナー形式の席配置を取った場合は3人掛けテーブルが8行6列となり100~144人の方が座れる計算です。それぞれの方が、ノートPCをメインに通信するとして1APあたり30~40台程度の端末収容数を目安に配置を考えていくと、各部屋に4~5台程度は必要でした。

Day2以降はこれをベースに各部屋5台程度として増強を行いました。また、Day1はAP間で接続数の偏りが大きかったため先の範囲でバランスするように設定を変更し安定化を試みました。

しかしDay2以降もダリアでは通信が不安定になる事象が頻発しており、後述するAPの配置・設置の問題およびARPによる影響等があったものと見ています。

次に配置設計の点です。上記の通りDay1およびDay2以降ともに基本的には壁際にAPを設置しています。これは下記の通り別イベントにて適用した配置設計を、構築時間とのトレードオフのためそのまま引き継いで適用したのですが今回に関して言えば不十分だったと考えています。

まず前方における配置についてです。もちろんどう来場者の方が座るかに依存しますが、これまで見てきたイベントの傾向として比較的発表者方向つまり前方のAPに接続が集中することが多いという認識を持っています。これに反して今回の配置設計では、中~後方よりな配置を主軸としていました。前方を特に重点的にカバーしつつ、席中に入っていく形での増強も視野に入れたほうがより安定化に繋がったかもしれません。

また設置についても不十分な点がありました。ダリアでは、譜面台の不足から現地にあった椅子の座面にAPを設置したのですが、以下の様に低すぎました。

上記別イベントでも1m程度の高さには設置できていたため、今回ももう数十cm程度高さを確保すべきでした。理想的には先に挙げたようにポスタースタンド程度の高さですが、ちょうど席に座った人の頭の位置よりは高い位置に設置出来るよう工夫をすべきでした。

また今回のAPでは飛び過ぎを懸念して出力を下げ目で設定していましたが、先に挙げた展示スペース同様に人の壁に阻まれて届かないことによる通信不安定というケースが何件か発生していました。世の中には人の壁を想定して通信可能範囲を制御するというテクニックもあるようですが、その道に至るまではまだ長いようです。

最後に、壇上に有線LANを完備すべきだったという反省があります。これは特にDay1のBoFにおいてリモートプレゼンができなかった点の対策です。今回、有線LANを提供する先としてヒアリングを行いフェニックスホールの壇上と各配信席にという要望は認識していました。が、それ以外でも発表者が利用しうる全ての位置に先回りして配線・共有しておくべきだったと考えます。

グローバルIPv4アドレス配布の大規模無線LAN

会場で何気なくWi-Fiインタフェースにてパケットキャプチャをした方は、ご自身のPCにて以下の様なフレームが流れ続けていたのをご覧頂けたかと思います。

BBチームの報告書でも触れたように、今回の会場無線LANではグローバルIPv4アドレスを来場者の皆様に配布していたため、外からのスキャンその他により会場内に常に400~600ppsのARPフレームが流れていました。こうなることは事前に聞いてはいたため「想定外」とは言えないのですが、「想定外」に対処が上手くいっておらず振り回されておりました。

大規模無線LANにおけるマルチキャストフレームの多発は、全てのAPにおいて利用するチャネルのエアタイムを消費することになるため抑制するのが安定運用の必須要件となります。一般的にはネットワーク内に最も数が多い無線LANクライアントが送信するマルチキャスト/ブロードキャストフレーム(ARPやND、Bonjourなど)が問題となるため、以下の様にAPではプライバシセパレータやクライアント分離機能、スイッチではプライベートVLAN機能によりこれを抑制するといった方法が採られます。

しかし、今回は横同士のマルチキャストフレームではなく、キャプチャからもおわかり頂ける様にJuniper OUIつまり会場ルータであるMX80により”上”からARPフレームが降り注いでいる状況でした。これは上記の構成ではブロックできません。またこのARPフレームは各APに来てSSIDごとに増幅されます。今回はSSIDとして、通常の来場者用とeduroamを吹いていたため、2倍に増幅される結果となりました。

他社の一部APでは、「マルチキャスト最適化機能」としてマルチキャストフレームを枝狩りし、必要なものはユニキャストフレームに変換して送信するといった機能をサポートしている製品があります。これによりフレーム数の削減とユニキャスト変換により可能となる転送レートの向上によりエアタイムの消費を抑えることが可能です。残念ながら今回会場で用いていたSA-W2含む持込AP機材にはそういった機能がなかったため、接続しているクライアントが居る限り空間中に最大800~1200ppsのARPフレームを流す様になっていました。

結果として、特に2.4GHz帯では通信困難な状況や通信が不安定な状況を発生させてしまっていたようです。また5GHz帯でも、チャネル使用率から見てARPフラッディングを直接的な要因としているかは検証中ですが、会場内全域においてRTTが不安定な状況が継続していたようです。

このARPによる影響を改善するため、ルータ・スイッチ・APの各ポイントで対策の検討・実施を行いました。

APとしては、マルチキャスト転送レートの向上およびこれに対応していないAPの撤去を行いました。SA-W2はベースレート(マルチキャストデータフレームやマネジメントフレームの転送レート)を制御できる機能があるため、これを当初設定値の24Mbpsからえいやと54Mbpsにまで上げてエアタイムの消費を抑制するようにしました。

一方で、フェニックスホールに設置していたGoBeamはこのタイミングでサービスを停止しました。このAPは、その非常に良く飛ぶ性質を活かし単機でホール全体に2.4GHz帯を提供しバックアップとして5GHz帯も提供すべく設置していました。が、ベースレートの変更機能に対応しておらずこのARPフラッディングの影響を大きく受けその飛びやすさが裏目に出ていたため停波としました。常時130台程度接続していたため少なくともこの数のユーザが上手く通信出来ていなかったと推測されます。

以下は2.4GHz帯における空間中のマルチキャストフレーム(=ARPフレーム)の消費したエアタイム(マイクロ秒)のDay3における遷移です。午前中は赤い線で示される11チャネルにてGoBeamにより2.4GHz帯を提供していましたが、午後からSA-W2 3台で置き換えました。これにより利用可能エリアは狭まりましたが、以下の様にARPにより過剰にエアタイムが消費されるといった状態を改善できていたようです。現地でもある程度通信状況が改善したことを確認しています。

ただし、一部のエリアでは転送レート向上によるエアタイム消費の削減を行っても不安定さが継続することがありました。

この点を受けて、事後検証としてマルチキャストフレーム多発環境でのエアタイムの変動調査とその通信への影響について検証を行っています。以下の図はその一環としてARPの流量、マルチキャストフレーム転送レート(mcast rate)を変えた際にチャネル使用率がどう変動するかを観測したものです。

この環境下でそれぞれping RTTやiperf等による通信速度の計測を行いパラメータの影響調査を行っています。観測結果としては確かに2.4GHz帯ではエアタイムが80%に張り付き明らかな不安定に繋がることが言える一方で、チャネル使用率上まだ空きがある5GHz帯では単純な環境ではマルチキャストフレームの有無は影響しないように見受けられ、会場で起きていた事象と一致しません。この点については引き続き検証が必要そうです。

最後に

本稿では、JANOG41Wi-Fiの会期中の概況と構築・運用の中で発生したトラブルや出来事をトピックとして取り上げさせて頂きました。

今回のイベントネットワークは上流が10GbE & JANOGにとっても我々にとっても最大規模とのことで、802.11acなAPを一通り揃えどうにか瞬間的にでも1Gbpsを超えたるぞーという意気込みでいたのですが残念ながら様々なトラブルに振り回された結果それに遙かに及ばずという残念な結果に終わりました。

しかしながら今回も様々な「想定外」な事象から新しい機能あるいはツールや構築・運用方法といったものに向けての知見を得ることができたと考えています。これらをまた次回の快適なイベント無線LAN提供の実現に活かしていきたいと思います。

JANOG41の会場にて無線LANをご利用くださった皆様ありがとうございました。

金子 直矢

2018年07月10日 火曜日

IIJ ネットワーク本部IoT基盤開発部 デバイス技術課所属。 802.11(無線LAN)技術を中心に、ルータ/AP製品の開発に従事しています。 電波が好物なのでイベント無線LANの構築をしたり、キャプチャ箱持って電波吹いてそうなところをうろうろしています。

Related
関連記事