本記事では、MRがDynamic Frequency Selection（以下DFS）を検知した際、その確認・対応方法について解説しています。   // 概要 // MRは利用する環境によって、DFSイベントを検知する場合があります。 DFS自体は一般的にアクセスポイントに実装される機能及びその一連の動作の名称であり、設置場所で観測された軍事、気象、その他レーダー信号を検知し、干渉を防ぐために動的に自身のSSIDのチャネルを切り替えるものとなります。 日本においては特定5GHzチャネルであるW53（52ch～64ch）およびW56（100ch～144ch）が対象となりますが、MRがこのチャネル以外でSSIDをブロードキャストをしているような場合はDFS検知対象となりません。   ※上記はチャネル52にてレーダー信号を32回検知しDFSが発動した例、上記イベントログのリンクより詳細確認も可能。   DFS イベントは上述のように複数種類のレーダー信号がトリガーとなるため、MR設置周辺に関連施設がある場合や、水路や空港等の近くでは特に多く発生する可能性があります。 また確認可能な事項は検知情報のみであり、どういった種別のレーダー信号なのか等の詳細はわからないものとなります。   なお、比較的近い場所でMRを複数台を利用されている場合でも、設置場所や条件等により発生有無や頻度に差分が出る場合もあります。   // 事象による影響 // 上述動作でSSIDのチャネルが切り替わることにより、対象APに5GHzで接続されていた端末の無線が一時的に切断されユーザ通信に影響が出る場合があります。 また、この場合2.4GHzのSSIDには影響は出ません。   // MRの基本的な動作 // 検知時のMRの動作について詳細はこちらをご確認ください。 また、移行先のチャネルは基本的には対象MRが利用しているRFプロファイルの許可チャネルが参考にされ、これはチャネルを固定している場合においても同様となります。 例えば全チャネル許可のRFプロファイルを適用したMRが52chを80MHzでブロードキャストしている状況において、上記例のように52chでDFS検知があった場合、DFS検知に伴い100ch等に移行するような形になります。その後再度100chでDFS検知された場合、再度動的なチャネル切り替えの処理を繰り返していくような動作となります。また移行に伴いチャネルボンディングが縮退する場合もあります。   なお屋外用MRについては、法令の規制に基づきW52（36ch～48ch）およびW53（52ch～64ch）での利用自体が出来ないことから移行先は常にDFSの検知対象チャネルとなる形となります。    // 事象原因と回避方法// 検知自体はDFSの仕組みに基づいた正常動作となります。また、DFSは各国の法律に基づき実装義務となっているものであり、この機能自体を無効化することは出来ません。 しかしながら、上述の通り5GHzの特定チャネル（W53、W56）がDFSの発動前提となっているため、環境的な制約や要件がない場合は以下どちらかの対応によって事象発生回避が可能です。   ・手動で非DFSチャネルを選択 ・自動チャネル割り当てからDFSチャネルを除外（Meraki Auto RF: Wi-Fi Channel and Power Management）   この場合、利用可能なチャネルの数自体が少なくなるため、特に隣接AP間においては別チャネルを利用し電波干渉を防ぐような対応が必要となる場合があります。   // 検知アラートについて // 検知時のアラート表示は24時間程度表示される場合がありますが、再検知された場合はその分表示が延長されるような動作となります。 またこの表示を手動で削除することはできないものとなりますが、特に表示されていること自体に問題はありません。しかし、検知頻度が多い場合は上述の通り検知対象とならない設定の検討が必要となる場合があります。   //参考情報// Dynamic Frequency Selection (DFS) について ... View more

 // 概要 // 本記事ではMXのAuto VPN機能においてVPNトンネルの確立に問題が発生した場合の切り分け及び対応方法について解説しています。 VPNトンネルの確立後に発生する問題（VPN経由での通信不可事象や速度遅延、Auto VPN機能を前提とた各種SD-WAN関連機能における問題等）については、本記事の対象外としております。   VPNトンネルの確立において問題が発生する場合、通常”セキュリティ＆SD-WAM” > “VPNの状況”の画面において対向ピアとの接続が下記のように赤い状態となります。   またイベントログ上でも以下のように ピアのconnectivityがfalseに変化(復旧時にはtrue）した事が記録されます。   // Auto VPNについて// MerakiのAuto VPNはこちらの仕組みによって実現されますが、前提として各機器の情報（パブリックIPアドレス、UDPポート）がVPNレジストリに登録され各機器がそれを参照し、MXがNATの背後であってもUDP hole punchingの仕組みによりVPNの通信を実現しています。   各MXは機器起動時に自身が送信元に利用するUDPポートをランダムに採択し、これは再起動によって変化しますが上述の通り都度VPNレジストリを介して対向ピアに伝達されることで、再度VPNの通信が確立される仕組みとなります。上記利用ポートについては”セキュリティ＆SD-WAM” > “VPNの状況”  の画面にて確認が可能です。 上記例においてはVPNレジストリへの接続に問題がなく、またMXがNAT配下で動作しており、MX自身のWANのIPアドレスは192.168.10.254でUDPポートは43610を利用しています。 上位のNATにてグローバルIPアドレス（xxx.xxx.17.166）に変換されポートは同じものが送信元ポートとして利用されています。   この箇所にてunfriendly NATで表示される場合や、そもそもVPNレジストリの接続に問題が出ているような場合はこちらの手順にしたがって事象解消をする必要があります。なお、VPNレジストリへの接続に問題があってもそれが即座にVPNの通信自体に影響を及ぼすわけではありません。   // 影響範囲の考え方について// VPNトンネルの確立の問題においては、まずは事象発生タイミングがポイントの一つとなり以下のように整理します。   (1)新規の機器設置時（これまでに一度もVPNの通信が確立していない場合） この場合、 再度通信要件を見直し下記に対して上流環境で制御を実施していないかを確認します。または該当環境の上流がunfriendly NATとなっていないか等を確認します。 ・Ports used for IPsec tunneling: Source UDP port range 32768-61000 Destination UDP port range 32768-61000 (2) 機器運用時における発生 上記の通信要件に関わるような変更作業などが特になかった場合、問題がある区間においてのトラブルシューティングを行いますがこの場合事象が単一区間か複数区間で発生しているかを確認します。   ・単一区間 下記のような例の場合、事象は拠点AのSpokeだけで発生しておりその他の拠点については問題ないことから拠点A側の問題である可能性が高くなります。 HUB — 拠点AのSpoke ・複数区間 下記のような例で事象がすべての拠点で発生している場合、HUB側に事象発生要因がある可能性が高くなります。   HUB ┣拠点AのSpoke ┣拠点BのSpoke ┗拠点CのSpoke   以降に具体的な事象発生事例とそれぞれの確認・対応方法を記載します。 なお、事象がすでに解消している場合は事象発生時のパケットキャプチャ実施が実施できず原因特定が難しい場合もあります。    //  主な原因と問題切り分け方法 // 上記にて事象発生箇所を絞り込んだ場合、特に事象発生時にリアルタイムでのトラブルシューティングを実施する場合はまずは調査対象の事象発生区間の情報を整理します。 その後、事象発生時においてそれぞれのMXのインターネットポートにてこちらの手順でパケットキャプチャを実施し、双方向通信ができているかを確認します。 この場合、本事象においてはインターフェースにSite-to-Site VPNは利用せず、WANポートである「インターネット」を指定します。   以下の例では事象発生が複数区間である場合において、上述のような”HUBと拠点A間”での調査パターンを例にしており、各MX のパブリックIPアドレスと利用ポートは下記の通りです。 また、それぞれFriendly NATの背後にありVPNレジストリへの通信も問題がない事を前提としています。   HUB (3.3.3.3:35000 behind NAT) ——  拠点A間 (4.4.4.4:40000 behind NAT)   この場合に期待される通信としては、 HUBは4.4.4.4に対し宛先ポート40000（送信元ポートは自身の35000）でUDP通信をし、その逆方向で拠点AのMXは3.3.3.3に対して宛先ポート35000（送信元ポートは自身の40000）でUDPパケットを送信します。 そのため、問題がない場合は互いのMXのWAN側では必ず双方向通信が確認できますが、いずれかのMXで片方向通信となっている場合としては主に下記のような事項が考えられます。   (1)MXの上流（機器・ISP）の障害 この場合MX自体もオフラインとなる場合がありますが、すでに事象が解消しているような場合は対象MX画面の「デバイスの履歴データ 」より「接続不可」等となっている箇所がないか、または「アップリンク」画面の「デバイスの履歴データ」にて事象発生時間に高い損失がないか等の詳細確認が可能です。   例：5/16の10:49頃から8分程度MXが接続不可となっている場合   例：5/10の12:00前後にアップリンクにて最大26.5%の損失が出ている場合 ※この情報はインターネット上にある特定のIPアドレス(デフォルトではGoogle Public DNS(8.8.8.8))に対しての疎通確認であり、Meraki側サーバやデバイス動作との関連はありません。   (2)MX上流のNAT機器の問題 上記の問題がなく、また対向ピアがパケットキャプチャ上で正しいパブリックIPアドレスと宛先ポートに通信をしているにも関わらずそれが見えていないような場合、上流NAT機器が正常に動作しておらず配下のMXに必要な通信を届けられていないといったことが考えられます。   その場合、NAT機器のWAN側とMXと接続しているLAN側でパケットキャプチャをすることで詳細確認可能で、またはNAT機器再起動によって事象解消を試みることが可能です。   下記例のパケットキャプチャでは、NAT配下のHUB側（10.x.x.x）において対向ピア(xxx.xxx.165.2)からのUDPパケットが確認できず、下記のように自身の機器が対向ピアに送信している事だけが確認できます。   (3) UDP チェックサムにおける問題 互いのMXのWAN側で問題なく双方向通信となっていることが確認できた場合でも、UDP Checksum Errorsを原因とした（invalidもしくはbad UDP checksumが検知される等）ことでトンネルが確立できない問題が発生する場合があります。 この原因としては、主にMXの上流機器を経由することによってchecksumがinvalid になるようなケースです。   下記パケットキャプチャの例では対向ピアxxx.xxx.54.12からのUDPパケットのchecksumの箇所がBad checksumのErrorとなっています。   Wiresharkではパケットの詳細画面にて右クリック、“User Datagram Protocol” ＞ “Protocol Preferences”、“Validate UDP Checksum if Possible”にチェックを入れることで上記画面のようにわかりやすい形で確認可能です。   この場合、上位機器の再起動やファームウェアバージョンアップ等で解消しない場合は回避方法としては上流機器を介さない構成とするか、別の上位機器を利用することで改善を試みます。    // 参考情報 // Site-to-Site VPN Troubleshooting Meraki Auto VPN - Configuration and Troubleshooting ... View more

本記事では、Meraki機器がDHCPサーバとして利用されている環境において、端末からのDHCPのリクエストがRejectされる事でDHCPエラーとなっている事象と、その調査方法について解説しています。   ※1: MRもNATモードにおいてはDHCPサーバの役割を担いますが本記事では対象外となります。 ※2: 本記事ではDHCPのNegative ACKnowledgementはNAKまたはNACKと表記されます。 ※3: 本記事の内容ではMeraki機器がDHCPサーバとして稼働している前提ですが、他機器の場合でも発生する場合があります ※4: DHCP NAKは本記事に記載以外の要因や原因で発生する事もあり、その場合DHCPサーバ側の詳細ログ（Meraki機器以外の場合）等を含め詳細調査が必要となります。  // 概要 // 事象は主に無線接続環境で発生する場合が多く、DHCPエラーとしてダッシュボード上で確認できますが、MRの接続ログにおいて端末のリクエストに対し下記のようにdhcp_nackでrejectされるログ（Client made a request to the DHCP server, but the DHCP server rejected the client's request）が確認できます。     またエラー発生後、実際には端末がDHCPのリクエストを再実施し正しいIPアドレスを取得できる場合があり、ユーザ側では接続時に時間がかかっているといった状況になっていると想定されます。   この事象は特にDHCPプールにおける枯渇がしていない状況下でも発生しますが、通信経路で取得したパケットキャプチャでは端末がDHCP Requestを出した後に、Meraki機器側がDHCP NAKを返す様子が確認できます。 例：MXのLAN側で取得した例で#80でMXがDHCP NAKを返している     // 事象原因 // 本事象は対象環境や設定によって発生することがあり、主に以下のような環境で発生します。   ・MX（またはMS）をDHCPサーバとし、その配下にMRが接続されているような構成 ・ダッシュボード上でNetworkが複数あり、同じ設定のSSIDを利用しているような設定   （または同一ネットワーク内でも、こちらの設定で異なるフロア等に配置されたAPに対し、Tagで割当VLANを変えているような場合） ・端末が上記異なるネットワーク間（同じ建物内の別フロア、広い施設における別の場所・別館等）を物理的に移動するような環境   上記において、端末が移動元で保持してるIPアドレスを移動先の場所で利用する際にDHCP RequestすることでMX（またはMS）がそれをNAKでRejectする場合があります。こちらの挙動は端末の種別やOSにも依存し、Apple iOSデバイスにおける詳細についてはこちらのKBをご参照ください。   該当箇所： Before an Apple iOS device uses DHCP to obtain an IP address on a new network connection, it will first attempt to re-use the IP address configuration received from a previous networks DHCP server.   例：DHCP NAKの前に端末が#79で10.xx.xx.111でDHCP Requestをしている   上記NAKの理由としては以下のような場合が考えられますが、そのトリガーとしては上述の通り端末の挙動に依存します。   (1)端末が接続されたVLANとは異なるIPアドレスをRequestしている (2)端末からRequestされたIPアドレスが既に別の機器で利用されている　   上記1に関しては異なるNetwork間でSSIDに対し割り当たるIPアドレスレンジが異なる場合に発生しますが、IPアドレスレンジが同じであっても、2のような理由でNAKになる場合もあります。    // 事象対応方法 // 対応としては主に以下のようなものが考えられます。   1. クライアントの動作上やむをえず発生するエラーであるため、実影響を確認しダッシュボード上のエラー発生自体は許容する 2. ネットワーク構成、またはSSIDの変更    // 問題切り分け方法 // 該当DHCPエラーが確認できた場合、通常下記のような順序での確認で詳細が分かる場合があります。 1. エラーが発生した端末のMACアドレスが該当時間に移動をしていたか 建物図面やユーザへの確認を行います   2. 移動をしている場合、移動元及び移動先のNetworkでの接続履歴を時系列に確認 ネットワーク全体 ＞ イベントログ ＞ アクセスポイント向けの画面で、端末MACアドレスでフィルタし確認   3. 移動元のNetworkでリースされたIPアドレスを確認 イベントログ上でMXまたはMSの画面に切り替え、移動元のNeytworkでDHCPリース時のIPアドレスを確認   4. NAKの理由の調査 移動先のNetworkで同じIPアドレスレンジの場合、上記3のIPアドレスが別端末で既に利用されていないか、または端末の接続VLANが移動元と異なるIPアドレスレンジになっているか確認。   5. パケットキャプチャの取得 必要に応じて該当端末で移動し事象再現をさせている間に通信経路（APの有線やMXのLAN側）でパケットキャプチャを実施し端末がRequestしているIPアドレスやその後のNAKを確認します。   //参考情報// Configuring DHCP Services on the MX and MS DHCP Services VLAN Tagging on MR Access Points IP Conflict Events Triggered by iOS Devices ... View more

// 概要 // 本資料では、ケースオープン後の調査を経て、想定（期待）されない事象・動作であることが認定された際に、その後のケースの扱いについて説明しております。   こちらの資料に記載の通り、想定されない動作と判定された後に修正の対応となりますが、対応には優先度が大きく関わっており優先度が低い場合においては対応まで長く時間がかかる場合があります。   まずは優先度がどのように定められるかについて下記に概要を記載します。   // 対応優先度の考え方について // ケースオープン後に想定されない事象であると認定された場合、その後は優先度に応じた対応となりますがこの優先度は様々な要因によって決定され主に下記に分類されます。   　 - ワークアラウンドの有無 　　設定変更、再起動での回避の可否   　 - 事象の特性と影響 　　事象特性（表示上だけの表層的な事象、または通信影響等が発生するか等）、及びビジネスインパクトの有無等の影響度合い   　 - 事象規模 　　グローバルでの事象報告数、特定環境・設定等に依存する問題であるか   // 障害となった場合について // 想定されない動作により障害となっている場合、通常高優先度での対応となりますが日本語での詳細情報については対応ステータスを含めこちらのリンクにて公開される場合がございます。   // 修正・改善に要する期間の考え方 // 修正までに要する期間は実際の修正自体の容易性によっても変わりますが、それ以前に対応優先度が大きく関わってきます。 弊社内部での優先度の区分けは数段階に分かれておりますが、障害等を含め上述要因に複数該当しているような場合は最高優先度での対応となり、この場合は他優先度の事項と比較し早急に対応がなされます。   ※ すべての上記事項に当てはまったとして、必ずしも最高優先度となるわけではありません。   また期待されない動作による障害となった場合、対応ステータスを含め日本語での詳細情報についてはこちらのリンクにて公開される場合がございます。   上記以外の低い優先度となった場合は、順次対応される形になります。   // なぜ低い優先度の場合に時間がかかるのか // 想定されない事象はグローバルで日々数多くの報告が上がりますが、事象が判定された後に即座に修正されるわけではなく優先度に応じ順次対応がなされます。   これは単純な順番通りで対応がなされるというわけではなく、日々報告される他事象の報告状況に連動しダイナミックに変化するものであるため、修正までの期間を一概に明示することができません。 また優先度自体も状況に合わせ定期的に見直される場合があります。   // ケース上での報告と扱いについて // 上述理由で優先度の低い事象については予め対応時期を出す事ができないため、ケース上での状況報告は何かアップデートがあった場合のみとさせていただいております。   また上述の通り、多くの場合は修正時期を見込むこと自体が難しいため報告の頻度自体も非常に少なくなる場合もございます。 特に既知事象に該当している事象などで、“最低でも数ヶ月は進捗が無い見込み”となるケースもあることから、弊社内でのオープンケース増大に伴う各お客様への対応効率悪化の観点より一度ケースクローズをお願いさせて頂く場合があります。   もし進捗確認が必要であれば時間をおいて、元ケース番号の情報と共に新規にケースオープンをお願いできますと誠に幸いです。   // 事象による業務影響が出ている場合について // 対応優先度は上記のような理由で決定されるもの、もし実際に事象による業務影響やビジネスインパクトが大きくなっている場合、優先度をあげるために弊社営業を通したエスカレーションのプロセスについて相談させていただく場合がございます。 詳細についてはこちらのリンクをご参照ください。   // 参考情報 // サポート対応に関するよくあるご質問と回答(FAQ) ... View more

// 概要 // 本資料ではMeraki製品を利用の際に、想定（期待）されない挙動や動作が確認された場合の対応について解説しています。   想定されない挙動が確認された場合、ケースオープン後にサポートを窓口とし弊社内部で事象に対する正確な把握と判定が行われます。以降、修正・改善対応が実施されますが、その全体の流れ及び概要について以下に記述しています。 実際に弊社内部でどのような処理がされているかの概要把握のためにご参考ください。   // 修正・改善対応が行われるケースについて // Meraki機器はクラウド管理製品である特性上、製品として動作する上で様々なコンポーネントが関わっており、 具体的には下記のような事項に分類されます。   機器自体（ファームウェア・ハードウェア） ダッシュボード 制御、認証、設定等に関わるバックエンドの機構 ※ 固有機器のハードウェア不良と判定された場合は解決のためRMA（詳細はこちら）での対応となる場合がございます。   想定されない動作自体は上記それぞれの箇所で生じ得ますが、 事象によってその影響対象は、利用ユーザ及びMeraki管理者どちらにもなる可能性があります。 そのため、事象としてはユーザ端末のインターネットへの接続性の問題等といった場合から、 管理者がダッシュボード上で操作する事項についての問題となる場合もあります。   // 障害となった場合について // 想定されない動作により障害となっている場合、通常高優先度での対応となりますが 日本語での詳細情報については対応ステータスを含めこちらのリンクにて公開される場合がございます。   // 修正・改善対応までの一般的な流れ // サポートケースオープン後、通常切り分けを含め詳細調査を経た上で原因箇所の特定が行われますが、 その後の原因箇所への修正・改善対応を含め、全体としては下記のような流れで実施されます。   ケースオープン サポート側での事象の確認 事象の切り分け（別機器での発生有無、機器再起動、ファームウェアバージョンアップ等） 事象が仕様によるものであるかの確認 既知の類似事例有無の確認 既知事例がない場合、ラボ環境等での事象再現テスト 詳細調査に必要な情報の取得（詳細はこちら） 取得情報を元にサポートから開発部門への確認 開発側で期待されない動作であることの認定、及び優先度決定 優先度に応じ修正の対応（必要に応じサポートからケース上でお客様への追加事項を確認） 修正完了、及びお客様側での改善確認 ケースクローズ   ※ 上記プロセスは順番の前後・一部箇所がスキップされる場合があります ※ 切り分けや詳細調査においてリアルタイムのトラブルシュートを要する場合があります   // 切り分けについて // 初期段階での事象の切り分けは全体の調査スピードにおいて非常に重要で、 再起動や初期化による改善確認は主に機器の一時的な状態（メモリ・CPU・ディスク状況、各機能・プロセスの処理状況、設定等）に よるものかの判断のために必要となります。   ※ 再起動時に機器内部のログが消失するため、事前にログ取得が必要な場合があります   また、ファームウェアバージョン変更による切り分け確認も重要となりますが、 これは各Meraki製品では日々新しいファームウェアがリリースされており、 各既知の事象に対する修正だけではなく、パフォーマンスの改善およびセキュリティの対応等も含まれているためです。   切り分けが実施出来ない場合、必要以上に調査に時間を費やすだけではなく、 原因箇所の絞り込みが出来ないことで事象の原因究明のための調査に進めない場合もございます。   // 参考情報 // サポート対応に関するよくあるご質問と回答(FAQ) トラブルシューティングにおける情報取得について ... View more

本記事では、MXのポートフォワーディング機能を利用した際に、想定通り動作しない場合の切り分け手順について解説しています。   // 概要 // MXのポートフォワーディング機能はインターネットからWANポートに着信した通信を LAN配下（※1）の特定IPアドレスにフォワードする機能で、これによって社内のデバイスやサーバを インターネット上に公開することが可能です。   設定後、実際にアクセスをしても通信が出来ないという場合に下記に記載の事項を確認することで 問題の切り分けが可能です。   ※1：MXで設定したサブネットが対象となります。またAuto VPNでの対向ピアのサブネットなども指定できません。   // 設定方法 // 設定は下記画面で実施します。   セキュリティ＆SD-WAN ＞ ファイアウォール ＞ 転送ルール     上記例ではMXの両方のWANポートに着信したTCP/8080のパケットを、 MX配下の192.168.100.10にTCP/80でフォワードする設定となります。   // 問題切り分け方法 //   通常下記のような順序での切り分けが有効となります。 1. インターネット側の任意の環境から、対象のポートで通信を実施 上述の例の場合、ブラウザで確認可能な通信であれば「http://xxx.xxx.xxx.xxx:8080」等で、 またはtelnet等のコマンドでポートを指定し確認（xxx.xxx.xxx.xxxはグローバルIPアドレス）します。   ・Mac OSの端末での実施の場合 telnet xxx.xxx.xxx.xxx 8080   2. MXのWANポートでパケットキャプチャをし該当通信の着信確認 下記画面でMXとインターネットポートを指定します。 ネットワーク全体 ＞ パケットキャプチャ   該当通信が来ていない場合、MXの上流環境を確認し上位のルータ等がある環境であれば該当通信を 上流側でポートフォワーディングしてMXに向けているか、またフィルター等をしていないか確認。   また通信元の端末が、MXの設定で許可された送信元IPアドレスであるかを確認します。   3. MXのLANポートでフォワードして対象機器からの応答があるかを確認 上記のパケットキャプチャの画面でLANポートを選択し、該当通信を変換後のポートで 指定されたIPアドレスに送信しているか、また対象機器からの応答を確認します。 機器からの応答がない、TCPの再送処理等が発生している場合などの際は 対象デバイス自体が被疑箇所である可能性があるため下記確認に進みます。   4. 対象機器のサービス稼働状況、Firewall等での制御状況   下記のような事項を確認し機器側の状態を確認します。 ・対象サーバ、デバイスで問題なくサービスが起動しているか ・LAN内からはアクセス可能であるか ・Firewall等で指定したIPレンジからしか許可しないような設定になっていないか   //参考情報// Port Forwarding and NAT Rules on the MX Troubleshooting Port Forwarding and NAT Rules Port Forwarding Caveats   ... View more

// 概要 // Meraki機器において想定しない挙動や動作が確認された場合、事象原因の詳細調査にあたっていくつか確認依頼をさせていただく場合があります。 本資料ではその理由、及び取得が必要な情報についてまとめております。   // ユーザ側での情報取得が必要な理由 // Meraki機器の性質上、機器がオンラインになっている場合にはMerakiサポート側にてクラウド経由での詳細なログ取得や、各機器でのパケットキャプチャの実施が可能です。 しかしながら、事象によっては上記情報のみでの解析が難しい場合があり、ユーザ側の情報取得を進める事で初めて調査を進められるようなケースがあります。   一例として、機器が実際に利用されている環境でしか取得出来ない情報があり、これには端末や上位機器でのパケットキャプチャ等があります。 これら情報は事象の根本原因がMeraki機器以外の箇所にあることの特定だけではなく、Meraki機器が想定通り動作していないことの確認のためにも利用されます。   またMerakiサポート側でのクラウド経由での情報確認のための前提が各機器がオンラインとなっていることであるため、 機器自体がオフラインになるような事象等に関しては、調査にあたってOut-of-Band Log Fetching（オフライン時のログ取得）が必要となる場合があります。   // 調査に必要となる主な情報について// 以下、事象発生における詳細状況や環境の確認が実施済みの前提となります。   また、もし既に事象が機器交換で改善している場合、弊社側の確認のため 一度オフラインにした機器を再度オンラインにしていただく場合がございます。   ・事象の再現実施と、発生環境（対象クライアントのMACアドレス/IPアドレス、事象発生機器のシリアル番号等）情報   ・事象再現時におけるパケットキャプチャ（有線（各通信経路）、モニターモードによる無線空間、クライアント端末等）   ・事象再現時の、端末側での各操作やコマンド実施とその実施結果   ・Meraki以外の機器での確認結果（例：事象発生時のRadiusサーバでのログ、端末側のログ情報）等   ・その他、事象に関連する各設定等の情報 ※対象事象に応じて上記以外の情報が必要となる場合もあります。 // その他ログに関しての事項 //   ・機器再起動に伴うログの喪失について Meraki機器のログにはいくつか種類があり、通常の機器の挙動のログは機器がオンラインになっている間に クラウドに送信されダッシュボード上でイベントログ等で確認可能です。 （syslogサーバにログを転送している場合等も同様の考え方となります）   上記以外にも、機器正常性を記録するものや各機能における詳細履歴など、機器側にのみしか保存されないものもあり、 これらは弊社側でクラウド経由、もしくはOut-of-Band Logでのみ確認が可能です。   注意点としては機器の再起動によってこれらは一度リセットされるため、 確認のためには事象を再現させその状態にて確認する必要があります。   // 参考情報 // Case作成時に必要な情報（問診票） オフライン時のログ取得 クライアントマシンで無線空間のパケットキャプチャを取得する 無線パケットキャプチャについて ... View more

本記事では、クライアント端末でAndroid12を利用している場合における、MXでのクライアントVPN利用の注意点について解説いたします。   // 概要 // Android 12ではL2TP/IPsecの設定自体が廃止されたことに伴い、MXへのクライアントVPNの接続設定が実施できなくなっています。   ※Android OSをアップグレードする前に既にL2TP/IPsecのプロファイルを登録していた場合においては、継続して接続可能との事です。   // 対応方法 // OSの機能ではなく、CiscoのAny Connectやそれ以外のL2TP/IPsecに対応したサードパーティ製のVPN接続アプリケーションを利用し接続を行う必要があります。 //参考情報// クライアントVPNのOS設定 AnyConnect on the MX Appliance ... View more

本記事では、System ManagerのDEP端末の管理画面でASMサーバとの同期できないエラーが表示される問題とその対処方法について解説いたします。   // 概要 // System ManagerでDEP端末の管理画面（System Manager > DEP）を表示した際、下記のようにASMサーバもしくはBSMサーバとの同期が出来ない旨のメッセージが出る場合があります。   ※該当エラーが「Apple Device Enrollment Program Sync failed: Server token rejected by Apple.」等と表示される場合もあります。   // 問題 // これは、通常Apple 側のサーバとMeraki ダッシュボードで保持しているDEP のTokenが異なっている、 または証明書の期限が切れている場合などに発生しますが、なんらかの証明書の問題によってうまく同期できない状態となる場合もございます。   // 対応方法 // DEPのTokenの更新によって事象が改善される場合があります。 詳細手順は以下の「Renewing a DEP Token」をご参照ください。 https://documentation.meraki.com/SM/Device_Enrollment/Apple_Device_Enrollment_Program_(DEP)   ... View more

本記事では、System ManagerでDEP(現ADE)端末を登録する際、プロファイルを割当後にAssignedから変化しないという事象についてその対応方法をご説明します。   // 概要 // System Managerで新規及び機器交換などでデバイスをDEP(現ADE)端末として登録する場合、まずASMに登録された端末情報がダッシュボードにSyncされ、反映されたEmptyのデバイスに対しプロファイルを適用する形になります。   // 問題 // この際に、プロファイル適用後に登録ステータスがAssignedで止まってしまいPushedに変化しないというお問い合わせがよく発生します。     // 対応方法 // これはDEP(現ADE)の登録処理がデバイス設定段階（setup assistant）で実施されることによるものであるため、デバイスの初期設定を実施するか、もしくは既に利用状態となっている機器であればファクトリーリセットを実施する必要があります。   iPhone、iPadなどのファクトリーリセットに関しては、「すべての設定を消去」ではsetup assistantが開始されないため、下記のように実施する必要があります。 ホーム画面から、「設定」＞「一般」＞「リセット」＞「すべてのコンテンツと設定を消去」から初期化を実施。     その後、setup assistantの中でProfileをインストールし、問題なく完了した場合はダッシュボードの表示もPushedとなります。 //参考情報// Apple Device Enrollment Program (ADE)   ... View more

本記事ではMeraki機器オフライン時の切り分け方法について、影響範囲やそれぞれの状況からフローを用いて実施する方法をご案内します。   ※フロー上に該当しないパターンなどが発生する可能性もあり、ケースオープン時にはどこまで切り分けを実施 したかの情報を記載いただくと、その後調査を円滑に実施することが可能となります。   // 概要 // Meraki機器は通常クラウドに対し定期的に通信をしていますが、その用途は設定ダウンロード、統計情報の送信、モニタリング、ファームウェアのダウンロード等、多岐に渡ります。またこの通信は通常は特にユーザ操作に関わるものではありません。   この通信が何らかの原因によってクラウド側から確認できない場合、オフライン状態となります。   (オフライン時のメッセージの一例)   // 切り分けの考え方 //   上記原因は大きく分けて以下の３つに分類されます。   1)機器要因 ハードウェアの不具合、プロセスなどのソフトウェア側の問題等 2)環境要因 利用回線/ISP等の問題、Firewall等による遮断、電源喪失等   3)クラウド要因 クラウド側の障害、メンテナンス等による影響   これらは、オフラインの事象発生タイミングや影響範囲などから上記のいずれかに絞り込みが可能で、さらに詳細な原因特定へとすすめる事が可能です。   特に影響範囲は重要で、特定機器のみで発生している場合は主に機器側に問題があり、複数もしくはネットワーク内の全台で発生している場合は環境やクラウドに起因した問題である可能性が高くなります。   // 切り分けフロー// 本記事では以下のフローを以下の２パターンに分けており、それぞれの状況に応じてご確認ください。 ※各ファイルはダウンロードしてご確認ください。   ■事象発生が一台のみの場合 　（場合によっては複数機器で発生することもあります） ■事象発生が複数台もしくは全台の場合       //参考情報// Upstream Firewall Rules for Cloud Connectivity Using the Cisco Meraki Device Local Status Page Common Dashboard Alerts for Device Connectivity   ... View more