落雷・停電(計画・計画外)時の対応とRMAポリシーのポイント Cisco Meraki製品をご利用のお客様に向けて、落雷や停電といった電源系トラブル発生時の対応について、重要なポイントをご案内します。   1. 落雷・停電時に起こりうる影響 電源サージ（瞬間的な高電圧） 電源断によるハードウェア誤動作または故障 復電時に過電圧となり、デバイスの故障 内部部品への影響が発生 これらは天候や電力設備の状態に依存し、突発的に発生するため予防が大切です。 2. 推奨される事前対策 Cisco catalyst のハードウェア設置ガイドでも紹介されているように、以下のような対策を推奨します（参考：Catalyst 9300 事前準備）。 計画停電の場合、事前に電源の抜線を実施する：　 　　　- 復電時の過電圧を防止するため、計画停電時は事前に電源を抜線しておき、復電を確認してから、電源を接続する。 予期しない停電の場合、発覚時点で電源の抜線を実施する： 　　　- 復電時の過電圧を防止するため、計画外停電に気づいた時には電源を抜線しておき、復電を確認してから、電源を接続する。 サージ保護装置（SPD）を設置する： 　　　- 落雷時の電圧変動から機器を保護する。 UPS（無停電電源装置）を利用する： 　　　- 瞬間的な停電でも安定した電源を供給する。 　　　   ※UPS がカバーできる電力バジェット、稼働期間を事前に見積もりいただくことが推奨されます。 3. RMAポリシーと交換対応の注意点 CiscoのRMA ポリシーでは、故障が保証の対象となるかどうかは個別ケースごとに判断されます。 外部要因（停電/落雷など）による故障などの場合、製造上の欠陥や材料の欠陥に該当しないため、交換保証の対象とはならない場合がございます。（参考：Cisco Warranty） 落雷や停電後に問題が報告され、適切な保護対策が行われておらず、同じ停電影響を繰り返す場合は、担当チームとの協議の結果、保証適用外となる可能性があります。 同様の事象でも、機器の状態や設置環境によって結論が異なる場合があります。 最終的な交換可否は、サポートケース上での調査結果に基づきます。 4. まとめ 落雷・停電は機器故障を招きやすく、予防策が重要です。 保護対策が不十分な場合、RMA交換の対象外となる可能性があります。 対策を事前に実施することで、ダウンタイムや交換不可のリスクを最小化できます。 💡サポートからのお願い 事前対策、定期的な環境点検と保護装置の導入により、安心してMeraki製品をご利用いただけます。 もしトラブル発生時には、詳細な環境情報と発生状況をサポートまでお知らせください。   参考ドキュメント RMA 確認事項 ... View more

  はじめに 今回は、お客様のMerakiネットワーク運用を劇的に効率化する「Cisco Workflows」についてご紹介します。 日々の運用で発生する繰り返し作業や、複雑な設定変更に頭を悩ませていませんか？ Cisco Workflowsは、Merakiダッシュボードに統合された強力な自動化ツールとして、 これらの課題を解決し、お客様のネットワーク管理をよりスムーズにするためのものです。 まずは、Workflowsがどのように業務を変えるのか、実際の動画をご覧ください！     デモンストレーション   ※お客様の環境設定、既存の統合システム、ネットワークポリシーなどによっては、動画で示された挙動と異なる場合があります。 本番環境への適用前には、必ずテスト環境での十分な検証と影響範囲の確認をお願いいたします。 予期せぬ問題が発生しないよう、慎重な導入計画を立てることが重要です。   1. タグにマッチするネットワークのファームウェアスケジュール設定 Exchange(プリセット) にてパブリックで公開されているWorkflow を用いてデモンストレーションを行います。 このWorkflow は、実行した管理者アカウントが属するオーガナイゼーションで任意のタグが付与されたネットワークのファームウェアスケジュールを一括で実行します。     デモンストレーション動画 ※このWorkflow は、実行する管理者アカウントが属するすべてのオーガナイゼーションに対してアクションが実行されるため、 いずれかのオーガナイゼーションがライセンス違反で30日の猶予期間を迎え、シャットダウンしている場合は、実行に失敗します。 ※オートメーションメニューの設定は、オーガナイゼーションごとに管理されます。       2. 定期的な再起動の実行 プリセットのものでは無く、自身でWorkflow を作成してスケジュール設定を行い、自動化を用いたデモンストレーションを行います。 このWorkflow は、複数のデバイスに対して再起動を定期的な間隔で実行します。   デモンストレーション動画       3. AI assistant を用いてWorkflow を実施 AI assistant を用いて、タグにマッチするネットワークのファームウェアスケジュールを実施するデモンストレーションを行います。 このWorkflow は、1 で実施したものと同じものです。   デモンストレーション動画     いかがでしたでしょうか？ たった数クリックで、様々なアクションを完了する様子をご覧いただけたかと思います。 この自動化を実現するのが、Merakiダッシュボードに統合されたCisco Workflowsです。 ここからは、Workflowsのメリット、ご利用にあたっての要件、知っておくべき制限事項、 そして具体的な活用例を、ユーザーの皆様の視点に立って解説いたします。     Cisco Workflowsとは？ Cisco Workflowsは、お客様が日々ご利用されているMerakiダッシュボードに直接組み込まれた、クラウドホスト型の強力な自動化アプリケーションです。 タスクの自動化と運用の合理化を目的としており、様々なシステムやデータソースと連携する一連の活動を定義することができます。 これにより、複雑な操作を簡素化し、お客様の生産性向上を支援します。 Workflowsは、Ciscoが提唱するIT運用の未来「AgenticOps」の重要な要素であり、AIエージェントが自律的にネットワーク運用を推論、実行、最適化することを目指しています。   Workflowsは、ドラッグ＆ドロップによるローコード/ノーコードの直感的なインターフェースを提供し、手動実行、スケジュール実行、外部トリガー（Webhook）による実行、さらにはCisco AI Assistantからの実行も可能です。     Cisco Workflowsのメリット Cisco Workflowsを導入することで、Merakiユーザーの皆様は多岐にわたる恩恵を受けることができます。 Merakiダッシュボードへの統合と追加ライセンスなし: お客様が使い慣れたMerakiダッシュボードから直接アクセスでき、追加ライセンスなしでご利用いただけます。 タスクの簡素化と合理化: ITドメイン全体にわたる一般的なタスクを簡素化し、運用を合理化します。 ヒューマンエラーの削減: 自動化を活用することで、手作業によるミスを大幅に減らし、安定した運用を実現します。 迅速なイベント調査: 事前に構築されたワークフローやカスタムワークフローを使用することで、機械のような速度でイベントを調査し、問題解決を加速します。 幅広いシステムとの統合: Meraki製品はもちろん、Catalyst Center、SD-WAN、Umbrella、ISE、ACI、Nexus Dashboard、IntersightといったCisco製品群、さらにはNetBox、ServiceNow、Jira、Webex、ThousandEyes、Ansible、Terraform、そして一般的なREST APIやSSHアダプターを持つあらゆるサードパーティシステムと連携可能です。これにより、Meraki環境を中心としたお客様のネットワーク全体を自動化の範囲に含めることができます。 ローコード/ノーコードアプローチ: プログラミングの専門知識がなくても、ドラッグ＆ドロップで日常業務を自動化し、ネットワーク管理の複雑さを軽減できます。 一貫性と信頼性の向上: 自動化されたタスクにより、設定や運用の一貫性が保たれ、システムの信頼性が向上します。 生産性の向上: IT管理者とユーザー双方の生産性を高め、より戦略的な業務に集中できる時間を創出します。 運用コストの削減: 自動化により手作業が減り、運用コストの削減に貢献します。 実行ステップの完全な可視性: ワークフローの実行ステップ、変数、エラー追跡をライブで確認でき、トラブルシューティングも容易です。 AI統合: Cisco AI Assistantが関連するワークフローを見つけ、実行を支援したり、AIによるデータ解析や適応的なアクションをワークフローに組み込むことも可能です。 Gitリポジトリとの連携: GitHubとの連携により、ワークフローのバージョン管理とチームでのコラボレーションを可能にします。 Workflows Exchange: サンプルワークフローのライブラリが提供されており、お客様のニーズに合った自動化を簡単に見つけ、そのまま実行したり、カスタマイズしたりできます。     Cisco Workflowsの最低要件 Cisco Workflowsはクラウドホスト型サービスであるため、特定のハードウェア要件はございませんが、ご利用にあたっての基本的な要件は以下の通りです。 Merakiダッシュボードへのアクセス: Cisco Workflowsは、お客様がお使いのMerakiダッシュボードに直接統合されています。現在、米国、EU、APJCのデータセンターでホストされているMerakiアカウントでご利用いただけます。 Merakiアカウント: Merakiデバイスをお持ちでないお客様でも、Merakiアカウントを作成するだけでWorkflowsにアクセスし、自動化の可能性を探ることができます。 ワークフローの有効な状態: ワークフローは手動またはイベントによって実行されるためには、有効な状態である必要があります。変更を加えた場合は、実行前に検証が必要です。     Cisco Workflowsの制限事項 Workflowsを効果的にご利用いただくために、いくつかの設計上および実行上の制限事項がございます。 これらをご理解いただくことで、よりスムーズなワークフロー設計と運用が可能になります。 設計上の制限 ワークフローの最大数: 500 アトミック（最小単位のタスク）の最大数: 500 ワークフロー変数の最大数: 100 カスタム変数タイプ（配列、オブジェクト、テーブル）の最大数: 組織あたり合計200 Large String変数の最大サイズ: 10MB String変数の最大サイズ: 1MB Table変数の最大サイズ: 1MB ワークフローアクション（全種類）の最大数: 200 サブワークフローアクティビティの最大数: 30 実行時間に関する制限 ワークフローあたりのループ実行合計最大数: 50,000回 For EachまたはWhileループの最大反復回数: 500回 ワークフローの最大実行時間: 30分 これらの制限に達すると、ワークフローはworkflow_timeoutステータスで失敗します。 API実行に関する制限 Start APIのレート制限: 1分あたり20回 Webhook APIのレート制限: 1分あたり20回 その他の制限 カレンダーの最大数: 100 データタイプの最大数: 200 移行パス: 以前のWorkflows環境をご利用されていた場合、現在のMerakiダッシュボード組み込み環境への自動移行パスはございません。お手数ですが、手動での再作成をお願いいたします。 カスタムHTTPターゲット: カスタムHTTPターゲットはインポート時にコピーされるため、意図しない動作を引き起こす可能性があり、ワークフローが複雑化する原因となる場合があります。     Cisco Workflowsのユースケース Cisco Workflowsは、Meraki環境における多岐にわたるシナリオで活用できます。 Merakiデバイスのプロビジョニングの簡素化 SSIDまたはRFプロファイルの作成、変更作業 タグに基づいて複数のMXネットワークにルールを展開 タグに基づいて複数のオーガナイゼーションにファームウェアスケジュールを展開 VLAN 設定の変更 など。   他にも多くのMeraki API 機能との連携が可能な為、多くのアイディアが考えられます。 Cisco Workflows コミュニティ も確認しましょう。     まとめ Cisco Workflowsは、お客様のMerakiネットワーク運用をよりスマートに、より効率的にするための強力なツールです。 日々の煩雑な作業を自動化し、ヒューマンエラーを減らすことで、お客様は本来注力すべき戦略的な業務に集中できるようになります。 この記事での再現動画も、Workflowsの実際の動作をイメージするのに役立つはずです。 ぜひこのブログ記事と合わせてご参照いただき、Cisco Workflowsがもたらす自動化のメリットを最大限にご活用ください。   また、Exchange(プリセット) については、今後もより多くのプリセットが展開されますが、 お客様のアイディアも公開することが可能になります。よろしければ、ご検討ください。 詳細は、こちらのドキュメントをご参照ください。     参考ドキュメント - AI-powered network automation - Workflows GA: Welcome to the Future of AgenticOps - Workflows Evolution FAQ   - Workflows - Workflow_Best_Practices - Run_Monitoring - Authorship_Types - Frequently_Asked_Questions ... View more

SSIDが確認できない時のトラブルシュート 無線LAN環境でSSID（Wi-Fiネットワーク名）が表示されない場合、様々な原因が考えられます。 この記事では、主な原因とその確認・対処方法を分かりやすくまとめます。     主な原因 1. AP（MR）が特定SSIDのみ送信できていない 　- 設定ミス（特定バンドのみ、802.11ax 互換性など）が考えられます。 2. AP（MR）の故障 　- この場合、すべてのSSIDで同様の問題が起きます。 3. クライアントデバイス側の問題 　- 端末に依存するケース。 4. SSIDが秘匿（Hidden SSID）設定になっている 　- 端末上のネットワーク一覧に表示されません。 5. Local status pageでバンドが無効化されている 　- 電波自体が出ていない可能性があります。     チェックポイント・確認方法 1. APの詳細ページで「broadcasting」状態か確認 手順 - [Wireless] ＞ [Access points] ＞ 対象MRを選択 ＞ [Summary] ＞ [SSIDs] - 該当SSIDが「broadcasting」になっているか確認します。   - Tag制御による個別送信設定の場合は、管理画面上で特定APのみ送信になっている表示になります。     2. SSIDがHiddenになっていないか確認 手順 - [Wireless] ＞ [SSID availability] - 該当SSIDが「Hidden」になっていないか、設定を確認します。 - Hiddenの場合、端末からはSSIDが見えません。     3. RFスペクトラムからBSSID/MRの存在を確認 手順 - [Wireless] ＞ [RF spectrum]   View old version - 対象MRのBSSIDを控えておきます。   - 別のMRを選び、希望バンド（例：5GHz）で「Interfering APs」を表示し、ブラウザ検索でBSSIDを探します。 - SSID名・使用チャネルもここで確認できます。 例の場合、CW9166D1 のBSSID を確認したいため、MR52 を選択する。     View new version - New version のUI の場合、確認をシンプルとするためBSSID は表示されないが検出している場合は、画像のように表示されます。     4. ワイヤレスパケットキャプチャでビーコン確認 - MRがTXキャプチャ対応モデルの場合のみ利用可能（EOSモデルは不可）。 - [Network-wide] ＞ [Intelligent Capture For access points] - フィルタ条件：`wlan host [BSSID] and subtype beacon` （InterfaceはWireless指定） - ダッシュボードでもキャプチャ結果が確認可能です。 wlan host BSSID and subtype beacon     5. 周辺MRでのパケットキャプチャによるビーコン確認 - 周辺のMRでもパケットキャプチャが可能です。 - 詳細な手順はコミュニティ記事を参照ください。     6. Local status pageで電波出力がOFFになっていないか - 初期セットアップ時に「OFF」で保存すると、無線出力が止まります。 - 設定保存前に、電波出力状態がONになっていることを必ず確認してください。     7. 機器の初期化/再起動の実施 - 上記、設定上は異常が見られないが、周辺デバイスでBSSID も見られない場合は、 デバイス側の一時的な問題、故障の切り分けとして初期化/再起動を実施して改善がみられるか確認してください。     まとめ SSIDが見えない場合は、「設定」「機器状態」「クライアント」「Hidden設定」「出力状態」など、複数の観点から順に切り分けて確認することが重要です。     参考情報 - Hidden_SSIDs - Using_Tags_to_Broadcast_SSIDs_from_Specific_APs - Packet_Capture_Overview - RF_Spectrum_Page_Overview - AP_Neighbors - 障害切り分けとしてのファクトリーリセット-初期化-の重要性 - Resetting_Cisco_Meraki_Devices_to_Factory_Defaults_jp ... View more

MX 後継機への交換時に役立つ、ポートマッピング表の整理、移行手順と注意点   テンプレートネットワークに紐づく場合、Meraki MXを後継機種へ交換する際、 ポートマッピング表を活用することで、各ポートの設定を簡単に引き継ぐことが可能です。   実際の交換作業については、こちらの記事もご参照ください。 公式ドキュメントも参考になりますので、以下をご参照ください。 MX Cold Swap Replacing an Existing MX with a Different MX   今回は、MX64 からMX75への交換を例に、ポートマッピングの流れや注意点について整理しました。 1. 前提の整理 まず最初に、ポートマッピング表と各機器（筐体）のポート番号を確認しましょう。 今回は分かりやすさを重視し、テンプレートにおける「LAN5」の設定に注目して解説します。 今回の作業では、MX64からMX75への機器交換を行います。 この際、LAN5の設定が「MX64ではPort4」、「MX75ではPort6」にそれぞれ対応していることを事前に確認しました。   MX64 の物理ポート     MX75 の物理ポート   2. 交換前：MX64での動作確認 まずは、交換前のMX64での動作を確認します。   Port4に接続した場合、VLAN2のアドレスが正しく取得できており、想定通りの挙動です。     Port3に接続した場合に、VLAN1のアドレスが取得できているため、こちらも想定通りです。   3. 交換後：MX75での動作確認 続いて、機器交換後のMX75で同様の確認を行いました。 Port6に接続した場合、VLAN2のアドレスが取得でき、こちらも想定通りです。   Port7に接続した場合、VLAN1のアドレスが取得できました。こちらも想定通りです。     このように、事前のポートマッピングの確認と設定を行うことで、機器交換後もスムーズにネットワーク環境を維持できました。 同様の作業を行う際は、必ず現行機種と新機種のポート対応表を確認することをおすすめします。   テンプレートネットワーク以外の場合の交換の際の注意点 現在(2025/10/10 時点)、既知事象の影響によって、同じモデル、異なるモデルのデバイスをコールドスワップした場合、 すべてのポート設定が「Drop Untagged Traffic」という設定になる可能性がございます。 そのため、交換や移行前には、一度スクリーンショットなどを取得いただくことを強く推奨いたします。   まとめ テンプレートネットワークの場合、後継機種への交換時には、ポートマッピング表を活用することで、設定の引き継ぎがスムーズに行えます。 ただし、テンプレートネットワークの以外の場合、現時点では、想定外の動作が発生する可能性があり、移行前にスクリーンショットで設定情報のバックアップを取ることが強く推奨されます。 また、移行後は必ずダッシュボードで設定内容を確認し、必要に応じて修正を行うようにしましょう。 ... View more

  概要 この記事は、ファームウェアMX17+ 以降のCisco Talos Intelligence コンテンツ/URL フィルタリングのトラブルシュートについて記載しています。   MX17+ 以降から2025/5/26 現行バージョンのファームウェアでは、Cisco Talos Intelligence に置き換わっており、以前までのBright Cloud を用いたコンテンツ/URL フィルタリングは廃止されております。 この詳細に関しては、こちらの記事 をご参照ください。     前提条件 ファームウェア: バージョンMX17 以降 モード: ルーテッドモード ※パススルー/コンセントレータモードとして構成された MX では、コンテンツ フィルタリングは推奨されません。 MX のアップストリームのファイアウォールでTCP ポート 443 とともに以下が許可されていることを確認する。(SSL インスペクションなども対象外とすることが推奨) 　　ドメイン： 　　　- *.talos.cisco.com 　　IPv4 アドレス: 　　　- 146.112.62.0/24 　　　- 146.112.63.0/24 　　　- 146.112.255.0/24 　　　- 146.112.59.0/24 　　IPv6 アドレス: 　　　- 2A04:E4C7:FFFF::/48 　　　- 2A04:E4C7:FFFE::/48   HTTP or HTTPS の通信であるか。 仕様上、上記いずれかのトラフィックでない場合、ブロックすることができません。 例えば、Google のサービスやブラウザで広く利用されるQUIC プロトコルはブロックの対象にすることができません。 これは、パケットのペイロードが保護されているため、MX がトラフィックを分析することができないためです。     Cisco Talos Intelligence コンテンツ/URL フィルタリング仕組み Cisco Talos Intelligence では、MX のコンテンツフィルタリングはカテゴリリストをあらかじめ読み込んでおくことをしなくなりました。 代わりに、MX はCisco Talos のインテリジェンスサービスからURL のカテゴリを直接クエリします。 その後、クエリされたURL とそれぞれのカテゴリは、MX のローカルにキャッシュされます。  こちらのコミュニティ記事の図を参考にいただくとイメージしやすいです。   また、MX は URL を一致させるために同じURL パターンロジックを使用します。 このパターンロジックについて詳しく解説します。     URL パターンロジック まず、勘違いしやすい点が「*」 （アスタリスク）記号の利用方法についてです。 「*」 は単独で使用される場合は、すべての可能なエントリ を表す包括的なワイルドカードとなります。 つまり、以下の利用の場合、明示的に許可リストに指定されたものを除き、すべての URL パターンがブロックされる動作となります。   以下のような記載の方法は、「*」 がURL の一部として扱われることになるため、多くの通信を制御することができません。   しかし、ルールを書く時にすべてのURL を絶対パスで記載しなくてはならないわけではありません。 ここからが、具体的なURL パターンロジックの仕組みとなります。     HTTP 通信の場合 以下の例では、「wikipedia.org」をブロックとしています。 以下のURL 宛の通信が発生した時には、内部で段階的にURL が短縮されルールに合致するか確認されます。 http://en.wikipedia.org/wiki/Cisco_Meraki#Access_Points_(MR) ※wikipedia はHTTPS の通信ですが、HTTP の想定で考えた場合の例となります。   例では、①～⑤の流れで短縮され、合致することが確認されるためブロックの動作となります。   以下例では、ホワイトリストに登録した絶対パスは許可されますが、それ以外のfoo.bar.com ドメインへのアクセスはすべてブロックされることになります。     HTTPS 通信の場合 HTTPS リクエストもブロックできますが、HTTPS リクエスト内の URL は暗号化されているため、次の順序でドメイン URL チェックのみが実行されます。   www.foo.bar.com　 foo.bar.com bar.com .com * (キャッチオール URL の特殊文字)   以下設定例の場合、3つのURL へのアクセスに対してドメインURL チェックが段階的に行われ、合致するためブロックされます。   https://ja.wikipedia.org/wiki/ https://en.wikipedia.org/wiki/Cisco_Meraki https://ja.wikipedia.org/wiki/メインページ       トラブルシュートステップ 設定した通信が想定通りにならない場合、以下の点をもとに調査を行う。   1. 想定通りにならないのは特定端末か、全体的に発生するのか。 2. コンテンツフィルタリングルールの優先度 に基づいた観点で確認を行う。(例: 拒否する通信がグループポリシーで許可されてるなど) 3. ダッシュボード上で、制御したいURL のコンテンツと脅威のカテゴリを確認し、対象のカテゴリが設定に含まれていること。 4. Client のMAC アドレスを控える。 5. 端末側の問題に左右されないようにブラウザのプライベートウィンドウなどを用いて接続確認を行う。 6. 通信再現時にMX のLAN 側でパケットキャプチャを行う。     デモンストレーション 以下の設定をもとにデモンストレーションを実施します。   まずは、MX 配下にクライアント端末を接続し、端末上でパケットキャプチャを開始します。 これは、ダッシュボードツールを用いてMX のLAN を指定しパケットキャプチャを開始しても問題ありません。 その後、クライアント端末から"https://ja.wikipedia.org/wiki/シスコシステムズ" の通信を行います。   取得したパケットキャプチャを開き、以下のフィルタを用いて、対象のクライアントからの通信を確認します。 eth.addr == クライアントMAC and tls.handshake.extensions_server_name contains "wiki" ※ デモでは、クライアント端末上のパケットキャプチャのため、eth.addr は割愛していますが、ダッシュボードツールの場合、推奨されます。   以下の例のようにHTTPS の通信の場合、ブラウザ上で接続がリセットされたことが表示されます。 ※ブラウザによって表示の差異がある場合があります。 さらにこの時に宛先のIP アドレスが確認できます。   特定した宛先のIP アドレスでフィルタリングを実施すると、クライアント端末からのTLS ハンドシェイクに対してMX からRST パケットが送信されていることが確認できます。 ip.addr == 宛先IP アドレス   この結果、期待通りに動作することが確認できました。 これは、以下のようにEvent log やSummary report からも確認することできます。   Event log   Summary report     想定通りに機能しない場合、MX のLAN 側でこれらのパケットフローが確認できること、 QUIC などのプロトコルで通信が実施されていないかを確認する必要があります。     特定のURL が予期しないコンテンツのカテゴリに分類された場合 URL が予期しないコンテンツのカテゴリに分類された場合、異議申し立てはTalos のレピュテーションサポートページから直接提出することが可能となります。 詳細は以下のドキュメントをご参照ください。 Content_Category_Dispute   脅威カテゴリに関する申し立てに関しては、Meraki サポートまでご連絡いただき、ご依頼の提出を代行させていただきます。     追加リソース Content_Filtering_Troubleshooting Content_Filtering_Powered_By_Cisco_Talos Content_Filtering Talos_Intelligence Categories     Meraki Learning Hub - Implementing Content Filtering on a Security Appliance - Troubleshooting Content Filtering ... View more

  はじめに EAP-TLS 認証を使用した Radius 認証で、認証が定期的にタイムアウトするケースがあります。   この問題は主にRadius パケットのフラグメンテーション に起因しており、特にパブリッククラウド上(Azure, AWS またはISE など)でRadius サービスを利用している場合やVPN などを用いて拠点を跨いでRadius サーバを利用する構成で発生しやすい傾向があります。 本記事では、問題の原因、確認方法、そして解決策について解説します。   EAP-TLS 認証に関しての詳細は、ドキュメントを参照ください。   問題の概要 EAP-TLS の性質上、大きなパケットサイズ（1500バイト以上）になることがあります。この際、ネットワークデバイス（MR）は フラグメンテーション（IP パケット分割） を行い、これが原因で以下の状況が発生する可能性があります。 MTU の不一致などによる認証パケットドロップ：経路上のデバイスで MTU が異なる場合、フラグメントされたパケットが通信機器（特にファイアウォール）でドロップされる。 Radius サーバでの再構成失敗：フラグメントパケットが Radius サーバに届かない、または過負荷状態になる。結果として、認証がタイムアウトし、失敗するケースが発生します。 経路上でパケットドロップされる：フラグメントされたUDP パケットをファイアウォール等の通信機器が(ポリシーで定義していなくても)ドロップしてしまう場合があります。（順序外のUDP フラグメント、フラグメントパケットをドロップしてしまう設定など。）   例：Azure 環境にISE を構築した場合にフラグメントパケットを順番通りに受信したホストが適切に再構成して処理を行うことができず、パケットドロップされる問題が確認されています。 参考情報：[フラグメンテーション問題のトラブルシューティング：Azureを使用するc9800ワイヤレスコントローラに影響を与える](https://www.cisco.com/c/ja_jp/support/docs/troubleshooting/222339-troubleshoot-fragmentation-issues-affec.html)   フラグメンテーション問題の詳細 EAP-TLS フラグメンテーション： RFC 5216 に基づきフラグメントは正常な動作ですが、Radius プロトコル（通常 UDP 1812）ではフラグメント化されたパケットがファイアウォール等でドロップされることがあります。 特に、クラウド環境（AWS や Azure）に Radius サーバを移行した場合、経路上でのパケットドロップが発生する傾向があります。 初期症状： 認証がタイムアウトする。 EAP-PEAP では認証成功、EAP-TLS では失敗という場合、この問題が疑われます。   問題の確認方法 パケットキャプチャの取得： Radius サーバ側と MR Wired 側の両方でパケットキャプチャを取得。 フラグメントパケットが Radius サーバに届いていない場合、途中経路でドロップされている可能性があります。 Wireshark フィルタの使用： 以下のフィルタを使用してフラグメントパケットを確認します。   _ws.col.info contains "Fragmented IP protocol" or radius または eap.tls.fragments   例： Wireshark で以下のようなフラグメント情報が表示され、問題が特定できます。 以下の例では、Wireshark がパケット 6374、6376、6378、6380 を再構成したことが示されています。 EAPフラグメントのサイズは1,024、1,024、1,024および876で、EAP-TLSメッセージの合計サイズは 3948bytes になります。 [4 EAP-TLS Fragments (3948 bytes): #6374(1024), #6376(1024), #6378(1024), #6380(876)]   解決策 以下のアプローチでフラグメンテーション問題を解決できる可能性があります。 1. MTU サイズの調整 経路上の MTU を統一し、多くのフラグメントが発生しないように設定する。 経路上すべてでJumbo Frame を有効化（現実的には難しい場合あり）。 2. MR（Meraki）デバイスの MTU 設定 現在、MR デバイス自体の MTU 値はダッシュボードから変更できませんが、DHCP オプションを利用して調整可能です。これで、経路上のMTU が統一され、解決につながる見込みがあります。 DHCP Option 26 を使用し、管理インターフェースの MTU を変更します。 設定詳細：[Setting Custom DHCP Options - Cisco Meraki](https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Setting_Custom_DHCP_Options#Internal_Notes_-_DHCP_Options_Not_Being_Sent\) ※注意：設定反映には次回の DHCP リース更新が必要です。 （MR の場合、手動でRelease できないため、上位DHCP の設定変更などを実施してDHCP 情報をリセットする、MR の再起動などが必要。） 3. RadSec（RADIUS over TLS）を使用 UDP を使用する RADIUS の代わりに RadSec（TCP ベース） を採用。 フラグメントが発生しても問題なく通信が可能であり、TLS による暗号化も実現します。 メリット： インターネット越しの通信においてセキュリティが向上。 デメリット： MR 側と Radius サーバ側の両方で設定と証明書インストールが必要。 参考情報：[Configuring RADSec (MR) - Cisco Meraki Documentation](https://documentation.meraki.com/MR/Encryption_and_Authentication/MR_RADSec\) 4. 問題を特定したデバイスでオプション設定の見直し Azure 側のオプション設定にてUDP フラグメントの並べ替え機能を有効化するなど。 これらのオプションに関しては、利用元のベンダに確認いただく必要があります。   参考情報：[フラグメンテーション問題のトラブルシューティング：Azureを使用するc9800ワイヤレスコントローラに影響を与える](https://www.cisco.com/c/ja_jp/support/docs/troubleshooting/222339-troubleshoot-fragmentation-issues-affec.html)   まとめ EAP-TLS 認証におけるフラグメンテーション問題は、Radius 認証のタイムアウトや失敗の主な原因となります。この問題を解決するには、MTU サイズの調整や RadSec の導入が効果的です。特にクラウド環境で Radius サーバを利用している場合には、経路上の MTU 設定や通信機器のポリシーに注意が必要です。   ... View more

  この記事では、端末がインターネット接続ができない場合のトラブルシュートの方法について記載しています。   問診とトラブルシューティングステップ まずは、以下の問診に従って、発生の契機と影響範囲の特定を行います。   事象発生日時を確認。 継続して発生しているか。 継続していない場合、頻度の確認。 発生日時頃、周辺機器の設定変更の有無。 発生する端末は特定か、拠点全体か。 無線、有線どちらでも発生しているか。 宛先は特定のものか、すべての宛先か。 特定のアプリケーション通信のみ不可なのか、すべての通信が不可なのか。 対象にICMP は到達可能か。   設定変更があった場合、もとに戻した時に改善するかを確認する。 特定の端末や通信の場合、端末単位のグループポリシーの適用や経路上にファイアウォールの制限はないか確認する。   上記問診にて影響範囲が特定できない場合、実際のパケットをパケットキャプチャを行い確認します。 影響範囲が明確ではない場合、より端末に近いところからトラブルシュートを行います。   無線端末での事象でMeraki フルスタック構成の場合の例を示します。     ローカルステータスページに接続して、接続しているMR を特定します。  事象発生端末にてパケットキャプチャを開始し、端末上から無線IF にパケットが送信されているか。 ダッシュボードパケットキャプチャツールを活用し、同時にMR のWired（有線）でパケットキャプチャを取得して対象のクライアント、宛先の通信が確認できることを確認します。 宛先はFQDN で、IP アドレスが不明な場合、取得したパケットキャプチャのファイルを開きDNS パケットに含まれるドメイン名または、Client hello のパケットに含まれるサーバー名をフィルタして見つける。 MR からアップストリームへ対象のパケットが送信されていることを確認できた場合、MX のファイアウォールロギングツールを用いてMX にてブロックされていないか確認する。※ツールは、18.2以降で利用可能。 ファイアウォールロギングでブロックされていることが確認できない場合、MX のLAN とInternet で同時にパケットキャプチャを取得して、宛先への通信が含まれていることを確認します。 MX のLAN で対象パケットが見られない場合は、MS のACL モニタリングツールを利用してブロックされていないか確認する。※ツールは、MS16以降で利用可能。   Wireshark DNS filter dns.qry.name contains "FQDN" dns contains "FQDN"   Wireshark TLS filter tls.handshake.extensions_server_name contains "FQDN" デモンストレーション ”https://www.deepl.com/” 宛の通信をブロックした時の確認方法についてデモンストレーションします。 まず、テストのためMX にてdeepl 宛の通信をブロックとして設定します。     クライアント端末から通信を発生させ、「セキュリティ&SD-WAN」>「監視」>アプライアンスステータス>ファイアウォールログ でブロックされていることを確認します。 本ツールのフィルタリング方法は、ドキュメントを参照する。       念のため、通信を発生させた時に、MX のLAN とInternet でパケットキャプチャを同時に取得し、TLS パケットを確認するとInternet ではそのパケットが見られず、期待通りに動作していることを確認します。   tls.handshake.extensions_server_name contains "deepl"     次に、対象のファイアウォールルールを削除し、アップストリームのRT で対象通信をフィルタリングし、通信を発生させ動作を確認します。 ファイアウォールロギングでは、許可されていること、Internet のパケットキャプチャでMX からアップストリームへパケットが転送されていることが確認できます。     この場合、MX よりアップストリームの問題の可能性が高いと考えられます。     ... View more

  概要 ワイヤレスクライアント端末のスループットは、クライアントがネットワーク上で達成できる理論上の最大データレートを把握する必要があります。 802.11におけるアクセスポイント（AP）とクライアント間のデータレートは、主に以下の要因によって決定されます。   通信規格: 802.11には複数の規格（例：802.11a/b/g/n/ac/axなど）があり、それぞれがサポートする最大データレートが異なります。APとクライアントがどの規格をサポートしているかによって利用可能なデータレートが決まります。 チャネル帯域幅: 20MHz、40MHz、80MHz、160MHzなどのチャネル帯域幅があり、広い帯域幅を使用するほど高いデータレートを達成できます。 変調方式と符号化方式（MCS: Modulation and Coding Scheme）: 変調方式（例：BPSK、QPSK、16-QAM、64-QAM、256-QAMなど）と符号化方式の組み合わせによってデータレートが決まります。より高次の変調方式を使用することで、データレートが向上しますが、受信品質が必要です。 送信電力と受信感度: 信号強度が高い場合、より高いデータレートを選択することが可能です。一方、距離が遠い場合や障害物が多い場合には、信号が弱くなり、低いデータレートが選択されることがあります。 SNR（Signal-to-Noise Ratio）: ノイズに対する信号の強さの比率です。SNRが高いほど、高いデータレートを利用できます。 MIMO（Multiple Input Multiple Output）技術: MIMO技術を使用することで、複数のアンテナを活用してデータスループットを向上させることができます。MIMOのストリーム数が多いほど、データレートが向上します。 環境要因: 物理的な障害物、電波干渉、移動速度などの環境要因もデータレートに影響を与えます。これらの要因を基に、APとクライアントは動的に最適なデータレートを選択し、通信の信頼性と速度を最適化します。 デバイスが定期的にリンクの状態を評価し、必要に応じてデータレートを調整するプロセスを「リンクアダプテーション」と呼びます。 通信規格毎に定められたデータレートは、MCS テーブルで確認することができます。 MCS テーブルは、上記の要因の組み合わせに基づいて論理的に数値化されたものです。 MCS テーブルの各要素の詳細や使い方は、外部リンクですが、以下をご参照ください。 MCS Table and How To Use it – Wireless LAN Professionals   さらに、ワイヤレスの半二重の性質であることやオーバーヘッドと以下の要因と組み合わされると、 無線端末の実際のスループットは、通常、アドバタイズされた理論上の最大データレートの 50% 以下(50-70%程度)である可能性があります。 さらに、スループットを制限する可能性のある要因には、次のようなものがあります。   - クライアントデバイスからAPまでの距離。 - 信号対雑音比(SNR) の悪化。 - 干渉(無線、物理、電気)の影響。 - 物理的な障害物の影響。 - その他の近くのワイヤレスネットワークとデバイスの影響。(802.11 は帯域を共有するため) - デバイス側のパフォーマンス制限機能など。 無線クライアント端末の理論上の最大データレートをもとに、おおよその無線端末の予想スループットを求めることができます。 一般的には、”Maximum Theoretical Throughput ＝ Maximum Possible Data Rate × 0.7” でこれらの値を求めることができます。 例えば、VHT(802.11ac Wi-Fi5), 256-QAM, 80Mhz etc, の場合、780Mbps が理論上の最大データレートとなりますが、780×0.7 = 546Mbps が予想スループットとなります。（無線クライアント端末が1台の場合）   参考元：https://mcsindex.com/ ワイヤレスネットワークは共有されるため、ここから、30台の利用が想定される場合、計算上、546/30 = 18Mbps が約1台あたり利用可能な予想スループットの値となります。 また、一般的なアプリケーションのスループット要件は、20Mbps を満たしていることで処理が可能と考えられています。 参考：高密度 Wi-Fi の導入 - Cisco Meraki ドキュメンテーション How Much Speed Do You Need on the Internet?   この記事では、スループット計算とテストにフォーカスしています。 上記に記載した無線環境におけるトラブルシュート観点や方法は、以下の記事もご参照ください。 https://community.meraki.com/t5/Meraki-サポートの記事/無線環境の不安定時の切り分け方法/ba-p/151056 https://community.meraki.com/t5/Meraki-サポートの記事/1つのAPに複数のクライアントが集中してしまう原因と対処方法/ba-p/194518     データレートの確認方法(ダッシュボード/ローカルツール の利用) ダッシュボードツールを利用して、データレートなどスループットに影響を及ぼす観点での調査を行うことができます。 通常、Meraki ダッシュボードでは、クライアント端末が接続してから、10分ほどで無線クライアントの情報が反映されます。   - クライアント観点からの調査 特定のクライアントに関する詳細情報(ドキュメント) ダッシュボードパス：「ネットワーク全体 > クライアント > “対象のクライアント” > パフォーマンス 」 主な観点 - シグナル品質：SNR 値が 20 dB 以上の信号はデータ ネットワークに推奨され、音声アプリケーションを使用するネットワークには 25 dB 以上の SNR 値が推奨されます。 - AP チャネル利用率：50% を超える場合は、パフォーマンスの問題が発生している可能性が高く、使用率が上がるにつれて重大度が高くなります。 - AP クライアント数：1つバンドに接続されているクライアント数が25台以上を超える場合、パフォーマンスが低下する傾向にある。 - データレート：低データレートとなっていないか。低データレートとなる場合、環境の要因や端末の仕様によるものが大きい。     - AP 観点からの調査 特定のアクセスポイントに関するステータス情報(ドキュメント) ダッシュボードパス：「ワイヤレス > アクセスポイント > “対象のAP” > パフォーマンス」 主な観点 - クライアント：1つバンドに接続されているクライアント数が25台以上を超える場合、パフォーマンスが低下する傾向にある。 - 平均シグナル品質：SNR 値が 20 dB 以上の信号はデータ ネットワークに推奨され、音声アプリケーションを使用するネットワークには 25 dB 以上の SNR 値が推奨されます。 - チャネル利用率：50% を超える場合は、パフォーマンスの問題が発生している可能性が高く、使用率が上がるにつれて重大度が高くなります。 - データレート：低データレートとなっていないか。低データレートとなる場合、環境の要因や端末の仕様によるものが大きい。     - ローカルステータスページ観点からの調査 特定のアクセスポイントに関するステータス情報(アクセス方法) パス：「SSID へ接続し、http://10.128.128.126」   主な観点 - シグナル：SNR 値が 20 dB 以上の信号はデータ ネットワークに推奨され、音声アプリケーションを使用するネットワークには 25 dB 以上の SNR 値が推奨されます。 - チャネル利用率：50% を超える場合は、パフォーマンスの問題が発生している可能性が高く、使用率が上がるにつれて重大度が高くなります。 - スピードテスト：無線クライアントからアクセス ポイントまで速度テストを実施することができます。   ※現時点(2025/4/10 時点)にてLocal status page でのSpeed test は約 250 Mbps に制限される仕様となっているため、 40Mhz、80Mhz の高スループットが予想される場合、ローカル環境でのIPerf テストやSpeed test にて計測を行う必要があります。       スループットのテスト いくつかのシナリオにてスループットテストを実施します。 ※結果に関しては、トラフィックの制限などを設定していない環境での試験となります。 また、環境や利用端末など様々な観点にて変動する可能性が多くあるため、参考値としていただけますと幸いです。 シナリオ1: クライアント端末1台にてインターネット向けのスループット試験を行い結果を測定する。     80Mhz 設定の場合 - クライアント端末とダッシュボードで理論上の最大データレートを確認します。 ダッシュボードパス：「ネットワーク全体 > クライアント > “対象のクライアント” > パフォーマンス 」   - 端末でインターネット向けのスループットテストを行います。この時、データレートが780 Mbps となっているため、 ”Maximum Theoretical Throughput ＝ Maximum Possible Data Rate × 0.7” の式に当てはめると、780 × 0.7 = 546Mbps が予想される実際のスループットとなり、概ね、実測値も同じであることが確認できます。   - この時、ワイヤレスパケットキャプチャを取得することでも、MCN Index の情報を確認することができます。     20Mhz の場合 - クライアント端末とダッシュボードで理論上の最大データレートを確認します。 ダッシュボードパス：「ネットワーク全体 > クライアント > “対象のクライアント” > パフォーマンス 」   - 端末でインターネット向けのスループットテストを行います。この時、データレートが173 Mbps となっているため、 ”Maximum Theoretical Throughput ＝ Maximum Possible Data Rate × 0.7” の式に当てはめると、173 × 0.7 = 121Mbps が予想される実際のスループットとなり、概ね、実測値に近しい値であることが確認できます。   Local status page からも近しい値を確認できます。     シナリオ2: クライアント端末3台にてインターネット向けのスループット試験を行い結果を測定する。   ※MR では、80Mhz の設定としています。   - 端末でインターネット向けのスループットテストを行います。この時、データレートが866 Mbps となっているため、 ”Maximum Theoretical Throughput ＝ Maximum Possible Data Rate × 0.7” の式に当てはめると、866 × 0.7 = 606 / 3 = 202Mbps が予想される実際のスループットとなり、 平均して実測値も近しいことが確認できます。このことから、無線のスループットは帯域を共有していることが確認できます。 Windows 11   MacBook-Air   IPhone 12 Pro Max     シナリオ3: クライアントの信号強度が弱まった時の測定結果を確認する。   ※MR では、20Mhz の設定としています。 - テストでは、室内で接続を行い、金属の扉を挟んだ外に端末を持ち出して確認しております。   事前チェック 端末でインターネット向けのスループットテストを行います。この時、データレートが173 Mbps となっているため、 ”Maximum Theoretical Throughput ＝ Maximum Possible Data Rate × 0.7” の式に当てはめると、173 × 0.7 = 121Mbps が予想される実際のスループットとなり、実測値も近しいことが確認できます。     テスト ドア越しに、端末でインターネット向けのスループットテストを行います。この時、データレートがおよそ46 Mbps となっているため、 ”Maximum Theoretical Throughput ＝ Maximum Possible Data Rate × 0.7” の式に当てはめると、46 × 0.7 = 32Mbps が予想される実際のスループットとなるが、それ以下の数値を示していることがわかります。   この時にパケットキャプチャを取得して Wireshark > 統計 > 入出力グラフ を用いて、信号強度とデータレートを追跡したところ、 信号強度の低下に伴ってデータレートも低下することがわかります。これは、上述したMCN テーブルに基づいて再算出されていることになります。   また、以下の設定を使用して、グラフ化することができます。 Wireshark > 統計 > 入出力グラフ - Graph name: 任意の説明的な名前 - 信号強度のDisplay Filter：wlan.addr == 'Client mac' and wlan.fc.type == 2 信号強度のY Field：wlan_radio.signal_db データレートのDisplay Filter： wlan.sa == 'Client mac' データレートのY Field：radiotap.vht.datarate.0 - Color: 任意の色。 - Style: Line (デフォルト) - Y Axis: 信号強度 = AVG (Y Field) 、データレート = MIN (Y Field) - SMA Period: None(デフォルト)     さらにこの時に、クライアント端末のデータフレームの内訳は以下の通りとなっていることがわかりました。 クライアント端末のデータフレームパケット：1649 packets (wlan.addr == MAC and wlan.fc.type == 2) クライアント端末のデータフレームの再送信パケット：631 packets (wlan.addr == MAC and wlan.fc.type == 2 and wlan.fc.retry == 1 )   再送信の割合を計算すると、631(再送) / 1649(全体) ×100 = 38.27% が再送信となっていることがわかりました。 同様にシナリオ1 の時のパケットキャプチャで計算すると、151(再送) / 67524(全体) × 100 = 0.22% となっておりました。そのため、無線通信においては、信号強度が大切であることがわかります。   また、スピードテストの結果の他にIPerf を用いてスループットに関するトラブルシュートを行うことも可能ですが、この記事では記載しません。     追加リソース Wireless Throughput Calculations and Limitations - Cisco Meraki Documentation Tools for Troubleshooting Poor Wireless Performance - Cisco Meraki Documentation Signal-to-Noise Ratio (SNR) and Wireless Signal Strength - Cisco Meraki Documentation Wi-Fi 6/6EおよびWi-Fi 7ワイヤレススループットの検証とテスト - Cisco   ... View more

  クライアント端末のパフォーマンスに関する問題を切り分けるためには問題の発生箇所や影響範囲を正確に特定することが重要です この記事では、影響範囲を特定するためのiPerf を用いたトラブルシュートステップについて解説します。     はじめに TCP スループットの理論値について TCP スループット低下の要因は、ネットワーク遅延とパケットロスなどが考えられます。 TCP 通信では、レイテンシが大きくなると比例してスループットは低下し、通信の完了が大きく影響を受けます。 TCP 通信の最大スループットの理論値はこのウィンドウサイズと往復遅延時間（RTT: Round Trip Time）から以下の式で求めることができます。   式 スループット = TCP Window Size(Bit) / RTT(sec) ※これは、理論値となるため、様々な要因で変動する可能性のあるものとなっております。 デフォルトのウィンドウサイズはOS によって異なりますが、一般的には64KB 程度となっております。 しかし、実際には、64KB では現在のネットワークでは不足しており、RFC 1323で定義されているTCP オプションや 複数のTCP セッションを構成することで実通信は拡張されることになります。   つまり、予想される理論値に基づいて、iPerf などのテスト結果とサイジングガイドに沿った期待されるパフォーマンスが出せていることが確認でき、 遅延とパケットロスが無くパフォーマンスが悪い状況が続く場合は、クライアント端末側のチューニングやネットワーク環境のチューニング(輻輳制御/帯域制御、MTU など)することで改善が見込まれます。例えば、以下の観点のチューニングが考えられます。 - Path MTU Discovery - OS での TCP Buffer Size 調整 - Software での TCP Buffer Size 調整 - 転送回数削減: 並列処理、効率的プログラミング・アルゴリズムの使用、など - 転送サイズ縮小化: データ圧縮、オーバーヘッドの少ない暗号アルゴリズムの選択、など   これらのチューニングに関しては、以下のMicrosoft、Google、Cisco からも公開された記事があります。 [ネットワーク アダプターのパフォーマンス チューニング | Microsoft Learn] [ネットワーク パフォーマンスの TCP 最適化  |  Compute Engine Documentation  |  Google Cloud] [アプリケーションが10Mbpsしか使用しない理由リンクが1Gbpsであっても？]     前述の通り、64KB は、現在のネットワークでは十分ではありませんが、パフォーマンス測定のために64KB でのiPerf テストも効果的です。 例えば、64 KB (524288 bit)を6ms (0.006s)で割った値 = 87381333 bit/s = 約87Mbps が予想されるTCP スループット理論値となります。 しかし、実際のテストは、クライアント処理速度など様々な要因により常にわずかに低くなることが予想されます。   64KB の時のRTT に応じた理論値のスループット値(並列クライアントストリームはシングルの想定)   以下のiPerf テストでは、RTT 値は平均8ms となっているため、約66Mbps が理論値となり近しい値となっています。     iPerf の解説   iPerf は、Server とClient の2台のPC を用意して、LAN およびWLAN のスループットをテストするために使用できるツールです。 iPerf アプリケーションのダウンロードや使い方は、ドキュメント内のリンクを参照してください。   利用構成例：   以下は、iPerf のコマンドオプションの解説と便利なコマンドセットです。   オプションリスト -s ＝ サーバの指定 -c ＝ クライアントの指定 -R ＝ 逆方向モードで実行 (サーバが送信、クライアントが受信) -w ＝ TCP window size の指定 -P ＝ 実行する並列クライアントストリームの数 --logfile = 実行ディレクトリに指定のファイル名のログを保存する -u ＝ UDP の指定 -b ＝ ターゲットビットレート（ビット/秒）の指定。（無制限の場合は0）（デフォルトはUDPの場合は1 Mbit/秒、TCPの場合は無制限） -i  ＝ 定期的なスループット報告の間隔（秒）   便利なコマンドセット Server side: iperf3 -s --logfile [file name]   Client side: - Performance per Window size per direction（TCP） iperf3 -c <server_IP> -w 128kb -P 3 --logfile [file name] iperf3 -R -c <server_IP> -w 128kb -P 3 --logfile [file name] iperf3 -c <server_IP> -w 256kb -P 3 --logfile [file name] iperf3 -R -c <server_IP> -w 256kb -P 3 --logfile [file name] iperf3 -c <server_IP> -w 5M -P 3 --logfile [file name] iperf3 -R -c <server_IP> -w 5M -P 3 --logfile [file name]   - Bandwidth test（UDP） iperf3 -c <server_IP> -u -b 50M --logfile [file name] iperf3 -R -c <server_IP> -u -b 50M --logfile [file name] iperf3 -c <server_IP> -u -b 80M --logfile [file name] iperf3 -R -c <server_IP> -u -b 80M --logfile [file name] iperf3 -c <server_IP> -u -b 100M --logfile [file name] iperf3 -R -c <server_IP> -u -b 100M --logfile [file name] iperf3 -c <server_IP> -u -b 150M --logfile [file name] iperf3 -R -c <server_IP> -u -b 150M --logfile [file name] iperf3 -c <server_IP> -u -b 200M --logfile [file name] iperf3 -R -c <server_IP> -u -b 200M --logfile [file name]     チェックリスト 1. 問診をもとに問題箇所の特定と想定されるWAN リンク速度を確認します。 2. ドキュメントを参考にICMP レベルにて拠点内でのパケットロスが無いことを確認します。 3. MX をご利用の場合は、サイジングガイドでデバイスと設定値をチェックし、期待される最大スループットを確認します。 4. 対象宛先または、iPerf サーバに対してPing を実行して、RTT 値を確認する。 5. Traceroute、MTR、Pathping(Windows) などを実行して、経路上のLoss が無いことを確認する。 6. iPerf にてパフォーマンス測定を実施します。この時にパケットキャプチャの取得も行います。 ※外部リンクですが、Public iPerf サーバを利用することも可能。 https://github.com/R0GGER/public-iperf3-servers また、iPerf を用いたテストを行うことで被疑箇所の特定と期待値の測定などを実施することが可能となります。 被疑箇所の特定の考え方を以下に示します。 構成はMeraki フルスタック構成例となりますが、被疑箇所の特定は、他の構成でも同じ考え方が当てはまります。   ① インターネットスピードテスト、または、VPN 越しにiPerf または、Speed test を実行した時に低パフォーマンスが見られるか。（実際の事象の確認） ② MX に直接接続した時に同じテストを実施して、事象が見られるか。（この時に事象が見られない場合、LAN 内における問題の可能性が高い。） ③ MR 配下のiPerf client からMX に直接接続しているServer に向けてテストを実施した時に同様に低パフォーマンスが見られるか。（ここで事象が見られる場合、MS とMX の間の問題の可能性が高い。） ④ 同じようにMS に接続しているServer に向けてテストを行い同様の事象が見られるか。この時、影響範囲の絞り込むため別のMR がある場合は、別のMR からも実施する。（ここで事象が見られる場合、無線環境または、MR とMS の間の問題の可能性が高い。なお、この時点で③で事象が見られるが④で見られない場合は、③の被疑が強まる。） ⑤ 異なるMR がある場合、MR 間のクライアントでiPerf テストを実施する。異なるMR がない場合、MR のLocal status page にアクセスしてSpeed test 測定を行う。（ここで事象が見られる場合、無線環境の問題の可能性が高い。） ※ Local status page のSpeed test は、現時点（2025-02-25）では約 250 Mbps に制限されているため、40Mhz、80Mhz を利用しており、 スループットが超過することが予想される場合、ローカル環境でのiPerf テストを行う必要があります。   構成例：     TCP 試験例   例えば、以下の試験では、RTT 値は平均8ms となっているため、約66Mbps が理論値となり近しい値となっています。   iperf3.exe -c Server IP -i 1 -w 64KB     さらに、並列ストリーム (3つのインスタンスを実行)して実施すると3倍程度の値となっていることが確認できます。 この結果から、TCP ストリームが増えることでその分可能な通信量が増えることを証明しています。   iperf3.exe -c Server IP -i 1 -w 64KB -P 3   さらにウィンドウサイズを大きくすることでさらに増加することが確認できます。 この結果から、ウィンドウサイズが増え一回の送信する量が増える分可能な通信量が増えることを証明しています。   iperf3.exe -c Server IP -i 1 -w 5M -P 3     UDP 試験例 さらに、UDP の通信に関しても確認を進めていきます。 UDP の場合は、プロトコルの性質上、理論値の算出はできません。 しかし、通常は、帯域で利用可能な上限を送信可能と考えられます。 UDP の場合、-b コマンドを利用して徐々に回線の上限まで引き上げて確認を進めていきます。   iperf3.exe -c Server IP -u -b 100M 100M の場合、ロスが無いことが確認できます。   iperf3.exe -c Server IP -u -b 300M or 400M   300,400M とすると、トラフィックが過負荷になり、パケットの数% が受信者によってドロップされ、 速度は約250 - 260Mbpsであることがわかります。 これは、MX をご利用の場合、サイジングガイドで期待されている予想範囲内にあれば問題ありません。 ※各ネットワーク環境とトラフィックの特徴は独自のものであることに注意してください。 サイジングガイドで提示されている数値は、有害なネットワークや特徴のあるトラフィックの挙動が存在しない状態でのテスト中に取得されたものであるということにご留意ください。 今回の場合、TCP で確認したものと大きな差異は無いため問題無いと判断できます。     追加リソース Troubleshooting Client Speed using iPerf - Cisco Meraki Documentation https://community.meraki.com/t5/Meraki-サポートの記事/スループットの問題が発生した際の確認ポイント/ba-p/270330 https://community.meraki.com/t5/Meraki-サポートの記事/ワイヤレススループットの計算とテスト/ba-p/268941   ... View more

はじめに クライアント端末のパフォーマンスに関する問題を切り分けるためには問題の発生箇所や影響範囲を正確に特定することが重要です。 この記事では、影響範囲を特定するための問診の進め方について解説します。     問診 **前提条件の整理** - 有線接続でUSB NIC などを利用している場合、NIC の最大転送速度を確認。 (一部の USB-A または USB-C アダプターはUSB 2.0 を実行し、480Mbps が最大の場合があります。) - 利用中のWAN 回線の速度を確認。 - MX を利用している場合、設定内容に応じた、デバイスの最大スループットをサイジングガイドまたは各モデルごとのデータシートで確認。  特にVPN を利用している場合、スループットがさらに低下することを考慮してください。     **初期診断** - 事象の発生日時を記録。例 2024-03-15 10:00 - 発生頻度や再現性はあるか確認。 - 事象が発生してから継続時間を記録。 - 影響を受けたクライアント端末のMac アドレスを記録。   影響を受けていない端末がある場合は、それらのMACアドレスも記録。 - 事象が発生するデバイスの種類 (iOS、Windows)、ハードウェア (Macbook air、Lenovo X220)、およびドライバーの種類に共通点はあるか確認。 - 無線と有線、どちらに起因しているか確認。（例：MR接続時にのみ発生し、MX直結では発生しない。） - VPN 経由の通信のみ影響があるか。L2, L3 間の拠点内通信でも事象が発生するか。 - 事象発生タイミングの傾向を確認（例：15 分ごとに発生する、15:00 頃によく見られる。） - 対象までのICMP での遅延はどの程度であるか。 - パフォーマンス低下がすべてのトラフィックに影響しているか。 （例：TCP通信のみ問題があり、ICMPは問題なし。もし ICMPでも問題がある場合は、Tracerouteなどで経路を確認。）   被疑箇所が同一LAN 内であると想定される場合、以下の点を確認する。 - デュプレックスの不一致：設定の不一致が無いこと、コミュニティ記事を参考に物理的な切り分けを実施する。 - ケーブル不良または接触不良：コミュニティ記事を参考に物理的な切り分けを実施する。 - リンクの輻輳：利用可能な帯域を増やす、トラフィック シェービング ルールを適用して1ユーザ単位などで制御することは可能か。 - ファイアウォールが特定のトラフィックをブロックしている：FW の設定に誤りが無いか確認する。 - 経路上にて、MTU/MSS の問題がないか。パケットキャプチャを取得してフラグメンテーションが発生していないか。 - 事象発生日時付近にて設定や構成の変更はあったか。 - 特定のクライアント端末で発生するのか、それとも全体的に発生するのか。 特定の端末にて発生する場合は、無線ドライバー/USB NIC のアップデートなどを試して改善が見られるか。 - 事象発生時の利用クライアント端末数はどの程度か。     **追加の無線の診断** - 事象が発生する特定のAP または SSID など特徴はあるか。 - 事象発生時のクライアント接続数はどの程度か。 - 悪天候、樹木の成長、新しく建てられた壁などの環境要因に変更はあるか。 - クライアントデバイスからAP までの距離はどの程度か。 - 信号対雑音比(SNR) の値は良好であるか。一般に、SNR 値が 20 dB 以上の信号はデータ ネットワークに推奨され、音声アプリケーションを使用するネットワークには 25 dB 以上の SNR 値が推奨されます。 - 干渉(無線、物理、電気)が発生していないか。 - 端末側でパフォーマンスの制限機能がないか。     追加リソース https://community.meraki.com/t5/Meraki-サポートの記事/iPerf-を用いたスループット問題の特定とテスト/ba-p/270156 https://community.meraki.com/t5/Meraki-サポートの記事/ワイヤレススループットの計算とテスト/ba-p/268941 ... View more

概要   本記事では、Auto VPN における、Unfriendly 状態の理解とトラブルシュートについて記載をしております。   Auto VPN におけるトンネル確立のトラブルシュートは以下の記事をご参照ください。 Auto VPN機能におけるVPNトンネル確立のトラブルシューティングについて - The Meraki Community       Auto VPN の前提理解 NAT デバイスのLAN 側でMX を利用する場合、通常のIPsec-VPN では、そのNAT デバイスでUDP port 500,4500 をMX に対してポートフォワーディングする設定が必要となります。 しかし、Auto VPN では、UDP ホールパンチングという仕組みを利用してNAT 配下の場合にも、特に設定変更を意識せずにVPN を構築することが可能となります。※NAT デバイスやFW が厳しい要件の場合の例外はあります。   Auto VPN のUDP ホールパンチングの仕組みについては深く解説しませんが、前提理解のため簡単に記載をいたします。   初めにVPN Registry と呼ばれるMeraki クラウド側のサーバと接続を実施し、同じダッシュボードネットワークでVPN を有効としている隣接情報を取得します。 これによって、接続先のIP アドレスとポート番号などの情報がMX 間で通知されます。 (Warm spare 構成の場合、Spare 機器に切り替わる際にもPrimary と同じポートが使われます。)   *構成例(アップリンクにファイアウォールデバイスが存在する想定)     その後、Registry から取得した情報をもとに拠点間でVPN のコネクションを実施します。 一般的に、ファイアウォールではWAN からのインバウンド通信に対してブロックされる動作となるため、図の通りにブロックされる動作となります。       その後、先ほどの通信で拠点のアップストリームファイアウォールではNAT テーブルが生成され、ステートフルファイアウォールによって戻りのトラフィックが許可されるため、 パケットがNAT デバイスを超えてMX に到達することになります。これが、UDP ホールパンチングという仕組みになります。     Auto VPN とUDP ホールパンチングの詳細については、以下のドキュメントも参考となります。 Meraki Auto VPN - Configuration and Troubleshooting - Cisco Meraki Documentation Automatic NAT Traversal for Auto VPN Tunneling between Cisco Meraki Peers - Cisco Meraki Documentation       Unfriendly 状態について   UDP ホールパンチングは、拠点間のMX で一貫した IP アドレスとポートである必要があります。 VPN Registry は冗長性のために2 つのサーバーが使用されており、どちらもMX が同じパブリック IP アドレスとポートで利用可能であることを確認しています。 Unfriendly 状態としてマークされる場合、以下の状態にあることが考えられます。   1. 一部のNAT デバイス(ファイアウォールなど)で、VPN registry ごとに異なるソースポートに書き換え通信を実施している。     2. 一部のNAT デバイスまたはロードバランサーで、VPN registry ごとに2つの異なるパブリックIP アドレスを用いて通信を実施している。 これは、SNAT Load Balancing とも呼ばれる機能となります。     また、このような環境やCarrier-Grade NAT(通信事業者がIP 枯渇の対策として利用する機能)環境においては、Auto VPN に関するポート番号が変更されることでUDP ホールパンチングが機能しない場合があります。 以下の例では、片側のファイアウォール にて送信元ポート番号が変更されたことでUDP ホールパンチングが機能せずVPN パケットが通過できない状態となっています。       トラブルシュート   解決策1： MX のアップストリームのNAT デバイスでPreserve Source Port（送信元ポートの保持）設定を有効にする。 この問題は、パブリックIP とポート番号の組み合わせが変更されることによって発生するため、書き換えをしないことで解消する可能性があります。   以下の例では、赤い丸のデバイスが送信元ポート番号を変更しているため、設定対象となります。   NAT デバイスのPreserve Source Port 設定に関しては、ご利用機器のベンダに確認をいただくことが推奨されます。       解決策2： MX のアップストリームファイアウォールデバイスによっては、MX のWarm spare の切り替わり時に、MX の送信元IP が変更となることで、転送時の送信元ポートを変更する動作をとる場合があります。 NAT 配下でMX を利用する場合、耐障害性を高めるためにも仮想IP を用いて、MX が利用するIP を1つとすることで解決する可能性があります。   以下の例では、Spoke 拠点がWarm spare 構成を取っていると仮定した時、赤い丸のデバイスが設定対象となります。   MX の仮想IP の設定方法は以下のドキュメントをご参照ください。 MX Warm Spare - High-Availability Pair - Cisco Meraki Documentation       解決策3： NAT デバイスにて、SNAT Load Balancing などが利用されており、VPN Registry 宛ての通信が2つのパブリック IP アドレスに変換されてしまっている場合、 内部からのMX のトラフィックを単一のパブリックIP アドレスにマッピングするように設定を行います。 これにより、VPN レジストリで参照されるパブリック IP アドレスが常に同じになるため、解決する可能性があります。   以下の例では、赤い丸のデバイスがパブリックIP を複数のIP に変更している想定のため、設定対象となります。   SNAT Load Balancing は、Cisco RT などであればNAT Pool を用いたOverload の設定となるため、 これを1つのパブリックIP を利用するように設定変更を行う必要があります。(1:1 NAT など)       解決策4： Meraki ダッシュボードにて、Auto VPN の手動ポート転送にて任意のポート番号を設定し、アップストリームファイアウォールでポートフォワーディング機能を有効にして、MX へトラフィックを転送する。  これによってポート書き換えされたトラフィックを転送することが可能となるため、解決する可能性があります。   以下の例では、赤い丸のデバイスとMX が設定対象となります。     まずは、セキュリティ&SD-WAN > サイト間VPN > NAT トラバーサル > 手動: ポート転送 にて、左側の拠点で利用されるパブリックIP と任意のポート番号の指定を行います。（ポート範囲は1024-65535）   例の場合は、Spoke からHub に対してUDP 60000 を宛先としてUDP ホールパンチングが行われます。   次に、Hub 拠点のアップストリームファイアウォールにてUDP 60000 で受けたトラフィックをLAN 側のMX へ転送するようにポートフォワーディングの設定を行います。 これにより、Hub に到達できるようになります。   Hub はVPN Registry から取得した情報に存在しないSpoke から有効なAuto VPN パケットを受信すると、パケットのパブリックIP とUDP ポートを使用して新しいコネクションベースのエントリを追加してVPN 通信を開始します。       デモンストレーション   Fortigate 50E(v6.2.16 build1392 (GA)) を用いて疑似的にUnfriendly 状態を再現し、アップリンクデバイスにて状況を確認しました。 デモンストレーション構成は以下の試験構成となります。   ※試験結果は、あくまで試験としての参考情報としていただけますと幸いです。 また、こちらはラボ環境の設定例となります。ファームウェアバージョンなどによっても変動する可能性はありますので、 設定などの詳細はベンダーへご確認ください。   シナリオ：NAT デバイスが送信元ポートを変更してしまう環境にて、Primary 機器をダウンさせた時の挙動   通常時、VPN Registry  への通信は、Primary 機器から送信されたものが確認されています。     Primary 機器の電源断を行い、Warm spare の切り替えを実施します。すると、新しくSecondary 機器のNAT テーブルが作成されます。 しかし、画像の通りにSecondary の通信の送信元ポートの書き換えが行われていることが確認できます。     この状態の場合、MXではUnfriendly 状態を検知します。 また、Secondary 機器から対向ピアに対してのVPN 通信のポート番号も変更されるため、VPN 通信に影響を及ぼすことになります。     この時、Fortigate におけるポリシーの設定では、Preserve Source Port（送信元ポートの保持）設定が無効となっていたため、有効として確認を行います。     ポリシー変更後、Primary 機器をもとに戻し、通常状態のNAT テーブルを確認します。     その後、Primary 機器の電源断を行い確認をすると、Primary 機器のNAT フローテーブルを保持せずに単一のNAT フローが残っている状態を確認することができます。     この状態の場合、MXではFriendly 状態を検知し、Auto VPN の通信に異常は見られませんでした。 また、上記検証では、MX にて個別のIP を利用する設定となっていたが、仮想IP を設定した場合には、2つのNAT フローが作成されることはなかったため、今回の事象は発生しませんでした。     追加リソース   Carrier-Grade NAT and Meraki Auto VPN - Cisco Meraki Documentation Meraki Auto VPN - Configuration and Troubleshooting - Cisco Meraki Documentation Meraki Auto VPN General Best Practices - Cisco Meraki Documentation Auto VPN Hub Deployment Recommendations - Cisco Meraki Documentation Automatic NAT Traversal for Auto VPN Tunneling between Cisco Meraki Peers - Cisco Meraki Documentation ... View more

  MR 予期しない低電力モード（Unplanned low power mode）アラートの切り分け方法 本記事では、「予期しない低電力モード（Unplanned low power mode）」というアラートの概要と切り分け方法についてご紹介いたします。 お使いのデバイスにて本アラートが発生した際、本記事がトラブルシューティングの一助となれば幸いです。       本アラートの概要 本アラートは、MR のサポートしているPoE 規格と異なるPoE スイッチに接続した場合、起動時の電力ネゴシエーションやPoE SW のバジェット不足にて電力が不足した場合などに発報されます。 低電力モードは、通常、AP が全機能をサポートするのに十分な電力を受け取っていないフォールバックした状態を示しております。     本アラートのリスクと影響 リスクと影響： 予期せぬ再起動のリスク：特にネットワーク負荷が高い場合、MR が予期せぬ再起動が発生する可能性があります。これは、十分な電力が供給されないことによって、デバイスが動作を安定して維持できないためです。   機能への影響：電力消費を抑えるために、いくつかの機能に影響が及ぶ可能性があります。これには以下が含まれます。 Air Marshal：Air Marshal に関する、MR の専用スキャン無線インターフェースが無効となる可能性があります。これにより、不正なデバイスやその他の無線脅威の検出や防止が行えない状態となります。 無線：MR は、1つまたは複数の無線インターフェースを無効として、空間ストリームの数を減らす可能性があります。これにより、無線カバレッジやパフォーマンス、クライアント接続の処理能力を低下させることになります。 USB インターフェース：IoT などの外部デバイスをサポートするためのUSB インターフェースが無効となる可能性があります。   低電力モード時の動作については、MR モデルによって異なる可能性があるため、インストールガイド をご参照ください。     本アラートの主な原因 低電力モードの主な原因は、通常、物理的な問題であり、以下のようなものが考えられます。 規格外のイーサネットケーブルの利用：規格外のイーサネットケーブルは、電力供給の不足につながる可能性があります。例えば、「IEEE802.3at」ではCat5e 以上のLAN ケーブルを使用しなければなりません。 PoE バジェット不足：PoE スイッチに接続されたデバイスが多く、電力負荷がかかりすぎており、電力バジェットが不足している可能性があります。 RJ-45 コネクタ、イーサネットケーブルの緩み：RJ-45 コネクタやイーサネットケーブルが緩んでいたり、正しく接続されていない場合、断続的に電力が供給されることがあります。これにより、MR の電力供給が不安定になり、低電力モードがトリガーされる場合があります。 RJ-45 コネクタ、イーサネットケーブルの損傷：RJ-45 コネクタイーサネットケーブルに物理的な損傷（破損、切断、ねじれ、過度な曲げなど）がある場合、電力供給が不足する場合があります。 接続先スイッチにてLLDP が有効になっていない場合：電力ネゴシエーションの関係によってアラートが報告される場合があります。     本アラート発報時の基本的な切り分け方法   - POE の規格に沿ったケーブルを利用しているか。 例えば、「IEEE802.3at」ではCat5e 以上のLAN ケーブルを使用しなければなりません。   - MR の接続先デバイス、ポートで、CDP/LLDP が稼働しているか。 PoE+(802.3at)、PoE++(802.bt)などの規格の場合、追加の電力要求のためにCDP とLLDP の両方を使用して電力のネゴシエーションを実施する必要があります。 また、何らかの影響によって、起動処理の中で行われるPoE ネゴシエーション時に、CDP パケットがネゴシエーションの時間内に到達しない場合があります。 Meraki では可能な限り、接続先スイッチにてCDP と LLDP の両方を有効にすることを推奨しております。 Cisco switch でのLLDP の有効化については、ドキュメントをご参照ください。     - PoE バジェットが大幅に超過していないか。 接続先スイッチにてPoE バジェットの状況を確認します。容量が超過している場合は、接続しているPoE デバイスの接続数を減らした時に事象に改善が見られるかご確認ください。 Meraki MS をご利用の場合は、dashboard 上にてご確認をいただくことが可能となります。   ダッシュボードパス：「ワイヤレス > アクセスポイント > “アラート対象のMR” > 予期しない低電力モード: 詳細確認 > Suggested actions > 1. Check PoE budget」   ダッシュボードパス：「スイッチ > スイッチ > “接続先スイッチ” > 電源 > 割り当て」 ※消費と割り当ての違いに関しては、ドキュメントをご参照ください。     - ケーブルテストを行い、物理ケーブルに問題が無いか。 ケーブルテストの結果に異常が見られる場合は、ケーブルを変更した後に事象に改善が見られるかご確認ください。 ※このテストを使用すると、10 Mbps または 100 Mbps リンク上のトラフィックが中断される可能性があります。ギガビット リンクには影響はありません。 Meraki MS をご利用の場合は、dashboard 上にてご確認をいただくことが可能となります。   ダッシュボードパス：「ワイヤレス > アクセスポイント > “アラート対象のMR” > 予期しない低電力モード: 詳細確認 > Suggested actions > 2. Cable test」     ダッシュボードパス：「スイッチ > スイッチ > “接続先スイッチ” > ポート > 対象ポート選択 > トラブルシューティング > ケーブルテスト」   正常な結果   異常な結果     - 対象スイッチポートの再起動を実施して改善が見られないか。また、対象スイッチポートでパケットキャプチャの取得を行い、LLDP パケットのネゴシエーションに失敗していないか。 ケーブル再起動と同時にパケットキャプチャの取得を行い、改善が見られるかご確認ください。 改善が見られない場合は、LLDP パケットのネゴシエーションに失敗が見られないかご確認ください。 正常なLLDP パケットのサンプルは、ドキュメントをご参照ください。 Meraki MS をご利用の場合は、dashboard 上にてご確認をいただくことが可能となります。   ダッシュボードパス：「ワイヤレス > アクセスポイント > “アラート対象のMR” > 予期しない低電力モード: 詳細確認 > Suggested actions > 3. Cycle port on switch」   ダッシュボードパス：「ワイヤレス > アクセスポイント > “アラート対象のMR” > 予期しない低電力モード: 詳細確認 > Suggested actions > 4. Packet capture」   ダッシュボードパス：「スイッチ > スイッチ > “接続先スイッチ” > ポート > 対象ポート選択 > トラブルシューティング > ポートの再起動/パケットキャプチャ」     - 802.3at/PoE+ 規格に準拠する前のスイッチ(Cisco Catalyst 2960,3560など)を利用している場合の注意事項 802.3at/PoE+規格に準拠する前のスイッチの一部は、デフォルトでは802.3at のフル出力をネゴシエートしません。 そのため、これらのスイッチ（Cisco Catalyst 2960,3560など）では、電源供給を行うスイッチポートを、手動で30W の電力が供給されるように設定する必要があります。 これは、スイッチのインターフェースに入り、次のコマンドを使用してインライン電力を30W に設定することで実行できます。 power inline consumption 30000   実際にMR に電源を投入する前に、この設定を行ってください。 この設定を行わない場合、低電力状態が続くことで、MR が継続的に再起動する原因となる場合があります。     - パッチパネルやJJ コネクタなど中継して接続しているのか、それともスイッチと直接接続となっているか。 パッチパネルやJJ コネクタなどを中継しない場合に場合に同様の事象が確認されるのか。 改善される場合は、中継デバイス側の問題や、ケーブルの長さなどに起因する問題と考えられます。 例えば、LAN ケーブル最大の長さは一般的に100メートルとされています。     - ケーブルの交換や接続ポートを変更した場合、改善は見られるか。 ケーブル接続先を変更した際に改善が見られる場合は、接続先ポートの問題の可能性があります。 その場合、他のデバイスを元の接続先に接続しても同様の動作が見られるか確認します。 他のデバイスでは見られない場合は、MR 本体のポートの問題の可能性があります。   接続先を変更しても改善しない場合、ケーブル自体の交換を実施して改善が見られるか確認します。 改善が見られる場合は、ケーブルやRJ-45 コネクタの問題の可能性があります。   - MR ならびにMS の再起動または初期化 一時的な問題によりネゴシエーションに失敗していたり、MR の内部プロセスに一時的な問題が発生している可能性もございます。 この点を切り分けるため、MR の「再起動」および「初期化」を実施いただき、事象が改善するかご確認ください。 「初期化」の方法につきましてはドキュメントをご参照ください。   切り分けを行っても原因箇所が不明、事象が改善しない場合 上記をご参考に全ての切り分けをご実施いただいても問題が解決しない場合、または何かご不明点がある場合は、お気軽にサポートまでお問い合わせください。 なお、その際はより効果的なサポートをご提供するため、実施済みの切り分け内容及びその結果をケースにてご共有いただけますと幸いです。   Cisco Meraki テクニカルサポート - Cisco Meraki Documentation https://documentation.meraki.com/General_Administration/Support/cisco_meraki_support_jp     追加のリソース Root Cause Analysis (RCA) - Alert Based Workflows - Cisco Meraki Documentation Low Power Mode - Cisco Meraki Documentation Low Power Mode on Cisco Switches - Cisco Meraki Documentation MR57 Installation Guide - Cisco Meraki Documentation Troubleshooting PoE on MS switches - Cisco Meraki Documentation ... View more

こちらの記事はテクニカルフォーラム上の投稿を翻訳したものです。 翻訳内容の矛盾が生じた際は原文の投稿の内容が優先します。   サポートセンターページ がリニューアルされ、2025年3月28日よりご利用いただけるようになります。 このアップデートにより、サポートケースの提出やネットワークの問題解決のプロセスを効率化する新しい機能が多数追加されます。   サポートセンターケースの作成方法 についての詳細は、こちらのドキュメントをご確認ください。   新機能 新しいカテゴリー：問題を簡単に分類できる新しい製品およびプラットフォームカテゴリー ガイド付きワークフロー：ケースをより迅速に作成するためのガイド付きケース作成ワークフロー デバイスサポート：新しい「関連」テーブルにより、製品/プラットフォームカテゴリー、デバイスモデル、ネットワークをフィルタリングして、お問い合わせ対象のデバイス、サービスを素早く特定できます。 深刻度レベル：直面している問題のビジネスへの影響に基づいて、深刻度レベル（深刻度1～4）を選択します。 サポートへの連絡方法: 選択した重要度に応じて、ご希望のサポート連絡方法を選択します。"Call Me Now" 、"Call in" 、Create a "Case" などがあります。   ※ "Call Me Now" オプションは、現在(2025/3/31)ベータ モードとなっております。現在、日本語は未対応です。   操作方法 Merakiダッシュボード から、「？」（右上、緑のリボン）> 「ヘルプ&Merakiサポートケース」に移動します。 サポートが必要な問題に関連する製品またはプラットフォームのタイルを選択します。 ケースに関連付けるデバイスを選択します。 問題が既存のケースに関連するものか、新規のものかを選択し、説明を入力します。新規のケースの場合は、ビジネスへの影響を最もよく表す深刻度レベルを選択します。 ご希望の連絡オプションを選択します（選択した深刻度に応じて利用可能）。 ケースを送信し、送信確認のサマリーとケースに割り当てた深刻度レベルを確認します。   確認メールが送信されます。または、"Call Me Now" を使用している場合は、Meraki support と電話がつながります。 ※ "Call Me Now" オプションは、現在(2025/3/31)ベータ モードとなっております。現在、日本語は未対応です。     利用可能 この機能は、2025年3月28日より世界中で利用可能になります。新しいサポートセンターの使用方法については、ドキュメントを参照してください。 ... View more

はじめに   MX では、任意の宛先に対して、ICMP のテスト結果に基づいた、Uplink Statistics(遅延、損失データ) を取得することが可能になります。 デフォルトでは、8.8.8.8 向けの宛先に対してのテストを行い、これらの統計情報の出力を行っております。 この機能を応用することで回線側の調査やMX に直接接続されたアップリンクの監視を行うために役立てることができます。 本記事では、こちらの機能の活用方法について記載しております。   Meraki では、直接接続されたアップリンクを監視するために、MX のデフォルト ゲートウェイをこちらのリストに含めることを推奨しております。     本機能における制限事項   制限事項 - VPN トンネル越しのプライベートアドレスを宛先にすることはできません。 - MX のWAN インターフェースから到達可能でなければなりません。 - 宛先デバイスがICMP トラフィックに応答しなければなりません。 - ホスト名/FQDN はサポートされていません。     ダッシュボードリンク   設定ページ - セキュリティ&SD-WAN > SD-WAN & トラフィックシェーピング > アップリンクの統計       確認ページ - セキュリティ&SD-WAN > アプライアンスステータス > アップリンク タブ > Merakiデバイスの履歴データ       デモンストレーション   前述の通りにMeraki では、直接接続されたアップリンクを監視するために、MX のデフォルト ゲートウェイをこちらのリストに含めることを推奨しております。   例えば、アップリンクに回線貸与のルーター が存在する場合、デフォルトの8.8.8.8 のみの監視の場合では、 回線側に問題があったのか、ネクストホップのルーター に問題があったのか判断がつかない場合があります。 このリストにデフォルトゲートウェイの宛先を含めることでこの判断における情報を得られる可能性が上がります。   デモでは、8.8.8.8 宛てとMX のデフォルトゲートウェイ宛てに対してテストを実施します。   以下の例では、8.8.8.8 宛ての統計では、100% のロスを報告しております。   一方で、この同じ時刻に、MX のデフォルト ゲートウェイ宛ての統計では、0% のロスを報告しております。   この結果から、アップリンクのルーターのWAN 側に問題が発生していた可能性があることが判断可能となります。 ※デモでは、アップリンクのルーターのWAN インターフェースを切断して100% を再現しております。   また、MX のInternet ポートでパケットキャプチャの取得を行うことでこの通信を確認することができますが、 宛先に対しては1秒に1発のICMP が送信されていることが確認できます。     応用   Auto VPN で頻発したダウン/アップ が報告される場合、特定の拠点間のグローバルIP に対して このテストを行いフラッピングする事象に対して監視を行うことができます。 テストの統計とEvent log からVPN のアップダウンを確認して比較することができます。 ※双方のグローバルIP がICMP に返信することが前提となります。     追加のリソース SD-WAN and Traffic Shaping - Cisco Meraki Documentation Meraki Auto VPN - Configuration and Troubleshooting - Cisco Meraki Documentation Auto VPN機能におけるVPNトンネル確立のトラブルシューティングについて - The Meraki Community ... View more