Meraki Auto VPNとNon-Meraki VPNの併用について Meraki Auto VPNとNon-Meraki VPNを併用は可能です。 それらの併用は可能ですが、冗長構成を構築することは苦手な側面があります。 MXの仕様によりどのような通信が可能なのか、不可能なのか、 混乱することがありますので、代表的な例を交えてコミュニティ記事としてまとめます。   この記事での前提構成 Full Mesh構成のMeraki Auto VPNがA,B,Cの３拠点で構成されており、同時にNon-Meraki VPNでNon-Meraki VPN peer拠点と接続した構成を想定しています。また、IPv4デフォルトルートは構成していないものとします。 以下に3つのパターンに分けて動作を説明します。   パターン1 Non-Meraki Peerと接続を許可された拠点はAのみの場合。 サポートケースとしても最も多い問い合わせの一つです。許可されたA拠点はNon-Meraki Peerと通信が可能ですが、そのほかの拠点は通信ができません。 理由としては、A拠点がNon-Meraki VPN peerへのスタティックルートを他のB,C拠点に再配送しないためです。 Meraki Auto VPNは自身のLANサブネット以外のルートについては再配送しません。       パターン2 NonMeraki Peerと接続を許可された拠点は全てであり、C拠点がMeraki Auto VPNの接続を全て失った場合。 MXがHUBとして動作している場合、A,B拠点への接続を失ったとしてもそれらをトラッキングしておらず同じルートを保持し続けます。 そのため、同じルートにパケットを送信し続けることになり、仮にNon-Meraki peerがルーティング機能を持っていたとしても、それを介しての通信はできません。     パターン3 NonMeraki Peerと接続を許可された拠点は全てであり、C拠点がNon-Meraki peerとの接続を失った場合。 パターンAを踏まえると、これは不可能な通信であることが分かります。 こちらも同様にHUB拠点はNon-Meraki VPN peerへのスタティックルートを他の拠点に再配送しないため、A,B拠点を経由して通信はできません。       関連するドキュメント Meraki Auto VPN の一般的なベスト プラクティス - Cisco Meraki ドキュメント https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MX_Security_and_SD-WAN/Meraki_Auto_VPN_General_Best_Practices#VPN_Mesh   Site-to-Site VPN Settings - Cisco Meraki Documentation https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings ... View more

    利用できるファームウェアがMX17.x以上になります コンテンツフィルタリングは2024年の末から、MX17.x以上のファームウェアバージョンでのみ利用可能な機能となります。 なぜ、MX17.x以上に限定されるのか、またコンテンツフィルタリングとはどのような機能なのかについて下記にて簡潔に説明します。     コンテンツフィルタリングとは MX Advanced security ライセンスで利用可能になる機能です。 コンテンツ フィルタリングを使用すると、ユーザーが適時構成したポリシーに基づいて、クライアントからのHTTP および HTTPS のClient Hello packetから、特定のカテゴリのWebサイトをブロックできるようになります。   例えば、ゲームに関連するWebサイトにアクセスできないようにしたい場合には、ゲームカテゴリをポリシーに選択することで、 ゲームに関連するWebサイトの閲覧をしようとしたユーザーは、アクセスをブロックされ閲覧できなくなります。 また、カテゴリに分類されないWebサイトについても、特定のURLをブロックまたは許可リストに登録することで制御を行うことができます。     コンテンツフィルタリングの仕組み MX のコンテンツ フィルタリング機能は、Cisco Talos によって分類された Web コンテンツと脅威カテゴリに基づいて URL を分類します。 クライアントからのHTTP および HTTPS のClient Hello packetをCisco Talosに送信し、ポリシーのカテゴリリストにマッチするかどうかを照合し、クライアントに対して応答を返すという仕組みです。 HTTPとHTTPSでフローが若干異なりますが、いずれもClient Hello packetをトリガーに動作する機能であります。 また、コンテンツフィルタが動作した際のユーザー側でのブラウザの見え方が異なります。   HTTPの場合はブロックページへリダイレクトされMerakiのブロックページが表示されますが、HTTPSの場合はブロックページにリダイレクトしないため、ブラウザのデフォルトのアクセス失敗ページが表示されます。 Cisco Talos によるコンテンツ フィルタリング - Cisco Meraki ドキュメント https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Content_Filtering_Powered_By_Cisco_Talos HTTPでの例↓     サポートされるファームウェアバージョン MX17+ 2024年の末からBright Cloudとの連携が終了し、Cisco Talos Intelligence に一本化されます。 これに伴い、Bright Cloudとのカテゴリインテリジェンスソースを利用するMX17.xより以前のファームウェアバージョンでは、Cisco Talos intelligenceをサポートしていないため、自ずとコンテンツフィルタリング機能のサポートが終了になります。 上記のため、MX セキュリティ アプライアンスは、ファームウェア MX17.x以降で動作している必要があります。   今後は、MX のコンテンツ フィルタリング機能はCisco Talosによって分類された、Web コンテンツと脅威カテゴリのみ基づいて分類されます。      ファームウェア制限にかかった場合の挙動 コンテンツフィルタリング機能は動作しません。     ファームウェアバージョンのアップグレードの方法 ファームウェア アップグレードのスケジュールのマニュアルについては下記のドキュメントをご参照ください。 Managing Firmware Upgrades - Cisco Meraki Documentation https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Managing_Firmware_Upgrades     ファームウェアEOL 最新安定版ファームウェア以外を、Vintage Firmwareの位置付けとなり、最新の安定版ファームウェア以外で仕様変更のために修正パッチが入ることはないため、コンテンツフィルタリングを利用したい場合にはMX17.x以上のファームウェアにアップデートをいただくしかない状況となります。 ただし、セキュリティに関する重大な脆弱性に関する修正対応は Vintage Firmware に対しても提供されます。 Cisco Meraki ファームウェアの EOL ポリシーに関するよくある質問 - Cisco Meraki Documentation https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Cisco_Meraki_Firmware_EOL_Policy_FAQ_jp     製品別のファームウェア制限について レガシーMXについては、そもそもMX17.x以上のファームウェアにアップデートできないものがあります。 モデルによって実行可能な最大ファームウェアバージョンが設けられておりますので、 ご利用のMXがレガシーMXに該当しないかどうか、ご確認をください。 製品別のファームウェア制限 - Cisco Meraki Documentation https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Product_Firmware_Version_Restrictions_jp     関連するドキュメント Content Filtering - Cisco Meraki Documentation https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Content_Filtering Content Filtering Powered By Cisco Talos - Cisco Meraki Documentation https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Content_Filtering_Powered_By_Cisco_Talos BrightCloud Content Filtering Deprecation FAQ - Cisco Meraki Documentation https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/BrightCloud_Content_Filtering_Deprecation_FAQ ... View more

      MXの冗長構成について MXはVRRPプロトコルを使用して高可用性（HA）ペアを構成することができます。 セットアップする方法については下記のドキュメントにマニュアルがございますのでご参照いただけますと幸いです。 こちらのコミュニティ記事では、HAペア構成時に予測される間違った構成や、その動作について説明します。   冗長構成に最低限必要なもの ・スイッチ1台 ・MXのライセンス1個 ・同じモデルのMX2台 ・LANケーブル   MXのVRRPの仕様   HA 構成の MX ペアは、VRRP アドバタイズメントを使用して、現在のアクティブ MX の状態を監視します。 動作状態では、アクティブ MX は 1 秒ごとに VRRP アドバタイズメントを すべてのVLANから送信しており、パッシブ MX が 3 秒間アドバタイズメントを受信しない場合（すべてのVLANでVRRPのハートビートを3発ロストした場合）、アクティブ MX に障害が発生したとみなし、パッシブMXは新しいアクティブ MX として引き継ぎます。     注意！構成上で抑えておかなければならないポイントについて   MX同士は直接接続してはいけません 上記のVRRPの仕様から、なぜ直接接続してはいけないのかを紐解いていきます。   簡単な構成例で説明します。 MXはすべてのVLANでVRRPのハートビートを送信しているため、例えば専用のアクセスポートかつ専用のVLANを作成して直接接続をした状態としますと、このハートビートを直接交換することになります。 一見問題ないように見受けられますが、パッシブMXがアクティブになる条件は、すべてのVLANからハートビートを受信しなくなった段階であることを考えると落とし穴があることに気が付きます。 プライマリが故障などでダウンした場合にはこの構成でも機能します。 しかし、プライマリとスイッチを繋ぐLANケーブルやポートでなんらかの障害が発生した場合、直接接続されたケーブルでVRRPのハートビートが到達しているため、セカンダリMXはパッシブを維持してしまい、いつまで経ってもフェイルオーバーしなくなります。 その間、secondaryMXはARP応答を返さないため、クライアントのゲートウェイはprimaryMXを向いたままとなります。     複数スイッチでの構成例 MXの配下に複数スイッチを設置する場合にはスパニングツリープロトコル(STP)を考慮する必要があります。 公式のドキュメントには接続ポートに関する記載はありませんが、primary MXへの接続ポートは若番を接続し、 secondary MXへの接続ポートは老番を接続する必要があります。 下記にて構成例を示します。   なぜ、接続ポートに注意しなければならないのかを下記にて説明します。   ・ベストプラクティスの構成の例 STPにより右側スイッチのポート2,3がブロッキングポートとなり、primary MXとは直接接続での通信となります。 ※Meraki としては、効率的な構成であるMXとMSは直接接続で使用いただくことを推奨としております。 この構成で障害時の動作 ・primary MXが障害によりダウンした場合 右側スイッチのport2がブロッキングポートから復旧し、secondary MXと直接接続での通信ができるようになります。 ・primary MXとの接続ケーブル、ポートが障害が発生した場合 Root bridgeのport1がダウンした場合、右側スイッチがRoot bridgeとなりport3がブロッキングポートから復旧し通信を継続できます。 右側スイッチのport1がダウンした場合でも、port3がブロッキングポートから復旧し通信を継続できます。   ・ベストプラクティスではない構成の例 MXとMSが直接接続はされていますが、そのポートはブロッキングポートとなり、右側スイッチはRoot bridgeを介してMXに到達することとなります。 同様の構成のスイッチが増えますと、その数だけ数珠繋ぎの状態となり遠回りする形で通信を行うことになります。   また、2台程度であればL2のトラフィックであるため、これによる影響は軽微であるものと存じますが、これが増えて来た場合にはRoot bridgeに無駄な負荷がかかることになります。 さらに、例にあげた構成であれば障害時の冗長こそ取れるものと存じますのが、万が一ルート ポートがセカンダリ（パッシブMX）に接続されてしまった場合にはトラフィックは転送されなくなってしまいますので、ポートアサインは、上記のベストプラクティスに準拠いただくことを推奨しております。   MXに接続できるL2スイッチの上限 2台以上のL2スイッチを接続する場合には、3台目以降のL2スイッチのブロードキャストドメインを区切る必要があるため、 実質、複数スイッチかつトランクポートでの構成はL2スイッチは2台までが限度となります。 L2スイッチを3台以上導入する環境においては、L3スイッチを間に挟みMX単体のドメインに分けるか、L2スイッチ配下に接続する構成を取る必要があります。     関連するドキュメント   MX Warm Spare - 高可用性ペア - Cisco Meraki Documentation https://documentation.meraki.com/%E6%97%A5%E6%9C%AC%E8%AA%9E/Security_and_SD-WAN/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair   MX レイヤー 2 機能 - Cisco Meraki ドキュメント https://documentation.meraki.com/MX/Networks_and_Routing/MX_Layer_2_Functionality#Spanning_Tree_Protocol_(STP       ... View more

セーフコンフィグ「安全な設定(Safe Configuration)」について   Meraki デバイスにはセーフコンフィグ「安全な設定(Safe Configuration)」の概念があります。 ※以降セーフコンフィグと呼称 これはMeraki デバイスが安定的に接続できている、実績のあるコンフィグをMerakiデバイス内部に保存され、 以降、このセーフコンフィグがデフォルトの構成として利用されます。 こちらの記事は、Meraki ノード上に存在するセーフコンフィグについて理解を深めることを目的としております。     セーフコンフィグの概要   ダッシュボード上で変更された設定内容はダッシュボードに同期したタイミングでデバイス上にダウンロードされ、保持されるものとなります。 このとき、変更された設定をダウンロードした後、30分間再起動が行われなかった場合に対象の設定はセーフコンフィグとしてマークされ、次回再起動後にこの設定ファイルを読み込む動作となります。 ※この時点で、セーフコンフィグとランニングコンフィングは同じものとなります。 一方、変更後30分以内に再起動が発生した場合、最後に同期された設定は上記のセーフコンフィグとしてマークされないため、 次回再起動後は最後にセーフコンフィグとしてマークされた設定内容を読み込み起動するものとなります。 　 よくあるパターンとして、導入前のキッティングなどで上記のセーフコンフィグとしてマークされていない状態で、デバイス再起動やオフラインとしてしまい、設定内容がキッティング前に巻き戻ってしまうなどです。 ※セーフコンフィグが一つもない場合は工場出荷状態のものを使用します ※事例については後ほどの「よくある失敗事例」をご参考にください。 セーフコンフィグで起動した場合でも、デバイスがダッシュボードに同期したタイミングで、ダッシュボード上の最新のコンフィグがダウンロードされ、読み込まれるものとなります。 こちらについて、再起動後の同期まで10分〜1時間ほどかかる場合がございます。 お急ぎの場合、他の箇所の設定変更を行うことで最新の状態が反映される場合がございますが、 多くの場合自動的にダッシュボードの最新の状態を反映していくものとなります。     セーフコンフィグに保存されるまでの時間は？ 安定的な接続の実績としてサポートより1時間や2時間、4時間など回答に差がある場合があります。   これはモデルによってセーフコンフィグになるまでの時間が異なるほか、デバイスがダッシュボードに同期したタイミングで、ダッシュボード上の"最新の設定がデバイスに読み込まれて"から、タイマーがスタートするためです。 そしてタイマーがスタートした後で行われる、"次回"の設定の同期時にセーフコンフィグとして保存されます。   上記により、セーフコンフィグに保存されるまでに、30分以上の時間がかかることが想定されます。   そのため、確実にセーフコンフィグに保存されるように、安全をみて1時間〜4時間とサポートから案内を行う場合もあります。   公式のドキュメントには30分と記載があるが。。。 公式のドキュメントでは、下記のように記載がありますが、これは説明としては不十分な内容ではありますので、確実にセーフコンフィグとして構成したい場合には上記を参考にホールドタイムを確保いただけますと幸いでございます。 Note: 安全な構成とは 、「デバイスがクラウドに接続されており、構成変更後 30 分間再起動されていない」ことを意味します。つまり、安全な構成とは、デバイスがクラウドから受信した最後の構成であり、その後 30 分以内に再起動されていません。            新しいコンフィグが反映されない Meraki デバイスはセーフコンフィグを使用しており、構成の変更によってデバイスがオフラインになったり再起動したりした場合に、最後の正常な構成ファイルとして、セーフコンフィグに戻る動作を取ります。 ※一連の動作をコンフィグの検証とされています   この時、ダッシュボードからダウンロードした新しいコンフィグに「問題」があると判断された新しいコンフィグはバットコンフィグとみなされます。 バットコンフィグでは、ランニングコンフィグおよびセーフコンフィグになれません。 この時、ダッシュボード上の設定ステータスはOut of date (reverted to safe config) になります。     セーフコンフィグが消えることはあるの？ 工場出荷時設定にリセット（初期化）すると前述の構成ファイルがすべて削除され、プロセスが新規として開始されます。 これ以外ではセーフコンフィグが削除されることはありません。     よくある失敗事例 以下、工場出荷状態からのダッシュボードを使ったキッティングを想定 検証環境と現場環境のサブネットが違うことを想定   １、事前キッティングの際に、ダッシュボード上で構成しオンラインとせずに実装した 　→デバイスには設定はダウンロードされていないため、初期状態で起動します。   ２、事前キッティングの際に、オンラインとしたが、セーフコンフィグに保存される前にオフラインとした 　→セーフコンフィグがないため、初期状態で起動します。   ３、事前キッティングの際に、検証環境の構成でオンラインを維持しセーフコンフィグに保存、出荷前に現場環境の構成に変更しホールドタイムを設けずオフラインにした 　→セーフコンフィグには検証環境の構成となり、現場環境では検証環境の構成で起動します。   ４、事前キッティングの際に、検証環境の構成でオンラインを維持しセーフコンフィグに保存、検証環境で出荷前に現場環境の構成に変更してホールドタイムを設けてから実装した。 　→検証環境と現場環境のサブネットが異なり、Out of date (reverted to safe config) となり、セーフコンフィグとして保存されず、セーフコンフィグには検証環境の構成で起動します。     セーフコンフィグが保存されるまで待ちたくない！　[打開策] MRに固定IPアドレスを割り当てたい場合を想定   最も確実な方法としては、ローカルスタータスページに直接設定を行うことです。 ローカルステータスページの設定内容はセーフコンフィグとは別で管理されており、ローカルコンフィグとして使用されます。 Using the Cisco Meraki Device Local Status Page - Cisco Meraki Documentation https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page   ゼロタッチで実装したい場合、現地環境にキッティング用のDHCPサーバーを設け、ダッシュボード上に投入したい構成を事前に設定いただくことです。 現地環境でオンラインとなり次第設定が反映され、そのまま現地環境で稼働させる方法です。 キッティング用のDHCPサーバーは以後撤去で問題はありません。   あるいは、実装環境にDHCPサーバーを実装している場合、DHCPサーバーから固定IPアドレスを払い出すことでも、ゼロタッチでの構成が可能です。   関連するドキュメント Cisco Meraki クラウドへの接続が失われたときの動作 - Cisco Meraki ドキュメント https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Behavior_during_Connection_Loss_to_Cisco_Meraki_Cloud ... View more

  はじめに 現在、PDLライセンスの仕様を誤認されていたり、Co-termに比べ管理が複雑であるためか意図した動作とならずトラブルを抱えるお客様が多く見られます。 仕様を知らずに操作を行い、ライセンスが減少したり意図しないラインセンス期間となった場合、サポートにご相談をいただいたとしても、恐縮ではございますが「ライセンス管理の問題」として対応せざるを得ない状況となります。   PDLライセンスを利用していく上での、注意事項と仕様についてご理解を深めていただくために、このコミュニティ記事にまとめました。 この記事をブックマークしていただき、PDLライセンスにおけるトラブル回避のためにご活用いただけますと幸いです。   CO-termからPDL にライセンス形態を変更したときの動作 この記事をご覧の方はすでにご承知と存じますが、ライセンス形態は一度PDLへ変更すると、 いかなる理由であってもCo-termへ戻すことはできかねます。 PDLライセンスへの移行方法について - The Meraki Community Co-termからPDL へ移行した際のライセンスの動きとしては、Co-termでのライセンス期間が、 オーガナイゼーションのネットワークに追加されているすべてのデバイスで按分されて適応されます。 ライセンスごとに按分されるわけではありません。 Co-termで100日間の残日数があった場合には、すべてのデバイスが100日間の有効期間とされます。   PDLライセンスのライセンスの消費開始日  PDLライセンス形態の場合、ライセンスの消費開始日はライセンスがCiscoからメールにて発送されてから90日経ってからです。 ライセンスをご購入されますと、Ciscoからメールにてライセンスキーの発送通知が届きます。   Co-termに比べ、ライセンス適応までの猶予はございますが、 PDL についても更新の際にはライセンスの期限を待たずにライセンスキーの通知メールが届き次第、 なるべく早くオーガナイゼーションに登録し、デバイスに適応することを推奨しております。 理由については後述いたします。     PDL ライセンス形態でのライセンス適応時の注意点 この項では、PDL ライセンス形態でご利用されている、システム管理者が把握しておくべきライセンス操作時の注意点について記載します。 PDL ライセンス形態でライセンスを登録する方法については、 下記のドキュメンにマニュアルのご用意がありますので、ご参考に願います。   ネットワークに追加したばかりのデバイスであれば、ライセンスを適応の操作を行うと、即時に適応されます。 ※過去に一度もオーガナイゼーションに登録し、ネットワークに追加したことがないデバイスに限る   しかし、すでにライセンスが適応されているデバイスに対して、Unusedライセンスを適応する場合、ライセンスは適応の操作が行われた時点から消費が始まるわけではありません。 7日間の猶予期間の後に適応されます。 この7日間はお客様が「間違ってライセンスを適応してしまった」場合の救済処置のための期間です。 下記のライセンスが消費されてしまうパターンは、すべてお客様の「ライセンス管理の問題」として取り扱われる、よくある事例です。   1、 猶予期間がない状態で適応される事例 ライセンス期間365日より少ない場合、ライセンスが切れた際に猶予期間が設けられません。 即座にライセンスが存在しない状態（None）の状態となり、この状態でライセンスを適応すると、30日間即座に減ります。 例えば、ライセンスが切れる5日前にライセンス(365days)を適応した場合、ライセンス(365days)がアクティブになるのは7日後ですので、適応から６日目だけライセンスが存在しない状態（None）となります。 上記のため、7日目にライセンスがActiveの状態になる際には、ライセンスが存在しない状態（None）ととなっているため、30日間即座に減少します。 これはライセンスの不具合ではなく仕様による動作です。   ライセンス期間365日より少ない場合とは？ デバイスを追加してからライセンスを適応するまでにタイムラグがある場合、デバイスをネットワークに追加してから猶予期間がスタートするため、10日後に適応すれば、適応したライセンスは355日分として認識され、ライセンス切れになった際に30日間の猶予期間に入らず、ライセンスが存在しない状態（None）となります。   2、 猶予期間中に適応している事例 30日間より少ない日数で減少しているものは、ライセンスが切れてからの猶予期間中に適応しているものです。 この場合、消費した期間分減少しますので、仕様による動作です。   3、 そもそも追加せずに使用していた事例 デバイスを追加後、一度もライセンスを適応せずに１ヶ月以上使い続けている状態で、 ライセンスを適応したことで、仕様により30日間減少した場合です。     覚えていただきたいのは有効期限がNoneとなっている場合にライセンスを適応すると30日間ライセンス期間が消費されることです。この消費されてしまった期間はサポートによる修正、および補填はいたしかねてしまいます。     上記の事例を回避する唯一の方法は、ライセンスの有効期限の8日以上前にライセンスを適応することです。 なお、適応タイミングが有効期限が切れる1ヶ月前だったとしても、残りの日数は再計算時に有効期間に加算されます。 これによりライセンス期間を無駄なく利用できるため、早めの適応による損失はありません。     ライセンスの付け替えについて PDLライセンス形態ではライセンスの付け替えの概念があります。 また、デバイスから外されたライセンスはUnused Activeのステータスであるため、すでにライセンス適応済みのデバイスに対してこのライセンスを追加適応することはできません。 ※ライセンス適応済みのデバイスに対してライセンスを適応できるのはUnusedのステータスのライセンスのみです   ライセンスの付け替えの手順について １、オーガナイゼーション＞ライセンス情報＞デバイス のページを開き、ライセンス数の列を表示させます。   ２、ライセンス数の列にある数字をクリックすると、現在適応されているライセンスの状況が確認できます。 ３、Active licenseのポップアップのUnassignをクリックして、ライセンスをデバイスから取り外します。 ４、ライセンスタブから取り外したライセンスのActionsのプルダウンメニューからAssaign licensesをクリックします。 ５、ライセンスを割り当てる ページが表示されますので、割り当てたいデバイスのSelect of licensesのプルダウンメニューから割り当てる数量を指定し、次へを押下して表示されるサマリーで割当を押下することで適応が完了します。    その他、参考となるドキュメントやツール   デバイスごとのライセンス(PDL) - 設定・操作 - Cisco Meraki https://documentation.meraki.com/General_Administration/Licensing/Meraki_Per-Device_Licensing_-_Configuration_jp   デバイスごとのライセンスの背後にある科学 - Cisco Meraki https://documentation.meraki.com/General_Administration/Licensing/Meraki_Per-Device_Licensing_Overview/The_Science_behind_Per-Device_Licensing   ... View more

vMXとMXの切り分け作業の差異 vMXの場合、オンプレミスのMXに比べ、トラブル発生時の復旧に際してのご担当者さまの作業負荷が高い状況です。 トラブル発生時に、一通りのトラブルシューティングを実行しても改善がない場合にはサーバー再起動や、 vMXを再度SetUpしていただく必要があります。   具体的には、vMXに対してダッシュボードからデバイスの再起動は可能ですが、初期化はできません。 オンプレミスであれば初期化ボタンを押下するのみであるところ、vMX初期化を実行するには上記のように再度SetUpを行うという対応となります。   その際のSeyUpマニュアルがお使いのサーバーやクラウドによって異なり、弊社の公式ドキュメントが多岐にわたる状況です。 このコミュニティ記事では、初期化復旧時に参考となるマニュアルをまとめさせていただきます。   vMXをご利用いただいているお客様は、vMXのSetUpに必要なvMX認証トークンをダッシュボードから、その都度生成していただく必要がございます。 vMX認証トークンは、 生成後 1 時間以内に入力する必要があります。 それ以外の場合は、新しいトークンを生成する必要があります。      プラットフォームごとのSetUpマニュアル一覧 vMX Setup Guide for NFVIS vMX Setup Guide for Alibaba Cloud vMX Setup Guide for Microsoft Azure vMX Setup Guide for Amazon Web Services (AWS) vMX Setup Guide for Amazon Web Services (AWS) China [deprecated] vMX Setup Guide for Google Cloud Platform (GCP) vMX Setup Guide for Cisco UCM Cloud (UCMC) ... View more

モニターキャプチャとは 無線LANアダプターを「モニターモード」状態にすることで、指定したチャンネルの無線パケットを全て収集することです。 無線環境の問題に遭遇した時に、トラブルシューティングの1つとしてモニターモードキャプチャが必要となることがあります。 主に必要となるユースケースは、無線においての接続の問題などに有効となることがあります。   Meraki ダッシュボードからワイヤレスのパケットキャプチャを取得することができますが、 ワイヤレスインターフェースを指定した場合、MR自身から送信した無線パケットは取得されないという仕様があるため、モニターモードキャプチャとして取り扱うには不十分です。   モニターモードキャプチャは、第三者となる調査用端末が、アクセスポイントとクライアント間の無線パケットをキャッチするものです。 無線LANのパケットキャプチャーはこれまで、調査用端末として、Macを使うか専用の無線LANアダプターを使うのが基本であり、Windows PCしかない場合や専用の無線LANアダプターを用意することが難しく、モニターキャプチャを取得することが困難な状況が多々あります。   この記事では調査用端末をMRで代用して、モニターキャプチャを取得する方法についてご案内します。   MRでモニターキャプチャを取得する方法 前提条件として、MRは必ず2台隣接して存在している環境であることです。  ※理由は先述の通り 全体の簡単な手順としては下記の通りです。     ①ダッシュボードでチャネル設定 隣接する2つのAPを同じチャネルに設定します。 何かしらの事象が発生しているAPが利用しているチャネルにもう一方を合わせます。 チャネル指定の方法については下記の通りです。 使用チャネルを手動で設定する方法についてご案内いたします。 (1)「ワイヤレス」 > 「設定」 > 「無線設定」ページで 、「バンド」ドロップダウン メニューから5Ghzを選択し、設定変更したい任意のMRの無線を見つける (2)任意の無線の 「チャネル」列でチャネル番号のリンクをクリック (3)ポップアップが表示されるため、「チャネル設定を変更する」を押下 (4)手動を押下して、テスト用MRで選択されていた同じチャネルを選択し、保存 以上で、手動設定は完了します。 より詳細な手順や、説明が必要な場合は下記のドキュメントに写真付きのマニュアルがございますので、ご参考にください。 Transmit Power and Antenna Configuration - Cisco Meraki https://documentation.meraki.com/MR/Radio_Settings/Transmit_Power_and_Antenna_Configuration#Manual_Power   注意：チャネル変更時にチャネル変更をしたMRに接続しているクライアントは一時的に切断されます。 業務時間外やクライアントが少ないタイミングでの設定変更を推奨いたします。     ②物理的な準備 下記の図のように3台を近辺に配置し、テスト用のMRとClientが必ず接続する状況としてください。 ※モニターキャプチャを行うMRに接続しないように 場合によっては、モニターキャプチャを行うMRからSSIDを送信しないようにすることが効果的です。 ＊SSIDの稼働設定機能を使って特定のMRから特定のSSIDを送信しないように設定することができます。 設定手順は下記の通りです。 (1)「ワイヤレス > アクセスポイント」で、一覧より該当のAPに対してタグを設定 (2) 「ワイヤレス > SSID」で使用していない「Unconfigured SSID 」を有効化し、設定を実施 (3) 「ワイヤレス > SSIDの稼働設定」で、以下の内容で、変更内容の保存を実施 　　- SSID: (2) で設定したSSIDを選択 　　- 公開設定：　このSSIDを非公開にする 　　- APごとの公開設定：　「次のタグを持つAPでのみ有効」で(1) のタグを指定 　　- 利用可能時間の設定： 無効 ※通信切断は発生しない想定とはなりますが、運用影響の少ない時間帯で設定変更を行うことを推奨いたします。   ③パケットキャップ開始 モニターキャプチャ用のMRと、テスト用のMRを2つ指定して、   ワイヤレスインターフェースを指定してパケットキャプチャを実行します。 2つのMRを指定することで、モニターキャプチャの取りこぼしを防ぎます。   パケットキャプチャのページの詳細な利用方法については、下記のドキュメントをご参考にください。 パケット キャプチャの概要 - Cisco Meraki https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Packet_Capture_Overview#MR_-_Access_points   ※無線ビーコンパケットが大量に飛び交う環境の場合、MRのメモリ容量がすぐにいっぱいになり、 モニターキャプチャがすぐに終了してしまうことがあります。 その際には、パケットキャプチャを実行時にテスト用ClientのMacアドレスでフィルタ設定をしてから、パケットキャプチャを実行してください。 例：ether host 11:22:33:44:55:66     ④検証 パケットキャプチャを実行中にClientをMRに接続し、検証に必要な通信を発生させてください。     ⑤パケットキャプチャ終了 パケットキャプチャの取得に成功し、正常にダウンロードされれば完了となります。     関連するドキュメント TS-flow-radius - Cisco Meraki https://documentation.meraki.com/MR/Encryption_and_Authentication/RADIUS_Issue_Resolution_Guide/TS-flow-radius パケット キャプチャの概要 - Cisco Meraki https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Packet_Capture_Overview#MR_-_Access_points   ... View more

はじめに このコミュニティ記事は、共同終了（Co-term)ライセンス形態を利用されている、システム管理者に向けた、 ライセンス管理および、操作、更新に関するガイドです。 基本的な部分をまとめた内容ですので、詳細な説明が必要な場合にはドキュメンテーションをご参照ください。     ライセンスの消費開始日について 共同終了ライセンスの場合、ライセンスの消費開始日はライセンスがCiscoからメールにて発送された日からです。 ライセンスをご購入されますと、Ciscoからメールにてライセンスキーの発送通知が届きます。   無駄にライセンスが消費されてしまう前に、ライセンスキーの通知メールが届き次第、 なるべく早くオーガナイゼーションに登録することを推奨しております。   ライセンスをご購入されただけではライセンスは登録されません。 必ず、ダッシュボードからライセンスの登録をお願いいたします。 ※登録されず無駄に消費されてしまった分については、補填はできかねますのでご了承ください。     共同終了ライセンス形態でのライセンス登録操作について オーガナイゼーション > 設定 > ライセンス情報 ページから、Add another license（別のライセンスを追加） リンクをクリックすると、管理者はオーガナイゼーションにライセンスを追加できます。  この後の操作は「新たに機器を追加新設される場合」と、「ライセンスを更新される場合」で操作が異なります。 ・新たに機器を追加新設される場合 License more devices（デバイスライセンスの追加）を選択します。 追加するライセンスキーは追加するデバイスと同じ数量必要です。 なお、追加済みのライセンス数に余剰がある場合は不足分の追加で問題ありません。 参考：https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview#Adding_New_Licenses   ・オーガナイゼーションのライセンスを更新する場合 Renew my Dashboard license(ダッシュボードのライセンスの更新)を選択します。 この時、注意いただきたいこととしては、更新する際に購入するライセンスの数量は、 ライセンス情報ページの「ライセンス数」ではなく実際に利用している「現在のデバイス数」であることです。   ライセンスの更新には現在稼働しているデバイスと同じモデルで同じ数量のライセンスをご購入いただく必要がございます。 参考：https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview#Renewing_Your_Dashboard_Licensing   注意！ 誤って、License more devices（デバイスライセンスの追加）を選択して登録をしますと、 従来のライセンス数と更新分のライセンス数の合算でライセンスを按分するため、想定よりも短いライセンス期間となります。 例）10個の1Year ライセンスで10台のデバイスを稼働しているオーガナイゼーションのライセンスが期限が近いため、更新しなければならない。 しかし、誤って、新たに購入した10個の1Year ライセンスをLicense more devices（デバイスライセンスの追加）で登録してしまった。 →この場合、新たに購入した10個の1Yearライセンスを20台で按分することになり、約半年しか期間が伸びません。   ライセンスの取り消し 誤って追加してしまった場合には、ライセンス履歴から赤いロールバックマークで表示されている 「ライセンスの取り消しボタン」の操作を行うことで復旧できます。 ライセンス登録取り消しボタンが有効になるのは、ライセンスが適用されてから7日の間です。 ライセンス登録後のライセンス期間が想定と相違がないか必ずご確認をください。   元のライセンスキーを無効化し、同じ内容のライセンスキーを新たに発行するという動作をします。 取り消し実行時に、新たに発行されたライセンスキーが表示されますので、そちらのメモなどに控えてください。   なお、取り消し時に表示される新たに発行されたライセンスキーを見落としてしまった場合には、 オーガナイゼーション＞変更ログ のページにてから改めて確認することができます。 Meraki同時終了ライセンスの概要 ライセンス取り消し操作について- Cisco Meraki https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview#Removing_and_Undoing_License_Claims     ライセンスの按分のメカニズム 共同終了ライセンスの仕様上、ライセンス期間はライセンス数で按分されております。 Co-Term は1つオーガナイゼーションで利用できるデバイスの上限を、ライセンス数によって決定するだけなので デバイスを消す = 上限が減る とはならず、上限にあわせて有効期限が設定されます。   また、それぞれのモデルとライセンスには、それぞれの金額に基づいた価値が付けられています。 その価値に伴って按分されるウェイトも異なるため、最も価値の低いMR ENTライセンスを1つ追加しても、1日程度しか伸びないということがあります。   共同終了ライセンスにおける計算方法やイメージについて詳細な説明が必要な場合は下記のドキュメントが参考になります。 ライセンスの共同終了の背後にある科学 - Cisco Meraki https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview/The_Science_behind_Licensing_Co-Termination       ライセンスが切れてしまった場合の動作 ライセンスを更新し忘れてしまった場合、購入したものの間に合わない場合についてです。 ライセンス期限が切れたとしてもすぐさまオーガナイゼーションがシャットダウンされるわけではないので、ご安心ください。 ライセンスが切れた日から30日間のシャットダウンまでの猶予期間が設けられています。 この期間内にライセンスを購入いただき登録の操作までをお願いいたします。   Meraki同時終了ライセンスの概要 猶予期間について - Cisco Meraki https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview#The_30-Day_Grace_Period     その他、参考となるドキュメントやツール ライセンス更新時、あるいは追加時にどの程度のライセンス期間が見込まれるのか計算することができます。 下記のドキュメントよりライセンス計算機をご活用ください。 Using the License Calculator - Cisco Meraki https://documentation.meraki.com/General_Administration/Licensing/Using_the_License_Calculator   オーガナイゼーション間でライセンスを移動したい場合には下記のマニュアルが参考になります。 How to do a License Transfer in Cotermination - Cisco Meraki https://documentation.meraki.com/General_Administration/Licensing/How_to_do_a_License_Transfer_in_Cotermination ... View more

はじめに こちらは、Meraki Nowをご契約されているお客様に向けたコミュニティ記事です。 この記事のフォーカスとしてはフィールドエンジニア（FE）付きのサービスをご契約いただいている際の Meraki Nowを申請した際に、お客様側で必要な対応についてです。   Meraki Nowのサービスについてはドキュメントをご参考にください。 Cisco Meraki RMA Only Service -Meraki Now     Meraki NOWの申請に際して Meraki Nowご契約機器の交換申請時は、原則としてお電話にてお問い合わせいただくようお願いいたします。 また、お電話いただく際はMeraki Nowのご契約の有無についても担当者までお伝えいただくようお願いいたします。 メールにてご依頼いただきますと、通常のケースと同じ取り扱いとなり、対応開始までお時間がかかることがあります。   また、4時間目標など時間目標付きのご契約に関しては、時間目標はサポートにてMeraki Nowの処理が完了した段階からの目標時間となります。 翌営業日が目標時間のご契約の場合には、当日15時までにMeraki Nowの処理が完了していなければなりません。 この時刻を過ぎますと、翌々営業日の到着となりますのでご了承ください。   ご依頼時に必要な情報の問診票をご用意しておりますので、ご活用いただけますと幸いでございます。 問診票に記載された情報を事前にご教示いただけますと、サポートによる切り分けに非常に有効に活用されます。   また、機器の設置位置や、入館時のセキュリティチェックに必要な書類などの情報をあらかじめご教示いただきたく存じます。 ※機器の作業位置が2m以上の場合、FEのサポート対象外となりますので、あらかじめご了承ください。 　高さ 2m 以上の高所での作業（床面から 2ｍを越える場所に上がっての作業は高所作業となります。） ※所管の法令規制により、オンサイト作業の対象範囲外となります。 Case作成時に必要な情報（問診票） - Cisco Meraki       FEの作業範囲について FEの作業範囲としては、管理者権限の不要な作業全般となります。   この作業範囲には、ローカルステータスページの設定が含まれておりますが、 この設定内容についてはお客様側にて事前にご用意をいただき、FEに設定情報をお伝えいただく必要がございます。   例）交換機器にStatic IPが割り振れられている場合など IP address：x.x.x.x Subnet：x.x.x.x Gateway：x.x.x.x Primary DNS：x.x.x.x Secondary DNS：x.x.x.x   ローカルステータスページの概要と、アクセス方法、操作については下記のドキュメントをご参考にください。 Cisco Merakiデバイスのローカル ステータス ページの使用 - Cisco Meraki     管理者権限が必要なMeraki ダッシュボード上の操作はFEでは対応できかねますのでご了承ください。 管理者権限が必要な操作でご不明点などがございましたら、ケース起票時にMerakiサポートにお問い合わせをいただくか、 Merakiのドキュメンテーションを参考にいただけますと幸いです。   ※MSの交換時には設定の複製などの作業が見込まれますので、下記のコミュニティ記事をご参考にいただけますと幸いです。 MSの交換方法について - The Meraki Community   なお、その他、FEが実施できない作業については下記のご利用ガイドをご参考にください。 Cisco テクニカルサービス ご利用ガイド https://www.cisco.com/c/dam/global/ja_jp/support/loc-tac-guide/pdf/cisco-ts-startup-guide.pdf     Ciscoテクニカルサービス規約について Tools & Resource 1次店　/　ディストリビュータ - Cisco https://www.cisco.com/c/m/ja_jp/partners/partner-with-cisco/services-partner-program-cspp/tools-resources-1.html       ... View more

MSの交換方法 MSの交換の手順と注意時点について記載しております。 予備機やRMA時の代替機との交換作業時の、実地作業のご参考になればと存じます。   MSの交換に際して、シングル構成かスタック構成か、Warm spare構成なのかで手順が異なります。 それぞれの手順で注意していただきたい事項、Catalyst SWと混同してしまうケースが多々あるため、 こちらの記事でご紹介している手順をご参考にしていただけますと幸いでございます。   前提条件として、交換機を事前にオーガナイゼーション＞インベントリに登録済みとしております。 デバイスをインベントリに追加いただいてから下記の作業をご実施いただくようにお願いいたします。 インベントリの操作方法については下記のドキュメントをご参考にください。   Using the Organization Inventory - Cisco Meraki Documentation https://documentation.meraki.com/General_Administration/Inventory_and_Devices/Using_the_Organization_Inventory     シングル構成の場合 ダッシュボードより代替機をネットワークに追加いただき、故障機から設定を複製をお願いします。    1.「スイッチ」タブにて代替機の「スイッチ追加」 。 　（上記によって、「スイッチ」タブにて代替機が表示される）  2.「スイッチ」タブにて、設定複製、タグ内容など設定。 ※3 　PDLの場合、上記によって、障害機のライセンスを代替機に付け替えが必要。 3.故障機の電源OFF。  4.代替機の電源ON。代替機にて初期設定、ローカルステータスページの設定内容があれば。なければスキップ。  5.ステータスオンライン状態にすると設定がダウンロードされファームウェアがアップデートされる。  6.代替機の詳細ページにて設定ステータスが最新となっているか確認。  7.物理配線を新しいスイッチに付け替え。 8.故障機を「スイッチ」タブと「インベントリ」タブから両方削除 ※1※2 9.故障機取り外し        スタック構成の場合 この手順では、ファームウェア不一致によるスタック失敗を回避することを考慮して作成しております。  また、LAGをスイッチを跨いで設定している状況ですと、交換時にスタックメンバーで通信断が発生する事象が確認されています。  ※MS15.21.1まで事象発生、MS16.1以降にて修正済み そのため、交換にはメンテナンス時間を設けて実施をお願いいたします。    1.「スイッチ」タブにて代替機の「スイッチ追加」  　（上記によって、「スイッチ」タブにて代替機が表示される）  　PDLの場合、上記によって、障害機のライセンスを代替機に付け替えが必要。 2.スイッチ＞スタックスイッチ＞【対象スタック名】＞複製とメンバーの交換＞スタック内のスイッチの交換にて故障機と代替機を交換。 ※設定は自動的に複製されます スタックメンバーが3台以上の場合は、設定複製を行い新規スタックメンバとして代替機を追加、スタックメンバから故障機の削除する手順でも可能です。 3.故障機の電源OFF、故障機からスタックケーブルを外す。 4.代替機の電源ON。代替機にて初期設定、ローカルステータスページの設定内容があれば設定を行う。 　※なければスキップ。 5.ステータスオンライン状態にすると設定がダウンロードされファームウェアがアップデートされる。  6.MSの詳細ページにて設定ステータスが最新となっているか確認。  　※最新でないままにスタックケーブルを接続すると、ファームウェアや設定が不一致の状態となり、スタックに失敗することがあります。  7.物理配線を新しいスイッチに付け替え、スタックケーブルを接続して復旧。  8.故障機を「スイッチ」タブと「インベントリ」タブから両方削除 。※1※2 9.故障機取り外し 。 10.スイッチ＞スタックスイッチ＞【対象スタック名】＞メンバー管理 にてスタックステータスにエラーやアラートがないか確認。    ※ただしくスタックができていないというアラートが発生していることがありますが作業途中で発生したアラートが残っていることがあります。  実機の方でステータスランプが緑色であれば正しくスタックができているため、無視して問題ありません。  時間経過で解消されます。       Warm spare構成の場合 1.「スイッチ」タブにて代替機の「スイッチ追加」 。 　（上記によって、「スイッチ」タブにて代替機が表示される）  2.「スイッチ」タブにて、設定複製、タグ内容など設定。 ※3 　PDLの場合、上記によって、障害機のライセンスを代替機に付け替えが必要。 3.故障機の電源OFF。  4.Meraki ダッシュボードで[スイッチ] > [スイッチ]ページにてWarm Spare設定を、 古いスイッチから新しいスイッチに変更。 MS Warm Spare (VRRP) Overview - Cisco Meraki https://documentation.meraki.com/MS/Layer_3_Switching/MS_Warm_Spare_(VRRP)_Overview 5.代替機の電源ON。代替機にて初期設定、ローカルステータスページの設定内容があれば設定を行う。 　※なければスキップ。 6.ステータスオンライン状態にすると設定がダウンロードされファームウェアがアップデートされる。  7.設定のダウンロード及び、Firmwareアップグレードが完了したことを確認。 8.物理配線を新しいスイッチに付け替え。 9.故障機を「スイッチ」タブと「インベントリ」タブから両方削除 。※1※2 10.故障機取り外し 。   ※ただしくWarm spareが構成できていないというアラートが発生していることがありますが作業途中で発生したアラートが残っていることがあります。  実機の方でステータスランプが緑色であれば正しく構成ができているため、無視して問題ありません。       デバイスの設定がMerakiCloudと同期できているかを確認する方法 該当のMSの詳細ページを開いていただきますと、画面左側にMSのステータスが順に表示されております。 各ステータスの中に、CONFIG（設定）の項目があり、そちらがUp to date（最新）となっていれば同期がされていることがわかります。       参考資料 ※1[オーガナイゼーション インベントリの使用方法]  https://www.cisco.com/c/m/ja_jp/meraki/documentation/general-administration/inventory-and-devices/using-the-organization-inventory.html  ※2[ダッシュボードのネットワークに対するデバイスの追加と削除]  https://www.cisco.com/c/m/ja_jp/meraki/documentation/general-administration/inventory-and-devices/adding-and-removing-devices-from-dashboard-networks.html  ※3[設定の複製方法] https://documentation.meraki.com/MS/Other_Topics/Switch_Cloning_jp ... View more

PDL変換の新規のご依頼は6月25日をもって対応終了となりました。   現在、PDLへの変更をご希望の場合、現在サポートに「英語」でケースを上げていただくことで変更機能の有効化を行っています。 お客様側でPDLへの変換が出来なくなった経緯とこの一連の手順については、以下のドキュメントページでもご案内しております。 EN:How to convert an org from Co-term to Per Device licensing - Cisco Meraki   PDLへの変換をご希望の場合、上記ページの注意事項をご確認いただいた上で、 以下の5つの情報を英語で記載した新規ケースをオープンしていただけますでしょうか。   ＊PDLへ変換する前に ・すでにPDLの組織を保有している場合は、MSPポータルの機能でPDLの組織のクローンを作成することで、このフローをスキップすることができます。 ・PDL と共同期間の間でライセンスを移動できないことをご留意ください。 ・2 つのライセンス モデルの管理は複雑になる可能性があるため、すべての組織で一貫して 1 つのライセンス モデルを使用することを推奨しております。 ・組織が PDL モデルの検証に使用したい場合、本番の組織がすでにPDLであればMSPポータルから組織のクローンを作成することができます。     ＊PDL変換の全体の流れ 1. PDL変換依頼のための英語でのケースオープン 2. 海外のライセンス担当チームでの確認 3. ライセンス担当チームでの機能有効可処理とケース上での報告 4. お客様側で確認及びダッシュボードでの変換実施     1のケース起票時に必要となる情報は以下のとおりです。 下記の5つの項目を英語の情報でご用意いただき、通常通りダッシュボードからケースをオープンしてください。 下記にテンプレートをご用意しておりますので、ケース起票時にご活用ください。 ※日本語は削除してご利用をお願いいたします 件名： Convert License model to PDL ・Reasons to Convert to PDL（PDLへ変換する理由） 　... お客様のビジネス上、PDL形式への変換が求められる理由をご記載ください。 ・Agree with considerations（PDL変換へ同意いただける旨のお返事） 　... Co-terminationからPDLに変換後、原則としていかなる場合もCo-terminationに戻すことはできません。 　この旨にご了承いただける旨のお返事が必要となります。 ・Administrator（該当オーガナイゼーションの管理者ユーザ情報） 　... 管理者ユーザ名、ご登録のメールアドレスをお送りください。 ・Support Passcode（上記管理者ユーザのサポート用パスコード） ・Sales representative（該当オーガナイゼーションの Meraki営業担当者） 　... Meraki 営業担当者の氏名とメールアドレスをご記載ください。 　営業担当者は以下の手順でご確認いただけます。 　ダッシュボード上部「ヘルプ」 ＞ メニュー内「ヘルプ」 ＞ ページ下部「ドキュメントでお探しの情報が見つからなかった場合」 をクリック ＞ 「ドキュメントでお探しの情報が見つからなかった場合」をクリック 　営業担当者の情報が表示されない場合、この項目はスキップしてください。   なお、サポート用パスコードに関しては、毎日変更されるものとなります。   ご提出いただく時間によっては、翌日に再度確認していただく必要がある可能性がございます。   [Meraki 顧客番号やサポート用パスコードを確認する方法]     　上記内容でケースを起票いただくことで、ライセンス担当チームから追ってご連絡をいたします。 場合によって追加の情報を求められる場合がございますので、英語でお返事をいただけますと幸いでございます。 なお、ケース内で組織名などの固有名詞以外で日本語を用いると、システムにより正しい担当者への割り当てに時間を要する場合がございますので、ご了承ください。 お手数ではございますが、ケースの起票からライセンス担当チームと会話まで、全て英語でご記載いただくようにお願いいたします。 ... View more