本記事では、Meraki 認証を使用されているSSID を使用されている環境において、

サーバ側の証明書更新が実施された際の動作等について、紹介をさせて頂ければと存じます。

// 問題 //

Meraki 認証を使用している環境において、サーバ側で証明書の期限切れに伴い、更新作業が発生する事がございます。

この動作に伴い、端末側で新たに更新された証明書の情報を信頼する必要があり、

無線接続時にポップアップが表示される場合がございます。

端末側の動作によっては、ポップアップ等が表示されず、新しい証明書が信頼されるまで

無線接続ができないという様な事象が発生する場合がございます。

無線接続時の端末のやり取りを確認すると、TLS Certificate のやり取りにおいて、

サーバ側は新しい証明書の情報を端末に通知をしている事が確認出来ます。

この情報を受信した端末側が、証明書を信頼するかどうかの判断を実施する形となります。

// 解決策 //

Meraki 認証の証明書更新は、今後も発生する可能性があるため、

更新の度に端末側で証明書を信頼する操作が必要になる可能性がございます。

ポップアップが表示されず、無線接続が実施できない場合、端末側で手動でWi-Fi プロファイルを削除し、

再度作成する事で事象が改善される可能性がございますが、弊社MDM をご利用の場合、

事前に以下の設定を実施して頂く事で、端末側での操作が不要になる場合がございます。

* 端末やOS のバージョン等により、動作が異なる場合がございますので、動作確認の上、
  実際にご利用頂ければと存じます。(弊社環境: iPhone 11/OS 15.6.1)

1. システムマネージャ> 管理> 設定 より、新しいプロファイルの作成

2. "設定を追加" をクリックし、Wi-Fi Settings を追加

3. SSID 名を設定し、セキュリティの項目でWPA2-エンタプライズ 及びプロトコルにおいて、PEAP にチェック

4. "信頼性"のタブにて、radius.meraki.com と入力し、保存

* 入力する値は、変動する可能性があるため、後に記載のあるURL を参照して下さい

上記設定後に、端末側にWi-Fi プロファイルがインストールされた事を確認した後に、

実際にSSID を接続時に、証明書を信頼する旨のポップアップが表示されないかどうか確認をして下さい。

現在Meraki 認証で使用されている証明書は、2023/02/08 までの期限となっているため、

この辺りの時期に再度証明書の更新が実施される事が予想されます。

証明書更新に関するご案内は、こちらのURL の様な形で公開がされるかと存じます。

なお、上記手順４で入力した値については、URL にて証明書のホスト名が公開されるかと存じますので、

そちらの値を入力して頂ければと存じます。

本記事では、WEBブラウザ（Chrome）でHARキャプチャーの取得方法を動画にてご紹介させていただきます。

■HARキャプチャーの取得方法

作成時使用したChrome Browser version : 103.0.5060.114

①　再現するページを開きます。

②「F12」を押下し開発者モードを開きます。

③「NETWORK」タブをクリックします。

④　HAR キャプチャーが開始されていることを確認します。
　※丸いボタン(●)が赤くなっていると、キャプチャー中となります。

⑤　事象を再現させます。

⑥　事象の再現が完了しましたら、Export ボタンを押下し、HAR ファイルをダウンロードします。

// 概要 //

本資料では、ケースオープン後の調査を経て、想定（期待）されない事象・動作であることが認定された際に、その後のケースの扱いについて説明しております。

こちらの資料に記載の通り、想定されない動作と判定された後に修正の対応となりますが、対応には優先度が大きく関わっており優先度が低い場合においては対応まで長く時間がかかる場合があります。

まずは優先度がどのように定められるかについて下記に概要を記載します。

// 対応優先度の考え方について //

ケースオープン後に想定されない事象であると認定された場合、その後は優先度に応じた対応となりますがこの優先度は様々な要因によって決定され主に下記に分類されます。

　 - ワークアラウンドの有無

　　設定変更、再起動での回避の可否

　 - 事象の特性と影響

　　事象特性（表示上だけの表層的な事象、または通信影響等が発生するか等）、及びビジネスインパクトの有無等の影響度合い

　 - 事象規模

　　グローバルでの事象報告数、特定環境・設定等に依存する問題であるか

// 障害となった場合について //

想定されない動作により障害となっている場合、通常高優先度での対応となりますが日本語での詳細情報については対応ステータスを含めこちらのリンクにて公開される場合がございます。

// 修正・改善に要する期間の考え方 //

修正までに要する期間は実際の修正自体の容易性によっても変わりますが、それ以前に対応優先度が大きく関わってきます。

弊社内部での優先度の区分けは数段階に分かれておりますが、障害等を含め上述要因に複数該当しているような場合は最高優先度での対応となり、この場合は他優先度の事項と比較し早急に対応がなされます。

※ すべての上記事項に当てはまったとして、必ずしも最高優先度となるわけではありません。

また期待されない動作による障害となった場合、対応ステータスを含め日本語での詳細情報についてはこちらのリンクにて公開される場合がございます。

上記以外の低い優先度となった場合は、順次対応される形になります。

// なぜ低い優先度の場合に時間がかかるのか //

想定されない事象はグローバルで日々数多くの報告が上がりますが、事象が判定された後に即座に修正されるわけではなく優先度に応じ順次対応がなされます。

これは単純な順番通りで対応がなされるというわけではなく、日々報告される他事象の報告状況に連動しダイナミックに変化するものであるため、修正までの期間を一概に明示することができません。

また優先度自体も状況に合わせ定期的に見直される場合があります。

// ケース上での報告と扱いについて //

上述理由で優先度の低い事象については予め対応時期を出す事ができないため、ケース上での状況報告は何かアップデートがあった場合のみとさせていただいております。

また上述の通り、多くの場合は修正時期を見込むこと自体が難しいため報告の頻度自体も非常に少なくなる場合もございます。

特に既知事象に該当している事象などで、“最低でも数ヶ月は進捗が無い見込み”となるケースもあることから、弊社内でのオープンケース増大に伴う各お客様への対応効率悪化の観点より一度ケースクローズをお願いさせて頂く場合があります。

もし進捗確認が必要であれば時間をおいて、元ケース番号の情報と共に新規にケースオープンをお願いできますと誠に幸いです。

// 事象による業務影響が出ている場合について //

対応優先度は上記のような理由で決定されるもの、もし実際に事象による業務影響やビジネスインパクトが大きくなっている場合、優先度をあげるために弊社営業を通したエスカレーションのプロセスについて相談させていただく場合がございます。

詳細についてはこちらのリンクをご参照ください。

// 参考情報 //

サポート対応に関するよくあるご質問と回答(FAQ)

Meraki製品における、想定されない挙動や動作が確認された場合の処理や対応プロセスについて解説します。

無線LANにて発生する不安定の事象につきましては、
AP自体の原因で発生する場合より無線LAN環境により発生する場合が多いです。
本記事では、無線環境の不安定事象について環境要因を切り分けする方法をご紹介させていただきます。

■ 接続されているクライアントの数

無線LAN環境は 有線の環境とは異なり、CSMA/CAの特徴上、half duplexとなり1つのデバイスとAPが
やりとりを行う際は、他のデバイスは待機するようになります。
そのため、接続する端末が多くなればなるほど、Airtime contentionが発生し、
クライアントのパフォーマンスは低下するようになります。
クライアントが利用するアプリにもよりますが、1つバンドに接続されているクライアント数が25台以上を超える場合、
パフォーマンスが低下する傾向がございます。

■ 必要とされる帯域幅の要件

規格ごとに定義されている最大 data rateにつきましては、
あくまでも理論値となり、control frame などの overhead を考慮していない
数値となり、実際の無線環境では、一般的には最大 data rateの半分の throughput となります。
また、channel bonding を利用しない (20Mhz)場合は、さらに30%ほど軽減させた
throughput が一般的にAPにて提供できる最大の throughput となります。

例えば、3ストリーム(MIMO 3*3)の 802.11 ac(5Ghz)の場合、最大 data rateは 289Mbps となりますが、
実際の無線環境では、144 Mbps、さらに channel bonding を利用しない (20Mhz)場合は~101 Mbpsとなります。
そのため、クライアント側より4Mbps ほどの帯域が必要とされる環境では、
約 25台ほどのクライアントが該当バンドを利用できますが、
高画質の動画ストリーミング必要となり、クライアント側より8Mbps以上の
帯域必要とされる環境では12台を超えるところからパフォーマンスが低下する傾向となります。

計算式
101 Mbps / 4mbps = 25.25台
101 Mbps / 8mbps = 12.625台

■ブロードキャストするSSIDの数

SSID数が多くなればなるほど、Management Frame(Beacon frame, Probe response等)も共に増加するようになり、
その結果 AirtimeのOverheadが発生するようになります。

例えば、5つ以上のSSIDを同時に広報する場合、
全体のスループットの2割程もしくは、それ以上にパフォーマンスが低下する場合がございます。
そのため、1つのAPにて推奨される最大のSSID数は3つまでとなります。

クライアンとの利用が少ない環境の場合は、目的によっては5つ程のSSIDを広報することも可能ですが、
高密度無線LAN環境においては、少しでもスループットが低下する場合、ユーザへの影響が大きいため、
必ず3つ以下のSSIDを利用していただくことを推奨いたします。

[Multi-SSID Deployment Considerations]
https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Multi-SSID_Deployment_Considerations

■ 2.4Ghz バンド利用時

2.4Ghz バンドにつきましては、5Ghz バンドは異なり、
日本で一般的に使用できるチャネルの数は3つ(一般的には1, 6, 11)のみとなります。
そのため、他の AP(他ベンダーのAP）にて同様のチャネル使用している可能性が高く、
結果的に該当チャネルの使用率が高くなるため、
2.4Ghz バンドに接続されているクライアントのパフォーマンスは低下する傾向となります。

また、2.4Ghz バンドにつきましては、Bluetooth や、無線マウス、電子レンジ、他の無線デバイス
においても多く使われるため、比較的に干渉が発生しやすいバンドとなります。
そのため、2.4Ghz バンドを導入する前後では必ずサイトサーベイを実施していただき、
無線環境の電波状況を確認して頂ければと思います。
2.4Ghz利用において環境の改善が難しい場合は、5Ghzのみ利用していただくことを推奨します。

干渉を起こす原因となる一般的なソースの一覧は以下のページをご参照して頂ければと思います。
[Common Sources of Wireless Interference]
https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Common_Sources_of_Wireless_Interf...

MRにておいては以下のページよりリアルタイムでチャネル使用率及び、干渉をご確認いただけます。
ワイヤレス >> アクセスポイント>> 特定AP >> [概要]タブ画面 >> 現在のチャネルの利用率

■ パワーミスマッチ

カバレッジを確保のためにAPの電波強度を最大値にする場合がございますが、
APの電波強度を強くする(最大値にする)ことで、遠い所でもAPからの信号は
クライアントより検知できるようになりますが、
クライアントの場合、発信できる電波の強度はAP程強くないため、(バッテリの保存の理由等で)
APからは無線クライアントの戻りのフレームが確認できなくなる可能性がございます。
その結果、APはクライアントからのフレームが受信できず、
Re-transsmissionを繰り返し、無線LANの全体的なパフォーマンスが低下する場合がございます。

また、逆にAPの電波強度をMinimumに設定することや、
Auto Power 設定にて選択できる幅を小さくすることにより、
意図していないローミングが多発する可能性もございますので、
事前・事後のサイトサーベイを実施し、適切な電波強度・範囲を決めていただく必要がございます。

MerakiのAPでは以下のページより電波強度の設定が可能です。

ワイヤレス >> 電波設定 >> 該当APのターゲット出力を選択（手動設定）


ワイヤレス >> 電波設定 >> 該当プロファイルを選択（Auto範囲設定）

■ Legacy device と Data rate

802.11 無線LAN環境では、CSMA/CA方式により
1つのクライアントがバンドを利用している場合は
他のクライアントは待機するようになります。

また、802.11 無線LAN環境では規格よって様々なdata rateで通信を行うため、
古いデバイスは比較的に遅いdata rateを利用し、
新しいデバイスは比較的に早いdata rateを利用するようになります。

そのため、無線LAN環境おいて、遅いdata rateを利用する端末が多く存在すればするほど
データを送信するまで時間がかかるようになり、
結果的に無線LAN環境の全体的なパフォーマンスが低下するようになります。
特に高密度無線LAN環境では、古い規格のデバイスの接続させないことが大事です。

MerakiのAPでは以下のページよりAssociation時の必要とされるMinimum bitrateを
高く設定することで、遅いdata rateを利用する端末の接続を事前に防ぐことができます。
ワイヤレス >> 電波設定 >> 該当プロファイルを選択 >> 最小ビットレート

■ 有線側による問題

無線LAN側より発生した Traffic も結局は、上位の有線側を通ることになるため、
有線ネットワーク環境のどこかでボトルネック、もしくはルーティング、パケットドロップ等の問題が発生している場合は
必然的にAPに接続されているクライアントにも影響が発生するようになります。

そのため、上位の有線側の問題か、無線側の問題かを切り分けするために
不安定の事象発生時に以下の方法で切り分けを実施していただければと思います。

・APが接続されている SWにて直接クライアントを接続した際には通信に問題がないか。
・APの無線側のパケットキャプチャー、有線側のパケットキャプチャーを取得し、
　有線側にてすでにパケットがドラップ発生していないか。

■ VoIP Traffic

VoIP Traffic等、リアルタイムで通信が必要とされるTrafficの場合、
安定したSNR、適切なローミング、パケットの優先度設定等が重要な要素となります。

・安定したSNR

　無線通信においては、データ送信を行ってから対向側より必ずAckを受信する必要がございます。
　SNR数値が低い場合は、対向側よりAckが受信できない場合が多くなり、
　結果 re-transmission (再送信)が頻繁に起きるようになります。
　Fileのダウンロード等のトラフィックにつきましては、ある程度
　re-transmissionが発生した場合でも、最終的に全てのデータが送信できれば、
　ユーザ側からはあんまりパフォーマンスの問題を感じませんが、
　VoIP電話等、リアルタイムのトラフィック送信を要するアプリにおいては、
　少しでも re-transmission の比率が高くなる場合、声が途切れてしまい、
　ユーザ側よりパフォーマンスの低下を感じやすくなります。

　そのため、十分なSNR値が確保できるか確認する必要がございます。
　VoIPのアプリが利用される無線環境で、推奨される SNR値は、25dB 以上となります。

　SNR値は以下のページにてご確認いただけます。
　ネットワーク全体 >>　クライアント >> 特定のクライアント選択 >> 信号


  SNRについての詳細は以下のKBをご参照して頂ければと思います。
　[Signal-to-Noise Ratio (SNR) and Wireless Signal Strength]
　https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Signal-to-Noise_Ratio_(SNR)_and_...

・適切なローミング

　VoIP電話を利用している状況で、ユーザが移動をする場合、
　APから他のAPへローミングを行うようになります。
　その際に、AP間で適切なOverlap coverageが存在する必要がございますが、
　APの距離が遠すぎる場合、他のAPへ「ローミング」判定とならず、
　一度切断され、再度接続が行われるようになり、
　VoIPアプリの利用に問題となる場合がございます。
　一般的にOverlap coverageは 15~20%程となりますが、
　実際の環境では正確なcoverageを測定することが難しいため、
　VoIPアプリが利用される無線環境では、導入前後に VoIP Call テストを行なっていただくことを推奨いたします。

・パケットの優先度

　複数のアプリからTrafficが混雑している場合、
　デフォルトでは、均等にパケットが処理されるようになるため、
　比較的にVoIP アプリしているユーザの場合品質に問題を
　感じる可能性が高くなります。
　その際、VoIPのTrafficの優先度を上げていただくことで、他のパケットより処理が優先され、
　混雑している環境でも、VoIP Trafficの品質を保証することが可能となります。

　パケットの優先度設定は、以下のページより設定が可能です。
　ワイヤレス >> Firewall ＆ トラフィックシェーピング >> トラフィックシェーピングルール


　詳細の設定は以下のKBをご参照して頂ければと思います。
　[Traffic and Bandwidth Shaping]
　https://documentation.meraki.com/MR/Firewall_and_Traffic_Shaping/Traffic_and_Bandwidth_Shaping

本記事では、ファームウェアアップグレードをスケジュール際に、

エラーメッセージが表示される問題について、ご紹介いたします。

<事象>

MR/MX/MS のファームウェアを最新版に変更する際に、以下の様なエラーメッセージが表示され、

スケジュールが出来ないという問題が発生する場合がございます。

Firmware Upgrade failed due to the following node_groups: <Network Name>.

Firmware Versions MR 28 and MX 16 require nodes to be able to contact Meraki's Device to Cloud Connectivity service over TCP port 443

<原因>

現在(2022/04) で最新版として公開されておりますMR28.x またはMX16.x では、Meraki クラウドとの通信に、

TCP443 を使用する動作に変更されており、ファームウェアアップグレード前に事前に

TCP 経由でMeraki クラウドとの通信が可能かどうか疎通性確認を実施します。

スケジュール時に疎通性が取れていない場合、上記の様なエラーメッセージが表示されます。

また、TCP443 が上位のネットワークでブロックされていなくても、疎通性の確認結果が反映されるまで、

時間がかかるため、上記のエラーメッセージが表示される場合がございます。

なお、MR では全てのモデルでTCP 経由での通信に変更されるわけではないため、

該当モデルについては、こちらのURL をご参照頂ければと存じます。

<解決策>

- 少し時間を置いて頂いてから、再度スケジュールを試して頂く

- 上位の機器でSSL Inspection 等の機能が有効になっている場合、クラウド向けの通信に対しては、無効にして頂く

- (急ぎでアップグレードが必要な場合) 以下の情報を添えて、弊社サポート側にスケジュールの依頼をして頂く

・対象のネットワーク名またはネットワークに登録されているいずれかの機器のシリアル番号

・スケジュール日時

<2024/02/08 追記>

管理通信がUDP を使用しているファームウェアから、TCP を使用するファームウェアへ

アップグレードする際に、以下の画像の項目の"Override firewall tests" にチェックを入れる事で、

本記事のエラー状態を回避する事が出来るかと存じます。

本記事では、任意のポートが閾値以上の時間ダウンした場合にアラートを送信する方法について、ご紹介します。

1.

アラートメールを受信したいメールアドレスを、ネットワーク全体> アラート> デフォルトの受信者に追加して下さい

2.

スイッチ> スイッチポート をクリックして下さい

3.

アラートの対象にしたいポートにチェックを入れ、タグをクリックして下さい

4.

任意のタグを追加して下さい

5.

ネットワーク全体> アラート> スイッチ> 任意のポートがダウンした時 のプルダウンを選択し、

手順4で作成したタグを選択して下さい

<参考文献>

Alerts and Notifications

本記事では、MR のLocal Status Page へのアクセス方法について紹介いたします。

1.

無線クライアントにて、Meraki-xxx のSSID が表示されているか確認をして下さい

* 下記の動画では、Meraki-Setup-Scanning のSSID が表示されましたが、型番やバージョンによっては、

別のMeraki-xxx のSSID が送信される場合がございます

2.

SSID 接続後に、任意のブラウザを開いて頂き、ap.meraki.com または10.128.128.126 へアクセスをして下さい

3.

固定IP 等の設定を実施したい場合には、Configure タブをクリックした後、

ユーザ名にAP のシリアル番号、パスワードは空白でログインを実施して下さい

Meraki-xxx という様なSSID が確認できない場合には、

こちらのURL よりトラブルシューティングを実施して頂ければと存じます。

<参考文献>

Cisco Merakiデバイスのローカル ステータス ページの使用

本記事では、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

本記事では、モニターキャプチャーの取得方法を動画にてご案内いたします。

※モニターキャプチャーを取得するためには、macbookが必要となります。

■モニターキャプチャーの取得方法

使用したmacbook Model : Mac Pro
使用したmacOS : Monterey 12.2.1


①右上のWi-fiマークを Option + Click します。

②ターゲットSSIDの情報を確認します。(使用Ch, BSSID等)

③「ワイヤレス診断を開く」をクリックします。

④左上の「ワイヤレス >> スニファ」をクリックします。

⑤モニターするチャネルと幅（20Mhz)を選択します。
　※Wifiや有線接続は事前にすべて切断してください。

　※チャネルは環境によって変更してください。
　 なお、Channel bondingを利用している場合は、データの漏れが発生場合があるため
　 必ず、チャネル幅を20Mhzに設定してください。（APの設定、測定するMacbook側両方とも）

⑥「開始」ボタンをクリックし、MACのパスワードを入力します。

⑦モニターキャプチャが開始されているので、事象を再現します。
　※クライアントをすでに接続している場合は、一度切断しSSIDへ接続する所からキャプチャを開始してください。

⑧取得したファイルは /var/tempの配下の保存されるため、
　取得している間に事前に該当フォルダーへ移動しておきましょう。

⑨事象の再現が完了しましたら、「中止」をクリックしてください。

⑩取得したファイルを開いて中身を確認します。
　該当BSSIDや、クライアントMACアドレスを利用して
　フィルターをかけ、データが正しく取得されているか確認します。

 ■モニターキャプチャー取得する目的や、一例につきましては、以下の記事をご参照していただければと思います。

https://community.meraki.com/t5/Meraki-サポートの記事/無線パケットキャプチャについて/ba-p/73741

本記事では、devnet ページより、API endpoint の使用方法についてご紹介させていただきます。

Devnet ページでは、現在利用可能な API の endpoint の一覧、詳細を確認することができます。
また、直接該当ページより API call の結果を確認することも可能です。

Devnet ページ URL
https://developer.cisco.com/meraki/api-v1/#!introduction/meraki-dashboard-api

■ Devnetページで、API endpoint使用方法

①ご希望のendpointを検索バーより検索します。

②該当endpointの説明、必須パラメータ、サンプル結果等を確認します。

③ページの右上「Parameter」タブを選択し、

　必須パラメータ、APIキーを入力し、「Run」ボタンをクリックしてください。

④必須パラメータ以外、他のパラメータも利用したい場合は、

　「Query Params」を有効にしていただき、該当パラメータの値を入力し、

　「Run」ボタンをクリックし、endpointを実行してください。

⑤出力結果をご確認ください。

■ Organization IDを確認する方法

Organization IDはダッシュボードの一番下に記載されております。

または、以下のAPI endpointでもご確認いただけます。

[Get Organizations]

https://developer.cisco.com/meraki/api-v1/#!get-organizations

出力例

■ Network IDを確認する方法

Network IDは上記で取得したOrganization IDを利用して、

以下のAPI endpointでご確認いただけます。

[Get Organization Networks]

https://developer.cisco.com/meraki/api-v1/#!get-organization-networks

出力例

◾️はじめに

Merakiではサポートケースクローズ後に、お客様満足度のアンケートへのご回答をお願いしております。

本記事では、日本のユーザー向けにアンケートの回答方法、目的および質問内容を概説します。

●アンケートへの回答方法

アンケートメールはケースクローズの翌日頃にお問い合わせいただいた管理者のメールアドレス宛に送信されます。

件名は「Cisco Meraki Support Feedback - Case ケース番号」となっています。

メールに記載されている「Provide Feedback:」に続くURLからアンケートへの回答が可能です。

[メール例]

●アンケートの目的

弊社テクニカルサポートのサービス品質向上のため、ケースクローズ後に任意で満足度調査をお願いしております。

いただいたご意見は弊社内で確認し、今後のサービス品質向上のために利用させていただきます。

なお、お客様からのアンケート結果に関しては、外部への公開等はございませんので、ご安心ください。

●アンケートの内容について

回答に関しては数値の高いものから減点方式となっております。

アンケート内容は英語で記載されていますが、下記の日本語訳を参考にご回答いただけますと幸いです。

なお、ご回答は英語ではなく日本語で記載いただくことも可能です。

①今回のケースにおけるMerakiサポートの全体的な対応にどのくらい満足しましたか。
　(0〜10で満足度の評価をお願いします。) また、その理由をお聞かせください。

②フィードバックいただきありがとうございます。
あと2分ほどお時間をいただき、追加のフィードバックを提供していただけますか。
(追加の質問にお答えいただくことが可能の場合は”Yes”を選択してください。)

③ケース対応に関して、次の点にどのくらい満足していますか。
　(0〜10で満足度の評価をお願いします。)
・サポートウェブサイトと問題解決への貢献度
・問題の解決
・Merakiサポートとのやり取りのしやすさ
・製品の品質と使いやすさ

④Merakiサポートエンジニアとのやり取りにおいて、次の点にどのくらい満足していますか。
　(0〜10で満足度の評価をお願いします。)
・プロフェッショナリズム
・対応の迅速さ
・技術的専門知識
・コミュニケーション

⑤Merakiサポートの対応のさらなる向上のため、私たちができることに関してご意見をお願いします。
　(記述式の自由解答)

⑥今回の問題について解決に至るまではどのくらい簡単でしたか。

⑦問題は解決しましたか。(解決した場合は'Yes'を、解決しなかった場合は'No'を選択してください。)

アンケートへご回答のご協力ありがとうございます。

本記事では、弊社ダッシュボード側でApple のDEP 端末を管理する際に使用されるトークンの

更新手順についてご紹介します。

なお、記事の途中で、Apple 側のポータルサイトの操作等の記載がございますが、

弊社サポートではApple 側に関するお問い合わせは対応出来兼ねますので、予めご了承下さい。

また、本記事ではApple Business Manager を使用しております。

1.

Meraki 側のダッシュボードにログインし、オーガナイゼーション>MDM をクリックしてください

2.

トークンの更新を実施したいApple DEPサーバをクリックしてください

3.

以下の様な画面が表示されるため、"トークンを更新する" をクリックしてください

4.

以下の様な画面が表示させるため、公開鍵証明書をダウンロードから、.pem 形式のファイルをダウンロードしてください

5.

Apple Business Manager にログインを実施してください

6.

設定> MDM サーバより、更新対象のトークンを選択し、編集をクリックしてください

7.
MDM サーバの設定より、手順4でダウンロードした.pem 形式のファイルをアップロードし、完了をクリックしてください。

8.

トークンのダウンロードを実行してください

9.

Meraki 側のダッシュボード画面に戻り、ダウンロードしたDEP トークンをアップロードしてください

10.

トークンの有効期限が延長されているかどうか確認をしてください

参考URL: Apple_Device_Enrollment_Program_(DEP)

本記事では、Apple's Push Notification Service (以下、APNS) の証明書の更新方法について

ご紹介させて頂ければと存じます。

また、本記事内でApple のポータル画面のスクリーンショットや操作等の記述がございますが、

弊社Meraki サポートではApple 側のポータルに関するお問い合わせはご対応出来兼ねますので、予めご了承下さい。

1.

Meraki 側のダッシュボードにログインし、オーガナイゼーション> MDM をクリックし、Appleプッシュトピック の値をコピーして、メモしてください

2.
Apple Push Certificates Portal にダッシュボードに紐づいているApple ID を使用して、ログインをしてください

3.
更新対象の証明書の "Renew" をクリックしてください

* 複数の証明書が登録されている場合、Renew の左にあるアイコンをクリックして頂き、手順1で確認した値とUID が一致するかどうかで確認を行う事が可能となります。

4.

Meraki 側のダッシュボードに戻り、オーガナイゼーション> MDM> Apple MDM> 更新/証明書を更新 をクリックしてください

5.

以下の様な画面に遷移するため、.csr ファイルのダウンロードを実施してください

6.
Apple 側のポータル画面にアクセスし、ダウンロードした.csr ファイルをアップロードしてください

7.

Download ボタンをクリックし、.pem ファイルのダウンロードを実施してください

8.
Meraki 側のダッシュボードに戻り、ダウンロードした.pem ファイルのアップロード及びApple ID を入力してください

9.
有効期限が延長された事とAppleプッシュトピック の値が手順1で取得した値と同一であるかどうかを確認してください

参考URL: Apple MDM Push Certificate

// 概要 //

Meraki機器において想定しない挙動や動作が確認された場合、事象原因の詳細調査にあたっていくつか確認依頼をさせていただく場合があります。

本資料ではその理由、及び取得が必要な情報についてまとめております。

// ユーザ側での情報取得が必要な理由 //

Meraki機器の性質上、機器がオンラインになっている場合にはMerakiサポート側にてクラウド経由での詳細なログ取得や、各機器でのパケットキャプチャの実施が可能です。

しかしながら、事象によっては上記情報のみでの解析が難しい場合があり、ユーザ側の情報取得を進める事で初めて調査を進められるようなケースがあります。

一例として、機器が実際に利用されている環境でしか取得出来ない情報があり、これには端末や上位機器でのパケットキャプチャ等があります。

これら情報は事象の根本原因がMeraki機器以外の箇所にあることの特定だけではなく、Meraki機器が想定通り動作していないことの確認のためにも利用されます。

またMerakiサポート側でのクラウド経由での情報確認のための前提が各機器がオンラインとなっていることであるため、

機器自体がオフラインになるような事象等に関しては、調査にあたってOut-of-Band Log Fetching（オフライン時のログ取得）が必要となる場合があります。

// 調査に必要となる主な情報について//

以下、事象発生における詳細状況や環境の確認が実施済みの前提となります。

また、もし既に事象が機器交換で改善している場合、弊社側の確認のため

一度オフラインにした機器を再度オンラインにしていただく場合がございます。

・事象の再現実施と、発生環境（対象クライアントのMACアドレス/IPアドレス、事象発生機器のシリアル番号等）情報

・事象再現時におけるパケットキャプチャ（有線（各通信経路）、モニターモードによる無線空間、クライアント端末等）

・事象再現時の、端末側での各操作やコマンド実施とその実施結果

・Meraki以外の機器での確認結果（例：事象発生時のRadiusサーバでのログ、端末側のログ情報）等

・その他、事象に関連する各設定等の情報

※対象事象に応じて上記以外の情報が必要となる場合もあります。

// その他ログに関しての事項 //

・機器再起動に伴うログの喪失について

Meraki機器のログにはいくつか種類があり、通常の機器の挙動のログは機器がオンラインになっている間に

クラウドに送信されダッシュボード上でイベントログ等で確認可能です。

（syslogサーバにログを転送している場合等も同様の考え方となります）

上記以外にも、機器正常性を記録するものや各機能における詳細履歴など、機器側にのみしか保存されないものもあり、

これらは弊社側でクラウド経由、もしくはOut-of-Band Logでのみ確認が可能です。

注意点としては機器の再起動によってこれらは一度リセットされるため、

確認のためには事象を再現させその状態にて確認する必要があります。

// 参考情報 //

Case作成時に必要な情報（問診票）
オフライン時のログ取得
クライアントマシンで無線空間のパケットキャプチャを取得する
無線パケットキャプチャについて

本記事では、MRにてSetup SSID が送信されない際、対処方法のについてご紹介させて頂きます。

MRがMeraki Cloudへアクセスできない場合(インターネットへアクセスできない場合）は、

Default SSIDとして以下のSSIDの内どちらかが送信されるようになります。

こちらのDefault SSIDのどちらかに接続することで、Local Status Pageにアクセスができ、固定IPや初期セットアップを行うことが可能となります。

「<SSID_name>-bad-gateway」

「<SSID_name>-connecting」

「<SSID_name>-scanning」

「Meraki Setup」

しかし、一部のMRにて上記のDefault SSIDが表示されないとの報告があり、

その場合は以下の手順を実施ください。

■ 手動で以下のSSIDに接続を行う。

「meraki-xx:xx:xx:xx:xx:xx」

　※ xをAPのMACアドレス(小文字)に変更していただく必要がございます。

■ 手動のSSIDでも接続ができない場合は、MRのFactory Resetを実施してください。

■ Factory Resetでも、SSIDが送信されない場合は、DHCP環境で一度Firmware upgradeを実施し、

  その後再度SSIDが送信されているかご確認ください。

参考URL

[Troubleshooting local connection issues using default SSID on MR Access Points]

https://documentation.meraki.com/MR/Other_Topics/Troubleshooting_local_connection_issues_using_defau...

本記事では、Meraki 製品における脆弱性の影響有無の確認方法について、ご紹介します。

Meraki 製品が脆弱性の影響を受けるかどうかは、以下の Cisco Security Advisories を

ご確認頂く事で確認する事が可能となります。

脆弱性毎に項目が分かれているため、確認をされたい項目をクリックして頂き、

Meraki 製品が影響を受けるのかどうかご確認を頂ければと存じます。

なお、英語と日本語のURL で内容が異なる場合、英語のURL の方が優先されますので、ご留意頂ければと存じます。

Cisco Security Advisories (英語版)

セキュリティ アドバイザリ (日本語版)

本記事では、クライアント端末で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

本記事では、MXのFirmwareを14.xxから15.xxへUpgrade後Non-meraki VPNとのトンネルが確立できない際の対処方法をご紹介させて頂きます。

MX 15以降ではMX内部の変化により、Non-Meraki VPNトンネルを確立する際、Remote ID パラメータを厳密に
チェックするようになっております。

以前のMX 14.xxでは、対向のPeerにて Local IDを設定している場合、 または NAT 配下である場合においても、
Remote IDが記載する必要はございませんでした。

しかし、MX 15以降では対向の Peer で Local ID を設定している場合、もしくは対向の Peer が NAT 配下にある場合には、
Remote IDに 該当Local ID(Peer が NAT 配下に存在する場合は、Private IP を Remote IDとして記載)を記載することが必須となりました。

また、同様に異なるOrganizationに存在するMX同士のVPN(Non-Meraki VPN)接続時につきましても
MX が NAT 配下にある場合は それぞれのRemote IDで、対向 Peerの Private IPを記載する必要がございます。

■ Remote IDの設定が必要な場合

・Remote Peer (ASA,AWS, Fortigate等）で明示的にLocal IDを設定している場合。

　例）abc@test.com, www.example.com

・Remote Peer (AWS,ASA,Fortigate等）がNAT配下に存在する場合。

　例）対向の Peer の Public IP が1.1.1.1, Private IP が192.168.1.1である場合、Private IP 192.168.1.1を

　　   Remote IDとして記載する必要がある。

・異なるOrganizationに存在するMX同士の場合でも Non-Meraki VPNを使うことになるため、

　同様に、対向の Peer でLocal IDを指定している場合は Remote IDを記載する必要がある。

　また、NAT配下である場合は、Private IP をRemote IDとして記載する必要がある。

■ Remote IDの設定が必要 ない場合

・対向のPeerで特にLocal IDを設定していない。

・対向のPeerはNAT配下ではなく、Public IP addressを使用している。

■ Remote ID、Local ID 設定ページ

・Security & SD-WAN >> Site to Site >> Organization-wide settings >> Non-Meraki VPN peers 

■ MX 15.xx リリースノート

Due to underlying changes present in MX 15, MX appliances will now strictly validate the remote ID parameter during VPN tunnel formation. 

If you notice issues with non-Meraki VPN tunnel connectivity after upgrading to MX 15 for the first time, 

please ensure the remote ID configured in the site-to-site VPN page for a given non-Meraki peer matches what is configured as the local ID on that device.

■ 参考URL

[Non Meraki Peers]

https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-Site_VPN_Settings#Non-Meraki_VPN_peers

本記事では、ホワイトリストやブロックリストに登録したMAC アドレスの確認方法についてご案内します。

// ホワイトリスト・ブロックリストへの追加方法 //

1. ネットワーク全体> クライアント> クライアントの追加 をクリック

2. 任意の名前とMAC アドレスを入力し、適用するポリシーを選択

3. クライアントの追加をクリック

// 登録したMAC アドレスの確認方法//

1. ネットワーク全体> クライアント をクリック

2. クライアント一覧のフィルターを'すべて' から "ポリシー設定済みのクライアントすべて" に変更

3. 登録したMAC アドレスが表示されるかご確認ください

※2025年1月現在、新しいUIでこのリストが確認できない事象が報告されているため、

クライアントリストページの右上の[古いバージョンを見る]から古いUIでご確認いただければと存じます。

ローカルステータスページにアクセスができない際の対処方法についてご紹介させて頂きます。

Meraki機器の初期状態では、

機器にPC等を接続し、Webブラウザより機器のLAN IPアドレスまたはURLを入力の上、

Usernameは機器のシリアル番号、Passwordは空白でログインすることができるかと思います。

しかし、一度Meraki Cloudに接続行った場合は該当ネットワークの設定をダウンロードするようになりますので、

設定によっては完全にアクセスできなかったり、ログイン情報が変わってしまい初期のシリアル番号ではログインできない場合がございます。

詳細な対処方法につきましては、以下をご確認いただければと思います。

■LAN接続からローカルステータスページへアクセスができない際対処方法

ネットワーク全体 >> 一般 >> 機器の設定にて以下の設定を確認

①ローカル機器のステータスページ　→有効化 (Local status pageにアクセス有効・無効の設定)

②リモート機器ステータスページ　→有効化 (機器のLAN IPからLocal status pageへアクセス許可・拒否)

③ローカルの認証情報　→こちらのユーザ名とパスワードでローカルステータスページへログイン

■リモートのPC端末からMXのローカルステータスページ(MXのPublic IP)へアクセスができない際対処方法。

①上記の同様に以下の設定が有効化されているか確認する。

・ローカル機器のステータスページ

・リモート機器ステータスページ

②セキュリティ & WAN >> ファイアウォール >> セキュリティアプリアンスサービス >> Web（ローカルステータスと設定にて

　「許可されたリモートIP」に該当IPアドレスが許可されているか確認する。（Anyと記載する場合、全てのリモートIPから接続を許可する)

③MXがNAT配下に存在する場合、上位装置にてTCP 80 portがMXへPort Forwardingされているか確認する。

//////参考URL//////

[Using the Cisco Meraki Device Local Status Page]

https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Me...

本記事では自動ファームウェアアップグレードについてご紹介させていただきます。

■自動ファームウェアアップグレードとは？

Merakiでは安定したサービスを提供するために、Firmware Upgradeのスケジュールを登録する場合がございます。

MerakiによるFirmware Upgradeのスケジュールは、スケジュールされている日より1~2週間前には管理者へメール及びDasboardのバナーより通知されるようになります。

またMerakiより設定されたスケジュールは、都合に応じて延期することも可能です。

■通知メールサンプル

件名：Scheduled maintenance for network "test - appliance" in organization My Home NW

本文：以下の添付をご参照ください。

また自動ファームウェアアップグレードにつきましては、以下のいくつかの特徴がございます。

■現在ネットワークのFirmwareタイプに応じた自動スケジュール。

現在ネットワークで設定しているファームウェアのタイプ(安定版、安定版候補、Beta)に応じて、スケジュールされるファームウェアも異なります。

例えば、現在ネットワークのファームウェアが安定版(Stable)が設定されている場合には、

新たな安定版(Stable)バージョンがリリースされる場合に限り、安定版(Stable)のファームウェアがスケジュールされるようになります。

※ただ、安定版候補の場合、全体のノードが概ね20%以上となったタイミングに限り、

　安定版(Stable)へ最終的なレビューが行われるため、

　一部の安定版(Stable)のネットワークにおいては、安定版候補とスケジュールされる場合がございます。

■Organization単位ではなく、ネットワーク単位でスケジュール。

自動ファームウェアアップグレードは、ネットアーク単位でスケジュールされるため

Organization内の全てのネットワークが、同様の日にスケジュールされない場合もございます。

■デバイスが1つも登録されていないネットワーク。

ネットワークにデバイスが1つも登録されていない場合は、1~2週間後のスケジュールで設定されることはなく、即時で設定される場合がございます。

■新たなファームウェアのリリース直後にスケジュールされるわけではない。

新たなファームウェアがリリースされた直後、すぐに自動ファームウェアアップグレードがスケジュールはされません。

セキュリティーや、Uptime、互換性等の要因によって、自動ファームウェアアップグレードの設定されるまで、数週間かかる場合がございます。

■自動ファームウェアアップグレードを無効化することはできない

Merakiでは、安定したサービスを提供するために自動ファームウェアアップグレードを実施しており、

設定されているスケジュールを管理者が延期することはできますが、完全に無効化することはできません。

※参考URL

[Best Practices for Meraki Firmware]

https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/...

本記事では、弊社クラウド側に障害が発生している事を確認できるページについてご紹介いたします。

以下の様な影響範囲の大きい障害が発生した場合、こちらのURLより、

弊社側の障害発生有無をご確認頂く事が可能となります。

また、本ページは日本チームで管理をしておりますので、平日の17時以降・土日に関しては

更新が行われない場合がございますので、予めご了承ください。

上記のページが更新されておらず、事象が発生しているかどうかをご確認されたい場合には、

弊社サポート窓口よりケースまたはお電話にてお問い合わせを頂ければと存じます。

Cisco Meraki テクニカルサポート

本記事では、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)

本記事では、異なるOrganization間でライセンスを移行する方法につてご紹介させていただきます。

ライセンスを異なるOrganization間で移行するためには、

移動元と移動先のOrganizationのライセンスモデルが一致する必要がございます。

ライセンスモデルが異なる場合は、Organization間でライセンス移行は不可となります。

例）Co-term <—> Co-term , PDL <—> PDL ライセンス移動可能。

      Co-term <—> PDL 移動不可。

■ PDL (Per device license)からPDLへのライセンスの移行方法。

以下の手順よりライセンス移行が可能となります。

①Organization >> inventory >> Licenseにて該当ライセンスを選択

②Action >> Change Organization

③移動先のOrganizationを選択

④移動先・元Organizationで、ライセンス移行が正しく行われているか確認。

※ライセンス移行を操作する管理者は移動先及び移動元両方のOrganizationの管理者である必要がございます。

※ライセンスがデバイスに紐づいている場合、移行を行うとデバイスとライセンス両方とも移行されます。

■ Co-terminationからCo-terminationへのライセンス移行方法。

ユーザーはこのライセンスモデルではOrganization間で移行できませんので、

サポートへライセンス移行をリクエストする必要がございます。（新規ケースをオープンする必要がございます。）

リクエスト時必要な情報は以下となります。

　移動元のOrganizationのsupport passcode

　移動元のOrganization名

　移動元のOrganizationのURL

　移動対象のライセンスKey・数

　移動先のOrganizationのsupport passcode

　移動先のOrganization名

　移動先のOrganizationURL

※リクエスト依頼者は、移動元及び移動先のOrganizationの管理者である必要がございます。（Full-access)

参考URL

[How to Request a License Transfer]

https://documentation.meraki.com/General_Administration/Licensing/How_to_Request_a_License_Transfer

[Meraki Per-Device Licensing Overview]

https://documentation.meraki.com/General_Administration/Licensing/Meraki_Per-Device_Licensing_Overvi...

本記事ではiOS端末からQRコードのスキャンができない際の対処方法についてご紹介させていただきます。 

■トラブル

iOS 14以降の端末で、Profile Restrictionを使用している場合、QRコードのスキャンができない場合がある。

■対象方法

アプリを表示または非表示にて、「com.apple.barcodesupport.qrcode」を追加する必要がある。

■詳細手順

①システムマネージャー >> 設定 >>

②該当プロファイルを選択 >>

③Restrictionタブを選択 >>

④アプリを表示または非表示にて、「com.apple.barcodesupport.qrcode」を追加する。

⑤再度Profileをインストールし、該当デバイスから再起動を行う。

以上となりますが、もし、上記の手順を実施してもQRコードのスキャンができない場合はサポートへ

新規ケースを作成するようお願いいたします。

本記事では、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)

本記事では、最近弊社サポートにお問い合わせの多いMR のリンクスピードが100 Mbps になる事象について紹介をします。

上記の様な事象が発生した場合、まず以下の切り分けを実施して頂ければと存じます。

- 別ポートに接続した場合、事象が改善されるかどうか

- 別ケーブルを使用した場合、事象が改善されるかどうか

- 別機器を該当AP が元々接続されていた機器に接続した場合、事象が発生するかどうか

別のポートやケーブルでも100Mbps で動作してしまう場合や

別の機器では元々AP が接続していたポートでは、1Gbps で動作する場合、

該当AP に何らかの問題が発生している可能性が考えられます。

もし、上記の切り分け後でも事象が改善されない場合、

AP とEthernet ケーブルとの間にアダプターを使用している環境かどうかご確認ください。

弊社事例において、アダプターを強く差し込む事により、

AP のEthernet ポートの両端のPin が沈む事例が報告されており、100Mbps で動作する可能性がございます。

また、その他報告されている事例としては、以下の事象がございます。

- 有線接続しているにも関わらず、AP がRepeater モードで動作する

- AP を少し動かすとケーブル(アダプター)が抜けてしまう

現在事象が発生する事が報告されているアダプターについて確認が必要な際には、ダッシュボードより

弊社サポートへ本記事のURL を添えて、ケースオープンをして頂ければと存じます。

本記事では、デバイスタイプ別にグループポリシーを割り当てできる機能の詳細についてご紹介させていただきます。

■デバイスタイプ別にグループポリシーを割り当てる機能とは？

デバイスがSSIDに接続される際、デバイスタイプによって異なるグループプリシーを適用することができる

機能となります。

例えば、iPhoneはWhitelist policyを、Android Deviceにはblockedを

Windows OSにはCustom policyを適用するというようなことが可能です。

■デバイスのOS識別方法

APはデバイスのHTTP GET Packet内のUser-Agent Fieldを確認し、

デバイスのタイプを判断し、それぞれに応じるポリシーを適用するようになります。

APはクライアントのUser-Agent Fieldに依存するためベストプラクティスとして動作するようになります。

※一部のクライアントは、誤った情報を識別してしまうことがあり、結果としてAPは正しくないポリシーを適用する場合があります。

　この場合は、System ManagerやCisco ISEを活用していただくか、

　ネットワーク全体 >> クライアントページよりマニュアルで該当クライアントのポリシーを再度適用してください。

■設定方法

①ワイヤレス >>アクセス制御に移動

②デバイスタイプ別にグループポリシーを割り当て項目にて、本機能を有効とする

③デバイスタイプのグループポリシー追加をクリックし、デバイスタイプごとにポリシーを設定する。

参考URL

https://documentation.meraki.com/MR/Group_Policies_and_Block_Lists/Applying_Policies_by_Device_Type

本記事では、PDL のライセンスモデルにおいて、既存の機器の更新に関して、ご紹介します。

PDL のライセンス更新では、特定の機器に既に適用されているライセンスの期限を更新する様な動作となります。

そのため、2つのライセンスを1つにする様な動作となります。

特定のライセンスに対して、更新を実施すると、一度 recently queued のステータスとなります。

recently queued の状態が、7日間継続すると、2つのライセンスキーは1つのライセンスキーに統合される様な形となります。

また、適用から7日以内であれば、 Undo queue を実施する事により、更新の作業を取り消す事が可能となります。

recently queued が7日以上経過したライセンスは、以下の様に合算された形で表示されます。

この状態になってしまうと、Undo queue を行う事はできず、ライセンスを適用前の2つの状態にするという事は不可となります。

参考URL

Meraki Per-Device Licensing - Configuration