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 Firepower 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 (Firepower Threat Defense-using-FMC 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. 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 Firepower Threat Defense-using-FMC devices. To use this interface, you must configure its IP address and other parameters at the Firepower 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.
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. The FDM and CDO does not support clustering.
Note |
This chapter discusses FXOS VLAN subinterfaces only. You can separately create subinterfaces within the FTD application. See FXOS Interfaces vs. Application Interfaces for more information. |
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. 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.
Shared Interface Scalability
Shared Interface Best Practices
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 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, see the . For example: area
Inline Set Link State Propagation for the FTD
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 Firepower Threat Defense application and enable link state propagation, the Firepower 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. |