About Firepower 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 Firepower Chassis Manager. 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. See also Changing the Management IP Address. 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.
Interface Types
Each interface 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 (FTD 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, 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. For ASA: 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.
-
Firepower-eventing—Use as a secondary management interface for FTD devices. To use this interface, you must configure its IP address and other parameters at the FTD CLI. For example, you can separate management traffic from events (such as web events). See the FMC configuration guide for more information. Firepower-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.
-
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.
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 only, you can also create VLAN subinterfaces in FXOS (on interfaces without FXOS subinterfaces). 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:
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.
Hardware Bypass Pairs
For the FTD, certain interface modules on the Firepower 9300 and 4100 series let you enable the Hardware Bypass feature. 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.
The Hardware Bypass feature is configured within the FTD application. You do not need to use these interfaces as Hardware Bypass pairs; they can be used as regular interfaces for both the ASA and the FTD applications. Note that Hardware Bypass-capable interfaces cannot be configured for breakout ports. If you want to use the Hardware Bypass feature, do not configure the ports as EtherChannels; otherwise, you can include these interfaces as EtherChannel members in regular interface mode.
When Hardware Bypass is enabled on an inline pair, switch bypass is attempted first. If the bypass configuration fails due a switch error, physical bypass is enabled.
The FTD supports Hardware Bypass for interface pairs on specific network modules on the following models:
-
Firepower 9300
-
Firepower 4100 series
The supported Hardware Bypass network modules for these models include:
-
Firepower 6-port 1G SX FTW Network Module single-wide (FPR-NM-6X1SX-F)
-
Firepower 6-port 10G SR FTW Network Module single-wide (FPR-NM-6X10SR-F)
-
Firepower 6-port 10G LR FTW Network Module single-wide (FPR-NM-6X10LR-F)
-
Firepower 2-port 40G SR FTW Network Module single-wide (FPR-NM-2X40G-F)
-
Firepower 8-port 1G Copper FTW Network Module single-wide (FPR-NM-8X1G-F)
Hardware Bypass can only use the following port pairs:
-
1 & 2
-
3 & 4
-
5 & 6
-
7 & 8
Jumbo Frame Support
The Firepower 4100/9300 chassis has support for jumbo frames enabled by default. To enable jumbo frame support on a specific logical device installed on the Firepower 4100/9300 chassis, you will need to configure the appropriate MTU settings for the interfaces on the logical device.
The maximum MTU that is supported for the application on the Firepower 4100/9300 chassis is 9184.
Shared Interface Scalability
Container 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. Depending on the number of parent interfaces and other deployment decisions, 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:
-
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.
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).
-
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.
-
Worst—Share individual parent interfaces (physical or EtherChannel).
This method uses the most forwarding table entries.
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.
Dedicated Interfaces |
Shared Interfaces |
Number of Instances |
% Forwarding Table Used |
---|---|---|---|
32:
|
0 |
4:
|
16% |
30:
|
0 |
2:
|
14% |
14:
|
1 |
14:
|
46% |
33:
|
3:
|
33:
|
98% |
33:
|
3:
|
34:
|
102% DISALLOWED |
30:
|
1 |
6:
|
25% |
30:
|
3:
|
6:
|
23% |
30:
|
2 |
5:
|
28% |
30:
|
4:
|
5:
|
26% |
24:
|
7 |
4:
|
44% |
24:
|
14:
|
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.
Dedicated Subinterfaces |
Shared Subinterfaces |
Number of Instances |
% Forwarding Table Used |
---|---|---|---|
168:
|
0 |
42:
|
33% |
224:
|
0 |
14:
|
27% |
14:
|
1 |
14:
|
46% |
33:
|
3:
|
33:
|
98% |
70:
|
1 |
14:
|
46% |
165:
|
3:
|
33:
|
98% |
70:
|
2 |
14:
|
46% |
165:
|
6:
|
33:
|
98% |
70:
|
10 |
14:
|
46% |
165:
|
30:
|
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 Firepower 9300 with one SM-44 can support up to 14 instances.
Dedicated Interfaces |
Shared Interfaces |
Number of Instances |
% Forwarding Table Used |
---|---|---|---|
32:
|
0 |
4:
|
16% |
30:
|
0 |
2:
|
14% |
14:
|
1 |
14:
|
46% |
14:
|
2:
|
14:
|
37% |
32:
|
1 |
4:
|
21% |
32:
|
2 |
4:
|
20% |
32:
|
2 |
4:
|
25% |
32:
|
4:
|
4:
|
24% |
24:
|
8 |
3:
|
37% |
10:
|
10 |
5:
|
69% |
10:
|
20:
|
5:
|
59% |
14:
|
10 |
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.
Dedicated Subinterfaces |
Shared Subinterfaces |
Number of Instances |
% Forwarding Table Used |
---|---|---|---|
112:
|
0 |
14:
|
17% |
224:
|
0 |
14:
|
17% |
14:
|
1 |
14:
|
46% |
14:
|
2:
|
14:
|
37% |
112:
|
1 |
14:
|
46% |
112:
|
2:
|
14:
|
37% |
112:
|
2 |
14:
|
46% |
112:
|
4:
|
14:
|
37% |
140:
|
10 |
14:
|
46% |
140:
|
20:
|
14:
|
37% |
Viewing Shared Interface Resources
To view forwarding table and VLAN group usage, enter the show detail command under scope fabric-interconnect . For example:
Firepower# scope fabric-interconnect
DFirepower /fabric-interconnect # show detail
Fabric Interconnect:
ID: A
Product Name: Cisco FPR9K-SUP
PID: FPR9K-SUP
VID: V02
Vendor: Cisco Systems, Inc.
Serial (SN): JAD104807YN
HW Revision: 0
Total Memory (MB): 16185
OOB IP Addr: 10.10.5.14
OOB Gateway: 10.10.5.1
OOB Netmask: 255.255.255.0
OOB IPv6 Address: ::
OOB IPv6 Gateway: ::
Prefix: 64
Operability: Operable
Thermal Status: Ok
Ingress VLAN Group Entry Count (Current/Max): 0/500
Switch Forwarding Path Entry Count (Current/Max): 16/1021
Current Task 1:
Current Task 2:
Current Task 3:
Inline Set Link State Propagation for the Firepower 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 FTD application and enable link state propagation, the FTD 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.