弊社で利用しているサードパーティベンダーにおいて問題が発生し、 弊社 Cisco Meraki を含む一部の顧客に対して 証明書の更新を要求していることが判明いたしました。 これに伴い、Meraki Cloud 認証で使用される RADIUS 証明書の更新を 2024年8月2日 10:30 JSTに実施いたします。 証明書の更新が完了すると、推奨される対応を実施しない場合、 特定のデバイスが Meraki Cloud 認証を正常に行えなくなるため、 下記のページをご参考にしていただき、ご対応を行なっていただければと存じます。 [2024年7月末に行われるMeraki 認証サーバー用証明書の更新について] https://documentation.meraki.com/SM/Other_Topics/Meraki_Authentication_Server_Certificate_Rotation_-_July_jp また、Meraki Cloud Authentication証明書更新に対して、 その他ご不明な点等がございましたら、サポートまでご連絡ください。 https://meraki.cisco.com/meraki-support/overview/ ... View more

本記事では、最新安定版Firmwareを推奨する理由及び Firmware version status について説明させていただきます。   ◼︎最新Firmwareを推奨する理由 Meraki Productは潜在的な危険性及び下記の理由等により 常に最新のファームウェアのバージョンを保つことを強く推奨しております。 セキュリティーの脆弱性 セキュリティー関連の脆弱性が確認された場合、 弊社の開発側では最新のファームウェアにて優先的に修正を行います。 そのため、最新Firmwareではないバージョンの場合、 修正対応が遅れる、また、場合によっては修正されない可能性もございます。 既知及び新たに確認された事象の修正対応 弊社の開発では、既知及び新たに確認された事象に対して、 セキュリティー関連の脆弱性の対応と同様に 最新のファームウェアにて優先的に修正を行なっております。 特にソフトウェアに起因する事象の場合、 最新の安定版ファームウェアで事象の再現性を確認する必要があり、 古いファームウェアではBest effort対応となり、修正されない場合がございます。 パフォーマンス低下 Merakiでは、常にパフォーマンス向上のために 努力を重ねており、新しくリリースされたファームウェアにて 最大のパフォーマンスを発揮します。 そのため、古いファームウェアでは、予期せぬパフォーマンス低下の問題が 発生する可能性がございます。 新しい機能の利用 Merakiではユーザー様へ多様な環境及び要望に応じるために、 常に新機能の実装を行なっております。 しかし、こちらの新しい機能は古いファームウェアままでは利用が不可なため、 必要に応じて、最新の安定版またはBeta版等へアップグレードをしていただく必要がございます。   ◼︎ファームウェアのステータス Merakiではより簡単にFirmware versionが管理できるように Firmware versionを3つのステータスで区分しております。 Good (Green)🟢 こちらのステータスは現在のFirmware versionには特に問題がない状態で、 すぐにバージョンアップグレードの対応は不要な状態となります。 また、現時点で該当Firmwareは EFM(End of Firmware Maintenance)の見込みがない もしくはEFMとなるまでに6ヶ月以上余裕がある場合「Good (Green)」と表示されます。 ただし、アップグレードが可能なマイナーバージョンはある場合がございますので、 リリースノートをご確認に上、必要に応じてアップグレードをご検討していただければと思います。 Warning (Yellow)🟡 こちらのステータスは現在のFirmware versionに対して、 6ヶ月以内で、EFM(End of Firmware Maintenance)になる際に、表示されるステータスとなります。 現時点ではまだ該当ファームウェアがEFMにはなっておりませんが、 近い内(180日以内)にEFMとなるため、アップグレードが可能な最新のバージョンを確認の上、 アップデートを推奨します。 また、Warningと横に記載されている日付が該当Firmware versionがEFMとなる日付となります。 Critical (Red)🔴 こちらのステータスは現在利用中のFirmware versionが、 すでにEFMとなった際に表示されるステータスとなります。 EFM(End of Firmware Maintenance)となったFirmwareにつきましては、 セキュリティー関連の脆弱性やパフォーマンス低下の恐れがございますので、 直ちにアップグレードを行っていただくことを強く、推奨いたします。     参考URL [Firmware Version Status] https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Managing_Firmware_Upgrades#Firmware_Version_Status ... View more

本記事では、1つのAPに複数のクライアントが集中してしまう際に考えられる原因と 有効な対処方法について紹介させていただきますので、参考にして頂ければと思います。   ■端末が接続するAPを判定する基準 端末は機種によって少し差異はありますが、一般的には該当端末にて 受信できる電波強度(RSSI:Received Signal Strength Indicator)によって接続するAPを判断するようになります。 そのため、複数のAPより同様のSSIDが確認できる際は端末自身の現在の位置より一番強い電波が受信できるAPへ接続を試すようになります。   ■多数のクライアントが1つのAPに集中してしまう原因 //周囲の他のAPの電波強度が強い場合、または接続を意図したAPの電波が弱い場合// 　上記にも説明させていただきました通り、端末は受信できる 　電波強度より接続するAPを選択するため、無線環境において、接続を意図していない周りのAPの電波が強い場合、 　もしくは本来接続されるべきのAPの電波が弱い場合は、端末が意図したAPに接続されず、1つのAPに集中してしまう場合があります。 //CoverageのOverlappingエリアが正しく選定されていない場合// 　ローミングは、最初接続されているAPから端末が物理的に移動を行い、 　最初接続を行った電波信号が弱くなったタイミングで、他のAPへローミングが行われるようになります。 　しかし、CoverageのOverlappingエリアが広い場合、 　端末は移動を完了したものの、端末にて受信できる電波信号が、 　ローミング判定となるdBmまで減少していないためローミングは行われず、既存のAPに接続したままとなります。 　その結果、比較的に1つのAPの端末が集中されてしまう場合があります。   ■多数のクライアントが1つのAPに集中してしまう際の有効な対策 //端末がAPに接続を行う場所にて、無線サーベイを行い、再度各APの電波強度を見直す// 　APへの接続は端末にて受信できる電波強度により、 　判断されるため、接続を意図したAPの電波強度を上げたり、 　接続を意図していないAPの電波強度下げることで、改善される場合があります。 　電波強度の設定は下記のページで設定可能です。 　ワイヤレス >> 電波設定 >> ターゲット出力 　 　[Manual Power] 　https://documentation.meraki.com/MR/Radio_Settings/Transmit_Power_and_Antenna_Configuration#Manual_Power //端末側のローミング設定を変更する// 　端末側の設定でローミングの感度(Roaming Aggressiveness)を変更することで、 　よりローミングがしやすくなり、結果的に1つのAPの集中する問題の改善できる可能性があります。 　 　こちらの詳細については、以下のKBをご参照して頂ければと思います。 　[クライアントのローミングおよび接続の決定に関する説明] 　https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Client_roaming_and_connectivity_decisions_explained_jp 　 //APの物理的な移動、またはAPの増設を検討する// 　端末が接続を試す場所にて、複数のAPの距離が近すぎる場合 　どのAPの電波も強く受信するため、場合によっては特定のAPの偏ってしまう可能性があります。 　また、端末がAPへ接続を試す際、逆に該当APが端末の位置から遠すぎる場合も同様に意図したAPに接続されないため、 　APの物理的な移動や、増設、端末が接続を行う場所の変更等をご検討して頂ければと思います。 　 //クライアントバランシングを有効とする// 　こちらの機能を有効にしていただくことで、クライアントが接続を試す際、 　APの負荷状況により、ベストAPに接続が行われるように誘導することが可能です。 　また、MR firmware 29.xx以降で、802.11vサポートする 　端末の場合は、接続後もアクティブにこの機能が働くため、 　より良いAPへ常に端末を優度するようになります。 　クライアントバランシングは下記のページで設定可能です。 　ワイヤレス >> 電波設定 >> 該当RFプロファイル選択 >> クライアントバランシング >> オン 　 　[Client Balancing] 　https://documentation.meraki.com/MR/Other_Topics/Client_Balancing   ... View more

本記事ではMAC Flap Detection機能の検出条件及び、実際にL2ループが発生したいない場合においても 本MAC address flappingログが記録される例をご紹介させていただきます。   ■MAC Flap Detectionとは? MAC Flap Detection機能はMAC address forwarding tableを通じて、 短時間で同一のMACアドレスが複数のポートにて検出された際、その情報をイベントログに記録し、 潜在的なループを防ぐための機能となります。   ■MAC Flappingと判断する基準 「同一のMACアドレスが、10秒以内に、異なる2つ以上のポートにて、3回以上検出された際」   ■サポートモデル及びバージョン サポートモデル MS130/MS120/MS210/MS225/MS250/MS350/MS355/*MS390/MS410/MS420/MS425/MS450 サポートバージョン MS12.8以降 *MS390の場合は、MS15.14+よりサポートしております。    ■ 一般的にMAC address flappingがイベントログに記録される例  ①スイッチの1番ポートにPC(MAC AA:AA:AA:AA:AA:AA)が接続されている。 ②L2 ループ発生によりPC(MAC AA:AA:AA:AA:AA:AA)のMACアドレスが短時間で、ポート2,3でも検知される。 ③MSはForwarding table情報を参考し、イベントログに下記のMAC address flappingが記録する。   ■頻繁なローミングによるMAC address flappingイベントログ記録例 ①AP1に接続されていたPCが短時間でAP2,3へローミングを行う場合 ②AP1に接続されていたPCが短時間で、AP2へローミングし再度AP1にローミングする場合   ■参考URL Loop and MAC Flap Detection on MS - Cisco Meraki https://documentation.meraki.com/MS/Monitoring_and_Reporting/Loop_and_MAC_Flap_Detection_on_MS   ... View more

本記事では、WEBブラウザ（Chrome）でHARキャプチャーの取得方法を動画にてご紹介させていただきます。     ■HARキャプチャーの取得方法     作成時使用したChrome Browser version : 103.0.5060.114 ①　再現するページを開きます。 ②「F12」を押下し開発者モードを開きます。 ③「NETWORK」タブをクリックします。 ④　HAR キャプチャーが開始されていることを確認します。 　※丸いボタン(●)が赤くなっていると、キャプチャー中となります。 ⑤　事象を再現させます。 ⑥　事象の再現が完了しましたら、Export ボタンを押下し、HAR ファイルをダウンロードします。     ... View more

無線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_Interference 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_Wireless_Signal_Strength ・適切なローミング 　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   ... View more

本記事では、モニターキャプチャーの取得方法を動画にてご案内いたします。 ※モニターキャプチャーを取得するためには、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 ... View more

本記事では、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   出力例 ... View more

本記事では、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_default_SSID_on_MR_Access_Points ... View more

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

ローカルステータスページにアクセスができない際の対処方法についてご紹介させて頂きます。   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_Meraki_Device_Local_Status_Page#Controlling_Remote_Access_to_the_Local_Status_Page   ... View more

本記事では自動ファームウェアアップグレードについてご紹介させていただきます。   ■自動ファームウェアアップグレードとは？ 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/Best_Practices_for_Meraki_Firmware   ... View more

本記事では、異なる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_Overview#Moving_Licenses_and_Devices ... View more

本記事ではiOS端末からQRコードのスキャンができない際の対処方法についてご紹介させていただきます。    ■トラブル iOS 14以降の端末で、Profile Restrictionを使用している場合、QRコードのスキャンができない場合がある。   ■対象方法 アプリを表示または非表示にて、「com.apple.barcodesupport.qrcode」を追加する必要がある。   ■詳細手順 ①システムマネージャー >> 設定 >>   ②該当プロファイルを選択 >>   ③Restrictionタブを選択 >>   ④アプリを表示または非表示にて、「com.apple.barcodesupport.qrcode」を追加する。     ⑤再度Profileをインストールし、該当デバイスから再起動を行う。     以上となりますが、もし、上記の手順を実施してもQRコードのスキャンができない場合はサポートへ 新規ケースを作成するようお願いいたします。 ... View more

本記事では、デバイスタイプ別にグループポリシーを割り当てできる機能の詳細についてご紹介させていただきます。   ■デバイスタイプ別にグループポリシーを割り当てる機能とは？ デバイスが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 ... View more

本記事では、アプリまたはProfileがインストールできない際、まず確認必要がある項目についてご紹介させていただきます。   ①該当アプリ、ProfileページからデバイスがScope内であることを確認します。 　・アプリ（システムマネージャ >> アプリ >> 該当アプリを選択 　・Profile (システムマネージャ >> 設定 >> 該当Profileを選択) システムマネージャ >> デバイス >> デバイス詳細ページにて上記のようなStatusが表示されていない場合は、 該当端末は、Scope内ではない可能性が高いです。   ②アプリ・Profileをアップデートまたはインストールしてから、 該当端末がインターネット(Meraki Cloud)へアクセスができるかご確認ください。   ③以下のオンラインステータスページ(デバイスの詳細ページ)より、 アプリ・ProfileををPushしてから、チェックインが行われているかご確認ください。    チェックインが行わっていなければ「今すぐチェックイン」ボタンを押してください   ④該当デバイスがロックされていないか・電源ONになっているかご確認ください。(アプリ・Profile両方)   ⑤該当デバイスの詳細ページにて、該当アプリの活動ログを確認してください。(アプリのみ) 　例えば状態がpendingの場合は端末がまだMeraki Cloudにチェックインしていないことを示します。   ⑥該当デバイスのiTuneアカウントで支払い方法が設定されているかご確認ください。 　無料のアプリの場合でも支払い方法を選択が必要な場合がございます。 　(アプリのみ、VPP Device Licenseの場合は不要）   ⑦該当デバイスの詳細ページのProfile項目より、該当Profileがインストールされているか、 　または最新Versionであるかをご確認ください。(Profileのみ) 　Profileがインストールされていない場合、あるいは最新Versionではない場合は 　「不足/更新プロファイルをインストール」をクリックしてください。   ⑧上位FWや、Proxy ServerでMeraki Cloudへアクセスを拒否するようなルールはなく、 　それでも正常にMeraki Cloudへチェックインが行われない場合は、 　System Managerアプリを該当デバイスから削除、該当デバイスをネットワークから削除していただき、 　再度ご登録をしチェックインが行われるかご確認ください。   上記の全てを確認してからも正常にアプリまたはProfileがインストールできない場合はMeraki Technicalサポートまで お問い合わせください。   [Managed device does not receive deployed app or settings profile] https://documentation.meraki.com/SM/Profiles_and_Settings/Managed_device_does_not_receive_deployed_app_or_settings_profile ... View more

本記事では、Schedule tag及びGeofencing tagについてご紹介させていただきます。 Schedule tag及びGeofencing tag両方とも該当タグを利用し、アプリやプロファイルの適用を制御することができます。     Schedule tagとは 指定している時間範囲内、範囲外で アプリまたはプロファイルをインストールまたはアンインストールすることができます。 例えは、スケジュールを平日09:00 ~ 17:00と設定し、ご希望のアプリやプロファイルを紐付けると、 09:00 ~ 17:00間ではアプリやプロファイルが有効(インストールされる）ですが、 時間外となると、アプリや、プロファイルが削除されるようになります。   Geofencing tagとは 指定した場所に端末が位置しているか、していないかによって、 アプリやプロフィルのインストール、アンインストールすることができます。 Geofencing tagを作成し、特定の場所を指定した際、 端末がその場所に位置する場合は、準拠デバイス(compliant)tag 端末がその場所に位置しない場合は、違反デバイス(violating)tagというオートタグが付与されるようになります。 これらのタグを利用し、ご希望のアプリやプロファイルを紐づけ、 場所によって該当アプリや、プロファイルの制御することが可能となります。     Schedule tagの設定方法 ①システムマネージャー　>> タグ >> +タグを追加    ②スケジュールタグを選択し次へ >> 新規スケジュールを作成。   ③システムマネージャー >> デバイスより、チェックインを行い、端末がMDMサーバへ到達できるか確認を行う。   ④以下のページより、端末が正常に登録されているか確認する。   ⑤ご希望のアプリや、プロファイルを紐付ける。   ⑥指定している時間によって、アプリや、プロファイルがインストール、またはアンインストールされるか確認する。       Geofencing tagの設定方法   ①端末側で、GPSより位置情報取得が許可がされているか確認する。 端末のGPS設定方法はこちらの記事を参照してください。   ②システムマネージャー >> ジオフェンシング >> +新規追加   ③名前と、デバイスの適用範囲、猶予期間を設定する。 ④ご希望の新規場所を追加し、保存する。   ⑤システムマネージャー　>> タグ >> ジオフェンシングにて、準拠デバイス、違反デバイスを確認する。   ⑥準拠デバイスまたは、違反デバイスタグにご希望のアプリやプロファイルを紐付ける。     ⑦端末の位置によって、紐づいているアプリや、プロファイルがインストール、またはアンインストールされるか確認する。     [Schedule Tag] https://documentation.meraki.com/SM/Tags_and_Policies/Tags_Management_Page_for_Systems_Manager#Schedule_Tag   [Geofencing with Managed Devices] https://documentation.meraki.com/SM/Tags_and_Policies/Geofencing_with_Managed_Devices   ... View more

本記事では、Passcode Payloadについてご紹介させていただきます。 Passcode Payloadは、MDMより管理しているデバイスに対して、ユーザ側でパスワードや、パスコードを設定する際、必要な要件を指定することが可能な機能となります。   ※リモートから管理しているデバイスのパスコードやパスワードを直接設定するような機能ではありません。   設定可能なパスコード項目は以下となります。   ■簡単な文字列を許可 簡単な文字列の入力を許可します。例）1111, 1234, abcdなどなど   ■1つ以上の英数字の組み合わせ必須 英数字の組み合わせが必須となります。例）数字のみ1111, アルファベットのみabcdは入力不可。   ■ 最小長 パスコードの長さは、指定の長さ以上である必要があります。(0~14).   ■最小特殊文字数 最小特殊文字数以上の特殊文字を入力する必要があります。(0~4).   ■パスコードの最大有効期間 パスコード変更要求が行われない最大有効期間を指定します。 0から730まで設定が可能となります。（1 = 1日）   ■自動ロック 自動ロックがかかるまでの時間を指定します。   ■パスコード入力の失敗回数制限 パスコード入力の失敗回数を指定することが可能となります。 (4~10)   iOS オプション ■デバイスロック解除後、パスコード猶予時間 デバイスロック解除後、再度パスコードを入力を行われなくても良い時間。   ■パスコード履歴 再利用が不可能な以前のパスコード数( 1 ~ 50 )   ■Touch ID ユーザーにTouch ID設定の変更を許可   Androidのオプション ■仕事用プロファイルのみロックする。   -----------------------設定方法は以下をご参照くださいませ。-----------------------   システムマネージャー >> 設定 >> 該当Profileを選択     ＋設定を追加 >> パスコードポリシー     ご希望のパスコードポリシーを設定し、保存する。     [Systems Manager Passcode Payload] https://documentation.meraki.com/SM/Profiles_and_Settings/Systems_Manager_Passcode_Payload ... View more

本記事では、System Managerの管理設定のみ削除(Selective wife)及びデバイス初期化(Erase Device)について ご紹介させていただきます。   ■管理設定のみ削除コマンド 該当端末をFactory Resetすることはなく、 SMよりインストールされているProfile、Appを削除することが可能なコマンドとなります。 管理設定のみ削除コマンドは、主にBYOD(各々の端末を持ってきて使う)の環境で、 該当DeviceがそのOrganizationに所属から離れる際、よく使われます。   ■デバイス初期化コマンド 該当端末をFactory Resetすることになります。 本コマンドはSMよりインストールされたProfile、Appはもちろん端末のContentsや設定等全てが初期化され 工場出荷時の状態になります。     「管理設定のみ削除コマンド」は以下のどちらの方法でも実行可能となります。    ①Client Listにより システムマネージャー >> デバイス >> 隔離 >> 管理設定のみ削除   ②Client Details pageにより システムマネージャー >> デバイス >> 該当デバイス選択 >>MDMコマンドにて「管理設定のみ削除」     デバイス初期化コマンドは以下から実行可能となります。 System Manager >> Device >> 該当Device選択 >>MDMコマンドにて「デバイスを初期化」   Selective Wife and Device Quarantine in System Manager https://documentation.meraki.com/SM/Monitoring_and_Reporting/Selective_Wipe_and_Device_Quarantine_in_Systems_Manager   Using Systems Manager to Locate a Missing or Stolen Device https://documentation.meraki.com/SM/Monitoring_and_Reporting/Using_Systems_Manager_to_Locate_a_Missing_or_Stolen_Device   ... View more

本記事では、Gateway Mode AP及び、Repeater Mode APについてご紹介させていただきます。   LANに接続され、インターネットへの経路を持っている場合MRは基本的にGateway Modeとなります。 このModeは、Dashboard上で意図的にRepeater Modeへ設定、Gateway Modeへ設定することはできず、 以下のどちらの場合に当てはまる場合、Gateway ModeからRepeater ModeへFailoverするようになります。   ・接続されているLANのデフォルトゲートウェイからARP応答がない場合。 ・DHCPから有効なIPアドレスが取得できない場合。 　※条件：周囲にインターネットへアクセスができる他のMRが存在している   以下のAPページの一覧から、現在のAPモードを確認することができます。 Wireless >> Access points     Gatewayの項目で(self)となっているAPは現在Gateway Modeとなります。 Gatewayの項目で他のAPのホスト名となっているAPは現在Repeater Modeとなります。     Gateway Mode APになる想定のMRがRepeater Modeになる場合に対処方法 ・APの代わりにPCを接続し、DHCPから正しいIPが取得できるか、Default GWへPing疎通ができるか確認する。 ・DHCPから正しいIPアドレスが取得できない場合、DHCPサーバの正常性及設定を確認する ・Default GWからARP応答がない場合、Default GWの正常性及設定を確認。   関連URLは以下となりますので、必要に応じてご参照していただければと思います。 [Gateway AP switches to Repeater Mode] https://documentation.meraki.com/MR/Monitoring_and_Reporting/Gateway_AP_Switches_to_Repeater_Mode       ... View more