My Home NW Lab

逸般の誤家庭のネットワーク

Meraki MXでOutbound方向のアクセス可否のログを取得

概要

Meraki MXでOutbound方向のアクセス可否のログを取得したい場合は、 Syslog serversRolesFlows を指定をしたうえで、Outbound rules または Site-to-site outbound firewallSyslog オプションにチェックを入れる必要があります。
しかし、Flows を指定すると ip_flow_startip_flow_end のFlowログが(アクセス可否のログとは別に)出力されるため、ログの肥大化を避ける場合はサポートへ依頼しての無効化が必要になります。

f:id:myhomenwlab:20220318232327j:plain
Syslog servers で Flows を指定時

該当する公式ドキュメントは Syslog Server Overview and ConfigurationFlows のセクションになります。

documentation.meraki.com

Flowログの無効化に関しては公式ドキュメントに明確な記載がないようであったため、2022年03月頃にサポートへ問い合わせたうえで実機で挙動の確認をしました。

また、Inbound rules にも Syslog オプションがありますが、Inbound rules はサポートへ有効化の依頼が必要な機能であるため本記事内では取り扱いません。

ログ出力のサンプル

ip_flow_startip_flow_end がどのように出力されるのか比較するためのサンプルを掲載します。

f:id:myhomenwlab:20220318232847j:plain
ip_flow_start と ip_flow_end とアクセス可否のログ

Flowログとアクセス可否のログの混在

Mar 16 08:16:21 10.255.11.254  1647352121.770117590 MX67W flows src=10.255.11.1 dst=8.8.8.8 mac=**:**:**:**:**:** protocol=tcp sport=58613 dport=443 pattern: allow tcp && (dst 8.8.8.8/32)
Mar 16 08:16:21 10.255.11.254  1647352121.770165190 MX67W ip_flow_start src=10.255.11.1 dst=8.8.8.8 protocol=tcp sport=58613 dport=443 translated_src_ip=10.255.201.2 translated_port=58613
Mar 16 08:17:14 10.255.11.254  1647352174.852326694 MX67W ip_flow_end src=10.255.11.1 dst=8.8.8.8 protocol=tcp sport=58574 dport=443 translated_src_ip=10.255.201.2 translated_port=58574
Mar 16 08:17:37 10.255.11.254  1647352198.071691414 MX67W flows src=10.255.11.1 dst=1.1.1.1 mac=**:**:**:**:**:** protocol=tcp sport=58621 dport=443 pattern: deny tcp && (dst 1.1.1.1/32)
Mar 16 08:17:38 10.255.11.254  1647352199.080955614 MX67W flows src=10.255.11.1 dst=1.1.1.1 mac=**:**:**:**:**:** protocol=tcp sport=58621 dport=443 pattern: deny tcp && (dst 1.1.1.1/32)
Mar 16 08:17:40 10.255.11.254  1647352201.090315974 MX67W flows src=10.255.11.1 dst=1.1.1.1 mac=**:**:**:**:**:** protocol=tcp sport=58621 dport=443 pattern: deny tcp && (dst 1.1.1.1/32)
Mar 16 08:17:44 10.255.11.254  1647352205.096665414 MX67W flows src=10.255.11.1 dst=1.1.1.1 mac=**:**:**:**:**:** protocol=tcp sport=58621 dport=443 pattern: deny tcp && (dst 1.1.1.1/32)
Mar 16 08:17:52 10.255.11.254  1647352213.099215734 MX67W flows src=10.255.11.1 dst=1.1.1.1 mac=**:**:**:**:**:** protocol=tcp sport=58621 dport=443 pattern: deny tcp && (dst 1.1.1.1/32)
Mar 16 08:19:13 10.255.11.254  1647352293.575189734 MX67W ip_flow_end src=10.255.11.1 dst=8.8.8.8 protocol=tcp sport=58601 dport=443 translated_src_ip=10.255.201.2 translated_port=58601

Flowログの出力を無効化時

Mar 18 19:14:06 10.255.11.254  1647564404.147778219 MX67W flows src=10.255.11.1 dst=8.8.8.8 mac=**:**:**:**:**:** protocol=tcp sport=51260 dport=443 pattern: allow (dst 8.8.8.8/32)
Mar 18 19:14:46 10.255.11.254  1647564443.635272872 MX67W flows src=10.255.11.1 dst=1.1.1.1 mac=**:**:**:**:**:** protocol=tcp sport=51266 dport=443 pattern: deny (dst 1.1.1.1/32)
Mar 18 19:14:47 10.255.11.254  1647564444.648729352 MX67W flows src=10.255.11.1 dst=1.1.1.1 mac=**:**:**:**:**:** protocol=tcp sport=51266 dport=443 pattern: deny (dst 1.1.1.1/32)
Mar 18 19:14:49 10.255.11.254  1647564446.650971792 MX67W flows src=10.255.11.1 dst=1.1.1.1 mac=**:**:**:**:**:** protocol=tcp sport=51266 dport=443 pattern: deny (dst 1.1.1.1/32)
Mar 18 19:14:53 10.255.11.254  1647564450.651563792 MX67W flows src=10.255.11.1 dst=1.1.1.1 mac=**:**:**:**:**:** protocol=tcp sport=51266 dport=443 pattern: deny (dst 1.1.1.1/32)
Mar 18 19:15:01 10.255.11.254  1647564458.657929952 MX67W flows src=10.255.11.1 dst=1.1.1.1 mac=**:**:**:**:**:** protocol=tcp sport=51266 dport=443 pattern: deny (dst 1.1.1.1/32)

関連設定

Outbound方向でのアクセス制御は、Outbound rulesSite-to-site outbound firewall の2つの設定方法があるため、Syslog出力を有効化する設定箇所も分かれます。
アクセス制御の観点が異なる点に留意してください。

f:id:myhomenwlab:20220318233052j:plain
アクセス制御の設定箇所の観点

Syslog servers の設定

Syslogのログ種別はいくつかありますがアクセス可否のログを取得したい場合は、 メニュー: Network-wide > General の設定項目: Syslog serverRolesFlow を指定します。

f:id:myhomenwlab:20220318215859j:plain
Syslog servers の Role で Flows を指定

Outbound rules の設定

Outbound rules は「LANからUplinkへの物理Interfaceの出力方向」に適用されるルールになります。
通信ログを取得したい対象のルールで Syslog オプションを有効化します。

f:id:myhomenwlab:20220318220144j:plain
Outbound rules で Syslog オプションを有効化

Site-to-site outbound firewall の設定

Site-to-site outbound firewall は「Auto VPNトンネル経由の出力方向」に適用されるルールになります。
通信ログを取得したい対象のルールで Syslog オプションを有効化します。

f:id:myhomenwlab:20220318223826j:plain
Site-to-site outbound firewall で Syslog オプションを有効化

Flowログの出力を無効化するためのサポートへの依頼

Flowログの出力を無効化するには、サポートに依頼を行う必要があります。

設定対象の指定には2つの方法があります。

  • MerakiバイスのSerial Numberを対象にする。
  • Merakiの管理単位であるNetworkを対象にする。

Serial Numberで申請を行っていると、障害で機器交換が発生した際に代替機のSerial Numberを申請しなおす必要があるため、 本番環境ではNetworkを対象として無効化するのが好ましいと考えられます。

また、検証環境でMerakiバイスのNetworkの作成や削除を繰り返す場合は、 Network設定に依存しないSerial Numberを対象にした方が好ましい場合もあるため、適している設定方針を検討してください。

更にどちらの場合にしても、設定対象の管理をパラーメータ シートや管理台帳などで適宜行ってください。

状況によってはサポートへの依頼が間に合わないケースも生まれるため、ログの肥大化を確実に避けるのであればSyslog Server側でFlowログをフィルタも検討してください。

Merakiのライセンス、サポート、保守サービスの情報整理

Merakiのライセンス、サポート、保守サービスに関して情報を大まかに整理します。
主に購入時の観点で、勘違いしやすそうな点を中心にまとめました。

ライセンス

  • Merakiバイスを実際に利用するには、該当デバイスに対応するライセンスが必要になります。
  • MerakiバイスのWarranty (製品保証)は、Merakiバイスのハードウェア自体に含まれており、ライセンスには含まれていません。

サポート

  • Meraki Technical Supportへ問い合わせの権利はライセンスに含まれています。
  • ライセンスを持っていれば、Meraki Dashboard上からケースをオープンして問い合わせできます。

保守サービス

保守作業で機器交換のためのRMA (Return Merchandise Authorization)を行うには、大きく分けて3つの条件を満たしている必要があります。

  1. 対象のMerakiバイスがWarranty (製品保証)の期間内である必要があります。
    下記のドキュメントにWarrantyの期間の情報がまとまっています。

    documentation.meraki.com

  2. トラブルシューティングを行い、サポートの方から故障していると認定される必要があります。

  3. トラブルシューティングを行う必要があるため、実質的に対象Merakiバイスのライセンスを購入している必要があります。 そのためMerakiバイスがWarrantyの期間内であっても、ライセンスがない状態では実質的にRMAできないのが注意点となります。

また、保守サービスにはメーカー (Meraki)が提供する Cisco Meraki RMA Only Service と、代理店が提供する独自の保守もあります。 サービス内容が異なるため、標準のサービス レベルでは要件を満たせない場合は適宜購入を検討してください。

表現を変えると、検証用途などでサービス レベルを求めない場合は、Merakiバイス本体とライセンスの購入のみにしてコストの削減が可能です。

なお、代理店の独自保守に関しては、ダイワボウ情報システム社 (DIS社)のWebサイトが参考となるためリンクを掲載します。

www.idaten.ne.jp

関連ドキュメント

Meraki Communityの関連トピック

MerakiでRegionを指定して新たなOrganizationを作成する (アカウント作成済みの状態想定)

概要

Merakiのアカウントの作成済みの状態で、Regionを明示的に指定して新たなOrganizationを作成する方法を記載します。
すでにOrganizationが複数紐付いている場合はMSP Portalより新たなOrganizationを作成可能ですが、MSP Portalの場合はRegionを明示的には指定はできない点に留意してください。
なお、既存アカウントに複数のOrganizationを紐付けてマルチ テナント環境を作り、MSP Portalにて操作したい場合も本手順と共通となります。
※備考: MSP = Managed Service Providers

本記事は2022年03月頃の情報となっております。

MSP Portal

  • 1つのアカウントに対して複数のOrganizationが紐付くと、Meraki Dashboardへのログイン直後にOrganizationの選択画面が表示されるようになります。

    f:id:myhomenwlab:20220306220754j:plain
    Meraki Dashboardログイン後の Organization 選択画面

  • Meraki Dashboard の左ペインにはOrganizationの切り替えメニューが追加されます。MSP Portalのメニューを選択するとOrganizationが一覧表示されます。

    f:id:myhomenwlab:20220306220838j:plain
    MSP Portal 画面

  • MSP Portal 画面の Add organization がありますが、Regionを明示的に指定する設定項目はありません。

    f:id:myhomenwlab:20220313193144j:plain
    MSP Portal 画面からのOrganizationの作成

Region指定でのOrganization作成手順

Regionを指定して新たなOrganizationを作成する手順を記載します。

Meraki DashboardのLogin画面で Create an account の選択

  • Meraki DashboardのLogin画面を開き、Create an account を選択します。

    account.meraki.com

    f:id:myhomenwlab:20220306214232j:plain
    Meraki DashboardのLogin画面で Create an account の選択

    補足: Create an account は新しいアカウントを作成するためのメニューですが、既存アカウントを指定することで新たなOrganizationの作成も行えます。

Regionの選択

アカウント情報の入力画面

Create a net Meraki Dashboard account の画面では、Emailに既存アカウントのメール アドレスを入力します。

f:id:myhomenwlab:20220306214731j:plain
アカウント情報の入力画面 (1/2)

既存アカウントのメール アドレスが入力されると、入力欄の表示が少なくなります。

f:id:myhomenwlab:20220306214739j:plain
アカウント情報の入力画面 (2/2)

Password には、既存アカウントのパスワードを指定します。
Organization Name には、新たに作成されるOrganizationの名称を指定します。

Organization作成後のRegionの確認

Meraki Dashboardの画面下部にデータのホスト先のRegionが表示されるため、意図したRegionで作成されているか確認してください。

f:id:myhomenwlab:20220306214830j:plain
Organization作成後のRegionの確認

関連ドキュメント

documentation.meraki.com

documentation.meraki.com

Meraki Dashboard APIとセキュリティ設計

概要

Meraki Dashboard APIの有効化方法を交えながら、セキュリティ設計の観点で情報を整理します。
本記事の内容は2022年03月頃の情報をベースにしているため、適宜最新の情報を確認してください。

まず前提情報として、Meraki Dashboard APIを使用するには2つのステップを踏む必要があります。

  1. Organizationに対するAPIの使用を有効化します。
  2. AccountでAPI Keyを生成します。

ここで重要な点は、API KeyはAccountに紐付く点です。
さらにAccountには複数のOrganizationが紐付く場合があるため、単一のAPI Keyで複数のOrganizationにアクセスが可能になります。 よって、Organization毎に専用のAPI Keyが発行されない点に注意してください。

そしてAccountでAPI Keyを生成していても、OrganizationによってはAPIの使用を無効化している場合もあるため、 API KeyでアクセスができるOrganizationと、アクセスできないOrganizationに分かれます。

Meraki Dashboard APIのOrganizationやAccountとの関連性

実際の設定画面

実際の設定画面でAPIの有効化方法を確認してみましょう。

Organizationに対するAPIの使用可否を設定

メニュー: Organization > Settings より Dashboard API access セクションにある API Access にて、Organizationに対するAPIの使用可否を決定できます。

API Access

AccountでAPI Keyを生成

メニュー: Account名 > My profile より API access セクションにある Generate new API keyAPI Keyを生成可能です。

Account > My profile

API keys

古いAPI Keyと新しいAPI Keyの交換期間を設けれるように、API Keyは最大2つまで生成できます。API Keyが2スロット分あるイメージです。

API Keyとセキュリティの観点

API KeyはAccountの権限の範囲でOrganizationの情報にアクセスが可能であるため、 第三者API Keyが漏洩すると不正アクセスされる可能性があります。
API Keyはプログラムからの使用を前提とされている都合で、多要素認証による不正使用のブロックもできないので慎重に取り扱う必要があります。

そしてここで重要になるのは、Accountに複数のOrganizationが紐付いていれば、横断的なOrganizationのアクセスが可能になってしまう点になります。

API Key漏洩時の影響範囲

AccountとAPIの権限の限定

MerakiのAccountは、OrganizationレベルとNetworkレベルで権限を分けれます。
そのため、APIを使用するAccountにはアクセス対象のNetworkの限定や、必要最小限の権限の割り当てをして、API Key漏洩時の影響範囲を限定を検討してください。
更に必要に応じて、Organizationを跨ぐAccountを避ける方法も検討してください。 ただし、Accountが不必要に増えていくと管理が煩雑になり、管理漏れが起きるリスクも付きまとう点に留意が必要です。

AccountとAPIの権限の限定

また、API Keyの生成はAccountの使用者に委ねられており、管理者が制御できない点に留意してください。
AccountにAPI Keyが紐付いている都合で、Organizationを跨いだアクセスが可能である仕様になっているため、 特定のOrganizationにすぎない管理者が、AccountのAPI Keyに対する制御が行えないのが背景にあると推察されます。

そして、本記事の執筆時点 (2022年03月頃)で、Organization側でAPIを使用するAccountを個別に制限する機能はありません。 そのため、上述の権限の最小化で制御せざるを得ないのが実情です。

API使用対象のAccountを個別に制限する機能はない

Organizationレベルの制限

メニュー: Organization > Administrators では、OrganizationとNetworkの管理者の両方の設定が可能です。

  • Organizationの管理者として扱う場合は、Organization access の設定で Full (設定変更可)もしくは Read-only (読み取り専用)を適宜指定します。

    Organization管理者として扱う場合

  • Networkの管理者として扱う場合は、Organization access の設定は None として、Target に対象Networkを指定した上で Access に権限を指定します。

    Network管理者として扱う場合

  • Organizationでは Read-only で読み取り専用として、一部のNetworkには Full で設定変更の権限を与えるような組み合わせの設定も可能です。

    権限の組み合わせ

Networkレベルの制限

メニュー: Network-wide > Administration より Network admins にて、Networkに割り当てられている管理者の設定が可能です。
Networkの管理者は前述のメニュー: Organization > Administrators でも設定可能のため適宜使い分けてください。

Network admins

Meraki Dashboard APIの送信元IPアドレスの制限

メニュー: Organization > Settings より Login IP ranges セクションにある Limit Dashboard API access to these IP ranges にて、 "API使用者のみ"に対する送信元IPアドレスの制限を行えます。

Limit Dashboard and Dashboard API access to these IP ranges の設定項目だと、DashboardAPIの両方に適用されてしまうので設定を間違えないように注意してください。

Login IP ranges

Dashboardも含めて送信元IPアドレスを絞る場合は、 経由先のInternet RouterやForward Proxyなどの障害時にも迂回経路のIPアドレスでアクセスが可能になっている点を適宜確認してください。

関連ドキュメント

documentation.meraki.com

コミュニティの関連トピック

community.meraki.com

関連記事

myhomenwlab.hatenablog.com

myhomenwlab.hatenablog.com

Meraki MXのRouted Modeの製品特性

概要

Meraki MXには Routed Mode と Passthrough or VPN Concentrator がありますが、本記事では Routed Mode に焦点を当てて製品特性を整理します。

f:id:myhomenwlab:20220306010547j:plain
Meraki MXのMode

Meraki MXのRouted Modeの特性

Meraki MXのRouted Modeは、Internet Firewallに分類される製品特性を備えています。 基本的にRouted Modeの場合はInternetに面しての設置が想定されており、拠点へのInternet接続用のGatewayとしての導入が適しています。

セキュリティの側面ではInternet接続用のGatewayとしての役割が大きいのが理由で、 WAN←→LAN (North-South)の通信のアクセス制御に特化しております。
表現を変えると、境界型 (Zone-based)のFirewallではないため、 システム間のようなLAN←→LAN (East-West)の通信のアクセス制御には不向きとなります。

f:id:myhomenwlab:20220306011425j:plain
Meraki MXのRouted Modeの特性

Meraki MXと境界型のアクセス制御

Meraki MXには境界型 (Zone-based)のアクセス制御の概念がないため、Firewall Policyの制御は運用性が高くありません。
Merakiクラウド管理型の特性でInternetへの接続を前提としておりますが、その中でもMeraki MXはInternet接続用のGatewayの側面が強いため、 どうしてもLAN←→LAN (East-West)の通信の制御には不向きになっています。

f:id:myhomenwlab:20220306014618j:plain
Meraki MXと境界型のアクセス制御

Meraki MXのLayer 3 Firewall RulesにはZoneの概念はないため、送信元アドレスや宛先アドレスをベースとしたアクセス制御になります。

f:id:myhomenwlab:20220306202314j:plain
Meraki MXのLayer 3 Firewall Rules

Meraki MXのRouting Protocol対応状況

Meraki MXはModeと設定によってRouting Protocolの対応状況が異なります。
Merakiクラウド管理型のため、アーキテクチャ的にInternet側に流れる管理系の通信が異常な流量にならないような設計になっております。
その中でもMeraki MXは動的ルーティングでルートのフラップが発生しにくくなるように、状態変化が少なくなるアーキテクチャになっています。
そのため、OSPFはルートの広報は出来ますが、OSPF Neighborからのルートの動的な学習ができない仕様になっていると推察されます。

f:id:myhomenwlab:20220306013120j:plain
Meraki MXのRouting Protocol対応状況

Routing Protocol対応状況の中でも特に注意が必要なのが、 Routed ModeはLAN settingの設定により、OSPF (広報のみ・学習なし)の対応可否が異なる点です。
拠点によってLAN側の収容設計を変える場合は、本仕様の影響を受ける可能性があるため留意してください。

f:id:myhomenwlab:20220306012533j:plain
Routed ModeのOSPFに関わる設定

一般的なRouting & Switchの知識があるベテランほど、状態変化が少なくなるアーキテクチャにハマりやすい点があるため、下記の記事も適宜参照してください。

myhomenwlab.hatenablog.com

myhomenwlab.hatenablog.com

Meraki MXはLAN内のRouting Deviceとしての導入には不向き

Meraki MXのRouted ModeはInternet接続用のGatewayとしての機能に特化しているため、 LAN内でのRouting Deviceとしての導入には不向きとなります。

f:id:myhomenwlab:20220306013350j:plain
Meraki MXはLAN内のRouting Deviceとしての導入には不向き

UplinkはInternetへの接続を前提としているアーキテクチャとなっているため、Uplink側でOSPFとStatic Routeは設定できません。
Static RouteはLAN側に対して設定できますが、Uplinkに対する個別のStatic Routeは設定できないので勘違いしないように注意してください。

OSPFはAuto VPN Peerからのルートを広報をしますが、OSPFによる学習は行いません。 OSPFをルートの交換ではなく、経路を一方的に広報するのに使用するイメージとなります。

Meraki MXはUplinkでSource NATを行うため、LAN内のアドレスは隠蔽されます。 BETA機能 (2022年03月頃)のNAT Exceptions / No NATでSource NATの無効化は行えますが、 Internet接続用のGatewayは送信元NATがあってこそ成り立つため、Meraki MXの製品特性が瓦解しかねません。
その一例として、UplinkのWAN1とWAN2を用いたWAN負荷分散の機能は、 送信元NATを行って同じ出力Interface (WAN1,WAN2)に確実に通信が戻ってくるようにして成り立っています。

Meraki MX (Routed Mode)が適さない設計

Meraki MXで LAN setting を VLANs にして、多数のVLAN且つ1 Hop越えのセグメントを収容するのは不向きになります。
何故なら動的ルーティングの制御が弱いため、Meraki MX配下のL3 Deviceに対して多数のStatic Routeを設定する必要があるためです。
そして、Meraki MXのVLANs設定ではOSPF (広報のみ・学習なし)を設定できませんし。Meraki MXの配下のOSPF Router同士は、Meraki MXが介在してのOSPFでの経路交換も行えません。

f:id:myhomenwlab:20220306014656j:plain
Meraki MX (Routed Mode)が適さない設計

Meraki MXの制約を前提としたネットワーク設計

Meraki MXで多数のVLANやセグメントを収容するは難しいため、 1 Hop越えのセグメントを収容する場合は、通信を通過 (Transit)させるためのTransit VLANを1つ作成して、配下のMS (L3SW)にGatewayを一任するのが現実的です。

明確な設計意図があるなら、Transit VLANをサービス系と管理系で2つで分けるなども良いかとは思います。
ただし、Tagged VLANを使用するために、LAN setting を VLANs にするとOSPF (広報のみ・学習なし)は使用できない点に留意してください。

f:id:myhomenwlab:20220306015303j:plain
Meraki MXの制約を前提としたネットワーク設計

MerakiのMXとMS (L3SW)のLayer 3 Topologyの情報に関しては、下記のドキュメントに記載があります。

documentation.meraki.com

MS (L3SW)がEndpointのGatewayとなると、Meraki MXのFirewall Policyによるアクセス制御は行えないのが欠点になりますが、 そもそもMeraki MXはLAN←→LAN (East-West)のアクセス制御が不向きである点を思い出してください。

上述の内容は、あくまでも「1 Hop越えのセグメントを収容する場合」であるため、 MS (L2SW)のLayer 2 TopologyにてMeraki MXで多数のVLANやセグメントを収容するのは、管理性や運用性に問題が出なければそれも1つの設計方法だとは思います。

最後に

Merakiは機能が限定されていてシンプルが故に、設計箇所が限定されるため素早く大量展開を行いやすいのが利点です。
逆にシンプルさ故に多機能さによる設計のリカバリはできないため、Merakiの不向きな環境に無理やりに複雑な設計で導入するのは製品特性に大きく反してしまいます。
そのため、製品が不得意とする側面を理解した上で、製品特性の長所を活かす形での導入をオススメします。

Merakiデバイスの通信要件はDashboard上の情報が正となり、収容先のOrganizationによって変わる可能性がある

概要

Merakiバイスの通信要件は、Meraki Dashboard上の情報が正となります。 また、Merakiバイスを収容するOrganizationによって通信要件が変わる可能性があります。

documentation.meraki.com

そのため、本番環境と検証環境でOrganizationを分けてる場合などは、作業手順書内の通信要件が食い違ったりしないように注意してください。 また、使用する機能によって、表示される通信要件が変わる可能性があるため、最新の情報を参照するように意識してください。

Merakiの通信要件はOrganizationによって異なる

通信要件の表示

  • 通信要件は、メニュー: Help > Firewall info からFirewall informationを表示させて確認します。

    メニュー: Help > Firewall info

Rules as CSV と Unfiltered rules as CSV の違い

Firewall information 画面の Download... ボタンでは Rules as CSVUnfiltered rules as CSV の2種類のメニューがあります。

「Download...」ボタンの「Rules as CSV」と「Unfiltered rules as CSV

下記のように内容に差異が出る可能性があるため、ダウンロードする対象に注意してください。

WinMergeで比較した際の参考画面

Rules as CSVUnfiltered rules as CSV の違いはドキュメント上で明記されていなかったため、 2022年03月頃にサポートに問い合わせて確認を行いました。

Rules as CSV

Rules as CSV は、現時点で実際に必要な通信ルールのみに絞っています。
表現を変えると、通信ルールがフィルタされています。(Filtered)

Unfiltered rules as CSV

Unfiltered rules as CSVは、現時点では実際には不必要ですが、機能の使用可否などで変わる通信ルールまで含まれています。
表現を変えると、通信ルールがフィルタされていません。(Unfiltered)

注意点

Firewall information 画面と Rules as CSV でダウンロードしたCSVファイルは、現時点で実際に必要な通信ルールのみに絞られています。 よって、プロジェクト初期などで構築が全くの未着手の状態と、構築完了後の状態では通信要件に差異が出る可能性があります。
そのため、必要性に応じて Unfiltered rules as CSV でダウンロードしたCSVファイルから、今後必要になる通信要件を確認してください。

特に顧客に通信要件を提出するようなケースでは、設定作業の二度手間が起きないように正確な通信要件を確認してください。

参考例として、Organizationの初期状態と、 Network type: Combined hardware のNetworkを作成した後の Firewall information 画面を掲載します。
設定変更に起因して画面に表示されている通信要件が増えているのが分かります。

Organizationの初期状態

Network type: Combined hardware のNetworkの作成後

関連記事

myhomenwlab.hatenablog.com

MerakiのFimrware Upgradeの運用方法は、プロジェクトの早期に合意形成すべき

MerakiFirmware Upgradeの運用方法に関わる点を整理します。

Firmware Upgradeの基礎知識

MerakiFirmwareは新しいVersionが登場すると、自動的にスケジューリングされて約1~2週間前にメールで通知されます。
注意点として、手動でリスケジュールした場合は2度目のメール通知は来ません。

新しいFirmwareのスケジューリングと通知

Upgrade windowの指定

自動でスケジューリングされる曜日と時間は、Upgrade window にてNetwork単位で指定が可能です。 メニュー: Network-wide > General に Upgrade window の設定が存在します。 Network単位となるため、全てのNetworkを網羅するように設定が必要です。見逃しがないように注意してください。

Upgrade windowの設定画面

リスケジュールの注意点

リスケジュールする場合は約1ヶ月以内の範囲内での指定となります。

リスケジュールで指定可能な範囲

Firmware Upgradeの運用方法を顧客と合意形成されていない場合は、Upgradeを一時的に見送る場合が考えられます。 その場合はリスケジュールではなく、不意にUpgradeの処理が走らないように CANCEL でスケジュール自体の削除も検討してください。

スケジュールのキャンセル

運用方法を確立する重要性

Firmware Upgradeの管理を怠っていると、実際にUpgradeの処理が走ってからスケジューリングされていたことに気づく事故が起こりかねません。 そのような事故が実際に発生してしまうと、影響があった拠点を急いでめぐる全国行脚が発生する可能性もあり、事後処理のコストが高くなります。

特にConfiguration Templateを使用して全国のNetworkを管理していると、 Firmware Versionを統一して整合性を取るために、紐付けられているNetworkのFirmware Upgradeが順次実行されるため、 全国規模で機器の再起動が発生して取り返しがつかない事態に発展する可能性があります。

Firmware Upgradeの明示的なスケジューリングを失念してしまった最悪のケース

もしメール通知の見落としが懸念されるのであれば、 週次定例などの機会を利用して、関係者が定期的にMeraki Dashboardからスケジューリングがされていないか確認する運用方法なども検討してください。

そして何よりも重要なのが、最悪のケースを避けるためには、Firmware Upgradeの運用方法は顧客と早期に合意形成をすべき点です。
顧客との合意形成がないと、Upgrade window を指定するためのメンテナンス時間の確保すらままなりません。

Firmware Upgrade中のサービス断時間の観点

サービス断時間を懸念してFirmware Upgradeの頻度を少なくして、重要な脆弱性のみに限定してUpgradeを適用していくような顧客要望も想定されますが、 Merakiクラウド管理型で進化が早く、安定的な利用をしたい場合はFirmwareを安定版 (Stable)で更新し続けるべきです。 延々とFirmware Upgradeを先送りにするような運用方法は好ましくありません。

Meraki Communityに最新Firmwareが推奨される背景情報が整理されたので、顧客説明への根拠情報が増えました。(2023年10月頃 追記)

community.meraki.com

そして、そもそも論として、メンテナンスのためのダウンタイムも許されないような環境であれば、Merakiの製品特性が顧客環境に向いていません。 同じCisco製品であればCatalystシリーズなどの提案を検討してください。

関連ドキュメント

関連記事

myhomenwlab.hatenablog.com