ICTSC, イベント, インフォメーション, セキュリティ, ネットワーク

学生による学生のためのトラブルシューティングコンテストが始まりました。
8/29、30の2日間、熱い戦いが繰り広げられます。

関連エントリ→学生による学生のためのトラブルシューティングコンテスト

ICTSC4ICTSC4

ICTSC4ICTSC4

wifi, ネットワーク, 運用管理

調査しに行く

前回の記事: つながらない無線LAN!?(1/3)導入編

無線LANが繋がらなくなっている状態のオフィスに赴き、調査します。

事前のヒアリングでは 「快適に繋がるときと調子が悪いときがあり、混み合う時間帯で特に繋がりにくい」 とのことでしたので、電波が届きにくい箇所があるというより混雑しているのではないかと予想しました。

席数に対してアクセスポイントが少なすぎると思われる地点もあり、収容能力を超えている可能性も考えました。このようなケースでは、利用者が多い時間帯を狙って電波の状況を測定する必要があります。

ツール

Metageek WiSpy

電波を可視化する、周波数帯のなかで電波がどんな強度、密度、タイミングで存在するかを見るツールです(スペクトラム アナライザ)。同じ帯域(2.4GHz, 5GHz)に出ている電波なら無線LANに限らず、電子レンジや Bluetooth, ZigBee, 気象レーダーなどの電波も表示できます。特に 2.4GHz帯(ISMバンド)では、無線LANから存在が見えない種類の電波利用がとてもたくさんあり、互いに衝突するものも多いため、存在を可視化することは大切です。

なんでも受信できますが、その内容をデコードすることはできないため、何の電波か見分けるには慣れが必要かもしれません(最終的にわからないことも多い)。

また、広い周波数帯をスピーディに把握でき、干渉源の把握以外にも役立ちます。inSSIDerのような無線LANのビーコンをスペクトラムに重ねて表示できます。

FlukeNetworks AirMagnet WiFi Analyzer

非常に多機能な無線LANアナライザです。無線LANを完全にデコードでき、具体的な問題の特定に役立ちます。WiSpy が電波の存在を見るツールだとすれば、こちらは電波の中身を解釈できるツールです。

無線LANのトラブルシューティングでは、電波の存在だけを見ればわかる低レイヤな問題と、実際に無線LANの中を見てみないとわからない問題があります。AirMagnet は中身を解析し、膨大な情報を非常に見やすい形に整理して表示してくれます。無線LAN以外の電波を見ることはできません。スペクトラムアナライザよりレイヤが高いツールといえます。

inSSIDer, WiFi Analyzer, WiFi Explorer

もっとも身近な無線LAN調査ツールかと思います。AirMagnet, WiSpy は専用のハードウェアを必要とし、必ずしも導入しやすい価格でないかもしれないのに対し、inSSIDer, WiFi Analyzer, WiFi Explorer は PC やスマホの WiFi デバイスを利用した、無料ないし安価なツールです。

これらのツールで可能なのは、無線LANアクセスポイントの存在の検知とその電波強度を調べることだけです。高密度無線LAN環境で起こりがちな、電波が強いのに速度が遅かったり不安定である状態や、実際にアクセスポイントがどれくらい利用されているかなどを調べたいときにはあまり役立ちません。でも、とても軽くて手軽なので、前述のツールと併用することはよくあります。

他に無料で実現可能な手法として、モニタモードで動作できる無線LANデバイスを Wireshark などで見る方法もあります。その気になれば AirMagnet の一部機能のように無線LANの中身を調べることができますが、深い知識と根気が必要な方法かと思います…。 (トラブルシューティングではちょっとやりたくないですが) 取得したい情報があらかじめ決まっているのであれば、たとえば Python のモジュール Scapy には Dot11 Layer が用意されていますので、ツールを作成して解析することも可能です。


測定結果をいくつかご紹介します。

地点A

high_utilization_slow_datarate_s
遅いデータレートと高すぎるチャネル使用率

遅いデータレート(1Mbps)でチャネルの約74%が使用済になっています。スループットが1Mbpsも出ていません。この状態では遅いながらもかろうじて通信はできていますが、これ以上のトラフィックを流そうとすると、無線LANは切れてしまうと思われます。

このときは、複数のポータブル WiFi ルータが存在したようです。実際にデータがたくさん流れておらず、多くがビーコンとプローブ レスポンスでした。ビーコンとは、アクセスポイントが SSID などを含めた基本的機能を送信し続ける制御トラフィックで、端末はこれを受信するとアクセスポイントの一覧に SSID が表示されます。
データをたくさん流していなくとも、アクセスポイントが大量に存在することによって制御トラフィックでチャネルが使い切られてしまい、ろくに通信ができないという本末転倒の状況にあります。

5GHz_HighUtilization
高すぎるチャネル使用率, W53, W56利用なし

こちらは5GHz帯です。40ch, 48ch のチャネル使用率が高いことがうかがえます。また、52ch以上のチャネルが利用されていません。アクセスポイントは5台以上見えているので、DFSか、と思ったのですが、52ch以上がまったく利用されていないのは不思議です。

※DFS: 52ch以上(W53バンド以上)の無線LANでは、同じ周波数帯を共用する気象レーダ等を検出し、検出された場合はそのチャネルでの電波の送信を停止することが義務づけられています。アクセスポイントは、そのチャネルの利用をやめ、他のチャネルをランダムに選択します。レーダの検出により、利用可能なチャネルが減ることになります。レーダの検出は、窓際や見晴らしのよい場所に設置されたアクセスポイントで起こりやすく、建物の奥まったところでは比較的起こりません。

地点B

2.4G_overlap_s
ノイズが多い2.4GHz帯

有線LANで接続されたPCが多いエリアです。アクセスポイントへの接続端末数は多いのですが、それほどトラフィックは多くありません。しかし、上下フロアおよび外からの電波、野良アクセスポイントによって利用チャネルがオーバーラップしてしまい、干渉しあっています。

問題

  • チャネル利用率が高すぎる
  • 遅いデータレートでチャネルが埋まっている可能性が高い
  • アクセスポイントに対して端末数が多く、収容能力を超えている箇所がある
  • 電波が弱いエリアはほとんどない

測定により、以上のような状況が把握できました。何ができるのか考えてみたいと思います。

無線LANの電波を伝える空間は共有されているため、理想的な状態にできるとは限りません。外や上下フロアなどの自社の管理下にない装置から飛んでくる電波、持ち込まれるポータブル WiFi ルータやテザリングなど。免許不要の無線は、国が電波の交通整理をしないから混信を許容せよ、ということでもあります。できることからやっていこうと思います。

続く

wifi, ネットワーク, 運用管理

あらまし

x月x日、某社オフィスで
「社内無線LANが使い物にならず非常に困っている」
という相談を受けました。

特に繋がらない場所は会議室であり、iPadでFaceTimeを使ったテレビ会議をしようとすると、映像がブラックアウトしたり音声がブチブチ切れるという悲惨な状況だというのです。さらに会議室以外でも通常なら数分終了する構成管理ツールが、なんと70分も掛かるなどの事例が報告され、社員は無線LANに対して大きな不満を抱えているとのこと。つまり……

今すぐ解決してほしい!

ということです。今すぐに解決できるわかりませんが、まず調査してみて、対処できることからトライしてみようと思います。

無線LANが不安定になる原因

  1. 電波が弱い
  2. 混雑している

オフィス無線LANが不安定になる原因の多くは混雑です。同時に多数の端末が通信できているように見えますが、有限のチャネルを時間で分割して利用しています。

ひとつのチャネルを5台の端末で共有
ひとつのチャネルを5台の端末で共有

無線LANの特徴として、端末ごとに通信状況が異なることがあげられます。これは、伝送媒体の品質が保障できる有線と違い、電波の状況が悪くなっても接続を維持できるように、端末ごとにデータレート(bps)をつねに変化させています。電波状況は刻一刻と変化していますので、それに追随してデータレートも常に自動調整されています。

OS X では Option + 無線LANアイコンクリックで 現在のデータレートなどを確認できます。電波の状況があまり良好でないときは、クリックするたびに数字が変化しているのを見ることができるでしょう。

そのうち一台(オレンジ色)の端末が遠くに行ってしまい、電波状況が悪化したため、データレートが 2Mbps まで低下したとします。すべての端末に 100KB を転送すると

全てが54Mbps転送だった場合(上)と、うち一台のみが2Mbpsだった場合(下)にかかる時間の比較(概念)
全てが54Mbps転送だった場合(上)と、うち一台のみが2Mbpsだった場合(下)にかかる時間の比較(概念)

なんということでしょう! 遅いデータレートの端末が一台いるだけでかなりの時間を消費し、チャネルを共有している全端末のパフォーマンスが大幅に劣化してしまいました。

この遅いデータレートの存在があると、無線LANに収容できる端末数は大幅に低下します。無線LANでは制御も同一チャネルの半二重で行うため、チャネルの空き時間が少なくなると制御も困難になり、全体が一気に不安定になってしまいます。

この場合、ボトルネックになっているのは伝送媒体である空間そのものですので、同じチャネル×空間にアクセスポイントを増設しても改善されません。

高密度無線LAN環境において遅いデータレートは悪!

オフィスなどの高密度無線LAN環境では、遅いデータレートの端末が発生しないよう考慮します。遅いデータレートでの接続を禁止する設定ができるアクセスポイント製品もあります。

データレート制限機能の例
データレート制限機能の例

データレートが速いほど、より高品質な電波状況が要求されます。遅いデータレートでの接続を禁止してしまうと、電波状況が少しでも悪化すると切れてしまうことになります。端末が移動したり、何らかの原因で電波状況が悪くなったとしたら、より近くのアクセスポイントへローミングを早めに行わせます。

※ローミング 複数のアクセスポイントが同じSSIDで設置されている場合、端末は最も良い電波状況のアクセスポイントを自動的に選んで接続し、電波状況が変化すれば別のアクセスポイントへ接続先を変更する。

続く:: つながらない無線LAN!?(2/3) 調査編


初めまして、申し遅れましたが新人ツチノコのkumaです。よろしくおねがいいたします。

セキュリティ, ネットワーク, 運用管理

本日 「うるう秒」の挿入が行なわれましたが、みなさま無事だったでしょうか?

参考)  閏秒 – Wikipedia

DMMで行なった「うるう秒」対策は以下の6点です。

  1. うるう秒による影響調査
  2. ネットワーク機器の対策
  3. ゆっくり時刻を合わせるNTPサーバの構築
  4. 大量のサーバのNTPの設定変更
  5. パブリックNTPサーバとの通信遮断
  6. 当日待機

うるう秒による影響調査

ベンダーからのアナウンス情報、3年前の事例、NTPのプロトコル調査、等を行なって以下の問題があることを事前に洗い出して、チーム内周知を行ないました。

  • うるう秒で問題が発生する要因は大きく2つ。
    • NTPプロトコルでうるう秒対策に使われる、リープインジケータ(以下LI)をうまく処理できないLinuxサーバが存在する。
    • うるう秒挿入をうまく処理できないアプリケーションがある。
      • 60秒の挿入、時間の巻き戻り、にうまく対応できないソフトウェアがある。
  • 3年前には、MySQL、Java、で高負荷になる事例があった。
  • LIを受信しなければ、LIに起因する問題発生は回避できる。
    • LIを受けるタイミング(うるう秒挿入の24時間前からうるう秒挿入までの時間)でNTPサーバを停止すれば問題は回避可能。
    • LIを送信しないNTPサーバを使うことでも回避可能。
  • NTPをslewモードで動作させれば、ゆっくり時間を合わせるので時間の巻き戻りをある程度回避できる。
    • ただし、NTPの古いバージョンではうるう秒の時のslewモードにバグがある。
  • ネットワーク機器についての情報は各ベンダが情報を出してくれている。
    • 問題があるものはファームウェアを上げることで対処可能。
    • ファームウェアを上げられない場合は、NTPサービスを停止することで問題回避は可能。

ネットワーク機器の対策

機材によって以下の2つ対策を使いわけました。

  • ファームウェアのアップデート
  • 前日からのNTPサービスの停止

ゆっくり時刻を合わせるNTPサーバの構築

LIを流さずに、ゆっくり時刻を合わせるNTPサーバがあれば、うるう秒による問題は回避できます。

そんな製品がありました。

このアプライアンスサーバを最上位(stratum 1)のNTPサーバとして、複数のNTPサーバを用意しました。

大量のサーバのNTPの設定変更

DMMには大量のサーバがありますが、そのサーバのNTPの設定を確認してみたところ、いろいろなNTPサーバを参照していました。

なんてこったい。

Ansibleを使って、一気にNTPサーバの設定変更を行ない、NTPサーバの再起動を行ないました。

設定の標準化できて一石二鳥。

パブリックNTPサーバへの通信遮断

DMMには本当に沢山の機材があって、上記の対応をしても、更新漏れの機材がある可能性があります。

万が一に備えて、前日から24時間、参照している可能性があるパブリックNTPサーバへの通信を遮断しました。

ルータのルーティングテーブル上で、/32の経路をdropする、という乱暴なことをしています。

当日待機

念のため当日待機もしましたが、残念なことに、幸いなことに、何もありませんでした。

めでたしめでたし。

ネットワーク, 小ネタ

おはようございます。ライトノベル好きの新人ツチノコです。魔法少女禁止法は読みましたか?

さて本題ですが、HTML5のResource Timingでユーザ環境のネットワーク品質の測定ができるらしいとのことで、試行してみました。デモ用サイトは以下になります。

  • 測定デモ
    • 重要:
      測定デモでは速度測定結果をサーバに送信、またアクセス日時・IPアドレス・User-Agentをサーバで収集しています。
      サーバに送信されたデータ・サーバで収集されたデータは下の測定履歴で表示(IPアドレスについては一部をマスク)されます。
      また、アクセス元を特定できないようにアクセス日時・IPアドレスを加工・統計処理したうえで、社内外の発表で利用する可能性があります。
    • http://connection-speed-demo.appspot.com/
  • 測定履歴

仕組みは window.performance.getEntriesByType(‘resource’) によって PerformanceResourceTiming Objectの配列が返ってきます。
PerformanceResourceTiming Objectは以下の要素を持っています。

各attributeの時間関係は以下の図のようになっています(Resource Timing W3C Working Draftより)。

resource-timing-overview-1

例えば responseEnd – responseStart でHTTPのresponseを転送するのにかかった時間が得られます。これで転送バイト数/転送時間 = ネットワーク速度が得られることになります。
ただ、上に挙げたすべてのattributeが実装されているわけではなく、たとえばChrome 43ではtransferSizeは未実装でした(今回はファイルサイズをハードコーディングしました)。

課題や検討事項もいろいろあります。

  • 今回利用したファイルが31Kbyteと比較的小さいため、精度が低いこと
    • 小さいファイルから順にダウンロードしていくのがよさそう
    • 一方で特に通信量に制限がある携帯回線で通信量をいたずらに消耗しないようにしたい
  • 動画などがダウンロードされたときに測定する方法との得失
    • 動画などファイルサイズが大きければ精度は高い
    • 今回のようにHTMLに埋め込めれば、より広い範囲でデータが取れる
  • 個人情報保護の観点で大丈夫か?
    • いわゆるアクセス解析と同じはず

DMMはAKB48グループ LIVE!! ON DEMAND動画オンラインゲームといった大量の通信を行うサービスを提供しています。
サービスごとに対応プラットフォーム(PC、携帯、etc.,)は異なりますし、通信の内容(動画ストリーミング、動画ダウンロード、ゲームの音声ダウンロード、etc.,)も様々です。
サービスの使い勝手は様々な要素によって決まりますが、DMMのサービスの使い勝手を決める要素のひとつであるネットワーク速度の測定について、今回はデモを作成して試行してみました。
いろいろと検討事項はありますが、悪くはない感触がえられました。

p.s.
私事ではありますが帰宅時にわざわざ定期の無い路線に乗り換えて開拓したラーメン屋がたいへん美味しくなくて異世界に転生したい気持ちになりました。
そんな気持ちですが最近のおすすめのライトノベルは異世界居酒屋「のぶ」です。3巻目が6/24に出るそうです。

PAGE TOP