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