皆さん、こんにちは。本日はワイヤレスネットワークのトラブルシューティングに関するElevateセッションにご参加いただきありがとうございます。Logic Monitor製品チームのPatrickです。本日は、過去10年間のワイヤレス技術の変化と、Logic Monitorを使ってワイヤレスネットワークのトラブルシューティングを行う方法についてお話します。

過去10年間で、ワイヤレスネットワークは大きく変化しました。かつては、オフィスに堅牢なワイヤレスネットワークがあれば便利でしたが、今ではエンドユーザーはミッションクリティカルなワイヤレス機能を期待しています。

過去 10 年間で変化したこととして、ワイヤレス ネットワークの管理は、オンプレミスのワイヤレス コントローラーの使用から、Cisco Meraki や Aruba Central などのクラウド ベースの管理テクノロジーに移行しました。

それに伴い、過去 10 年間で、Wi Fi 6、Wi Fi 6 e、そして Wi Fi 7 という 3 つの新しいワイヤレス規格が登場しました。

企業は、各キュービクルへの有線接続のオプションがなく、ワイヤレス接続のみを備えたワイヤレス優先のオフィスを構築しています。

それに加えて、エンドユーザーは通常、2台以上のデバイスを所有しています。かつては、ワイヤレスネットワークに接続するノートパソコンを1台持っていました。しかし今では、エンドユーザーはノートパソコンを1台持っています。タブレットやスマートフォンを持っている人もいるでしょう。さらに、IoTデバイスやスマートカメラなど、ワイヤレスネットワークに接続されるデバイスは無数にあります。

そのため、かつては安定したワイヤレスは単に便利なだけでしたが、今では誰もがワイヤレスが常時動作していることを期待しています。

さて、ここでサリーの話に移りたいと思います。サリーはAnytechのマーケティングマネージャーで、日中のほとんどの時間を様々な会議室や共用エリアに出入りし、顧客や見込み客との打ち合わせに費やしています。しかし、それは他の日々と変わりません。今日、彼女は無線ネットワークの利用に特に苦労しています。

同僚のジェイクも、上司のサリーに不満をぶちまけています。「インターネットって、どうしてこんなにネットワークが悪いんだ？どうすればいいんだ？」と。ところが残念なことに、ジェイクの上司のサリーは立て続けに会議が詰まっていて、オフィスに顧客が来ているんです。IT部門に連絡して、自分とチームがワイヤレスネットワークで問題を抱えていることを伝える時間なんてありません。

では、エンドユーザーはこのジレンマに直面したときにどうするのでしょうか?

ほとんどの従業員と同様、彼らは結局、その問題に対処し、一日を懸命にやり遂げることになります。

ジェーンは不満を抱き、チームも不満を抱き、生産性にも影響が出ています。良い状況とは言えません。

しかし、もし違うとしたらどうなるでしょうか?

ジェーンとサリー、そして彼らのチームがこのような問題を抱えている時、IT部門が報告したらどう対応してくれるのかと考えるのではなく、IT部門がジェーンに積極的に連絡を取り、「ワイヤレス環境が不安定なようですので、すでに調査中です」と伝えたらどうでしょうか。

したがって、サリーと彼女のチームは以前と同じワイヤレス問題を抱えているかもしれませんが、経験はかなり異なります。なぜなら、サリーは、IT 部門が積極的に彼女に連絡し、彼女が介入しなくてもすでに調査を始めていることに驚いているからです。

では、ロジック モニターでは、顧客や従業員が不満を抱く前に IT 部門が積極的に顧客や従業員の問題の解決に取り組むようなエクスペリエンスを実現するために、何を行っているのでしょうか。

典型的なダッシュボードとロジックモニター（この場合はCisco Meraki）を見ると、デバイスベースの情報が多数表示されます。無線アクセスポイントの健全性とパフォーマンス、それらが接続されているアクセススイッチ、それらをインターネットに接続するセキュリティアプライアンスやルーター、そしてこれらの各デバイスの健全性とパフォーマンス、ネットワークの使用状況などを確認できます。

これらはすべてデバイス中心の情報であり、サリーのエクスペリエンスに影響があるかどうかの手がかりとなるものは実際には何もないのです。つまり、エンドユーザー固有の情報についてはここには何も記載されていないのです。

しかし、エンド ユーザーについて話し始めると、通常、主要なパフォーマンス指標はエンド ユーザー接続の信号強度になります。

では、そのような情報をロジック モニターに取り込むにはどうすればよいでしょうか?

まず、信号強度とは何かを理解する必要があります。エンドユーザーの無線接続を確認する際には、受信信号強度、つまり信号強度インジケーター（RSSI）を使用します。これはデシベル単位で表されます。私たちが注目する最高レベルの指標です。

そして、配線上のノイズがあります。これは金属や壁からの環境ノイズかもしれませんし、背景ノイズかもしれません。例えば、コンサートでバンドの演奏を聴いているとします。しかし、観客自体が騒がしかったり、隣で何かが起こっていてバンドの演奏を聞きたい場合、観客の騒音を抑えるか、バンドのアンプの音量を上げるかのどちらかです。

増幅器が信号強度だと想像してみてください。私たちは信号をできるだけ強くしたいし、ノイズはできるだけ低くしたいと思っていますが、私たちが制御できるのはそのうちのどちらか一方だけです。つまり、実際に制御できるのは信号強度だけです。つまり、信号対ノイズ比は、この2つの差なのです。

信号強度と背景ノイズ、つまりノイズフロアの差です。シスコによると、音声通信で良好な接続を確保するには、信号対雑音比（S/N比）が20～25デシベル以上、データ通信では20デシベル以上が必要です。そこで、ここでは信号対雑音比（S/N比）を少なくとも25デシベル以上にすることを目指します。

では、信号対雑音比と受信機の信号強度インジケーターがわかったので、それをロジック モニターに取り込むにはどうすればよいでしょうか。

Merakiアプリケーションで確認すると、これは家からできるだけ遠くまで歩いて行き、信号強度が弱まり、ネットワークから切断され始めたときの測定値です。信号強度はわずか3デシベルです。

しかし、無線アクセスポイントのすぐそばに立つと、信号強度はほぼ60デシベルになります。確か58デシベルくらいだったと思います。

つまり、3 は非常に悪く、58 は非常に高いです。

しかし、サリーやロジック モニター内の特定の誰かの信号強度が低い場合に警告を受け取るにはどうすればよいのでしょうか。

無線アクセスポイントからロジックモニターに送られてくるSyslogエントリは、こんな感じです。受信機の信号強度インジケータはありますが、信号対雑音比（S/N比）の指標はありません。そこで、この特定のケースでは、エンドユーザーの体感の指標としてRSSIを使用しています。

他にも確認できる点がいくつかありますが、ここでは何ができるかを示すために、受信機の信号強度インジケーターに特に注目します。

しかし、信号強度がどこにあるかを特定・解読するために、すべてのSyslogエントリを調べるのは避けたいものです。そこで、Logic Monitor内で、実際にアラートを受信できるような仕組みを作りたいのです。ここに、クライアントRSSIに関するアラート条件があります。25未満の場合はアラートを受け取りたいのです。

24を超えたらアラートをクリアしたいのですが、これはエンドユーザーごとに設定したいです。サリーの信号強度が閾値を超えた場合にのみアラートをクリアし、サリーの信号強度が低い場合にのみアラートを発報したいのです。つまり、サムの信号強度が上がってもサリーの信号強度がまだ低い場合、アラートをクリアしても構わないのです。

それで、これをどうやって設定したのでしょうか?

ロジックモニター内で、Syslogベースのログソースを作成しました。ここでは、クライアントRSSIなどのフィールドを正規表現で解析しています。前のスライドではRSSIが14だったのを覚えていますが、このスライドではRSSIが21です。必要なのは整数値だけです。つまり、ここでは21だけが欲しいのです。そこで、正規表現を使ってその整数値だけを解析します。

他にもたくさんのフィールドがあり、それらも解析して、接続にかかった時間や認証にかかった時間などを取得しています。今回は特に信号強度インジケータに注目しています。そこで、その値に基づいてアラートを生成できるように、整数値だけを解析します。

lm ログで RSSI が等しいメッセージなどを検索するときに、ここでクリックしてメッセージをログに記録し、アラート条件を作成します。

次に、アラート条件を設定します。ここでは、クライアントのRSSIが25未満の場合にアラートをトリガーするように設定しています。

そして、クリア条件として、クライアント RSSI が 20 より大きい、または 24 より大きい場合は、その条件をクリアしたいとします。

一番下には、私が抽出したログメタデータフィールドがクライアントの最大値であることがわかります。これが実際にトリガーしているものです。つまり、このアラート条件は特定のクライアントMACアドレスに固有のものです。繰り返しますが、これはどのクライアントデバイスにも適用されるわけではなく、特定のクライアントMACアドレスにのみ適用されます。

ただし、信号強度に関するアラートをトリガーできるようにするために、これらすべての手順を実行しましたが、syslog にある情報を解析する必要がありました。

正規表現を使用する必要がありました。

アラートを発したいタイミングと、アラートを解除したいタイミングのしきい値を具体的に設定する必要がありましたが、少し複雑です。ワイヤレスネットワークに関して、ロジックモニター内でエンドユーザー固有の情報に基づいてアラートを発するには、これが唯一の方法なのでしょうか？

はい、もう一つ開発中の方法があります。Cisco Merakiのダッシュボードを見てみると、クライアントの信号強度が低下した際にアラートを発するオプションがあります。例えば、特定のSSIDのクライアントの信号品質が低い場合、その信号品質が（デフォルト設定は30分ですが）サリーのチームの誰かが5分以上信号対雑音比（SNR）が低い状態になった場合にアラートを発するように設定できます。

しかし、その情報はどのようにロジックモニターに取り込まれるのでしょうか？ 実は、Webhookを使ってこの情報をロジックモニターのログに送信できる機能を現在開発中です。そのため、しきい値を設定する必要はもうありません。ロジックモニターにこれらのメッセージが届いただけでアラートを発報できるようになります。

そして、それは次のようになります。Wi-Fi 信号が弱い場合、誰かがカメラの前を通った場合、空気の質が悪い場合、セキュリティ警告がある場合、または、たとえば、スイッチ ポートの 1 つでリンクのリンク速度が変わった場合などにアラートを発することができます。

したがって、これは、Syslog と REST API のオプションがある現在ではなく、Webhook 経由でロジック モニターにテレメトリを取得するもう 1 つの方法になります。

今日ご紹介した方法を使えば、Syslog経由で情報を取り込むことができます。情報を解析し、信号強度やSyslog内のその他の項目に基づいてアラートを設定することもできます。

そして近い将来、Cisco Meraki や他のクラウド管理テクノロジーを使用して、Webhook 経由でそれが実行できるようになります。

本日はワイヤレスネットワークのトラブルシューティングに関するセッションにご参加いただき、ありがとうございました。また、Elevateにもご参加いただき、ありがとうございました。