エンタープライズ向け Meraki 無線のベスト プラクティス - アーキテクチャ
このドキュメントは原文を 2025年09月02日付けで翻訳したものです。
最新の情報は原文をご確認ください。
はじめに
Cisco® Meraki は、Cisco が提供するベストインクラスのクラウド管理型ネットワーク製品です。無線業界を25年にわたりリードして得た RF の卓越性と Cisco IOS® XE および AireOS ソフトウェアを、クラウドのシンプルさとスケーラビリティと組み合わせています。
AireOS WLC や Cisco Catalyst 9800 などの無線 LAN コントローラ（WLC）でアクセスポイントを管理する従来方式と比べて、Meraki アクセス ポイント（MR）は Meraki ダッシュボードを介してクラウドから直接管理されます。これにより、お客様はネットワークに VPN 接続することなく、単一のクラウド アプリケーションで複数サイトにまたがる無線ネットワークをどこからでも管理できるようになります。
本ドキュメントでは、大規模エンタープライズ向けに Meraki 無線ネットワークを構成・導入する際の推奨ベスト プラクティスを取り上げます。ここでの目的は、ほとんどの無線ネットワーク実装に適用できる共通の設定を提供することにあります。ただし、すべてのネットワークが同じではないため、一部の推奨事項がお客様のネットワークに当てはまらない場合があります。実運用ネットワークに変更を加える前に、必ず検証してください。
Meraki 無線の大規模キャンパス設計
分散データ プレーン アプローチ
大規模キャンパスの展開では、Meraki 無線は 1 つの Meraki ネットワークあたり最大 800 台の AP と 1 万クライアントでのシームレスかつ高速なローミングに対応する形での導入を推奨します。Meraki 無線の導入は分散データ プレーン アプローチを採用しており、すべての MR アクセス ポイントが無線トラフィックをローカルでスイッチしてネットワークの他の部分へ転送します。これは Cisco AireOS または Catalyst 9800 WLC を用いた FlexConnect 展開に似ています。
分散データ プレーン アプローチの主な利点の 1 つは、各 AP が自身の無線トラフィックをすべてローカルでネットワークへスイッチするため、Wi‑Fi 6E 以降の新しい Wi‑Fi 規格のスループット需要に対応できることです。集中スイッチ型の WLC ベースの展開ではスループットが WLC によって制限されますが、分散無線ネットワークの総スループットはアクセスポイントの台数に応じて拡張され、基盤となるスイッチング アーキテクチャによってのみ制限されます。
さらに、Meraki は分散データ プレーンとクラウドベースのデバイス マネージャを活用するため、多くの場合 WLC を必要とせず、ネットワークに導入すべき機器を削減できます。Meraki ダッシュボードがネットワーク内のすべてのデバイスを管理および監視するため、導入に必要なのは MR アクセス ポイントのみです。
ただし、分散データ プレーン アプローチを使用する場合は、ローミング ドメインおよびスイッチング アーキテクチャに関して、より綿密な計画が必要になります。
スイッチング アーキテクチャ
基盤となるスイッチング アーキテクチャを設計する際、AP に接続されるアクセス スイッチのポートは次の推奨事項に従ってください。
- ポートはトランク ポートとして構成し、AP が無線トラフィックを有線ネットワークにスイッチする際に複数の VLAN を通過できるようにします。
- AP の管理トラフィック用 VLAN と、ブロードキャストされる各 SSID 用の VLAN がポートで許可されていることを確認します。
- MR のゼロタッチ プロビジョニングのため、トランク ポートのネイティブ VLAN を AP の管理 VLAN に設定します。
- ポートは Spanning Tree Portfast Trunk、BPDU Guard、Root Guard を有効化して構成します。
詳細については、こちらを参照してください。
同じスイッチに有線クライアントが接続されている場合、有線クライアントに関連付けられた VLAN はその特定のアクセス スイッチ内に閉じるべきです（下記の例を参照してください）。無線クライアントに関連付けられた VLAN は、ローミング ドメイン内のすべてのアクセス スイッチにまたがる必要があります。これについては次のセクションで説明します。
ディストリビューション レイヤのスイッチに進むにあたり、ディストリビューション スイッチは次のいずれかで構成することを推奨します。
- StackWise Virtual / Virtual Stacking
- 意図的なレイヤ 2（L2）ループを伴わず、ディストリビューション レイヤに冗長性を提供します。
- アクセス スイッチからディストリビューション スイッチへのアップリンクは、トランク ポートかつ EtherChannel として構成する必要があります。
- トランク ポートで許可する VLAN は必要な VLAN のみに絞り込みます。
- HSRP / VRRP
- ファーストホップ冗長性を提供します。
- STP Root と HSRP プライマリは同一スイッチ上に構成します。
- アップリンクはトランクかつ EtherChannel として構成します。
- ダウンリンクでは BPDU Guard と Root Guard を、アップリンクでは Loop Guard を有効化します。
- ディストリビューション レイヤへのトランクでは、必要な VLAN のみを許可します。
無線クライアントが WLAN に接続した際に配置される VLAN は、ディストリビューション スイッチとローミング ドメインに含まれるすべてのアクセス スイッチ間のトランクで許可されている必要があります。
MR57 の二重 PoE（PoE 冗長化と LACP）
MR57 には 2 つのイーサネット ポートがあり、802.3af/802.3at/802.3bt/UPoE をサポートします。
PoE の動作モードは 3 つあります。
- 単一 PoE: 1 つのイーサネット ポートのみが PoE を受電します。
- 二重 PoE（電力共有モード）: 両方のイーサネット ポートが PoE を受電します。電力は両ポートに分配されますが、必ずしも均等ではありません。
- 二重 PoE（デュアル アップリンク モード）: 両方のイーサネット ポートが PoE を受電します。いずれかのイーサネット ポートで PoE が失われた場合でも、MR57 は残りのポートへシームレスに切り替わり、無線クライアントの接続性に悪影響を与えません。
電力共有モードでは、2 つの PoE 間で消費電力が等分されるとは限りません。MR57 は電圧の高い PoE からより多くの電力を引き出す傾向があります。例えば、MR57 が 2 つの 802.3af PSE ポートに接続され、合計 23W を消費する場合、1 つの PoE ポートから 18W の 802.3af を超える電力を引き出し、もう一方からは 5W といった具合になる可能性があります。PD がスイッチのサポートを超える電力を引き出すと、スイッチ ポートがシャットダウンし、MR57 が再起動することがあります。この問題を解決するには、MR57 が分類された PD タイプまたは LLDP/CDP のネゴシエーション結果に応じて、PSE からの最大電力引き出しを設定する必要があります。
高可用性モードでは、いずれかのポートで電力が失われても、MR57 は再起動せず、無線クライアントを切断しません。
いずれのケースでも、スイッチは MR57 に接続された両方のスイッチ ポートに対し、供給可能な最大電力を割り当てます。電力予算を計画する際には、この動作を考慮する必要があります。AP あたりに割り当てられる電力が倍増するためです。
詳細については、こちらを参照してください。
ローミング ドメイン
Meraki はお客様に包括的な体験を提供することに尽力しています。以下のセクションには、当社の包含性基準に準拠していない表現が含まれています。現在、パートナーと協力して修正に取り組んでいます。
ローミング ドメインとは、同一の SSID を用いた RF の連続性がある領域で、クライアント デバイスがドメイン内のどこへ移動しても接続を維持できる領域のことです。これは物理的または仮想的に複数のドメインになり得ます。ユーザが論理的に移動し、アプリケーションの接続性を維持するために高速かつシームレスなローミングが必要となる領域です。
高速かつシームレスなローミングとは何でしょうか。
- シームレス: クライアントが異なる AP 間をローミングしても、IP アドレスとポリシーを保持できる場合はシームレスにローミングしていると言えます。シームレスなローミングには、クライアントが同一ローミング ドメイン内のどの AP に接続しても、ポリシーと IP アドレスに関するステートフルなクライアント情報を保持する必要があります。Meraki ダッシュボードは、この情報がネットワーク内のすべての AP 間で一貫して保持されることを保証します。
- 高速: クライアントが新しい AP にローミングするたびに再認証を行う必要がない場合は、高速にローミングしていると言えます。高速かつセキュアなローミングには、初回認証時に導出された Pairwise Master Key（PMK）をローミング ドメイン内で一貫して共有する必要があります。これにより、通常 50ms 未満という短いローミング遅延が保証されます。これを実現するには、802.11r や OKC といったキー キャッシング プロトコルを有効化し、クライアント側でサポートする必要があります。さらに最適化するには、802.11k/v を活用できます。
ローミング ドメインには、フロアのグループ、単一の建物、複数の建物などが含まれます。ローミング ドメインとして選択される物理的または仮想的なグループは、AP を Meraki ダッシュボードに追加する方法に影響します。Meraki ダッシュボードには、管理上の 2 つの主要な設計コンストラクトがあります。
- 組織（Organization）: 単一の組織体に属するネットワークの集合です。
- 推奨ノード数: 25,000
- ネットワーク（Network）: Meraki デバイスの集合とその構成、統計、情報です。通常は地理的な場所（例: サイト、建物群、建物、フロアなど）に対応付けられます。
- 推奨ノード数: 800
注意: ノードとは、あらゆる Meraki デバイス（MR、MS、MX、MV、MT など）を指します。
Meraki ネットワークは高速ローミング ドメインです。クライアントの PMK 情報は、同一ネットワークに属する MR 間で共有されます。また、AP は同一の管理 VLAN 上にあり、ソース ポート 23541、宛先ポート 35213 を用いて相互に通信できる必要があります。これにより、AP はクライアントの PMK を相互に共有できます。したがって、クライアント デバイスが同一 Meraki ネットワーク内の AP 間をローミングする場合、高速ローミングを行います。一方、異なる Meraki ネットワークに属する AP 間をローミングする場合、各クライアントの IP アドレス、ポリシー、および PMK は共有されないため、クライアント デバイスは完全に再認証が必要なハード ローミングになります。
このため、キャンパスの物理的な場所を明確な RF 境界で分割し、クライアントが同一ローミング ドメイン内の AP にローミングするようにローミング ドメインを設計することが重要です。これらの区分を見つける例として、次のようなものがあります。
- 地理的領域: キャンパスを論理的に切り分けられる区画を探します。例えば、キャンパスの北・南・東・西といった名称には理由があります。
- 屋外無線: 建物に付随する屋外無線エリアは、それぞれの建物内にグループ化します。
- スタジアム/スポーツ会場: これらのエリアには多数のクライアントが存在するため、専用のローミング ドメインおよび専用のネットワークとして分けることが最適です。
キャンパスは、最小単位のローミング ドメインとして建物単位でセグメント化することを推奨します。これは、フロア間で RF リークが発生し、クライアント デバイスが別のフロアの AP に接続してしまう可能性があるためです。そうしないと、同一建物内でもハード ローミングが発生する可能性があります。
また、Meraki ネットワーク内では、ローミング ドメインの規模を決定する際に、クライアントがレイヤ 2（L2）ローミングになるのか、レイヤ 3（L3）ローミングになるのかを理解し選択することが不可欠です。これは基盤となるスイッチング アーキテクチャに直接影響します。
- レイヤ 2 ローミング: クライアントが別の AP にローミングしても、WLAN が同一 VLAN に紐づいており、セッションを維持する場合です。SSID が同一で、同じ VLAN 上であるため、シームレス（同一 IP）かつ高速なローミングになります。同じ WLAN でも異なる VLAN に紐づく AP にローミングした場合、セッションは切断され、最終的にクライアントは再度 DHCP を行う必要があり、数秒を要することがあります。
- レイヤ 3 ローミング: 同じ WLAN でも異なる VLAN に紐づく AP にクライアントがローミングした場合でも、トンネリングや元の AP への再アンカーなどのメカニズムにより、クライアントが IP アドレスを保持できるようにすることで、シームレスなローミングが可能になります。
|
L2 ローミング（同一 VLAN） |
L2 ローミング（異なる VLAN） |
分散 L3 ローミング（異なる VLAN）** |
|
|
同一 SSID |
クライアントは再認証します。 シームレス（同一 IP）です。 |
クライアントは再認証します。 セッションが切断します。 |
クライアントは再認証します。 シームレス（同一 IP）です。 |
|
802.11r（または OKC） |
高速ローミングです。 シームレス（同一 IP）です。 |
高速ローミングです。 セッションが切断します。 |
高速ローミングです。 シームレス（同一 IP）です。 |
分散 L3 ローミング（DL3R）は、シームレスな L3 ローミングを提供する Meraki のソリューションです。現時点では、このソリューションは大規模環境での高速ローミングをサポートしていないため、大企業キャンパスには推奨されません。したがって、L2 ローミング ソリューションを選択することを推奨し、シームレスかつ高速なローミングが必要な場合は、Meraki ネットワーク内のすべての MR に同じ VLAN を関連付けるようネットワークを設計することが重要です。大規模なレイヤ 3 ローミングが必要な場合は、Cisco Wireless Business Unit にお問い合わせください。
VLAN が変更され、クライアントの IP アドレスが無効になったことでセッションが切断する場合、どの程度影響があるでしょうか。これはクライアント OS によって異なります。
- ローミング時に完全な再認証（高速ローミングが無効、または Meraki ネットワーク境界を越える）が発生しても、一部のクライアント OS は同一 SSID を同一ネットワークおよび同一サブネットと見なすため、DHCP が有効かどうかを確認しない場合があります。
- Windows OS はローミング時に DHCP Inform と GW 検出を実行しますが、どの OS も DHCP ディスカバリの全プロセスを実施するわけではありません。
- その他のクライアント OS は何もしないため、DHCP がタイムアウトします（30 秒間のセッション切断）。
- ローミングに失敗して de-auth を受信すると、クライアントは再認証後に完全な DHCP ディスカバリを実行します（それでも 4～5 秒）。
クライアントの挙動に加え、セッションが切断した際のネットワーク上のアプリケーションやサービスへの影響も考慮することが重要です。アプリケーションはシームレスに復旧しますか。VPN などのアプリケーションは動作せず、接続を再確立する必要があります。加えて、セッションの再確立が必要となる大量ローミングが発生すると、DHCP や AAA といったサービスに非常に大きな負荷がかかります。これらの問題を回避するには、シームレスかつ高速なローミングが不可欠であり、そのためにはクライアントに同じ VLAN を用いる必要があります。つまり L2 ローミングが必要です。
ただし、WLAN に同一 VLAN を用いた L2 ローミングでは、ローミング ドメイン内のすべてのアクセス スイッチ（場合によっては複数の配線クロゼットや複数の建物にまたがる）に VLAN をスパンさせる必要があります。ローミング ドメイン内のデバイス数によっては、その VLAN に大規模なサブネットが必要となり、大きなブロードキャスト ドメインにつながる可能性があります。
 |
 |
この VLAN の規模は、サイトに導入されているレイヤ 2 およびレイヤ 3 スイッチの種類に影響されます。MAC アドレスおよび ARP テーブルのスケール、CPU に対するスパニング ツリーの影響、クライアント規模、DHCP スコープ設計など、多くの要素が VLAN をどれだけ大きく展開できるかに直接影響します。アクセス ネットワーク設計のベスト プラクティスに従ってください。
RF の境界に加えて、ローミング ドメインごとに VLAN/サブネットを分離することを推奨します。これにより、ブロードキャスト ドメインの規模をローミング ドメインの範囲に制限でき、ブロードキャスト、未知のユニキャスト、マルチキャスト（BUM）といったトラフィックの影響を抑えられます。また、障害やセキュリティ問題（TCAM/ARP 攻撃、ブロードキャスト ストームなど）も低減できます。さらに、VLAN/サブネットごとにクライアントの所在が分かりやすくなるため、運用管理が容易になるという利点もあります。
では、ローミング ドメイン内の VLAN はどれくらいの大きさまで許容されるのでしょうか。
共通の RF ドメインがあり、シームレスかつ高速なローミングを実現したい場合、ドメイン全体に同じ VLAN をスパンする必要があります（上図左参照）。この場合、単一のローミング ドメインおよび VLAN をどこまで大きくできるかを考慮する必要があります。
IPv4 と IPv6 のデュアルスタック環境を想定すると、各ホストは IPv4 アドレスを 1 つ、および最低 3 つの IPv6 アドレスを持ちます。
- IPv4 ユニキャスト
- IPv6 リンクローカル
- IPv6 ユニークローカル
- IPv6 グローバル ユニキャスト
注意: 一部の Windows 11 クライアントは、最大 16 個の IPv6 アドレスまでスケール可能です。本ガイドでは合計 4 つの IP アドレスのみを考慮します。
これを踏まえ、まずはレイヤ 2 のスイッチング アーキテクチャを考えます。Cisco Catalyst 9200L（または Meraki MS 同等）を例にします。
- MAC アドレス テーブルのスケールは合計 16,000 エントリです。
- 各無線デバイスは MAC アドレス エントリを 1 つ使用します。
- ランダム化および変更される MAC（RCM）を考慮するとこの数は増える可能性がありますが、ここでは考慮せず最良ケースとします。
- AP あたり 40 クライアントと仮定すると、1 VLAN あたり最大 400 台の AP まで許容できます。
次にレイヤ 3 のスイッチング アーキテクチャについて、Cisco Catalyst 9300（または Meraki MS 同等）を例に考慮すべき点は以下の通りです。
- ARP エントリのスケールは合計 32,000 エントリです。
- デュアルスタック クライアントでは、各クライアントが合計 4 つの IP アドレスを持つため、クライアントあたり最小 4 エントリが必要です。
- これにより、合計で最大 8,000 クライアントまで許容されます。
- AP あたり 40 クライアントと仮定すると、1 VLAN あたり最大 200 台の AP まで許容できます。
ネットワーク サービスのガイドライン
RADIUS
Meraki MR を Network Access Server（NAS）として追加
802.1X、MAB などの AAA RADIUS サーバ認証において、各 MR はそれぞれが独立した NAS として動作します。つまり、NAS として各 MR が AAA 通信のすべてについて AAA サーバと直接通信します。これにより、各 MR の IP アドレスを AAA サーバに構成し、サーバとの通信を許可する必要があるため、IT 運用コストが増大する可能性があります。
これを回避し、管理を容易にするために、AP の管理サブネットを上位のサブネットに集約できるよう設計することを推奨します。例えば、展開するすべての MR を /16 サブネット内に配置し、ローミング ドメインに基づいて分割します。これにより、AAA サーバ側で単一のサブネット エントリとして MR 全体を NAS に構成できます。
RADIUS サーバのスケール
Meraki ダッシュボードでは、SSID ごとに最大 3 台の AAA サーバを構成できます。これらは使用される優先順位の順に設定します。
- 最初に構成された AAA サーバが常に最初に使用されます。
- サーバ 1 が障害となった場合、サーバ 2 が使用されます。
- サーバ 2 が障害となった場合、サーバ 3 が使用されます。
MR はフォールバック オプションを有効化して構成できます。高優先度のサーバが復旧すると、AP はその優先サーバ（高優先度）にフォールバックして使用します。
通常、SSID ごとに 3 台の AAA サーバがあれば制約にはなりませんが、大規模・高密度の展開では、より多くのスケールに対応するため AAA サーバの前段にロードバランサを配置することを検討してください。ロードバランサを使用する場合は、クライアント セッションごとに常に同じ AAA サーバと通信できるよう、送信元ベースのスティッキーな負荷分散を構成してください（対象サーバが稼働中であることが前提）。
詳細はこちらを参照してください。
Adaptive Policy
Cisco Group Based Policy、特に SGT を用いたマイクロセグメンテーションは Meraki でサポートされます。注意: サポートされるのはインライン タギングのみです（SXP は非対応）。つまり、エンドツーエンドのポリシーを適用するには、経路上のすべてのスイッチが SGT とインライン タギングをサポートする必要があります。Adaptive Policy をサポートするのは MS390 のみであるため、その他のスイッチは Cisco Catalyst のスイッチを使用することを推奨します。
詳細はこちらを参照してください。
DHCP
注意: このセクションでは、ブリッジ モード SSID を使用し、無線クライアントが上流の DHCP サーバから IP アドレスを取得することを前提とします。詳細はこちらを参照してください。
キャンパスの DHCP を構成する際は、まず、そのエリア/建物に参加し得るすべてのデバイスを考慮して DHCP スコープの規模を見積もってください。ネットワーク機器、プリンタ、テレビなどの据置型デバイスから、携帯電話やノート PC などのローミング デバイスまで多岐にわたります。ネットワークに接続するものはすべて考慮対象です。最も避けたいのは DHCP アドレスの枯渇です。高密度エリア（スタジアムや公共イベントなど）では、より大きなスコープが必要です（/16 または /18）。プール サイズの推奨は、想定クライアント数の約 3 倍です。
DHCP リース時間は、DHCP スコープの枯渇やセキュリティ問題を防ぐうえで重要です。リース時間は、そのスコープが適用される環境の平均滞在時間に合わせて設定してください。
例:
- 大学: 8 時間
- 小売: 1 時間
- オフィス: 12 時間
セキュリティを高めるため、リース時間を非常に短く（例: 30 分）設定することも可能ですが、その分 DHCP サーバや AP の負荷が増加します。クライアントはリースの半分の時点で DHCP をチェックするため、リース時間を短くするとチェック頻度が高くなります。RCM 環境では、同一デバイスでも MAC アドレスの変更により異なる IP アドレスが割り当てられ得るため、枯渇を防ぐ目的でリース時間を短くすることも検討してください。
スタティック IP 割り当てが必要な場合は、DHCP サーバでの DHCP 予約を検討してください。これにより、DHCP 強制 を有効化した際のセキュリティを維持しつつ、スタティック IP アドレスの柔軟な使用が可能になります。
これらを踏まえると、DHCP スコープは各規模で許容されるサブネット サイズによって制限される可能性が高いです。例えば、各建物に最大 /24 の独自サブネットが割り当てられる場合があります。その理由としては、次のようなものがあります。
- ディストリビューション レベルでのサブネット設計とサマリ化。
- サブネットの拡張や変更が容易ではないパブリック IP の使用。
サブネット設計により DHCP スコープが制限される場合は、VLAN プーリングの構成を検討してください。これにより、単一の SSID に複数の VLAN を割り当てることができます。
詳細はこちらを参照してください。
注意: VLAN プーリングのサポートには MR30 以降のリリースが必要です。
DNS
ブリッジ モード SSID を使用することを推奨します。これにより、無線クライアントは組織の DHCP サーバから DNS サーバ情報を受け取ることができます。
一方、SSID を NAT モードで展開する場合は、次の構成ガイドを参照してください。
Configuring_Custom_DNS_for_an_SSID_in_NAT_Mode
注意: 大規模展開では MR 上で NAT 機能を実行することは推奨されません。 パフォーマンスとスケールの観点から、専用デバイスで構成してください。
ファイアウォール
詳細な構成手順については、構成ガイドを参照してください。
注意: 大規模展開では MR 上でファイアウォール機能を実行することは推奨されません。パフォーマンスとスケールの観点から、専用デバイスで構成してください。
マルチキャスト / ブロードキャスト設計
Meraki 無線は、ブロードキャストおよびマルチキャスト トラフィックのパフォーマンスを最適化しつつ、ネットワーク全体への影響を最小限に抑えるよう設計されています。MR には、クライアントのブロードキャストやマルチキャストの影響を抑制または低減するためのメカニズム（ARP プロキシ、レート リミット、マルチキャストのユニキャスト変換など）が組み込まれています。
詳細については、こちらのドキュメントを参照してください。
これらのメカニズムのいくつかを分析します。各 MR アクセス ポイントでは ARP プロキシが既定で有効化されており、無効化できません。MR はクライアントに代わって ARP リクエストに応答し、無線区間におけるブロードキャスト トラフィックを防止します。
注意: 受動クライアントのサポートなどで ARP プロキシを無効化する必要がある場合は、Meraki サポートに連絡して SSID 単位で無効化してください。
マルチキャストのユニキャスト変換
MR は、マルチキャスト ストリームに参加したクライアントのリストを保持します。これは IGMP スヌーピングを通じて学習します。MR は、マルチキャスト ストリームを要求したクライアントに対してのみ、ユニキャスト（変換された）パケットを送信します。
詳細はこちらを参照してください。
マルチキャストと AAA VLAN オーバーライド
単一の SSID を使用し、AAA ポリシー経由で複数のクライアント VLAN にマッピングする場合、クライアント VLAN 間で IP マルチキャストの分離が必要となる場合があります。
以下の例では、クライアントは同一 SSID に属し、IP マルチキャスト分離が構成されていません。この場合の動作は次のとおりです。
- クライアント 1 が IP マルチキャストを要求します。
- IGMP クエリが VLAN 100 上で行われます。
- マルチキャスト トラフィックが VLAN 100 に到達します。
- 無線区間では、#1 SSID と #1 GTK が対応しているため、AP はそれをブロードキャストとして送信し、クライアント 2（VLAN 103）もトラフィックを受信します。
- 無線区間ではマルチキャストやブロードキャストのセグメンテーションがありません。これは IPv4 と IPv6 の両方に該当します。
IP マルチキャストの分離を構成するには、マルチキャストのユニキャスト変換機能を有効化してください。これにより、MR は無線区間でトラフィックを「デマルチキャスト」し、VLAN セグメンテーションを維持します。
注意: 現時点では mDNS トラフィックはマルチキャストからユニキャストへの変換に対応していません。
mDNS
mDNS はサポートされており、Bonjour サービスが複数の VLAN にまたがって動作することを可能にします。特定サービスのみを対象として Bonjour 転送を有効化することも可能です（例: AirPlay のみ）。なお、場所に基づくフィルタはサポートされません。
詳細はこちらを参照してください。
IPv6 インフラストラクチャ
IPv6 について、MR がサポートするのは Static IP と SLAAC のみです。DHCPv6 はサポートされません。
クライアントの IPv6 アドレッシングは、いくつかの注意点付きでサポートされます。
- IPv6 インフラ上での 802.11r/OKC をサポートします。
- 分散レイヤ 3 ローミングは、IPv4 インフラを使用している場合にのみサポートされます。
- WPN のサポートは MR 30 リリースでサポートされます。
詳細はこちらを参照してください。
SSID 構成
Meraki 無線の SSID は、お客様のニーズに合わせて 3 つのモードで構成できます。3 つのモードは以下のとおりです。
- トンネル SSID: SSID のトラフィックはすべて中央の Meraki MX にトンネルされ、MX がトラフィックのスイッチング判断を行います。これは WLC を用いた中央スイッチ型の展開に似ています。通常、無線クライアントの展開を簡素化したい中央スイッチング環境や、コンプライアンスにより中央トンネルの使用が求められる場合に使用します。
- 使用する MX のモデルは無線展開の規模に基づきます。さまざまなクラウド ベースおよびハードウェア ベースのモデルがあり、異なるスケールに対応します。適切なサイズを決定するには、VPN トンネルのスケールを考慮する必要があります。AP ごとに、トンネル SSID ごとに 1 本のトンネルが張られます。
- 100 台の AP がそれぞれ 2 つのトンネル SSID をブロードキャストする場合、無線インフラだけで MX は 200 本のトンネルをサポートする必要があります。Meraki SD-WAN Auto-VPN ソリューションも展開する場合は、Auto-VPN とトンネル SSID のトンネル本数を合わせて考慮する必要があります。
- MX はパススルー モードに構成する必要があり、SSID はスプリット トンネル（関連トラフィックのみ MX にトンネル）またはフル トンネル（すべてのトラフィックをトンネル）のいずれかにできます。SSID には VLAN ID の構成も必要です。
- MX を使用する場合は、HA の要件も定義する必要があります。ゼロ ダウンタイムを実現する必要がある場合、MX は HA を考慮して設計してください。そうでない場合、MX がダウンすると AP はトンネル SSID のブロードキャストを停止します。
注意: このモードのスケールとパフォーマンスの制約を踏まえ、企業向け展開ではトンネル モードは推奨されません。
- 分散 SSID: SSID のトラフィックはすべて MR AP によってローカルでスイッチされます。これは FlexConnect のローカル スイッチング展開に似ています。セグメンテーション ルールは SSID 上で定義され、AP によって適用されます。通常は、次ホップを決定する中央のポリシー ベース ルーティング ルールが存在します。
- リモート ワーカー展開: トンネル SSID と分散 SSID を組み合わせたものです。企業トラフィックはデータセンターに配置した MX にトンネルされ、従業員は自宅から企業リソースに容易かつ安全にアクセスできます。MR は従業員の個人ネットワーク用に分散 SSID もブロードキャストでき、これは MR によってローカルでスイッチされ、従業員宅のホーム ルータを経由して送信されます。
AP あたりの SSID 構成数は最大 3 つまでにすることを推奨します。Meraki ネットワークごとの最大 SSID 数は 15 です。
Meraki ネットワーク内で SSID が 3 つを超える場合は、AP タグを構成し、どの AP がどの SSID をブロードキャストするかを指定できます。これは Cisco Catalyst 9800 WLC の Policy Tag や Cisco AireOS WLC の AP グループに相当します。
詳細はこちらを参照してください。
注意: 1 つの SSID は常にメッシュ SSID 用に予約されます。無線メッシュの有効/無効に関わらず、ユーザが構成可能な SSID は合計 15 個までです。
ブリッジ モード SSID
大規模な集中型または分散型の展開では、SSID をブリッジ モードで構成することを推奨します。AP は透過的に動作し、DHCP や NAT を行いません。これにより L2 接続性が LAN に提供され、組織の DHCP サーバおよび NAT ルータがすべてのクライアント トラフィックを処理します。ブリッジ モードに設定する場合は、クライアント トラフィックに正しい VLAN タグを付与し、そのトラフィックに対して適切な処理が適用されるようにする必要があります。
ブリッジ モード SSID は同一 VLAN 内でのみ通信を許可する点にご注意ください。サブネット間をローミングするには、分散 L3 ローミング（DL3R）またはコンセントレータを用いた L3 が必要です。ただし、これらの構成には追加のオーバーヘッドが伴うため、完全にシームレスなローミング体験には理想的ではありません。
ブリッジ モード SSID の詳細はこちらを参照してください。
6 GHz の WPA3 設計
Wi‑Fi 6E および 6 GHz 帯の登場に伴い、より厳格な WLAN セキュリティが求められるようになりました。6 GHz で SSID をブロードキャストするには、次の構成することが必須です。
- レイヤ 2 セキュリティとしての WPA3（以下のいずれか）。
- OWE
- SAE
- 802.1X SHA256
- Protected Management Frame（PMF）の有効化。
- WPA3 以外の L2 セキュリティ方式は禁止（混在モードは不可）。
上記の要件により、現在の多くの WLAN 展開では 6 GHz でのブロードキャストに対応できない可能性があります。これを解決するため、次の 3 つの移行パスを推奨します。
- 「オールイン」オプション: 既存の WLAN を WPA3 に再構成します（2.4/5/6 GHz の 3 バンドで 1 つの SSID）。
- 「複数 SSID」オプション: ユース ケースごとにセキュリティ設定を分けた WLAN/SSID を設計します。
- 「1 つの SSID」オプション: MR31 リリースで提供予定。2.4/5 GHz ではトランジション モード（WPA2 + WPA3）、6 GHz では WPA3 のみを 1 つの SSID で構成可能になります。機能リリース時に詳細情報を提供します。
「オールイン」オプション
ネットワークに接続するエンドユーザ デバイスをお客様が完全に管理できる場合、この方法が最も推奨されます。WPA3 により最大限のセキュリティを提供できるためです。ただし、デバイスの種類を制御できない（大学などの BYOD 環境）場合は、WPA3 に非対応のデバイスが接続できなくなるため、このオプションは推奨されません。
オールイン オプションを採用すると、SSID のブロードキャストもすっきりします。6 GHz をサポートする SSID のみに限定することで、ユーザが記憶すべき SSID 数を減らすだけでなく、各 SSID がネットワークの最小データ レートでビーコンやプローブを送信する必要があるため、全体的なチャネル使用率の削減にもつながります。
マルチ SSID 展開の詳細はこちらを参照してください。
WPA3 のみの SSID を構成するには、対象 WLAN のアクセス制御ページで必要なセキュリティ方式を選択します。暗号方式は「WPA3 のみ」を選択してください。
「複数 SSID」オプション
多くのお客様にとって、6 GHz WLAN 設計における推奨移行パスは「複数 SSID」オプションです。これにより、各ユース ケースに応じた WLAN 設計が可能となり、より幅広いデバイスの接続に対応できます。特に、接続デバイスの種類を制御できない場合に有効です。
このパスには 2 つの方法があります。
a) WPA3 用に別 SSID 名の WLAN を追加し、すべてのバンドでブロードキャストする。既存の WLAN/SSID は変更しない。
b) すべての WLAN を再設計し、バンドごとに特定のデバイス/ユース ケースに割り当てる。
オプション A
この方法では、既存 SSID はレガシー クライアント向けとして 2.4/5 GHz で残します。新しい SSID は WPA3 のみで構成し、新しい SSID 名を付けて全バンドでブロードキャストします。
注意: 新しい SSID 名は任意ですが、エンドユーザの体験を考慮し、既存 SSID 名に近い名称にすることを推奨します。例えば、レガシー SSID 名が internal の場合、新しい SSID 名は internal-WPA3 とします。いずれにせよ、ユーザが新しい SSID に移行できるよう、告知と教育を強く推奨します。
オプション B
この方法では、既存のすべての WLAN を再設計します。各 SSID は特定のデバイス種別/ユース ケースに応じて特定のバンドでブロードキャストします。
2.4 GHz 帯は特定のデバイス専用（レガシー デバイス、PSK 中心の IoT など）。5 GHz 帯は既存クライアントの大半を割り当て、6 GHz 帯は最新クライアント向けに WPA3 のみとします。
VLAN 設計
クライアント用の VLAN とサブネットを設計する際は、上記の DHCP セクションで示したベスト プラクティスに従ってください。
クライアント VLAN に関する一般的な推奨事項は次のとおりです。
- VLAN のブロードキャスト ドメインの原則を適用する。
- /24 ～ /20 のサブネット サイズ。
- 無線のマルチキャスト ユニキャスト変換を有効化する。
- VLAN の分離を検討する。
- 例: 来訪者向けプリンタ リソース用のサービス VLAN を作成する。
- タグ ベースの VLAN や SSID 割り当てを使用する。
- MR30 以降のリリースでは、Named VLAN / VLAN プーリングを構成し、大規模なクライアント VLAN に対応する。
SSID 単位の VLAN タギング
無線クライアントの VLAN タギングを可能にし、そのトラフィックをネットワーク全体へ到達させるには、AP に接続するアクセス スイッチのスイッチ ポートで次の構成を行ってください。
- Cisco Meraki AP が接続されるスイッチ ポートは、802.1Q のトランク ポートに構成する。
- トランク ポートには、各 SSID でタグ付けされるすべての VLAN を許可する。
- ダッシュボード上の各 SSID にはルーティング可能な VLAN をタグ付けし、ローカルのスイッチング アーキテクチャ全体で構成する。
- VLAN タギングは External DHCP server assigned（エンタープライズ向け機能）でのみ利用可能。
Named VLAN / VLAN プーリング
MR30 リリース以降、Meraki 無線はクライアント向けに Named VLAN および VLAN プーリングをサポートします。Named VLAN を構成すると、デバイス/ユーザ/エンドポイントに対する VLAN の動的な RADIUS ベース割り当てを、整数番号ではなく英数字名で行えます。これは、ユーザをセグメント化し AAA サーバから特定 VLAN に割り当てる大規模展開において、サイトごとに VLAN ID が異なる場合に特に有用です。
以下の例を考えます。
サイトに関わらず、クライアントのセグメンテーションは同一です。教授、学生、IoT はそれぞれ専用の VLAN に属しますが、サイトによって VLAN ID は異なります。グリーン サイトでは教授を VLAN 401、ブルー サイトでは VLAN 301 に配置します。VLAN を整数で割り当てる場合、ネットワーク管理者はユーザごと、サイトごとに VLAN ID を考慮した RADIUS Access-Accept プロファイルを作成する必要があります。上記の例では 9 つ（ユーザ種別 3 × サイト 3）のプロファイルで済みますが、より大規模な展開では管理負荷が指数関数的に増加します。特定ユーザ種別のプロパティを変更するだけでも、その種別に紐づくすべてのプロファイルへ同様の変更を適用する必要が生じます。
注意: AAA オーバーライドおよび 802.11r と組み合わせた Named VLAN をサポートするには、MR が MR30 以降を実行している必要があります。
管理負荷を軽減するため、Named VLAN を使用してユーザ VLAN を名前で割り当てます。これにより AAA サーバ上の RADIUS Accept プロファイル数はユーザ種別にのみ依存します。プロファイルはユーザ種別ごとに作成し、サイトにまたがって再利用できます。教授 VLAN の例に戻ると、RADIUS Access-Accept プロファイルは教授を「Professors」という名前の VLAN に割り当てます。対象サイトに「Professors」という名前の VLAN が存在する限り、VLAN ID が 401 でも 301 でも、教授ユーザは正しい VLAN に配置されます。
VLAN プーリングを構成すると、ブロードキャスト ドメインを大幅に拡大することなく、ネットワークがサポートする無線クライアント数を拡張できます。異なる VLAN をプールすることで、サブネット設計の柔軟性も高まります。大量の無線クライアントに対応するためにサブネットを再設計するのではなく、規模に応じて複数のサブネットを容易にプールできます。VLAN プーリングはすべての認証タイプでサポートされ、RADIUS を必要としません。
詳細はこちらを参照してください。
AP タグ
AP タグは、同一の Meraki ネットワーク内で、ユース ケースやニーズに応じて MR のグループをセグメント化/分割する優れた方法です。例としては、次のようなものがあります。
- タグ ベースの RF プロファイル割り当て
- 教室の AP と講堂の AP。
- 天井設置 AP と壁面設置 AP。
- 特定の AP グループに対して検索、レポート、分析フィルタを容易に実行。
- SSID 可用性: AP タグに基づき、一定時間のみ SSID をブロードキャスト。
- 例: 来訪者 SSID を平日の午前 8 時～午後 5 時の間、ロビーの AP のみでブロードキャスト。
- VLAN タギング: 同一 AP に対して、AP タグに基づき異なる VLAN を適用。
AP タグの作成方法の詳細はこちらを参照してください。
タグを用いた SSID 可用性の利用方法については、こちらを参照してください。
QoS（サービス品質）ガイドライン
QoS は、Differentiated Services（DiffServ）モデルを用いて特定のデータ種別を優先的かつ確実に配信することで、ネットワークで重要な役割を果たします。DiffServ は、パケットを要求するサービス種別に応じてマーキングすることで優先度モデルを実装します。このマーキングに応じて、AP、ルータ、スイッチはさまざまなキューイング手法を活用し、期待に沿ったパフォーマンスを実現します。
無線ネットワークで QoS を構成する際の一般的なガイドラインは次のとおりです。
- SSID
- SSID に対してトラフィック種別（例: VoIP やビデオ会議）を優先する設定を適用する。
- スイッチング基盤
- SSID およびネットワーク全体で使用する DSCP 値を定義し、整合させる。
- WAN 基盤
- サイト間で QoS ポリシーを一貫させる。
- ポリシーは双方向トラフィックに適用する。
クライアントやアプリケーションのトラフィックを SSID 上でシェーピングする際は、トラフィックの種類と要件を考慮します。トラフィック シェーピングは、SSID 全体に対するトップダウンの強制ではなく、まずクライアント単位、次にアプリケーション単位で行うべきです。
ゲスト ネットワークの場合、帯域幅のスロットリング ポリシーを適用する必要があるかもしれません。これらゲスト クライアントに対しては、シェーピング ルールを適用する前に、そのワークロードと必要平均ビットレートを把握する必要があります。必要帯域幅を決定したら、クライアント単位の帯域幅ルールに適用します。さらに SpeedBurst を有効にし、ユーザが割り当て帯域を一時的に超過しても劣化のない体験でサービス利用や小さなファイルのダウンロードができるよう、緩やかなトラフィック整形を可能にします。
注意: 帯域幅スロットリング ポリシーを適用すると、ワークロード完了までに時間がかかるため、エアタイム利用率が逆に増加する可能性がある点に注意してください。
アプリケーションに関しては、ミッションクリティカルなアプリケーションを非制限かつ優先化し、レクリエーション アプリや帯域幅を大量消費するアプリは制限します。対象アプリは展開のユース ケースに応じて選択します。例えば、ビデオ会議やコラボレーション アプリ、業界固有アプリを優先しつつ、P2P、クラウド バックアップ/OS アップデートなどのアプリのパフォーマンスを制限します。
トラフィック シェーピングの構成ガイドはこちらを参照してください。
Application Visibility and Control（AVC）ポリシーの動作
AVC ポリシー（DSCP マーキング、トラフィック レート制限など）は、ローミング元 AP とローミング先 AP の両方に存在します。ただし、現時点ではクライアントのフロー状態はローミング時に引き継がれません。その結果、フローは初回に接続した AP 上ではポリシーが適用されるものの、ローミング後は適用されなくなる場合があります。以下の例では、Windows ファイル転送に対してレート制限ポリシーが適用され、転送速度が低下しています。クライアントが新しい AP にローミングすると、レート制限ポリシーは適用されなくなります。
この動作が発生するのは、アプリケーションが認識できない（暗号化されるなど）ため、ローミング先 AP が分類できず、ポリシーを適用できない場合です。また、多くの Web ページやアプリケーションは複数のセッションで構成されるため、ローミング先 AP で新たに開始されたフローは正しく分類されます。
アクセスポイントの無線設定
クライアント負荷分散(クライアントバランシング)
クライアント負荷分散は、無線ネットワーク（AP とクライアント）の状態情報を用いて、クライアントを最適な AP に誘導します。これは能動方式と受動方式の 2 つの方法で行います。
- 受動方式: クライアントのアソシエーション時に、プローブやアソシエーション拒否に基づいて制御します。
- 能動方式: クライアントのアソシエーション時に加え、アソシエーション後でも、802.11v 対応クライアントに対して BSS‑TM フレーム（MR 29 以降）を用いて制御します。
クライアント負荷分散の情報は、UDP ポート 61111 で L2 ブロードキャスト メッセージを用いて AP 間で共有されます。
高密度展開では、プローブ処理の負荷がネットワークを圧迫する可能性があるため、クライアント負荷分散をオフにすることを推奨します。このため、新しく作成される Meraki ネットワークでは、クライアント負荷分散は既定でオフになっています。
ワイヤレス メッシュ ネットワーキング
ワイヤレス メッシュ展開が不要な場合は、メッシング設定を無効にすることを推奨します。これにより、MR がメッシュ SSID をブロードキャストしなくなり、エアタイムを節約できます。
詳細はこちらを参照してください。
AI による自動 RF
Auto RF
Auto RF は、Meraki アクセス ポイントに搭載された機能で、Auto TX Power と Auto Channel を基盤に、非 Wi‑Fi 干渉を検知し、Wi‑Fi 環境を監視して、無線設定をリアルタイムに調整・最適化します。検知した環境要因に基づき、チャネル割り当て、ラジオごとの送信電力、バンド ステアリングなどの設定を自動でチューニングできます。
これは Meraki ネットワーク単位で動作するため、RF で隣接関係にある AP は同一の Meraki ネットワークに含める必要があります。これにより、最適化されたチャネル/電力計画が確保されます。ベスト プラクティスとしては、1 つの Meraki ネットワークあたり約 500 台、最大 800 台の AP を推奨します。ただし、これは厳密な上限ではありません。
推奨数を超える AP 台数があり、同一の Meraki ネットワークに配置できない場合は、高速ローミング ドメインまたは共通の RF ドメインに基づき AP を分割してください。
詳細はこちらを参照してください。
Auto Busy Hour
Busy Hour 機能は、定義した時間帯に不要な RF 変更を回避し、重要な変更のみを Busy Hour 後に実施します。Meraki ダッシュボードは、顧客ネットワークの過去の利用状況を処理して、Busy Hour を自動的に検出します。必要に応じて、お客様が手動で Busy Hour を設定することも可能です。これにより、チャネル変更に伴うクライアントの切断やローミングを最小化または解消できます。
業種ごとに Busy Hour の特徴は異なり、中央のネットワーク管理者の視点から一律に定義することが難しい場合があります。Auto Busy Hour は有効化しておくことで、Auto RF が各ネットワークの固有の Busy Hour に合わせて日々自動最適化します。
AI チャネル プランニング
適切に設計されたチャネル プランは、高性能な無線ネットワークを運用するために RF を最大限に活用するうえで不可欠です。これは、AutoChannel リストで利用可能なチャネルの分布を広く持たせることで達成できます。ただし、これらのチャネルは DFS イベントや妨害波（ジャマー）などの非 Wi‑Fi 干渉の影響を受け、実質的に使用可能なチャネル数が減少します。AI チャネル プランニングを有効化すると、Meraki ダッシュボードがネットワーク内の各 AP に対して「回避チャネル リスト」を維持します。
AI チャネル プランニングは、本質的に次の理由で大きく影響を受けるチャネルを回避します。
- • DFS イベントが頻発するチャネル。
- • ジャミングが頻発するチャネル。
- • AFC による低出力規制（屋外 6 GHz AP）。
AI による Auto RF の構成ガイドはこちらを参照してください。
インフラの運用管理
ファームウェア アップデート
Cisco Meraki は、強力なネットワーキングおよび IT ソリューションをシンプルで管理しやすい形で提供することを常に重視しています。これは Meraki デバイスのファームウェア管理にも当てはまります。従来、ファームウェア管理は面倒で時間のかかるリスキーな作業であり、アップグレードを担当するネットワーク管理者にとって負担でした。USB ドライブの破損が原因でアップグレードが失敗したり、データセンターで新しいコードを手作業でプロビジョニングしたりといった「恐怖体験」も広く知られています。
Meraki は、Meraki のクラウド型ダッシュボードの力を活用し、容易な展開とファームウェアのスケジューリングを可能にすることで、この複雑な問題に取り組んでいます。ダッシュボードは、新しいファームウェア リリースで利用可能になる新機能について、独自のインサイトも提供します。
クラウドがもたらすシンプルさにより、お客様はネットワークごとに実行したいファームウェアとアップグレードのスケジュールを選択できます。そのうえで、最適な無線体験のために従うべき推奨事項がいくつかあります。
- 同一ローミング ドメイン内のすべての MR は同一の MR バージョンを実行し、ローミング時の機能と互換性を一貫させる。
- 本番ネットワークでは ベータ版を試す を いいえ に設定し、検証前にベータ版が自動的にインストールされないようにする。
- 新しいファームウェア（新しい安定版やベータ版）にアップグレードする際は、特定の MR テスト エリアを指定し、これらの AP を専用のテスト ネットワークに移動する。ここでネットワーク全体へ影響を与えることなく新しいバージョンを検証します。テスト ネットワークは、ビジネスにクリティカルでないエリアで、十分に多様かつ多くのクライアントが参加する環境にしてください。
- ファームウェアのアップグレード戦略は、スケジュールされたアップグレード中にクライアントが接続を維持する必要があるかどうかを考慮します。
- クライアント接続を維持する必要がある場合: クライアントのダウンタイムを最小化 を選択。AP は段階的に新しいファームウェアをダウンロード/アップグレードし、クライアントへの影響を抑えます。この段階的アップグレードは時間がかかりますが、クライアントの接続を維持できます。
- クライアント接続を維持する必要がない場合: 合計アップグレード時間を最小化を選択。すべての AP が同時に新しいファームウェアをダウンロード/アップグレードします。これにより短時間でアップグレードできますが、すべての無線デバイスで一時的な接続断が発生します。
Meraki ファームウェアのベスト プラクティスの詳細はこちらを参照してください。
アクセスポイントのファームウェア アップグレード計画の詳細はこちらを参照してください。
サポートで有効化が必要な機能
特に記載がない限り、すべての機能は Meraki ダッシュボードから構成できます。一部の機能については、組織でその機能を使用できるよう、Meraki サポートによる有効化が必要です。その場合、本機能の構成ガイドに、以下の注意のように明確に記載されます。
注意: このセクションが表示されない場合は、Cisco Meraki サポートにケースをオープンし、有効化を依頼してください。