Firepower 4100/9300 のクラスタリング
About Clustering on the Firepower 4100/9300 Chassis
クラスタリングのライセンス
クラスタリングの要件と前提条件
Clustering Guidelines and Limitations
クラスタリングの設定
FXOS: Remove a Cluster Node
FMC：クラスタメンバーの管理
Firewall Management Center：クラスタのモニタリング
- クラスタヘルスモニターダッシュボード
Firewall Management Center：クラスタのトラブルシューティング
- クラスター制御リンクへの ping の実行
Examples for Clustering
- Firewall on a Stick
- Traffic Segregation
Reference for Clustering
クラスタリングの履歴

Firepower 4100/9300 のクラスタリング

クラスタリングを利用すると、複数の Firewall Threat Defense ノードをグループ化して 1 つの論理デバイスとすることができます。クラスタは、単一デバイスのすべての利便性（管理、ネットワークへの統合）を備える一方で、複数デバイスによって高いスループットおよび冗長性を達成します。

（注）

クラスタリングを使用する場合、一部の機能はサポートされません。クラスタリングでサポートされない機能を参照してください。

About Clustering on the Firepower 4100/9300 Chassis

When you deploy a cluster on the Firepower 4100/9300 chassis, it does the following:

For native instance clustering: Creates a cluster-control link (by default, port-channel 48) for node-to-node communication.

For multi-instance clustering: You should pre-configure subinterfaces on one or more cluster-type EtherChannels; each instance needs its own cluster control link.

For a cluster isolated to security modules within one Firepower 9300 chassis, this link utilizes the Firepower 9300 backplane for cluster communications.

For clustering with multiple chassis, you need to manually assign physical interface(s) to this EtherChannel for communications between chassis.
Creates the cluster bootstrap configuration within the application.

When you deploy the cluster, the chassis supervisor pushes a minimal bootstrap configuration to each unit that includes the cluster name, cluster control link interface, and other cluster settings.

Assigns data interfaces to the cluster as Spanned interfaces.

For a cluster isolated to security modules within one Firepower 9300 chassis, spanned interfaces are not limited to EtherChannels, like it is for clustering with multiple chassis. The Firepower 9300 supervisor uses EtherChannel technology internally to load-balance traffic to multiple modules on a shared interface, so any data interface type works for Spanned mode. For clustering with multiple chassis, you must use Spanned EtherChannels for all data interfaces.

（注）

Individual interfaces are not supported, with the exception of a management interface.

Assigns a management interface to all units in the cluster.

See the following sections for more information about clustering.

Bootstrap Configuration

When you deploy the cluster, the Firepower 4100/9300 chassis supervisor pushes a minimal bootstrap configuration to each unit that includes the cluster name, cluster control link interface, and other cluster settings.

Cluster Members

Cluster members work together to accomplish the sharing of the security policy and traffic flows.

One member of the cluster is the control unit. The control unit is determined automatically. All other members are data units.

You must perform all configuration on the control unit only; the configuration is then replicated to the data units.

Some features do not scale in a cluster, and the control unit handles all traffic for those features. .

Cluster Control Link

For native instance clustering: The cluster control link is automatically created using the Port-channel 48 interface.

For multi-instance clustering: You should pre-configure subinterfaces on one or more cluster-type EtherChannels; each instance needs its own cluster control link.

For a cluster isolated to security modules within one Firepower 9300 chassis, this interface has no member interfaces. This Cluster type EtherChannel utilizes the Firepower 9300 backplane for cluster communications. For clustering with multiple chassis, you must add one or more interfaces to the EtherChannel.

For a cluster with two chassis, do not directly connect the cluster control link from one chassis to the other chassis. If you directly connect the interfaces, then when one unit fails, the cluster control link fails, and thus the remaining healthy unit fails. If you connect the cluster control link through a switch, then the cluster control link remains up for the healthy unit.

Cluster control link traffic includes both control and data traffic.

Size the Cluster Control Link

If possible, you should size the cluster control link to match the expected throughput of each chassis so the cluster control link can handle the worst-case scenarios.

Cluster control link traffic is comprised mainly of state update and forwarded packets. The amount of traffic at any given time on the cluster control link varies. The amount of forwarded traffic depends on the load-balancing efficacy or whether there is a lot of traffic for centralized features. For example:

NAT results in poor load balancing of connections, and the need to rebalance all returning traffic to the correct units.
When membership changes, the cluster needs to rebalance a large number of connections, thus temporarily using a large amount of cluster control link bandwidth.

A higher-bandwidth cluster control link helps the cluster to converge faster when there are membership changes and prevents throughput bottlenecks.

（注）

If your cluster has large amounts of asymmetric (rebalanced) traffic, then you should increase the cluster control link size.

Cluster Control Link Redundancy

The following diagram shows how to use an EtherChannel as a cluster control link in a Virtual Switching System (VSS), Virtual Port Channel (vPC), StackWise, or StackWise Virtual environment. All links in the EtherChannel are active. When the switch is part of a redundant system, then you can connect firewall interfaces within the same EtherChannel to separate switches in the redundant system. The switch interfaces are members of the same EtherChannel port-channel interface, because the separate switches act like a single switch. Note that this EtherChannel is device-local, not a Spanned EtherChannel.

Cluster Control Link Reliability for Inter-Chassis Clustering

To ensure cluster control link functionality, be sure the round-trip time (RTT) between units is less than 20 ms. This maximum latency enhances compatibility with cluster members installed at different geographical sites. To check your latency, perform a ping on the cluster control link between units.

The cluster control link must be reliable, with no out-of-order or dropped packets; for example, for inter-site deployment, you should use a dedicated link.

Cluster Control Link Network

The Firepower 4100/9300 chassis auto-generates the cluster control link interface IP address for each unit based on the chassis ID and slot ID: 127.2.chassis_id.slot_id. For multi-instance clusters, which typically use different VLAN subinterfaces of the same EtherChannel, the same IP address can be used for different clusters because of VLAN separation. The cluster control link network cannot include any routers between units; only Layer 2 switching is allowed.

Management Network

We recommend connecting all units to a single management network. This network is separate from the cluster control link.

管理インターフェイス

管理タイプのインターフェイスをクラスタに割り当てる必要があります。このインターフェイスはスパンドインターフェイスではなく、特別な個別インターフェイスです。管理インターフェイスによって各ユニットに直接接続できます。この管理論理インターフェイスはデバイスの他のインターフェイスから切り離されています。これは、Secure Firewall Management Center にデバイスを設定し、登録するために使用されます。独自のローカル認証、IP アドレス、およびスタティックルーティングを使用します。クラスタの各メンバーは、管理ネットワーク上で、それぞれに異なる IP アドレスを使用します。これらの IP アドレスは、ブートストラップ構成の一部としてユーザーが設定します。

Cluster Interfaces

For a cluster isolated to security modules within one Firepower 9300 chassis, you can assign both physical interfaces or EtherChannels (also known as port channels) to the cluster. Interfaces assigned to the cluster are Spanned interfaces that load-balance traffic across all members of the cluster.

For clustering with multiple chassis, you can only assign data EtherChannels to the cluster. These Spanned EtherChannels include the same member interfaces on each chassis; on the upstream switch, all of these interfaces are included in a single EtherChannel, so the switch does not know that it is connected to multiple devices.

You can use regular firewall interfaces or IPS-only interfaces (inline sets or passive interfaces).

Individual interfaces are not supported, with the exception of a management interface.

Spanned EtherChannels

You can group one or more interfaces per chassis into an EtherChannel that spans all chassis in the cluster. The EtherChannel aggregates the traffic across all the available active interfaces in the channel.

For regular firewall interfaces:A Spanned EtherChannel can be configured in both routed and transparent firewall modes. In routed mode, the EtherChannel is configured as a routed interface with a single IP address. In transparent mode, the IP address is assigned to the BVI, not to the bridge group member interface.

The EtherChannel inherently provides load balancing as part of basic operation.

For multi-instance clusters, each cluster requires dedicated data EtherChannels; you cannot use shared interfaces or VLAN subinterfaces.

Connecting to a Redundant Switch System

We recommend connecting EtherChannels to a redundant switch system such as a VSS, vPC, StackWise, or StackWise Virtual system to provide redundancy for your interfaces.

Configuration Replication

All nodes in the cluster share a single configuration. You can only make configuration changes on the control node (with the exception of the bootstrap configuration), and changes are automatically synced to all other nodes in the cluster.

クラスタリングのライセンス

個別のノードではなく、クラスタ全体に機能ライセンスを割り当てます。ただし、クラスタの各ノードは機能ごとに個別のライセンスを使用します。クラスタリング機能自体にライセンスは必要ありません。

クラスタノードを Firewall Management Center に追加する際に、そのクラスタに使用する機能ライセンスを指定できます。クラスタのライセンスは、[デバイス（Devices）] > [デバイス管理（Device Management）] > [クラスタ（Cluster）] > [ライセンス（License）] 領域で変更できます。

（注）

Firewall Management Center にライセンスを取得する（および評価モードで実行する）前にクラスタを追加した場合、Firewall Management Center にライセンスを取得する際にポリシーの変更をクラスタに展開するとトラフィックの中断が発生することがあります。ライセンスモードを変更したことによって、すべてのデータユニットがクラスタをいったん離れてから再参加することになります。

クラスタリングの要件と前提条件

クラスタモデルのサポート

Firewall Threat Defense は、次のモデルでのクラスタリングをサポートしています。

Firepower 9300：クラスタには最大 16 ノードを含めることができます。たとえば、16 のシャーシで 1 つのモジュールを使用したり、 8 つのシャーシで 2 つのモジュールを使用して、最大 16 のモジュールを組み合わせることができます。複数のシャーシによるクラスタリングと、1 つのシャーシ内のセキュリティモジュールに分離されたクラスタリングがサポートされます。
Firepower 4100：複数のシャーシでクラスタリングを使用して、最大 16 ノードがサポートされます。

User roles

Admin
Access Admin
Network Admin

クラスタリングハードウェアおよびソフトウェアの要件

All chassis in a cluster:

Native instance clustering—For the Firepower 4100: All chassis must be the same model. For the Firepower 9300: All security modules must be the same type. For example, if you use clustering, all modules in the Firepower 9300 must be SM-40s. You can have different quantities of installed security modules in each chassis, although all modules present in the chassis must belong to the cluster including any empty slots.
Container instance clustering—We recommend that you use the same security module or chassis model for each cluster instance. However, you can mix and match container instances on different Firepower 9300 security module types or Firepower 4100 models in the same cluster if required. You cannot mix Firepower 9300 and 4100 instances in the same cluster. For example, you can create a cluster using an instance on a Firepower 9300 SM-56, SM-48, and SM-40. Or you can create a cluster on a Firepower 4145 and a 4125.
Must run the identical FXOS and application software except at the time of an image upgrade. Mismatched software versions can lead to poor performance, so be sure to upgrade all nodes in the same maintenance window.
Must include the same interface configuration for interfaces you assign to the cluster, such as the same Management interface, EtherChannels, active interfaces, speed and duplex, and so on. You can use different network module types on the chassis as long as the capacity matches for the same interface IDs and interfaces can successfully bundle in the same spanned EtherChannel. Note that all data interfaces must be EtherChannels in clusters with multiple chassis. If you change the interfaces in FXOS after you enable clustering (by adding or removing interface modules, or configuring EtherChannels, for example), then perform the same changes on each chassis, starting with the data nodes, and ending with the control node.
Must use the same NTP server. For Firewall Threat Defense, the Firewall Management Center must also use the same NTP server. Do not set the time manually.

マルチインスタンスクラスタリングの要件

No intra-security-module/engine clustering—For a given cluster, you can only use a single container instance per security module/engine. You cannot add 2 container instances to the same cluster if they are running on the same module.
Mix and match clusters and standalone instances—Not all container instances on a security module/engine need to belong to a cluster. You can use some instances as standalone or High Availability nodes. You can also create multiple clusters using separate instances on the same security module/engine.
All 3 modules in a Firepower 9300 must belong to the cluster—For the Firepower 9300, a cluster requires a single container instance on all 3 modules. You cannot create a cluster using instances on module 1 and 2, and then use a native instance on module 3, or example.
Match resource profiles—We recommend that each node in the cluster use the same resource profile attributes; however, mismatched resources are allowed when changing cluster nodes to a different resource profile, or when using different models.
Dedicated cluster control link—For clusters with multiple chassis, each cluster needs a dedicated cluster control link. For example, each cluster can use a separate subinterface on the same cluster-type EtherChannel, or use separate EtherChannels.
No shared interfaces—Shared-type interfaces are not supported with clustering. However, the same Management and Eventing interfaces can used by multiple clusters.
No subinterfaces—A multi-instance cluster cannot use FXOS-defined VLAN subinterfaces. An exception is made for the cluster control link, which can use a subinterface of the Cluster EtherChannel.
Mix chassis models—We recommend that you use the same security module or chassis model for each cluster instance. However, you can mix and match container instances on different Firepower 9300 security module types or Firepower 4100 models in the same cluster if required. You cannot mix Firepower 9300 and 4100 instances in the same cluster. For example, you can create a cluster using an instance on a Firepower 9300 SM-56, SM-48, and SM-40. Or you can create a cluster on a Firepower 4145 and a 4125.
Maximum 6 nodes—You can use up to six container instances in a cluster.

スイッチ要件

Be sure to complete the switch configuration and successfully connect all the EtherChannels from the chassis to the switch(es) before you configure clustering on the Firepower 4100/9300 chassis.
For supported switch characteristics, see Cisco FXOS Compatibility.

Clustering Guidelines and Limitations

Switches for Clustering

Make sure connected switches match the MTU for both cluster data interfaces and the cluster control link interface. You should configure the cluster control link interface MTU to be at least 100 bytes higher than the data interface MTU, so make sure to configure the cluster control link connecting switch appropriately. Because the cluster control link traffic includes data packet forwarding, the cluster control link needs to accommodate the entire size of a data packet plus cluster traffic overhead. In addition, we do not recommend setting the cluster control link MTU between 2561 and 8362; due to block pool handling, this MTU size is not optimal for system operation. When a node joins the cluster, it checks MTU compatibility by sending a ping to the control node with a packet size matching the cluster control link MTU. If the ping fails, a notification is generated so you can fix the MTU mismatch on connecting switches and try again.
For Cisco IOS XR systems, if you want to set a non-default MTU, set the IOS XR interface MTU to be 14 bytes higher than the cluster device MTU. Otherwise, OSPF adjacency peering attempts may fail unless the mtu-ignore option is used. Note that the cluster device MTU should match the IOS XR IPv4 MTU. This adjustment is not required for Cisco Catalyst and Cisco Nexus switches.
On the switch(es) for the cluster control link interfaces, you can optionally enable Spanning Tree PortFast on the switch ports connected to the cluster unit to speed up the join process for new units.
On the switch, we recommend that you use one of the following EtherChannel load-balancing algorithms: source-dest-ip or src-dst-mixed-ip-port (see the Cisco Nexus OS and Cisco IOS-XE port-channel load-balance command). Do not use a vlan keyword in the load-balance algorithm because it can cause unevenly distributed traffic to the devices in a cluster.
If you change the load-balancing algorithm of the EtherChannel on the switch, the EtherChannel interface on the switch temporarily stops forwarding traffic, and the Spanning Tree Protocol restarts. There will be a delay before traffic starts flowing again.
Switches on the cluster control link path should not verify the L4 checksum. Redirected traffic over the cluster control link does not have a correct L4 checksum. Switches that verify the L4 checksum could cause traffic to be dropped.
Port-channel bundling downtime should not exceed the configured keepalive interval.
On Supervisor 2T EtherChannels, the default hash distribution algorithm is adaptive. To avoid asymmetric traffic in a VSS design, change the hash algorithm on the port-channel connected to the cluster device to fixed:

router(config)# port-channel id hash-distribution fixed

Do not change the algorithm globally; you may want to take advantage of the adaptive algorithm for the VSS peer link.

Firepower 4100/9300 clusters support LACP graceful convergence. So you can leave LACP graceful convergence enabled on connected Cisco Nexus switches.
When you see slow bundling of a Spanned EtherChannel on the switch, you can enable LACP rate fast for an individual interface on the switch. FXOS EtherChannels have the LACP rate set to fast by default. Note that some switches, such as the Nexus series, do not support LACP rate fast when performing in-service software upgrades (ISSUs), so we do not recommend using ISSUs with clustering.

EtherChannels for Clustering

In Catalyst 3750-X Cisco IOS software versions earlier than 15.1(1)S2, the cluster unit did not support connecting an EtherChannel to a switch stack. With default switch settings, if the cluster unit EtherChannel is connected cross stack, and if the control unit switch is powered down, then the EtherChannel connected to the remaining switch will not come up. To improve compatibility, set the stack-mac persistent timer command to a large enough value to account for reload time; for example, 8 minutes or 0 for indefinite. Or, you can upgrade to more a more stable switch software version, such as 15.1(1)S2.
Spanned vs. Device-Local EtherChannel Configuration—Be sure to configure the switch appropriately for Spanned EtherChannels vs. Device-local EtherChannels.
- Spanned EtherChannels—For cluster unit Spanned EtherChannels, which span across all members of the cluster, the interfaces are combined into a single EtherChannel on the switch. Make sure each interface is in the same channel group on the switch.
- Device-local EtherChannels—For cluster unit Device-local EtherChannels including any EtherChannels configured for the cluster control link, be sure to configure discrete EtherChannels on the switch; do not combine multiple cluster unit EtherChannels into one EtherChannel on the switch.

Additional Guidelines

When significant topology changes occur (such as adding or removing an EtherChannel interface, enabling or disabling an interface on the Firepower 4100/9300 chassis or the switch, adding an additional switch to form a VSS, vPC, StackWise, or StackWise Virtual) you should disable the health check feature, and also disable interface monitoring for the disabled interfaces . When the topology change is complete, and the configuration change is synced to all units, you can re-enable the health check feature.
When adding a unit to an existing cluster, or when reloading a unit, there will be a temporary, limited packet/connection drop; this is expected behavior. In some cases, the dropped packets can hang connections; for example, dropping a FIN/ACK packet for an FTP connection will make the FTP client hang. In this case, you need to reestablish the FTP connection.
If you use a Windows 2003 server connected to a Spanned EtherChannel interface, when the syslog server port is down, and the server does not throttle ICMP error messages, then large numbers of ICMP messages are sent back to the cluster. These messages can result in some units of the cluster experiencing high CPU, which can affect performance. We recommend that you throttle ICMP error messages.
We recommend connecting EtherChannels to a VSS, vPC, StackWise, or StackWise Virtual for redundancy.
Within a chassis, you cannot cluster some security modules and run other security modules in standalone mode; you must include all security modules in the cluster.
For decrypted TLS/SSL connections, the decryption states are not synchronized, and if the connection owner fails, then decrypted connections will be reset. New connections will need to be established to a new unit. Connections that are not decrypted (they match a do-not-decrypt rule) are not affected and are replicated correctly.

Defaults

The cluster health check feature is enabled by default with the holdtime of 3 seconds. Interface health monitoring is enabled on all interfaces by default.
The cluster auto-rejoin feature for a failed cluster control link is set to unlimited attempts every 5 minutes.
The cluster auto-rejoin feature for a failed data interface is set to 3 attempts every 5 minutes, with the increasing interval set to 2.
Connection replication delay of 5 seconds is enabled by default for HTTP traffic.

クラスタリングの設定

クラスタは、Firepower 4100/9300 スーパバイザから簡単に展開できます。すべての初期設定が各ユニット用に自動生成されます。その後、ユニットを Firewall Management Center に追加し、1 つのクラスタにグループ化できます。

FXOS: Add a Firewall Threat Defense Cluster

In native mode: You can add a cluster to a single Firepower 9300 chassis that is isolated to security modules within the chassis, or you can use multiple chassis.

In multi-instance mode: You can add one or more clusters to a single Firepower 9300 chassis that are isolated to security modules within the chassis (you must include an instance on each module), or add one or more clusters on multiple chassis.

For clusters on multiple chassis, you must configure each chassis separately. Add the cluster on one chassis; you can then copy the bootstrap configuration from the first chassis to the next chassis for ease of deployment

Create a Firewall Threat Defense Cluster

You can easily deploy the cluster from the Firepower 4100/9300 chassis supervisor. All initial configuration is automatically generated for each unit.

For clustering on multiple chassis, you must configure each chassis separately. Deploy the cluster on one chassis; you can then copy the bootstrap configuration from the first chassis to the next chassis for ease of deployment.

In a Firepower 9300 chassis, you must enable clustering for all 3 module slots, or for container instances, a container instance in each slot, even if you do not have a module installed. If you do not configure all 3 modules, the cluster will not come up.

始める前に

Download the application image you want to use for the logical device from Cisco.com, and then upload that image to the Firepower 4100/9300 chassis.
For container instances, if you do not want to use the default profile, add a resource profile according to Add a Resource Profile for Container Instances.
For container instances, before you can install a container instance for the first time, you must reinitialize the security module/engine so that the disk has the correct formatting. Choose Security Modules or Security Engine, and click the Reinitialize icon (). An existing logical device will be deleted and then reinstalled as a new device, losing any local application configuration. If you are replacing a native instance with container instances, you will need to delete the native instance in any case. You cannot automatically migrate a native instance to a container instance.
Gather the following information:
- Management interface ID, IP addresses, and network mask
- Gateway IP address
- Firewall Management Center IP address and/or NAT ID of your choosing
- DNS server IP address
- Firewall Threat Defense hostname and domain name

手順

ステップ 1

Configure interfaces.

Add at least one Data type interface or EtherChannel (also known as a port-channel) before you deploy the cluster. See Add an EtherChannel (Port Channel) or Configure a Physical Interface.

For clustering on multiple chassis, all data interfaces must be Spanned EtherChannels with at least one member interface. Add the same EtherChannels on each chassis. Combine the member interfaces from all cluster units into a single EtherChannel on the switch. See Clustering Guidelines and Limitations for more information about EtherChannels.

For multi-instance clustering, you cannot use FXOS-defined VLAN subinterfaces or data-sharing interfaces in the cluster. Only application-defined subinterfaces are supported. See FXOS Interfaces vs. Application Interfaces for more information.
Add a Management type interface or EtherChannel. See Add an EtherChannel (Port Channel) or Configure a Physical Interface.

The management interface is required. Note that this management interface is not the same as the chassis management interface that is used only for chassis management (in FXOS, you might see the chassis management interface displayed as MGMT, management0, or other similar names).

For clustering on multiple chassis, add the same Management interface on each chassis.

For multi-instance clustering, you can share the same management interface across multiple clusters on the same chassis, or with standalone instances.
For clustering on multiple chassis, add a member interface to the cluster control link EtherChannel (by default, port-channel 48). See Add an EtherChannel (Port Channel).

Do not add a member interface for a cluster isolated to security modules within one Firepower 9300 chassis. If you add a member, the chassis assumes this cluster will be using multiple chassis, and will only allow you to use Spanned EtherChannels, for example.

On the Interfaces tab, the port-channel 48 cluster type interface shows the Operation State as failed if it does not include any member interfaces. For a cluster isolated to security modules within one Firepower 9300 chassis, this EtherChannel does not require any member interfaces, and you can ignore this Operational State.

Add the same member interfaces on each chassis. The cluster control link is a device-local EtherChannel on each chassis. Use separate EtherChannels on the switch per device. See Clustering Guidelines and Limitations for more information about EtherChannels.

For multi-instance clustering, you can create additional Cluster type EtherChannels. Unlike the Management interface, the cluster control link is not sharable across multiple devices, so you will need a Cluster interface for each cluster. However, we recommend using VLAN subinterfaces instead of multiple EtherChannels; see the next step to add a VLAN subinterface to the Cluster interface.
For multi-instance clustering, add VLAN subinterfaces to the cluster EtherChannel so you have a subinterface for each cluster. See Add a VLAN Subinterface for Container Instances.

If you add subinterfaces to a Cluster interface, you cannot use that interface for a native cluster.
（任意） Add an eventing interface. See Add an EtherChannel (Port Channel) or Configure a Physical Interface.

This interface is a secondary management interface for the Firewall Threat Defense devices. To use this interface, you must configure its IP address and other parameters at the Firewall Threat Defense CLI. For example, you can separate management traffic from events (such as web events). See the configure network commands in the Firewall Threat Defense command reference.

For clustering on multiple chassis, add the same eventing interface on each chassis.

ステップ 2

Choose Logical Devices.

ステップ 3

Click Add > Cluster, and set the following parameters:

Choose I want to: > Create New Cluster
Provide a Device Name.

This name is used internally by the chassis supervisor to configure management settings and to assign interfaces; it is not the device name used in the application configuration.
For the Template, choose Cisco Firepower Threat Defense.
Choose the Image Version.
For the Instance Type, choose either Native or Container.

A native instance uses all of the resources (CPU, RAM, and disk space) of the security module/engine, so you can only install one native instance. A container instance uses a subset of resources of the security module/engine, so you can install multiple container instances.

(Container Instance only) For the Resource Type, choose one of the resource profiles from the drop-down list.

For the Firepower 9300, this profile will be applied to each instance on each security module. You can set different profiles per security module later in this procedure; for example, if you are using different security module types, and you want to use more CPUs on a lower-end model. We recommend choosing the correct profile before you create the cluster. If you need to create a new profile, cancel out of the cluster creation, and add one using Add a Resource Profile for Container Instances.

（注）

If you assign a different profile to instances in an established cluster, which allows mismatched profiles, then apply the new profile on the data nodes first; after they reboot and come back up, you can apply the new profile to the control node.

Click OK.

You see the Provisioning - device name window.

ステップ 4

Choose the interfaces you want to assign to this cluster.

For native mode clustering: All valid interfaces are assigned by default. If you defined multiple Cluster type interfaces, deselect all but one.

For multi-instance clustering: Choose each data interface you want to assign to the cluster, and also choose the Cluster type port-channel or port-channel subinterface.

ステップ 5

Click the device icon in the center of the screen.

A dialog box appears where you can configure initial bootstrap settings. These settings are meant for initial deployment only, or for disaster recovery. For normal operation, you can later change most values in the application CLI configuration.

ステップ 6

On the Cluster Information page, complete the following.

(Container Instance for the Firepower 9300 only) In the Security Module (SM) and Resource Profile Selection area, you can set a different resource profile per module; for example, if you are using different security module types, and you want to use more CPUs on a lower-end model.
For clustering on multiple chassis, in the Chassis ID field, enter a chassis ID. Each chassis in the cluster must use a unique ID.

This field only appears if you added a member interface to cluster control link Port-Channel 48.
For inter-site clustering, in the Site ID field, enter the site ID for this chassis between 1 and 8. FlexConfig feature. Additional inter-site cluster customizations to enhance redundancy and stability, such as director localization, site redundancy, and cluster flow mobility, are only configurable using the Firewall Management Center FlexConfig feature.
In the Cluster Key field, configure an authentication key for control traffic on the cluster control link.

The shared secret is an ASCII string from 1 to 63 characters. The shared secret is used to generate the key. This option does not affect datapath traffic, including connection state update and forwarded packets, which are always sent in the clear.

Set the Cluster Group Name, which is the cluster group name in the logical device configuration.

The name must be an ASCII string from 1 to 38 characters.

重要	From 2.4.1, spaces in cluster group name will be considered as special characters and may result in error while deploying the logical devices. To avoid this issue, you must rename the cluster group name without a space.

Choose the Management Interface.

This interface is used to manage the logical device. This interface is separate from the chassis management port.

If you assign a Hardware Bypass-capable interface as the Management interface, you see a warning message to make sure your assignment is intentional.
（任意） Set the CCL Subnet IP as a.b.0.0.

By default, the cluster control link uses the 127.2.0.0/16 network. However, some networking deployments do not allow 127.2.0.0/16 traffic to pass. In this case, specify any /16 network address on a unique network for the cluster, except for loopback (127.0.0.0/8), multicast (224.0.0.0/4), and internal (169.254.0.0/16) addresses. If you set the value to 0.0.0.0, then the default network is used.

The chassis auto-generates the cluster control link interface IP address for each unit based on the chassis ID and slot ID: a.b.chassis_id.slot_id.

ステップ 7

On the Settings page, complete the following.

In the Registration Key field, enter the key to be shared between the Firewall Management Center and the cluster members during registration.

You can choose any text string for this key between 1 and 37 characters; you will enter the same key on the Firewall Management Center when you add the Firewall Threat Defense.
Enter a Password for the Firewall Threat Defense admin user for CLI access.
In the Firepower Management Center IP field, enter the IP address of the managing Firewall Management Center. If you do not know the Firewall Management Center IP address, leave this field blank and enter a passphrase in the Firepower Management Center NAT ID field.
（任意） For a container instance, Permit Expert mode from FTD SSH sessions: Yes or No. Expert Mode provides Firewall Threat Defense shell access for advanced troubleshooting.

If you choose Yes for this option, then users who access the container instance directly from an SSH sesssion can enter Expert Mode. If you choose No, then only users who access the container instance from the FXOS CLI can enter Expert Mode. We recommend choosing No to increase isolation between instances.

Use Expert Mode only if a documented procedure tells you it is required, or if the Cisco Technical Assistance Center asks you to use it. To enter this mode, use the expert command in the Firewall Threat Defense CLI.
（任意） In the Search Domains field, enter a comma-separated list of search domains for the management network.
（任意） From the Firewall Mode drop-down list, choose Transparent or Routed.

In routed mode, the Firewall Threat Defense is considered to be a router hop in the network. Each interface that you want to route between is on a different subnet. A transparent firewall, on the other hand, is a Layer 2 firewall that acts like a “bump in the wire,” or a “stealth firewall,” and is not seen as a router hop to connected devices.

The firewall mode is only set at initial deployment. If you re-apply the bootstrap settings, this setting is not used.
（任意） In the DNS Servers field, enter a comma-separated list of DNS servers.

The Firewall Threat Defense uses DNS if you specify a hostname for the Firewall Management Center, for example.
（任意） In the Firepower Management Center NAT ID field, enter a passphrase that you will also enter on the Firewall Management Center when you add the cluster as a new device.

Normally, you need both IP addresses (along with a registration key) for both routing purposes and for authentication: the Firewall Management Center specifies the device IP address, and the device specifies the Firewall Management Center IP address. However, if you only know one of the IP addresses, which is the minimum requirement for routing purposes, then you must also specify a unique NAT ID on both sides of the connection to establish trust for the initial communication and to look up the correct registration key. You can specify any text string as the NAT ID, from 1 to 37 characters. The Firewall Management Center and device use the registration key and NAT ID (instead of IP addresses) to authenticate and authorize for initial registration.
（任意） In the Fully Qualified Hostname field, enter a fully qualified name for the Firewall Threat Defense device.

Valid characters are the letters from a to z, the digits from 0 to 9, the dot (.), and the hyphen (-); maximum number of characters is 253.
（任意） From the Eventing Interface drop-down list, choose the interface on which events should be sent. If not specified, the management interface will be used.

To specify a separate interface to use for events, you must configure an interface as a firepower-eventing interface. If you assign a Hardware Bypass-capable interface as the Eventing interface, you see a warning message to make sure your assignment is intentional.

ステップ 8

On the Interface Information page, configure a management IP address for each security module in the cluster. Select the type of address from the Address Type drop-down list and then complete the following for each security module.

（注）

You must set the IP address for all 3 module slots in a chassis, even if you do not have a module installed. If you do not configure all 3 modules, the cluster will not come up.

In the Management IP field, configure an IP address.

Specify a unique IP address on the same network for each module.
Enter a Network Mask or Prefix Length.
Enter a Network Gateway address.

ステップ 9

On the Agreement tab, read and accept the end user license agreement (EULA).

ステップ 10

Click OK to close the configuration dialog box.

ステップ 11

Click Save.

The chassis deploys the logical device by downloading the specified software version and pushing the bootstrap configuration and management interface settings to the application instance. Check the Logical Devices page for the status of the new logical device. When the logical device shows its Status as online, you can add the remaining cluster chassis, or for a cluster isolated to security modules within one Firepower 9300 chassis, start configuring the cluster in the application. You may see the "Security module not responding" status as part of the process; this status is normal and is temporary.

ステップ 12

For clustering on multiple chassis, add the next chassis to the cluster:

On the first chassis of the Firewall Chassis Manager, click the Show Configuration icon at the top right; copy the displayed cluster configuration.
Connect to the Firewall Chassis Manager on the next chassis, and add a logical device according to this procedure.
Choose I want to: > Join an Existing Cluster.
Click OK.
In the Copy Cluster Details box, paste in the cluster configuration from the first chassis, and click OK.
Click the device icon in the center of the screen. The cluster information is mostly pre-filled, but you must change the following settings:
- Chassis ID—Enter a unique chassis ID.
- Site ID—For inter-site clustering, enter the site ID for this chassis between 1 and 8. Additional inter-site cluster customizations to enhance redundancy and stability, such as director localization, site redundancy, and cluster flow mobility, are only configurable using the Firewall Management Center FlexConfig feature.
- Cluster Key—(Not prefilled) Enter the same cluster key.
- Management IP—Change the management address for each module to be a unique IP address on the same network as the other cluster members.
Click OK.
Click Save.

The chassis deploys the logical device by downloading the specified software version and pushing the bootstrap configuration and management interface settings to the application instance. Check the Logical Devices page for each cluster member for the status of the new logical device. When the logical device for each cluster member shows its Status as online, you can start configuring the cluster in the application. You may see the "Security module not responding" status as part of the process; this status is normal and is temporary.

ステップ 13

Add the control unit to the Firewall Management Center using the management IP address.

All cluster units must be in a successfully-formed cluster on FXOS prior to adding them to Firewall Management Center.

The Firewall Management Center then automatically detects the data units.

Add More Cluster Nodes

Add or replace the Firewall Threat Defense cluster node in an existing cluster. When you add a new cluster node in FXOS, the Firewall Management Center adds the node automatically.

（注）

The FXOS steps in this procedure only apply to adding a new chassis; if you are adding a new module to a Firepower 9300 where clustering is already enabled, the module will be added automatically.

始める前に

In the case of a replacement, you must delete the old cluster node from the Firewall Management Center. When you replace it with a new node, it is considered to be a new device on the Firewall Management Center.
The interface configuration must be the same on the new chassis. You can export and import FXOS chassis configuration to make this process easier.

手順

ステップ 1

If you previously upgraded the Firewall Threat Defense image using the Firewall Management Center, perform the following steps on each chassis in the cluster.

When you upgraded from the Firewall Management Center, the startup version in the FXOS configuration was not updated, and the standalone package was not installed on the chassis. Both of these items need to be set manually so the new node can join the cluster using the correct image version.

（注）

If you only applied a patch release, you can skip this step. Cisco does not provide standalone packages for patches.

Install the running Firewall Threat Defense image on the chassis using the System > Updates page.
Click Logical Devices and click the Set Version icon (). For a Firepower 9300 with multiple modules, set the version for each module.

The Startup Version shows the original package you deployed with. The Current Version shows the version you upgraded to.
In the New Version drop-down menu, choose the version that you uploaded. This version should match the Current Version displayed, and will set the startup version to match the new version.
On the new chassis, make sure the new image package is installed.

ステップ 2

On an existing cluster chassis Firewall Chassis Manager, click Logical Devices.

ステップ 3

Click the Show Configuration icon at the top right; copy the displayed cluster configuration.

ステップ 4

Connect to the Firewall Chassis Manager on the new chassis, and click Add > Cluster.

ステップ 5

For the Device Name, provide a name for the logical device.

ステップ 6

Click OK.

ステップ 7

In the Copy Cluster Details box, paste in the cluster configuration from the first chassis, and click OK.

ステップ 8

Click the device icon in the center of the screen. The cluster information is partly pre-filled, but you must fill in the following settings:

Chassis ID—Enter a unique chassis ID.
Site ID—For inter-site clustering, enter the site ID for this chassis between 1 and 8. This feature is only configurable using the Firewall Management Center FlexConfig feature.
Cluster Key—Enter the same cluster key.
Management IP—Change the management address for each module to be a unique IP address on the same network as the other cluster members.
Fully Qualified Hostname—Enter the same hostname.
Password—Enter the same password.
Registration Key—Enter the same registration key.

Click OK.

ステップ 9

Click Save.

The chassis deploys the logical device by downloading the specified software version and pushing the bootstrap configuration and management interface settings to the application instance. Check the Logical Devices page for each cluster member for the status of the new logical device. When the logical device for each cluster member shows its Status as online, you can start configuring the cluster in the application. You may see the "Security module not responding" status as part of the process; this status is normal and is temporary.

Firewall Management Center：クラスタの追加

クラスタユニットのいずれかを新しいデバイスとして Secure Firewall Management Center に追加します。Firewall Management Center は、他のすべてのクラスタメンバーを自動検出します。

始める前に

すべてのクラスタユニットは、Firewall Management Center に追加する前に、FXOS 上にある正常な形式のクラスタ内に存在している必要があります。また、どのユニットが制御ユニットかを確認することも必要です。Firewall Chassis Manager の [論理デバイス（Logical Devices）] 画面を参照するか、Firewall Threat Defense の show cluster info コマンドを使用します。

手順

ステップ 1	Firewall Management Center で、[デバイス（Devices）] > [デバイス管理（Device Management）] を選択してから、[追加（Add）] > [デバイスの追加（Add Device）] を選択し、クラスタを展開したときに割り当てた制御ユニットの管理 IP アドレスを使用して制御ユニットを追加します。図 8. デバイスの追加 [ホスト（Host）] フィールドに、制御ユニットの IP アドレスまたはホスト名を入力します。最適なパフォーマンスを得るため、制御ユニットの追加を推奨しますが、クラスタの任意のユニットを追加できます。デバイスのセットアップ時に NAT ID を使用した場合は、このフィールドを入力する必要がない可能性があります。詳細については、「NAT 環境」を参照してください。 [表示名（Display Name）] フィールドに、Firewall Management Center での制御ユニットの表示名を入力します。この表示名はクラスタ用ではありません。追加する制御ユニット専用です。後で、他のクラスタメンバーの名前やクラスタ表示名を変更できます。 [登録キー（Registration Key）] フィールドに、FXOS にクラスタを展開したときに使用したものと同じ登録キーを入力します。登録キーは、1 回限り使用可能な共有シークレットです。（任意）デバイスをデバイスグループに追加します。登録後すぐに、デバイスに展開する最初の [アクセスコントロールポリシー（Access Control Policy）] を選択するか、新しいポリシーを作成します。新しいポリシーを作成する場合は、基本ポリシーのみを作成します。必要に応じて、後でポリシーをカスタマイズできます。デバイスに適用するライセンスを選択します。デバイスの設定時に、NAT ID を使用した場合、[詳細（Advanced）] セクションを展開し、[一意の NAT ID（Unique NAT ID）] フィールドに同じ NAT ID を入力します。 [パケットの転送（Transfer Packets）] チェックボックスをオンにし、デバイスで Firewall Management Center にパケットを転送することを許可します。このオプションは、デフォルトで有効です。このオプションを有効にして IPS や Snort などのイベントがトリガーされた場合は、デバイスが検査用としてイベントメタデータ情報とパケットデータを Firewall Management Center に送信します。このオプションを無効にした場合は、イベント情報だけが Firewall Management Center に送信され、パケットデータは送信されません。 [登録（Register）] をクリックします。 Firewall Management Center は、制御ユニットを識別して登録した後に、すべてのデータユニットを登録します。制御ユニットが正常に登録されていない場合、クラスタは追加されません。クラスタがシャーシで稼働状態になかったか、その他の接続問題が原因で、登録エラーが発生する場合があります。こうした状況では、クラスタユニットを再度追加することをお勧めします。 [デバイス（Devices）] > [デバイス管理（Device Management）] ページにクラスタ名が表示されます。クラスタを展開して、クラスタユニットを表示します。現在登録されているユニットには、ロードアイコンが表示されます。クラスタユニットの登録をモニターするには、[通知（Notifications）] アイコンをクリックし、[タスク（Tasks）] を選択します。Firewall Management Center は、ユニットの登録ごとにクラスタ登録タスクを更新します。いずれかのユニットの登録に失敗した場合には、クラスタメンバーの照合を参照してください。
ステップ 2	クラスタの Edit () をクリックして、デバイス固有の設定を指定します。ほとんどの設定は、クラスタ内のメンバーユニットではなくクラスタ全体に適用できます。たとえば、ユニットごとに表示名を変更できますが、インターフェイスはクラスタ全体についてのみ設定できます。
ステップ 3	[デバイス（Devices）] > [デバイス管理（Device Management）] > [クラスタ（Cluster）] 画面に、[全般（General）]、[ライセンス（License）]、[システム（System）]、および [ヘルス（Health）] の設定が表示されます。次のクラスタ固有の項目を参照してください。 [全般（General）] > [名前（Name）]：Edit () をクリックして、クラスタの表示名を変更します。その後に、[名前（Name）] フィールドを設定します。 [全般（General）] > [クラスタステータスの表示（View cluster status）]：[クラスタステータスの表示（View cluster status）] リンクをクリックして [クラスタステータス（Cluster Status）] ダイアログボックスを開きます。 [クラスタステータス（Cluster Status）] ダイアログボックスで、[照合（Reconcile）] をクリックしてデータユニットの登録を再試行することもできます。 [全般（General）] > [トラブルシュート（Troubleshoot）]：トラブルシューティングログを生成およびダウンロードしたり、クラスタ CLI を表示したりできます。Firewall Management Center：クラスタのトラブルシューティングを参照してください。図 9. トラブルシューティング [ライセンス（License）]：Edit () をクリックして、ライセンス付与資格を設定します。
ステップ 4	[デバイス（Devices）] > [デバイス管理（Device Management）] > [デバイス（Devices）] の右上のドロップダウンメニューで、クラスタ内の各メンバーを選択し、次の設定を指定することができます。 [全般（General）] > [名前（Name）]：Edit () をクリックして、クラスタメンバーの表示名を変更します。その後に、[名前（Name）] フィールドを設定します。 [管理（Management）] > [ホスト（Host）]：デバイス設定で管理 IP アドレスを変更する場合、Firewall Management Center で新しいアドレスを一致させてネットワーク上のデバイスに到達できるようにし、[管理（Management）] 領域で [ホスト（Host）] アドレスを編集します。

Firewall Management Center：クラスタ、データインターフェイスの設定

この手順では、FXOS にクラスタを展開したときにクラスタに割り当てられた各データインターフェイスの基本的なパラメータを設定します。複数のシャーシにわたるクラスタリングの場合、データインターフェイスは常にスパンド EtherChannel インターフェイスです。1 つのFirepower 9300 シャーシ内のセキュリティモジュール内に隔離されたクラスタのクラスタ制御リンクインターフェイスの場合、MTU をデフォルトから増やす必要があります。

（注）

複数のシャーシによるクラスタリングにスパンド EtherChannel を使用している場合、クラスタリングが完全に有効になるまで、ポートチャネルインターフェイスは起動しません。この要件により、クラスタのアクティブではないユニットにトラフィックが転送されるのが防がれます。

手順

ステップ 1

[デバイス（Devices）] > [デバイス管理（Device Management）] を選択し、クラスタの横にある Edit ( edit icon ) をクリックします。

ステップ 2

[インターフェイス（Interfaces）] をクリックします。

ステップ 3

クラスタ制御リンクを設定します。

複数シャーシによるクラスタリングの場合、クラスタ制御リンク MTU に、データインターフェイスの最大 MTU より少なくとも 100 バイト高い値を指定します。クラスタ制御リンクのトラフィックにはデータパケット転送が含まれるため、クラスタ制御リンクはデータパケット全体のサイズに加えてクラスタトラフィックのオーバーヘッドにも対応する必要があります。MTU の最大値を 9184 バイトに設定し、最小値を 1400 バイトに設定することをお勧めします。たとえば、最大 MTU は 9184 バイトであるため、データインターフェイスの最大 MTU は 9084 になり、クラスタ制御リンクは 9184 に設定できます。

クラスタに参加したノードは、クラスタ制御リンク MTU と一致するパケットサイズで制御ノードに ping を送信することで MTU の互換性をチェックします。ping が失敗すると、通知が生成されるため、接続スイッチの MTU 不一致を修正して再試行することができます。

ネイティブクラスタの場合：クラスタ制御リンクインターフェイスは、デフォルトで Port-Channel48 です。どのインターフェイスがクラスタ制御リンクであるかがわからない場合は、クラスタに割り当てられたクラスタタイプインターフェイスのシャーシの FXOS 設定を確認します。

クラスタ制御リンクインターフェイスの Edit () をクリックします。
[全般（General）] ページの [MTU] フィールドに、1400 ～ 9184 の値を入力します。ただし、2561 ～ 8362 の範囲の値は入力しないでください。ブロックプールの処理が原因で、この MTU サイズはシステム動作に最適ではありません。最大の 9184 を使用することをお勧めします。
[OK] をクリックします。

ステップ 4

データインターフェイスを設定します。

（任意）通常のファイアウォールインターフェイスの場合は、データインターフェイスに VLAN サブインターフェイスを設定します。この手順の残りの部分は、サブインターフェイスに適用されます。サブインターフェイスの追加を参照してください。
データインターフェイスの Edit () をクリックします。

名前とその他のパラメータを設定します。通常のファイアウォールインターフェイスについては、ルーテッドモードのインターフェイスの設定を参照してください。また、トランスペアレントモードについては、ブリッジグループインターフェイスの設定を参照してください。IPS 専用インターフェイスについては、インラインセットとパッシブインターフェイスを参照してください。.

（注）

クラスタ制御リンクインターフェイスの MTU がデータインターフェイスの MTU より 100 バイト以上大きくない場合、データインターフェイスの MTU を減らす必要があるというエラーが表示されます。ステップ 3 を参照して、クラスタ制御リンクの MTU を増やしてください。その後、データインターフェイスの設定を続行できます。

複数シャーシによるクラスタリングの場合は、EtherChannel の手動グローバル MAC アドレス（一意）を設定します。[詳細設定（Advanced）] をクリックし、[アクティブなMACアドレス（Active MAC Address）] フィールドに、MAC アドレスを H.H.H 形式で設定します。H は 16 ビットの 16 進数です。

たとえば、MAC アドレスが 00-0C-F1-42-4C-DE の場合、000C.F142.4CDE と入力します。MAC アドレスはマルチキャストビットセットを持つことはできません。つまり、左から 2 番目の 16 進数字を奇数にすることはできません。

[スタンバイMACアドレス（Standby MAC Address）] は設定しないでください。無視されます。

潜在的なネットワークの接続問題を回避するために、スパンド EtherChannel には、現在ネットワークで使用されていない、一意の MAC アドレスを設定する必要があります。MAC アドレスが手動設定されている場合、その MAC アドレスは現在の制御ユニットに留まります。MAC アドレスを設定していない場合に、制御ユニットが変更された場合、新しい制御ユニットはインターフェイスに新しい MAC アドレスを使用します。これにより、一時的なネットワークの停止が発生する可能性があります。
[OK] をクリックします。他のデータインターフェイスについても前述の手順を繰り返します。

ステップ 5

[Save（保存）] をクリックします。

これで、Deploy > Deploy に移動して、ポリシーを割り当てたデバイスにデプロイします。変更内容は導入するまで適用されません。

Firewall Management Center：クラスタのヘルスモニターの設定

[クラスタ（Cluster）] ページの [クラスタヘルスモニターの設定（Cluster Health Monitor Settings）] セクションには、次の表で説明されている設定が表示されます。

表 1. [クラスタヘルスモニターの設定（Cluster Health Monitor Settings）] セクションテーブルのフィールド
フィールド	説明
タイムアウト（Timeouts）
保留時間（Hold Time）	指定できる範囲は 0.3 ～ 45 秒です。デフォルトは 3 秒です。ノードの状態を確認するため、クラスタノードはクラスタ制御リンクで他のノードにハートビートメッセージを送信します。ノードが保留時間内にピアノードからハートビートメッセージを受信しない場合、そのピアノードは応答不能またはデッド状態と見なされます。
インターフェイスのデバウンス時間（Interface Debounce Time）	指定できる範囲は 300 ～ 9000 ミリ秒です。デフォルトは 500 ms です。インターフェイスのデバウンス時間は、インターフェイスで障害が発生していると見なされ、クラスタからノードが削除されるまでの時間です。
Monitored Interfaces（モニタリング対象インターフェイス）	インターフェイスのヘルスチェックはリンク障害をモニターします。特定の論理インターフェイスのすべての物理ポートが、特定のノード上では障害が発生したが、別のノード上の同じ論理インターフェイスでアクティブポートがある場合、そのノードはクラスタから削除されます。ノードがメンバーをクラスタから削除するまでの時間は、インターフェイスのタイプと、そのノードが確立済みノードであるか、またはクラスタに参加しようとしているかによって異なります。
サービスアプリケーション（Service Application）	Snort プロセスおよび disk-full プロセスが監視されているかどうかを示します。
モニタリング対象外のインターフェイス（Unmonitored Interfaces）	モニタリング対象外のインターフェイスを表示します。
自動再結合の設定（Auto-Rejoin Settings）
クラスタインターフェイス（Cluster Interface）	クラスタ制御リンクに障害が発生した後に自動再結合の設定を表示します。
試行（Attempts）	指定できる範囲は -1 ～ 65535 です。デフォルトは -1（無制限）です。再結合の試行回数を設定します。
試行の間隔（Interval Between Attempts）	指定できる範囲は 2 ～ 60 です。デフォルトは 5 分です。再結合試行の間隔を分単位で定義します。
間隔のバリエーション（Interval Variation）	指定できる範囲は 1 ～ 3 です。デフォルトは間隔の 1 倍です。試行ごとに間隔を長くするかどうかを定義します。
データインターフェイス（Data Interfaces）	データインターフェイスに障害が発生した後に自動再結合の設定を表示します。
試行（Attempts）	指定できる範囲は -1 ～ 65535 です。デフォルトは 3 です。再結合の試行回数を設定します。
試行の間隔（Interval Between Attempts）	指定できる範囲は 2 ～ 60 です。デフォルトは 5 分です。再結合試行の間隔を分単位で定義します。
間隔のバリエーション（Interval Variation）	指定できる範囲は 1 ～ 3 です。デフォルトは間隔の 2 倍です。試行ごとに間隔を長くするかどうかを定義します。
システム（System）	内部エラーが発生した後に自動再結合の設定を表示します。内部エラーには、アプリケーション同期のタイムアウト、一貫性のないアプリケーションステータスなどがあります。
試行（Attempts）	指定できる範囲は -1 ～ 65535 です。デフォルトは 3 です。再結合の試行回数を設定します。
試行の間隔（Interval Between Attempts）	指定できる範囲は 2 ～ 60 です。デフォルトは 5 分です。再結合試行の間隔を分単位で定義します。
間隔のバリエーション（Interval Variation）	指定できる範囲は 1 ～ 3 です。デフォルトは間隔の 2 倍です。試行ごとに間隔を長くするかどうかを定義します。

（注）

システムのヘルスチェックを無効にすると、システムのヘルスチェックが無効化されている場合に適用されないフィールドは表示されません。

これらの設定は、このセクションから変更できます。

任意のポートチャネル ID、単一の物理インターフェイス ID、Snort プロセス、および disk-full プロセスを監視できます。ヘルスモニタリングは VLAN サブインターフェイス、または VNI　や BVI などの仮想インターフェイスでは実行されません。クラスタ制御リンクのモニタリングは設定できません。このリンクは常にモニタされています。

手順

ステップ 1	Devices > Device Management を選択します。
ステップ 2	変更するクラスタの横にある Edit () をクリックします。
ステップ 3	[クラスタ（Cluster）] をクリックします。
ステップ 4	[クラスタのヘルスモニターの設定（Cluster Health Monitor Settings）] セクションで、Edit () をクリックします。
ステップ 5	[ヘルスチェック（Health Check）] スライダをクリックして、システムのヘルスチェックを無効にします。図 11. システムヘルスチェックの無効化何らかのトポロジ変更（たとえばデータインターフェイスの追加/削除、ノードやスイッチのインターフェイスの有効化/無効化、VSS や vPC（または VNet）を形成するスイッチの追加）を行うときには、システムのヘルスチェック機能を無効にし、無効化したインターフェイスのモニタリングも無効にしてください。トポロジの変更が完了して、設定の変更がすべてのノードに同期されたら、システムのヘルスチェック機能を再度有効にてインターフェイスをモニタリングできます。
ステップ 6	ホールド時間とインターフェイスのデバウンス時間を設定します。 [ホールド時間（Hold Time）]：ノードのハートビートステータスメッセージの時間間隔を指定します。指定できる範囲は 3 ～ 45 秒で、デフォルトは 3 秒です。 [インターフェイスのデバウンス時間（Interface Debounce Time）]：デバウンス時間は 300 ～ 9000 ms の範囲で値を設定します。デフォルトは 500 ms です。値を小さくすると、インターフェイスの障害をより迅速に検出できます。デバウンス時間を短くすると、誤検出の可能性が高くなることに注意してください。インターフェイスのステータス更新が発生すると、インターフェイス障害としてマーク付けされるまで、ノードは指定されたミリ秒数待機します。その後、ノードはクラスタから削除されます。EtherChannel がダウン状態からアップ状態に移行する場合（スイッチがリロードされた、スイッチで EtherChannel が有効になったなど）、デバウンス時間がより長くなり、ポートのバンドルにおいて別のクラスタノードの方が高速なため、クラスタノードでインターフェイスの障害が表示されることを妨げることがあります。
ステップ 7	ヘルスチェック失敗後の自動再結合クラスタ設定をカスタマイズします。図 12. 自動再結合の設定 [クラスタインターフェイス（Cluster Interface）]、[データインターフェイス（Data Interface）]、および [システム（System）] に次の値を設定します（内部エラーには、アプリケーションの同期タイムアウト、一貫性のないアプリケーションステータスなどがあります）。 [試行数（Attempts）]：再結合の試行回数を 0 ～ 65535 の範囲の値に設定します。0 は自動再結合を無効化します。[クラスタインターフェイス（Cluster Interface）] のデフォルト値は -1（無制限）です。 [データインターフェイス（Data Interface）] と [システム（System）] のデフォルト値は 3 です。 [試行の間隔（Interval Between Attempts）]：再結合試行の間隔を 2 ～ 60 の分単位で定義します。デフォルト値は 5 分です。クラスタへの再参加をノードが試行する最大合計時間は、最後の障害発生時から 14400 分（10 日）に制限されます。 [間隔のバリエーション（Interval Variation）]：間隔を増加させるかどうかを定義します。1 ～ 3 の範囲で値を設定します（1：変更なし、2：直前の間隔の 2 倍、3：直前の間隔の 3 倍）。たとえば、間隔を 5 分に設定し、変分を 2 に設定した場合は、最初の試行が 5 分後、2 回目の試行が 10 分後（2 x 5）、3 階目の試行が 20 分後（2 x 10）となります。デフォルト値は、[クラスタインターフェイス（Cluster Interface）] の場合は 1、[データインターフェイス（Data Interface）] および [システム（System）] の場合は 2 です。
ステップ 8	[モニタリング対象のインターフェイス（Monitored Interfaces）] または [モニタリング対象外のインターフェイス（Unmonitored Interfaces）] ウィンドウでインターフェイスを移動して、モニタリング対象のインターフェイスを設定します。[サービスアプリケーションのモニタリングを有効にする（Enable Service Application Monitoring）] をオンまたはオフにして、Snort プロセスと disk-full プロセスのモニタリングを有効または無効にすることもできます。図 13. モニタリング対象インターフェイスの設定インターフェイスのヘルスチェックはリンク障害をモニターします。特定の論理インターフェイスのすべての物理ポートが、特定のノード上では障害が発生したが、別のノード上の同じ論理インターフェイスでアクティブポートがある場合、そのノードはクラスタから削除されます。ノードがメンバーをクラスタから削除するまでの時間は、インターフェイスのタイプと、そのノードが確立済みノードであるか、またはクラスタに参加しようとしているかによって異なります。デフォルトでは、ヘルスチェックはすべてのインターフェイス、および Snort プロセスと disk-full プロセスで有効になっています。必須以外のインターフェイスのヘルスモニタリングを無効にできます。何らかのトポロジ変更（たとえばデータインターフェイスの追加/削除、ノードやスイッチのインターフェイスの有効化/無効化、VSS や vPC（または VNet）を形成するスイッチの追加）を行うときには、システムのヘルスチェック機能を無効にし、無効化したインターフェイスのモニタリングも無効にしてください。トポロジの変更が完了して、設定の変更がすべてのノードに同期されたら、システムのヘルスチェック機能を再度有効にてインターフェイスをモニタリングできます。
ステップ 9	[保存（Save）] をクリックします。
ステップ 10	設定変更を展開します設定変更の展開を参照してください。

FXOS: Remove a Cluster Node

The following sections describe how to remove nodes temporarily or permanently from the cluster.

Temporary Removal

A cluster node will be automatically removed from the cluster due to a hardware or network failure, for example. This removal is temporary until the conditions are rectified, and it can rejoin the cluster. You can also manually disable clustering.

To check whether a device is currently in the cluster, check the cluster status on the Firewall Chassis Manager Logical Devices page:

For Firewall Threat Defense using the Firewall Management Center, you should leave the device in the Firewall Management Center device list so that it can resume full functionality after you reenable clustering.

Disable clustering in the application—You can disable clustering using the application CLI. Enter the cluster remove unit name command to remove any node other than the one you are logged into. The bootstrap configuration remains intact, as well as the last configuration synced from the control node, so you can later re-add the node without losing your configuration. If you enter this command on a data node to remove the control node, a new control node is elected.

When a device becomes inactive, all data interfaces are shut down; only the Management interface can send and receive traffic. To resume traffic flow, re-enable clustering. The Management interface remains up using the IP address the node received from the bootstrap configuration. However if you reload, and the node is still inactive in the cluster , the Management interface is disabled.

To reenable clustering, on the Firewall Threat Defense enter cluster enable .
Disable the application instance—In the Firewall Chassis Manager on the Logical Devices page, click the Slider enabled (). You can later reenable it using the Slider disabled ().
Shut down the security module/engine—In the Firewall Chassis Manager on the Security Module/Engine page, click the Power Off icon.
Shut down the chassis—In the Firewall Chassis Manager on the Overview page, click the Shut Down icon.

Permanent Removal

You can permanently remove a cluster node using the following methods.

For Firewall Threat Defense using the Firewall Management Center, be sure to remove the node from the Firewall Management Center device list after you disable clustering on the chassis.

Delete the logical device—In the Firewall Chassis Manager on the Logical Devices page, click the Delete (). You can then deploy a standalone logical device, a new cluster, or even add a new logical device to the same cluster.
Remove the chassis or security module from service—If you remove a device from service, you can add replacement hardware as a new node of the cluster.

FMC：クラスタメンバーの管理

クラスタを導入した後は、コンフィギュレーションを変更し、クラスタメンバを管理できます。

新規クラスタメンバーの追加

FXOS に新しいクラスタメンバーを追加すると、Secure Firewall Management Center によりメンバーが自動的に追加されます。

始める前に

インターフェイスの設定が他のシャーシと交換用ユニットで同じ設定になっていることを確認します。

手順

ステップ 1

FXOS のクラスタに新しいユニットを追加します。『FXOS コンフィギュレーションガイド』を参照してください。

新しいユニットがクラスタに追加されるまで待機します。Firepower Chassis Manager の [論理デバイス（Logical Devices）] 画面を参照するか、または Firepower Threat Defense の show cluster info コマンドを使用してクラスタステータスを表示します。

ステップ 2

新しいクラスタメンバーは自動的に追加されます。交換用ユニットの登録状況をモニターするには、次のように表示します。

[クラスタステータス（Cluster Status）] ダイアログボックス（[デバイス（Devices）] > [デバイス管理（Device Management）] More () アイコンまたは [デバイス（Devices）] > [デバイス管理（Device Management）] > [クラスタ（Cluster）] タブ > [全般（General）] 領域 > [クラスタステータスの表示（View Cluster Status）]> [クラスタのライブステータス（Cluster Live Status）] リンクから使用可能）で、シャーシ上でクラスタに追加中のユニットに「クラスタに追加中...（Joining cluster...）」と示されます。クラスタに追加された後に、Firewall Management Center はこれの登録を試み、ステータスが「登録可能（Available for Registration）」に変わります。登録が完了すると、ステータスが「同期状態（In Sync）」に変わります。登録に失敗すると、ユニットは「登録可能（Available for Registration）」の状態に留まります。この場合、[照合（Reconcile）] をクリックして再登録を強制します。
[システムステータス（System status）] > [タスク（Tasks）]：Firewall Management Center にすべての登録イベントとエラーが表示されます。
[デバイス（Devices）] > [デバイス管理（Device Management）]：デバイスの一覧表示ページでクラスタを展開して、左側にロードアイコンがある場合は、ユニットが登録中であることを示しています。

クラスタメンバーの置換

既存クラスタ内のクラスタメンバーを置き換えることができます。Firewall Management Center は交換ユニットを自動検出します。ただし、Firewall Management Center 内の古いクラスタメンバーは手動で削除する必要があります。また、この手順は再初期化したユニットにも適用されます。その場合は、ハードウェアが同じでも新しいメンバーとして表示されます。

始める前に

インターフェイス設定が他のシャーシに関する交換ユニットと同じであることを確認します。

手順

ステップ 1	新しいシャーシの場合、可能であれば、FXOS 内の古いシャーシの設定をバックアップして復元します。 Firepower 9300 のモジュールを交換する場合は、次の手順を実行する必要はありません。古いシャーシのバックアップ FXOS 設定がない場合は、最初に新規クラスタメンバーの追加の手順を実行します。以下のすべての手順については、FXOS コンフィギュレーションガイド [英語] を参照してください。設定のエクスポート機能を使用して、Firepower 4100/9300 シャーシの論理デバイスとプラットフォームの構成時の設定を含んでいる XML ファイルをエクスポートします。交換用シャーシに設定ファイルをインポートします。ライセンス契約に同意します。必要に応じて、論理デバイスのアプリケーションインスタンスバージョンをアップグレードして、残りのクラスタと一致させます。
ステップ 2	古いユニットの Firewall Management Center で、[デバイス（Devices）] > [デバイス管理（Device Management）] > More () > [削除（Delete）] を選択し。
ステップ 3	ユニットを削除することを確認します。ユニットがクラスタから削除され、Firewall Management Center デバイスリストからも削除されます。
ステップ 4	新しいクラスタメンバーまたは再初期化したクラスタメンバーは自動的に追加されます。交換用ユニットの登録状況をモニターするには、次のように表示します。 [クラスタステータス（Cluster Status）] ダイアログボックス（[デバイス（Devices）] > [デバイス管理（Device Management）] More () アイコンまたは [デバイス（Devices）] > [デバイス管理（Device Management）] > [クラスタ（Cluster）] ページ > [全般（General）] 領域 > [クラスタステータスの表示（View Cluster Status）]> [クラスタのライブステータス（Cluster Live Status）] リンク）で、シャーシ上でクラスタに追加中のユニットに「クラスタに追加中...（Joining cluster...）」と示されます。クラスタに追加された後に、Firewall Management Center はこれの登録を試み、ステータスが「登録可能（Available for Registration）」に変わります。登録が完了すると、ステータスが「同期状態（In Sync）」に変わります。登録に失敗すると、ユニットは「登録可能（Available for Registration）」の状態に留まります。この場合、[照合（Reconcile）] [すべて（All）] をクリックして再登録を強制します。 System () > [タスク（Tasks）]：Firewall Management Center にすべての登録イベントとエラーが表示されます。 [デバイス（Devices）] > [デバイス管理（Device Management）]：デバイスの一覧表示ページでクラスタを展開して、左側にロードアイコンがある場合は、ユニットが登録中であることを示しています。

メンバーの非アクティブ化

ユニットの削除に備えて、またはメンテナンスのために一時的にメンバーを非アクティブ化する場合があります。この手順は、メンバーを一時的に非アクティブ化するためのものです。ユニットは引き続き Firewall Management Center デバイスリストに表示されます。

（注）

ユニットが非アクティブになると、すべてのデータインターフェイスがシャットダウンされます。管理インターフェイスのみがトラフィックを送受信できます。トラフィックフローを再開するには、クラスタリングを再度有効にします。管理インターフェイスは、そのユニットがブートストラップ設定から受け取った IP アドレスを使用して引き続き稼働状態となります。ただし、リロードする場合、クラスタでユニットがまだ非アクティブになっていると、管理インターフェイスは無効になります。それ以降のコンフィギュレーション作業には、コンソールを使用する必要があります。

手順

ステップ 1

非アクティブ化するユニットに対し、[デバイス（Devices）] > [デバイス管理（Device Management）]More ( more icon ) > [クラスタリングを無効にする（Disable Clustering）] を選択します。

[クラスタステータス（Cluster Status）] ダイアログボックスから、ユニットを非アクティブ化することもできます（[デバイス（Devices）] > [デバイス管理（Device Management）]More ( more icon ) > [クラスタのライブステータス（Cluster Live Status）]）。

ステップ 2

ユニットのクラスタリングを無効にすることを確認します。

ユニットは、[デバイス（Devices）] > [デバイス管理（Device Management）]リストの名前の横に [（無効（Disabled））] と表示されます。

ステップ 3

クラスタリングを再び有効にするには、クラスタへの再参加を参照してください。

クラスタへの再参加

障害が発生したインターフェイスなど、ユニットがクラスタから削除された場合または手動でクラスタリングを無効にした場合、クラスタに手動で再参加させる必要があります。クラスタへの再参加を試行する前に、障害が解決されていることを確認します。クラスタからユニットが削除される理由の詳細については、クラスタへの再参加を参照してください。

手順

ステップ 1

再アクティブ化するユニットに対し、[デバイス（Devices）] > [デバイス管理（Device Management）] More ( more icon ) > [クラスタリングを有効にする（Enable Clustering）] を選択します。

[クラスタステータス（Cluster Status）] ダイアログボックスから、ユニットを再アクティブ化することもできます（[デバイス（Devices）] > [デバイス管理（Device Management）] > More ( more icon ) > [クラスタのライブステータス（Cluster Live Status）]）。

ステップ 2

ユニットでクラスタリングを有効にすることを確認します。

データノードの登録解除

クラスタノードを完全に削除する必要がある場合（たとえば、Firepower 9300 でモジュールを削除する場合、またはシャーシを削除する場合）は、Firewall Management Center からメンバーを登録解除する必要があります。

ノードが正常なクラスタの一部である場合、またはノードを一時的に無効にするだけの場合は、ノードを登録解除しないでください。FXOS のクラスタから完全に削除するには、FXOS: Remove a Cluster Node を参照してください。Firewall Management Center から登録解除しても、まだクラスタの一部である場合、トラフィックを引き続き通過させ、制御ノード（Firewall Management Center が管理できない制御ノード）になる可能性もあります。

始める前に

ユニットを手動で非アクティブ化するには、メンバーの非アクティブ化を参照してください。ノードを登録解除する前に、手動で、またはヘルス障害により、ノードが非アクティブになっている必要があります。

手順

ステップ 1

ノードが Firewall Management Center から登録解除できる状態であることを確認します。[デバイス（Devices）] > [デバイス管理（Device Management）] で、ユニットに [（無効（Disabled））] と表示されていることを確認します。

また、各ノードのステータスは、More ( more icon ) から [クラスタステータス（Cluster Status）] ダイアログボックスで確認できます。ステータスが古い場合は、[クラスタステータス（Cluster Status）] ダイアログボックスの [照合（Reconcile）] をクリックして強制的に更新します。

ステップ 2

削除するデータユニットの Firewall Management Center で、[デバイス（Devices）] > [デバイス管理（Device Management）] > More ( more icon ) > [登録解除（Unregister）] を選択します。

ステップ 3

ノードを登録解除することを確認します。

ノードがクラスタから削除され、Firewall Management Center デバイスリストからも削除されます。

制御ユニットの変更

注意	制御ユニットを変更する最良の方法は、制御ユニットでクラスタリングを無効にし、新しい制御ユニットの選択を待ってから、クラスタリングを再度有効にする方法です。制御ユニットにするユニットを厳密に指定する必要がある場合は、この項の手順を使用します。中央集中型機能については、制御ユニット変更を強制するとすべての接続がドロップされるので、新しい制御ユニット上で接続を再確立する必要があります。

制御ユニットを変更するには、次の手順を実行します。

手順

ステップ 1

[デバイス（Devices）] > [デバイス管理（Device Management）] > More ( more icon ) > [クラスタのライブステータス（Cluster Live Status）] を選択して [クラスタステータス（Cluster Status）] ダイアログボックスを開きます。

[クラスタステータス（Cluster Status）] ダイアログボックスは、[デバイス（Devices）] > [デバイス管理（Device Management）] > [クラスタ（Cluster）]ページ > [全般（General）] 領域 > [クラスタのライブステータス（Cluster Live Status）] リンクからも開くことができます。

ステップ 2

制御ユニットにしたいユニットについて、More ( more icon ) > [ロールを制御に変更（Change Role to Control）] を選択します。

ステップ 3

ロールの変更を確認するように求められます。チェックボックスをオンにして [OK] をクリックします。

クラスタメンバーの照合

クラスタメンバーの登録に失敗した場合、シャーシから Secure Firewall Management Center に対してクラスタメンバーシップを照合することができます。たとえば、Firewall Management Center が特定のプロセスで占領されているか、またはネットワークに問題がある場合、データユニットの登録に失敗することがあります。

手順

ステップ 1

クラスタの [Devices] > [Device Management] > More ( more icon ) を選択し、次に [Cluster Live Status] を選択して [Cluster Status] ダイアログボックスを開きます。

[Cluster Status] ダイアログボックスは、[Devices] > [Device Management] > [Cluster] ページ > [General] 領域 > [Cluster Live Status] リンクからも開くことができます。

ステップ 2

[Reconcile All] をクリックします。

クラスタステータスの詳細については、Firewall Management Center：クラスタのモニタリングを参照してください。

Firewall Management Center：クラスタのモニタリング

クラスタのモニタリングは、Secure Firewall Management Center および Firewall Threat Defense CLI で実行できます。

[Cluster Status] ダイアログボックスには、 [デバイス（Devices）] > [デバイス管理（Device Management）] > More () アイコンから、または [デバイス（Devices）] > [デバイス管理（Device Management）] > [クラスタ（Cluster）] ページ > [全般（General）] 領域 > [クラスタステータスの表示（View cluster status）]> [クラスタのライブステータス（Cluster Live Status）] リンクからアクセスできます。

コントロールユニットには、そのロールを示すグラフィックインジケータがあります。

クラスタメンバーステータスには、次の状態が含まれます。
- 同期中（In Sync）：装置は Firewall Management Center に登録されています。
- Pending Registration：装置はクラスタの一部ですが、まだ Firewall Management Center に登録されていません。装置が登録に失敗した場合、[Reconcile All] をクリックして登録を再試行することができます。
- Clustering is disabled：装置は Firewall Management Center に登録されていますが、クラスタの非アクティブなメンバーです。クラスタリング設定は、後で再有効化する予定がある場合は変更せずに維持できます。または、装置をクラスタから削除することも可能です。
- クラスタに参加中（Joining cluster）：装置がシャーシ上でクラスタに参加していますが、参加は完了していません。参加後に Firewall Management Center に登録されます。
装置ごとに、[Summary] または [History] で、それぞれ概要と履歴を表示できます。

More () メニューから、装置ごとに次のステータス変更を実行できます。
- クラスタリングを無効にする
- クラスタリングを有効にする
- ロールを Control に変更する
System () > [Tasks] ページ。

[Tasks] ページには、各装置が登録されるごとに、クラスタ登録タスクの最新の状況が表示されます。
[デバイス（Devices）] > [デバイス管理（Device Management）] > cluster_name。

デバイスの一覧表示ページでクラスタを展開すると、制御装置（IP アドレスの横にその役割が示されている）を含め、すべてのメンバ装置を表示できます。登録中の装置には、ロード中のアイコンが表示されます。
show cluster {access-list [acl_name] | conn [count] | cpu [usage] | history | interface-mode | memory | resource usage | service-policy | traffic | xlate count}

クラスタ全体の集約データまたはその他の情報を表示するには、show cluster コマンドを使用します。
show cluster info [auto-join | clients | conn-distribution | flow-mobility counters | goid [options] | health | incompatible-config | loadbalance | old-members | packet-distribution | trace [options] | transport { asp | cp}]

クラスタ情報を表示するには、show cluster info コマンドを使用します。

クラスタヘルスモニターダッシュボード

クラスタのヘルスモニター

Firewall Threat Defense がクラスタの制御ノードである場合、Firewall Management Center はデバイスメトリックデータコレクタからさまざまなメトリックを定期的に収集します。クラスタのヘルスモニターは、次のコンポーネントで構成されています。

概要ダッシュボード：クラスタトポロジ、クラスタ統計、およびメトリックチャートに関する情報を表示します。

トポロジセクションには、クラスタのライブステータス、個々の脅威防御の状態、脅威防御ノードのタイプ（制御ノードまたはデータノード）、およびデバイスの状態が表示されます。デバイスの状態は、[無効（Disabled）]（デバイスがクラスタを離れたとき）、[初期状態で追加（Added out of box）]（パブリッククラウドクラスタで Firewall Management Center に属していない追加ノード）、または [標準（Normal）]（ノードの理想的な状態）のいずれかです。

クラスタの統計セクションには、CPU 使用率、メモリ使用率、入力レート、出力レート、アクティブな接続数、および NAT 変換数に関するクラスタの現在のメトリックが表示されます。

（注）

CPU とメモリのメトリックは、データプレーンと Snort の使用量の個々の平均を示します。

メトリックチャート、つまり、CPU 使用率、メモリ使用率、スループット、および接続数は、指定された期間におけるクラスタの統計を図表で示します。

負荷分散ダッシュボード：2 つのウィジェットでクラスタノード全体の負荷分散を表示します。
- 分布ウィジェットには、クラスタノード全体の時間範囲における平均パケットおよび接続分布が表示されます。このデータは、ノードによって負荷がどのように分散されているかを示します。このウィジェットを使用すると、負荷分散の異常を簡単に特定して修正できます。
- ノード統計ウィジェットには、ノードレベルのメトリックが表形式で表示されます。クラスタノード全体の CPU 使用率、メモリ使用率、入力レート、出力レート、アクティブな接続数、および NAT 変換数に関するメトリックデータが表示されます。このテーブルビューでは、データを関連付けて、不一致を簡単に特定できます。
メンバーパフォーマンスダッシュボード：クラスタノードの現在のメトリックを表示します。セレクタを使用してノードをフィルタリングし、特定ノードの詳細を表示できます。メトリックデータには、CPU 使用率、メモリ使用率、入力レート、出力レート、アクティブな接続数、および NAT 変換数が含まれます。
CCL ダッシュボード：クラスタの制御リンクデータ、つまり入力レートと出力レートをグラフ形式で表示します。
トラブルシューティングとリンク：頻繁に使用されるトラブルシューティングのトピックと手順への便利なリンクを提供します。
時間範囲：さまざまなクラスタメトリックダッシュボードやウィジェットに表示される情報を制限するための調整可能な時間枠。
カスタムダッシュボード：クラスタ全体のメトリックとノードレベルのメトリックの両方に関するデータを表示します。ただし、ノードの選択は脅威防御メトリックにのみ適用され、ノードが属するクラスタ全体には適用されません。

クラスタヘルスの表示

この手順を実行するには、管理者ユーザー、メンテナンスユーザー、またはセキュリティアナリストユーザーである必要があります。

クラスタヘルスモニターは、クラスタとそのノードのヘルスステータスの詳細なビューを提供します。このクラスタヘルスモニターは、一連のダッシュボードでクラスタのヘルスステータスと傾向を提供します。

始める前に

Firewall Management Center の 1 つ以上のデバイスからクラスタを作成しているかを確認します。

手順

ステップ 1	System () > Health > Monitor を選択します。 [モニタリング（Monitoring）] ナビゲーションウィンドウを使用して、ノード固有のヘルスモニターにアクセスします。
ステップ 2	デバイスリストで Expand() と Collapse () をクリックして、管理対象のクラスタデバイスのリストを展開または折りたたみます。
ステップ 3	クラスタのヘルス統計を表示するには、クラスタ名をクリックします。デフォルトでは、クラスタモニターは、いくつかの事前定義されたダッシュボードで正常性およびパフォーマンスのメトリックを報告します。メトリックダッシュボードには次のものが含まれます。 [概要（Overview）]：他の事前定義されたダッシュボードからの主要なメトリックを表示します。ノード、CPU、メモリ、入力レート、出力レート、接続統計情報、NAT 変換情報などが含まれます。 [負荷分散（Load Distribution）]：クラスタノード間のトラフィックとパケットの分散。 [メンバーパフォーマンス（Member Performance）]：CPU 使用率、メモリ使用率、入力スループット、出力スループット、アクティブな接続、および NAT 変換に関するノードレベルの統計情報。 [CCL]：インターフェイスのステータスおよび集約トラフィックの統計情報。ラベルをクリックすると、さまざまなメトリックダッシュボードに移動できます。サポートされているクラスタメトリックの包括的なリストについては、「Cisco Secure Firewall Threat Defense Health Metrics」を参照してください。
ステップ 4	右上隅のドロップダウンで、時間範囲を設定できます。最短で 1 時間前（デフォルト）から、最長では 2 週間前からの期間を反映できます。ドロップダウンから [Custom] を選択して、カスタムの開始日と終了日を設定します。更新アイコンをクリックして、自動更新を 5 分に設定するか、自動更新をオフに切り替えます。
ステップ 5	選択した時間範囲について、トレンドグラフの展開オーバーレイの展開アイコンをクリックします。展開アイコンは、選択した時間範囲内の展開数を示します。垂直の帯は、展開の開始時刻と終了時刻を示します。複数の展開の場合、複数の帯または線が表示されます。展開の詳細を表示するには、点線の上部にあるアイコンをクリックします。
ステップ 6	（ノード固有のヘルスモニターの場合）ページ上部のデバイス名の右側にあるアラート通知で、ノードの正常性アラートを確認します。正常性アラートにポインタを合わせると、ノードの正常性の概要が表示されます。ポップアップウィンドウに、上位 5 つの正常性アラートの概要の一部が表示されます。ポップアップをクリックすると、正常性アラート概要の詳細ビューが開きます。
ステップ 7	（ノード固有のヘルスモニターの場合）デフォルトでは、デバイスモニターは、いくつかの事前定義されたダッシュボードで正常性およびパフォーマンスのメトリックを報告します。メトリックダッシュボードには次のものが含まれます。 Overview：CPU、メモリ、インターフェイス、接続統計情報など、他の定義済みダッシュボードからの主要なメトリックを表示します。ディスク使用量と重要なプロセス情報も含まれます。 CPU：CPU 使用率。プロセス別および物理コア別の CPU 使用率を含みます。 Memory：デバイスのメモリ使用率。データプレーンと Snort のメモリ使用率を含みます。 Interfaces：インターフェイスのステータスおよび集約トラフィック統計情報。 Connections：接続統計（エレファントフロー、アクティブな接続数、ピーク接続数など）および NAT 変換カウント。 [Snort]：Snort プロセスに関連する統計情報。 [ASPドロップ（ASP drops）]：さまざまな理由でドロップされたパケットに関連する統計情報。ラベルをクリックすると、さまざまなメトリックダッシュボードに移動できます。サポートされているデバイスメトリックの包括的なリストについては、「Cisco Secure Firewall Threat Defense Health Metrics」を参照してください。
ステップ 8	正常性モニターの右上隅にあるプラス記号 Add New Dashboard() をクリックして、使用可能なメトリックグループから独自の変数セットを構成し、カスタムダッシュボードを作成します。クラスタ全体のダッシュボードの場合は、クラスタのメトリックグループを選択してから、メトリックを選択します。

クラスタメトリック

クラスタのヘルスモニターは、クラスタとそのノードに関連する統計情報と、負荷分散、パフォーマンス、および CCL トラフィックの統計データの集約結果を追跡します。

表 2. クラスタメトリック
メトリック	説明	フォーマット（Format）
CPU	クラスタノード上の CPU メトリックの平均（データプレーンと snort についてそれぞれ表示）。	パーセンテージ
メモリ	クラスタノード上のメモリメトリックの平均（データプレーンと snort についてそれぞれ表示）。	パーセンテージ
データスループット	クラスタの着信および発信データトラフィックの統計。	バイト
CCL スループット	クラスタの着信および発信 CCL トラフィックの統計。	バイト
接続	クラスタ内のアクティブな接続数。	番号
NAT 変換数	クラスタの NAT 変換数。	番号
分布	1 秒ごとのクラスタ内の接続分布数。	番号
パケット	クラスタ内の 1 秒ごとのパケット配信の件数。	番号

Firewall Management Center：クラスタのトラブルシューティング

CCL Ping ツールを使用すると、クラスタ制御リンクが正しく動作していることを確認できます。デバイスとクラスタで使用可能な次のツールを使用することもできます。

トラブルシューティングファイル：ノードがクラスタに参加できない場合、トラブルシューティングファイルが自動的に生成されます。また、[デバイス（Devices）] > [デバイス管理（Device Management）] > [クラスタ（Cluster）] > [一般（General）] エリアからトラブルシューティングファイルを生成してダウンロードすることもできます。トラブルシューティングファイルの生成を参照してください。

More () をクリックし、[トラブルシューティングファイル（Troubleshoot Files）] を選択して、[デバイス管理（Device Management）] ページからファイルを生成することもできます。
CLI 出力：[デバイス（Devices）] > [デバイス管理（Device Management）] > [クラスタ（Cluster）] > [一般（General）] エリアで、クラスタのトラブルシューティングに役立つ一連の定義済み CLI 出力を表示できます。クラスタに対して次のコマンドが自動的に実行されます。
- show running-config cluster
- show cluster info
- show cluster info health
- show cluster info transport cp
- show version
- show asp drop
- show counters
- show arp
- show int ip brief
- show blocks
- show cpu detailed
- show interface ccl_interface
- ping ccl_ip size ccl_mtu repeat 2
[コマンド（Command）] フィールドに任意の show コマンドを入力することもできます。詳細については、CLI 出力の表示を参照してください。

クラスター制御リンクへの ping の実行

クラスタに参加したノードは、クラスタ制御リンク MTU と一致するパケットサイズで制御ノードに ping を送信することで MTU の互換性をチェックします。ping が失敗すると、通知が生成されるため、接続スイッチの MTU 不一致を修正して再試行することができます。このツールを使用すると、クラスタ制御リンクの接続に問題がある場合に、すでにクラスタに参加しているすべてのノードに手動で ping を実行できます。

手順

ステップ 1

[デバイス（Devices）] > [デバイス管理（Device Management）] の順に選択し、クラスタの横の More ( more icon ) をクリックして [クラスタのライブステータス（Cluster Live Status）] を選択します。

ステップ 2

ノードの 1 つを展開し、[CCL Ping] をクリックします。

ノードは、最大 MTU に一致するパケットサイズを使用して、クラスタ制御リンクで他のすべてのノードに ping を送信します。

Examples for Clustering

These examples include typical deployments.

Firewall on a Stick

Data traffic from different security domains are associated with different VLANs, for example, VLAN 10 for the inside network and VLAN 20 for the outside network. Each has a single physical port connected to the external switch or router. Trunking is enabled so that all packets on the physical link are 802.1q encapsulated. The is the firewall between VLAN 10 and VLAN 20.

When using Spanned EtherChannels, all data links are grouped into one EtherChannel on the switch side. If the becomes unavailable, the switch will rebalance traffic between the remaining units.

Traffic Segregation

You may prefer physical separation of traffic between the inside and outside network.

As shown in the diagram above, there is one Spanned EtherChannel on the left side that connects to the inside switch, and the other on the right side to outside switch. You can also create VLAN subinterfaces on each EtherChannel if desired.

Reference for Clustering

This section includes more information about how clustering operates.

Firewall Threat Defense の機能とクラスタリング

Firewall Threat Defense の一部の機能はクラスタリングではサポートされず、一部は制御ユニットだけでサポートされます。その他の機能については適切な使用に関する警告がある場合があります。

クラスタリングでサポートされない機能

次の各機能は、クラスタリングが有効なときは設定できず、コマンドは拒否されます。

（注）

クラスタリングでもサポートされていない FlexConfig 機能（WCCP インスペクションなど）を表示するには、ASA の一般的な操作のコンフィギュレーションガイドを参照してください。FlexConfig では、Firewall Management Center GUI にはない多くの ASA 機能を設定できます。FlexConfig ポリシーを参照してください。

リモートアクセス VPN（SSL VPN および IPsec VPN）
パブリッククラウドでは、サイト間 VPN（ポリシーベースおよびルートベース）はサポートされていません。
DHCP クライアント、サーバー、およびプロキシ。DHCP リレーはサポートされています。
仮想トンネルインターフェイス（VTI）
高可用性
統合ルーティングおよびブリッジング
Firewall Management Center UCAPL/CC モード

DHCP クライアント、サーバー、およびプロキシ。DHCP リレーはサポートされています。

クラスタリングの中央集中型機能

The following features are only supported on the control node, and are not scaled for the cluster.

（注）

Traffic for centralized features is forwarded from member nodes to the control node over the cluster control link.

If you use the rebalancing feature, traffic for centralized features may be rebalanced to non-control nodes before the traffic is classified as a centralized feature; if this occurs, the traffic is then sent back to the control node.

For centralized features, if the control node fails, all connections are dropped, and you have to re-establish the connections on the new control node.

（注）

To view FlexConfig features that are also centralized with clustering, for example RADIUS inspection, see the ASA general operations configuration guide. FlexConfig lets you configure many ASA features that are not present in the Firewall Management Center GUI. See FlexConfig ポリシー.

The following application inspections:
- DCERPC
- ESMTP
- NetBIOS
- PPTP
- RSH
- SQLNET
- SUNRPC
- TFTP
- XDMCP
Static route monitoring

サイト間 VPN
IGMP マルチキャストコントロールプレーンプロトコル処理（データプレーン転送はクラスタ全体に分散されます）
PIM マルチキャストコントロールプレーンプロトコル処理（データプレーン転送はクラスタ全体に分散されます）

ダイナミックルーティング

Connection Settings

Connection limits are enforced cluster-wide. Each node has an estimate of the cluster-wide counter values based on broadcast messages. Due to efficiency considerations, the configured connection limit across the cluster might not be enforced exactly at the limit number. Each node may overestimate or underestimate the cluster-wide counter value at any given time. However, the information will get updated over time in a load-balanced cluster.

Dynamic Routing and Clustering

The routing process only runs on the control unit, and routes are learned through the control unit and replicated to secondaries. If a routing packet arrives at a data unit, it is redirected to the control unit.

After the data units learn the routes from the control unit, each unit makes forwarding decisions independently.

The OSPF LSA database is not synchronized from the control unit to data units. If there is a control unit switchover, the neighboring router will detect a restart; the switchover is not transparent. The OSPF process picks an IP address as its router ID. Although not required, you can assign a static router ID to ensure a consistent router ID is used across the cluster. See the OSPF Non-Stop Forwarding feature to address the interruption.

FTP and Clustering

If FTP data channel and control channel flows are owned by different cluster members, then the data channel owner will periodically send idle timeout updates to the control channel owner and update the idle timeout value. However, if the control flow owner is reloaded, and the control flow is re-hosted, the parent/child flow relationship will not longer be maintained; the control flow idle timeout will not be updated.

Multicast Routing and Clustering

The control unit handles all multicast routing packets and data packets until fast-path forwarding is established. After the connection is established, each data unit can forward multicast data packets.

NAT and Clustering

NAT can affect the overall throughput of the cluster. Inbound and outbound NAT packets can be sent to different Firewall Threat Defenses in the cluster, because the load balancing algorithm relies on IP addresses and ports, and NAT causes inbound and outbound packets to have different IP addresses and/or ports. When a packet arrives at the Firewall Threat Defense that is not the NAT owner, it is forwarded over the cluster control link to the owner, causing large amounts of traffic on the cluster control link. Note that the receiving node does not create a forwarding flow to the owner, because the NAT owner may not end up creating a connection for the packet depending on the results of security and policy checks.

If you still want to use NAT in clustering, then consider the following guidelines:

PAT with Port Block Allocation—See the following guidelines for this feature:
- Maximum-per-host limit is not a cluster-wide limit, and is enforced on each node individually. Thus, in a 3-node cluster with the maximum-per-host limit configured as 1, if the traffic from a host is load-balanced across all 3 nodes, then it can get allocated 3 blocks with 1 in each node.
- Port blocks created on the backup node from the backup pools are not accounted for when enforcing the maximum-per-host limit.
- On-the-fly PAT rule modifications, where the PAT pool is modified with a completely new range of IP addresses, will result in xlate backup creation failures for the xlate backup requests that were still in transit while the new pool became effective. This behavior is not specific to the port block allocation feature, and is a transient PAT pool issue seen only in cluster deployments where the pool is distributed and traffic is load-balanced across the cluster nodes.
- When operating in a cluster, you cannot simply change the block allocation size. The new size is effective only after you reload each device in the cluster. To avoid having to reload each device, we recommend that you delete all block allocation rules and clear all xlates related to those rules. You can then change the block size and recreate the block allocation rules.
NAT pool address distribution for dynamic PAT—When you configure a PAT pool, the cluster divides each IP address in the pool into port blocks. By default, each block is 512 ports, but if you configure port block allocation rules, your block setting is used instead. These blocks are distributed evenly among the nodes in the cluster, so that each node has one or more blocks for each IP address in the PAT pool. Thus, you could have as few as one IP address in a PAT pool for a cluster, if that is sufficient for the number of PAT’ed connections you expect. Port blocks cover the 1024-65535 port range, unless you configure the option to include the reserved ports, 1-1023, on the PAT pool NAT rule.
Reusing a PAT pool in multiple rules—To use the same PAT pool in multiple rules, you must be careful about the interface selection in the rules. You must either use specific interfaces in all rules, or "any" in all rules. You cannot mix specific interfaces and "any" across the rules, or the system might not be able to match return traffic to the right node in the cluster. Using unique PAT pools per rule is the most reliable option.
No round-robin—Round-robin for a PAT pool is not supported with clustering.
No extended PAT—Extended PAT is not supported with clustering.
Dynamic NAT xlates managed by the control node—The control node maintains and replicates the xlate table to data nodes. When a data node receives a connection that requires dynamic NAT, and the xlate is not in the table, it requests the xlate from the control node. The data node owns the connection.
Stale xlates—The xlate idle time on the connection owner does not get updated. Thus, the idle time might exceed the idle timeout. An idle timer value higher than the configured timeout with a refcnt of 0 is an indication of a stale xlate.
No static PAT for the following inspections—
- FTP
- RSH
- SQLNET
- TFTP
- XDMCP
- SIP
If you have an extremely large number of NAT rules, over ten thousand, you should enable the transactional commit model using the asp rule-engine transactional-commit nat command in the device CLI. Otherwise, the node might not be able to join the cluster.

SIP Inspection and Clustering

A control flow can be created on any node (due to load balancing); its child data flows must reside on the same node.

SNMP and Clustering

You should always use the Local address, and not the Main cluster IP address for SNMP polling. If the SNMP agent polls the Main cluster IP address, if a new control node is elected, the poll to the new control node will fail.

When using SNMPv3 with clustering, if you add a new cluster node after the initial cluster formation, then SNMPv3 users are not replicated to the new node. You must remove the users, and re-add them, and then redeploy your configuration to force the users to replicate to the new node.

Syslog and Clustering

Each node in the cluster generates its own syslog messages. You can configure logging so that each node uses either the same or a different device ID in the syslog message header field. For example, the hostname configuration is replicated and shared by all nodes in the cluster. If you configure logging to use the hostname as the device ID, syslog messages generated by all nodes look as if they come from a single node. If you configure logging to use the local-node name that is assigned in the cluster bootstrap configuration as the device ID, syslog messages look as if they come from different nodes.

TLS/SSL 接続とクラスタリング

TLS/SSL 接続の復号状態は同期されず、接続オーナーに障害が発生すると、復号された接続がリセットされます。新しいユニットへの新しい接続を確立する必要があります。復号されていない接続（復号しないルールに一致）は影響を受けず、正しく複製されます。

Cisco TrustSec and Clustering

Only the control node learns security group tag (SGT) information. The control node then populates the SGT to data nodes, and data nodes can make a match decision for SGT based on the security policy.

VPN とクラスタリング

サイト間 VPN は、中央集中型機能です。制御ユニットのみが VPN 接続をサポートします。

（注）

リモートアクセス VPN は、クラスタリングではサポートされません。

VPN 機能を使用できるのは制御ユニットだけであり、クラスタの高可用性機能は活用されません。制御ユニットで障害が発生した場合は、すべての既存の VPN 接続が失われ、VPN ユーザーにとってはサービスの中断となります。新しい制御ユニットが選定されたときに、VPN 接続を再確立する必要があります。

VPN トンネルをスパンドインターフェイスのアドレスに接続すると、接続が自動的に制御ユニットに転送されます。

VPN 関連のキーと証明書は、すべてのユニットに複製されます。

Performance Scaling Factor

When you combine multiple units into a cluster, you can expect the total cluster performance to be approximately 80% of the maximum combined throughput.

For example, for TCP throughput, the Firepower 9300 with 3 SM-40 modules can handle approximately 135 Gbps of real world firewall traffic when running alone. For 2 chassis, the maximum combined throughput will be approximately 80% of 270 Gbps (2 chassis x 135 Gbps): 216 Gbps.

Control Unit Election

Members of the cluster communicate over the cluster control link to elect a control unit as follows:

When you deploy the cluster, each unit broadcasts an election request every 3 seconds.
Any other units with a higher priority respond to the election request; the priority is set when you deploy the cluster and is not configurable.

If after 45 seconds, a unit does not receive a response from another unit with a higher priority, then it becomes the control unit.

（注）

If multiple units tie for the highest priority, the cluster unit name and then the serial number is used to determine the control unit.

If a unit later joins the cluster with a higher priority, it does not automatically become the control unit; the existing control unit always remains as the control unit unless it stops responding, at which point a new control unit is elected.
In a "split brain" scenario when there are temporarily multiple control units, then the unit with highest priority retains the role while the other units return to data unit roles.

（注）

You can manually force a unit to become the control unit. For centralized features, if you force a control unit change, then all connections are dropped, and you have to re-establish the connections on the new control unit.

High Availability Within the Cluster

Clustering provides high availability by monitoring chassis, unit, and interface health and by replicating connection states between units.

Chassis-Application Monitoring

Chassis-application health monitoring is always enabled. The Firepower 4100/9300 chassis supervisor checks the Firewall Threat Defense application periodically (every second). If the Firewall Threat Defense device is up and cannot communicate with the Firepower 4100/9300 chassis supervisor for 3 seconds, the Firewall Threat Defense device generates a syslog message and leaves the cluster.

If the Firepower 4100/9300 chassis supervisor cannot communicate with the application after 45 seconds, it reloads the Firewall Threat Defense device. If the Firewall Threat Defense device cannot communicate with the supervisor, it removes itself from the cluster.

Unit Health Monitoring

Each unit periodically sends a broadcast keepaliveheartbeat packet over the cluster control link. If the control node does not receive any keepaliveheartbeat packets or other packets from a data node within the configurable timeout period, then the control node removes the data node from the cluster. If the data nodes do not receive packets from the control node, then a new control node is elected from the remaining node.

If nodes cannot reach each other over the cluster control link because of a network failure and not because a node has actually failed, then the cluster may go into a "split brain" scenario where isolated data nodes will elect their own control nodes. For example, if a router fails between two cluster locations, then the original control node at location 1 will remove the location 2 data nodes from the cluster. Meanwhile, the nodes at location 2 will elect their own control node and form their own cluster. Note that asymmetric traffic may fail in this scenario. After the cluster control link is restored, then the control node that has the higher priority will keep the control node’s role. See Control Unit Election for more information.

Interface Monitoring

Each node monitors the link status of all hardware interfaces in use, and reports status changes to the control node. For clustering on multiple chassis, Spanned EtherChannels use the cluster Link Aggregation Control Protocol (cLACP). Each chassis monitors the link status and the cLACP protocol messages to determine if the port is still active in the EtherChannel, and informs the Firewall Threat Defense application if the interface is down. When you enable health monitoring, all physical interfaces are monitored by default (including the main EtherChannel for EtherChannel interfaces). Only named interfaces that are in an Up state can be monitored. For example, all member ports of an EtherChannel must fail before a named EtherChannel is removed from the cluster. You can optionally disable monitoring per interface.

If a monitored interface fails on a particular node, but it is active on other nodes, then the node is removed from the cluster. The amount of time before the Firewall Threat Defense device removes a node from the cluster depends on whether the node is an established member or is joining the cluster. The Firewall Threat Defense device does not monitor interfaces for the first 90 seconds that a node joins the cluster. Interface status changes during this time will not cause the Firewall Threat Defense device to be removed from the cluster. For an established member, the node is removed after 500 ms.

For clustering on multiple chassis, if you add or delete an EtherChannel from the cluster, interface health-monitoring is suspended for 95 seconds to ensure that you have time to make the changes on each chassis.

Decorator Application Monitoring

When you install a decorator application on an interface, such as the Radware DefensePro application, then both the Firewall Threat Defense device and the decorator application must be operational to remain in the cluster. The unit does not join the cluster until both applications are operational. Once in the cluster, the unit monitors the decorator application health every 3 seconds. If the decorator application is down, the unit is removed from the cluster.

Status After Failure

When a node in the cluster fails, the connections hosted by that node are seamlessly transferred to other nodes; state information for traffic flows is shared over the control node's cluster control link.

If the control node fails, then another member of the cluster with the highest priority (lowest number) becomes the control node.

The Firewall Threat Defense automatically tries to rejoin the cluster, depending on the failure event.

（注）

When the Firewall Threat Defense becomes inactive and fails to automatically rejoin the cluster, all data interfaces are shut down; only the Management interface can send and receive traffic.

クラスタへの再参加

クラスタメンバがクラスタから削除された後、クラスタに再参加するための方法は、削除された理由によって異なります。

最初に参加するときに障害が発生したクラスタ制御リンク：クラスタ制御リンクの問題を解決した後、クラスタリングを再び有効にして、手動でクラスタに再参加する必要があります。
クラスタに参加した後に障害が発生したクラスタ制御リンク：FTD は、無限に 5 分ごとに自動的に再参加を試みます。
データインターフェイスの障害：Firewall Threat Defense は自動的に最初は 5 分後、次に 10 分後、最終的に 20 分後に再参加を試みます。20 分後に参加できない場合、Firewall Threat Defense アプリケーションはクラスタリングを無効にします。データインターフェイスの問題を解決した後、手動でクラスタリングを有効にする必要があります。
ノードの障害：ノードがヘルスチェック失敗のためクラスタから削除された場合、クラスタへの再参加は失敗の原因によって異なります。たとえば、一時的な電源障害の場合は、クラスタ制御リンクが稼働している限り、ノードは再起動するとクラスタに再参加します。Firewall Threat Defense アプリケーションは 5 秒ごとにクラスタへの再参加を試みます。
内部エラー：内部エラーには、アプリケーション同期のタイムアウト、一貫性のないアプリケーションステータスなどがあります。
障害が発生した設定の展開：FMC から新しい設定を展開し、展開が一部のクラスタメンバーでは失敗したものの、他のメンバーでは成功した場合、失敗したノードはクラスタから削除されます。クラスタリングを再度有効にして手動でクラスタに再参加する必要があります。制御ノードで展開が失敗した場合、展開はロールバックされ、メンバーは削除されません。すべてのデータノードで展開が失敗した場合、展開はロールバックされ、メンバーは削除されません。

シャーシアプリケーション通信の障害：Firewall Threat Defense アプリケーションはシャーシアプリケーションの状態が回復したことを検出すると、自動的にクラスタへの再参加を試みます。

Data Path Connection State Replication

Every connection has one owner and at least one backup owner in the cluster. The backup owner does not take over the connection in the event of a failure; instead, it stores TCP/UDP state information, so that the connection can be seamlessly transferred to a new owner in case of a failure. The backup owner is usually also the director.

Some traffic requires state information above the TCP or UDP layer. See the following table for clustering support or lack of support for this kind of traffic.

表 3. Features Replicated Across the Cluster
Traffic	State Support	Notes
Up time	Yes	Keeps track of the system up time.
ARP Table	Yes	—
MAC address table	Yes	—
User Identity	Yes	—
IPv6 Neighbor database	Yes	—
Dynamic routing	Yes	—
SNMP Engine ID	No	—

How the Cluster Manages Connections

Connections can be load-balanced to multiple nodes of the cluster. Connection roles determine how connections are handled in both normal operation and in a high availability situation.

Connection Roles

See the following roles defined for each connection:

Owner—Usually, the node that initially receives the connection. The owner maintains the TCP state and processes packets. A connection has only one owner. If the original owner fails, then when new nodes receive packets from the connection, the director chooses a new owner from those nodes.
Backup owner—The node that stores TCP/UDP state information received from the owner, so that the connection can be seamlessly transferred to a new owner in case of a failure. The backup owner does not take over the connection in the event of a failure. If the owner becomes unavailable, then the first node to receive packets from the connection (based on load balancing) contacts the backup owner for the relevant state information so it can become the new owner.

As long as the director (see below) is not the same node as the owner, then the director is also the backup owner. If the owner chooses itself as the director, then a separate backup owner is chosen.

For clustering on the Firepower 9300, which can include up to 3 cluster nodes in one chassis, if the backup owner is on the same chassis as the owner, then an additional backup owner will be chosen from another chassis to protect flows from a chassis failure.
Director—The node that handles owner lookup requests from forwarders. When the owner receives a new connection, it chooses a director based on a hash of the source/destination IP address and ports (see below for ICMP hash details), and sends a message to the director to register the new connection. If packets arrive at any node other than the owner, the node queries the director about which node is the owner so it can forward the packets. A connection has only one director. If a director fails, the owner chooses a new director.

As long as the director is not the same node as the owner, then the director is also the backup owner (see above). If the owner chooses itself as the director, then a separate backup owner is chosen.

ICMP/ICMPv6 hash details:
- For Echo packets, the source port is the ICMP identifier, and the destination port is 0.
- For Reply packets, the source port is 0, and the destination port is the ICMP identifier.
- For other packets, both source and destination ports are 0.

Forwarder—A node that forwards packets to the owner. If a forwarder receives a packet for a connection it does not own, it queries the director for the owner, and then establishes a flow to the owner for any other packets it receives for this connection. The director can also be a forwarder. Note that if a forwarder receives the SYN-ACK packet, it can derive the owner directly from a SYN cookie in the packet, so it does not need to query the director. (If you disable TCP sequence randomization, the SYN cookie is not used; a query to the director is required.) For short-lived flows such as DNS and ICMP, instead of querying, the forwarder immediately sends the packet to the director, which then sends them to the owner. A connection can have multiple forwarders; the most efficient throughput is achieved by a good load-balancing method where there are no forwarders and all packets of a connection are received by the owner.

（注）

We do not recommend disabling TCP sequence randomization when using clustering. There is a small chance that some TCP sessions won't be established, because the SYN/ACK packet might be dropped.

Fragment Owner—For fragmented packets, cluster nodes that receive a fragment determine a fragment owner using a hash of the fragment source IP address, destination IP address, and the packet ID. All fragments are then forwarded to the fragment owner over the cluster control link. Fragments may be load-balanced to different cluster nodes, because only the first fragment includes the 5-tuple used in the switch load balance hash. Other fragments do not contain the source and destination ports and may be load-balanced to other cluster nodes. The fragment owner temporarily reassembles the packet so it can determine the director based on a hash of the source/destination IP address and ports. If it is a new connection, the fragment owner will register to be the connection owner. If it is an existing connection, the fragment owner forwards all fragments to the provided connection owner over the cluster control link. The connection owner will then reassemble all fragments.

Port Address Translation Connections

New Connection Ownership

When a new connection is directed to a node of the cluster via load balancing, that node owns both directions of the connection. If any connection packets arrive at a different node, they are forwarded to the owner node over the cluster control link. If a reverse flow arrives at a different node, it is redirected back to the original node.

Sample Data Flow for TCP

The following example shows the establishment of a new connection.

The SYN packet originates from the client and is delivered to one Firewall Threat Defense (based on the load balancing method), which becomes the owner. The owner creates a flow, encodes owner information into a SYN cookie, and forwards the packet to the server.
The SYN-ACK packet originates from the server and is delivered to a different Firewall Threat Defense (based on the load balancing method). This Firewall Threat Defense is the forwarder.
Because the forwarder does not own the connection, it decodes owner information from the SYN cookie, creates a forwarding flow to the owner, and forwards the SYN-ACK to the owner.
The owner sends a state update to the director, and forwards the SYN-ACK to the client.
The director receives the state update from the owner, creates a flow to the owner, and records the TCP state information as well as the owner. The director acts as the backup owner for the connection.
Any subsequent packets delivered to the forwarder will be forwarded to the owner.
If packets are delivered to any additional nodes, it will query the director for the owner and establish a flow.
Any state change for the flow results in a state update from the owner to the director.

Sample Data Flow for ICMP and UDP

The following example shows the establishment of a new connection.

図 17. ICMP and UDP Data Flow

The first UDP packet originates from the client and is delivered to one Firewall Threat Defense (based on the load balancing method).
The node that received the first packet queries the director node that is chosen based on a hash of the source/destination IP address and ports.
The director finds no existing flow, creates a director flow and forwards the packet back to the previous node. In other words, the director has elected an owner for this flow.
The owner creates the flow, sends a state update to the director, and forwards the packet to the server.
The second UDP packet originates from the server and is delivered to the forwarder.
The forwarder queries the director for ownership information. For short-lived flows such as DNS, instead of querying, the forwarder immediately sends the packet to the director, which then sends it to the owner.
The director replies to the forwarder with ownership information.
The forwarder creates a forwarding flow to record owner information and forwards the packet to the owner.
The owner forwards the packet to the client.

クラスタリングの履歴

表 4.

機能

Minimum Firewall Management Center

Minimum Firewall Threat Defense

詳細

MTU ping test on cluster node join

7.6.0

When a node joins the cluster, it checks MTU compatibility by sending a ping to the control node with a packet size matching the cluster control link MTU. If the ping fails, a notification is generated so you can fix the MTU mismatch on connecting switches and try again.

Cluster control link ping tool.

7.2.6/7.4.1

いずれか

You can check to make sure all the cluster nodes can reach each other over the cluster control link by performing a ping. One major cause for the failure of a node to join the cluster is an incorrect cluster control link configuration; for example, the cluster control link MTU may be set higher than the connecting switch MTUs.

New/modified screens: Devices > Device Management > More > Cluster Live Status.

Troubleshooting file generation and download available from Device and Cluster pages.

7.4.1

You can generate and download troubleshooting files for each device on the Device page and also for all cluster nodes on the Cluster page. For a cluster, you can download all files as a single compressed file. You can also include cluster logs for the cluster for cluster nodes. You can alternatively trigger file generation from the Devices > Device Management > More > Troubleshoot Files menu.

New/modified screens:

Devices > Device Management > Device > General
Devices > Device Management > Cluster > General

View CLI output for a device or device cluster.

7.4.1

任意

You can view a set of pre-defined CLI outputs that can help you troubleshoot the device or cluster. You can also enter any show command and see the output.

New/modified screens: Devices > Device Management > Cluster > General

クラスタのヘルスモニターの設定。

7.3.0

いずれか

クラスタのヘルスモニター設定を編集できるようになりました。

新規/変更された画面：[デバイス（Devices）] > [デバイス管理（Device Management）] > クラスタ（Cluster） > [クラスタのヘルスモニターの設定（Cluster Health Monitor Settings）]

（注）

以前に FlexConfig を使用してこれらの設定を行った場合は、展開前に必ず FlexConfig の設定を削除してください。削除しなかった場合は、FlexConfig の設定によって Management Center の設定が上書きされます。

クラスタヘルスモニターダッシュボード。

7.3.0

いずれか

クラスタのヘルスモニターダッシュボードでクラスタの状態を表示できるようになりました。

新規/変更された画面：[システム（System）] > [正常性（Health）] > [モニター（Monitor）]

16 ノードクラスタのサポート。

7.2.0

Firepower 4100/9300 で 16 ノードクラスタを構成できるようになりました。これまでは最大で 6 ユニットでした。

新規/変更された画面：なし。

サポートされるプラットフォーム：Firepower 4100/9300

ファイアウォールの変更に対するクラスタの展開がより迅速に完了します。

7.1.0

ファイアウォールの変更に対するクラスタの展開がより迅速に完了するようになりました。

新規/変更された画面：なし。

クラスタリング用の PAT ポートブロック割り当ての改善。

7.0.0

PAT ポートブロック割り当ての改善により、制御ユニットはノードに参加するためにポートを確保し、未使用のポートを積極的に再利用できるようになります。割り当てを最適化するには、FlexConfig を使用して cluster-member-limit コマンドを実行して、予定しているクラスタ内の最大ノード数を設定します。これにより、制御ユニットは計画されたノード数にポートブロックを割り当てることができ、使用する予定のない追加のノード用にポートを予約する必要がなくなります。デフォルトは 16 ノードです。また、syslog 747046 を監視して、新しいノードに使用できるポートが十分にあることを確認することもできます。

新規/変更されたコマンド：cluster-member-limit （FlexConfig）、show nat pool cluster [summary] 、show nat pool ip detail

Snort の変更に対するクラスタの展開がより迅速に完了し、イベントが発生するとより迅速に失敗する。

6.7.0

Snort の変更に対するクラスタの展開がより迅速に完了するようになりました。また、Firewall Management Center 展開が失敗する原因となるイベントがクラスタにある場合、エラーがより迅速に発生するようになりました。

新規/変更された画面：なし。

クラスタ管理の改善。

6.7.0

Firewall Management Center では、以前は CLI を使用することでしか実現できなかった、次のようなクラスタ管理機能が改善されました。

クラスタユニットの有効化および無効化
[デバイス管理（Device Management）] ページからクラスタのステータスを表示（ユニットごとの履歴とサマリーを含む）
ロールの制御ユニットへの変更

新規/変更された画面：

[デバイス（Devices）] > [デバイス管理（Device Management）] > [詳細（More）]メニュー
[デバイス（Devices）] > [デバイス管理（Device Management）] > [クラスタ（Cluster）] > [全般（General）]エリア > [クラスタのライブステータス（Cluster Live Status）] リンク > [クラスタステータス（Cluster Status）]

サポートされるプラットフォーム：Firepower 4100/9300

マルチインスタンスクラスタリング。

6.6.0

コンテナインスタンスを使用してクラスタを作成できるようになりました。Firepower 9300 では、クラスタ内の各モジュールに 1 つのコンテナインスタンスを含める必要があります。セキュリティエンジン/モジュールごとに複数のコンテナインスタンスをクラスタに追加することはできません。クラスタインスタンスごとに同じセキュリティモジュールまたはシャーシモデルを使用することを推奨します。ただし、必要に応じて、同じクラスタ内に異なる Firepower 9300 セキュリティモジュールタイプまたは Firepower 4100 モデルのコンテナインスタンスを混在させ、一致させることができます。同じクラスタ内で Firepower 9300 と 4100 のインスタンスを混在させることはできません。

新規/変更された FXOS コマンド： set port-type cluster

新規/変更された [Firepower Chassis Manager] 画面：

[論理デバイス（Logical Devices）] > [クラスタの追加（Add Cluster）]
[インターフェイス（Interfaces）] > [すべてのインターフェイス（All Interfaces）] > [新規追加（Add New）] ドロップダウンメニュー [サブインターフェイス（Subinterface）] [タイプ（Type）] フィールド

サポートされるプラットフォーム：Firepower 4100/9300 上の Firewall Threat Defense

データユニットとの設定の並列同期。

6.6.0

制御ユニットでは、デフォルトで設定変更がデータユニットと同時に同期化されるようになりました。以前は、順番に同期が行われていました。

新規/変更された画面：なし。

クラスタへの参加の失敗や削除のメッセージを show cluster history に追加。

6.6.0

クラスタユニットがクラスタへの参加に失敗した場合や、クラスタを離脱した場合の新しいメッセージが、 show cluster history コマンドに追加されました。

新規/変更されたコマンド： show cluster history

新規/変更された画面：なし。

デッド接続検出（DCD）の発信側および応答側の情報、およびクラスタ内の DCD のサポート。

6.5.0

デッド接続検出（DCD）を有効にした場合は、show conn detail コマンドを使用して発信側と応答側に関する情報を取得できます。デッド接続検出を使用すると、非アクティブな接続を維持できます。show conn の出力は、エンドポイントがプローブされた頻度が示されます。さらに、DCD がクラスタでサポートされるようになりました。

新しい/変更されたコマンド：show conn （出力のみ）

サポートされるプラットフォーム：Firepower 4100/9300 上の Firewall Threat Defense

クラスタの追加が容易に。

6.3.0

Firewall Management Center にクラスタの任意のユニットを追加できるようになりました。他のクラスタユニットは自動的に検出されます。以前は、各クラスタユニットを個別のデバイスとして追加し、グループ化してクラスタにする必要がありました。クラスタユニットの追加も自動で実行されるようになりました。ユニットは手動で削除する必要があることに注意してください。

新規/変更された画面：

[デバイス（Devices）] > [デバイス管理（Device Management）] > [追加（Add）]ドロップダウンメニュー [デバイス（Devices）] > [デバイスの追加（Add Device）]ダイアログボックス

[デバイス（Devices）] > [デバイス管理（Device Management）] > [クラスタ（Cluster）] タブ [全般（General）] エリア [クラスタの登録ステータス（Cluster Registration Status）] [現在のクラスタの概要（Current Cluster Summary）] リンク [クラスタステータス（Cluster Status）] ダイアログボックス

サポートされるプラットフォーム：Firepower 4100/9300 上の Firewall Threat Defense

中央集中型機能としてのクラスタリングによるサイト間 VPN のサポート。

6.2.3.3

クラスタリングを使用してサイト間 VPN を設定できるようになりました。サイト間 VPN は、中央集中型機能です。制御ユニットのみが VPN 接続をサポートします。

サポートされるプラットフォーム：Firepower 4100/9300 上の Firewall Threat Defense

内部障害発生後に自動的にクラスタに再参加します。

6.2.3

以前は、多くの内部エラー状態によって、クラスタユニットがクラスタから削除され、ユーザーが問題を解決した後で、手動でクラスタに再参加する必要がありました。現在は、ユニットが自動的に、5 分、10 分、20 分の間隔でクラスタに再参加しようとします。内部エラーには、アプリケーション同期のタイムアウト、一貫性のないアプリケーションステータスなどがあります。

新しい/変更されたコマンド：show cluster info auto-join

変更された画面はありません。

サポートされるプラットフォーム：Firepower 4100/9300 上の Firewall Threat Defense

6 モジュールの複数シャーシのクラスタリング、Firepower 4100 をサポート。

6.2.0

FXOS 2.1.1 では、Firepower 9300 および 4100 の複数のシャーシでクラスタリングを有効にできるようになりました。Firepower 9300 の場合、最大 6 つのモジュールを含めることができます。たとえば、6 つのシャーシで 1 つのモジュールを使用したり、3 つのシャーシで 2 つのモジュールを使用したり、最大 6 つのモジュールを組み合わせたりできます。Firepower 4100 の場合、最大 6 つのシャーシを含めることができます。

（注）

サイト間クラスタリングもサポートされていません。しかし、サイト固有の MAC および IP アドレス、ディレクタのローカリゼーション、サイトの冗長性、クラスタフローモビリティなどの冗長性と安定性を向上させるためのカスタマイズは、FlexConfig 機能を使用した場合にのみ設定できます。

変更された画面はありません。

サポートされるプラットフォーム：Firepower 4100/9300 上の Firewall Threat Defense

1 つの Firepower 9300 シャーシを使用した複数モジュールでのクラスタリング。

6.0.1

FirePOWER 9300 シャーシ内では、最大 3 つのセキュリティモジュールをクラスタ化できます。シャーシ内のすべてのモジュールは、クラスタに属している必要があります。

新規/変更された画面：

[デバイス（Devices）] > [デバイス管理（Device Management）] > [追加（Add）] > [クラスタの追加（Add Cluster）]

[Devices] > [Device Management] > [Cluster]

サポートされるプラットフォーム：Firepower 9300 上の Firewall Threat Defense

Cisco Secure Firewall Management Center 7.7 デバイス構成ガイド

偏向のない言語

翻訳について

検索結果

章のタイトル： Firepower 4100/9300 のクラスタリング

Firepower 4100/9300 のクラスタリング

About Clustering on the Firepower 4100/9300 Chassis

Bootstrap Configuration

Cluster Members

Cluster Control Link

Size the Cluster Control Link

Cluster Control Link Redundancy

Cluster Control Link Reliability for Inter-Chassis Clustering

Cluster Control Link Network

Management Network

管理インターフェイス

Cluster Interfaces

Spanned EtherChannels

Connecting to a Redundant Switch System

Configuration Replication

クラスタリングのライセンス

クラスタリングの要件と前提条件

クラスタ モデルのサポート

User roles

クラスタリングハードウェアおよびソフトウェアの要件

マルチインスタンス クラスタリングの要件

スイッチ要件

Clustering Guidelines and Limitations

Switches for Clustering

EtherChannels for Clustering

Additional Guidelines

Defaults

クラスタリングの設定

FXOS: Add a Firewall Threat Defense Cluster

Create a Firewall Threat Defense Cluster

始める前に

手順

Add More Cluster Nodes

始める前に

手順

Firewall Management Center：クラスタの追加

始める前に

手順

Firewall Management Center：クラスタ、データインターフェイスの設定

手順

Firewall Management Center：クラスタのヘルスモニターの設定

手順

FXOS: Remove a Cluster Node

Temporary Removal

Permanent Removal

FMC：クラスタメンバーの管理

新規クラスタ メンバーの追加

始める前に

手順

クラスタ メンバーの置換

始める前に

手順

メンバーの非アクティブ化

手順

クラスタへの再参加

手順

データノードの登録解除

始める前に

手順

制御ユニットの変更

手順

クラスタ メンバーの照合

手順

Firewall Management Center：クラスタのモニタリング

クラスタ ヘルス モニター ダッシュボード

クラスタのヘルスモニター

クラスタ ヘルスの表示

始める前に

手順

クラスタメトリック

Firewall Management Center：クラスタのトラブルシューティング

クラスター制御リンクへの ping の実行

手順

Examples for Clustering

Firewall on a Stick

クラスタモデルのサポート

マルチインスタンスクラスタリングの要件

新規クラスタメンバーの追加

クラスタメンバーの置換

クラスタメンバーの照合

クラスタヘルスモニターダッシュボード

クラスタヘルスの表示