Logical Devices on the Firepower 4100/9300

The Firepower 4100/9300 is a flexible security platform on which you can install one or more logical devices. Before you can add the threat defense to the management center, you must configure chassis interfaces, add a logical device, and assign interfaces to the device on the Firepower 4100/9300 chassis using the Secure Firewall chassis manager or the FXOS CLI. This chapter describes basic interface configuration and how to add a standalone or High Availability logical device using the Secure Firewall chassis manager. To add a clustered logical device, see Clustering for the Firepower 4100/9300. To use the FXOS CLI, see the FXOS CLI configuration guide. For more advanced FXOS procedures and troubleshooting, see the FXOS configuration guide.

About Interfaces

The Firepower 4100/9300 chassis supports physical interfaces, VLAN subinterfaces for container instances, and EtherChannel (port-channel) interfaces. EtherChannel interfaces can include up to 16 member interfaces of the same type.

Chassis Management Interface

The chassis management interface is used for management of the FXOS Chassis by SSH or chassis manager. This interface appears at the top of the Interfaces tab as MGMT, and you can only enable or disable this interface on the Interfaces tab. This interface is separate from the mgmt-type interface that you assign to the logical devices for application management.

To configure parameters for this interface, you must configure them from the CLI. To view information about this interface in the FXOS CLI, connect to local management and show the management port:

Firepower # connect local-mgmt

Firepower(local-mgmt) # show mgmt-port

Note that the chassis management interface remains up even if the physical cable or SFP module are unplugged, or if the mgmt-port shut command is performed.


Note

The chassis management interface does not support jumbo frames.

Interface Types

Physical interfaces, VLAN subinterfaces for container instances, and EtherChannel (port-channel) interfaces can be one of the following types:

  • Data—Use for regular data. Data interfaces cannot be shared between logical devices, and logical devices cannot communicate over the backplane to other logical devices. For traffic on Data interfaces, all traffic must exit the chassis on one interface and return on another interface to reach another logical device.

  • Data-sharing—Use for regular data. Only supported with container instances, these data interfaces can be shared by one or more logical devices/container instances (threat defense-using-management center only). Each container instance can communicate over the backplane with all other instances that share this interface. Shared interfaces can affect the number of container instances you can deploy. Shared interfaces are not supported for bridge group member interfaces (in transparent mode or routed mode), inline sets, passive interfaces, clusters, or failover links.

  • Mgmt—Use to manage application instances. These interfaces can be shared by one or more logical devices to access external hosts; logical devices cannot communicate over this interface with other logical devices that share the interface. You can only assign one management interface per logical device. Depending on your application and manager, you can later enable management from a data interface; but you must assign a Management interface to the logical device even if you don't intend to use it after you enable data management. For information about the separate chassis management interface, see Chassis Management Interface.


    Note

    Mgmt interface change will cause reboot of the logical device, for example one change mgmt from e1/1 to e1/2 will cause the logical device to reboot to apply the new management.

  • Eventing—Use as a secondary management interface for threat defense-using-management center devices. To use this interface, you must configure its IP address and other parameters at the threat defense CLI. For example, you can separate management traffic from events (such as web events). See the management center configuration guide for more information. Eventing interfaces can be shared by one or more logical devices to access external hosts; logical devices cannot communicate over this interface with other logical devices that share the interface. If you later configure a data interface for management, you cannot use a separate eventing interface.


    Note

    A virtual Ethernet interface is allocated when each application instance is installed. If the application does not use an eventing interface, then the virtual interface will be in an admin down state. 

    Firepower # show interface Vethernet775
Firepower # Vethernet775 is down (Administratively down)
Bound Interface is Ethernet1/10
Port description is server 1/1, VNIC ext-mgmt-nic5

  • Cluster—Use as the cluster control link for a clustered logical device. By default, the cluster control link is automatically created on Port-channel 48. The Cluster type is only supported on EtherChannel interfaces. For multi-instance clustering, you cannot share a Cluster-type interface across devices. You can add VLAN subinterfaces to the Cluster EtherChannel to provide separate cluster control links per cluster. If you add subinterfaces to a Cluster interface, you cannot use that interface for a native cluster. The device manager and CDO does not support clustering.


Note

This chapter discusses FXOS VLAN subinterfaces only. You can separately create subinterfaces within the threat defense application. See FXOS Interfaces vs. Application Interfaces for more information.

See the following table for interface type support for the threat defense and ASA applications in standalone and cluster deployments.

Table 1. Interface Type Support

Application

Data

Data: Subinterface

Data-Sharing

Data-Sharing: Subinterface

Mgmt

Eventing

Cluster (EtherChannel only)

Cluster: Subinterface

Threat Defense

Standalone Native Instance

Yes

—

—

—

Yes

Yes

—

—

Standalone Container Instance

Yes

Yes

Yes

Yes

Yes

Yes

—

—

Cluster Native Instance

Yes

(EtherChannel only for inter-chassis cluster)

—

—

—

Yes

Yes

Yes

—

Cluster Container Instance

Yes

(EtherChannel only for inter-chassis cluster)

—

—

—

Yes

Yes

Yes

Yes

ASA

Standalone Native Instance

Yes

—

—

—

Yes

—

Yes

—

Cluster Native Instance

Yes

(EtherChannel only for inter-chassis cluster)

—

—

—

Yes

—

Yes

—

FXOS Interfaces vs. Application Interfaces

The Firepower 4100/9300 manages the basic Ethernet settings of physical interfaces, VLAN subinterfaces for container instances, and EtherChannel (port-channel) interfaces. Within the application, you configure higher level settings. For example, you can only create EtherChannels in FXOS; but you can assign an IP address to the EtherChannel within the application.

The following sections describe the interaction between FXOS and the application for interfaces.

VLAN Subinterfaces

For all logical devices, you can create VLAN subinterfaces within the application.

For container instances in standalone mode only, you can also create VLAN subinterfaces in FXOS. Multi-instance clusters do not support subinterfaces in FXOS except on the Cluster-type interface. Application-defined subinterfaces are not subject to the FXOS limit. Choosing in which operating system to create subinterfaces depends on your network deployment and personal preference. For example, to share a subinterface, you must create the subinterface in FXOS. Another scenario that favors FXOS subinterfaces comprises allocating separate subinterface groups on a single interface to multiple instances. For example, you want to use Port-channel1 with VLAN 2–11 on instance A, VLAN 12–21 on instance B, and VLAN 22–31 on instance C. If you create these subinterfaces within the application, then you would have to share the parent interface in FXOS, which may not be desirable. See the following illustration that shows the three ways you can accomplish this scenario:

Figure 1. VLANs in FXOS vs. the Application for Container Instances
VLAN subinterface scenario

Independent Interface States in the Chassis and in the Application

You can administratively enable and disable interfaces in both the chassis and in the application. For an interface to be operational, the interface must be enabled in both operating systems. Because the interface state is controlled independently, you may have a mismatch between the chassis and application.

The default state of an interface within the application depends on the type of interface. For example, the physical interface or EtherChannel is disabled by default within the application, but a subinterface is enabled by default.

Shared Interface Scalability

Instances can share data-sharing type interfaces. This capability lets you conserve physical interface usage as well as support flexible networking deployments. When you share an interface, the chassis uses unique MAC addresses to forward traffic to the correct instance. However, shared interfaces can cause the forwarding table to grow large due to the need for a full mesh topology within the chassis (every instance must be able to communicate with every other instance that is sharing the same interface). Therefore, there are limits to how many interfaces you can share.

In addition to the forwarding table, the chassis maintains a VLAN group table for VLAN subinterface forwarding. You can create up to 500 VLAN subinterfaces.

See the following limits for shared interface allocation:

Shared Interface Best Practices

For optimal scalability of the forwarding table, share as few interfaces as possible. Instead, you can create up to 500 VLAN subinterfaces on one or more physical interfaces and then divide the VLANs among the container instances.

When sharing interfaces, follow these practices in the order of most scalable to least scalable:

  1. Best—Share subinterfaces under a single parent, and use the same set of subinterfaces with the same group of instances.

    For example, create a large EtherChannel to bundle all of your like-kind interfaces together, and then share subinterfaces of that EtherChannel: Port-Channel1.2, 3, and 4 instead of Port-Channel2, Port-Channel3, and Port-Channel4. When you share subinterfaces from a single parent, the VLAN group table provides better scaling of the forwarding table than when sharing physical/EtherChannel interfaces or subinterfaces across parents.

    Figure 2. Best: Shared Subinterface Group on One Parent

    If you do not share the same set of subinterfaces with a group of instances, your configuration can cause more resource usage (more VLAN groups). For example, share Port-Channel1.2, 3, and 4 with instances 1, 2, and 3 (one VLAN group) instead of sharing Port-Channel1.2 and 3 with instances 1 and 2, while sharing Port-Channel1.3 and 4 with instance 3 (two VLAN groups).

    Figure 3. Good: Sharing Multiple Subinterface Groups on One Parent

  2. Fair—Share subinterfaces across parents.

    For example, share Port-Channel1.2, Port-Channel2.3, and Port-Channel3.4 instead of Port-Channel2, Port-Channel4, and Port-Channel4. Although this usage is not as efficient as only sharing subinterfaces on the same parent, it still takes advantage of VLAN groups.

    Figure 4. Fair: Shared Subinterfaces on Separate Parents

  3. Worst—Share individual parent interfaces (physical or EtherChannel).

    This method uses the most forwarding table entries.

    Figure 5. Worst: Shared Parent Interfaces

Shared Interface Usage Examples

See the following tables for examples of interface sharing and scalability. The below scenarios assume use of one physical/EtherChannel interface for management shared across all instances, and another physical or EtherChannel interface with dedicated subinterfaces for use with High Availability.

Firepower 9300 with Three SM-44s

The following table applies to three SM-44 security modules on a 9300 using only physical interfaces or EtherChannels. Without subinterfaces, the maximum number of interfaces are limited. Moreover, sharing multiple physical interfaces uses more forwarding table resources than sharing multiple subinterfaces.

Each SM-44 module can support up to 14 instances. Instances are split between modules as necessary to stay within limits.

Table 2. Physical/EtherChannel Interfaces and Instances on a Firepower 9300 with Three SM-44s

Dedicated Interfaces

Shared Interfaces

Number of Instances

% Forwarding Table Used

32:

  • 8

  • 8

  • 8

  • 8

0

4:

  • Instance 1

  • Instance 2

  • Instance 3

  • Instance 4

16%

30:

  • 15

  • 15

0

2:

  • Instance 1

  • Instance 2

14%

14:

  • 14 (1 ea.)

1

14:

  • Instance 1-Instance 14

46%

33:

  • 11 (1 ea.)

  • 11 (1 ea.)

  • 11 (1 ea.)

3:

  • 1

  • 1

  • 1

33:

  • Instance 1-Instance 11

  • Instance 12-Instance 22

  • Instance 23-Instance 33

98%

33:

  • 11 (1 ea.)

  • 11 (1 ea.)

  • 12 (1 ea.)

3:

  • 1

  • 1

  • 1

34:

  • Instance 1-Instance 11

  • Instance 12-Instance 22

  • Instance 23-Instance 34

102%

DISALLOWED

30:

  • 30 (1 ea.)

1

6:

  • Instance 1-Instance 6

25%

30:

  • 10 (5 ea.)

  • 10 (5 ea.)

  • 10 (5 ea.)

3:

  • 1

  • 1

  • 1

6:

  • Instance 1-Instance2

  • Instance 2-Instance 4

  • Instance 5-Instance 6

23%

30:

  • 30 (6 ea.)

2

5:

  • Instance 1-Instance 5

28%

30:

  • 12 (6 ea.)

  • 18 (6 ea.)

4:

  • 2

  • 2

5:

  • Instance 1-Instance2

  • Instance 2-Instance 5

26%

24:

  • 6

  • 6

  • 6

  • 6

7

4:

  • Instance 1

  • Instance 2

  • Instance 3

  • Instance 4

44%

24:

  • 12 (6 ea.)

  • 12 (6 ea.)

14:

  • 7

  • 7

4:

  • Instance 1-Instance2

  • Instance 2-Instance 4

41%

The following table applies to three SM-44 security modules on a 9300 using subinterfaces on a single parent physical interface. For example, create a large EtherChannel to bundle all of your like-kind interfaces together, and then share subinterfaces of that EtherChannel. Sharing multiple physical interfaces uses more forwarding table resources than sharing multiple subinterfaces.

Each SM-44 module can support up to 14 instances. Instances are split between modules as necessary to stay within limits.

Table 3. Subinterfaces on One Parent and Instances on a Firepower 9300 with Three SM-44s

Dedicated Subinterfaces

Shared Subinterfaces

Number of Instances

% Forwarding Table Used

168:

  • 168 (4 ea.)

0

42:

  • Instance 1-Instance 42

33%

224:

  • 224 (16 ea.)

0

14:

  • Instance 1-Instance 14

27%

14:

  • 14 (1 ea.)

1

14:

  • Instance 1-Instance 14

46%

33:

  • 11 (1 ea.)

  • 11 (1 ea.)

  • 11 (1 ea.)

3:

  • 1

  • 1

  • 1

33:

  • Instance 1-Instance 11

  • Instance 12-Instance 22

  • Instance 23-Instance 33

98%

70:

  • 70 (5 ea.)

1

14:

  • Instance 1-Instance 14

46%

165:

  • 55 (5 ea.)

  • 55 (5 ea.)

  • 55 (5 ea.)

3:

  • 1

  • 1

  • 1

33:

  • Instance 1-Instance 11

  • Instance 12-Instance 22

  • Instance 23-Instance 33

98%

70:

  • 70 (5 ea.)

2

14:

  • Instance 1-Instance 14

46%

165:

  • 55 (5 ea.)

  • 55 (5 ea.)

  • 55 (5 ea.)

6:

  • 2

  • 2

  • 2

33:

  • Instance 1-Instance 11

  • Instance 12-Instance 22

  • Instance 23-Instance 33

98%

70:

  • 70 (5 ea.)

10

14:

  • Instance 1-Instance 14

46%

165:

  • 55 (5 ea.)

  • 55 (5 ea.)

  • 55 (5 ea.)

30:

  • 10

  • 10

  • 10

33:

  • Instance 1-Instance 11

  • Instance 12-Instance 22

  • Instance 23-Instance 33

102%

DISALLOWED
Firepower 9300 with One SM-44

The following table applies to the Firepower 9300 with one SM-44 using only physical interfaces or EtherChannels. Without subinterfaces, the maximum number of interfaces are limited. Moreover, sharing multiple physical interfaces uses more forwarding table resources than sharing multiple subinterfaces.

The Firepower 9300 with one SM-44 can support up to 14 instances.

Table 4. Physical/EtherChannel Interfaces and Instances on a Firepower 9300 with One SM-44

Dedicated Interfaces

Shared Interfaces

Number of Instances

% Forwarding Table Used

32:

  • 8

  • 8

  • 8

  • 8

0

4:

  • Instance 1

  • Instance 2

  • Instance 3

  • Instance 4

16%

30:

  • 15

  • 15

0

2:

  • Instance 1

  • Instance 2

14%

14:

  • 14 (1 ea.)

1

14:

  • Instance 1-Instance 14

46%

14:

  • 7 (1 ea.)

  • 7 (1 ea.)

2:

  • 1

  • 1

14:

  • Instance 1-Instance 7

  • Instance 8-Instance 14

37%

32:

  • 8

  • 8

  • 8

  • 8

1

4:

  • Instance 1

  • Instance 2

  • Instance 3

  • Instance 4

21%

32:

  • 16 (8 ea.)

  • 16 (8 ea.)

2

4:

  • Instance 1-Instance 2

  • Instance 3-Instance 4

20%

32:

  • 8

  • 8

  • 8

  • 8

2

4:

  • Instance 1

  • Instance 2

  • Instance 3

  • Instance 4

25%

32:

  • 16 (8 ea.)

  • 16 (8 ea.)

4:

  • 2

  • 2

4:

  • Instance 1-Instance 2

  • Instance 3-Instance 4

24%

24:

  • 8

  • 8

  • 8

8

3:

  • Instance 1

  • Instance 2

  • Instance 3

37%

10:

  • 10 (2 ea.)

10

5:

  • Instance 1-Instance 5

69%

10:

  • 6 (2 ea.)

  • 4 (2 ea.)

20:

  • 10

  • 10

5:

  • Instance 1-Instance 3

  • Instance 4-Instance 5

59%

14:

  • 12 (2 ea.)

10

7:

  • Instance 1-Instance 7

109%

DISALLOWED

The following table applies to the Firepower 9300 with one SM-44 using subinterfaces on a single parent physical interface. For example, create a large EtherChannel to bundle all of your like-kind interfaces together, and then share subinterfaces of that EtherChannel. Sharing multiple physical interfaces uses more forwarding table resources than sharing multiple subinterfaces.

The Firepower 9300 with one SM-44 can support up to 14 instances.

Table 5. Subinterfaces on One Parent and Instances on a Firepower 9300 with One SM-44

Dedicated Subinterfaces

Shared Subinterfaces

Number of Instances

% Forwarding Table Used

112:

  • 112 (8 ea.)

0

14:

  • Instance 1-Instance 14

17%

224:

  • 224 (16 ea.)

0

14:

  • Instance 1-Instance 14

17%

14:

  • 14 (1 ea.)

1

14:

  • Instance 1-Instance 14

46%

14:

  • 7 (1 ea.)

  • 7 (1 ea.)

2:

  • 1

  • 1

14:

  • Instance 1-Instance 7

  • Instance 8-Instance 14

37%

112:

  • 112 (8 ea.)

1

14:

  • Instance 1-Instance 14

46%

112:

  • 56 (8 ea.)

  • 56 (8 ea.)

2:

  • 1

  • 1

14:

  • Instance 1-Instance 7

  • Instance 8-Instance 14

37%

112:

  • 112 (8 ea.)

2

14:

  • Instance 1-Instance 14

46%

112:

  • 56 (8 ea.)

  • 56 (8 ea.)

4:

  • 2

  • 2

14:

  • Instance 1-Instance 7

  • Instance 8-Instance 14

37%

140:

  • 140 (10 ea.)

10

14:

  • Instance 1-Instance 14

46%

140:

  • 70 (10 ea.)

  • 70 (10 ea.)

20:

  • 10

  • 10

14:

  • Instance 1-Instance 7

  • Instance 8-Instance 14

37%

Viewing Shared Interface Resources

To view forwarding table and VLAN group usage, see the Devices & Network > Interface Forwarding Utilization area. For example:

Inline Set Link State Propagation for the Threat Defense

An inline set acts like a bump on the wire, and binds two interfaces together to slot into an existing network. This function allows the system to be installed in any network environment without the configuration of adjacent network devices. Inline interfaces receive all traffic unconditionally, but all traffic received on these interfaces is retransmitted out of an inline set unless explicitly dropped.

When you configure an inline set in the threat defense application and enable link state propagation, the threat defense sends inline set membership to the FXOS chassis. Link state propagation means that the chassis automatically brings down the second interface in the inline interface pair when one of the interfaces in an inline set goes down. When the downed interface comes back up, the second interface automatically comes back up, also. In other words, if the link state of one interface changes, the chassis senses the change and updates the link state of the other interface to match it. Note that the chassis requires up to 4 seconds to propagate link state changes. Link state propagation is especially useful in resilient network environments where routers are configured to reroute traffic automatically around network devices that are in a failure state.


Note

Do not enable Hardware Bypass and link state propagation for the same inline set.

About Logical Devices

A logical device lets you run one application instance (either ASA or threat defense) and also one optional decorator application (Radware DefensePro) to form a service chain.

When you add a logical device, you also define the application instance type and version, assign interfaces, and configure bootstrap settings that are pushed to the application configuration.


Note

For the Firepower 9300, you can install different application types (ASA and threat defense) on separate modules in the chassis. You can also run different versions of an application instance type on separate modules.

Standalone and Clustered Logical Devices

You can add the following logical device types:

  • Standalone—A standalone logical device operates as a standalone unit or as a unit in a High Availability pair.

  • Cluster—A clustered logical device lets you group multiple units together, providing all the convenience of a single device (management, integration into a network) while achieving the increased throughput and redundancy of multiple devices. Multiple module devices, like the Firepower 9300, support intra-chassis clustering. For the Firepower 9300, all three modules must participate in the cluster, for both native and container instances. The device manager does not support clustering.

Logical Device Application Instances: Container and Native

Application instances run in the following deployment types:

  • Native instance—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.

  • Container instance—A container instance uses a subset of resources of the security module/engine, so you can install multiple container instances. Multi-instance capability is only supported for the threat defense using management center; it is not supported for the ASA or the threat defense using device manager.


    Note

    Multi-instance capability is similar to ASA multiple context mode, although the implementation is different. Multiple context mode partitions a single application instance, while multi-instance capability allows independent container instances. Container instances allow hard resource separation, separate configuration management, separate reloads, separate software updates, and full threat defense feature support. Multiple context mode, due to shared resources, supports more contexts on a given platform. Multiple context mode is not available on the threat defense.

For the Firepower 9300, you can use a native instance on some modules, and container instances on the other module(s).

Container Instance Interfaces

To provide flexible physical interface use for container instances, you can create VLAN subinterfaces in FXOS and also share interfaces (VLAN or physical) between multiple instances. Native instances cannot use VLAN subinterfaces or shared interfaces. A multi-instance cluster cannot use VLAN subinterfaces or shared interfaces. An exception is made for the cluster control link, which can use a subinterface of the Cluster EtherChannel. See Shared Interface Scalability and Add a VLAN Subinterface for Container Instances.


Note

This document discusses FXOS VLAN subinterfaces only. You can separately create subinterfaces within the threat defense application. See FXOS Interfaces vs. Application Interfaces for more information.

How the Chassis Classifies Packets

Each packet that enters the chassis must be classified, so that the chassis can determine to which instance to send a packet.

  • Unique Interfaces—If only one instance is associated with the ingress interface, the chassis classifies the packet into that instance. For bridge group member interfaces (in transparent mode or routed mode), inline sets, or passive interfaces, this method is used to classify packets at all times.

  • Unique MAC Addresses—The chassis automatically generates unique MAC addresses for all interfaces, including shared interfaces. If multiple instances share an interface, then the classifier uses unique MAC addresses assigned to the interface in each instance. An upstream router cannot route directly to an instance without unique MAC addresses. You can also set the MAC addresses manually when you configure each interface within the application.


Note

If the destination MAC address is a multicast or broadcast MAC address, the packet is duplicated and delivered to each instance.

Classification Examples

Packet Classification with a Shared Interface Using MAC Addresses

The following figure shows multiple instances sharing an outside interface. The classifier assigns the packet to Instance C because Instance C includes the MAC address to which the router sends the packet.

Figure 6. Packet Classification with a Shared Interface Using MAC Addresses
Incoming Traffic from Inside Networks

Note that all new incoming traffic must be classified, even from inside networks. The following figure shows a host on the Instance C inside network accessing the internet. The classifier assigns the packet to Instance C because the ingress interface is Ethernet 1/2.3, which is assigned to Instance C.

Figure 7. Incoming Traffic from Inside Networks
Transparent Firewall Instances

For transparent firewalls, you must use unique interfaces. The following figure shows a packet destined to a host on the Instance C inside network from the internet. The classifier assigns the packet to Instance C because the ingress interface is Ethernet 1/2.3, which is assigned to Instance C.

Figure 8. Transparent Firewall Instances
Inline Sets

For inline sets, you must use unique interfaces and they must be physical interfaces or EtherChannels. The following figure shows a packet destined to a host on the Instance C inside network from the internet. The classifier assigns the packet to Instance C because the ingress interface is Ethernet 1/5, which is assigned to Instance C.

Figure 9. Inline Sets

Cascading Container Instances

Placing an instance directly in front of another instance is called cascading instances; the outside interface of one instance is the same interface as the inside interface of another instance. You might want to cascade instances if you want to simplify the configuration of some instances by configuring shared parameters in the top instance.

The following figure shows a gateway instance with two instances behind the gateway.

Figure 10. Cascading Instances

Note

Do not use cascading instances (using a shared interface) with High Availability. After a failover occurs and the standby unit rejoins, MAC addresses can overlap temporarily and cause an outage. You should instead use unique interfaces for the gateway instance and inside instance using an external switch to pass traffic between the instances.

Typical Multi-Instance Deployment

The following example includes three container instances in routed firewall mode. They include the following interfaces:

  • Management—All instances use the Port-Channel1 interface (management type). This EtherChannel includes two 10 Gigibit Ethernet interfaces. Within each application, the interface uses a unique IP address on the same management network.

  • Inside—Each instance uses a subinterface on Port-Channel2 (data type). This EtherChannel includes two 10 Gigibit Ethernet interfaces. Each subinterface is on a separate network.

  • Outside—All instances use the Port-Channel3 interface (data-sharing type). This EtherChannel includes two 10 Gigibit Ethernet interfaces. Within each application, the interface uses a unique IP address on the same outside network.

  • Failover—Each instance uses a subinterface on Port-Channel4 (data type). This EtherChannel includes two 10 Gigibit Ethernet interfaces. Each subinterface is on a separate network.

Typical Multi-Instance Deployment

Automatic MAC Addresses for Container Instance Interfaces

The chassis automatically generates MAC addresses for instance interfaces, and guarantees that a shared interface in each instance uses a unique MAC address.

If you manually assign a MAC address to a shared interface within the instance, then the manually-assigned MAC address is used. If you later remove the manual MAC address, the autogenerated address is used. In the rare circumstance that the generated MAC address conflicts with another private MAC address in your network, we suggest that you manually set the MAC address for the interface within the instance.

Because autogenerated addresses start with A2, you should not start manual MAC addresses with A2 due to the risk of overlapping addresses.

The chassis generates the MAC address using the following format:

A2xx.yyzz.zzzz

Where xx.yy is a user-defined prefix or a system-defined prefix, and zz.zzzz is an internal counter generated by the chassis. The system-defined prefix matches the lower 2 bytes of the first MAC address in the burned-in MAC address pool that is programmed into the IDPROM. Use connect fxos , then show module to view the MAC address pool. For example, if the range of MAC addresses shown for module 1 is b0aa.772f.f0b0 to b0aa.772f.f0bf, then the system prefix will be f0b0.

The user-defined prefix is an integer that is converted into hexadecimal. For an example of how the user-defined prefix is used, if you set a prefix of 77, then the chassis converts 77 into the hexadecimal value 004D (yyxx). When used in the MAC address, the prefix is reversed (xxyy) to match the chassis native form:

A24D.00zz.zzzz

For a prefix of 1009 (03F1), the MAC address is:

A2F1.03zz.zzzz

Container Instance Resource Management

To specify resource usage per container instance, create one or more resource profiles in FXOS. When you deploy the logical device/application instance, you specify the resource profile that you want to use. The resource profile sets the number of CPU cores; RAM is dynamically allocated according to the number of cores, and disk space is set to 40 GB per instance. To view the available resources per model, see Requirements and Prerequisites for Container Instances. To add a resource profile, see Add a Resource Profile for Container Instances.

Performance Scaling Factor for Multi-Instance Capability

The maximum throughput (connections, VPN sessions, and TLS proxy sessions) for a platform is calculated for a native instance’s use of memory and CPU (and this value is shown in show resource usage ). If you use multiple instances, then you need to calculate the throughput based on the percentage of CPU cores that you assign to the instance. For example, if you use a container instance with 50% of the cores, then you should initially calculate 50% of the throughput. Moreover, the throughput available to a container instance may be less than that available to a native instance.

For detailed instructions on calculating the throughput for instances, see https://www.cisco.com/c/en/us/products/collateral/security/firewalls/white-paper-c11-744750.html.

Container Instances and High Availability

You can use High Availability using a container instance on 2 separate chassis; for example, if you have 2 chassis, each with 10 instances, you can create 10 High Availability pairs. Note that High Availability is not configured in FXOS; configure each High Availability pair in the application manager.

For detailed requirements, see Requirements and Prerequisites for High Availability and Add a High Availability Pair.

Licenses for Container Instances

All licenses are consumed per security engine/chassis (for the Firepower 4100) or per security module (for the Firepower 9300), and not per container instance. See the following details:

  • Essentials licenses are automatically assigned: one per security module/engine.

  • Feature licenses are manually assigned to each instance; but you only consume one license per feature per security module/engine. For example, for the Firepower 9300 with 3 security modules, you only need one URL Filtering license per module for a total of 3 licenses, regardless of the number of instances in use.

For example:

Table 6. Sample License Usage for Container Instances on a Firepower 9300

Firepower 9300

Instance

Licenses

Security Module 1

Instance 1

Essentials, URL Filtering, Malware Defense

Instance 2

Essentials, URL Filtering

Instance 3

Essentials, URL Filtering

Security Module 2

Instance 4

Essentials, IPS

Instance 5

Essentials, URL Filtering, Malware Defense, IPS

Security Module 3

Instance 6

Essentials, Malware Defense, IPS

Instance 7

Essentials, IPS
Table 7. Total Number of Licenses

Essentials

URL Filtering

Malware Defense

IPS

3

2

3

2

Requirements and Prerequisites for Logical Devices

See the following sections for requirements and prerequisites.

Requirements and Prerequisites for Hardware and Software Combinations

The Firepower 4100/9300 supports multiple models, security modules, application types, and high availability and scalability features. See the following requirements for allowed combinations.

Firepower 9300 Requirements

The Firepower 9300 includes 3 security module slots and multiple types of security modules. See the following requirements:

  • Security Module Types—You can install modules of different types in the Firepower 9300. For example, you can install the SM-48 as module 1, SM-40 as module 2, and SM-56 as module 3.

  • Native instance Clustering—All security modules in the cluster, whether it is intra-chassis or inter-chassis, must be the same type. 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. For example, you can install 2 SM-40s in chassis 1, and 3 SM-40s in chassis 2. You cannot use clustering if you install 1 SM-48 and 2 SM-40s in the same chassis.

  • Container instance Clustering—You can create a cluster using instances on different model types. For example, you can create a cluster using an instance on a Firepower 9300 SM-56, SM-48, and SM-40. You cannot mix the Firepower 9300 and the Firepower 4100 in the same cluster, however.

  • High Availability—High Availability is only supported between same-type modules on the Firepower 9300. However, the two chassis can include mixed modules. For example, each chassis has an SM-40, SM-48, and SM-56. You can create High Availability pairs between the SM-40 modules, between the SM-48 modules, and between the SM-56 modules.

  • ASA and threat defense application types—You can install different application types on separate modules in the chassis. For example, you can install ASA on module 1 and module 2, and threat defense on module 3.

  • ASA or threat defense versions—You can run different versions of an application instance type on separate modules, or as separate container instances on the same module. For example, you can install the threat defense 6.3 on module 1, threat defense 6.4 on module 2, and threat defense 6.5 on module 3.

Firepower 4100 Requirements

The Firepower 4100 comes in multiple models. See the following requirements:

  • Native and Container instances—When you install a container instance on a Firepower 4100, that device can only support other container instances. A native instance uses all of the resources for a device, so you can only install a single native instance on the device.

  • Native instance Clustering—All chassis in the cluster must be the same model.

  • Container instance Clustering—You can create a cluster using instances on different model types. For example, you can create a cluster using an instance on a Firepower 4145 and a 4125. You cannot mix the Firepower 9300 and the Firepower 4100 in the same cluster, however.

  • High Availability—High Availability is only supported between same-type models.

  • ASA and threat defense application types—The Firepower 4100 can only run a single application type.

  • The threat defense container instance versions—You can run different versions of threat defense as separate container instances on the same module.

Requirements and Prerequisites for Container Instances

For information about high-availability or clustering requirements with multi-instance, see Requirements and Prerequisites for High Availability and see Requirements and Prerequisites for Clustering.

Supported Application Types

  • The threat defense using management center

Maximum Container Instances and Resources per Model

For each container instance, you can specify the number of CPU cores to assign to the instance. RAM is dynamically allocated according to the number of cores, and disk space is set to 40 GB per instance.

Table 8. Maximum Container Instances and Resources per Model

Model

Max. Container Instances

Available CPU Cores

Available RAM

Available Disk Space

Firepower 4112

3

22

78 GB

308 GB

Firepower 4115

7

46

162 GB

308 GB

Firepower 4125

10

62

162 GB

644 GB

Firepower 4140

7

70

222 GB

311.8 GB

Firepower 4145

14

86

344 GB

608 GB

Firepower 9300 SM-40 security module

13

78

334 GB

1359 GB

Firepower 9300 SM-48 security module

15

94

334 GB

1341 GB

Firepower 9300 SM-56 security module

18

110

334 GB

1314 GB

Management Center Requirements

For all instances on a Firepower 4100 chassis or Firepower 9300 module, you must use the same management center due to the licensing implementation.

Requirements and Prerequisites for High Availability

  • The two units in a High Availability Failover configuration must:

    • Be on a separate chassis; intra-chassis High Availability for the Firepower 9300 is not supported.

    • Be the same model.

    • Have the same interfaces assigned to the High Availability logical devices.

    • Have the same number and types of interfaces. All interfaces must be preconfigured in FXOS identically before you enable High Availability.

  • High Availability is only supported between same-type modules on the Firepower 9300; but the two chassis can include mixed modules. For example, each chassis has an SM-56, SM-48, and SM-40. You can create High Availability pairs between the SM-56 modules, between the SM-48 modules, and between the SM-40 modules.

  • For container instances, each unit must use the same resource profile attributes.

  • For container instances: Do not use cascading instances (using a shared interface) with High Availability. After a failover occurs and the standby unit rejoins, MAC addresses can overlap temporarily and cause an outage. You should instead use unique interfaces for the gateway instance and inside instance using an external switch to pass traffic between the instances.

  • For other High Availability system requirements, see High Availability System Requirements.

Requirements and Prerequisites for Clustering

Cluster Model Support

The Threat Defense supports clustering on the following models:

  • Firepower 9300— You can include up to 16 nodes in the cluster. For example, you can use 1 module in 16 chassis, or 2 modules in 8 chassis, or any combination that provides a maximum of 16 modules. Supports clustering with multiple chassis and clustering isolated to security modules within one chassis.

  • Firepower 4100—Supported for up to 16 nodes using clustering with multiple chassis.

User Roles

  • Admin

  • Access Admin

  • Network Admin

Clustering Hardware and Software Requirements

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 threat defense, the management center must also use the same NTP server. Do not set the time manually.

Multi-Instance Clustering Requirements

  • 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.

Switch Requirements

  • 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.

Guidelines and Limitations for Logical Devices

See the following sections for guidelines and limitations.

Guidelines and Limitations for Interfaces

VLAN Subinterfaces

  • This document discusses FXOS VLAN subinterfaces only. You can separately create subinterfaces within the threat defense application. See FXOS Interfaces vs. Application Interfaces for more information.

  • Subinterfaces (and the parent interfaces) can only be assigned to container instances.


    Note

    If you assign a parent interface to a container instance, it only passes untagged (non-VLAN) traffic. Do not assign the parent interface unless you intend to pass untagged traffic. For Cluster type interfaces, the parent interface cannot be used.

  • Subinterfaces are supported on Data or Data-sharing type interfaces, as well as Cluster type interfaces. If you add subinterfaces to a Cluster interface, you cannot use that interface for a native cluster.

  • For multi-instance clustering, FXOS subinterfaces are not supported on Data interfaces. However, subinterfaces are supported for the cluster control link, so you can use either a dedicated EtherChannel or a subinterface of an EtherChannel for the cluster control link. Note that application-defined subinterfaces are supported for Data interfaces.

  • You can create up to 500 VLAN IDs.

  • See the following limitations within the logical device application; keep these limitations in mind when planning your interface allocation.

    • You cannot use subinterfaces for an threat defense inline set or as a passive interface.

    • If you use a subinterface for the failover link, then all subinterfaces on that parent, and the parent itself, are restricted for use as failover links. You cannot use some subinterfaces as failover links, and some as regular data interfaces.

Data-sharing Interfaces

  • You cannot use a data-sharing interface with a native instance.

  • Maximum 14 instances per shared interface. For example, you can allocate Ethernet1/1 to Instance1 through Instance14.

    Maximum 10 shared interfaces per instance. For example, you can allocate Ethernet1/1.1 through Ethernet1/1.10 to Instance1.

  • You cannot use a data-sharing interface in a cluster.

  • See the following limitations within the logical device application; keep these limitations in mind when planning your interface allocation.

    • You cannot use a data-sharing interface with a transparent firewall mode device.

    • You cannot use a data-sharing interface with threat defense inline sets or passive interfaces.

    • You cannot use a data-sharing interface for the failover link.

Inline Sets for Threat Defense

  • Supported for physical interfaces (both regular and breakout ports) and EtherChannels. Subinterfaces are not supported.

  • Link state propagation is supported.

  • Do not enable Hardware Bypass and link state propagation for the same inline set.

Hardware Bypass

  • Supported for the threat defense; you can use them as regular interfaces for the ASA.

  • The threat defense only supports Hardware Bypass with inline sets.

  • Hardware Bypass-capable interfaces cannot be configured for breakout ports.

  • You cannot include Hardware Bypass interfaces in an EtherChannel and use them for Hardware Bypass; you can use them as regular interfaces in an EtherChannel.

  • Hardware Bypass is not supported with High Availability.

  • Do not enable Hardware Bypass and link state propagation for the same inline set.

Default MAC Addresses

For native instances:

Default MAC address assignments depend on the type of interface.

  • Physical interfaces—The physical interface uses the burned-in MAC address.

  • EtherChannels—For an EtherChannel, all interfaces that are part of the channel group share the same MAC address. This feature makes the EtherChannel transparent to network applications and users, because they only see the one logical connection; they have no knowledge of the individual links. The port-channel interface uses a unique MAC address from a pool; interface membership does not affect the MAC address.

For container instances:

  • MAC addresses for all interfaces are taken from a MAC address pool. For subinterfaces, if you decide to manually configure MAC addresses, make sure you use unique MAC addresses for all subinterfaces on the same parent interface to ensure proper classification. See Automatic MAC Addresses for Container Instance Interfaces.

General Guidelines and Limitations

Firewall Mode

You can set the firewall mode to routed or transparent in the bootstrap configuration for the threat defense.

High Availability

  • Configure high availability within the application configuration.

  • You can use any data interfaces as the failover and state links. Data-sharing interfaces are not supported.

Multi-Instance

  • Multi-instance capability with container instances is only available for the threat defense using management center.

  • For threat defense container instances, a single management center must manage all instances on a security module/engine.

  • For threat defense container instances, the following features are not supported:

    • Radware DefensePro link decorator

    • Management Center UCAPL/CC mode

    • Flow offload to hardware

Configure Interfaces

By default, physical interfaces are disabled. You can enable interfaces, add EtherChannels, add VLAN subinterfaces, and edit interface properties.

Enable or Disable an Interface

You can change the Admin State of each interface to be enabled or disabled. By default, physical interfaces are disabled. For VLAN subinterfaces, the admin state is inherited from the parent interface.

Procedure

Step 1

Choose Interfaces to open the Interfaces page.

The Interfaces page shows a visual representation of the currently installed interfaces at the top of the page and provides a listing of the installed interfaces in the table below.

Step 2

To enable the interface, click the disabled Slider disabled (slider disabled) so that it changes to the enabled Slider enabled (slider enabled).

Click Yes to confirm the change. The corresponding interface in the visual representation changes from gray to green.

Step 3

To disable the interface, click the enabled Slider enabled (slider enabled) so that it changes to the disabled Slider disabled (slider disabled).

Click Yes to confirm the change. The corresponding interface in the visual representation changes from green to gray.

Configure a Physical Interface

You can physically enable and disable interfaces, as well as set the interface speed and duplex. To use an interface, it must be physically enabled in FXOS and logically enabled in the application.


Note

For QSFPH40G-CUxM, auto-negotiation is always enabled by default and you cannot disable it.

Before you begin

  • Interfaces that are already a member of an EtherChannel cannot be modified individually. Be sure to configure settings before you add it to the EtherChannel.

Procedure

Step 1

Choose Interfaces to open the Interfaces page.

The All Interfaces page shows a visual representation of the currently installed interfaces at the top of the page and provides a listing of the installed interfaces in the table below.

Step 2

Click Edit in the row for the interface you want to edit to open the Edit Interface dialog box.

Step 3

To enable the interface, check the Enable check box. To disable the interface, uncheck the Enable check box.

Step 4

Choose the interface Type:

See Interface Types for details about interface type usage.

  • Data

  • Data-sharing—For container instances only.

  • Mgmt

  • Firepower-eventing—For threat defense only.

  • Cluster—Do not choose the Cluster type; by default, the cluster control link is automatically created on Port-channel 48.

Step 5

(Optional) Choose the speed of the interface from the Speed drop-down list.

Step 6

(Optional) If your interface supports Auto Negotiation, click the Yes or No radio button.

Step 7

(Optional) Choose the duplex of the interface from the Duplex drop-down list.

Step 8

(Optional) Explicitly configure Debounce Time (ms). Enter a value between 0-15000 milli-seconds.

Step 9

Click OK.

Add an EtherChannel (Port Channel)

An EtherChannel (also known as a port channel) can include up to 16 member interfaces of the same media type and capacity, and must be set to the same speed and duplex. The media type can be either RJ-45 or SFP; SFPs of different types (copper and fiber) can be mixed. You cannot mix interface capacities (for example 1GB and 10GB interfaces) by setting the speed to be lower on the larger-capacity interface. The Link Aggregation Control Protocol (LACP) aggregates interfaces by exchanging the Link Aggregation Control Protocol Data Units (LACPDUs) between two network devices.

You can configure each physical Data or Data-sharing interface in an EtherChannel to be:

  • Active—Sends and receives LACP updates. An active EtherChannel can establish connectivity with either an active or a passive EtherChannel. You should use the active mode unless you need to minimize the amount of LACP traffic.

  • On—The EtherChannel is always on, and LACP is not used. An “on” EtherChannel can only establish a connection with another “on” EtherChannel.


Note

It may take up to three minutes for an EtherChannel to come up to an operational state if you change its mode from On to Active or from Active to On.

Non-data interfaces only support active mode.

LACP coordinates the automatic addition and deletion of links to the EtherChannel without user intervention. It also handles misconfigurations and checks that both ends of member interfaces are connected to the correct channel group. “On” mode cannot use standby interfaces in the channel group when an interface goes down, and the connectivity and configurations are not checked.

When the Firepower 4100/9300 chassis creates an EtherChannel, the EtherChannel stays in a Suspended state for Active LACP mode or a Down state for On LACP mode until you assign it to a logical device, even if the physical link is up. The EtherChannel will be brought out of this Suspended state in the following situations:

  • The EtherChannel is added as a data or management interface for a standalone logical device

  • The EtherChannel is added as a management interface or cluster control link for a logical device that is part of a cluster

  • The EtherChannel is added as a data interface for a logical device that is part of a cluster and at least one unit has joined the cluster

Note that the EtherChannel does not come up until you assign it to a logical device. If the EtherChannel is removed from the logical device or the logical device is deleted, the EtherChannel will revert to a Suspended or Down state.

Procedure

Step 1

Choose Interfaces to open the Interfaces page.

The All Interfaces page shows a visual representation of the currently installed interfaces at the top of the page and provides a listing of the installed interfaces in the table below.

Step 2

Click Add Port Channel above the interfaces table to open the Add Port Channel dialog box.

Step 3

Enter an ID for the port channel in the Port Channel ID field. Valid values are between 1 and 47.

Port-channel 48 is reserved for the cluster control link when you deploy a clustered logical device. If you do not want to use Port-channel 48 for the cluster control link, you can delete it and configure a Cluster type EtherChannel with a different ID.You can add multiple Cluster type EtherChannels and add VLAN subinterfaces for use with multi-instance clustering. For intra-chassis clustering, do not assign any interfaces to the Cluster EtherChannel.

Step 4

To enable the port channel, check the Enable check box. To disable the port channel, uncheck the Enable check box.

Step 5

Choose the interface Type:

See Interface Types for details about interface type usage.

  • Data

  • Data-sharing—For container instances only.

  • Mgmt

  • Firepower-eventing—For threat defense only.

  • Cluster

Step 6

Set the required Admin Speed for the member interfaces from the drop-down list.

If you add a member interface that is not at the specified speed, it will not successfully join the port channel.

Step 7

For Data or Data-sharing interfaces, choose the LACP port-channel Mode, Active or On.

For non-Data or non-Data-sharing interfaces, the mode is always active.

Step 8

Set the required Admin Duplex for the member interfaces, Full Duplex or Half Duplex.

If you add a member interface that is configured with the specified duplex, it will not successfully join the port channel.

Step 9

To add an interface to the port channel, select the interface in the Available Interface list and click Add Interface to move the interface to the Member ID list.

You can add up to 16 member interfaces of the same media type and capacity. The member interfaces must be set to the same speed and duplex, and must match the speed and duplex that you configured for this port channel. The media type can be either RJ-45 or SFP; SFPs of different types (copper and fiber) can be mixed. You cannot mix interface capacities (for example 1GB and 10GB interfaces) by setting the speed to be lower on the larger-capacity interface.

Tip

 

You can add multiple interfaces at one time. To select multiple individual interfaces, click on the desired interfaces while holding down the Ctrl key. To select a range of interfaces, select the first interface in the range, and then, while holding down the Shift key, click to select the last interface in the range.

Step 10

To remove an interface from the port channel, click the Delete button to the right of the interface in the Member ID list.

Step 11

Click OK.

Add a VLAN Subinterface for Container Instances

You can add between 250 and 500 VLAN subinterfaces to the chassis, depending on your network deployment. You can add up to 500 subinterfaces to your chassis.

For multi-instance clustering, you can only add subinterfaces to the Cluster-type interface; subinterfaces on data interfaces are not supported.

VLAN IDs per interface must be unique, and within a container instance, VLAN IDs must be unique across all assigned interfaces. You can reuse VLAN IDs on separate interfaces as long as they are assigned to different container instances. However, each subinterface still counts towards the limit even though it uses the same ID.

This document discusses FXOS VLAN subinterfaces only. You can separately create subinterfaces within the threat defense application. For more information on when to use FXOS subinterfaces vs. application subinterfaces, see FXOS Interfaces vs. Application Interfaces.

Procedure

Step 1

Choose Interfaces to open the All Interfaces tab.

The All Interfaces tab shows a visual representation of the currently installed interfaces at the top of the page and provides a listing of the installed interfaces in the table below.

Step 2

Click Add New > Subinterface to open the Add Subinterface dialog box.

Step 3

Choose the interface Type:

See Interface Types for details about interface type usage.

  • Data

  • Data-sharing

  • Cluster—If you add subinterfaces to a Cluster interface, you cannot use that interface for a native cluster.

For Data and Data-sharing interfaces: The type is independent of the parent interface type; you can have a Data-sharing parent and a Data subinterface, for example.

Step 4

Choose the parent Interface from the drop-down list.

You cannot add a subinterface to a physical interface that is currently allocated to a logical device. If other subinterfaces of the parent are allocated, you can add a new subinterface as long as the parent interface itself is not allocated.

Step 5

Enter a Subinterface ID, between 1 and 4294967295.

This ID will be appended to the parent interface ID as interface_id.subinterface_id. For example, if you add a subinterface to Ethernet1/1 with the ID of 100, then the subinterface ID will be: Ethernet1/1.100. This ID is not the same as the VLAN ID, although you can set them to match for convenience.

Step 6

Set the VLAN ID between 1 and 4095.

Step 7

Click OK.

Expand the parent interface to view all subinterfaces under it.

Configure Logical Devices

Add a standalone logical device or a High Availability pair on the Firepower 4100/9300.

For clustering, see Clustering for the Firepower 4100/9300.

Add a Resource Profile for Container Instances

To specify resource usage per container instance, create one or more resource profiles. When you deploy the logical device/application instance, you specify the resource profile that you want to use. The resource profile sets the number of CPU cores; RAM is dynamically allocated according to the number of cores, and disk space is set to 40 GB per instance.

  • The minimum number of cores is 6.


    Note

    Instances with a smaller number of cores might experience relatively higher CPU utilization than those with larger numbers of cores. Instances with a smaller number of cores are more sensitive to traffic load changes. If you experience traffic drops, try assigning more cores.

  • You can assign cores as an even number (6, 8, 10, 12, 14 etc.) up to the maximum.

  • The maximum number of cores available depends on the security module/chassis model; see Requirements and Prerequisites for Container Instances.

The chassis includes a default resource profile called "Default-Small," which includes the minimum number of cores. You can change the definition of this profile, and even delete it if it is not in use. Note that this profile is created when the chassis reloads and no other profile exists on the system.

Changing the resource profile after you assign it is disruptive. See the following guidelines:

  • You cannot change the resource profile settings if it is currently in use. You must disable any instances that use it, then change the resource profile, and finally reenable the instance.

  • If you change the resource profile settings after you add the threat defense instance to the management center, then update the inventory for each unit on the management center Devices > Device Management > Device > System > Inventory dialog box.

  • If you assign a different profile to an instance, it reboots.

  • If you assign a different profile to instances in an established high-availability pair, which requires the profile to be the same on both units, you must:

    1. Break high availability.

    2. Assign the new profile to both units.

    3. Re-establish high availability.

  • 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 all come back up, you can apply the new profile to the control node.

Procedure

Step 1

Choose Platform Settings > Resource Profiles , and click Add.

The Add Resource Profile dialog box appears.

Step 2

Set the following paramters.

  • Name—Sets the name of the profile between 1 and 64 characters. Note that you cannot change the name of this profile after you add it.

  • Description—Sets the description of the profile up to 510 characters.

  • Number of Cores—Sets the number of cores for the profile, between 6 and the maximum, depending on your chassis, as an even number.

Step 3

Click OK.

Add a Standalone Threat Defense

Standalone logical devices work either alone or in a High Availability pair. On the Firepower 9300 with multiple security modules, you can deploy either a cluster or standalone devices. The cluster must use all modules, so you cannot mix and match a 2-module cluster plus a single standalone device, for example.

You can use native instances on some modules, and container instances on the other module(s).

Before you begin

  • 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.


    Note

    For the Firepower 9300, you can install different application types (ASA and threat defense) on separate modules in the chassis. You can also run different versions of an application instance type on separate modules.

  • Configure a management interface to use with the logical device. The management interface is required. Note that this management interface is not the same as the chassis management port that is used only for chassis management (and that appears at the top of the Interfaces tab as MGMT).

  • You can later enable management from a data interface; but you must assign a Management interface to the logical device even if you don't intend to use it after you enable data management. See the configure network management-data-interface command in the FTD command reference for more information.

  • You must also configure at least one Data type interface. Optionally, you can also create a firepower-eventing interface to carry all event traffic (such as web events). See Interface Types for more information.

  • 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:

    • Interface IDs for this device

    • Management interface IP address and network mask

    • Gateway IP address

    • management center IP address and/or NAT ID of your choosing

    • DNS server IP address

    • threat defense hostname and domain name

Procedure

Step 1

Choose Logical Devices.

Step 2

Click Add > Standalone, and set the following parameters:

  1. Provide a Device Name.

    This name is used by the chassis supervisor to configure management settings and to assign interfaces; it is not the device name used in the application configuration.

    Note

     

    You cannot change this name after you add the logical device.

  2. For the Template, choose Cisco Firepower Threat Defense.

  3. Choose the Image Version.

  4. Choose the Instance Type: Container or Native.

    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.

  5. Click OK.

    You see the Provisioning - device name window.

Step 3

Expand the Data Ports area, and click each interface that you want to assign to the device.

You can only assign data and data-sharing interfaces that you previously enabled on the Interfaces page. You will later enable and configure these interfaces in management center, including setting the IP addresses.

You can only assign up to 10 data-sharing interfaces to a container instance. Also, each data-sharing interface can be assigned to at most 14 container instances. A data-sharing interface is indicated by the sharing icon (sharing icon).

Hardware Bypass-capable ports are shown with the following icon: . For certain interface modules, you can enable the Hardware Bypass feature for Inline Set interfaces only (see the management center configuration guide). Hardware Bypass ensures that traffic continues to flow between an inline interface pair during a power outage. This feature can be used to maintain network connectivity in the case of software or hardware failures. If you do not assign both interfaces in a Hardware Bypass pair, you see a warning message to make sure your assignment is intentional. You do not need to use the Hardware Bypass feature, so you can assign single interfaces if you prefer.

Step 4

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.

Step 5

On the General Information page, complete the following:

  1. (For the Firepower 9300) Under Security Module Selection click the security module that you want to use for this logical device.

  2. For a container instance, specify the Resource Profile.

    If you later assign a different resource profile, then the instance will reload, which can take approximately 5 minutes.

    Note

     

    If you later assign a different profile to instances in an established high-availability pair, which requires the profile to be the same on both units, you must:

    1. Break high availability.

    2. Assign the new profile to both units.

    3. Re-establish high availability.

  3. Choose the Management Interface.

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

  4. Choose the management interface Address Type: IPv4 only, IPv6 only, or IPv4 and IPv6.

  5. Configure the Management IP address.

    Set a unique IP address for this interface.

  6. Enter a Network Mask or Prefix Length.

  7. Enter a Network Gateway address.

Step 6

On the Settings tab, complete the following:

  1. For a native instance, in the Management type of application instance drop-down list, choose FMC.

    Native instances also support device manager as a manager. After you deploy the logical device, you cannot change the manager type.

  2. Enter the Firepower Management Center IP of the managing management center. If you do not know the management center IP address, leave this field blank and enter a passphrase in the Firepower Management Center NAT ID field.

  3. For a container instance, Permit Expert mode from FTD SSH sessions: Yes or No. Expert Mode provides 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 threat defense CLI.

  4. Enter the Search Domains as a comma-separated list.

  5. Choose the Firewall Mode: Transparent or Routed.

    In routed mode, the 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.

  6. Enter the DNS Servers as a comma-separated list.

    The threat defense uses DNS if you specify a hostname for the management center, for example.

  7. Enter the Fully Qualified Hostname for the threat defense.

  8. Enter a Registration Key to be shared between the management center and the device during registration.

    You can choose any text string for this key between 1 and 37 characters; you will enter the same key on the management center when you add the threat defense.

  9. Enter a Password for the threat defense admin user for CLI access.

  10. Choose the Eventing Interface on which events should be sent. If not specified, the management interface will be used.

    This interface must be defined as a Firepower-eventing interface.

  11. For a container instance, set the Hardware Crypto as Enabled or Disabled.

    This setting enables TLS crypto acceleration in hardware, and improves performance for certain types of traffic. This feature is enabled by default. You can enable TLS crypto acceleration for up to 16 instances per security module. This feature is always enabled for native instances. To view the percentage of hardware crypto resources allocated to this instance, enter the show hw-crypto command.

Step 7

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

Step 8

Click OK to close the configuration dialog box.

Step 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 the status of the new logical device. When the logical device shows its Status as online, you can start configuring the security policy in the application.

Step 10

See the management center configuration guide to add the threat defense as a managed device and start configuring your security policy.

Add a High Availability Pair

Threat Defense High Availability (also known as failover) is configured within the application, not in FXOS. However, to prepare your chassis for high availability, see the following steps.

Before you begin

See Requirements and Prerequisites for High Availability.

Procedure

Step 1

Allocate the same interfaces to each logical device.

Step 2

Allocate 1 or 2 data interfaces for the failover and state link(s).

These interfaces exchange high availability traffic between the 2 chassis. We recommend that you use a 10 GB data interface for a combined failover and state link. If you have available interfaces, you can use separate failover and state links; the state link requires the most bandwidth. You cannot use the management-type interface for the failover or state link. We recommend that you use a switch between the chassis, with no other device on the same network segment as the failover interfaces.

For container instances, data-sharing interfaces are not supported for the failover link. We recommend that you create subinterfaces on a parent interface or EtherChannel, and assign a subinterface for each instance to use as a failover link. Note that you must use all subinterfaces on the same parent as failover links. You cannot use one subinterface as a failover link and then use other subinterfaces (or the parent interface) as regular data interfaces.

Step 3

Enable High Availability on the logical devices. See High Availability.

Step 4

If you need to make interface changes after you enable High Availability, perform the changes on the standby unit first, and then perform the changes on the active unit.

Change an Interface on a Threat Defense Logical Device

You can allocate or unallocate an interface, or replace a management interface on the threat defense logical device. You can then sync the interface configuration in the management centerthe .

Adding a new interface, or deleting an unused interface has minimal impact on the threat defense configuration. However, deleting an interface that is used in your security policy will impact the configuration. Interfaces can be referenced directly in many places in the threat defense configuration, including access rules, NAT, SSL, identity rules, VPN, DHCP server, and so on. Policies that refer to security zones are not affected. You can also edit the membership of an allocated EtherChannel without affecting the logical device or requiring a sync on the management centerthe .

Deleting an interface will delete any configuration associated with that interface.

Before you begin

  • Configure your interfaces, and add any EtherChannels according to Configure a Physical Interface and Add an EtherChannel (Port Channel).

  • If you want to add an already-allocated interface to an EtherChannel (for example, all interfaces are allocated by default to a cluster), you need to unallocate the interface from the logical device first, then add the interface to the EtherChannel. For a new EtherChannel, you can then allocate the EtherChannel to the device.

  • If you want to replace the management or eventing interface with a management EtherChannel, then you need to create the EtherChannel with at least 1 unallocated data member interface, and then replace the current management interface with the EtherChannel. After the threat defense device reboots (management interface changes cause a reboot), and you sync the configuration in the management centerthe , you can add the (now unallocated) management interface to the EtherChannel as well.

  • For clustering or High Availability, make sure you add or remove the interface on all units before you sync the configuration in the management centerthe . We recommend that you make the interface changes on the data/standby unit(s) first, and then on the control/active unit. Note that new interfaces are added in an administratively down state, so they do not affect interface monitoring.

  • In mult-instance mode, for changing a sub-interface with an another sub-interface with the same vlan tag, you must first remove all the configuration (including nameif config) of the interface and then unalloacte the interface from chassis manager. Once unallocated, add the new interface and then use sync interfaces from the management center.

Procedure

Step 1

In the chassis manager, choose Logical Devices.

Step 2

Click the Edit icon at the top right to edit the logical device.

Step 3

Allocate a new data interface by selecting the interface in the Data Ports area.

Do not delete any interfaces yet.

Step 4

Replace the management or eventing interface:

For these types of interfaces, the device reboots after you save your changes.

  1. Click the device icon in the center of the page.

  2. On the General or Cluster Information tab, choose the new Management Interface from the drop-down list.

  3. On the Settings tab, choose the new Eventing Interface from the drop-down list.

  4. Click OK.

If you change the IP address of the Management interface, then you must also change the IP address for the device in the management center: go to Devices > Device Management > Device/Cluster. In the Management area, set the IP address to match the bootstrap configuration address.

Step 5

Click Save.

Step 6

Sync the interfaces in the management center.

  1. Log into the management center.

  2. Select Devices > Device Management and click Edit (edit icon) for your threat defense device. The Interfaces page is selected by default.

  3. Click the Sync Device button on the top left of the Interfaces page.

  4. After the changes are detected, you will see a red banner on the Interfaces page indicating that the interface configuration has changed. Click the Click to know more link to view the interface changes.

  5. If you plan to delete an interface, manually transfer any interface configuration from the old interface to the new interface.

    Because you have not yet deleted any interfaces, you can refer to the existing configuration. You will have additional opportunity to fix the configuration after you delete the old interface and re-run the validation. The validation will show you all locations in which the old interface is still used.

  6. Click Validate Changes to make sure your policy will still work with the interface changes.

    If there are any errors, you need to change your policy and rerun the validation.

  7. Click Save.

  8. Click Deploy > Deployment.

  9. Select the devices and click Deploy to deploy the policy to the assigned devices. The changes are not active until you deploy them.

Step 7

In the chassis manager, unallocate a data interface by de-selecting the interface in the Data Ports area.

Step 8

Click Save.

Step 9

Sync the interfaces again in the management centerthe .

Connect to the Console of the Application

Use the following procedure to connect to the console of the application.

Procedure

Step 1

Connect to the module CLI using a console connection or a Telnet connection.

connect module slot_number { console | telnet}

To connect to the security engine of a device that does not support multiple security modules, always use 1 as the slot_number .

The benefits of using a Telnet connection is that you can have multiple sessions to the module at the same time, and the connection speed is faster.

Example:


Firepower# connect module 1 console
Telnet escape character is '~'.
Trying 127.5.1.1...
Connected to 127.5.1.1.
Escape character is '~'.

CISCO Serial Over LAN:
Close Network Connection to Exit

Firepower-module1>

Step 2

Connect to the application console.

connect ftd name

To view the instance names, enter the command without a name.

Example:


Firepower-module1> connect ftd ftd1
Connecting to ftd(ftd-native) console... enter exit to return to bootCLI
[...]
>

Step 3

Exit the application console to the FXOS module CLI.

  • Threat Defense—Enter exit

Step 4

Return to the supervisor level of the FXOS CLI.

Exit the console:

  1. Enter ~

    You exit to the Telnet application.

  2. To exit the Telnet application, enter:

    telnet>quit

Exit the Telnet session:

  1. Enter Ctrl-], .

History for Logical Devices

Feature

Minimum Management Center

Minimum Threat Defense

Details

Synchronization between the threat defense operational link state and the physical link state

6.7

Any

The chassis can now synchronize the threat defense operational link state with the physical link state for data interfaces. Currently, interfaces will be in an Up state as long as the FXOS admin state is up and the physical link state is up. The threat defense application interface admin state is not considered. Without synchronization from threat defense, data interfaces can be in an Up state physically before the threat defense application has completely come online, for example, or can stay Up for a period of time after you initiate threat defense shutdown. For inline sets, this state mismatch can result in dropped packets because external routers may start sending traffic to the threat defense before the threat defense can handle it. This feature is disabled by default, and can be enabled per logical device in FXOS.

Note

 

This feature is not supported for clustering, container instances, or threat defense with a Radware vDP decorator. It is also not supported for the ASA.

New/Modified Firepower Chassis Manager screens: Logical Devices > Enable Link State

New/Modified FXOS commands: set link-state-sync enabled, show interface expand detail

Threat Defense configuration backup and restore using management center for container instances

6.7

Any

You can now use the management center backup/restore tool on threat defense container instances.

New/Modified management center screens: System > Tools > Backup/Restore > Managed Device Backup

New/Modified threat defense CLI commands: restore

Supported platforms: Firepower 4100/9300

Note

 

Requires FXOS 2.9.

Support for VLAN subinterfaces on a Cluster type interface (multi-instance use only)

6.6

Any

For use with multi-instance clusters, you can now create VLAN subinterfaces on cluster type interfaces. Because each cluster requires a unique cluster control link, VLAN subinterfaces provide a simple method to fulfill this requirement. You can alternatively assign a dedicated EtherChannel per cluster. Multiple cluster interfaces are now allowed.

New/Modified Firepower Chassis Manager screens:

Interfaces > All Interfaces > Add New drop-down menu > Subinterface > Type field

New/Modified FXOS commands: set port-type cluster

Note

 

Requires FXOS 2.8.1.

Threat Defense on the Firepower 4112

6.6

Any

We introduced the Firepower 4112.

Note

 

Requires FXOS 2.8.1.

TLS crypto acceleration for multiple container instances

6.5

Any

TLS crypto acceleration is now supported on multiple container instances (up to 16) on a Firepower 4100/9300 chassis. Previously, you could enable TLS crypto acceleration for only one container instance per module/security engine.

New instances have this feature enabled by default. However, the upgrade does not enable acceleration on existing instances. Instead, use the enter hw-crypto and then the set admin-state enabled FXOS commands.

New/Modified Firepower Chassis Manager screens:

Logical Devices > Add Device > Settings > Hardware Crypto drop-down menu

Note

 

Requires FXOS 2.7.1.

Threat Defense on the Firepower 4115, 4125, and 4145

6.4

Any

We introduced the Firepower 4115, 4125, and 4145.

Note

 

Requires FXOS 2.6.1.157.

Firepower 9300 SM-40, SM-48, and SM-56 support

 6.4

Any

We introduced the following three security modules: SM-40, SM-48, and SM-56.

Note

 

Requires FXOS 2.6.1.157.

Support for ASA and threat defense on separate modules of the same Firepower 9300

6.4

Any

You can now deploy ASA and threat defense logical devices on the same Firepower 9300.

Note

 

Requires FXOS 2.6.1.157.

Support for SSL hardware acceleration on one threat defense container instance on a module/security engine

6.4

Any

You can now enable SSL hardware acceleration for one container instance on a module/security engine. SSL hardware acceleration is disabled for other container instances, but enabled for native instances.

New/Modified FXOS commands: config hwCrypto enable

No modified screens.

Note

 

Requires FXOS 2.6.1.157.

Multi-instance capability for threat defense on the Firepower 4100/9300

6.3

Any

You can now deploy multiple logical devices, each with a threat defense container instance, on a single security engine/module. Formerly, you could only deploy a single native application instance.

To provide flexible physical interface use, you can create VLAN subinterfaces in FXOS and also share interfaces between multiple instances. Resource management lets you customize performance capabilities for each instance.

You can use High Availability using a container instance on 2 separate chassis. Clustering is not supported.

Note

 

Multi-instance capability is similar to ASA multiple context mode, although the implementation is different. Multiple context mode is not available on the threat defense.

New/Modified management center screens:

  • Devices > Device Management > Edit icon > Interfaces tab

New/Modified Firepower Chassis Manager screens:

  • Overview > Devices

  • Interfaces > All Interfaces > Add New drop-down menu > Subinterface

  • Interfaces > All Interfaces > Type

  • Logical Devices > Add Device

  • Platform Settings > Mac Pool

  • Platform Settings > Resource Profiles

New/Modified FXOS commands: connect ftd name, connect module telnet, create bootstrap-key PERMIT_EXPERT_MODE, create resource-profile, create subinterface, scope auto-macpool, set cpu-core-count, set deploy-type, set port-type data-sharing, set prefix, set resource-profile-name, set vlan, scope app-instance ftd name, show cgroups container, show interface, show mac-address, show subinterface, show tech-support module app-instance, show version

Supported platforms: Firepower 4100/9300

Cluster control link customizable IP Address for the Firepower 4100/9300

6.3

Any

By default, the cluster control link uses the 127.2.0.0/16 network. You can now set the network when you deploy the cluster in FXOS. The 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. However, some networking deployments do not allow 127.2.0.0/16 traffic to pass. Therefore, you can now set a custom /16 subnet for the cluster control link in FXOS except for loopback (127.0.0.0/8) and multicast (224.0.0.0/4) addresses.

New/modified Firepower Chassis Manager screens:

  • Logical Devices > Add Device > Cluster Information > CCL Subnet IP field

New/Modified FXOS commands: set cluster-control-link network

Supported platforms: Firepower 4100/9300

Support for data EtherChannels in On mode

6.3

Any

You can now set data and data-sharing EtherChannels to either Active LACP mode or to On mode. Other types of EtherChannels only support Active mode.

New/Modified Firepower Chassis Manager screens:

  • Interfaces > All Interfaces > Edit Port Channel > Mode

New/Modified FXOS commands: set port-channel-mode

Supported platforms: Firepower 4100/9300

Support for EtherChannels in threat defense inline sets

6.2

Any

You can now use EtherChannels in a threat defense inline set.

Supported platforms: Firepower 4100/9300

Inter-chassis clustering for 6 threat defense modules

6.2

Any

You can now enable inter-chassis clustering for the threat defense. You can include up to 6 modules in up to 6 chassis.

New/modified Firepower Chassis Manager screens:

  • Logical Devices > Configuration

Supported platforms: Firepower 4100/9300

Hardware bypass support on the Firepower 4100/9300 for supported network modules

6.1

Any

Hardware Bypass ensures that traffic continues to flow between an inline interface pair during a power outage. This feature can be used to maintain network connectivity in the case of software or hardware failures.

New/Modified screens:

  • Devices > Device Management > Interfaces > Edit Physical Interface

Supported platforms: Firepower 4100/9300

Inline set link state propagation support for the threat defense

6.1

Any

When you configure an inline set in the threat defense application and enable link state propagation, the threat defense sends inline set membership to the FXOS chassis. Link state propagation means that the chassis automatically brings down the second interface in the inline interface pair when one of the interfaces in an inline set goes down.

New/Modified FXOS commands: show fault |grep link-down, show interface detail

Supported platforms: Firepower 4100/9300

Support for intra-chassis clustering on the threat defense on the Firepower 9300

6.0.1

Any

The Firepower 9300 supports intra-chassis clustering with the threat defense application.

New/Modified Firepower Chassis Manager screens:

  • Logical Devices > Configuration

New/Modified FXOS commands: enter mgmt-bootstrap ftd, enter bootstrap-key FIREPOWER_MANAGER_IP, enter bootstrap-key FIREWALL_MODE, enter bootstrap-key-secret REGISTRATION_KEY, enter bootstrap-key-secret PASSWORD, enter bootstrap-key FQDN, enter bootstrap-key DNS_SERVERS, enter bootstrap-key SEARCH_DOMAINS, enter ipv4 firepower, enter ipv6 firepower, set value, set gateway, set ip, accept-license-agreement

Supported platforms: Firepower 4100/9300