web-dev-qa-db-ja.com

Wi-Fiの輻輳を診断/特性化するSNMP変数はどれですか?

教室のwifiシステムの負荷テストの準備をしています。生徒は全員、レッスンの開始時にラップトップの電源を入れます。これにより、Webブラウザーが起動し、レッスンが開始されます。これには、フラッシュベースのレッスン(学校内のサーバーから)のダウンロードが含まれます。通常、ダウンロードは半分から2MBです。

場合によっては、読み込み時間が5分または10分に伸びます。そのため、システムのすべての部分を監視して、ボトルネックがどこにあるか、および1つのwifiアクセスポイントを合理的に使用できるクライアントの数を自信を持って伝えたいと思います。したがって、最大50のクライアントでテストを実行し、何が起こるかを確認することを計画しています(ほとんどの人は、アクセスポイントごとに20〜25のクライアントを推奨していますが、クライアントはこれをテストしたいと考えています。また、クライアントに表示するための適切なデータを取得したいと考えています。あれやこれやで)。

私はすでにサーバーを監視する方法を知っています。 Wi-FiアクセスポイントはSNMPをサポートしており、非常に多くの変数を提供しているようですが、あまり多くのことをやり遂げる必要はありません。

したがって、問題は、システムが過負荷になっているとき、クライアントが待機しているとき、衝突が発生しているときなどを特徴づけるために監視する重要なWi-Fi関連の変数は何ですか?

そこにあるべきものの一般的な名前を教えられて、自分でファイルを探し回ることができてうれしいですが、詳細を確認したい/必要な場合は、使用しているアクセスポイントは biquity Nanostation 2 。 Ubiquity製品のMIBファイルは、 SNMPページ の下部からリンクされています。私はまた、それらが Mikrotik MIB の少なくとも一部をサポートしているように見えることもわかりました。

5
Hamish Downer

簡単なアプローチは、IF-MIB::ifInOctets.<ifIndex>/IF-MIB::ifOutOctets.<ifIndex> OIDを定期的に監視し、使用可能な帯域幅と照合することです。リンクされたMikroTikMIBから、mtxrWlStatTxRate:1.3.6.1.4.1.14988.1.1.1.1.1.2.<ifIndex>およびmtxrWlStatRxRate:1.3.6.1.4.1.14988.1.1.1.1.1.3.<ifIndex>を読み取ることにより、現在設定されているレートを見つけることができます。もちろん、これはワイヤレスの詳細を考慮しませんが、インターフェイスで使用可能な合計帯域幅がボトルネックであるかどうか(おそらく、合計チャネル容量の近くで使用量が見られる場合)を大まかに把握できます。

一般に、ステーションまたはアンテナの位置が悪く、選択したチャネルの周波数でエーテルがクリーンでない限り、単一のGチャネル(54 MBps 2,4 GHz)から約2〜3 MB/sのスループットが期待できます。

AP側からの再試行とエラーに関するより具体的な情報が必要な場合は、IEEE802dot11MIBのdot11Countersテーブル、具体的にはdot11RetryCountdot11MultipleRetryCount、およびdot11FailedCountの値を読み取ることができます。適切なインスタンスの。

802.11には衝突はありませんが、フレームの送信前に物理的なキャリアセンシングと、オプションで RTS/CTSハンドシェイク があります。 dot11RTSFailureCountを監視すると、RTS要求がCTSによって応答されない頻度が大まかにわかり、送信ステーションにチャネルが許可されません。

トラフィックの大部分を生成しているのがアクセスポイントである場合(つまり、ステーションが主にデータを受信して​​いる場合)、再試行回数とRTS障害が比較的少ない場合があることに注意してください。ワイヤレスインターフェイスのIF-MIB::ifOutDiscards.<ifIndex>または有線インターフェイスのIF-MIB::ifInDiscards.<ifIndex>を確認することをお勧めします。これらの数値は、バッファがいっぱいで追加のフレームを受信できない場合は常に増加します(つまり、APはフルレートで送信しますが、イーサネットインターフェイスのフレームはより速いレートで到着し続けます)。

2
the-wabbit

APが過負荷になっていることをクライアントに証明するだけの場合は、dot11RetryCountおよびdot11MultipleRetryCountOIDを使用できます。

dot11RetryCount-1.2.840.10036.2.2.1.4

dot11MultipleRetryCount-1.2.840.10036.2.2.1.5

これにより、空気がどれだけ混雑しているかを大まかに見積もることができます。再試行回数がdot11TransmittedFrameCountの約10%を超えると、速度が低下し始めます。

これがCiscoのMIBオブジェクトウォーカーです。これは、他のOIDを調べて調べる必要がある場合に役立ちます。

http://tools.Cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=1.2.840.10036.2.2.1.13#oidContent

4
smithian