Cisco FXOS Firepower Security Appliance CLI Configuration Guide
The Cisco FXOS chassis is a next-generation platform for network and content security solutions. The FXOS chassis is part of the Cisco Application Centric Infrastructure (ACI) Security Solution and provides an agile, open, secure platform that is built for scalability, consistent control, and simplified management.
Advertisement
Advertisement
Cisco FXOS CLI Configuration Guide, 2.2(1)
First Published: 2017-05-15
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,
INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH
THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY,
CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright
©
1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS.
CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT
LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: http:// www.cisco.com/go/trademarks
. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)
©
2017 Cisco Systems, Inc. All rights reserved.
C O N T E N T S
C H A P T E R 1
C H A P T E R 2
C H A P T E R 3
C H A P T E R 4
Introduction to the Firepower Security Appliance 1
About the Firepower Security Appliance
Overview of the Command-Line Interface 5
Committing, Discarding, and Viewing Pending Commands
About Smart Software Licensing
Smart Software Licensing for Applications on the FXOS Chassis
Smart Software Manager and Accounts
Licenses and Devices Managed per Virtual Account
Device Registration and Tokens
Periodic Communication with the License Authority
Smart Call Home Infrastructure
Cisco FXOS CLI Configuration Guide, 2.2(1) iii
Contents
C H A P T E R 5
Prerequisites for Smart Software Licensing
Defaults for Smart Software Licensing
Configure Smart Software Licensing
(Optional) Configure the HTTP Proxy
(Optional) Delete the Call Home URL
Register the Firepower Security Appliance with the License Authority
Smart License Manager Satellite for the FXOS chassis
Configure a Smart License Satellite Server for the FXOS chassis
Configure Permanent License Reservation
(Optional) Return the FXOS Permanent License
Monitoring Smart Software Licensing
History for Smart Software Licensing
Guidelines for Remote Authentication
Password Profile for Locally Authenticated Users
Select the Default Authentication Service
Configuring the Absolute Session Timeout
Configuring the Role Policy for Remote Users
Enabling Password Strength Check for Locally Authenticated Users
Set the Maximum Number of Login Attempts
View and Clear User Lockout Status
Configuring the Maximum Number of Password Changes for a Change Interval
Configure Minimum Password Length Check
Configuring a No Change Interval for Passwords
Configuring the Password History Count
Activating or Deactivating a Local User Account
Clearing the Password History for a Locally Authenticated User
iv
Cisco FXOS CLI Configuration Guide, 2.2(1)
Contents
C H A P T E R 6
C H A P T E R 7
C H A P T E R 8
Downloading Images from Cisco.com
Downloading a Firepower eXtensible Operating System Software Image to the FXOS chassis
Verifying the Integrity of an Image
Upgrading the Firepower eXtensible Operating System Platform Bundle
Downloading a Logical Device Software Image to the FXOS chassis
Updating the Image Version for a Logical Device
Security Certifications Compliance
Security Certifications Compliance
Configure IPSec Secure Channel
Configure Static CRL for a Trustpoint
About the Certificate Revocation List Check
Configure CRL Periodic Download
Enable NTP Server Authentication
Set the LDAP Key Ring Certificate
Enable Client Certificate Authentication
Changing the Management IP Address
Changing the Application Management IP
Modifying the Pre-Login Banner
Install a Trusted Identity Certificate
Cisco FXOS CLI Configuration Guide, 2.2(1) v
Contents
C H A P T E R 9
Recovering from a Software Failure
Recovering from a Corrupted File System
Viewing the Configured Date and Time
Setting the Date and Time Using NTP
Setting the Date and Time Manually
SNMP Security Levels and Privileges
Supported Combinations of SNMP Security Models and Levels
Enabling SNMP and Configuring SNMP Properties
Certificates, Key Rings, and Trusted Points
Regenerating the Default Key Ring
Creating a Certificate Request for a Key Ring
Creating a Certificate Request for a Key Ring with Basic Options
Creating a Certificate Request for a Key Ring with Advanced Options
Importing a Certificate into a Key Ring
vi
Cisco FXOS CLI Configuration Guide, 2.2(1)
Contents
C H A P T E R 1 0
C H A P T E R 1 1
Configuring Properties for LDAP Providers
Configuring Properties for RADIUS Providers
Configuring Properties for TACACS+ Providers
About Firepower Security Appliance Interfaces
Create a Standalone Logical Device
Create a Standalone ASA Logical Device
Create a Standalone Threat Defense Logical Device
Cisco FXOS CLI Configuration Guide, 2.2(1) vii
Contents
C H A P T E R 1 2
About Clustering on the FXOS Chassis
Primary and Secondary Unit Roles
Size the Cluster Control Link for Inter-Chassis Clustering
Cluster Control Link Redundancy for Inter-Chassis Clustering
Cluster Control Link Reliability for Inter-Chassis Clustering
Configure Firepower Threat Defense Clustering
Examples for Inter-Site Clustering
Spanned EtherChannel Transparent Mode North-South Inter-Site Example
Spanned EtherChannel Transparent Mode East-West Inter-Site Example
Prerequisites for Service Chaining
Guidelines for Service Chaining
Configure Radware DefensePro Service Chain on a Standalone Logical Device
Configure Radware DefensePro Service Chain on an Intra-Chassis Cluster
Open UDP/TCP Ports and Enable vDP Web Services
Connect to the Console of the Application or Decorator
Delete an Application Instance that is not Associated with a Logical Device
Change an Interface on a Firepower Threat Defense Logical Device
Change an Interface on an ASA Logical Device
viii
Cisco FXOS CLI Configuration Guide, 2.2(1)
Contents
C H A P T E R 1 3
About Configuration Import/Export
Exporting a Configuration File
Scheduling Automatic Configuration Export
Setting a Configuration Export Reminder
Importing a Configuration File
Creating or Editing a Packet Capture Session
Configuring Filters for Packet Capture
Starting and Stopping a Packet Capture Session
Downloading a Packet Capture File
Deleting Packet Capture Sessions
Cisco FXOS CLI Configuration Guide, 2.2(1) ix
Contents x
Cisco FXOS CLI Configuration Guide, 2.2(1)
C H A P T E R
1
Introduction to the Firepower Security Appliance
•
About the Firepower Security Appliance, page 1
•
Monitoring Chassis Health, page 1
About the Firepower Security Appliance
The Cisco FXOS chassis is a next-generation platform for network and content security solutions. The FXOS chassis is part of the Cisco Application Centric Infrastructure (ACI) Security Solution and provides an agile, open, secure platform that is built for scalability, consistent control, and simplified management.
The FXOS chassis provides the following features:
• Modular chassis-based security system—provides high performance, flexible input/output configurations, and scalability.
• Firepower Chassis Manager—graphical user interface provides streamlined, visual representation of current chassis status and simplified configuration of chassis features.
• FXOS CLI—provides command-based interface for configuring features, monitoring chassis status, and accessing advanced troubleshooting features.
• FXOS REST API—allows users to programmatically configure and manage their chassis.
Monitoring Chassis Health
You can use the show environment summary command to view the following pieces of information that show the overall health for the FXOS chassis:
• Total Power Consumption—Total power consumed in watts.
• Inlet Temperature—Ambient system temperature in Celsius.
• CPU Temperature—Processor temperature in Celsius.
• Power Supply Type—AC or DC.
• Power Supply Input Feed Status—Input status (Ok, Fault).
Cisco FXOS CLI Configuration Guide, 2.2(1)
1
Introduction to the Firepower Security Appliance
Monitoring Chassis Health
• Power Supply Output Status—12V output status (Ok, Fault).
• Power Supply Overall Status—Overall health of PSU (Operable, Removed, Thermal problem).
• Fan Speed RPM—Highest RPM of both fans in single fan tray.
• Fan Speed Status—Fan speed (Slow, Ok, High, Critical).
• Fan Overall Status—Overall health of Fan (Operable, Removed, Thermal problem)
• Blade Total Power Consumption—Total power consumed by security module/engine in watts.
• Blade Processor Temperature—Highest temperature in Celsius of processors on security module/engine.
Procedure
Step 1
Connect to the FXOS CLI (see
Accessing the FXOS CLI, on page 13
).
Step 2
Enter chassis mode:
Firepower-chassis# scope chassis 1
Step 3
To view a summary of the chassis health, enter the following command:
Firepower-chassis /chassis # show environment summary
Firepower-chassis#
scope chassis 1
Firepower-chassis /chassis #
show environment summary
Chassis INFO :
Total Power Consumption: 638.000000
Inlet Temperature (C): 32.000000
CPU Temperature (C): 47.000000
Last updated Time: 2017-01-05T23:34:39.115
PSU 1:
Type: AC
Input Feed Status: Ok
12v Output Status: Ok
Overall Status: Operable
PSU 2:
Type: AC
Input Feed Status: Ok
12v Output Status: Ok
Overall Status: Operable
FAN 1
Fan Speed RPM (RPM): 3168
Speed Status: Ok
Overall Status: Operable
FAN 2
Fan Speed RPM (RPM): 3388
Speed Status: Ok
Overall Status: Operable
FAN 3
Fan Speed RPM (RPM): 3168
Speed Status: Ok
Overall Status: Operable
FAN 4
Fan Speed RPM (RPM): 3212
Speed Status: Ok
Overall Status: Operable
BLADE 1:
2
Cisco FXOS CLI Configuration Guide, 2.2(1)
Introduction to the Firepower Security Appliance
Total Power Consumption: 216.000000
Processor Temperature (C): 58.000000
BLADE 2:
Total Power Consumption: 222.000000
Processor Temperature (C): 62.500000
Monitoring Chassis Health
Cisco FXOS CLI Configuration Guide, 2.2(1)
3
Monitoring Chassis Health
Introduction to the Firepower Security Appliance
4
Cisco FXOS CLI Configuration Guide, 2.2(1)
C H A P T E R
2
Overview of the Command-Line Interface
•
•
•
•
•
•
Committing, Discarding, and Viewing Pending Commands, page 9
•
Online Help for the CLI, page 9
•
Managed Objects
The Firepower eXtensible Operating System uses a managed object model, where managed objects are abstract representations of physical or logical entities that can be managed. For example, chassis, security modules, network modules, ports, and processors are physical entities represented as managed objects, and licenses, user roles, and platform policies are logical entities represented as managed objects.
Managed objects may have one or more associated properties that can be configured.
Command Modes
The CLI is organized into a hierarchy of command modes, with the EXEC mode being the highest-level mode of the hierarchy. Higher-level modes branch into lower-level modes. You use create, enter, and scope commands to move from higher-level modes to modes in the next lower level , and you use the exit command to move up one level in the mode hierarchy. You can also use the top command to move to the top level in the mode hierarchy.
Cisco FXOS CLI Configuration Guide, 2.2(1)
5
Overview of the Command-Line Interface
Command Modes
Note
Most command modes are associated with managed objects, so you must create an object before you can access the mode associated with that object. You use create and enter commands to create managed objects for the modes being accessed. The scope commands do not create managed objects and can only access modes for which managed objects already exist.
Each mode contains a set of commands that can be entered in that mode. Most of the commands available in each mode pertain to the associated managed object.
The CLI prompt for each mode shows the full path down the mode hierarchy to the current mode. This helps you to determine where you are in the command mode hierarchy, and it can be an invaluable tool when you need to navigate through the hierarchy.
The following table lists the main command modes, the commands used to access each mode, and the CLI prompt associated with each mode.
Table 1: Main Command Modes and Prompts
Mode Name
EXEC adapter cabling chassis
Ethernet server
Ethernet uplink fabric-interconnect firmware
Host Ethernet interface license monitoring
Commands Used to Access
top command from any mode
Mode Prompt
#
/adapter # scope adapter command from
EXEC mode
scope cabling command from
EXEC mode
/cabling #
scope chassis command from
EXEC mode
/chassis #
scope eth-server command from
EXEC mode
/eth-server #
scope eth-uplink command from
EXEC mode
/eth-uplink #
scope fabric-interconnect
command from EXEC mode
scope firmware command from
EXEC mode
/fabric-interconnect #
/firmware #
scope host-eth-if command from
EXEC mode
/host-eth-if #
scope license command from
EXEC mode
/license #
scope monitoring command from
EXEC mode
/monitoring #
6
Cisco FXOS CLI Configuration Guide, 2.2(1)
Overview of the Command-Line Interface
Object Commands
Mode Name
organization security server service-profile ssa system virtual HBA virtual NIC
Commands Used to Access
scope org command from EXEC mode
Mode Prompt
/org #
scope security command from
EXEC mode
/security #
scope server command from
EXEC mode
/server #
scope service-profile command from EXEC mode
/service-profile #
scope ssa command from EXEC mode
/ssa #
scope system command from
EXEC mode
/system #
scope vhba command from EXEC mode
/vhba #
scope vnic command from EXEC mode
/vnic #
Object Commands
Four general commands are available for object management:
• create object
• delete object
• enter object
• scope object
You can use the scope command with any managed object, whether a permanent object or a user-instantiated object. The other commands allow you to create and manage user-instantiated objects. For every create object command, a corresponding delete object and enter object command exists.
In the management of user-instantiated objects, the behavior of these commands depends on whether the object exists, as described in the following tables:
Cisco FXOS CLI Configuration Guide, 2.2(1)
7
Overview of the Command-Line Interface
Complete a Command
Table 2: Command behavior if the object does not exist
Command
create object
delete object
enter object
scope object
Behavior
The object is created and its configuration mode, if applicable, is entered.
An error message is generated.
The object is created and its configuration mode, if applicable, is entered.
An error message is generated.
Table 3: Command behavior if the object exists
Command
create object
delete object
enter object
scope object
Behavior
An error message is generated.
The object is deleted.
The configuration mode, if applicable, of the object is entered.
The configuration mode of the object is entered.
Complete a Command
You can use the Tab key in any mode to complete a command. Partially typing a command name and pressing
Tab causes the command to be displayed in full or to the point where another keyword must be chosen or an argument value must be entered.
Command History
The CLI stores all commands used in the current session. You can step through the previously used commands by using the Up Arrow or Down Arrow keys. The Up Arrow key steps to the previous command in the history, and the Down Arrow key steps to the next command in the history. If you get to the end of the history, pressing the Down Arrow key does nothing.
All commands in the history can be entered again by simply stepping through the history to recall the desired command and pressing Enter. The command is entered as if you had manually typed it. You can also recall a command and change it before you press Enter.
8
Cisco FXOS CLI Configuration Guide, 2.2(1)
Overview of the Command-Line Interface
Committing, Discarding, and Viewing Pending Commands
Committing, Discarding, and Viewing Pending Commands
When you enter a configuration command in the CLI, the command is not applied until you enter the
commit-buffer command. Until committed, a configuration command is pending and can be discarded by entering a discard-buffer command.
You can accumulate pending changes in multiple command modes and apply them together with a single
commit-buffer command. You can view the pending commands by entering the show configuration pending command in any command mode.
Note
Committing multiple commands together is not an atomic operation. If any command fails, the successful commands are applied despite the failure. Failed commands are reported in an error message.
While any commands are pending, an asterisk (*) appears before the command prompt. The asterisk disappears when you enter the commit-buffer command.
The following example shows how the prompts change during the command entry process:
Firepower#
scope system
Firepower /system #
scope services
Firepower /system/services #
create ntp-server 192.168.200.101
Firepower /system/services* #
show configuration pending
+ scope services create ntp-server 192.168.200.101
exit
Firepower /system/services* #
commit-buffer
Firepower /system/services #
Online Help for the CLI
At any time, you can type the ? character to display the options available at the current state of the command syntax.
If you have not typed anything at the prompt, typing ? lists all available commands for the mode you are in.
If you have partially typed a command, typing ? lists all available keywords and arguments available at your current position in the command syntax.
CLI Session Limits
The Firepower eXtensible Operating System limits the number of CLI sessions that can be active at one time to 32 total sessions. This value is not configurable.
Cisco FXOS CLI Configuration Guide, 2.2(1)
9
CLI Session Limits
Overview of the Command-Line Interface
10
Cisco FXOS CLI Configuration Guide, 2.2(1)
C H A P T E R
3
Getting Started
•
•
Initial Configuration, page 11
•
Accessing the FXOS CLI, page 13
Task Flow
The following procedure shows the basic tasks that should be completed when configuring your FXOS chassis.
Procedure
Step 1
Configure the FXOS chassis hardware (see the Cisco Firepower Security Appliance Hardware Installation
Guide ).
Step 2
Complete the initial configuration (see
Initial Configuration, on page 11
).
Step 3
Set the Date and Time (see
Setting the Date and Time, on page 103
).
Step 4
Configure a DNS server (see
Configuring DNS Servers, on page 139
).
Step 5
Register your product license (see
License Management, on page 17
).
Step 6
Configure users (see
).
Step 7
Perform software updates as required (see
).
Step 8
Configure additional platform settings (see
Platform Settings, on page 103
).
Step 9
Configure interfaces (see
Interface Management, on page 141
).
Step 10 Create logical devices (see
).
Initial Configuration
Before you can use Firepower Chassis Manager or the FXOS CLI to configure and manage your system, you must perform some initial configuration tasks using the FXOS CLI accessed through the console port. The
Cisco FXOS CLI Configuration Guide, 2.2(1)
11
Getting Started
Initial Configuration
first time that you access the FXOS chassis using the FXOS CLI, you will encounter a setup wizard that you can use to configure the system.
You can choose to either restore the system configuration from an existing backup file, or manually set up the system by going through the Setup wizard. If you choose to restore the system, the backup file must be reachable from the management network.
You must specify only one IPv4 address, gateway, and subnet mask, or only one IPv6 address, gateway, and network prefix for the single management port on the FXOS chassis. You can configure either an IPv4 or an
IPv6 address for the management port IP address.
Before You Begin
1
Verify the following physical connections on the FXOS chassis:
• The console port is physically connected to a computer terminal or console server.
• The 1 Gbps Ethernet management port is connected to an external hub, switch, or router.
For more information, refer to the Cisco Firepower Security Appliance Hardware Installation Guide .
2
Verify that the console port parameters on the computer terminal (or console server) attached to the console port are as follows:
• 9600 baud
• 8 data bits
• No parity
• 1 stop bit
Procedure
Step 1
Connect to the console port.
Step 2
Power on the FXOS chassis.
You will see the power on self-test messages as the FXOS chassis boots.
Step 3
When the unconfigured system boots, a setup wizard prompts you for the following information required to configure the system:
• Setup mode (restore from full system backup or initial setup)
• Strong password enforcement policy (for strong password guidelines, see
)
• Admin password
• System name
• Management port IPv4 address and subnet mask, or IPv6 address and prefix
• Default gateway IPv4 or IPv6 address
• DNS Server IPv4 or IPv6 address
• Default domain name
12
Cisco FXOS CLI Configuration Guide, 2.2(1)
Getting Started
Accessing the FXOS CLI
Step 4
Review the setup summary and enter yes to save and apply the settings, or enter no to go through the Setup wizard again to change some of the settings.
If you choose to go through the Setup wizard again, the values you previously entered appear in brackets. To accept previously entered values, press Enter.
The following example sets up a configuration using IPv4 management addresses:
Enter the setup mode; setup newly or restore from backup. (setup/restore) ?
setup
You have chosen to setup a new Fabric interconnect. Continue? (y/n):
y
Enforce strong password? (y/n) [y]:
n
Enter the password for "admin":
adminpassword%958
Confirm the password for "admin":
adminpassword%958
Enter the system name:
foo
Physical Switch Mgmt0 IP address :
192.168.10.10
Physical Switch Mgmt0 IPv4 netmask:
255.255.255.0
IPv4 address of the default gateway:
192.168.10.1
Configure the DNS Server IP address? (yes/no) [n]:
yes
DNS IP address:
20.10.20.10
Configure the default domain name? (yes/no) [n]:
yes
Default domain name:
domainname.com
Following configurations will be applied:
Switch Fabric=A
System Name=foo
Enforce Strong Password=no
Physical Switch Mgmt0 IP Address=192.168.10.10
Physical Switch Mgmt0 IP Netmask=255.255.255.0
Default Gateway=192.168.10.1
IPv6 value=0
DNS Server=20.10.20.10
Domain Name=domainname.com
Apply and save the configuration (select 'no' if you want to re-enter)? (yes/no):
yes
The following example sets up a configuration using IPv6 management addresses:
Enter the setup mode; setup newly or restore from backup. (setup/restore) ?
setup
You have chosen to setup a new Fabric interconnect. Continue? (y/n):
y
Enforce strong password? (y/n) [y]:
n
Enter the password for "admin":
adminpassword%652
Confirm the password for "admin":
adminpassword%652
Enter the system name:
foo
Physical Switch Mgmt0 IP address :
2001::107
Physical Switch Mgmt0 IPv6 prefix:
64
IPv6 address of the default gateway:
2001::1
Configure the DNS Server IPv6 address? (yes/no) [n]:
yes
DNS IP address:
2001::101
Configure the default domain name? (yes/no) [n]:
yes
Default domain name:
domainname.com
Following configurations will be applied:
Switch Fabric=A
System Name=foo
Enforced Strong Password=no
Physical Switch Mgmt0 IPv6 Address=2001::107
Physical Switch Mgmt0 IPv6 Prefix=64
Default Gateway=2001::1
Ipv6 value=1
DNS Server=2001::101
Domain Name=domainname.com
Apply and save the configuration (select 'no' if you want to re-enter)? (yes/no):
yes
Accessing the FXOS CLI
You can connect to the FXOS CLI using a terminal plugged into the console port. Verify that the console port parameters on the computer terminal (or console server) attached to the console port are as follows:
Cisco FXOS CLI Configuration Guide, 2.2(1)
13
Getting Started
Accessing the FXOS CLI
• 9600 baud
• 8 data bits
• No parity
• 1 stop bit
You can also connect to the FXOS CLI using SSH and Telnet. The Firepower eXtensible Operating System supports up to eight simultaneous SSH connections. To connect with SSH, you need to know the hostname or IP address of the FXOS chassis.
Use one of the following syntax examples to log in with SSH, Telnet, or Putty:
Note
SSH log in is case-sensitive.
From a Linux terminal using SSH:
• ssh ucs-auth-domain\\username@{UCSM-ip-address|UCMS-ipv6-address}
ssh ucs-example\\[email protected]
ssh ucs-example\\jsmith@2001::1
• ssh -l ucs-auth-domain\\username {UCSM-ip-address| UCSM-ipv6-address| UCSM-host-name}
ssh -l ucs-example\\jsmith 192.0.20.11
ssh -l ucs-example\\jsmith 2001::1
• ssh {UCSM-ip-address | UCSM-ipv6-address | UCSM-host-name} -l ucs-auth-domain\\username
ssh 192.0.20.11 -l ucs-example\\jsmith ssh 2001::1 -l ucs-example\\jsmith
• ssh ucs-auth-domain\\username@{UCSM-ip-address|UCSM-ipv6-address}
ssh ucs-ldap23\\[email protected]
ssh ucs-ldap23\\jsmith@2001::1
From a Linux terminal using Telnet:
Note
Telnet is disabled by default. See
Configuring Telnet, on page 109
for instructions on enabling Telnet.
• telnet ucs-UCSM-host-name ucs-auth-domain\username
telnet ucs-qa-10
login:
ucs-ldap23\blradmin
• telnet ucs-{UCSM-ip-address|UCSM-ipv6-address}ucs-auth-domain\username
telnet 10.106.19.12 2052
ucs-qa-10-A login:
ucs-ldap23\blradmin
From a Putty client:
• Login as: ucs-auth-domain\username
Login as:
ucs-example\jsmith
14
Cisco FXOS CLI Configuration Guide, 2.2(1)
Getting Started
Accessing the FXOS CLI
Note
If the default authentication is set to local, and the console authentication is set to LDAP, you can log in to the fabric interconnect from a Putty client using ucs-local\admin, where admin is the name of the local account.
Cisco FXOS CLI Configuration Guide, 2.2(1)
15
Accessing the FXOS CLI
Getting Started
16
Cisco FXOS CLI Configuration Guide, 2.2(1)
C H A P T E R
4
License Management
Cisco Smart Software Licensing lets you purchase and manage a pool of licenses centrally. You can easily deploy or retire devices without having to manage each unit’s license key. Smart Software Licensing also lets you see your license usage and needs at a glance.
•
About Smart Software Licensing, page 17
•
Prerequisites for Smart Software Licensing, page 19
•
Defaults for Smart Software Licensing, page 20
•
Configure Smart Software Licensing, page 20
•
Smart License Manager Satellite for the FXOS chassis, page 23
•
Permanent License Reservation, page 24
•
Monitoring Smart Software Licensing, page 26
•
History for Smart Software Licensing, page 26
About Smart Software Licensing
This section describes how Smart Software Licensing works.
Note
This section only applies to ASA logical devices on the FXOS chassis. For more information on licensing for Firepower Threat Defense logical devices, see the Firepower Management Center Configuration Guide.
Smart Software Licensing for Applications on the FXOS Chassis
For the application on the FXOS chassis, Smart Software Licensing configuration is split between the FXOS chassis supervisor and the application.
• FXOS chassis—Configure all Smart Software Licensing infrastructure in the supervisor, including parameters for communicating with the License Authority. The FXOS chassis itself does not require any licenses to operate.
Cisco FXOS CLI Configuration Guide, 2.2(1)
17
License Management
Smart Software Manager and Accounts
For offline licensing, you can deploy a Cisco Smart Software Manager satellite server that is accessible to your local network, and that syncs with the License Authority on demand or on a schedule you set.
The three Smart License models supported on the FXOS chassis are Smart License default mode, Proxy mode, and Smart License Satellite mode. Inter-chassis clustering requires that you enable the same Smart
Licensing mode type on each FXOS chassis in the cluster.
• Application—Configure all license entitlements in the application.
Smart Software Manager and Accounts
When you purchase 1 or more licenses for the device, you manage them in the Cisco Smart Software Manager: https://software.cisco.com/#module/SmartLicensing
The Smart Software Manager lets you create a master account for your organization.
Note
If you do not yet have an account, click the link to set up a new account . The Smart Software Manager lets you create a master account for your organization.
By default, your licenses are assigned to the Default Virtual Account under your master account. As the account administrator, you can optionally create additional virtual accounts; for example, you can create accounts for regions, departments, or subsidiaries. Multiple virtual accounts let you more easily manage large numbers of licenses and devices.
Licenses and Devices Managed per Virtual Account
Licenses and devices are managed per virtual account: only that virtual account’s devices can use the licenses assigned to the account. If you need additional licenses, you can transfer an unused license from another virtual account. You can also transfer devices between virtual accounts.
Only the FXOS chassis registers as a device, while the applications in the chassis request their own licenses.
For example, for a Firepower 9300 chassis with 3 security modules, the chassis counts as one device, but the modules use 3 separate licenses.
Device Registration and Tokens
For each virtual account, you can create a registration token. This token is valid for 30 days by default. Enter this token ID plus entitlement levels when you deploy each device, or when you register an existing device.
You can create a new token if an existing token is expired.
Note
Device registration is configured in the FXOS chassis supervisor, not on the security module.
At startup after deployment, or after you manually configure these parameters on an existing device, the device registers with the Cisco License Authority. When the device registers with the token, the License Authority issues an ID certificate for communication between the device and the License Authority. This certificate is valid for 1 year, although it will be renewed every 6 months.
18
Cisco FXOS CLI Configuration Guide, 2.2(1)
License Management
Periodic Communication with the License Authority
Periodic Communication with the License Authority
The device communicates with the License Authority every 30 days. If you make changes in the Smart Software
Manager, you can refresh the authorization on the device so the change takes place immediately. Or you can wait for the device to communicate as scheduled.
You can optionally configure an HTTP proxy.
The FXOS chassis must have Internet access either directly or through an HTTP proxy at least every 90 days.
Normal license communication occurs every 30 days, but with the grace period, your device will operate for up to 90 days without calling home. After the grace period, you must contact the Licensing Authority, or you will not be able to make configuration changes to features requiring special licenses; operation is otherwise unaffected.
Note
Offline licensing is not supported.
Out-of-Compliance State
The device can become out of compliance in the following situations:
• Over-utilization—When the device uses unavailable licenses.
• License expiration—When a time-based license expires.
• Lack of communication—When the device cannot reach the Licensing Authority for re-authorization.
To verify whether your account is in, or approaching, an Out-of-Compliance state, you must compare the entitlements currently in use by your FXOS chassis against those in your Smart Account.
In an out-of-compliance state, the device will be limited in some way, depending on the application.
Smart Call Home Infrastructure
By default, a Smart Call Home profile exists in the configuration that specifies the URL for the Licensing
Authority. You cannot remove this profile. Note that the only configurable option for the License profile is the destination address URL for the License Authority. Unless directed by Cisco TAC, you should not change the License Authority URL.
You cannot disable Smart Call Home for Smart Software Licensing.
Prerequisites for Smart Software Licensing
• Create a master account on the Cisco Smart Software Manager: https://software.cisco.com/#module/SmartLicensing
If you do not yet have an account, click the link to set up a new account . The Smart Software Manager lets you create a master account for your organization.
Cisco FXOS CLI Configuration Guide, 2.2(1)
19
License Management
Defaults for Smart Software Licensing
• Purchase 1 or more licenses from Cisco Software Central.
• Ensure Internet access or HTTP proxy access from the device, so the device can contact the Licensing
Authority. Offline licensing is not supported.
• Configure a DNS server so the device can resolve the name of the licensing authority server.
• Set the clock for the device.
• Note that this section only applies to ASA logical devices on the FXOS chassis. For more information on licensing for Firepower Threat Defense logical devices, see the Firepower Management Center
Configuration Guide.
Defaults for Smart Software Licensing
The FXOS chassis default configuration includes a Smart Call Home profile called “SLProf” that specifies the URL for the Licensing Authority.
scope monitoring scope callhome scope profile SLProf scope destination SLDest set address https://tools.cisco.com/its/service/oddce/services/DDCEService
Configure Smart Software Licensing
To communicate with the Cisco License Authority, you can optionally configure an HTTP proxy. To register with the License Authority, you must enter the registration token ID on the FXOS chassis that you obtained from your Smart Software License account.
Procedure
Step 1
(Optional) Configure the HTTP Proxy, on page 20
.
Step 2
Register the Firepower Security Appliance with the License Authority, on page 22
.
(Optional) Configure the HTTP Proxy
If your network uses an HTTP proxy for Internet access, you must configure the proxy address for Smart
Software Licensing. This proxy is also used for Smart Call Home in general.
Note
HTTP proxy with authentication is not supported.
20
Cisco FXOS CLI Configuration Guide, 2.2(1)
License Management
(Optional) Delete the Call Home URL
Procedure
Step 1
Enable the HTTP proxy:
scope monitoring scope callhome set http-proxy-server-enable on
Example:
scope monitoring scope call-home set http-proxy-server-enable on
Step 2
Set the proxy URL:
set http-proxy-server-url url where url is the http or https address of the proxy server.
Example:
set http-proxy-server-url https://10.1.1.1
Step 3
Set the port:
set http-proxy-server-port port
Example:
set http-proxy-server-port 443
Step 4
Commit the buffer:
commit-buffer
(Optional) Delete the Call Home URL
Use the following procedure to delete a previously configured Call Home URL.
Procedure
Step 1
Enter the monitoring scope:
scope monitoring
Step 2
Enter the callhome scope:
scope callhome
Step 3
Look for the SLProfile:
scope profile SLProfile
Step 4
Show the destination:
show destination
Cisco FXOS CLI Configuration Guide, 2.2(1)
21
License Management
Register the Firepower Security Appliance with the License Authority
Example:
SLDest https https://tools.cisco.com/its/oddce/services/DDCEService
Step 5
Delete the URL:
delete destination SLDest
Step 6
Commit the buffer:
commit-buffer
Register the Firepower Security Appliance with the License Authority
When you register the FXOS chassis, the License Authority issues an ID certificate for communication between the FXOS chassis and the License Authority. It also assigns the FXOS chassis to the appropriate virtual account. Normally, this procedure is a one-time instance. However, you might need to later re-register the
FXOS chassis if the ID certificate expires because of a communication problem, for example.
Procedure
Step 1
In the Smart Software Manager, request and copy a registration token for the virtual account to which you want to add this FXOS chassis.
Step 2
Enter the registration token on the FXOS chassis:
scope license register idtoken id-token
Example:
scope license register idtoken ZGFmNWM5NjgtYmNjYS00ZWI3L
WE3NGItMWJkOGExZjIxNGQ0LTE0NjI2NDYx%0AMDIzNT
V8N3R0dXM1Z0NjWkdpR214eFZhMldBOS9CVnNEYnVKM1 g3R3dvemRD%0AY29NQT0%3D%0A
Step 3
To later unregister the device, enter:
deregister
Deregistering the FXOS chassis removes the device from your account. All license entitlements and certificates on the device are removed. You might want to deregister to free up a license for a new FXOS chassis.
Alternatively, you can remove the device from the Smart Software Manager.
Step 4
To renew the ID certificate and update the entitlements on all security modules, enter:
scope licdebug renew
By default, the ID certificate is automatically renewed every 6 months, and the license entitlement is renewed every 30 days. You might want to manually renew the registration for either of these items if you have a limited window for Internet access, or if you make any licensing changes in the Smart Software Manager, for example.
22
Cisco FXOS CLI Configuration Guide, 2.2(1)
License Management
Smart License Manager Satellite for the FXOS chassis
Smart License Manager Satellite for the FXOS chassis
Cisco Smart Software Manager satellite is a component of Cisco Smart Licensing that works in conjunction with Cisco Smart Software Manager (SSM) . It helps you intelligently manage customer product licenses, providing near real-time visibility and reporting of Cisco licenses that customers purchase and consume.
Customers who, either for policy or network reachability reasons, do not want to manage their Cisco products directly using the Cisco Smart Software Manager residing at software.cisco.com, can choose to install the
Cisco Smart Software Manager satellite on-premises. When enabled, the FXOS chassis sends report license consumption to the Smart Software Manager satellite as though it were a replicate of the Cisco Smart Software
Manager hosted within your premises.
Once you download and deploy the satellite application, you can perform the following functions without sending data to Cisco SSM using the Internet:
• Activate or register a license
• View your company's licenses
• Transfer licenses between company entities
For more information, see the Smart Software Manager satellite installation and configuration guides on Smart
Account Manager satellite .
Configure a Smart License Satellite Server for the FXOS chassis
The following procedure shows how to configure the FXOS chassis to use a Smart Licence Manager satellite.
Before You Begin
• Complete all prerequisites listed in the
Prerequisites for Smart Software Licensing, on page 19
.
• Download the Smart License Satellite OVA file from Cisco.com and install and configure it on a
VMwareESXi server. For more information, see the Smart Software Manager satellite Install Guide .
Procedure
Step 1
Set up the satellite server as the callhome destination:
scope monitoring scope call-home scope profile SLProfile scope destination SLDest
set address https://ip_address/Transportgateway/services/DeviceRequestHandler
Step 2
Create a new trust point.
a) Enter security mode
scope security
b) Create and name a trusted point:
Cisco FXOS CLI Configuration Guide, 2.2(1)
23
License Management
Permanent License Reservation
create trustpoint trustpoint_name c) Specify certificate information for the trust point. Note: the certificate must be in Base64 encoded X.509
(CER) format.
set certchain certchain
If you do not specify certificate information in the command, you are prompted to enter a certificate or a list of trustpoints defining a certification path to the root certificate authority (CA). On the next line following your input, type ENDOFBUF to finish.
d) Commit the configuration:
commit-buffer
Step 3
Register the FXOS chassis with the License Authority (see
Register the Firepower Security Appliance with the License Authority, on page 22
). Note that you must request and copy the registration token from the
Smart License Manager satellite.
Permanent License Reservation
You can assign a permanent license to your FXOS chassis. This universal reservation allows you to use any entitlement for an unlimited count on your device.
Note
Before you begin, you must purchase the permanent licenses so they are available in the Smart Software
Manager. Not all accounts are approved for permanent license reservation. Make sure you have approval from Cisco for this feature before you attempt to configure it.
Configure Permanent License Reservation
The following procedure shows how to assign a permanent license to your FXOS chassis.
Procedure
Step 1
From the FXOS CLI, enable license reservation:
scope license enable reservation
Step 2
Scope to the license reservation:
scope license scope reservation
Step 3
Generate a reservation request code:
request universal show license resvcode
24
Cisco FXOS CLI Configuration Guide, 2.2(1)
License Management
(Optional) Return the FXOS Permanent License
Step 4
Go to the Smart Software Manager Inventory screen in the Cisco Smart Software Manager portal, and click the Licenses tab: https://software.cisco.com/#SmartLicensing-Inventory
The Licenses tab displays all existing licenses related to your account, both regular and permanent.
Step 5
Click License Reservation, and type the generated reservation request code into the box.
Step 6
Click Reserve License.
The Smart Software Manager generates an authorization code. You can download the code or copy it to the clipboard. At this point, the license is now in use according to the Smart Software Manager.
If you do not see the License Reservation button, then your account is not authorized for permanenet license reservation. In this case, you should disable permanent license reservation and re-enter the regular smart license commands.
Step 7
In the FXOS CLI, enter the authorization code:
license smart reservation install code
Your FXOS is now fully licensed with PLR.
(Optional) Return the FXOS Permanent License
If you no longer need a permanent license, you must officially return it to the Smart Software Manager using this procedure. If you do not follow all steps, the license stays in an in-use state and cannot be used elsewhere.
Procedure
Step 1
From the FXOS CLI, generate a return code:
license smart reservation return
The FXOS chassis immediately becomes unlicensed and moves to the Evaluation state.
Step 2
View the FXOS universal device identifier (UDI) so you can find your FXOS instance in the Smart Software
Manager:
show license udi
Step 3
Go to the Smart Software Manager Inventory screen, and click on the Product Instances tab: https://software.cisco.com/#SmartLicensing-Inventory
Step 4
Search for your FXOS chassis using its universal device identifier (UDI).
Step 5
Choose Actions > Remove, and type the generated return code into the box.
Step 6
Click Remove Product Instance.
The permanent license is returned to the available pool.
Cisco FXOS CLI Configuration Guide, 2.2(1)
25
License Management
Monitoring Smart Software Licensing
Monitoring Smart Software Licensing
See the following commands for viewing license status:
• show license all
Displays the state of Smart Software Licensing, Smart Agent version, UDI information, Smart Agent state, global compliance status, the entitlements status, licensing certificate information and schedule
Smart Agent tasks.
• show license status
• show license techsupport
History for Smart Software Licensing
Feature Name Description
Cisco Smart Software Licensing for the FXOS chassis
Platform
Releases
1.1(1) Smart Software Licensing lets you purchase and manage a pool of licenses. Smart licenses are not tied to a specific serial number. You can easily deploy or retire devices without having to manage each unit’s license key. Smart Software Licensing also lets you see your license usage and needs at a glance. Smart
Software Licensing configuration is split between the FXOS chassis supervisor and the security module.
We introduced the following commands: deregister, register
idtoken, renew, scope callhome, scope destination, scope licdebug, scope license, scope monitoring, scope profile, set address, set http-proxy-server-enable on, set http-proxy-server-url, set http-proxy-server-port, show license all, show license status, show license techsupport
26
Cisco FXOS CLI Configuration Guide, 2.2(1)
C H A P T E R
5
User Management
•
•
Guidelines for Usernames, page 28
•
Guidelines for Passwords, page 29
•
Guidelines for Remote Authentication, page 30
•
•
Password Profile for Locally Authenticated Users, page 33
•
Select the Default Authentication Service, page 34
•
Configuring the Absolute Session Timeout, page 35
•
Configuring the Role Policy for Remote Users, page 36
•
Enabling Password Strength Check for Locally Authenticated Users, page 37
•
Set the Maximum Number of Login Attempts, page 38
•
View and Clear User Lockout Status, page 39
•
Configuring the Maximum Number of Password Changes for a Change Interval, page 39
•
Configure Minimum Password Length Check, page 40
•
Configuring a No Change Interval for Passwords, page 41
•
Configuring the Password History Count, page 41
•
Creating a Local User Account, page 42
•
Deleting a Local User Account, page 44
•
Activating or Deactivating a Local User Account, page 44
•
Clearing the Password History for a Locally Authenticated User, page 45
Cisco FXOS CLI Configuration Guide, 2.2(1)
27
User Management
User Accounts
User Accounts
User accounts are used to access the system. You can configure up to 48 local user accounts. Each user account must have a unique username and password.
Admin Account
The admin account is a default user account and cannot be modified or deleted. This account is the system administrator or superuser account and has full privileges. There is no default password assigned to the admin account; you must choose the password during the initial system setup.
The admin account is always active and does not expire. You cannot configure the admin account as inactive.
Locally Authenticated User Accounts
A locally authenticated user account is authenticated directly through the chassis and can be enabled or disabled by anyone with admin or AAA privileges. Once a local user account is disabled, the user cannot log in.
Configuration details for disabled local user accounts are not deleted by the database. If you reenable a disabled local user account, the account becomes active again with the existing configuration, including username and password.
Remotely Authenticated User Accounts
A remotely authenticated user account is any user account that is authenticated through LDAP, RADIUS, or
TACACS+.
If a user maintains a local user account and a remote user account simultaneously, the roles defined in the local user account override those maintained in the remote user account.
See the following topics for more information on guidelines for remote authentication, and how to configure and delete remote authentication providers:
•
Guidelines for Remote Authentication, on page 30
•
Configuring LDAP Providers, on page 128
•
Configuring RADIUS Providers, on page 132
•
Configuring TACACS+ Providers, on page 135
Expiration of User Accounts
You can configure user accounts to expire at a predefined time. When the expiration time is reached, the user account is disabled.
By default, user accounts do not expire.
After you configure a user account with an expiration date, you cannot reconfigure the account to not expire.
You can, however, configure the account with the latest expiration date available.
Guidelines for Usernames
The username is also used as the login ID for Firepower Chassis Manager and the FXOS CLI. When you assign login IDs to user accounts, consider the following guidelines and restrictions:
28
Cisco FXOS CLI Configuration Guide, 2.2(1)
User Management
Guidelines for Passwords
• The login ID can contain between 1 and 32 characters, including the following:
◦Any alphabetic character
◦Any digit
◦_ (underscore)
◦- (dash)
◦. (dot)
• The login ID must be unique.
• The login ID must start with an alphabetic character. It cannot start with a number or a special character, such as an underscore.
• The login ID is case-sensitive.
• You cannot create an all-numeric login ID.
• After you create a user account, you cannot change the login ID. You must delete the user account and create a new one.
Guidelines for Passwords
A password is required for each locally authenticated user account. A user with admin or AAA privileges can configure the system to perform a password strength check on user passwords. If the password strength check is enabled, each user must have a strong password.
We recommend that each user have a strong password. If you enable the password strength check for locally authenticated users, the Firepower eXtensible Operating System rejects any password that does not meet the following requirements:
• Must contain a minimum of 8 characters and a maximum of 80 characters.
Note
You can optionally configure a minimum password length of 15 characters on the system, to comply with Common Criteria requirements. For more information, see
Minimum Password Length Check, on page 40
.
• Must include at least one uppercase alphabetic character.
• Must include at least one lowercase alphabetic character.
• Must include at least one non-alphanumeric (special) character.
• Must not contain a character that is repeated more than 3 times consecutively, such as aaabbb.
• Must not contain three consecutive numbers or letters in any order, such as passwordABC or password321.
• Must not be identical to the username or the reverse of the username.
• Must pass a password dictionary check. For example, the password must not be based on a standard dictionary word.
• Must not contain the following symbols: $ (dollar sign), ? (question mark), and = (equals sign).
Cisco FXOS CLI Configuration Guide, 2.2(1)
29
User Management
Guidelines for Remote Authentication
• Must not be blank for local user and admin accounts.
Guidelines for Remote Authentication
If a system is configured for one of the supported remote authentication services, you must create a provider for that service to ensure that the FXOS chassis can communicate with the system. The following guidelines impact user authorization:
User Accounts in Remote Authentication Services
User accounts can exist locally in the FXOS chassis or in the remote authentication server.
You can view the temporary sessions for users who log in through remote authentication services from the FXOS Chassis Manager GUI and from the FXOS CLI.
User Roles in Remote Authentication Services
If you create user accounts in the remote authentication server, you must ensure that the accounts include the roles those users require for working in the FXOS chassis and that the names of those roles match the names used in FXOS. Based on the role policy, a user might not be allowed to log in, or is granted only read-only privileges.
User Attributes in Remote Authentication Providers
For RADIUS and TACAS+ configurations, you must configure a user attribute for the FXOS chassis in each remote authentication provider through which users log in to Firepower Chassis Manager and the FXOS CLI.
This user attribute holds the roles and locales assigned to each user.
When a user logs in, FXOS does the following:
1
Queries the remote authentication service.
2
Validates the user.
3
If the user is validated, checks the roles and locales assigned to that user.
The following table contains a comparison of the user attribute requirements for the remote authentication providers supported by FXOS:
30
Cisco FXOS CLI Configuration Guide, 2.2(1)
User Management
Guidelines for Remote Authentication
Authenication Provider
LDAP
Custom Attribute
Optional
RADIUS Optional
Schema Extension Attribute ID Requirements
You can choose to do one of the following:
• Do not extend the
LDAP schema and configure an existing, unused attribute that meets the requirements.
The Cisco LDAP implementation requires a unicode type attribute.
If you choose to create the
CiscoAVPair custom attribute, use the following attribute ID:
1.3.6.1.4.1.9.287247.1
• Extend the LDAP schema and create a custom attribute with a unique name, such as
CiscoAVPair.
A sample OID is provided in the following section.
You can choose to do one of the following:
• Do not extend the
RADIUS schema and use an existing, unused attribute that meets the requirements.
• Extend the
RADIUS schema and create a custom attribute with a unique name, such as cisco-avpair.
The vendor ID for the
Cisco RADIUS implementation is 009 and the vendor ID for the attribute is 001.
The following syntax example shows how to specify multiples user roles and locales if you choose to create the cisco-avpair attribute: shell:roles="admin,aaa" shell:locales="L1,abc"
.
Use a comma "," as the delimiter to separate multiple values.
Cisco FXOS CLI Configuration Guide, 2.2(1)
31
User Management
Guidelines for Remote Authentication
Authenication Provider
TACAS
Custom Attribute
Required
Schema Extension Attribute ID Requirements
You must extend the schema and create a custom attribute with the name cisco-av-pair.
The cisco-av-pair name is the string that provides the attribute ID for the
TACACS+ provider.
The following syntax example shows how to specify multiples user roles and locales when you create the cisco-av-pair attribute: cisco-av-pair=shell:roles="admin aaa" shell:locales*"L1 abc"
. Using an asterisk
(*) in the cisco-av-pair attribute syntax flags the locale as optional, preventing authentication failures for other Cisco devices that use the same authorization profile. Use a space as the delimiter to separate multiple values.
Sample OID for LDAP User Attribute
The following is a sample OID for a custom CiscoAVPair attribute:
CN=CiscoAVPair,CN=Schema,
CN=Configuration,CN=X objectClass: top objectClass: attributeSchema cn: CiscoAVPair distinguishedName: CN=CiscoAVPair,CN=Schema,CN=Configuration,CN=X instanceType: 0x4 uSNCreated: 26318654 attributeID: 1.3.6.1.4.1.9.287247.1
attributeSyntax: 2.5.5.12
isSingleValued: TRUE showInAdvancedViewOnly: TRUE adminDisplayName: CiscoAVPair adminDescription: UCS User Authorization Field oMSyntax: 64 lDAPDisplayName: CiscoAVPair name: CiscoAVPair objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,CN=X
32
Cisco FXOS CLI Configuration Guide, 2.2(1)
User Management
User Roles
User Roles
The system contains the following user roles:
Administrator
Complete read-and-write access to the entire system. The default admin account is assigned this role by default and it cannot be changed.
Read-Only
Read-only access to system configuration with no privileges to modify the system state.
Operations
Read-and-write access to NTP configuration, Smart Call Home configuration for Smart Licensing, and system logs, including syslog servers and faults. Read access to the rest of the system.
AAA Administrator
Read-and-write access to users, roles, and AAA configuration. Read access to the rest of the system.
Password Profile for Locally Authenticated Users
The password profile contains the password history and password change interval properties for all locally authenticated users. You cannot specify a different password profile for each locally authenticated user.
Password History Count
The password history count allows you to prevent locally authenticated users from reusing the same password over and over again. When this property is configured, the Firepower chassis stores passwords that were previously used by locally authenticated users up to a maximum of 15 passwords. The passwords are stored in reverse chronological order with the most recent password first to ensure that the only the oldest password can be reused when the history count threshold is reached.
A user must create and use the number of passwords configured in the password history count before being able to reuse one. For example, if you set the password history count to 8, a locally authenticated user cannot reuse the first password until after the ninth password has expired.
By default, the password history is set to 0. This value disables the history count and allows users to reuse previously passwords at any time.
If necessary, you can clear the password history count for a locally authenticated user and enable reuse of previous passwords.
Password Change Interval
The password change interval enables you to restrict the number of password changes a locally authenticated user can make within a given number of hours. The following table describes the two configuration options for the password change interval.
Cisco FXOS CLI Configuration Guide, 2.2(1)
33
User Management
Select the Default Authentication Service
Interval Configuration
No password change allowed
Description
This option does not allow passwords for locally authenticated users to be changed within a specified number of hours after a password change.
You can specify a no change interval between 1 and 745 hours. By default, the no change interval is 24 hours.
Example
For example, to prevent passwords from being changed within 48 hours after a locally authenticated user changes his or her password, set the following:
• Change during interval to disable
• No change interval to 48
Password changes allowed within change interval
This option specifies the maximum number of times that passwords for locally authenticated users can be changed within a pre-defined interval.
You can specify a change interval between 1 and 745 hours and a maximum number of password changes between 0 and 10. By default, a locally authenticated user is permitted a maximum of 2 password changes within a 48 hour interval.
For example, to allow a password to be changed a maximum of once within 24 hours after a locally authenticated user changes his or her password, set the following:
• Change during interval to enable
• Change count to 1
• Change interval to 24
Select the Default Authentication Service
Procedure
Step 1
Enter security mode:
Firepower-chassis # scope security
Step 2
Enter default authorization security mode:
Firepower-chassis /security # scope default-auth
Step 3
Specify the default authentication:
Firepower-chassis /security/default-auth # set realm auth-type where auth-type is one of the following keywords:
• ldap—Specifies LDAP authentication
• local—Specifies local authentication
• none—Allows local users to log on without specifying a password
• radius—Specifies RADIUS authentication
• tacacs—Specifies TACACS+ authentication
Step 4
(Optional) Specify the associated provider group, if any:
Firepower-chassis /security/default-auth # set auth-server-group auth-serv-group-name
34
Cisco FXOS CLI Configuration Guide, 2.2(1)
User Management
Configuring the Absolute Session Timeout
Step 5
(Optional) Specify the maximum amount of time allowed between refresh requests for a user in this domain:
Firepower-chassis /security/default-auth # set refresh-period seconds
Specify an integer between 0 and 600. The default is 600 seconds.
If this time limit is exceeded, FXOS considers the web session to be inactive, but it does not terminate the session.
Step 6
(Optional) Specify the maximum amount of time that can elapse after the last refresh request before FXOS considers a web session to have ended:
Firepower-chassis /security/default-auth # set session-timeout seconds
Specify an integer between 0 and 600. The default is 600 seconds.
Note
If you set two-factor authentication for a RADIUS or TACACS+ realm, consider increasing the
session-refresh and session-timeout periods so that remote users do not have to reauthenticate too frequently.
Step 7
(Optional) Set the authentication method to two-factor authentication for the realm:
Firepower-chassis /security/default-auth # set use-2-factor yes
Note
Two-factor authentication applies only to the RADIUS and TACACS+ realms.
Step 8
Commit the transaction to the system configuration:
commit-buffer
The following example sets the default authentication to RADIUS, the default authentication provider group to provider1, enables two-factor authentications, sets the refresh period to 300 seconds (5 minutes), the session timeout period to 540 seconds (9 minutes), and enables two-factor authentication. It then commits the transaction.
Firepower-chassis#
scope security
Firepower-chassis /security # scope default-auth
Firepower-chassis /security/default-auth #
set realm radius
Firepower-chassis /security/default-auth* #
set auth-server-group provider1
Firepower-chassis /security/default-auth* #
set use-2-factor yes
Firepower-chassis /security/default-auth* #
set refresh-period 300
Firepower-chassis /security/default-auth* #
set session-timeout 540
Firepower-chassis /security/default-auth* #
commit-buffer
Firepower-chassis /security/default-auth #
Configuring the Absolute Session Timeout
The FXOS chassis has an absolute session timeout setting that closes user sessions after the absolute session timeout period has passed, regardless of session use. This absolute timeout functionality is global across all forms of access including serial console, SSH, and HTTPS.
You can separately configure the absolute session timeout for serial console sessions. This allows for disabling the serial console absolute session timeout for debugging needs while maintaining the timeout for other forms of access.
The absolute timeout value defaults to 3600 seconds (60 minutes) and can be changed using the FXOS CLI.
To disable this setting, set the absolute session timeout value to 0.
Cisco FXOS CLI Configuration Guide, 2.2(1)
35
User Management
Configuring the Role Policy for Remote Users
Procedure
Step 1
Enter security mode:
Firepower-chassis # scope security
Step 2
Enter default authorization security mode:
Firepower-chassis /security # scope default-auth
Step 3
Set the absolute session timeout:
Firepower-chassis /security/default-auth # set absolute-session-timeout seconds
Step 4
(Optional) Set the separate console absolute session timeout:
Firepower-chassis /security/default-auth # set con-
con-absolute-session-timeout Serial Console Absolute Session timeout(in secs) seconds
Step 5
(Optional) View the session and absolute session timeout settings:
Firepower-chassis /security/default-auth # show detail
Example:
Default authentication:
Admin Realm: Local
Operational Realm: Local
Web session refresh period(in secs): 600
Session timeout(in secs) for web, ssh, telnet sessions: 600
Absolute Session timeout(in secs) for web, ssh, telnet sessions: 3600
Serial Console Session timeout(in secs): 600
Serial Console Absolute Session timeout(in secs): 3600
Admin Authentication server group:
Operational Authentication server group:
Use of 2nd factor: No
Configuring the Role Policy for Remote Users
By default, read-only access is granted to all users logging in to Firepower Chassis Manager or the FXOS
CLI from a remote server using the LDAP, RADIUS, or TACACS protocols. For security reasons, it might be desirable to restrict access to those users matching an established user role.
You can configure the role policy for remote users in the following ways:
assign-default-role
When a user attempts to log in and the remote authentication provider does not supply a user role with the authentication information, the user is allowed to log in with a read-only user role.
This is the default behavior.
36
Cisco FXOS CLI Configuration Guide, 2.2(1)
User Management
Enabling Password Strength Check for Locally Authenticated Users no-login
When a user attempts to log in and the remote authentication provider does not supply a user role with the authentication information, access is denied.
Procedure
Step 1
Enter security mode:
Firepower-chassis # scope security
Step 2
Specify whether user access to Firepower Chassis Manager and the FXOS CLI should be restricted based on user roles:
Firepower-chassis /security # set remote-user default-role {assign-default-role | no-login}
Step 3
Commit the transaction to the system configuration:
Firepower-chassis /security # commit-buffer
The following example sets the role policy for remote users and commits the transaction:
Firepower-chassis#
scope security
Firepower-chassis /security #
set remote-user default-role no-login
Firepower-chassis /security* #
commit-buffer
Firepower-chassis /security #
Enabling Password Strength Check for Locally Authenticated
Users
If the password strength check is enabled, the Firepower eXtensible Operating System does not permit a user to choose a password that does not meet the guidelines for a strong password (see
on page 29 ).
Procedure
Step 1
Enter security mode:
Firepower-chassis # scope security
Step 2
Specify whether the password strength check is enabled or disabled:
Firepower-chassis /security # set enforce-strong-password {yes | no}
The following example enables the password strength check:
Firepower-chassis#
scope security
Firepower-chassis /security #
set enforce-strong-password yes
Firepower-chassis /security* #
commit-buffer
Firepower-chassis /security #
Cisco FXOS CLI Configuration Guide, 2.2(1)
37
User Management
Set the Maximum Number of Login Attempts
Set the Maximum Number of Login Attempts
You can configure the maximum number of failed login attempts allowed before a user is locked out of the
FXOS chassis for a specified amount of time. If a user exceeds the set maximum number of login attempts, the user is locked out of the system. No notification appears indicating that the user is locked out. In this event, the user must wait the specified amount of time before attempting to log in.
Perform these steps to configure the maximum number of login attempts.
Note
• All types of user accounts (including admin) are locked out of the system after exceeding the maximum number of login attempts.
• The default maximum number of unsuccessful login attempts is 0. The default amount of time the user is locked out of the system after exceeding the maximum number of login attemps is 15 minutes
(1800 seconds).
• For steps to view a user's lockout status and to clear the user’s locked out state, see
User Lockout Status, on page 39
.
This option is one of a number offered for achieving Common Criteria certification compliance on your system. For more information, see
Security Certifications Compliance, on page 57
.
Procedure
Step 1
From the FXOS CLI, enter security mode:
scope system scope security
Step 2
Set the maximum number of unsuccessful login attempts.
set max-login-attempts
max_login
The max_login value is any integer from 0-10.
Step 3
Specify the amount of time (in seconds) the user should remain locked out of the system after reaching the maximum number of login attempts:
set user-account-unlock-time
unlock_time
Step 4
Commit the configuration:
commit-buffer
38
Cisco FXOS CLI Configuration Guide, 2.2(1)
User Management
View and Clear User Lockout Status
View and Clear User Lockout Status
Admin users can view and clear the locked out status of users that have been locked out of the FXOS chassis after exceeding the maximum number of failed login attempts specified in the Maximum Number of Login
Attempts CLI setting. For more information, see
Set the Maximum Number of Login Attempts, on page 38
.
Procedure
Step 1
From the FXOS CLI, enter security mode:
scope system scope security
Step 2
Display the user information (including lockout status) of the user in question:
Firepower-chassis /security # show local-user user detail
Example:
Local User user:
First Name:
Last Name:
Email:
Phone:
Expiration: Never
Password:
User lock status: Locked
Account status: Active
User Roles:
Name: read-only
User SSH public key:
Step 3
(Optional) Clear the user's lock out status:
Firepower-chassis /security # scope local-user user
Firepower-chassis /security/local-user # clear lock-status
Configuring the Maximum Number of Password Changes for a
Change Interval
Procedure
Step 1
Enter security mode:
Firepower-chassis # scope security
Step 2
Enter password profile security mode:
Cisco FXOS CLI Configuration Guide, 2.2(1)
39
User Management
Configure Minimum Password Length Check
Firepower-chassis /security # scope password-profile
Step 3
Restrict the number of password changes a locally authenticated user can make within a given number of hours:
Firepower-chassis /security/password-profile # set change-during-interval enable
Step 4
Specify the maximum number of times a locally authenticated user can change his or her password during the Change Interval:
Firepower-chassis /security/password-profile # set change-count pass-change-num
This value can be anywhere from 0 to 10.
Step 5
Specify the maximum number of hours over which the number of password changes specified in the Change
Count field are enforced:
Firepower-chassis /security/password-profile # set change-interval num-of-hours
This value can be anywhere from 1 to 745 hours.
For example, if this field is set to 48 and the Change Count field is set to 2, a locally authenticated user can make no more than 2 password changes within a 48 hour period.
Step 6
Commit the transaction to the system configuration:
Firepower-chassis /security/password-profile # commit-buffer
The following example enables the change during interval option, sets the change count to 5, sets the change interval to 72 hours, and commits the transaction:
Firepower-chassis #
scope security
Firepower-chassis /security #
scope password-profile
Firepower-chassis /security/password-profile #
set change-during-interval enable
Firepower-chassis /security/password-profile* #
set change-count 5
Firepower-chassis /security/password-profile* #
set change-interval 72
Firepower-chassis /security/password-profile* #
commit-buffer
Firepower-chassis /security/password-profile #
Configure Minimum Password Length Check
If you enable minimum password length check, you must create passwords with the specified minimum number of characters. For example, if the min_length option is set to 15, you must create passwords using 15 characters or more. This option is one of a number that allow for Common Criteria certification compliance on your system. For more information, see
Security Certifications Compliance, on page 57
.
Perform these steps to configure the minimum password length check.
Procedure
Step 1
From the FXOS CLI, enter security mode:
Step 2 scope system scope security
Step 3
Enter password profile security mode:
scope password-profile
Step 4
Specify the minimum password length:
40
Cisco FXOS CLI Configuration Guide, 2.2(1)
User Management
Configuring a No Change Interval for Passwords
set min-password-length min_length
Step 5
Commit the configuration:
commit-buffer
Configuring a No Change Interval for Passwords
Procedure
Step 1
Enter security mode:
Firepower-chassis # scope security
Step 2
Enter password profile security mode:
Firepower-chassis /security # scope password-profile
Step 3
Disable the change during interval feature:
Firepower-chassis /security/password-profile # set change-during-interval disable
Step 4
Specify the minimum number of hours that a locally authenticated user must wait before changing a newly created password:
Firepower-chassis /security/password-profile # set no-change-interval min-num-hours
This value can be anywhere from 1 to 745 hours.
This interval is ignored if the Change During Interval property is not set to Disable.
Step 5
Commit the transaction to the system configuration:
Firepower-chassis /security/password-profile # commit-buffer
The following example disables the change during interval option, sets the no change interval to 72 hours, and commits the transaction:
Firepower-chassis #
scope security
Firepower-chassis /security #
scope password-profile
Firepower-chassis /security/password-profile #
set change-during-interval disable
Firepower-chassis /security/password-profile* #
set no-change-interval 72
Firepower-chassis /security/password-profile* #
commit-buffer
Firepower-chassis /security/password-profile #
Configuring the Password History Count
Procedure
Step 1
Enter security mode:
Firepower-chassis # scope security
Step 2
Enter password profile security mode:
Cisco FXOS CLI Configuration Guide, 2.2(1)
41
User Management
Creating a Local User Account
Firepower-chassis /security # scope password-profile
Step 3
Specify the number of unique passwords that a locally authenticated user must create before that user can reuse a previously used password:
Firepower-chassis /security/password-profile # set history-count num-of-passwords
This value can be anywhere from 0 to 15.
By default, the History Count field is set to 0, which disables the history count and allows users to reuse previously used passwords at any time.
Step 4
Commit the transaction to the system configuration:
Firepower-chassis /security/password-profile # commit-buffer
The following example configures the password history count and commits the transaction:
Firepower-chassis #
scope security
Firepower-chassis /security #
scope password-profile
Firepower-chassis /security/password-profile #
set history-count 5
Firepower-chassis /security/password-profile* #
commit-buffer
Firepower-chassis /security/password-profile #
Creating a Local User Account
Procedure
Step 1
Enter security mode:
Firepower-chassis# scope security
Step 2
Create the user account:
Firepower-chassis /security # create local-user local-user-name where local-user-name is the account name to be used when logging into this account. This name must be unique and meet the guidelines and restrictions for user account names (see
page 28 ).
After you create the user, the login ID cannot be changed. You must delete the user account and create a new one.
Step 3
Specify whether the local user account is enabled or disabled:
Firepower-chassis /security/local-user # set account-status {active| inactive}
Step 4
Set the password for the user account:
Firepower-chassis /security/local-user # set password
Enter a password: password
Confirm the password: password
If password strength check is enabled, a user's password must be strong and the Firepower eXtensible Operating
System rejects any password that does not meet the strength check requirements (see
on page 29 ).
Step 5
(Optional) Specify the first name of the user:
Firepower-chassis /security/local-user # set firstname first-name
42
Cisco FXOS CLI Configuration Guide, 2.2(1)
User Management
Creating a Local User Account
Step 6
(Optional) Specify the last name of the user:
Firepower-chassis /security/local-user # set lastname last-name
Step 7
(Optional) Specify the date that the user account expires. The month argument is the first three letters of the month name.
Firepower-chassis /security/local-user # set expiration month day-of-month year
Note
After you configure a user account with an expiration date, you cannot reconfigure the account to not expire. You can, however, configure the account with the latest expiration date available.
Step 8
(Optional) Specify the user e-mail address.
Firepower-chassis /security/local-user # set email email-addr
Step 9
(Optional) Specify the user phone number.
Firepower-chassis /security/local-user # set phone phone-num
Step 10 (Optional) Specify the SSH key used for passwordless access.
Firepower-chassis /security/local-user # set sshkey ssh-key
Step 11 All users are assigned the read-only role by default and this role cannot be removed. For each additional role that you want to assign to the user:
Firepower-chassis /security/local-user # create role role-name where role-name is the role that represents the privileges you want to assign to the user account (see
).
Note
Changes in user roles and privileges do not take effect until the next time the user logs in. If a user is logged in when you assign a new role to or remove an existing role from a user account, the active session continues with the previous roles and privileges.
Step 12 To remove an assigned role from the user:
Firepower-chassis /security/local-user # delete role role-name
Note
All users are assigned the read-only role by default and this role cannot be removed.
Step 13 Commit the transaction.
Firepower-chassis security/local-user # commit-buffer
The following example creates the user account named kikipopo, enables the user account, sets the password to foo12345, assigns the admin user role, and commits the transaction:
Firepower-chassis#
scope security
Firepower-chassis /security #
create local-user kikipopo
Firepower-chassis /security/local-user* #
set account-status active
Firepower-chassis /security/local-user* #
set password
Enter a password:
Confirm the password:
Firepower-chassis /security/local-user* #
create role admin
Firepower-chassis /security/local-user* #
commit-buffer
Firepower-chassis /security/local-user #
The following example creates the user account named lincey, enables the user account, sets an OpenSSH key for passwordless access, assigns the aaa and operations user roles, and commits the transaction.
Firepower-chassis#
scope security
Firepower-chassis /security #
create local-user lincey
Firepower-chassis /security/local-user* #
set account-status active
Firepower-chassis /security/local-user* #
set sshkey "ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAIEAuo9VQ2CmWBI9/S1f30klCWjnV3lgdXMzO0WUl5iPw85lkdQqap+NFuNmHcb4K iaQB8X/PDdmtlxQQcawclj+k8f4VcOelBxlsGk5luq5ls1ob1VOIEwcKEL/h5lrdbNlI8y3SS9I/gGiBZ9ARlop9LDpD m8HPh2LOgyH7Ei1MI8="
Cisco FXOS CLI Configuration Guide, 2.2(1)
43
User Management
Deleting a Local User Account
Firepower-chassis /security/local-user* #
create role aaa
Firepower-chassis /security/local-user* #
create role operations
Firepower-chassis /security/local-user* #
commit-buffer
Firepower-chassis /security/local-user #
The following example creates the user account named jforlenz, enables the user account, sets a Secure SSH key for passwordless access, and commits the transaction.
Firepower-chassis#
scope security
Firepower-chassis /security #
create local-user jforlenz
Firepower-chassis /security/local-user* #
set account-status active
Firepower-chassis /security/local-user* #
set sshkey
Enter lines one at a time. Enter ENDOFBUF to finish. Press ^C to abort.
User's SSH key:
>
---- BEGIN SSH2 PUBLIC KEY ----
>
AAAAB3NzaC1yc2EAAAABIwAAAIEAuo9VQ2CmWBI9/S1f30klCWjnV3lgdXMzO0WUl5iPw8
>
5lkdQqap+NFuNmHcb4KiaQB8X/PDdmtlxQQcawclj+k8f4VcOelBxlsGk5luq5ls1ob1VO
>
IEwcKEL/h5lrdbNlI8y3SS9I/gGiBZ9ARlop9LDpDm8HPh2LOgyH7Ei1MI8=
>
---- END SSH2 PUBLIC KEY ----
>
ENDOFBUF
Firepower-chassis /security/local-user* #
commit-buffer
Firepower-chassis /security/local-user #
Deleting a Local User Account
Procedure
Step 1
Enter security mode:
Firepower-chassis# scope security
Step 2
Delete the local-user account:
Firepower-chassis /security # delete local-user local-user-name
Step 3
Commit the transaction to the system configuration:
Firepower-chassis /security # commit-buffer
The following example deletes the foo user account and commits the transaction:
Firepower-chassis#
scope security
Firepower-chassis /security #
delete local-user foo
Firepower-chassis /security* #
commit-buffer
Firepower-chassis /security #
Activating or Deactivating a Local User Account
You must be a user with admin or AAA privileges to activate or deactivate a local user account.
Procedure
Step 1
Enter security mode:
Firepower-chassis# scope security
Step 2
Enter local-user security mode for the user you want to activate or deactivate:
44
Cisco FXOS CLI Configuration Guide, 2.2(1)
User Management
Clearing the Password History for a Locally Authenticated User
Firepower-chassis /security # scope local-user local-user-name
Step 3
Specify whether the local user account is active or inactive:
Firepower-chassis /security/local-user # set account-status {active | inactive}
Note
The admin user account is always set to active. It cannot be modified.
The following example enables a local user account called accounting:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope local-user accounting
Firepower-chassis /security/local-user #
set account-status active
Clearing the Password History for a Locally Authenticated User
Procedure
Step 1
Enter security mode:
Firepower-chassis # scope security
Step 2
Enter local user security mode for the specified user account:
Firepower-chassis /security # scope local-user user-name
Step 3
Clear the password history for the specified user account:
Firepower-chassis /security/local-user # clear password-history
Step 4
Commit the transaction to the system configuration:
Firepower-chassis /security/local-user # commit-buffer
The following example configures the password history count and commits the transaction:
Firepower-chassis #
scope security
Firepower-chassis /security #
scope local-user admin
Firepower-chassis /security/local-user #
clear password-history
Firepower-chassis /security/local-user* #
commit-buffer
Firepower-chassis /security/local-user #
Cisco FXOS CLI Configuration Guide, 2.2(1)
45
Clearing the Password History for a Locally Authenticated User
User Management
46
Cisco FXOS CLI Configuration Guide, 2.2(1)
C H A P T E R
6
Image Management
•
About Image Management, page 47
•
Downloading Images from Cisco.com, page 48
•
Downloading a Firepower eXtensible Operating System Software Image to the FXOS chassis, page
•
Verifying the Integrity of an Image, page 49
•
Upgrading the Firepower eXtensible Operating System Platform Bundle, page 50
•
Downloading a Logical Device Software Image to the FXOS chassis, page 51
•
Updating the Image Version for a Logical Device, page 53
•
About Image Management
The FXOS chassis uses two basic types of images:
Note
All images are digitally signed and validated through Secure Boot. Do not modify the image in any way or you will receive a validation error.
• Platform Bundle—The Firepower platform bundle is a collection of multiple independent images that operate on the Firepower Supervisor and Firepower security module/engine. The platform bundle is a
Firepower eXtensible Operating System software package.
• Application—Application images are the software images you want to deploy on the security module/engine of the FXOS chassis. Application images are delivered as Cisco Secure Package files
(CSP) and are stored on the supervisor until deployed to a security module/engine as part of logical device creation or in preparation for later logical device creation. You can have multiple different versions of the same application image type stored on the Firepower Supervisor.
Cisco FXOS CLI Configuration Guide, 2.2(1)
47
Image Management
Downloading Images from Cisco.com
Note
If you are upgrading both the Platform Bundle image and one or more Application images, you must upgrade the Platform Bundle first.
Downloading Images from Cisco.com
Before You Begin
You must have a Cisco.com account.
Procedure
Step 1
Using a web browser, navigate to http://www.cisco.com/go/firepower9300-software or http://www.cisco.com/ go/firepower4100-software .
The software download page for the FXOS chassis is opened in the browser.
Step 2
Find and then download the appropriate software image to your local computer.
Downloading a Firepower eXtensible Operating System
Software Image to the FXOS chassis
You can use FTP, SCP, SFTP, or TFTP to copy the FXOS software image to the FXOS chassis.
Before You Begin
Collect the following information that you will need to import a configuration file:
• IP address and authentication credentials for the server from which you are copying the image
• Fully qualified name of the FXOS image file
Procedure
Step 1
Enter firmware mode:
Firepower-chassis # scope firmware
Step 2
Download the FXOS software image:
Firepower-chassis /firmware # download image URL
Specify the URL for the file being imported using one of the following syntax:
• ftp://username@hostname/path/image_name
• scp://username@hostname/path/image_name
• sftp://username@hostname/path/image_name
48
Cisco FXOS CLI Configuration Guide, 2.2(1)
Image Management
Verifying the Integrity of an Image
• tftp://hostname:port-num/path/image_name
Step 3
To monitor the download process:
Firepower-chassis /firmware # show package image_name detail
The following example copies an image using the SCP protocol:
Firepower-chassis #
scope firmware
Firepower-chassis /firmware #
download image scp://[email protected]/images/fxos-k9.1.1.1.119.SPA
Firepower-chassis /firmware #
show package fxos-k9.1.1.1.119.SPA detail
Download task:
File Name: fxos-k9.1.1.1.119.SPA
Protocol: scp
Server: 192.168.1.1
Userid:
Path:
Downloaded Image Size (KB): 5120
State: Downloading
Current Task: downloading image fxos-k9.1.1.1.119.SPA from
192.168.1.1(FSM-STAGE:sam:dme:FirmwareDownloaderDownload:Local)
Verifying the Integrity of an Image
The integrity of the image is automatically verified when a new image is added to the FXOS chassis. If needed, you can use the following procedure to manually verify the integrity of an image.
Procedure
Step 1
Connect to the FXOS CLI (see
Accessing the FXOS CLI, on page 13
).
Step 2
Enter firmware mode:
Firepower-chassis# scope firmware
Step 3
List images:
Firepower-chassis /firmware # show package
Step 4
Verify the image:
Firepower-chassis /firmware # verify platform-pack version version_number
version_number is the version number of the FXOS platform bundle you are verifying--for example, 1.1(2.51).
Step 5
The system will warn you that verification could take several minutes.
Enter yes to confirm that you want to proceed with verification.
Step 6
To check the status of the image verification:
Firepower-chassis /firmware # show validate-task
Cisco FXOS CLI Configuration Guide, 2.2(1)
49
Image Management
Upgrading the Firepower eXtensible Operating System Platform Bundle
Upgrading the Firepower eXtensible Operating System Platform
Bundle
Before You Begin
Download the platform bundle software image from Cisco.com (see
Downloading Images from Cisco.com,
on page 48 ) and then download that image to the FXOS chassis (see
Downloading a Logical Device Software
Image to the FXOS chassis, on page 51
).
Note
The upgrade process typically takes between 20 and 30 minutes.
If you are upgrading a Firepower 9300 or Firepower 4100 Series security appliance that is running a standalone logical device or if you are upgrading a Firepower 9300 security appliance that is running an intra-chassis cluster, traffic will not traverse through the device while it is upgrading.
If you are upgrading Firepower 9300 or a Firepower 4100 Series security appliance that is part of an inter-chassis cluster, traffic will not traverse through the device being upgraded while it is upgrading.
However, the other devices in the cluster will continue to pass traffic.
Procedure
Step 1
Connect to the FXOS CLI (see
Accessing the FXOS CLI, on page 13
).
Step 2
Enter firmware mode:
Firepower-chassis# scope firmware
Step 3
Enter auto-install mode:
Firepower-chassis /firmware # scope auto-install
Step 4
Install the FXOS platform bundle:
Firepower-chassis /firmware/auto-install # install platform platform-vers version_number
version_number is the version number of the FXOS platform bundle you are installing--for example, 1.1(2.51).
Step 5
The system will first verify the software package that you want to install. It will inform you of any incompatibility between currently installed applications and the specified FXOS platform software package.
It will also warn you that any existing sessions will be terminated and that the system will need to be rebooted as part of the upgrade.
Enter yes to confirm that you want to proceed with verification.
Step 6
Enter yes to confirm that you want to proceed with installation, or enter no to cancel the installation.
The Firepower eXtensible Operating System unpacks the bundle and upgrades/reloads the components.
Step 7
To monitor the upgrade process: a) Enter scope firmware.
b) Enter scope auto-install.
c) Enter show fsm status expand.
50
Cisco FXOS CLI Configuration Guide, 2.2(1)
Image Management
Downloading a Logical Device Software Image to the FXOS chassis
Downloading a Logical Device Software Image to the FXOS chassis
You can use FTP, SCP, SFTP, or TFTP to copy the logical device software image to the FXOS chassis.
Before You Begin
Collect the following information that you will need to import a configuration file:
• IP address and authentication credentials for the server from which you are copying the image
• Fully qualified name of the software image file
Procedure
Step 1
Enter Security Services mode:
Firepower-chassis # scope ssa
Step 2
Enter Application Software mode:
Firepower-chassis /ssa # scope app-software
Step 3
Download the logical device software image:
Firepower-chassis /ssa/app-software # download image URL
Specify the URL for the file being imported using one of the following syntax:
• ftp://username@hostname/path
• scp://username@hostname/path
• sftp://username@hostname/path
• tftp://hostname:port-num/path
Step 4
To monitor the download process:
Firepower-chassis /ssa/app-software # show download-task
Step 5
To view the downloaded applications:
Firepower-chassis /ssa/app-software # up
Firepower-chassis /ssa # show app
Step 6
To view details for a specific application:
Firepower-chassis /ssa # scope app application_type image_version
Firepower-chassis /ssa/app # show expand
The following example copies an image using the SCP protocol:
Firepower-chassis #
scope ssa
Firepower-chassis /ssa #
scope app-software
Firepower-chassis /ssa/app-software #
download image scp://[email protected]/images/cisco-asa.9.4.1.65.csp
Firepower-chassis /ssa/app-software #
show download-task
Cisco FXOS CLI Configuration Guide, 2.2(1)
51
Image Management
Downloading a Logical Device Software Image to the FXOS chassis
Downloads for Application Software:
File Name Protocol Server Userid State
------------------------------ ---------- -------------------- --------------- ----cisco-asa.9.4.1.65.csp
Scp 192.168.1.1
user Downloaded
Firepower-chassis /ssa/app-software #
up
Firepower-chassis /ssa #
show app
Application:
Name Version Description Author Deploy Type CSP Type Is Default App
---------- ---------- ----------- ---------- ----------- ----------- -------------asa asa
9.4.1.41
N/A
9.4.1.65
N/A
Native
Native
Application No
Application Yes
Firepower-chassis /ssa # scope app asa 9.4.1.65
Firepower-chassis /ssa/app # show expand
Application:
Name: asa
Version: 9.4.1.65
Description: N/A
Author:
Deploy Type: Native
CSP Type: Application
Is Default App: Yes
App Attribute Key for the Application:
App Attribute Key Description
----------------- ----------cluster-role mgmt-ip mgmt-url
This is the role of the blade in the cluster
This is the IP for the management interface
This is the management URL for this application
Net Mgmt Bootstrap Key for the Application:
Bootstrap Key Key Data Type Is the Key Secret Description
------------- ------------- ----------------- -----------
PASSWORD String Yes The admin user password.
Port Requirement for the Application:
Port Type: Data
Max Ports: 120
Min Ports: 1
Port Type: Mgmt
Max Ports: 1
Min Ports: 1
Mgmt Port Sub Type for the Application:
Management Sub Type
-------------------
Default
Port Type: Cluster
Max Ports: 1
Min Ports: 0
Firepower-chassis /ssa/app #
52
Cisco FXOS CLI Configuration Guide, 2.2(1)
Image Management
Updating the Image Version for a Logical Device
Updating the Image Version for a Logical Device
Before You Begin
Note
After initial creation of a Firepower Threat Defense logical device, you do not upgrade the Firepower
Threat Defense logical device using Firepower Chassis Manager or the FXOS CLI. To upgrade a Firepower
Threat Defense logical device, you must use Firepower Management Center. See the Firepower System
Release Notes for more information: http://www.cisco.com/c/en/us/support/security/defense-center/ products-release-notes-list.html
.
Also, note that any updates to the Firepower Threat Defense logical device will not be reflected on the
Logical Devices > Edit and System > Updates pages in Firepower Chassis Manager. On these pages, the version shown indicates the software version (CSP image) that was used to create the Firepower Threat
Defense logical device.
Download the application image you want to use for the logical device from Cisco.com (see
Images from Cisco.com, on page 48
) and then download that image to the FXOS chassis (see
Downloading a Logical Device Software Image to the FXOS chassis, on page 51
).
If you are upgrading both the Platform Bundle image and one or more Application images, you must upgrade the Platform Bundle first.
Procedure
Step 1
Enter Security Services mode:
Firepower-chassis # scope ssa
Step 2
Set the scope to the security module you are updating:
Firepower-chassis /ssa # scope slot slot_number
Step 3
Set the scope to the application you are updating:
Firepower-chassis /ssa/slot # scope app-instance app_template
Step 4
Set the Startup version to the version you want to update:
Firepower-chassis /ssa/slot/app-instance # set startup-version version_number
Step 5
Commit the configuration:
commit-buffer
Commits the transaction to the system configuration. The application image is updated and the application restarts.
The following example updates the software image for an ASA running on security module 1. Notice that you can use the show command to view the update status.
Firepower-chassis#
scope ssa
Firepower-chassis /ssa #
scope slot 1
Firepower-chassis /ssa/slot #
scope app-instance asa
Firepower-chassis /ssa/slot/app-instance #
set startup-version 9.4.1.65
Firepower-chassis /ssa/slot/app-instance* #
show configuration pending
enter app-instance asa
Cisco FXOS CLI Configuration Guide, 2.2(1)
53
Image Management
Firmware Upgrade
+ exit set startup-version 9.4.1.65
Firepower-chassis /ssa/slot/app-instance* #
commit-buffer
Firepower-chassis /ssa/slot/app-instance #
show
Application Instance:
Application Name Admin State Operational State Running Version Startup Version
---------------- ----------- ----------------- --------------- --------------asa Enabled Updating 9.4.1.41
9.4.1.65
Firepower-chassis /ssa/slot/app-instance #
Firepower-chassis /ssa/slot/app-instance #
show
Application Instance:
Application Name Admin State Operational State Running Version Startup Version
---------------- ----------- ----------------- --------------- --------------asa Enabled Online 9.4.1.65
9.4.1.65
Firepower-chassis /ssa/slot/app-instance #
Firmware Upgrade
Use the following procedure to upgrade the firmware on your FXOS chassis.
Procedure
Step 1
Using a web browser, navigate to http://www.cisco.com/go/firepower9300-software or http://www.cisco.com/ go/firepower4100-software .
The software download page for the FXOS chassis is opened in the browser.
Step 2
Find and then download the appropriate firmware package from Cisco.com to a server that you can access from the FXOS chassis.
Step 3
On the FXOS chassis, enter firmware mode: fxos-chassis # scope firmware
Step 4
Download the FXOS firmware image to the FXOS chassis: fxos-chassis /firmware # download image URL
Specify the URL for the file being imported using one of the following syntax:
• ftp:// username@hostname / path
• scp:// username@hostname / path
• sftp:// username@hostname / path
• tftp:// hostname : port-num / path
Step 5
To monitor the download process: fxos-chassis /firmware # show download task image_name detail
Step 6
After the download has completed, you can enter the following command to view the contents of the firmware package: fxos-chassis /firmware # show package image_name expand
Step 7
You can enter the following command to view the version number of the firmware package: fxos-chassis /firmware # show package
This version number is used in the following step when installing the firmware package.
54
Cisco FXOS CLI Configuration Guide, 2.2(1)
Image Management
Firmware Upgrade
Step 8
To install the firmware package: a) Enter firmware-install mode: fxos-chassis /firmware # scope firmware-install b) Install the firmware package: fxos-chassis /firmware/firmware-install # install firmware pack-version version_number
The system will verify the firmware package and will notify you that the verification process can take several minutes to complete.
c) Enter yes to proceed with the verification.
After verifying the firmware package, the system will notify you that the installation process can take several minutes to complete and that the system will reboot during the update process.
d) Enter yes to proceed with the installation. Do not power cycle the FXOS chassis during the upgrade process.
Step 9
To monitor the upgrade process: fxos-chassis /firmware/firmware-install # show detail
Step 10 After the installation has completed, you can enter the following commands to view the current firmware version: fxos-chassis /firmware/firmware-install # top fxos-chassis # scope chassis 1 fxos-chassis /firmware # show sup version
The following example upgrades the firmware to version 1.0.10: fxos-chassis#
scope firmware
fxos-chassis /firmware #
download image tftp://10.10.10.1/fxos-k9-fpr9k-firmware.1.0.10.SPA
fxos-chassis /firmware #
show download-task fxos-k9-fpr9k-firmware.1.0.10.SPA detail
Download task:
File Name: fxos-k9-fpr9k-firmware.1.0.10.SPA
Protocol: Tftp
Server: 10.10.10.1
Port: 0
Userid:
Path:
Downloaded Image Size (KB): 2104
Time stamp: 2015-12-04T23:51:57.846
State: Downloading
Transfer Rate (KB/s): 263.000000
Current Task: unpacking image fxos-k9-fpr9k-firmware.1.0.10.SPA on primary(
FSM-STAGE:sam:dme:FirmwareDownloaderDownload:UnpackLocal) fxos-chassis /firmware #
show package fxos-k9-fpr9k-firmware.1.0.10.SPA expand
Package fxos-k9-fpr9k-firmware.1.0.10.SPA:
Images: fxos-k9-fpr9k-fpga.1.0.5.bin
fxos-k9-fpr9k-rommon.1.0.10.bin
fxos-chassis /firmware #
show package
Name Version
--------------------------------------------- ------fxos-k9-fpr9k-firmware.1.0.10.SPA
1.0.10
fxos-chassis /firmware #
scope firmware-install
fxos-chassis /firmware/firmware-install #
install firmware pack-version 1.0.10
Verifying FXOS firmware package 1.0.10. Verification could take several minutes.
Cisco FXOS CLI Configuration Guide, 2.2(1)
55
Image Management
Firmware Upgrade
Do you want to proceed? (yes/no):yes
FXOS SUP ROMMON: Upgrade from 1.0.10 to 1.0.10
FXOS SUP FPGA : Upgrade from 1.04 to 1.05
This operation upgrades SUP firmware on Security Platform.
Here is the checklist of things that are recommended before starting the install operation
(1) Review current critical/major faults
(2) Initiate a configuration backup
Attention:
The system will be reboot to upgrade the SUP firmware.
The upgrade operation will take several minutes to complete.
PLEASE DO NOT POWER RECYCLE DURING THE UPGRADE.
Do you want to proceed? (yes/no):yes
Upgrading FXOS SUP firmware software package version 1.0.10
command executed
56
Cisco FXOS CLI Configuration Guide, 2.2(1)
C H A P T E R
7
Security Certifications Compliance
•
Security Certifications Compliance, page 57
•
•
Enable Common Criteria Mode, page 59
•
Generate the SSH Host Key, page 59
•
Configure IPSec Secure Channel, page 60
•
Configure Static CRL for a Trustpoint, page 65
•
About the Certificate Revocation List Check, page 65
•
Configure CRL Periodic Download, page 70
•
Enable NTP Server Authentication, page 71
•
Set the LDAP Key Ring Certificate, page 72
•
Configure the IP Access List, page 73
•
Enable Client Certificate Authentication, page 74
Security Certifications Compliance
United States federal government agencies are sometimes required to use only equipment and software complying with security standards established by the U.S. Department of Defense and global certification organizations. The FXOS chassis supports compliance with several of these security certification standards.
See the following topics for steps to enable features that support compliance with these standards:
•
•
Enable Common Criteria Mode, on page 59
•
Configure IPSec Secure Channel, on page 60
•
Configure Static CRL for a Trustpoint, on page 65
•
About the Certificate Revocation List Check, on page 65
•
Configure CRL Periodic Download, on page 70
Cisco FXOS CLI Configuration Guide, 2.2(1)
57
Security Certifications Compliance
Enable FIPS Mode
•
Enable NTP Server Authentication, on page 71
•
Set the LDAP Key Ring Certificate, on page 72
•
Configure the IP Access List, on page 73
•
Enable Client Certificate Authentication, on page 74
•
Configure Minimum Password Length Check, on page 40
•
Set the Maximum Number of Login Attempts, on page 38
•
Note
Note that these topics discuss enabling certifications compliance on the FXOS chassis only. Enabling certification compliance on the FXOS chassis does not automatically propagate compliance to any of its attached logical devices.
Enable FIPS Mode
Perform these steps to enable FIPS mode on your FXOS chassis.
Procedure
Step 1
From the FXOS CLI, enter the security mode:
scope system scope security
Step 2
Enable FIPS mode:
enable fips-mode
Step 3
Commit the configuration:
commit-buffer
Step 4
Reboot the system:
connect local-mgmt reboot
What to Do Next
Prior to FXOS release 2.0.1, the existing SSH host key created during first-time setup of a device was hard coded to 1024 bits. To comply with FIPS and Common Criteria certification requirements, you must destroy this old host key and generate a new one using the procedure detailed in
Generate the SSH Host Key, on page
59 . If you do not perform these additional steps, you will not be able to connect to the Supervisor using SSH after the device has rebooted with FIPS mode enabled. If you performed initial setup using FXOS 2.0.1 or later, you do not have to generate a new host key.
58
Cisco FXOS CLI Configuration Guide, 2.2(1)
Security Certifications Compliance
Enable Common Criteria Mode
Enable Common Criteria Mode
Perform these steps to enable Common Criteria mode on your FXOS chassis.
Procedure
Step 1
From the FXOS CLI, enter the security mode:
scope system scope security
Step 2
Enable Common Criteria mode:
enable cc-mode
Step 3
Commit the configuration:
commit-buffer
Step 4
Reboot the system:
connect local-mgmt reboot
What to Do Next
Prior to FXOS release 2.0.1, the existing SSH host key created during first-time setup of a device was hard coded to 1024 bits. To comply with FIPS and Common Criteria certification requirements, you must destroy this old host key and generate a new one using the procedure detailed in
page 59
. If you do not perform these additional steps, you will not be able to connect to the Supervisor using
SSH after the device has rebooted with Common Criteria mode enabled. If you performed initial setup using
FXOS 2.0.1 or later, you do not have to generate a new host key.
Generate the SSH Host Key
Prior to FXOS release 2.0.1, the existing SSH host key created during initial setup of a device was hard-coded to 1024 bits. To comply with FIPS and Common Criteria certification, you must destroy this old host key and generate a new one. See
or
Enable Common Criteria Mode, on page 59
for more information.
Perform these steps to destroy the old SSH host key and generate a new certifications-compliant one.
Procedure
Step 1
From the FXOS CLI, enter services mode:
scope system scope services
Step 2
Delete the SSH host key:
delete ssh-server host-key
Cisco FXOS CLI Configuration Guide, 2.2(1)
59
Security Certifications Compliance
Configure IPSec Secure Channel
Step 3
Commit the configuration:
commit-buffer
Step 4
Set the SSH host key size to 2048 bits:
set ssh-server host-key rsa 2048
Step 5
Commit the configuration:
commit-buffer
Step 6
Create a new SSH host key:
create ssh-server host-key commit-buffer
Step 7
Confirm the new host key size:
show ssh-server host-key
Host Key Size: 2048
Configure IPSec Secure Channel
You can configure IPSec on your FXOS chassis to provide end-to-end data encryption and authentication service on data packets going through the public network. This option is one of a number offered for achieving
Common Criteria certification compliance on your system. For more information, see
.
Note
If you elect to configure enforcement of matching cryptographic key strength between IKE and SA connections (set sa-strength-enforcement to yes in the below procedure):
If SA enforcement is enabled then when IKE negotiated key size is less then ESP negotiated key size, the connection fails.
then when IKE negotiated key size is large or equal than ESP negotiated key size, SA enforcement check passes and the connection is successful.
If SA enforcement is disabled then SA enforcement check passes and the connection is successful.
Perform these steps to configure an IPSec secure channel.
Procedure
Step 1
From the FXOS CLI, enter security mode:
scope system scope security
60
Cisco FXOS CLI Configuration Guide, 2.2(1)
Security Certifications Compliance
Step 2
Create the keyring:
enter keyring ssp
! create certreq subject-name subject-name ip ip
Step 3
Enter the associated certificate request information:
enter certreq
Step 4
Set the country:
set country country
Step 5
Set the DNS:
set dns dns
Step 6
Set the email:
set e-mail email
Step 7
Set the IP information:
set fi-a-ip fi-a-ip
set fi-a-ipv6 fi-a-ipv6
set fi-b-ip fi-b-ip
set fi-b-ipv6 fi-b-ipv6
set ipv6 ipv6
Step 8
Set the locality:
set locality locality
Step 9
Set the organization name:
set org-name org-name
Step 10 Set the organization unit name:
set org-unit-name org-unit-name
Step 11 Set the password:
! set password
Step 12 Set the state:
set state state
Step 13 Set the subject name for the certreq:
set subject-name subject-name
Step 14 Exit:
exit
Step 15 Set the modulus:
set modulus modulus
Step 16 Set the regeneration for the certificate request:
set regenerate { yes | no }
Step 17 Set the trustpoint:
set trustpoint interca
Step 18 Exit:
Configure IPSec Secure Channel
Cisco FXOS CLI Configuration Guide, 2.2(1)
61
Security Certifications Compliance
Configure IPSec Secure Channel exit
Step 19 Enter the newly created trustpoint:
enter trustpoint interca
Step 20 Generate certificate signing request:
set certchain
Example:
-----BEGIN CERTIFICATE-----
MIIF3TCCA8WgAwIBAgIBADANBgkqhkiG9w0BAQsFADBwMQswCQYDVQQGEwJVUzEL
MAkGA1UECAwCQ0ExDDAKBgNVBAcMA1NKQzEOMAwGA1UECgwFQ2lzY28xDTALBgNV
BAsMBFNUQlUxCzAJBgNVBAMMAkNBMRowGAYJKoZIhvcNAQkBFgtzc3BAc3NwLm5l dDAeFw0xNjEyMDgxOTMzNTJaFw0yNjEyMDYxOTMzNTJaMHAxCzAJBgNVBAYTAlVT
MQswCQYDVQQIDAJDQTEMMAoGA1UEBwwDU0pDMQ4wDAYDVQQKDAVDaXNjbzENMAsG
A1UECwwEU1RCVTELMAkGA1UEAwwCQ0ExGjAYBgkqhkiG9w0BCQEWC3NzcEBzc3Au bmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2ukWyMLQuLqTvhq7 zFb3Oz/iyDG/ui6mrLIYn8wE3E39XcXA1/x9IHCmxFKNJdD7EbsggfOuy0Bj+Y4s
+uZ1VapBXV/JrAie7bNn3ZYrI29yuyOrIqoi9k9gL/oRBzH18BwBwGHBOz3hGrSK
Yc2yhsq9y/6yI3nSuLZm6ybmUKjTa+B4YuhDTz4hl/I9x/J5nbGiab3vLDKss1nO xP9+1+Lc690Vl8/mNPWdjCjDI+U/L9keYs/rbZdRSeXy9kMae42+4FlRHDJjPcSN
Yw1g/gcR2F7QUKRygKckJKXDX2QIiGYSctlSHj18O87o5s/pmQAWWRGkKpfDv3oH cMPgI2T9rC0D8NNcgPXj9PFKfexoGNGwNTO85fK3kjgMOdWbdeMG3EihxEEOUPD0
Fdu0HrTM5lvwb+vr5wE9HsAiMJ8UuujmHqH5mlwyy3Me+cEDHo0hLeNs+AFrqEXQ e9S+KZC/dq/9zOLpRsVqSfJsAuVl/QdPDbWShjflE/fP2Wj01PqXywQydzymVvgE wEZaoFg+mlGJm0+q4RDvnpzEviOYNSAGmOkILh5HQ/eYDcxvd0qbORWb31H32ySl
Ila6UTT9+vnND1f838fxvNvr8nyGD2S/LVaxnZlO4jcSIvtdizbbT8u5B4VcLKIC x0vkqjo6RvNZJ52sUaD9C3UodTUCAwEAAaOBgTB/MC8GA1UdHwQoMCYwJKAioCCG
Hmh0dHA6Ly8xOTIuMTY4LjQuMjkvcm9vdGNhLmNybDAdBgNVHQ4EFgQU7Jg01A74 jpx8U0APk76pVfYQQ5AwHwYDVR0jBBgwFoAU7Jg01A74jpx8U0APk76pVfYQQ5Aw
DAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQsFAAOCAgEAvI8ky2jiXc4wPiMuxIfY
W7DRmszPUWQ7edor7yxuCqzHLVFFOwYRudsyXbv7INR3rJ/X1cRQj9+KidWWVxpo pFahRhzYxVZ10DHKIzGTQS3jiHgrF3Z8ohWbL15L7PEDlrxMBoJvabPeQRgTmY/n
XZJ7qRYbypO3gUMCaCZ12raJc3/DIpBQ29yweCbUkc9qiHKA0IbnvAxoroHWmBld
94LrJCggfMQTuNJQszJiVVsYJfZ+utlDp2QwfdDv7B0JkwTBjdwRSfotEbc5R18n
BNXYHqxuoNMmqbS3KjCLXcH6xIN8t+UkfP89hvJt/fluJ+s/VJSVZWK4tAWvR7wl
QngCKRJW6FYpzeyNBctiJ07wO+Wt4e3KhIjJDYvA9hFixWcVGDf2r6QW5BYbgGOK
DkHb/gdr/bcdLBKN/PtSJ+prSrpBSaA6rJX8D9UmfhqqN/3f+sS1fM4qWORJc6G2 gAcg7AjEQ/0do512vAI8p8idOg/Wv1O17mavzLpcue05cwMCX9fKxKZZ/+7Pk19Y
ZrXS6uMn/CGnViptn0w+uJ1IRj1oulk+/ZyPtBvFHUkFRnhoWj5SMFyds2IaatyI
47N2ViaZBxhU3GICaH+3O+8rs9Kkz9tBZDSnEJVZA6yxaNCVP1bRUO20G3oRTmSx
8iLBjN+BXggxMmG8ssHisgw=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFqDCCA5CgAwIBAgIBBDANBgkqhkiG9w0BAQsFADBwMQswCQYDVQQGEwJVUzEL
MAkGA1UECAwCQ0ExDDAKBgNVBAcMA1NKQzEOMAwGA1UECgwFQ2lzY28xDTALBgNV
BAsMBFNUQlUxCzAJBgNVBAMMAkNBMRowGAYJKoZIhvcNAQkBFgtzc3BAc3NwLm5l dDAeFw0xNjEyMTUyMTM0NTRaFw0yNjEyMTMyMTM0NTRaMHwxCzAJBgNVBAYTAlVT
MQswCQYDVQQIDAJDQTEPMA0GA1UECgwGbmV3c3RnMRAwDgYDVQQLDAduZXdzdGJ1
MRMwEQYDVQQDDAppbnRlcm0xLWNhMSgwJgYJKoZIhvcNAQkBFhlpbnRlcm0xLWNh
QGludGVybTEtY2EubmV0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA wLpNnyEx5I4P8uDoWKWF3IZsegjhLANsodxuAUmhmwKekd0OpZZxHMw1wSO4IBX5
4itJS0xyXFzPmeptG3OXvNqCcsT+4BXl3DoGgPMULccc4NesHeg2z8+q3SPA6uZh iseWNvKfnUjixbQEBtcrWBiSKnZuOz1cpuBn34gtgeFFoCEXN+EZVpPESiancDVh
8pCPlipc/08ZJ3o9GW2j0eHJN84sguIEDL812ROejQvpmfqGUq11stkIIuh+wB+V
VRhUBVG7pV57I6DHeeRp6cDMLXaM3iMTelhdShyo5YUaRJMak/t8kCqhtGXfuLlI
62
Cisco FXOS CLI Configuration Guide, 2.2(1)
Security Certifications Compliance
Configure IPSec Secure Channel
E2AkxKXeeveR9n6cpQd5JiNzCT/t9IQL/T/CCqMICRXLFpLCS9o5S5O2B6QFgcTZ yKR6hsmwe22wpK8QI7/5oWNXlolb96hHJ7RPbG7RXYqmcLiXY/d2j9/RuNoPJawI hLkfhoIdPA28xlnfIB1azCmMmdPcBO6cbUQfCj5hSmk3StVQKgJCjaujz55TGGd1
GjnxDMX9twwz7Ee51895Xmtr24qqaCXJoW/dPhcIIXRdJPMsTJ4yPG0BieuRwd0p i8w/rFwbHzv4C9Fthw1JrRxH1yeHJHrLlZgJ5txSaVUIgrgVCJaf6/jrRRWoRJwt
AzvnzYql2dZPCcEAYgP7JcaQpvdpuDgq++NgBtygiqECAwEAAaNBMD8wDAYDVR0T
BAUwAwEB/zAvBgNVHR8EKDAmMCSgIqAghh5odHRwOi8vMTkyLjE2OC40LjI5L2lu dGVybS5jcmwwDQYJKoZIhvcNAQELBQADggIBAG/XujJh5G5UWo+cwTSitAezWbJA h1dAiXZ/OYWZSxkFRliErKdupLqL0ThjnX/wRFfEXbrBQwm5kWAUUDr97D1Uz+2A
8LC5I8SWKXmyf0jUtsnEQbDZb33oVL7yXJk/A0SF0jihpPheMA+YRazalT9xj9KH
PE7nHCJMbb2ptrHUyvBrKSYrSeEqOpQU2+otnFyV3rS9aelgVjuaWyaWOc3lZ1Oi
CC2tJvY3NnM56j5iesxUCeY/SZ2/ECXN7RRBViLHmA3gFKmWf3xeNiKkxmJCxOaa
UWPC1x2V66I8DG9uUzlWyd79O2dy52aAphAHC6hqlzb6v+gw1Tld7UxaqVd8CD5W
ATjNs+ifkJS1h5ERxHjgcurZXOpR+NWpwF+UDzbMXxx+KAAXCI6ltCd8Pb3wOUC3
PKvwEXaIcCcxGx71eRLpWPZFyEoi4N2NGE9OXRjz0K/KERZgNhsIW3bQMjcw3aX6
OXskEuKgsayctnWyxVqNnqvpuz06kqyubh4+ZgGKZ5LNEXYmGNz3oED1rUN636Tw
SjGAPHgeROzyTFDixCei6aROlGdP/Hwvb0/+uThIe89g8WZ0djTKFUM8uBO3f+II
/cbuyBO1+JrDMq8NkAjxKlJlp1c3WbfCue/qcwtcfUBYZ4i53a56UNF5Ef0rpy/8
B/+07Me/p2y9Luqa
-----END CERTIFICATE-----
ENDOFBUF
Step 21 Show the certificate signing request:
show certreq
Example:
Firepower-chassis# /security/keyring # show certreq
Certificate request subject name: SSP
Certificate request ip address: 192.168.0.111
Certificate request FI A ip address: 0.0.0.0
Certificate request FI B ip address: 0.0.0.0
Certificate request e-mail name:
Certificate request ipv6 address: ::
Certificate request FI A ipv6 address: ::
Certificate request FI B ipv6 address: ::
Certificate request country name: US
State, province or county (full name): CA
Locality name (eg, city): SJC
Organisation name (eg, company): Cisco
Organisational Unit Name (eg, section): Sec
DNS name (subject alternative name):
Request:
-----BEGIN CERTIFICATE REQUEST-----
MIICwTCCAakCAQAwVTELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMQwwCgYDVQQH
DANTSkMxDjAMBgNVBAoMBUNpc2NvMQ0wCwYDVQQLDARTVEJVMQwwCgYDVQQDDANT
U1AwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDq292Rq3t0laoxPbfE p/lTKr6rxFhPqSSbtm6sXer//VZFiDTWODockDItuf4Kja215mIS0RyvEYVeRgAs wbN459wm0BASd8xCjIhsuHDV7yHu539BnvRW6Q2o+gHeSRwckqjClK/tsIxsPkV0
6OduZYXk2bnsLWs6tNk3uzOIT2Q0FcZ1ET66C8fyyKWTrmvcZjDjkMm2nDFsPlX9
39TYPItDkJE3PocqyaCqmT4uobOuvQeLJh/efkBvwhb4BF8vwzRpHWTdjjU5YnR1 qiR4q7j1RmzVFxCDY3IVP/KDBoa5NyCLEUZECP5QCQFDzIRETZwVOKtxUVG0Nljd
K5TxAgMBAAGgJzAlBgkqhkiG9w0BCQ4xGDAWMBQGA1UdEQQNMAuCA1NTUIcEwKgA rjANBgkqhkiG9w0BAQsFAAOCAQEARtRBoInxXkBYNlVeEoFCqKttu3+Hc7UdyoRM
2L2pjx5OHbQICC+8NRVRMYujTnp67BWuUZZl03dGP4/lbN6bC9P3CvkZdKUsJkN0 m1Ye9dgz7MO/KEcosarmoMl9WB8LlweVdt6ycSdJzs9shOxwT6TAZPwL7gq/1ShF
Cisco FXOS CLI Configuration Guide, 2.2(1)
63
Security Certifications Compliance
Configure IPSec Secure Channel
RJh6sq5W9p6E0SjYefK62E7MatRjDjS8DXoxj6gfn9DqK15iVpkK2QqT5rneSGj+
R+20TcUnT0h/S5K/bySEM/3U1gFxQCOzbzPuHkj28kXAVczmTxXEkJBFLVduWNo6
DT3u0xImiPR1sqW1jpMwbhC+ZGDtvgKjKHToagup9+8R9IMcBQ==
-----END CERTIFICATE REQUEST-----
Step 22 Enter IPSec mode:
scope ipsec
Step 23 Set the log verbose level:
set log-level log_level
Step 24 Create and enter an IPSec connection:
enter connection connection_name
Step 25 Set IPSec mode to tunnel or transport:
set mode tunnel_or_transport
Step 26 Set the local IP address:
set local-addr ip_address
Step 27 Set the remote IP address:
set remote-addr ip_address
Step 28 If using tunnel mode, set the remote subnet:
set remote-subnet ip/mask
Step 29 (Optional) Set the remote identity:
set remote-ike-ident remote_identity_name
Step 30 Set the keyring name:
set keyring-name name
Step 31 (Optional) Set the keyring password:
set keyring-passwd passphrase
Step 32 (Optional) Set the IKE-SA lifetime in minutes:
set ike-rekey-time minutes
The minutes value can be any integer between 60-1440, inclusive.
Step 33 (Optional) Set the Child SA lifetime in minutes (30-480):
set esp-rekey-time minutes
The minutes value can be any integer between 30-480, inclusive.
Step 34 (Optional) Set the number of retransmission sequences to perform during initial connect:
set keyringtries retry_number
The retry_number value can be any integer between 1-5, inclusive.
Step 35 (Optional) Enable or disable the certificate revocation list check:
set revoke-policy { relaxed | strict }
Step 36 Enable the connection:
set admin-state enable
Step 37 Reload all connections:
reload-conns
64
Cisco FXOS CLI Configuration Guide, 2.2(1)
Security Certifications Compliance
Configure Static CRL for a Trustpoint
Step 38 (Optional) Add the existing trustpoint name to IPsec:
create authority trustpoint_name
Step 39 Configure the enforcement of matching cryptographic key strength between IKE and SA connections:
set sa-strength-enforcement yes_or_no
Configure Static CRL for a Trustpoint
Revoked certifications are kept in the Certification Revocation List (CRL). Client applications use the CRL to check the authentication of a server. Server applications utilize the CRL to grant or deny access requests from client applications which are no longer trusted.
You can configure your FXOS chassis to validate peer certificates using Certification Revocation List (CRL) information. This option is one of a number offered for achieving Common Criteria certification compliance on your system. For more information, see
Security Certifications Compliance, on page 57
.
Perform these steps to validate peer certificates using CRL information.
Procedure
Step 1
From the FXOS CLI, enter security mode:
scope security
Step 2
Enter trustpoint mode:
scope trustpoint trustname
Step 3
Enter revoke mode:
scope revoke
Step 4
Download the CRL file(s):
import crl protocol://user_id@CA_or_CRL_issuer_IP/tmp/DoDCA1CRL1.crl
Step 5
(Optional) Show the status of the import process of CRL information:
show import-task detail
Step 6
Set the certificate revocation method to CRL-only:
set certrevokemethod {crl}
About the Certificate Revocation List Check
You can configure your Certificate Revocation List (CRL) check mode to be either strict or relaxed in IPSec,
HTTPS, and secure LDAP connections.
Dynamic (non-static) CRL information is harvested from the CDP information of an X.509 certificate, and indicates dynamic CRL information. Static CRL information is downloaded by system administration manually, and indicates local CRL information in the FXOS system. The dynamic CRL information is only processed
Cisco FXOS CLI Configuration Guide, 2.2(1)
65
Security Certifications Compliance
About the Certificate Revocation List Check
against the current processing certificate in the certificate chain. The static CRL is applied to the whole peer certificate chain.
For steps to enable or disable certificate revocation checks for your secure IPSec, LDAP, and HTTPS connections, see
Configure IPSec Secure Channel, on page 60
,
Creating an LDAP Provider, on page 129
and
Configuring HTTPS, on page 124
.
Note
• If the Certificate Revocation Check Mode is set to Strict, static CRL is only applicable when the peer certificate chain has a level of 1 or higher. (For example, when the peer certificate chain only contains the root CA certificate and the peer certificate signed by the root CA.)
• When configuring static CRL for IPSec, the Authority Key Identifier (authkey) field must be present in the imported CRL file. Otherwise, IPSec considers it invalid.
• Static CRL takes precedence over Dynamic CRL from the same issuer. When validating the peer certificate, if a valid (determined) static CRL of the same issuer exists, the CDP in the peer certificate is ignored.
The following tables describe the connection results, depending on your certificate revocation list check setting and certificate validation.
Table 4: Certificate Revocation Check Mode set to Strict without a local static CRL
Without local static CRL LDAP Connection
Checking peer certificate chain
Full certificate chain is required
Checking CDP in peer certificate chain
Full certificate chain is required
CDP checking for Root
CA certificate of the peer certificate chain
Yes
Any certificate validation failure in the peer certificate chain
Connection fails with syslog message
Any certificate revoked in the peer certificate chain
Connection fails with syslog message
One CDP is missing the peer certificate chain
Connection fails with syslog message
IPSec Connection
Full certificate chain is required
Full certificate chain is required
Not applicable
Connection fails with syslog message
Connection fails with syslog message
Peer certificate: connection fails with syslog message
Intermediate CAs: connection fails
Client Certificate
Authentication
Full certificate chain is required
Full certificate chain is required
Yes
Connection fails with syslog message
Connection fails with syslog message
Connection fails with syslog message
66
Cisco FXOS CLI Configuration Guide, 2.2(1)
Security Certifications Compliance
About the Certificate Revocation List Check
Without local static CRL LDAP Connection
One CDP CRL is empty in the peer certificate chain with valid signature
Connection succeeds
Any CDP in the peer certificate chain cannot be downloaded
Connection fails with syslog message
IPSec Connection
Connection succeeds
Client Certificate
Authentication
Connection fails with syslog message
Certificate has CDP, but the CDP server is down
Connection fails with syslog message
Certifcate has CDP, server is up, and CRL is on CDP, but the CRL has an invalid signature
Connection fails with syslog message
Peer certificate:
Connection fails with syslog message
Intermediate CA: connection fails
Peer certificate:
Connection fails with syslog message
Intermediate CA: connection fails
Peer certificate:
Connection fails with syslog message
Intermediate CA: connection fails
Connection fails with syslog message
Connection fails with syslog message
Connection fails with syslog message
Table 5: Certificate Revocation Check Mode set to Strict with a local static CRL
With local static CRL
Checking peer certificate chain
LDAP Connection
Full certificate chain is required
Checking CDP in peer certificate chain
Full certificate chain is required
CDP checking for Root CA certificate of the peer certificate chain
Yes
Any certificate validation failure in the peer certificate chain
Connection fails with syslog message
Any certificate revoked in the peer certificate chain
Connection fails with syslog message
One CDP is missing the peer certificate chain (Certificate Chain level is 1)
Connection succeeds
IPSec Connection
Full certificate chain is required
Full certificate chain is required
Not applicable
Connection fails with syslog message
Connection fails with syslog message
Connection succeeds
Cisco FXOS CLI Configuration Guide, 2.2(1)
67
Security Certifications Compliance
About the Certificate Revocation List Check
With local static CRL LDAP Connection
One CDP CRL is empty in the peer certificate chain (Certificate Chain level is 1)
Connection succeeds
Any CDP in the peer certificate chain cannot be downloaded
(Certificate Chain level is 1)
Connection succeeds
Certificate has CDP, but the CDP server is down (Certificate Chain level is 1)
Connection succeeds
Certificate has CDP, server is up, and CRL is on CDP, but the CRL has an invalid signature (Certificate
Chain level is 1)
Connection succeeds
Peer Certificate Chain level is higher than 1
Connection fails with syslog message
IPSec Connection
Connection succeeds
Connection succeeds
Connection succeeds
Connection succeeds
If combined with CDP, connection succeeds
If there is no CDP, connection fails with syslog message
Table 6: Certificate Revocation Check Mode set to Relaxed without a local static CRL
Without local static CRL LDAP Connection IPSec Connection
Full certificate chain
Client Certificate
Authentication
Full certificate chain Checking peer certificate chain
Full certificate chain
Checking CDP in peer certificate chain
Full certificate chain
CDP checking for Root
CA certificate of the peer certificate chain
Yes
Any certificate validation failure in the peer certificate chain
Connection fails with syslog message
Any certificate revoked in the peer certificate chain
Connection fails with syslog message
One CDP is missing the peer certificate chain
Connection succeeds
Full certificate chain
Not applicable
Connection fails with syslog message
Connection fails with syslog message
Connection succeeds
Full certificate chain
Yes
Connection fails with syslog message
Connection fails with syslog message
Connection fails with syslog message
68
Cisco FXOS CLI Configuration Guide, 2.2(1)
Security Certifications Compliance
About the Certificate Revocation List Check
Without local static CRL LDAP Connection
One CDP CRL is empty in the peer certificate chain with valid signature
Connection succeeds
Any CDP in the peer certificate chain cannot be downloaded
Connection succeeds
Certificate has CDP, but the CDP server is down
Connection succeeds
Certificate has CDP, server is up, and CRL is on CDP, but the CRL has an invalid signature
Connection succeeds
IPSec Connection
Connection succeeds
Client Certificate
Authentication
Connection succeeds
Connection succeeds Connection succeeds
Connection succeeds
Connection succeeds
Connection succeeds
Connection succeeds
Table 7: Certificate Revocation Check Mode set to Relaxed with a local static CRL
With local static CRL
Checking peer certificate chain
LDAP Connection
Full certificate chain
Checking CDP in peer certificate chain
Full certificate chain
CDP checking for Root CA certificate of the peer certificate chain
Yes
Any certificate validation failure in the peer certificate chain
Connection fails with syslog message
Any certificate revoked in the peer certificate chain
Connection fails with syslog message
One CDP is missing the peer certificate chain (Certificate Chain level is 1)
Connection succeeds
One CDP CRL is empty in the peer certificate chain (Certificate Chain level is 1)
Connection succeeds
Any CDP in the peer certificate chain cannot be downloaded
(Certificate Chain level is 1)
Connection succeeds
IPSec Connection
Full certificate chain
Full certificate chain
Not applicable
Connection fails with syslog message
Connection fails with syslog message
Connection succeeds
Connection succeeds
Connection succeeds
Cisco FXOS CLI Configuration Guide, 2.2(1)
69
Security Certifications Compliance
Configure CRL Periodic Download
With local static CRL
Certificate has CDP, but the CDP server is down (Certificate Chain level is 1)
LDAP Connection
Connection succeeds
Certificate has CDP, server is up, and CRL is on CDP, but the CRL has an invalid signature (Certificate
Chain level is 1)
Connection succeeds
Peer Certificate Chain level is higher than 1
Connection fails with syslog message
IPSec Connection
Connection succeeds
Connection succeeds
If combined with CDP, connection succeeds
If there is no CDP, connection fails with syslog message
Configure CRL Periodic Download
You can configure your system to periodically download a (CRL) so that a new CRL is used every 1 to 24 hours to validate certificates.
You can use the following protocols and interfaces with this feature:
• FTP
• SCP
• SFTP
• TFTP
• USB
Note
• SCEP and OCSP are not supported.
• You can only configure one periodic download per CRL.
• One CRL is supported per trustpoint.
Note
You can only configure the period in one-hour intervals.
Perform these steps to configure CRL periodic download.
Before You Begin
Ensure that you have already configured your FXOS chassis to validate peer certificates using (CRL) information. For more information, see
Configure Static CRL for a Trustpoint, on page 65
.
70
Cisco FXOS CLI Configuration Guide, 2.2(1)
Security Certifications Compliance
Enable NTP Server Authentication
Procedure
Step 1
From the FXOS CLI, enter security mode:
scope security
Step 2
Enter trustpoint mode:
scope trustpoint
Step 3
Enter revoke mode:
scope revoke
Step 4
Edit the revoke configuration:
sh config
Step 5
Set your preferred configuration:
Example:
set certrevokemethod crl set crl-poll-filename rootCA.crl
set crl-poll-path /users/myname set crl-poll-period 1 set crl-poll-port 0 set crl-poll-protocol scp
! set crl-poll-pwd set crl-poll-server 182.23.33.113
set crl-poll-user myname
Step 6
Exit the configuration file:
exit
Step 7
(Optional) Test the new configuration by downloading a new CRL:
Example:
Firepower-chassis /security/trustpoint/revoke # sh import-task
Import task:
File Name Protocol Server Port Userid
--------- -------- --------------- ---------- -------------- ----rootCA.crl Scp 182.23.33.113 0 myname
State
Downloading
Enable NTP Server Authentication
Perform these steps to enable NTP server authentication on your FXOS chassis.
Cisco FXOS CLI Configuration Guide, 2.2(1)
71
Security Certifications Compliance
Set the LDAP Key Ring Certificate
Note
• When enabled, the NTP authentication feature is global for all configured servers.
• Only SHA1 is supported for NTP server authentication.
• You need the key ID and the key value to authenticate a server. The key ID is used to tell both the client and server which key value to use when computing the message digest. The key value is a fixed value that is derived using ntp-keygen.
Procedure
Step 1
Download ntp 4.2.8p8.
Step 2
Install the NTP server with ntpd openssl enabled.
Step 3
Generate NTP key IDs and key values:
ntp-keygen -M
Use these generated keys for the following steps.
Step 4
From the FXOS CLI, create the NTP server:
create ntp-server server_id
Step 5
Enter the NTP server:
scope ntp-server server_id
Step 6
Set the SHA1 Key ID:
set ntp-sha1-key-id key_id
Step 7
Set the SHA1 Key String:
set ntp-sha1-key-string key_string
Step 8
Enable NTP authentication:
enable ntp-authentication
Set the LDAP Key Ring Certificate
You can configure a secure LDAP client key ring certificate to support a TLS connection on your FXOS chassis. This option is one of a number offered for achieving Common Criteria certification compliance on your system. For more information, see
Security Certifications Compliance, on page 57
.
Note
If Common Criteria mode is enabled, you must have SSL enabled, and you must use the server DNS information to create the key ring certificate.
If SSL is enabled for the LDAP server entry, key ring information is referenced and checked when forming a connection.
LDAP server information has to be DNS information in the CC mode for the secure LDAP connection (with
SSL enabled).
72
Cisco FXOS CLI Configuration Guide, 2.2(1)
Security Certifications Compliance
Configure the IP Access List
Perform these steps to configure a secure LDAP client key ring certificate:.
Procedure
Step 1
From the FXOS CLI, enter security mode:
scope security
Step 2
Enter LDAP mode:
scope ldap
Step 3
Enter LDAP server mode:
enter server {server_ip|server_dns}
Step 4
Set the LDAP key ring:
set keyring keyring_name
Step 5
Commit the configuration:
commit-buffer
Configure the IP Access List
By default, the FXOS chassis denies all access to the local web server. You must configure your IP Access
List with a list of allowed services for each of your IP blocks.
The IP Access List supports the following protocols:
• HTTPS
• SNMP
• SSH
For each block of IP addresses (v4 or v6), up to 25 different subnets can be configured for each service. A subnet of 0 and a prefix of 0 allows unrestricted access to a service.
Procedure
Step 1
From the FXOS CLI, enter the services mode:
scope system scope security
Step 2
Create an IP block for the services you want to enable access for:
For IPv4:
create ip-block ip prefix [0-32] https/snmp/ssh
For IPv6:
create ipv6-block ip prefix [0-28] https/snmp/ssh
Cisco FXOS CLI Configuration Guide, 2.2(1)
73
Security Certifications Compliance
Enable Client Certificate Authentication
IPv4:
Firepower-chassis # scope system
Firepower-chassis /system # scope services
Firepower-chassis /system/services # create ip-block 10.1.1.1 24 https
Firepower-chassis /system/services/ip-block* # com
Firepower-chassis /system/services/ip-block # up
Firepower-chassis /system/services # create ip-block 11.1.1.1 24 ssh
Firepower-chassis /system/services/ip-block* # com
Firepower-chassis /system/services/ip-block # up
Firepower-chassis /system/services # create ip-block 12.1.1.1 24 snmp
Firepower-chassis /system/services/ip-block* # com
Firepower-chassis /system/services/ip-block # up
Firepower-chassis /system/services # sh ip-block
Permitted IP Block:
IP Address Prefix Length Protocol
--------------- ------------- --------
10.1.1.1
24 Https
11.1.1.1
12.1.1.1
24
24
Ssh
Snmp
IPv6:
Firepower-chassis /system/services # create ipv6-block 2014::10:76:78:107 64 ssh
Firepower-chassis /system/services/ipv6-block* # com
Firepower-chassis /system/services/ipv6-block # up
Firepower-chassis /system/services # create ipv6-block 2014::10:76:78:107 64 snmp
Firepower-chassis /system/services/ipv6-block* # com
Firepower-chassis /system/services/ipv6-block # up
Firepower-chassis /system/services # create ipv6-block 2014::10:76:78:107 64 https
Firepower-chassis /system/services/ipv6-block* # com
Firepower-chassis /system/services/ipv6-block # up
Firepower-chassis /system/services # sh ipv6-block
Permitted IPv6 Block:
IPv6 Address Prefix Length Protocol
------------ ------------- --------
2014::10:76:78:107 64 Https
2014::10:76:78:107 64
2014::10:76:78:107 64
Snmp
Ssh
Enable Client Certificate Authentication
You can enable your system to use a client certificate in conjunction with LDAP to authenticate a user for
HTTPS access. The default authentication configuration on the FXOS chassis is credential-based.
Note
If certificate authentication is enabled, that is the only form of authentication permitted for HTTPS.
Certificate revocation check is not supported with the FXOS 2.1.1 release of the client certificate authentication feature.
The following requirements must be met by the Client Certificate to use this feature:
• The username must be included in the X509 attribute Subject Alternative Name - Email.
• The client certificate must be signed by a root CA that has had its certificate imported into a trustpoint on the Supervisor.
Procedure
Step 1
From the FXOS CLI, enter services mode:
scope system
74
Cisco FXOS CLI Configuration Guide, 2.2(1)
Security Certifications Compliance scope security
Step 2
(Optional) View your options for HTTPS authentication:
set https auth-type
Example:
Firepower-chassis /system/services # set https auth-type cert-auth Client certificate based authentication cred-auth Credential based authentication
Step 3
Set your HTTPS authentication to client-based:
set https auth-type cert-auth
Step 4
Commit the configuration:
commit-buffer
Enable Client Certificate Authentication
Cisco FXOS CLI Configuration Guide, 2.2(1)
75
Enable Client Certificate Authentication
Security Certifications Compliance
76
Cisco FXOS CLI Configuration Guide, 2.2(1)
C H A P T E R
8
System Administration
•
Changing the Management IP Address, page 77
•
Changing the Application Management IP, page 79
•
•
Rebooting the FXOS Chassis, page 83
•
Powering Off the FXOS Chassis, page 84
•
Install a Trusted Identity Certificate, page 84
•
Recovering from a Software Failure, page 89
•
Recovering from a Corrupted File System, page 94
Changing the Management IP Address
Before You Begin
You can change the management IP address on the FXOS chassis from the FXOS CLI.
Note
After changing the management IP address, you will need to reestablish any connections to Firepower
Chassis Manager or the FXOS CLI using the new address.
Procedure
Step 1
Connect to the FXOS CLI (see
Accessing the FXOS CLI, on page 13
).
Step 2
To configure an IPv4 management IP address: a) Set the scope for fabric-interconnect a:
Firepower-chassis# scope fabric-interconnect a b) To view the current management IP address, enter the following command:
Firepower-chassis /fabric-interconnect # show
Cisco FXOS CLI Configuration Guide, 2.2(1)
77
System Administration
Changing the Management IP Address
c) Enter the following command to configure a new management IP address and gateway:
Firepower-chassis /fabric-interconnect # set out-of-band ip ip_address netmask network_mask gw
gateway_ip_address
d) Commit the transaction to the system configuration:
Firepower-chassis /fabric-interconnect* # commit-buffer
Step 3
To configure an IPv6 management IP address: a) Set the scope for fabric-interconnect a:
Firepower-chassis# scope fabric-interconnect a b) Set the scope for management IPv6 configuration:
Firepower-chassis /fabric-interconnect # scope ipv6-config c) To view the current management IPv6 address, enter the following command:
Firepower-chassis /fabric-interconnect/ipv6-config # show ipv6-if d) Enter the following command to configure a new management IP address and gateway:
Firepower-chassis /fabric-interconnect/ipv6-config # set out-of-band ipv6 ipv6_address ipv6-prefix
prefix_length ipv6-gw gateway_address e) Commit the transaction to the system configuration:
Firepower-chassis /fabric-interconnect/ipv6-config* # commit-buffer
The following example configures an IPv4 management interface and gateway:
Firepower-chassis#
scope fabric-interconnect a
Firepower-chassis /fabric-interconnect #
show
Fabric Interconnect:
ID OOB IP Addr
Prefix Operability
OOB Gateway OOB Netmask OOB IPv6 Address OOB IPv6 Gateway
---- --------------- --------------- --------------- ---------------- ----------------
------ -----------
64
A 192.0.2.112
Operable
192.0.2.1
255.255.255.0
:: ::
Firepower-chassis /fabric-interconnect # set out-of-band ip 192.0.2.111 netmask 255.255.255.0
gw 192.0.2.1
Warning: When committed, this change may disconnect the current CLI session
Firepower-chassis /fabric-interconnect* #
commit-buffer
Firepower-chassis /fabric-interconnect #
The following example configures an IPv6 management interface and gateway:
Firepower-chassis#
scope fabric-interconnect a
Firepower-chassis /fabric-interconnect #
scope ipv6-config
Firepower-chassis /fabric-interconnect/ipv6-config #
show ipv6-if
Management IPv6 Interface:
IPv6 Address Prefix IPv6 Gateway
----------------------------------- ---------- ------------
2001::8998 64 2001::1
Firepower-chassis /fabric-interconnect/ipv6-config # set out-of-band ipv6 2001::8999 ipv6-prefix 64 ipv6-gw 2001::1
Firepower-chassis /fabric-interconnect/ipv6-config* #
commit-buffer
Firepower-chassis /fabric-interconnect/ipv6-config #
78
Cisco FXOS CLI Configuration Guide, 2.2(1)
System Administration
Changing the Application Management IP
Changing the Application Management IP
You can change the management IP address on the application(s) attached to your FXOS chassis from the
FXOS CLI. To do so, you must first change the IP information at the FXOS platform level, then change the
IP information at the application level.
Note
Attempts to make these changes using the FXOS Chassis Manager may result in a service interruption.
To avoid any potential service interruptions, you must perform these changes using the FXOS CLI.
Procedure
Step 1
Connect to the FXOS CLI. (See
Accessing the FXOS CLI, on page 13
).
Step 2
Scope to the logical device:
scope ssa
scope logical-device logical_device_name
Step 3
Scope to the management bootstrap and configure the new management bootstrap parameters. Note that there are differences between deployments:
For standalone configuration of an ASA logical device: a) Enter the logical device management bootstrap:
scope mgmt-bootstrap asa b) Enter the IP mode for the slot:
scope ipv4_or_6 slot_number default c) (IPv4 only) Set the new IP address:
set ip ipv4_address mask network_mask d) (IPv6 only) Set the new IP address:
set ip ipv6_address prefix-length prefix_length_number e) Set the gateway address:
set gateway gateway_ip_address f) Commit the configuration:
commit-buffer
For a clustered configuration of ASA logical devices: a) Enter the cluster management bootstrap:
scope cluster-bootstrap asa b) (IPv4 only) Set the new virtual IP:
set virtual ipv4 ip_address mask network_mask c) (IPv6 only) Set the new virtual IP:
set virtual ipv6 ipv6_address prefix-length prefix_length_number d) Set the new IP pool:
set ip pool start_ip end_ip e) Set the gateway address:
Cisco FXOS CLI Configuration Guide, 2.2(1)
79
System Administration
Changing the Application Management IP
set gateway gateway_ip_address f) Commit the configuration:
commit-buffer
For standalone and clustered configurations of Firepower Threat Defense: a) Enter the logical device management bootstrap:
scope mgmt-bootstrap ftd b) Enter the IP mode for the slot:
scope ipv4_or_6 slot_number firepower c) (IPv4 only) Set the new IP address:
set ip ipv4_address mask network_mask d) (IPv6 only) Set the new IP address:
set ip ipv6_address prefix-length prefix_length_number e) Set the gateway address:
set gateway gateway_ip_address f) Commit the configuration:
commit-buffer
Note
For a clustered configuration, you must set the new IP address for each application attached to the
FXOS Chassis. If you have an inter-chassis cluster or a HA configuration, you must repeat these steps for each application on both chassis.
Step 4
Clear the management bootstrap information for each application: a) Scope to ssa mode:
scope ssa
b) Scope to the slot:
scope slot slot_number c) Scope to the application instance:
scope app-instance asa_or_ftd d) Clear the management bootstrap information:
clear mgmt-bootstrap
e) Commit the configuration:
commit-buffer
Step 5
Disable the application:
disable commit-buffer
Note
For a clustered configuration, you must clear and disable the management bootstrap information for each application attached to the FXOS Chassis. If you have an inter-chassis cluster or a HA configuration, you must repeat these steps for each application on both chassis.
Step 6
When the application is offline and the slot comes online again, re-enable the application.
a) Scope back to ssa mode:
scope ssa
b) Scope to the slot:
scope slot slot_number
80
Cisco FXOS CLI Configuration Guide, 2.2(1)
System Administration
Pre-Login Banner
c) Scope to the application instance:
scope app-instance asa_or_ftd d) Enable the application:
enable
e) Commit the configuration:
commit-buffer
Note
For a clustered configuration, you must repeat these steps to re-enable each application attached to the FXOS Chassis. If you have an inter-chassis cluster or a HA configuration, you must repeat these steps for each application on both chassis.
Pre-Login Banner
With a pre-login banner, when a user logs into Firepower Chassis Manager, the system displays the banner text and the user must click OK on the message screen before the system prompts for the username and password. If a pre-login banner is not configured, the system goes directly to the username and password prompt.
When a user logs into the FXOS CLI, the system displays the banner text, if configured, before it prompts for the password.
Creating the Pre-Login Banner
Procedure
Step 1
Connect to the FXOS CLI (see
Accessing the FXOS CLI, on page 13
).
Step 2
Enter security mode:
Firepower-chassis# scope security
Step 3
Enter banner security mode:
Firepower-chassis /security # scope banner
Step 4
Enter the following command to create a pre-login banner:
Firepower-chassis /security/banner # create pre-login-banner
Step 5
Specify the message that FXOS should display to the user before they log into Firepower Chassis Manager or the FXOS CLI:
Firepower-chassis /security/banner/pre-login-banner* # set message
Launches a dialog for entering the pre-login banner message text.
Step 6
At the prompt, type a pre-login banner message. You can enter any standard ASCII character in this field.
You can enter multiple lines of text with each line having up to 192 characters. Press Enter between lines.
On the line following your input, type ENDOFBUF and press Enter to finish.
Press Ctrl and C to cancel out of the set message dialog.
Step 7
Commit the transaction to the system configuration:
Cisco FXOS CLI Configuration Guide, 2.2(1)
81
System Administration
Modifying the Pre-Login Banner
Firepower-chassis /security/banner/pre-login-banner* # commit-buffer
The following example creates the pre-login banner:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope banner
Firepower-chassis /security/banner #
create pre-login-banner
Firepower-chassis /security/banner/pre-login-banner* #
set message
Enter lines one at a time. Enter ENDOFBUF to finish. Press ^C to abort.
Enter prelogin banner:
>Welcome to the Firepower Security Appliance
>**Unauthorized use is prohibited**
>ENDOFBUF
Firepower-chassis /security/banner/pre-login-banner* #
commit-buffer
Firepower-chassis /security/banner/pre-login-banner #
Modifying the Pre-Login Banner
Procedure
Step 1
Connect to the FXOS CLI (see
Accessing the FXOS CLI, on page 13
).
Step 2
Enter security mode:
Firepower-chassis# scope security
Step 3
Enter banner security mode:
Firepower-chassis /security # scope banner
Step 4
Enter pre-login-banner banner security mode:
Firepower-chassis /security/banner # scope pre-login-banner
Step 5
Specify the message that FXOS should display to the user before they log into Firepower Chassis Manager or the FXOS CLI:
Firepower-chassis /security/banner/pre-login-banner # set message
Launches a dialog for entering the pre-login banner message text.
Step 6
At the prompt, type a pre-login banner message. You can enter any standard ASCII character in this field.
You can enter multiple lines of text with each line having up to 192 characters. Press Enter between lines.
On the line following your input, type ENDOFBUF and press Enter to finish.
Press Ctrl and C to cancel out of the set message dialog.
Step 7
Commit the transaction to the system configuration:
Firepower-chassis /security/banner/pre-login-banner* # commit-buffer
The following example modifies the pre-login banner:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope banner
Firepower-chassis /security/banner #
scope pre-login-banner
Firepower-chassis /security/banner/pre-login-banner #
set message
Enter lines one at a time. Enter ENDOFBUF to finish. Press ^C to abort.
Enter prelogin banner:
>Welcome to the Firepower Security Appliance
>**Unauthorized use is prohibited**
82
Cisco FXOS CLI Configuration Guide, 2.2(1)
System Administration
Deleting the Pre-Login Banner
>ENDOFBUF
Firepower-chassis /security/banner/pre-login-banner* #
commit-buffer
Firepower-chassis /security/banner/pre-login-banner #
Deleting the Pre-Login Banner
Procedure
Step 1
Connect to the FXOS CLI (see
Accessing the FXOS CLI, on page 13
).
Step 2
Enter security mode:
Firepower-chassis# scope security
Step 3
Enter banner security mode:
Firepower-chassis /security # scope banner
Step 4
Delete the pre-login banner from the system:
Firepower-chassis /security/banner # delete pre-login-banner
Step 5
Commit the transaction to the system configuration:
Firepower-chassis /security/banner* # commit-buffer
The following example deletes the pre-login banner:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope banner
Firepower-chassis /security/banner #
delete pre-login-banner
Firepower-chassis /security/banner* #
commit-buffer
Firepower-chassis /security/banner #
Rebooting the FXOS Chassis
Procedure
Step 1
Enter chassis mode:
scope chassis 1
Step 2
Enter the following command to reboot the chassis:
reboot [ reason ] [no-prompt]
Note
If you use the [no-prompt] keyword, the chassis will reboot immediately after entering the command.
If you do not use the [no-prompt] keyword, the system will not reboot until you enter the
commit-buffer command.
The system will gracefully shut down any logical devices configured on the system and then power down each security module/engine before finally powering down and then restarting the FXOS chassis. This process takes approximately 15-20 minutes.
Step 3
To monitor the reboot process:
scope chassis 1 show fsm status
Cisco FXOS CLI Configuration Guide, 2.2(1)
83
System Administration
Powering Off the FXOS Chassis
Powering Off the FXOS Chassis
Procedure
Step 1
Enter chassis mode:
scope chassis 1
Step 2
Enter the following command to power down the chassis:
shutdown [ reason ] [no-prompt]
Note
If you use the [no-prompt] keyword, the chassis will shut down immediately after entering the command. If you do not use the [no-prompt] keyword, the system will not shut down until you enter the commit-buffer command.
The system will gracefully shut down any logical devices configured on the system and then power down each security module/engine before finally powering down the FXOS chassis. This process takes approximately
15-20 minutes. After the chassis has successfully shut down, you can then physically unplug the power on the chassis.
Step 3
To monitor the shutdown process:
scope chassis 1 show fsm status
Install a Trusted Identity Certificate
After initial configuration, a self-signed SSL certificate is generated for use with the FXOS chassis web application. Because that certificate is self-signed, client browsers do not automatically trust it. The first time a new client browser accesses the FXOS chassis web interface, the browser will throw an SSL warning, requiring the user to accept the certificate before accessing the FXOS chassis. You can use the following procedure to generate a Certificate Signing Request (CSR) using the FXOS CLI and install the resulting identity certificate for use with the FXOS chassis. This identity certificate allows a client browser to trust the connection, and bring up the web interface with no warnings.
Procedure
Step 1
Connect to the FXOS CLI. (See
Accessing the FXOS CLI, on page 13
).
Step 2
Enter the security module:
scope security
Step 3
Create a keyring:
create keyring keyring_name
Step 4
Set a modulus size for the private key:
set modulus size
84
Cisco FXOS CLI Configuration Guide, 2.2(1)
System Administration
Install a Trusted Identity Certificate
Step 5
Commit the configuration:
commit-buffer
Step 6
Configure the CSR fields. The certificate can be generated with basic options (for example, a subject-name), and optionally more advanced options that allow information like locale and organization to be embedded in the certificate. Note that when you configure the CSR fields, the system prompts for a certificate password.
create certreq certreq subject_name
password
set country country
set state state
set locality locality
set org-name organization_name
set org-unit-name organization_unit_name
set subject-name subject_name
Step 7
Commit the configuration:
commit-buffer
Step 8
Export the CSR to provide to your certificate authority.
a) Show the full CSR:
show certreq
b) Copy the output starting with (and including) "-----BEGIN CERTIFICATE REQUEST-----", ending with
(and including) "-----END CERTIFICATE REQUEST-----":
Example:
-----BEGIN CERTIFICATE REQUEST-----
MIIC6zCCAdMCAQAwdzELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWEx
ETAPBgNVBAcMCFNhbiBKb3NlMRYwFAYDVQQKDA1DaXNjbyBTeXN0ZW1zMQwwCgYD
VQQLDANUQUMxGjAYBgNVBAMMEWZwNDEyMC50ZXN0LmxvY2FsMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs0ON5gagkfZ2fi4JVEANG+7YGgcHbnUt7LpV yMChnKOPJjBwkUMNQA1mQsRQDcbJ232/sK0fMSnyqOL8JzC7itxeVEZRyz7/ax7W
GNveg/XP+zd03nt4GXM63FsrPcPmA7EwgqDSLoShtBEV10hhf4+Nw4pKCZ+eSSkS
JkTB1ZHaKV9bttYg3kf/UEUUgk/EyrVq3B+u2DsooPVq76mTm8BwYMqHbJEv4Pmu
RjWE88yEvVwH7JTEij9OvxbatjDjVSJHZBURtCanvyBvGuLP/Q/Nmv3Lo3G9ITbL
L5gIYZVatTxp6HTUezH2MIIzOavU6d1tB9rnyxgGth5dPV0dhQIDAQABoC8wLQYJ
KoZIhvcNAQkOMSAwHjAcBgNVHREEFTATghFmcDQxMjAudGVzdC5sb2NhbDANBgkq hkiG9w0BAQsFAAOCAQEAZUfCbwx9vt5aVDcL+tATu5xFE3LA310ck6GjlNv6W/6r jBNLxusYi1rZZcW+CgnvNs4ArqYGyNVBySOavJO/VvQ1KfyxxJ1OIkyx3RzEjgK0 zzyoyrG+EZXC5ShiraS8HuWvE2wFM2wwWNtHWtvcQy55+/hDPD2Bv8pQOC2Zng3I kLfG1dxWf1xAxLzf5J+AuIQ0CM5HzM9Zm8zREoWT+xHtLSqAqg/aCuomN9/vEwyU
OYfoJMvAqC6AZyUnMfUfCoyuLpLwgkxB0gyaRdnea5RhiGjYQ2lDXYDjEXp7rCx9
+6bvDl1n70JCegHdCWtP75SaNyaBEPkO0365rTckbw==
-----END CERTIFICATE REQUEST-----
Step 9
Exit the certreq mode:
exit
Step 10 Exit the keyring mode:
exit
Step 11 Note
All certificates must be in Base64 format to be imported into FXOS. If the certificate or chain received from the Certificate Authority is in a different format, you must first convert it with an SSL tool such as OpenSSL.
Create a new trustpoint to hold the certificate chain.
Cisco FXOS CLI Configuration Guide, 2.2(1)
85
System Administration
Install a Trusted Identity Certificate
create trustpoint trustpoint_name
Step 12 Set the generated CSR in the trustpoint:
set certchain
Step 13
Note
For a Certificate Authority that uses intermediate certificates, the root and intermediate certificates must be combined. In a text file, paste the root certificate at the top, followed by each intermediate certificate in the chain, including all BEGIN CERTIFICATE and END CERTIFICATE flags. Copy and paste that entire text block into the trustpoint.
Enter the CSR output you copied in step 8, following the instructions on screen.
Example:
Enter lines one at a time. Enter ENDOFBUF to finish. Press ^C to abort.
Trustpoint Certificate Chain:
>
-----BEGIN CERTIFICATE-----
>
MIICDTCCAbOgAwIBAgIQYIutxPDPw6BOp3uKNgJHZDAKBggqhkjOPQQDAjBTMRUw
>
EwYKCZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAEZFghuYWF1c3RpbjEg
>
MB4GA1UEAxMXbmFhdXN0aW4tTkFBVVNUSU4tUEMtQ0EwHhcNMTUwNzI4MTc1NjU2
>
WhcNMjAwNzI4MTgwNjU2WjBTMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJ
>
kiaJk/IsZAEZFghuYWF1c3RpbjEgMB4GA1UEAxMXbmFhdXN0aW4tTkFBVVNUSU4t
>
UEMtQ0EwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASvEA27V1Enq1gMtLkvJ6rx
>
GXRpXWIEyuiBM4eQRoqZKnkeJUkm1xmqlubaDHPJ5TMGfJQYszLBRJPq+mdrKcDl
>
o2kwZzATBgkrBgEEAYI3FAIEBh4EAEMAQTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0T
>
AQH/BAUwAwEB/zAdBgNVHQ4EFgQUyInbDHPrFwEEBcbxGSgQW7pOVIkwEAYJKwYB
>
BAGCNxUBBAMCAQAwCgYIKoZIzj0EAwIDSAAwRQIhAP++QJTUmniB/AxPDDN63Lqy
>
18odMDoFTkG4p3Tb/2yMAiAtMYhlsv1gCxsQVOw0xZVRugSdoOak6n7wCjTFX9jr
>
RA==
>
-----END CERTIFICATE-----
>
ENDOFBUF
Step 14 Commit the configuration:
commit-buffer
Step 15 Exit the trustpoint mode:
exit
Step 16 Enter the keyring mode:
scope keyring keyring_name
Step 17 Associate the trustpoint created in step 13 with the keyring that was created for the CSR:
set trustpoint trustpoint_name
Step 18 Import the signed identity certificate for the server.
set cert
Step 19 Paste the contents of the identity certificate provided by the Certificate authority:
Example:
Enter lines one at a time. Enter ENDOFBUF to finish. Press ^C to abort.
Keyring certificate:
>
-----BEGIN CERTIFICATE-----
>
MIIE8DCCBJagAwIBAgITRQAAAArehlUWgiTzvgAAAAAACjAKBggqhkjOPQQDAjBT
>
MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAEZFghuYWF1c3Rp
>
bjEgMB4GA1UEAxMXbmFhdXN0aW4tTkFBVVNUSU4tUEMtQ0EwHhcNMTYwNDI4MTMw
>
OTU0WhcNMTgwNDI4MTMwOTU0WjB3MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2Fs
>
aWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2UxFjAUBgNVBAoTDUNpc2NvIFN5c3Rl
>
bXMxDDAKBgNVBAsTA1RBQzEaMBgGA1UEAxMRZnA0MTIwLnRlc3QubG9jYWwwggEi
>
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzQ43mBqCR9nZ+LglUQA0b7tga
>
BwdudS3sulXIwKGco48mMHCRQw1ADWZCxFANxsnbfb+wrR8xKfKo4vwnMLuK3F5U
>
RlHLPv9rHtYY296D9c/7N3Tee3gZczrcWys9w+YDsTCCoNIuhKG0ERXXSGF/j43D
>
ikoJn55JKRImRMHVkdopX1u21iDeR/9QRRSCT8TKtWrcH67YOyig9WrvqZObwHBg
>
yodskS/g+a5GNYTzzIS9XAfslMSKP06/Ftq2MONVIkdkFRG0Jqe/IG8a4s/9D82a
86
Cisco FXOS CLI Configuration Guide, 2.2(1)
System Administration
Install a Trusted Identity Certificate
>
/cujcb0hNssvmAhhlVq1PGnodNR7MfYwgjM5q9Tp3W0H2ufLGAa2Hl09XR2FAgMB
>
AAGjggJYMIICVDAcBgNVHREEFTATghFmcDQxMjAudGVzdC5sb2NhbDAdBgNVHQ4E
>
FgQU/1WpstiEYExs8DlZWcuHZwPtu5QwHwYDVR0jBBgwFoAUyInbDHPrFwEEBcbx
>
GSgQW7pOVIkwgdwGA1UdHwSB1DCB0TCBzqCBy6CByIaBxWxkYXA6Ly8vQ049bmFh
>
dXN0aW4tTkFBVVNUSU4tUEMtQ0EsQ049bmFhdXN0aW4tcGMsQ049Q0RQLENOPVB1
>
YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRp
>
b24sREM9bmFhdXN0aW4sREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz
>
dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIHMBggrBgEF
>
BQcBAQSBvzCBvDCBuQYIKwYBBQUHMAKGgaxsZGFwOi8vL0NOPW5hYXVzdGluLU5B
>
QVVTVElOLVBDLUNBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD
>
Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW5hYXVzdGluLERDPWxvY2Fs
>
P2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0
>
aG9yaXR5MCEGCSsGAQQBgjcUAgQUHhIAVwBlAGIAUwBlAHIAdgBlAHIwDgYDVR0P
>
AQH/BAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAoGCCqGSM49BAMCA0gAMEUC
>
IFew7NcJirEtFRvyxjkQ4/dVo2oI6CRB308WQbYHNUu/AiEA7UdObiSJBG/PBZjm
>
sgoIK60akbjotOTvUdUd9b6K1Uw=
>
-----END CERTIFICATE-----
>
ENDOFBUF
Step 20 Exit the keyring mode:
exit
Step 21 Exit the security mode:
exit
Step 22 Enter the system mode:
scope system
Step 23 Enter the services mode:
scope services
Step 24 Configure the FXOS web service to use the new certificate:
set https keyring keyring_name
Step 25 Commit the configuration:
commit-buffer
Step 26 Display the keyring associated with the HTTPS server. It should reflect the keyring name created in step 3 of this procedure. If the screen output displays the default keyring name, the HTTPS server has not yet been updated to use the new certificate:
show https
Example:
fp4120 /system/services #
show https
Name: https
Admin State: Enabled
Port: 443
Operational port: 443
Key Ring:
firepower_cert
Cipher suite mode: Medium Strength
Cipher suite: ALL:!ADH:!EXPORT40:!EXPORT56:!LOW:!RC4:!MD5:!IDEA:+HIGH:+MEDIUM:+EXP:+eNULL
Step 27 Display the contents of the imported certificate, and verify that the Certificate Status value displays as Valid:
scope security
show keyring keyring_name detail
Cisco FXOS CLI Configuration Guide, 2.2(1)
87
System Administration
Install a Trusted Identity Certificate
Example:
fp4120 /security #
scope security
fp4120 /security #
show keyring firepower_cert detail
Keyring firepower_cert:
RSA key modulus: Mod2048
Trustpoint CA: firepower_chain
Certificate status: Valid
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
45:00:00:00:0a:de:86:55:16:82:24:f3:be:00:00:00:00:00:0a
Signature Algorithm: ecdsa-with-SHA256
Issuer: DC=local, DC=naaustin, CN=naaustin-NAAUSTIN-PC-CA
Validity
Not Before: Apr 28 13:09:54 2016 GMT
Not After : Apr 28 13:09:54 2018 GMT
Subject: C=US, ST=California, L=San Jose, O=Cisco Systems, OU=TAC,
CN=fp4120.test.local
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b3:43:8d:e6:06:a0:91:f6:76:7e:2e:09:54:40:
0d:1b:ee:d8:1a:07:07:6e:75:2d:ec:ba:55:c8:c0: a1:9c:a3:8f:26:30:70:91:43:0d:40:0d:66:42:c4:
50:0d:c6:c9:db:7d:bf:b0:ad:1f:31:29:f2:a8:e2: fc:27:30:bb:8a:dc:5e:54:46:51:cb:3e:ff:6b:1e: d6:18:db:de:83:f5:cf:fb:37:74:de:7b:78:19:73:
3a:dc:5b:2b:3d:c3:e6:03:b1:30:82:a0:d2:2e:84: a1:b4:11:15:d7:48:61:7f:8f:8d:c3:8a:4a:09:9f:
9e:49:29:12:26:44:c1:d5:91:da:29:5f:5b:b6:d6:
20:de:47:ff:50:45:14:82:4f:c4:ca:b5:6a:dc:1f: ae:d8:3b:28:a0:f5:6a:ef:a9:93:9b:c0:70:60:ca:
87:6c:91:2f:e0:f9:ae:46:35:84:f3:cc:84:bd:5c:
07:ec:94:c4:8a:3f:4e:bf:16:da:b6:30:e3:55:22:
47:64:15:11:b4:26:a7:bf:20:6f:1a:e2:cf:fd:0f: cd:9a:fd:cb:a3:71:bd:21:36:cb:2f:98:08:61:95:
5a:b5:3c:69:e8:74:d4:7b:31:f6:30:82:33:39:ab: d4:e9:dd:6d:07:da:e7:cb:18:06:b6:1e:5d:3d:5d:
1d:85
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:fp4120.test.local
X509v3 Subject Key Identifier:
FF:55:A9:B2:D8:84:60:4C:6C:F0:39:59:59:CB:87:67:03:ED:BB:94
X509v3 Authority Key Identifier: keyid:C8:89:DB:0C:73:EB:17:01:04:05:C6:F1:19:28:10:5B:BA:4E:54:89
X509v3 CRL Distribution Points:
Full Name:
URI:ldap:///CN=naaustin-NAAUSTIN-PC-CA,CN=naaustin-pc,CN=CDP,
CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=naaustin,
DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint
Authority Information Access:
CA Issuers - URI:ldap:///CN=naaustin-NAAUSTIN-PC-CA,CN=AIA,
CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=naaustin,
DC=local?cACertificate?base?objectClass=certificationAuthority
1.3.6.1.4.1.311.20.2:
...W.e.b.S.e.r.v.e.r
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
Signature Algorithm: ecdsa-with-SHA256
30:45:02:20:57:b0:ec:d7:09:8a:b1:2d:15:1b:f2:c6:39:10: e3:f7:55:a3:6a:08:e8:24:41:df:4f:16:41:b6:07:35:4b:bf:
02:21:00:ed:47:4e:6e:24:89:04:6f:cf:05:98:e6:b2:0a:08:
2b:ad:1a:91:b8:e8:b4:e4:ef:51:d5:1d:f5:be:8a:d5:4c
88
Cisco FXOS CLI Configuration Guide, 2.2(1)
System Administration
Recovering from a Software Failure
-----BEGIN CERTIFICATE-----
MIIE8DCCBJagAwIBAgITRQAAAArehlUWgiTzvgAAAAAACjAKBggqhkjOPQQDAjBT
MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxGDAWBgoJkiaJk/IsZAEZFghuYWF1c3Rp bjEgMB4GA1UEAxMXbmFhdXN0aW4tTkFBVVNUSU4tUEMtQ0EwHhcNMTYwNDI4MTMw
OTU0WhcNMTgwNDI4MTMwOTU0WjB3MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2Fs aWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2UxFjAUBgNVBAoTDUNpc2NvIFN5c3Rl bXMxDDAKBgNVBAsTA1RBQzEaMBgGA1UEAxMRZnA0MTIwLnRlc3QubG9jYWwwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzQ43mBqCR9nZ+LglUQA0b7tga
BwdudS3sulXIwKGco48mMHCRQw1ADWZCxFANxsnbfb+wrR8xKfKo4vwnMLuK3F5U
RlHLPv9rHtYY296D9c/7N3Tee3gZczrcWys9w+YDsTCCoNIuhKG0ERXXSGF/j43D ikoJn55JKRImRMHVkdopX1u21iDeR/9QRRSCT8TKtWrcH67YOyig9WrvqZObwHBg yodskS/g+a5GNYTzzIS9XAfslMSKP06/Ftq2MONVIkdkFRG0Jqe/IG8a4s/9D82a
/cujcb0hNssvmAhhlVq1PGnodNR7MfYwgjM5q9Tp3W0H2ufLGAa2Hl09XR2FAgMB
AAGjggJYMIICVDAcBgNVHREEFTATghFmcDQxMjAudGVzdC5sb2NhbDAdBgNVHQ4E
FgQU/1WpstiEYExs8DlZWcuHZwPtu5QwHwYDVR0jBBgwFoAUyInbDHPrFwEEBcbx
GSgQW7pOVIkwgdwGA1UdHwSB1DCB0TCBzqCBy6CByIaBxWxkYXA6Ly8vQ049bmFh dXN0aW4tTkFBVVNUSU4tUEMtQ0EsQ049bmFhdXN0aW4tcGMsQ049Q0RQLENOPVB1
YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRp b24sREM9bmFhdXN0aW4sREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIHMBggrBgEF
BQcBAQSBvzCBvDCBuQYIKwYBBQUHMAKGgaxsZGFwOi8vL0NOPW5hYXVzdGluLU5B
QVVTVElOLVBDLUNBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD
Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPW5hYXVzdGluLERDPWxvY2Fs
P2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0 aG9yaXR5MCEGCSsGAQQBgjcUAgQUHhIAVwBlAGIAUwBlAHIAdgBlAHIwDgYDVR0P
AQH/BAQDAgWgMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAoGCCqGSM49BAMCA0gAMEUC
IFew7NcJirEtFRvyxjkQ4/dVo2oI6CRB308WQbYHNUu/AiEA7UdObiSJBG/PBZjm sgoIK60akbjotOTvUdUd9b6K1Uw=
-----END CERTIFICATE-----
Zeroized: No
What to Do Next
To verify that the new trusted certificate is presented, navigate to the Firepower Chassis Manager by entering
https://<FQDN_or_IP>/ in the address bar of a web browser.
Note
Browsers also verify the subject-name of a certificate against the input in the address bar. If the certificate is issued to the fully qualified domain name, it must be accessed that way in the browser. If it is accessed via IP address, a different SSL error is thrown (Common Name Invalid) even if the trusted certificate is used.
Recovering from a Software Failure
Before You Begin
In the event of software failure that prevents the system from booting successfully, you can use the following procedure to boot a new version of software. To complete this process you need to TFTP boot a kickstart image, download new system and manager images, and then boot using the new images.
The recovery images for a specific FXOS version can be obtained from Cisco.com at one of the following locations:
• Firepower 9300— https://software.cisco.com/portal/pub/download/portal/ select.html?&mdfid=286287252&flowid=77282&softwareid=286287263
Cisco FXOS CLI Configuration Guide, 2.2(1)
89
System Administration
Recovering from a Software Failure
• Firepower 4100 Series— https://software.cisco.com/portal/pub/download/portal/ select.html?&mdfid=286305187&flowid=79423&softwareid=286287263
The recovery images include three separate files. For example, below are the current recovery images for
FXOS 2.1.1.64.
Recovery image (kickstart) for FX-OS 2.1.1.64.
fxos-k9-kickstart.5.0.3.N2.4.11.63.SPA
Recovery image (manager) for FX-OS 2.1.1.64.
fxos-k9-manager.4.1.1.63.SPA
Recovery image (system) for FX-OS 2.1.1.64.
fxos-k9-system.5.0.3.N2.4.11.63.SPA
Procedure
Step 1
Access ROMMON: a) Connect to the console port.
b) Reboot the system.
The system will start loading and during the process display a countdown timer.
c) Press the Escape key during the countdown to enter ROMMON mode.
Example:
Cisco System ROMMON, version 1.0.09, RELEASE SOFTWARE
Copright (c) 1994-2015 by Cisco Systems, Inc.
Compiled Sun 01/01/1999 23:59:59:59.99 by user
Current image running: Boot ROM0
Last reset cause: LocalSoft
DIMM Slot 0 : Present
DIMM Slot 1 : Present
No USB drive !!
Platform FPR9K-SUP with 16384 Mbytes of main memory
MAC Address aa:aa:aa:aa:aa:aa find the string ! boot bootflash:/installables/switch/fxos-k9-kickstart.5.0.3.N2.0.00.00.SPA
bootflash:/installables/switch/fxos-k9-system.5.0.3.N2.0.00.00.SPA
Use BREAK, ESC or CTRL+L to interrupt boot.
use SPACE to begin boot immediately.
Boot interrupted.
rommon 1 >
Step 2
TFTP boot a kickstart image: a) Verify that the management IP address, management netmask, and gateway IP address are set correctly.
You can see their values using the set command. You can test the connectivity to the TFTP server using the ping command.
rommon 1 >
set
ADDRESS=
NETMASK=
GATEWAY=
SERVER=
IMAGE=
PS1="ROMMON ! > " rommon > address <ip-address>
90
Cisco FXOS CLI Configuration Guide, 2.2(1)
System Administration
Recovering from a Software Failure
rommon >
netmask <network-mask> rommon > gateway <default-gateway> b) Copy the kickstart image to a TFTP directory that is accessible from your FXOS chassis.
Note
The kickstart image version number will not match the bundle version number. Information showing the mapping between your FXOS version and the kickstart image can be found on the
Cisco.com software download page.
c) Boot the image from ROMMON using the boot command:
boot tftp://<IP address>/<path to image>
Note
You can also boot the kickstart from ROMMON using a USB media device inserted into the USB slot on the front panel of the FXOS chassis. If the USB device is inserted while the system is running, you will need to reboot the system before it will recognize the USB device.
The system will display a series of #'s indicating that the image is being received and will then load the kickstart image.
Example:
rommon 1 >
set
ADDRESS=
NETMASK=
GATEWAY=
SERVER=
IMAGE=
PS1="ROMMON ! > " rommon 2 >
address 10.0.0.2
rommon 3 >
netmask 255.255.255.0
rommon 4 >
gateway 10.0.0.1
rommon 5 >
ping 10.0.0.2
..!!!!!!!!!!
Success rate is 100 percent (10/10) rommon 6 >
ping 192.168.1.2
..!!!!!!!!!!
Success rate is 100 percent (10/10) rommon 7 >
boot tftp://192.168.1.2/fxos-k9-kickstart.5.0.3.N2.1.11.1.SPA
ADDRESS: 10.0.0.2
NETMASK: 255.255.255.0
GATEWAY: 10.0.0.1
SERVER: 192.168.1.2
IMAGE: fxos-k9-kickstart.5.0.3.N2.1.11.1.SPA
TFTP_MACADDR: aa:aa:aa:aa:aa:aa
............................................................................
Receiving fxos-k9-kickstart.5.0.3.N2.1.11.1.SPA from 192.168.1.2
###############################################################################
###############################################################################
#############################################################################
File reception completed.
Step 3
Download the recovery system and manager images that match the kickstart image you just loaded to the
FXOS chassis: a) To download the recovery system and manager images you will need to set the management IP address and gateway. You cannot download these images via USB.
switch(boot)#
config terminal
switch(boot)(config)#
interface mgmt 0
switch(boot)(config-if)# ip address <ip address> <netmask> switch(boot)(config-if)#
no shutdown
Cisco FXOS CLI Configuration Guide, 2.2(1)
91
System Administration
Recovering from a Software Failure
switch(boot)(config-if)#
exit
switch(boot)(config)# ip default-gateway <gateway> switch(boot)(config)#
exit
b) Copy the recovery system and manager images from the remote server to the bootflash: switch(boot)# copy URL bootflash:
Specify the URL for the file being imported using one of the following syntax:
• ftp://username@hostname/path/image_name
• scp://username@hostname/path/image_name
• sftp://username@hostname/path/image_name
• tftp://hostname/path/image_name
Example:
switch(boot)#
copy scp://<username>@192.168.1.2/recovery_images/fxos-k9-system.5.0.3.N2.4.11.69.SPA
bootflash:
switch(boot)#
copy scp://<username>@192.168.1.2/recovery_images/fxos-k9-manager.4.1.1.69.SPA
bootflash:
c) After the images have been successfully copied to the FXOS chassis, make a symlink to the manager image from nuova-sim-mgmt-nsg.0.1.0.001.bin. This link tells the load mechanism which manager image to load. The symlink name should always be nuova-sim-mgmt-nsg.0.1.0.001.bin regardless of what image you are trying to load.
switch(boot)# copy bootflash:<manager-image>
bootflash:nuova-sim-mgmt-nsg.0.1.0.001.bin
Example:
switch(boot)#
config terminal
Enter configuration commands, one per line.
End with CNTL/Z.
switch(boot)(config)#
interface mgmt 0
switch(boot)(config-if)#
ip address 10.0.0.2 255.255.255.0
switch(boot)(config-if)#
no shutdown
switch(boot)(config-if)#
exit
switch(boot)(config)#
ip default-gateway 10.0.0.1
switch(boot)(config)#
exit
switch(boot)#
copy tftp://192.168.1.2/recovery_images/fxos-k9-system.5.0.3.N2.4.11.69.SPA
bootflash:
Trying to connect to tftp server......
Connection to server Established. Copying Started.....
/
TFTP get operation was successful
Copy complete, now saving to disk (please wait)...
switch(boot)#
copy tftp://192.168.1.2/recovery_images/fxos-k9-manager.4.1.1.69.SPA
bootflash:
Trying to connect to tftp server......
Connection to server Established. Copying Started.....
/
TFTP get operation was successful
Copy complete, now saving to disk (please wait)...
92
Cisco FXOS CLI Configuration Guide, 2.2(1)
System Administration
Recovering from a Software Failure
switch(boot)#
copy bootflash:fxos-k9-manager.4.1.1.69.SPA
bootflash:nuova-sim-mgmt-nsg.0.1.0.001.bin
Copy complete, now saving to disk (please wait)...
switch(boot)#
Step 4
Load the system image that you just downloaded: switch(boot)# load bootflash:<system-image>
Example:
switch(boot)# load bootflash:fxos-k9-system.5.0.3.N2.4.11.69.SPA
Uncompressing system image: bootflash:/fxos-k9-system.5.0.3.N2.4.11.69.SPA
Manager image digital signature verification successful
...
System is coming up ... Please wait ...
Cisco FPR Series Security Appliance
FP9300-A login:
Step 5
After the recovery images have loaded, enter the following commands to prevent the system from trying to load the prior images:
Note
This step should be performed immediately after loading the recovery images.
FP9300-A#
scope org
FP9300-A /org #
scope fw-platform-pack default
FP9300-A /org/fw-platform-pack #
set platform-bundle-version ""
Warning: Set platform version to empty will result software/firmware incompatibility issue.
FP9300-A /org/fw-platform-pack* #
commit-buffer
Step 6
Download and install the Platform Bundle image that you want to use on your FXOS chassis. For more information, see
.
Example:
FP9300-A# scope firmware
FP9300-A /firmware # show download-task
Download task:
File Name Protocol Server Port Userid State
--------- -------- --------------- ---------- --------------- ----fxos-k9.2.1.1.73.SPA
Tftp 192.168.1.2
0 Downloaded
FP9300-A /firmware # show package fxos-k9.2.1.1.73.SPA detail
Firmware Package fxos-k9.2.1.1.73.SPA:
Version: 2.1(1.73)
Type: Platform Bundle
State: Active
Time Stamp: 2012-01-01T07:40:28.000
Build Date: 2017-02-28 13:51:08 UTC
FP9300-A /firmware #
Cisco FXOS CLI Configuration Guide, 2.2(1)
93
System Administration
Recovering from a Corrupted File System
Recovering from a Corrupted File System
Before You Begin
If the Supervisor’s onboard flash becomes corrupted and the system is no longer able to start successfully, you can use the following procedure to recover the system. To complete this process you need to TFTP boot a kickstart image, reformat the flash, download new system and manager images, and then boot using the new images.
Note
This procedure includes reformatting the system flash. As a result, you will need to completely reconfigure your system after it has been recovered.
The recovery images for a specific FXOS version can be obtained from Cisco.com at one of the following locations:
• Firepower 9300— https://software.cisco.com/portal/pub/download/portal/ select.html?&mdfid=286287252&flowid=77282&softwareid=286287263
• Firepower 4100 Series— https://software.cisco.com/portal/pub/download/portal/ select.html?&mdfid=286305187&flowid=79423&softwareid=286287263
The recovery images include three separate files. For example, below are the recovery images for FXOS
2.1.1.64.
Recovery image (kickstart) for FX-OS 2.1.1.64.
fxos-k9-kickstart.5.0.3.N2.4.11.63.SPA
Recovery image (manager) for FX-OS 2.1.1.64.
fxos-k9-manager.4.1.1.63.SPA
Recovery image (system) for FX-OS 2.1.1.64.
fxos-k9-system.5.0.3.N2.4.11.63.SPA
Procedure
Step 1
Access ROMMON: a) Connect to the console port.
b) Reboot the system.
The system will start loading and during the process display a countdown timer.
c) Press the Escape key during the countdown to enter ROMMON mode.
Example:
Cisco System ROMMON, version 1.0.09, RELEASE SOFTWARE
Copright (c) 1994-2015 by Cisco Systems, Inc.
Compiled Sun 01/01/1999 23:59:59:59.99 by user
Current image running: Boot ROM0
Last reset cause: LocalSoft
DIMM Slot 0 : Present
DIMM Slot 1 : Present
No USB drive !!
Platform FPR9K-SUP with 16384 Mbytes of main memory
94
Cisco FXOS CLI Configuration Guide, 2.2(1)
System Administration
Recovering from a Corrupted File System
MAC Address aa:aa:aa:aa:aa:aa find the string ! boot bootflash:/installables/switch/fxos-k9-kickstart.5.0.3.N2.0.00.00.SPA
bootflash:/installables/switch/fxos-k9-system.5.0.3.N2.0.00.00.SPA
Use BREAK, ESC or CTRL+L to interrupt boot.
use SPACE to begin boot immediately.
Boot interrupted.
rommon 1 >
Step 2
TFTP boot a kickstart image: a) Verify that the management IP address, management netmask, and gateway IP address are set correctly.
You can see their values using the set command. You can test the connectivity to the TFTP server using the ping command.
rommon 1 >
set
ADDRESS=
NETMASK=
GATEWAY=
SERVER=
IMAGE=
PS1="ROMMON ! > " rommon >
address <ip-address> rommon > netmask <network-mask> rommon > gateway <default-gateway> b) Copy the kickstart image to a TFTP directory that is accessible from your FXOS chassis.
Note
The kickstart image version number will not match the bundle version number. Information showing the mapping between your FXOS version and the kickstart image can be found on the
Cisco.com software download page.
c) Boot the image from ROMMON using the boot command:
boot tftp://<IP address>/<path to image>
Note
You can also boot the kickstart from ROMMON using a USB media device inserted into the USB slot on the front panel of the FXOS chassis. If the USB device is inserted while the system is running, you will need to reboot the system before it will recognize the USB device.
The system will display a series of #'s indicating that the image is being received and will then load the kickstart image.
Example:
rommon 1 >
set
ADDRESS=
NETMASK=
GATEWAY=
SERVER=
IMAGE=
PS1="ROMMON ! > " rommon 2 >
address 10.0.0.2
rommon 3 >
netmask 255.255.255.0
rommon 4 >
gateway 10.0.0.1
rommon 5 >
ping 10.0.0.2
..!!!!!!!!!!
Success rate is 100 percent (10/10) rommon 6 >
ping 192.168.1.2
..!!!!!!!!!!
Success rate is 100 percent (10/10) rommon 7 >
boot tftp://192.168.1.2/fxos-k9-kickstart.5.0.3.N2.1.11.1.SPA
Cisco FXOS CLI Configuration Guide, 2.2(1)
95
System Administration
Recovering from a Corrupted File System
ADDRESS: 10.0.0.2
NETMASK: 255.255.255.0
GATEWAY: 10.0.0.1
SERVER: 192.168.1.2
IMAGE: fxos-k9-kickstart.5.0.3.N2.1.11.1.SPA
TFTP_MACADDR: aa:aa:aa:aa:aa:aa
............................................................................
Receiving fxos-k9-kickstart.5.0.3.N2.1.11.1.SPA from 192.168.1.2
###############################################################################
###############################################################################
#############################################################################
File reception completed.
Step 3
After the kickstart image has loaded, reformat the flash using the init system command.
The init system command erases the contents of the flash including all software images downloaded to the system and all configurations on the system. The command takes approximately 20-30 minutes to complete.
Example:
switch(boot)# init system
This command is going to erase your startup-config, licenses as well as the contents of your bootflash:.
Do you want to continue? (y/n) [n] y
Detected 32GB flash...
Initializing the system mke2fs 1.35 (28-Feb-2004)
Checking for bad blocks (read-only test):
Initializing startup-config and licenses mke2fs 1.35 (28-Feb-2004)
Checking for bad blocks (read-only test): mke2fs 1.35 (28-Feb-2004)
Checking for bad blocks (read-only test): mke2fs 1.35 (28-Feb-2004)
Checking for bad blocks (read-only test):
Formatting bootflash: mke2fs 1.35 (28-Feb-2004)
Checking for bad blocks (read-only test):
Formatting SAM partition: mke2fs 1.35 (28-Feb-2004)
Checking for bad blocks (read-only test):
Formatting Workspace partition: mke2fs 1.35 (28-Feb-2004)
Checking for bad blocks (read-only test):
Formatting Sysdebug partition: mke2fs 1.35 (28-Feb-2004)
Checking for bad blocks (read-only test): done done done done done done done done
Step 4
Download the recovery images to the FXOS chassis: a) To download the recovery images you will need to set the management IP address and gateway. You cannot download these images via USB.
switch(boot)#
config terminal
switch(boot)(config)#
interface mgmt 0
switch(boot)(config-if)#
ip address <ip address> <netmask> switch(boot)(config-if)#
no shutdown
switch(boot)(config-if)#
exit
switch(boot)(config)# ip default-gateway <gateway> switch(boot)(config)#
exit
96
Cisco FXOS CLI Configuration Guide, 2.2(1)
System Administration
Recovering from a Corrupted File System
b) Copy all three recovery images from the remote server to the bootflash: switch(boot)# copy URL bootflash:
Specify the URL for the file being imported using one of the following syntax:
• ftp://username@hostname/path/image_name
• scp://username@hostname/path/image_name
• sftp://username@hostname/path/image_name
• tftp://hostname/path/image_name
Example:
switch(boot)#
copy scp://<username>@192.168.1.2/recovery_images/fxos-k9-kickstart.5.0.3.N2.4.11.69.SPA
bootflash:
switch(boot)#
copy scp://<username>@192.168.1.2/recovery_images/fxos-k9-system.5.0.3.N2.4.11.69.SPA
bootflash:
switch(boot)#
copy scp://<username>@192.168.1.2/recovery_images/fxos-k9-manager.4.1.1.69.SPA
bootflash:
c) After the images have been successfully copied to the FXOS chassis, make a symlink to the manager image from nuova-sim-mgmt-nsg.0.1.0.001.bin. This link tells the load mechanism which manager image to load. The symlink name should always be nuova-sim-mgmt-nsg.0.1.0.001.bin regardless of what image you are trying to load.
switch(boot)# copy bootflash:<manager-image>
bootflash:nuova-sim-mgmt-nsg.0.1.0.001.bin
Example:
switch(boot)#
config terminal
Enter configuration commands, one per line.
End with CNTL/Z.
switch(boot)(config)#
interface mgmt 0
switch(boot)(config-if)#
ip address 10.0.0.2 255.255.255.0
switch(boot)(config-if)#
no shutdown
switch(boot)(config-if)#
exit
switch(boot)(config)#
ip default-gateway 10.0.0.1
switch(boot)(config)#
exit
switch(boot)#
copy tftp://192.168.1.2/recovery_images/fxos-k9-kickstart.5.0.3.N2.4.11.69.SPA
bootflash:
Trying to connect to tftp server......
Connection to server Established. Copying Started.....
/
TFTP get operation was successful
Copy complete, now saving to disk (please wait)...
switch(boot)#
copy tftp://192.168.1.2/recovery_images/fxos-k9-system.5.0.3.N2.4.11.69.SPA
bootflash:
Trying to connect to tftp server......
Connection to server Established. Copying Started.....
/
TFTP get operation was successful
Copy complete, now saving to disk (please wait)...
switch(boot)#
copy
Cisco FXOS CLI Configuration Guide, 2.2(1)
97
System Administration
Recovering from a Corrupted File System tftp://192.168.1.2/recovery_images/fxos-k9-manager.4.1.1.69.SPA
bootflash:
Trying to connect to tftp server......
Connection to server Established. Copying Started.....
/
TFTP get operation was successful
Copy complete, now saving to disk (please wait)...
switch(boot)#
copy bootflash:fxos-k9-manager.4.1.1.69.SPA
bootflash:nuova-sim-mgmt-nsg.0.1.0.001.bin
Copy complete, now saving to disk (please wait)...
switch(boot)#
Step 5
Reload the switch: switch(boot)#
reload
Example:
switch(boot)#
reload
This command will reboot this supervisor module. (y/n) ?
y
[ 1866.310313] Restarting system.
!!
Rommon image verified successfully !!
Cisco System ROMMON, Version 1.0.11, RELEASE SOFTWARE
Copyright (c) 1994-2016 by Cisco Systems, Inc.
Compiled Wed 11/23/2016 11:23:23.47 by builder
Current image running: Boot ROM1
Last reset cause: ResetRequest
DIMM Slot 0 : Present
DIMM Slot 1 : Present
No USB drive !!
BIOS has been locked !!
Platform FPR9K-SUP with 16384 Mbytes of main memory
MAC Address: bb:aa:77:aa:aa:bb autoboot: Can not find autoboot file 'menu.lst.local'
Or can not find correct boot string !!
rommon 1 >
Step 6
Boot from the kickstart and system images: rommon 1 > boot <kickstart-image> <system-image>
Note
You will likely see license manager failure messages while the system image is loading. These messages can be safely ignored.
Example:
rommon 1 > dir
Directory of: bootflash:\
01/01/12 12:33a <DIR>
01/01/12 12:33a <DIR>
01/01/12 12:16a <DIR>
01/01/12 12:27a
01/01/12 12:29a
01/01/12 12:31a
01/01/12 12:34a
4,096
4,096 ..
16,384 lost+found
34,333,696
330,646,465
250,643,172
330,646,465
4 File(s) 946,269,798 bytes
3 Dir(s)
.
fxos-k9-kickstart.5.0.3.N2.4.11.69.SPA
fxos-k9-manager.4.1.1.69.SPA
fxos-k9-system.5.0.3.N2.4.11.69.SPA
nuova-sim-mgmt-nsg.0.1.0.001.bin
rommon 2 > boot fxos-k9-kickstart.5.0.3.N2.4.11.69.SPA fxos-k9-system.5.0.3.N2.4.11.69.SPA
!!
Kickstart Image verified successfully !!
98
Cisco FXOS CLI Configuration Guide, 2.2(1)
System Administration
Recovering from a Corrupted File System
Linux version: 2.6.27.47 ([email protected]) #1 SMP Thu Nov 17 18:22:00 PST 2016
[ 0.000000] Fastboot Memory at 0c100000 of size 201326592
Usage: init 0123456SsQqAaBbCcUu
INIT: version 2.86 booting
POST INIT Starts at Sun Jan 1 00:27:32 UTC 2012
S10mount-ramfs.supnuovaca Mounting /isan 3000m
Mounted /isan
Creating /callhome..
Mounting /callhome..
Creating /callhome done.
Callhome spool file system init done.
Platform is BS or QP MIO: 30
FPGA Version 0x00010500 FPGA Min Version 0x00000600
Checking all filesystems..r.r..r done.
Warning: switch is starting up with default configuration
Checking NVRAM block device ... done
.
FIPS power-on self-test passed
Unpack CMC Application software
Loading system software
Uncompressing system image: bootflash:/fxos-k9-system.5.0.3.N2.4.11.69.SPA
Manager image digital signature verification successful
...
System is coming up ... Please wait ...
nohup: appending output to `nohup.out'
---- Basic System Configuration Dialog ----
This setup utility will guide you through the basic configuration of the system. Only minimal configuration including IP connectivity to the Fabric interconnect and its clustering mode is performed through these steps.
Type Ctrl-C at any time to abort configuration and reboot system.
To back track or make modifications to already entered values, complete input till end of section and answer no when prompted to apply configuration.
You have chosen to setup a new Security Appliance. Continue? (y/n):
Step 7
After the images have loaded, the system will prompt you to enter initial configuration settings. For more information, see
Initial Configuration, on page 11
.
Step 8
Download the Platform Bundle image that you want to use on your FXOS chassis. The Platform Bundle image version should correspond with the images you used for recovering your system. For more information, see
.
Example:
FP9300-A# scope firmware
FP9300-A /firmware # show download-task
Download task:
File Name Protocol Server
Tftp 192.168.1.2
Port
0
Userid
FP9300-A /firmware # show package fxos-k9.2.1.1.73.SPA detail
State
--------- -------- --------------- ---------- --------------- ----fxos-k9.2.1.1.73.SPA
Downloaded
Firmware Package fxos-k9.2.1.1.73.SPA:
Version: 2.1(1.73)
Type: Platform Bundle
State: Active
Time Stamp: 2012-01-01T07:40:28.000
Cisco FXOS CLI Configuration Guide, 2.2(1)
99
System Administration
Recovering from a Corrupted File System
Build Date: 2017-02-28 13:51:08 UTC
FP9300-A /firmware #
Step 9
After the Platform Bundle has been successfully downloaded, you must manually activate the kickstart and system images so that they will be used when loading the system in the future. Automatic activation does not occur when using this procedure to recover from a corrupted file system because the running version matches the proposed startup version.
a) Set the scope for fabric-interconnect a:
FP9300-A#
scope fabric-interconnect a
b) Use the show version command to view the running kernel version and the running system version. You will use these strings to activate the images.
FP9300-A /fabric-interconnect #
show version
c) Enter the following command to activate the images:
FP9300-A /fabric-interconnect #
activate firmware
kernel-version <running_kernel_version> system-version <running_system_version> commit-buffer
Note
The server status might change to "Disk Failed." You do not need to worry about this message and can continue with this procedure.
d) Use the show version command to verify that the startup versions have been set correctly and to monitor the activation status for the images.
Important
Do not proceed to the next step until the status changes from "Activating" to "Ready."
FP9300-A /fabric-interconnect #
show version
Example:
FP9300-A /firmware #
top
FP9300-A#
scope fabric-interconnect a
FP9300-A /fabric-interconnect #
show version
Fabric Interconnect A:
Running-Kern-Vers: 5.0(3)N2(4.11.69)
Running-Sys-Vers: 5.0(3)N2(4.11.69)
Package-Vers: 2.1(1.73)
Startup-Kern-Vers:
Startup-Sys-Vers:
Act-Kern-Status: Ready
Act-Sys-Status: Ready
Bootloader-Vers:
FP9300-A /fabric-interconnect #
activate firmware kernel-version
5.0(3)N2(4.11.69) system-version 5.0(3)N2(4.11.69)
Warning: When committed this command will reset the end-point
FP9300-A /fabric-interconnect* #
commit-buffer
FP9300-A /fabric-interconnect #
show version
Fabric Interconnect A:
Running-Kern-Vers: 5.0(3)N2(4.11.69)
Running-Sys-Vers: 5.0(3)N2(4.11.69)
Package-Vers: 2.1(1.73)
Startup-Kern-Vers: 5.0(3)N2(4.11.69)
Startup-Sys-Vers: 5.0(3)N2(4.11.69)
Act-Kern-Status: Activating
Act-Sys-Status: Activating
Bootloader-Vers:
FP9300-A /fabric-interconnect #
show version
Fabric Interconnect A:
Running-Kern-Vers: 5.0(3)N2(4.11.69)
Running-Sys-Vers: 5.0(3)N2(4.11.69)
100
Cisco FXOS CLI Configuration Guide, 2.2(1)
System Administration
Recovering from a Corrupted File System
Package-Vers: 2.1(1.73)
Startup-Kern-Vers: 5.0(3)N2(4.11.69)
Startup-Sys-Vers: 5.0(3)N2(4.11.69)
Act-Kern-Status: Ready
Act-Sys-Status: Ready
Bootloader-Vers:
Step 10 Reboot the system:
Example:
FP9300-A /fabric-interconnect #
top
FP9300-A#
scope chassis 1
FP9300-A /chassis #
reboot no-prompt
Starting chassis reboot. Monitor progress with the command "show fsm status"
FP9300-A /chassis #
The system will power down each security module/engine before finally powering down and then restarting the FXOS chassis. This process takes approximately 5-10 minutes.
Step 11 Monitor the system status. The server status should go from "Discovery" to "Config" and then finally to "Ok".
Example:
FP9300-A#
show server status
Server Slot Status Overall Status Discovery
------- --------------------------------- --------------------- ---------
1/1
1/2
1/3
Equipped
Equipped
Empty
Discovery
Discovery
In Progress
In Progress
FP9300-A#
show server status
Server
1/2
1/3
Slot Status
Equipped
Empty
Overall Status Discovery
------- --------------------------------- --------------------- ---------
1/1 Equipped Config Complete
Config Complete
FP9300-A#
show server status
Server Slot Status Overall Status Discovery
------- --------------------------------- --------------------- ---------
1/1
1/2
1/3
Equipped
Equipped
Empty
Ok
Ok
Complete
Complete
When the Overall Status is "Ok" your system has been recovered. You must still reconfigure your security appliance (including license configuration) and re-create any logical devices. For more information:
• Firepower 9300 Quick Start Guides— http://www.cisco.com/go/firepower9300-quick
• Firepower 9300 Configuration Guides— http://www.cisco.com/go/firepower9300-config
• Firepower 4100 Series Quick Start Guides— http://www.cisco.com/go/firepower4100-quick
• Firepower 4100 Series Configuration Guides— http://www.cisco.com/go/firepower4100-config
Cisco FXOS CLI Configuration Guide, 2.2(1)
101
Recovering from a Corrupted File System
System Administration
102
Cisco FXOS CLI Configuration Guide, 2.2(1)
C H A P T E R
9
Platform Settings
•
Setting the Date and Time, page 103
•
•
•
•
•
•
•
Configuring DNS Servers, page 139
Setting the Date and Time
Use the CLI commands described below to configure the network time protocol (NTP) on the system, to set the date and time manually, or to view the current system time.
NTP settings are automatically synced between the FXOS chassis and any logical devices installed on the chassis.
Note
If you are deploying Firepower Threat Defense on the FXOS chassis, you must configure NTP on the
FXOS chassis so that Smart Licensing will work properly and to ensure proper timestamps on device registrations. You should use the same NTP server for the FXOS chassis and the Firepower Management
Center.
If you are using NTP, you can view the overall synchronization status on the Current Time tab, or you can view the synchronization status for each configured NTP server by looking at the Server Status field in the
NTP Server table on the Time Synchronization tab. If the system is unable to synchronize with a particular
NTP server, you can hover over the information icon next to the Server Status for more information.
Cisco FXOS CLI Configuration Guide, 2.2(1)
103
Platform Settings
Viewing the Configured Date and Time
Viewing the Configured Date and Time
Procedure
Step 1
Connect to the FXOS CLI (see
Accessing the FXOS CLI, on page 13
).
Step 2
To view the configured time zone:
Firepower-chassis# show timezone
Step 3
To view the configured date and time:
Firepower-chassis# show clock
The following example shows how to display the configured time zone and current system date and time:
Firepower-chassis#
show timezone
Timezone: America/Chicago
Firepower-chassis#
show clock
Thu Jun 2 12:40:42 CDT 2016
Firepower-chassis#
Setting the Time Zone
Procedure
Step 1
Enter system mode:
Firepower-chassis# scope system
Step 2
Enter system services mode:
Firepower-chassis /system # scope services
Step 3
Set the time zone:
Firepower-chassis /system/services # set timezone
At this point, you are prompted to enter a number corresponding to your continent, country, and time zone region. Enter the appropriate information at each prompt.
When you have finished specifying the location information, you are prompted to confirm that the correct time zone information is being set. Enter 1 (yes) to confirm, or 2 (no) to cancel the operation.
Step 4
To view the configured time zone:
Firepower-chassis /system/services # top
Firepower-chassis# show timezone
The following example configures the time zone to the Pacific time zone region, commits the transaction, and displays the configured time zone:
Firepower-chassis#
scope system
Firepower-chassis /system #
scope services
Firepower-chassis /system/services #
set timezone
Please identify a location so that time zone rules can be set correctly.
104
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Setting the Time Zone
Please select a continent or ocean.
1) Africa
2) Americas
3) Antarctica
4) Arctic Ocean 7) Australia
5) Asia 8) Europe
6) Atlantic Ocean 9) Indian Ocean
#?
2
Please select a country.
1) Anguilla
2) Antigua & Barbuda
3) Argentina
4) Aruba
5) Bahamas
28) Haiti
29) Honduras
30) Jamaica
31) Martinique
32) Mexico
6) Barbados
7) Belize
8) Bolivia
9) Brazil
10) Canada
11) Caribbean Netherlands
12) Cayman Islands
13) Chile
14) Colombia
15) Costa Rica
16) Cuba
17) Curacao
18) Dominica
19) Dominican Republic
20) Ecuador
21) El Salvador
22) French Guiana
33) Montserrat
34) Nicaragua
35) Panama
36) Paraguay
37) Peru
38) Puerto Rico
39) St Barthelemy
40) St Kitts & Nevis
41) St Lucia
42) St Maarten (Dutch part)
43) St Martin (French part)
44) St Pierre & Miquelon
45) St Vincent
46) Suriname
47) Trinidad & Tobago
48) Turks & Caicos Is
49) United States
10) Pacific Ocean
23) Greenland
24) Grenada
25) Guadeloupe
26) Guatemala
50) Uruguay
51) Venezuela
52) Virgin Islands (UK)
53) Virgin Islands (US)
27) Guyana
#?
49
Please select one of the following time zone regions.
1) Eastern Time
2) Eastern Time - Michigan - most locations
3) Eastern Time - Kentucky - Louisville area
4) Eastern Time - Kentucky - Wayne County
5) Eastern Time - Indiana - most locations
6) Eastern Time - Indiana - Daviess, Dubois, Knox & Martin Counties
7) Eastern Time - Indiana - Pulaski County
8) Eastern Time - Indiana - Crawford County
9) Eastern Time - Indiana - Pike County
10) Eastern Time - Indiana - Switzerland County
11) Central Time
12) Central Time - Indiana - Perry County
13) Central Time - Indiana - Starke County
14) Central Time - Michigan - Dickinson, Gogebic, Iron & Menominee Counties
15) Central Time - North Dakota - Oliver County
16) Central Time - North Dakota - Morton County (except Mandan area)
17) Central Time - North Dakota - Mercer County
18) Mountain Time
19) Mountain Time - south Idaho & east Oregon
20) Mountain Standard Time - Arizona (except Navajo)
21) Pacific Time
22) Pacific Standard Time - Annette Island, Alaska
23) Alaska Time
24) Alaska Time - Alaska panhandle
25) Alaska Time - southeast Alaska panhandle
26) Alaska Time - Alaska panhandle neck
27) Alaska Time - west Alaska
28) Aleutian Islands
29) Hawaii
#?
21
The following information has been given:
United States
Pacific Time
Therefore timezone 'America/Los_Angeles' will be set.
Local time is now: Wed Jun 24 07:39:25 PDT 2015.
Cisco FXOS CLI Configuration Guide, 2.2(1)
105
Platform Settings
Setting the Date and Time Using NTP
Universal Time is now: Wed Jun 24 14:39:25 UTC 2015.
Is the above information OK?
1) Yes
2) No
#?
1
Firepower-chassis /system/services* #
commit-buffer
Firepower-chassis /system/services #
top
Firepower-chassis#
show timezone
Timezone: America/Los_Angeles (Pacific Time)
Firepower-chassis#
Setting the Date and Time Using NTP
NTP is used to implement a hierarchical system of servers that provide a precisely synchronized time among network systems. This kind of accuracy is required for time-sensitive operations, such as validating CRLs, which include a precise time stamp. You can configure up to four NTP servers.
Procedure
Step 1
Enter system mode:
Firepower-chassis# scope system
Step 2
Enter system services mode:
Firepower-chassis /system # scope services
Step 3
Configure the system to use the NTP server with the specified hostname, IPv4, or IPv6 address:
Firepower-chassis /system/services # create ntp-server {hostname | ip-addr | ip6-addr}
Step 4
Commit the transaction to the system configuration:
Firepower-chassis /system/services # commit-buffer
Step 5
To view the synchronization status for all configured NTP servers:
Firepower-chassis /system/services # show ntp-server
Step 6
To view the synchronization status for a specific NTP server:
Firepower-chassis /system/services # scope ntp-server {hostname | ip-addr | ip6-addr}
Firepower-chassis /system/services/ntp-server # show detail
The following example configures an NTP server with the IP address 192.168.200.101 and commits the transaction:
Firepower-chassis#
scope system
Firepower-chassis /system #
scope services
Firepower-chassis /system/services #
create ntp-server 192.168.200.101
Firepower-chassis /system/services* #
commit-buffer
Firepower-chassis /system/services #
The following example configures an NTP server with the IPv6 address 4001::6 and commits the transaction:
Firepower-chassis#
scope system
Firepower-chassis /system #
scope services
Firepower-chassis /system/services #
create ntp-server 4001::6
Firepower-chassis /system/services* #
commit-buffer
Firepower-chassis /system/services #
106
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Deleting an NTP Server
Deleting an NTP Server
Procedure
Step 1
Enter system mode:
Firepower-chassis# scope system
Step 2
Enter system services mode:
Firepower-chassis /system # scope services
Step 3
Delete the NTP server with the specified hostname, IPv4, or IPv6 address:
Firepower-chassis /system/services # delete ntp-server {hostname | ip-addr | ip6-addr}
Step 4
Commit the transaction to the system configuration:
Firepower-chassis /system/services # commit-buffer
The following example deletes the NTP server with the IP address 192.168.200.101 and commits the transaction:
Firepower-chassis#
scope system
Firepower-chassis /system #
scope services
Firepower-chassis /system/services #
delete ntp-server 192.168.200.101
Firepower-chassis /system/services* #
commit-buffer
Firepower-chassis /system/services #
The following example deletes the NTP server with the IPv6 address 4001::6 and commits the transaction:
Firepower-chassis#
scope system
Firepower-chassis /system #
scope services
Firepower-chassis /system/services #
delete ntp-server 4001::6
Firepower-chassis /system/services* #
commit-buffer
Firepower-chassis /system/services #
Setting the Date and Time Manually
This section describes how to set the date and time manually on the Firepower chassis. System clock modifications take effect immediately.
Note
If the system clock is currently being synchronized with an NTP server, you will not be able to set the date and time manually.
Procedure
Step 1
Enter system mode:
Firepower-chassis# scope system
Step 2
Enter system services mode:
Firepower-chassis /system # scope services
Cisco FXOS CLI Configuration Guide, 2.2(1)
107
Platform Settings
Configuring SSH
Step 3
Configure the system clock:
Firepower-chassis /system/services # set clock month day year hour min sec
For month, use the first three digits of the month. Hours must be entered using the 24-hour format, where 7 pm would be entered as 19.
System clock modifications take effect immediately. You do not need to commit the buffer.
The following example configures the system clock:
Firepower-chassis#
scope system
Firepower-chassis /system #
scope services
Firepower-chassis /system/services #
set clock jun 24 2015 15 27 00
Firepower-chassis /system/services #
Configuring SSH
The following procedure describes how to enable or disable SSH access to the Firepower chassis. SSH is enabled by default.
Procedure
Step 1
Enter system mode:
Firepower-chassis # scope system
Step 2
Enter system services mode:
Firepower-chassis /system # scope services
Step 3
To configure SSH access to the Firepower chassis, do one of the following:
• To allow SSH access to the Firepower chassis, enter the following command:
Firepower-chassis /system/services # enable ssh-server
• To disallow SSH access to the Firepower chassis, enter the following command:
Firepower-chassis /system/services # disable ssh-server
Step 4
Commit the transaction to the system configuration:
Firepower /system/services # commit-buffer
The following example enables SSH access to the Firepower chassis and commits the transaction:
Firepower#
scope system
Firepower /system #
scope services
Firepower /system/services #
enable ssh-server
Firepower /system/services* #
commit-buffer
Firepower /system/services #
108
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Configuring Telnet
Configuring Telnet
The following procedure describes how to enable or disable Telnet access to the Firepower chassis. Telnet is disabled by default.
Note
Telnet configuration is currently only available using the CLI.
Procedure
Step 1
Enter system mode:
Firepower-chassis # scope system
Step 2
Enter system services mode:
Firepower-chassis /system # scope services
Step 3
To configure Telnet access to the Firepower chassis, do one of the following:
• To allow Telnet access to the Firepower chassis, enter the following command:
Firepower-chassis /system/services # enable telnet-server
• To disallow Telnet access to the Firepower chassis, enter the following command:
Firepower-chassis /system/services # disable telnet-server
Step 4
Commit the transaction to the system configuration:
Firepower /system/services # commit-buffer
The following example enables Telnet and commits the transaction:
Firepower-chassis#
scope system
Firepower-chassis /system #
scope services
Firepower-chassis /services #
enable telnet-server
Firepower-chassis /services* #
commit-buffer
Firepower-chassis /services #
Configuring SNMP
This section describes how to configure the Simple Network Management Protocol (SNMP) on the Firepower chassis. See the following topics for more information:
About SNMP
The Simple Network Management Protocol (SNMP) is an application-layer protocol that provides a message format for communication between SNMP managers and agents. SNMP provides a standardized framework and a common language used for the monitoring and management of devices in a network.
The SNMP framework consists of three parts:
Cisco FXOS CLI Configuration Guide, 2.2(1)
109
Platform Settings
SNMP Notifications
• An SNMP manager—The system used to control and monitor the activities of network devices using
SNMP.
• An SNMP agent—The software component within the Firepower chassis that maintains the data for the
Firepower chassis and reports the data, as needed, to the SNMP manager. The Firepower chassis includes the agent and a collection of MIBs. To enable the SNMP agent and create the relationship between the manager and agent, enable and configure SNMP in the Firepower Chassis Manager or the FXOS CLI.
• A managed information base (MIB)—The collection of managed objects on the SNMP agent.
The Firepower chassis supports SNMPv1, SNMPv2c and SNMPv3. Both SNMPv1 and SNMPv2c use a community-based form of security. SNMP is defined in the following:
• RFC 3410 ( http://tools.ietf.org/html/rfc3410 )
• RFC 3411 ( http://tools.ietf.org/html/rfc3411 )
• RFC 3412 ( http://tools.ietf.org/html/rfc3412 )
• RFC 3413 ( http://tools.ietf.org/html/rfc3413 )
• RFC 3414 ( http://tools.ietf.org/html/rfc3414 )
• RFC 3415 ( http://tools.ietf.org/html/rfc3415 )
• RFC 3416 ( http://tools.ietf.org/html/rfc3416 )
• RFC 3417 ( http://tools.ietf.org/html/rfc3417 )
• RFC 3418 ( http://tools.ietf.org/html/rfc3418 )
• RFC 3584 ( http://tools.ietf.org/html/rfc3584 )
SNMP Notifications
A key feature of SNMP is the ability to generate notifications from an SNMP agent. These notifications do not require that requests be sent from the SNMP manager. Notifications can indicate improper user authentication, restarts, the closing of a connection, loss of connection to a neighbor router, or other significant events.
The Firepower chassis generates SNMP notifications as either traps or informs. Traps are less reliable than informs because the SNMP manager does not send any acknowledgment when it receives a trap, and the
Firepower chassis cannot determine if the trap was received. An SNMP manager that receives an inform request acknowledges the message with an SNMP response protocol data unit (PDU). If the Firepower chassis does not receive the PDU, it can send the inform request again.
SNMP Security Levels and Privileges
SNMPv1, SNMPv2c, and SNMPv3 each represent a different security model. The security model combines with the selected security level to determine the security mechanism applied when the SNMP message is processed.
The security level determines the privileges required to view the message associated with an SNMP trap. The privilege level determines whether the message needs to be protected from disclosure or authenticated. The
110
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Supported Combinations of SNMP Security Models and Levels
supported security level depends upon which security model is implemented. SNMP security levels support one or more of the following privileges:
• noAuthNoPriv—No authentication or encryption
• authNoPriv—Authentication but no encryption
• authPriv—Authentication and encryption
SNMPv3 provides for both security models and security levels. A security model is an authentication strategy that is set up for a user and the role in which the user resides. A security level is the permitted level of security within a security model. A combination of a security model and a security level determines which security mechanism is employed when handling an SNMP packet.
Supported Combinations of SNMP Security Models and Levels
The following table identifies what the combinations of security models and levels mean.
Table 8: SNMP Security Models and Levels
Model
v1
Level
noAuthNoPriv
Authentication
Community string
Encryption
No v2c v3 v3 noAuthNoPriv noAuthNoPriv authNoPriv
Community string No
Username
HMAC-SHA
No
No
What Happens
Uses a community string match for authentication.
Uses a community string match for authentication.
Uses a username match for authentication.
Provides authentication based on the HMAC
Secure Hash
Algorithm (SHA).
Cisco FXOS CLI Configuration Guide, 2.2(1)
111
Platform Settings
SNMPv3 Security Features
Model
v3
Level
authPriv
Authentication
HMAC-SHA
Encryption
DES
What Happens
Provides authentication based on the HMAC-SHA algorithm. Provides
Data Encryption
Standard (DES)
56-bit encryption in addition to authentication based on the Cipher Block
Chaining (CBC)
DES (DES-56) standard.
SNMPv3 Security Features
SNMPv3 provides secure access to devices by a combination of authenticating and encrypting frames over the network. SNMPv3 authorizes management operations only by configured users and encrypts SNMP messages. The SNMPv3 User-Based Security Model (USM) refers to SNMP message-level security and offers the following services:
• Message integrity—Ensures that messages have not been altered or destroyed in an unauthorized manner and that data sequences have not been altered to an extent greater than can occur non-maliciously.
• Message origin authentication—Ensures that the claimed identity of the user on whose behalf received data was originated is confirmed.
• Message confidentiality and encryption—Ensures that information is not made available or disclosed to unauthorized individuals, entities, or processes.
SNMP Support
The Firepower chassis provides the following support for SNMP:
Support for MIBs
The Firepower chassis supports read-only access to MIBs.
Authentication Protocol for SNMPv3 Users
The Firepower chassis supports the HMAC-SHA-96 (SHA) authentication protocol for SNMPv3 users.
AES Privacy Protocol for SNMPv3 Users
The Firepower chassis uses Advanced Encryption Standard (AES) as one of the privacy protocols for SNMPv3 message encryption and conforms with RFC 3826.
112
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Enabling SNMP and Configuring SNMP Properties
The privacy password, or priv option, offers a choice of DES or 128-bit AES encryption for SNMP security encryption. If you enable AES-128 configuration and include a privacy password for an SNMPv3 user, the
Firepower chassis uses the privacy password to generate a 128-bit AES key. The AES privacy password can have a minimum of eight characters. If the passphrases are specified in clear text, you can specify a maximum of 64 characters.
Enabling SNMP and Configuring SNMP Properties
Procedure
Step 1
Enter monitoring mode:
Firepower-chassis# scope monitoring
Step 2
Enable SNMP:
Firepower-chassis /monitoring # enable snmp
Step 3
Enter snmp community mode:
Firepower-chassis /monitoring # set snmp community
After you enter the set snmp community command, you are prompted to enter the SNMP community.
Step 4
Specify the SNMP community. Use the community name as a password. The community name can be any alphanumeric string up to 32 characters.
Firepower-chassis /monitoring # Enter a snmp community: community-name
Step 5
Specify the system contact person responsible for SNMP. The system contact name can be any alphanumeric string up to 255 characters, such as an email address or name and telephone number.
Firepower-chassis /monitoring # set snmp syscontact system-contact-name
Step 6
Specify the location of the host on which the SNMP agent (server) runs. The system location name can be any alphanumeric string up to 512 characters.
Firepower-chassis /monitoring # set snmp syslocation system-location-name
Step 7
Commit the transaction to the system configuration:
Firepower-chassis /monitoring # commit-buffer
The following example enables SNMP, configures an SNMP community named SnmpCommSystem2, configures a system contact named contactperson, configures a contact location named systemlocation, and commits the transaction:
Firepower-chassis#
scope monitoring
Firepower-chassis /monitoring #
enable snmp
Firepower-chassis /monitoring* #
set snmp community
Enter a snmp community:
SnmpCommSystem2
Firepower-chassis /monitoring* #
set snmp syscontact contactperson1
Firepower-chassis /monitoring* #
set snmp syslocation systemlocation
Firepower-chassis /monitoring* #
commit-buffer
Firepower-chassis /monitoring #
What to Do Next
Create SNMP traps and users.
Cisco FXOS CLI Configuration Guide, 2.2(1)
113
Platform Settings
Creating an SNMP Trap
Creating an SNMP Trap
Procedure
Step 1
Enter monitoring mode:
Firepower-chassis# scope monitoring
Step 2
Enable SNMP:
Firepower-chassis /monitoring # enable snmp
Step 3
Create an SNMP trap with the specified host name, IPv4 address, or IPv6 address.
Firepower-chassis /monitoring # create snmp-trap {hostname | ip-addr | ip6-addr}
Step 4
Specify the SNMP community name to be used for the SNMP trap:
Firepower-chassis /monitoring/snmp-trap # set community community-name
Step 5
Specify the port to be used for the SNMP trap:
Firepower-chassis /monitoring/snmp-trap # set port port-num
Step 6
Specify the SNMP version and model used for the trap:
Firepower-chassis /monitoring/snmp-trap # set version {v1 | v2c | v3}
Step 7
(Optional) Specify the type of trap to send.
Firepower-chassis /monitoring/snmp-trap # set notificationtype {traps | informs}
This can be:
• traps if you select v2c or v3 for the version.
• informs if you select v2c for the version.
Note
An inform notification can be sent only if you select v2c for the version.
Step 8
(Optional) If you select v3 for the version, specify the privilege associated with the trap:
Firepower-chassis /monitoring/snmp-trap # set v3privilege {auth | noauth | priv}
This can be:
• auth—Authentication but no encryption
• noauth—No authentication or encryption
• priv—Authentication and encryption
Step 9
Commit the transaction to the system configuration:
Firepower-chassis /monitoring/snmp-trap # commit-buffer
The following example enables SNMP, creates an SNMP trap using an IPv4 address, specifies that the trap will use the SnmpCommSystem2 community on port 2, sets the version to v3, sets the notification type to traps, sets the v3 privilege to priv, and commits the transaction:
Firepower-chassis#
scope monitoring
Firepower-chassis /monitoring #
enable snmp
114
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Deleting an SNMP Trap
Firepower-chassis /monitoring* #
create snmp-trap 192.168.100.112
Firepower-chassis /monitoring/snmp-trap* #
set community SnmpCommSystem2
Firepower-chassis /monitoring/snmp-trap* #
set port 2
Firepower-chassis /monitoring/snmp-trap* #
set version v3
Firepower-chassis /monitoring/snmp-trap* #
set notificationtype traps
Firepower-chassis /monitoring/snmp-trap* #
set v3privilege priv
Firepower-chassis /monitoring/snmp-trap* #
commit-buffer
Firepower-chassis /monitoring/snmp-trap #
The following example enables SNMP, creates an SNMP trap using an IPv6 address, specifies that the trap will use the SnmpCommSystem3 community on port 2, sets the version to v3, sets the notification type to traps, sets the v3 privilege to priv, and commits the transaction:
Firepower-chassis#
scope monitoring
Firepower-chassis /monitoring #
enable snmp
Firepower-chassis /monitoring* #
create snmp-trap 2001::1
Firepower-chassis /monitoring/snmp-trap* #
set community SnmpCommSystem3
Firepower-chassis /monitoring/snmp-trap* #
set port 2
Firepower-chassis /monitoring/snmp-trap* #
set version v3
Firepower-chassis /monitoring/snmp-trap* #
set notificationtype traps
Firepower-chassis /monitoring/snmp-trap* #
set v3privilege priv
Firepower-chassis /monitoring/snmp-trap* #
commit-buffer
Firepower-chassis /monitoring/snmp-trap #
Deleting an SNMP Trap
Procedure
Step 1
Enter monitoring mode:
Firepower-chassis# scope monitoring
Step 2
Delete the SNMP trap with the specified hostname or IP address:
Firepower-chassis /monitoring # delete snmp-trap {hostname | ip-addr}
Step 3
Commit the transaction to the system configuration:
Firepower-chassis /monitoring # commit-buffer
The following example deletes the SNMP trap at IP address 192.168.100.112 and commits the transaction:
Firepower-chassis#
scope monitoring
Firepower-chassis /monitoring #
delete snmp-trap 192.168.100.112
Firepower-chassis /monitoring* #
commit-buffer
Firepower-chassis /monitoring #
Creating an SNMPv3 User
Procedure
Step 1
Enter monitoring mode:
Firepower-chassis# scope monitoring
Step 2
Enable SNMP:
Cisco FXOS CLI Configuration Guide, 2.2(1)
115
Platform Settings
Deleting an SNMPv3 User
Firepower-chassis /monitoring # enable snmp
Step 3
Create the specified SNMPv3 user:
Firepower-chassis /monitoring # create snmp-user user-name
After you enter the create snmp-user command, you are prompted to enter the password.
Step 4
Enable or disable the use of AES-128 encryption:
Firepower-chassis /monitoring/snmp-user # set aes-128 {no | yes}
By default, AES-128 encryption is disabled.
Step 5
Specify the user privacy password:
Firepower-chassis /monitoring/snmp-user # set priv-password
After you enter the set priv-password command, you are prompted to enter and confirm the privacy password.
Step 6
Commit the transaction to the system configuration:
Firepower-chassis /monitoring/snmp-user # commit-buffer
The following example enables SNMP, creates an SNMPv3 user named snmp-user14, enables AES-128 encryption, sets the password and privacy password, and commits the transaction:
Firepower-chassis#
scope monitoring
Firepower-chassis /monitoring #
enable snmp
Firepower-chassis /monitoring* #
create snmp-user snmp-user14
Password:
Firepower-chassis /monitoring/snmp-user* #
set aes-128 yes
Firepower-chassis /monitoring/snmp-user* #
set priv-password
Enter a password:
Confirm the password:
Firepower-chassis /monitoring/snmp-user* #
commit-buffer
Firepower-chassis /monitoring/snmp-user #
Deleting an SNMPv3 User
Procedure
Step 1
Enter monitoring mode:
Firepower-chassis# scope monitoring
Step 2
Delete the specified SNMPv3 user:
Firepower-chassis /monitoring # delete snmp-user user-name
Step 3
Commit the transaction to the system configuration:
Firepower-chassis /monitoring # commit-buffer
The following example deletes the SNMPv3 user named snmp-user14 and commits the transaction:
Firepower-chassis#
scope monitoring
Firepower-chassis /monitoring #
delete snmp-user snmp-user14
Firepower-chassis /monitoring* #
commit-buffer
Firepower-chassis /monitoring #
116
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Configuring HTTPS
Configuring HTTPS
This section describes how to configure HTTPS on the FXOS chassis.
Note
You can change the HTTPS port using Firepower Chassis Manager or the FXOS CLI. All other HTTPS configuration can only be done using the FXOS CLI.
Certificates, Key Rings, and Trusted Points
HTTPS uses components of the Public Key Infrastructure (PKI) to establish secure communications between two devices, such as a client's browser and the FXOS chassis.
Encryption Keys and Key Rings
Each PKI device holds a pair of asymmetric Rivest-Shamir-Adleman (RSA) encryption keys, one kept private and one made public, stored in an internal key ring. A message encrypted with either key can be decrypted with the other key. To send an encrypted message, the sender encrypts the message with the receiver's public key, and the receiver decrypts the message using its own private key. A sender can also prove its ownership of a public key by encrypting (also called 'signing') a known message with its own private key. If a receiver can successfully decrypt the message using the public key in question, the sender's possession of the corresponding private key is proven. Encryption keys can vary in length, with typical lengths from 512 bits to 2048 bits. In general, a longer key is more secure than a shorter key. FXOS provides a default key ring with an initial 2048-bit key pair, and allows you to create additional key rings.
The default key ring certificate must be manually regenerated if the cluster name changes or the certificate expires.
Certificates
To prepare for secure communications, two devices first exchange their digital certificates. A certificate is a file containing a device's public key along with signed information about the device's identity. To merely support encrypted communications, a device can generate its own key pair and its own self-signed certificate.
When a remote user connects to a device that presents a self-signed certificate, the user has no easy method to verify the identity of the device, and the user's browser will initially display an authentication warning. By default, FXOS contains a built-in self-signed certificate containing the public key from the default key ring.
Trusted Points
To provide stronger authentication for FXOS, you can obtain and install a third-party certificate from a trusted source, or trusted point, that affirms the identity of your device. The third-party certificate is signed by the issuing trusted point, which can be a root certificate authority (CA) or an intermediate CA or trust anchor that is part of a trust chain that leads to a root CA. To obtain a new certificate, you must generate a certificate request through FXOS and submit the request to a trusted point.
Important
The certificate must be in Base64 encoded X.509 (CER) format.
Cisco FXOS CLI Configuration Guide, 2.2(1)
117
Platform Settings
Creating a Key Ring
Creating a Key Ring
FXOS supports a maximum of 8 key rings, including the default key ring.
Procedure
Step 1
Enter security mode:
Firepower-chassis # scope security
Step 2
Create and name the key ring:
Firepower-chassis # create keyring keyring-name
Step 3
Set the SSL key length in bits:
Firepower-chassis # set modulus {mod1024 | mod1536 | mod2048 | mod512}
Step 4
Commit the transaction:
Firepower-chassis # commit-buffer
The following example creates a keyring with a key size of 1024 bits:
Firepower-chassis#
scope security
Firepower-chassis /security #
create keyring kr220
Firepower-chassis /security/keyring* #
set modulus mod1024
Firepower-chassis /security/keyring* #
commit-buffer
Firepower-chassis /security/keyring #
What to Do Next
Create a certificate request for this key ring.
Regenerating the Default Key Ring
The default key ring certificate must be manually regenerated if the cluster name changes or the certificate expires.
Procedure
Step 1
Enter security mode:
Firepower-chassis # scope security
Step 2
Enter key ring security mode for the default key ring:
Firepower-chassis /security # scope keyring default
Step 3
Regenerate the default key ring:
Firepower-chassis /security/keyring # set regenerate yes
Step 4
Commit the transaction:
Firepower-chassis # commit-buffer
118
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Creating a Certificate Request for a Key Ring
The following example regenerates the default key ring:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope keyring default
Firepower-chassis /security/keyring* #
set regenerate yes
Firepower-chassis /security/keyring* #
commit-buffer
Firepower-chassis /security/keyring #
Creating a Certificate Request for a Key Ring
Creating a Certificate Request for a Key Ring with Basic Options
Procedure
Step 1
Enter security mode:
Firepower-chassis # scope security
Step 2
Enter configuration mode for the key ring:
Firepower-chassis /security # scope keyring keyring-name
Step 3
Create a certificate request using the IPv4 or IPv6 address specified, or the name of the fabric interconnect.
You are prompted to enter a password for the certificate request.
Firepower-chassis /security/keyring # create certreq {ip [ipv4-addr | ipv6-v6] |subject-name name}
Step 4
Commit the transaction:
Firepower-chassis /security/keyring/certreq # commit-buffer
Step 5
Display the certificate request, which you can copy and send to a trust anchor or certificate authority:
Firepower-chassis /security/keyring # show certreq
The following example creates and displays a certificate request with an IPv4 address for a key ring, with basic options:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope keyring kr220
Firepower-chassis /security/keyring #
create certreq ip 192.168.200.123 subject-name sjc04
Certificate request password:
Confirm certificate request password:
Firepower-chassis /security/keyring* #
commit-buffer
Firepower-chassis /security/keyring #
show certreq
Certificate request subject name: sjc04
Certificate request ip address: 192.168.200.123
Certificate request e-mail name:
Certificate request country name:
State, province or county (full name):
Locality (eg, city):
Organization name (eg, company):
Organization Unit name (eg, section):
Request:
-----BEGIN CERTIFICATE REQUEST-----
MIIBfTCB5wIBADARMQ8wDQYDVQQDEwZzYW1jMDQwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBALpKn1t8qMZO4UGqILKFXQQc2c8b/vW2rnRF8OPhKbhghLA1YZ1F
JqcYEG5Yl1+vgohLBTd45s0GC8m4RTLJWHo4SwccAUXQ5Zngf45YtX1WsylwUWV4
0re/zgTk/WCd56RfOBvWR2Dtztu2pGA14sd761zLxt29K7R8mzj6CAUVAgMBAAGg
LTArBgkqhkiG9w0BCQ4xHjAcMBoGA1UdEQEB/wQQMA6CBnNhbWMwNIcECsEiXjAN
BgkqhkiG9w0BAQQFAAOBgQCsxN0qUHYGFoQw56RwQueLTNPnrndqUwuZHUO03Teg nhsyu4satpyiPqVV9viKZ+spvc6x5PWIcTWgHhH8BimOb/0OKuG8kwfIGGsEDlAv
Cisco FXOS CLI Configuration Guide, 2.2(1)
119
Platform Settings
Creating a Certificate Request for a Key Ring
TTYvUP+BZ9OFiPbRIA718S+V8ndXr1HejiQGxlDNqoN+odCXPc5kjoXD0lZTL09H
BA==
-----END CERTIFICATE REQUEST-----
Firepower-chassis /security/keyring #
What to Do Next
• Copy the text of the certificate request, including the BEGIN and END lines, and save it in a file. Send the file with the certificate request to a trust anchor or certificate authority to obtain a certificate for the key ring.
• Create a trusted point and set the certificate chain for the certificate of trust received from the trust anchor.
Creating a Certificate Request for a Key Ring with Advanced Options
Procedure
Step 1
Enter security mode:
Firepower-chassis # scope security
Step 2
Enter configuration mode for the key ring:
Firepower-chassis /security # scope keyring keyring-name
Step 3
Create a certificate request:
Firepower-chassis /security/keyring # create certreq
Step 4
Specify the country code of the country in which the company resides:
Firepower-chassis /security/keyring/certreq* # set country country name
Step 5
Specify the Domain Name Server (DNS) address associated with the request:
Firepower-chassis /security/keyring/certreq* # set dns DNS Name
Step 6
Specify the email address associated with the certificate request:
Firepower-chassis /security/keyring/certreq* # set e-mail E-mail name
Step 7
Specify the IP address of the FXOS chassis:
Firepower-chassis /security/keyring/certreq* # set ip {certificate request ip-address|certificate request
ip6-address }
Step 8
Specify the city or town in which the company requesting the certificate is headquartered:
Firepower-chassis /security/keyring/certreq* # set locality locality name (eg, city)
Step 9
Specify the organization requesting the certificate:
Firepower-chassis /security/keyring/certreq* # set org-name organization name
Step 10 Specify the organizational unit:
Firepower-chassis /security/keyring/certreq* # set org-unit-name organizational unit name
Step 11 Specify an optional password for the certificate request:
Firepower-chassis /security/keyring/certreq* # set password certificate request password
Step 12 Specify the state or province in which the company requesting the certificate is headquartered:
Firepower-chassis /security/keyring/certreq* # set state state, province or county
120
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Creating a Certificate Request for a Key Ring
Step 13 Specify the fully qualified domain name of the FXOS chassis:
Firepower-chassis /security/keyring/certreq* # set subject-name certificate request name
Step 14 Commit the transaction:
Firepower-chassis /security/keyring/certreq # commit-buffer
Step 15 Display the certificate request, which you can copy and send to a trust anchor or certificate authority:
Firepower-chassis /security/keyring # show certreq
The following example creates and displays a certificate request with an IPv4 address for a key ring, with advanced options:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope keyring kr220
Firepower-chassis /security/keyring #
create certreq
Firepower-chassis /security/keyring/certreq* #
set ip 192.168.200.123
Firepower-chassis /security/keyring/certreq* #
set subject-name sjc04
Firepower-chassis /security/keyring/certreq* #
set country US
Firepower-chassis /security/keyring/certreq* #
set dns bg1-samc-15A
Firepower-chassis /security/keyring/certreq* #
set email [email protected]
Firepower-chassis /security/keyring/certreq* #
set locality new york city
Firepower-chassis /security/keyring/certreq* #
set org-name "Cisco Systems"
Firepower-chassis /security/keyring/certreq* #
set org-unit-name Testing
Firepower-chassis /security/keyring/certreq* #
set state new york
Firepower-chassis /security/keyring/certreq* #
commit-buffer
Firepower-chassis /security/keyring/certreq #
show certreq
Certificate request subject name: sjc04
Certificate request ip address: 192.168.200.123
Certificate request e-mail name: [email protected]
Certificate request country name: US
State, province or county (full name): New York
Locality name (eg, city): new york city
Organization name (eg, company): Cisco
Organization Unit name (eg, section): Testing
Request:
-----BEGIN CERTIFICATE REQUEST-----
MIIBfTCB5wIBADARMQ8wDQYDVQQDEwZzYW1jMDQwgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBALpKn1t8qMZO4UGqILKFXQQc2c8b/vW2rnRF8OPhKbhghLA1YZ1F
JqcYEG5Yl1+vgohLBTd45s0GC8m4RTLJWHo4SwccAUXQ5Zngf45YtX1WsylwUWV4
0re/zgTk/WCd56RfOBvWR2Dtztu2pGA14sd761zLxt29K7R8mzj6CAUVAgMBAAGg
LTArBgkqhkiG9w0BCQ4xHjAcMBoGA1UdEQEB/wQQMA6CBnNhbWMwNIcECsEiXjAN
BgkqhkiG9w0BAQQFAAOBgQCsxN0qUHYGFoQw56RwQueLTNPnrndqUwuZHUO03Teg nhsyu4satpyiPqVV9viKZ+spvc6x5PWIcTWgHhH8BimOb/0OKuG8kwfIGGsEDlAv
TTYvUP+BZ9OFiPbRIA718S+V8ndXr1HejiQGxlDNqoN+odCXPc5kjoXD0lZTL09H
BA==
-----END CERTIFICATE REQUEST-----
Firepower-chassis /security/keyring/certreq #
What to Do Next
• Copy the text of the certificate request, including the BEGIN and END lines, and save it in a file. Send the file with the certificate request to a trust anchor or certificate authority to obtain a certificate for the key ring.
• Create a trusted point and set the certificate chain for the certificate of trust received from the trust anchor.
Cisco FXOS CLI Configuration Guide, 2.2(1)
121
Platform Settings
Creating a Trusted Point
Creating a Trusted Point
Procedure
Step 1
Enter security mode:
Firepower-chassis # scope security
Step 2
Create a trusted point:
Firepower-chassis /security # create trustpoint name
Step 3
Specify certificate information for this trusted point:
Firepower-chassis /security/trustpoint # set certchain [ certchain ]
If you do not specify certificate information in the command, you are prompted to enter a certificate or a list of trustpoints defining a certification path to the root certificate authority (CA). On the next line following your input, type ENDOFBUF to finish.
Important
The certificate must be in Base64 encoded X.509 (CER) format.
Step 4
Commit the transaction:
Firepower-chassis /security/trustpoint # commit-buffer
The following example creates a trusted point and provides a certificate for the trusted point:
Firepower-chassis#
scope security
Firepower-chassis /security #
create trustpoint tPoint10
Firepower-chassis /security/trustpoint* #
set certchain
Enter lines one at a time. Enter ENDOFBUF to finish. Press ^C to abort.
Trustpoint Certificate Chain:
>
-----BEGIN CERTIFICATE-----
>
MIIDMDCCApmgAwIBAgIBADANBgkqhkiG9w0BAQQFADB0MQswCQYDVQQGEwJVUzEL
>
BxMMU2FuIEpvc2UsIENBMRUwEwYDVQQKEwxFeGFtcGxlIEluYy4xEzARBgNVBAsT
>
ClRlc3QgR3JvdXAxGTAXBgNVBAMTEHRlc3QuZXhhbXBsZS5jb20xHzAdBgkqhkiG
>
9w0BCQEWEHVzZXJAZXhhbXBsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
>
AoGBAMZw4nTepNIDhVzb0j7Z2Je4xAG56zmSHRMQeOGHemdh66u2/XAoLx7YCcYU
>
ZgAMivyCsKgb/6CjQtsofvtrmC/eAehuK3/SINv7wd6Vv2pBt6ZpXgD4VBNKONDl
>
GMbkPayVlQjbG4MD2dx2+H8EH3LMtdZrgKvPxPTE+bF5wZVNAgMBAAGgJTAjBgkq
>
hkiG9w0BCQcxFhMUQSBjaGFsbGVuZ2UgcGFzc3dvcmQwDQYJKoZIhvcNAQEFBQAD
>
gYEAG61CaJoJaVMhzCl903O6Mg51zq1zXcz75+VFj2I6rH9asckCld3mkOVx5gJU
>
Ptt5CVQpNgNLdvbDPSsXretysOhqHmp9+CLv8FDuy1CDYfuaLtvlWvfhevskV0j6
>
jtcEMyZ+f7+3yh421ido3nO4MIGeBgNVHSMEgZYwgZOAFLlNjtcEMyZ+f7+3yh42
>
1ido3nO4oXikdjB0MQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExFDASBgNVBAcT
>
C1NhbnRhIENsYXJhMRswGQYDVQQKExJOdW92YSBTeXN0ZW1zIEluYy4xFDASBgNV
>
BAsTC0VuZ2luZWVyaW5nMQ8wDQYDVQQDEwZ0ZXN0Q0GCAQAwDAYDVR0TBAUwAwEB
>
/zANBgkqhkiG9w0BAQQFAAOBgQAhWaRwXNR6B4g6Lsnr+fptHv+WVhB5fKqGQqXc
>
wR4pYiO4z42/j9Ijenh75tCKMhW51az8copP1EBmOcyuhf5C6vasrenn1ddkkYt4
>
PR0vxGc40whuiozBolesmsmjBbedUCwQgdFDWhDIZJwK5+N3x/kfa2EHU6id1avt
>
4YL5Jg==
>
-----END CERTIFICATE-----
>
ENDOFBUF
Firepower-chassis /security/trustpoint* #
commit-buffer
Firepower-chassis /security/trustpoint #
What to Do Next
Obtain a key ring certificate from the trust anchor or certificate authority and import it into the key ring.
122
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Importing a Certificate into a Key Ring
Importing a Certificate into a Key Ring
Before You Begin
• Configure a trusted point that contains the certificate chain for the key ring certificate.
• Obtain a key ring certificate from a trust anchor or certificate authority.
Procedure
Step 1
Enter security mode:
Firepower-chassis # scope security
Step 2
Enter configuration mode for the key ring that will receive the certificate:
Firepower-chassis /security # scope keyring keyring-name
Step 3
Specify the trusted point for the trust anchor or certificate authority from which the key ring certificate was obtained:
Firepower-chassis /security/keyring # set trustpoint name
Step 4
Launch a dialog for entering and uploading the key ring certificate:
Firepower-chassis /security/keyring # set cert
At the prompt, paste the certificate text that you received from the trust anchor or certificate authority. On the next line following the certificate, type ENDOFBUF to complete the certificate input.
Important
The certificate must be in Base64 encoded X.509 (CER) format.
Step 5
Commit the transaction:
Firepower-chassis /security/keyring # commit-buffer
The following example specifies the trust point and imports a certificate into a key ring:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope keyring kr220
Firepower-chassis /security/keyring #
set trustpoint tPoint10
Firepower-chassis /security/keyring* #
set cert
Enter lines one at a time. Enter ENDOFBUF to finish. Press ^C to abort.
Keyring certificate:
>
-----BEGIN CERTIFICATE-----
>
MIIB/zCCAWgCAQAwgZkxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEVMBMGA1UE
>
BxMMU2FuIEpvc2UsIENBMRUwEwYDVQQKEwxFeGFtcGxlIEluYy4xEzARBgNVBAsT
>
ClRlc3QgR3JvdXAxGTAXBgNVBAMTEHRlc3QuZXhhbXBsZS5jb20xHzAdBgkqhkiG
>
9w0BCQEWEHVzZXJAZXhhbXBsZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
>
AoGBAMZw4nTepNIDhVzb0j7Z2Je4xAG56zmSHRMQeOGHemdh66u2/XAoLx7YCcYU
>
ZgAMivyCsKgb/6CjQtsofvtrmC/eAehuK3/SINv7wd6Vv2pBt6ZpXgD4VBNKONDl
>
GMbkPayVlQjbG4MD2dx2+H8EH3LMtdZrgKvPxPTE+bF5wZVNAgMBAAGgJTAjBgkq
>
hkiG9w0BCQcxFhMUQSBjaGFsbGVuZ2UgcGFzc3dvcmQwDQYJKoZIhvcNAQEFBQAD
>
gYEAG61CaJoJaVMhzCl903O6Mg51zq1zXcz75+VFj2I6rH9asckCld3mkOVx5gJU
>
Ptt5CVQpNgNLdvbDPSsXretysOhqHmp9+CLv8FDuy1CDYfuaLtvlWvfhevskV0j6
>
mK3Ku+YiORnv6DhxrOoqau8r/hyI/L43l7IPN1HhOi3oha4=
>
-----END CERTIFICATE-----
>
ENDOFBUF
Firepower-chassis /security/keyring* #
commit-buffer
Firepower-chassis /security/keyring #
Cisco FXOS CLI Configuration Guide, 2.2(1)
123
Platform Settings
Configuring HTTPS
What to Do Next
Configure your HTTPS service with the key ring.
Configuring HTTPS
Caution
After you complete the HTTPS configuration, including changing the port and key ring to be used by
HTTPS, all current HTTP and HTTPS sessions are closed without warning as soon as you save or commit the transaction.
Procedure
Step 1
Enter system mode:
Firepower-chassis# scope system
Step 2
Enter system services mode:
Firepower-chassis /system # scope services
Step 3
Enable the HTTPS service:
Firepower-chassis /system/services # enable https
Step 4
(Optional) Specify the port to be used for the HTTPS connection:
Firepower-chassis /system/services # set https port port-num
Step 5
(Optional) Specify the name of the key ring you created for HTTPS:
Firepower-chassis /system/services # set https keyring keyring-name
Step 6
(Optional) Specify the level of Cipher Suite security used by the domain:
Firepower-chassis /system/services # set https cipher-suite-mode cipher-suite-mode
cipher-suite-mode can be one of the following keywords:
• high-strength
• medium-strength
• low-strength
• custom—Allows you to specify a user-defined Cipher Suite specification string.
Step 7
(Optional) If cipher-suite-mode is set to custom, specify a custom level of Cipher Suite security for the domain:
Firepower-chassis /system/services # set https cipher-suite cipher-suite-spec-string
cipher-suite-spec-string can contain up to 256 characters and must conform to the OpenSSL Cipher Suite specifications. You cannot use any spaces or special characters except ! (exclamation point), + (plus sign), -
(hyphen), and : (colon). For details, see http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#sslciphersuite .
For example, the medium strength specification string FXOS uses as the default is:
ALL:!ADH:!EXPORT56:!LOW:RC4+RSA:+HIGH:+MEDIUM:+EXP:+eNULL
Note
This option is ignored if cipher-suite-mode is set to anything other than custom.
124
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Changing the HTTPS Port
Step 8
(Optional) Enable or disable the certificate revocation list check:
set revoke-policy { relaxed | strict }
Step 9
Commit the transaction to the system configuration:
Firepower-chassis /system/services # commit-buffer
The following example enables HTTPS, sets the port number to 443, sets the key ring name to kring7984, sets the Cipher Suite security level to high, and commits the transaction:
Firepower-chassis#
scope system
Firepower-chassis /system #
scope services
Firepower-chassis /system/services #
enable https
Firepower-chassis /system/services* #
set https port 443
Warning: When committed, this closes all the web sessions.
Firepower-chassis /system/services* #
set https keyring kring7984
Firepower-chassis /system/services* #
set https cipher-suite-mode high
Firepower-chassis /system/services* #
commit-buffer
Firepower-chassis /system/services #
Changing the HTTPS Port
The HTTPS service is enabled on port 443 by default. You cannot disable HTTPS, but you can change the port to use for HTTPS connections.
Procedure
Step 1
Enter system mode:
Firepower-chassis # scope system
Step 2
Enter system services mode:
Firepower-chassis /system # scope services
Step 3
Specify the port to use for HTTPS connections:
Firepower-chassis /system/services # set https port port-number
Specify an integer between 1 and 65535 for port-number. HTTPS is enabled on port 443 by default.
Step 4
Commit the transaction to the system configuration:
Firepower /system/services # commit-buffer
After changing the HTTPS port, all current HTTPS sessions are closed. Users will need to log back in to the
Firepower Chassis Manager using the new port as follows: https://<chassis_mgmt_ip_address>:<chassis_mgmt_port> where <chassis_mgmt_ip_address> is the IP address or host name of the Firepower chassis that you entered during initial configuration and <chassis_mgmt_port> is the HTTPS port you have just configured.
The following example sets the HTTPS port number to 443 and commits the transaction:
Firepower-chassis#
scope system
Firepower-chassis /system #
scope services
Firepower-chassis /system/services #
set https port 444
Warning: When committed, this closes all the web sessions.
Cisco FXOS CLI Configuration Guide, 2.2(1)
125
Deleting a Key Ring
Firepower-chassis /system/services* #
commit-buffer
Firepower-chassis /system/services #
Deleting a Key Ring
Procedure
Step 1
Enter security mode:
Firepower-chassis # scope security
Step 2
Delete the named key ring:
Firepower-chassis /security # delete keyring name
Step 3
Commits the transaction:
Firepower-chassis /security # commit-buffer
The following example deletes a key ring:
Firepower-chassis#
scope security
Firepower-chassis /security #
delete keyring key10
Firepower-chassis /security* #
commit-buffer
Firepower-chassis /security #
Deleting a Trusted Point
Before You Begin
Ensure that the trusted point is not used by a key ring.
Procedure
Step 1
Enters security mode:
Firepower-chassis# scope security
Step 2
Delete the named trusted point:
Firepower-chassis /security # delete trustpoint name
Step 3
Commits the transaction:
Firepower-chassis /security # commit-buffer
The following example deletes a trusted point:
Firepower-chassis#
scope security
Firepower-chassis /security #
delete trustpoint tPoint10
Firepower-chassis /security* #
commit-buffer
Firepower-chassis /security #
126
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Platform Settings
Disabling HTTPS
Disabling HTTPS
Procedure
Step 1
Enter system mode:
Firepower-chassis# scope system
Step 2
Enter system services mode:
Firepower-chassis /system # scope services
Step 3
Disable the HTTPS service:
Firepower-chassis /system/services # disable https
Step 4
Commit the transaction to the system configuration:
Firepower-chassis /system/services # commit-buffer
The following example disables HTTPS and commits the transaction:
Firepower-chassis#
scope system
Firepower-chassis /system #
scope services
Firepower-chassis /system/services #
disable https
Firepower-chassis /system/services* #
commit-buffer
Firepower-chassis /system/services #
Configuring AAA
This section describes authentication, authorization, and accounting. See the following topics for more information:
About AAA
AAA is a set of services for controlling access to computer resources, enforcing policies, assessing usage, and providing the information necessary to bill for services. These processes are considered important for effective network management and security.
Authentication
Authentication provides a way to identify a user, typically by having the user enter a valid username and valid password before access is granted. The AAA server compares a user's authentication credentials with other user credentials stored in a database. If the credentials match, the user is permitted access to the network. If the credentials do not match, authentication fails and network access is denied.
You can configure the FXOS chassis to authenticate administrative connections to the chassis, including the following sessions:
• HTTPS
• SSH
• Serial console
Cisco FXOS CLI Configuration Guide, 2.2(1)
127
Platform Settings
Configuring LDAP Providers
Authorization
Authorization is the process of enforcing policies: determining what types of activities, resources, or services a user is permitted to access. After a user is authenticated, that user may be authorized for different types of access or activity.
Accounting
Accounting measures the resources a user consumes during access, which may include the amount of system time or the amount of data that a user has sent or received during a session. Accounting is carried out through the logging of session statistics and usage information, which is used for authorization control, billing, trend analysis, resource utilization, and capacity planning activities.
Interaction Between Authentication, Authorization, and Accounting
You can use authentication alone or with authorization and accounting. Authorization always requires a user to be authenticated first. You can use accounting alone, or with authentication and authorization.
AAA Servers
The AAA server is a network server that is used for access control. Authentication identifies the user.
Authorization implements policies that determine which resources and services an authenticated user may access. Accounting keeps track of time and data resources that are used for billing and analysis.
Local Database Support
The Firepower chassis maintains a local database that you can populate with user profiles. You can use a local database instead of AAA servers to provide user authentication, authorization, and accounting.
Configuring LDAP Providers
Configuring Properties for LDAP Providers
The properties that you configure in this task are the default settings for all provider connections of this type.
If an individual provider includes a setting for any of these properties, the Firepower eXtensible Operating
System uses that setting and ignores the default setting.
If you are using Active Directory as your LDAP server, create a user account in the Active Directory server to bind with the Firepower eXtensible Operating System. This account should be given a non-expiring password.
Procedure
Step 1
Enter security mode:
Firepower-chassis# scope security
Step 2
Enter security LDAP mode:
Firepower-chassis /security # scope ldap
Step 3
Restrict database searches to records that contain the specified attribute:
Firepower-chassis /security/ldap # set attribute attribute
128
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Configuring LDAP Providers
Step 4
Restrict database searches to records that contain the specified distinguished name:
Firepower-chassis /security/ldap # set basedn distinguished-name
Step 5
Restrict database searches to records that contain the specified filter:
Firepower-chassis /security/ldap # set filter filter
Step 6
Set the time interval the system should wait for a response from the LDAP server before noting the server as down:
Firepower-chassis /security/ldap # set timeout seconds
Step 7
Commit the transaction to the system configuration:
Firepower-chassis /security/ldap # commit-buffer
The following example sets the LDAP attribute to CiscoAvPair, the base distinguished name to
"DC=cisco-firepower-aaa3,DC=qalab,DC=com", the filter to sAMAccountName=$userid, and the timeout interval to 5 seconds, and commits the transaction:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope ldap
Firepower-chassis /security/ldap #
set attribute CiscoAvPair
Firepower-chassis /security/ldap* #
set basedn "DC=cisco-firepower-aaa3,DC=qalab,DC=com"
Firepower-chassis /security/ldap* #
set filter sAMAccountName=$userid
Firepower-chassis /security/ldap* #
set timeout 5
Firepower-chassis /security/ldap* #
commit-buffer
Firepower-chassis /security/ldap #
Note
User login will fail if the userdn for an LDAP user exceeds 255 characters.
What to Do Next
Create an LDAP provider.
Creating an LDAP Provider
The Firepower eXtensible Operating System supports a maximum of 16 LDAP providers.
Before You Begin
If you are using Active Directory as your LDAP server, create a user account in the Active Directory server to bind with the Firepower eXtensible Operating System. This account should be given a non-expiring password.
Procedure
Step 1
Enter security mode:
Firepower-chassis# scope security
Step 2
Enter security LDAP mode:
Firepower-chassis /security # scope ldap
Step 3
Create an LDAP server instance and enter security LDAP server mode:
Cisco FXOS CLI Configuration Guide, 2.2(1)
129
Platform Settings
Configuring LDAP Providers
Firepower-chassis /security/ldap # create server server-name
If SSL is enabled, the server-name , typically an IP address or FQDN, must exactly match a Common Name
(CN) in the LDAP server's security certificate. Unless an IP address is specified, a DNS server must be configured.
Step 4
(Optional) Set an LDAP attribute that stores the values for the user roles and locales:
Firepower-chassis /security/ldap/server # set attribute attr-name
This property is always a name-value pair. The system queries the user record for the value that matches this attribute name.
This value is required unless a default attribute has been set for LDAP providers.
Step 5
(Optional) Set the specific distinguished name in the LDAP hierarchy where the server should begin a search when a remote user logs in and the system attempts to get the user's DN based on their username:
Firepower-chassis /security/ldap/server # set basedn basedn-name
The length of the base DN can be set to a maximum of 255 characters minus the length of CN=username, where username identifies the remote user attempting to access Firepower Chassis Manager or the FXOS CLI using LDAP authentication.
This value is required unless a default base DN has been set for LDAP providers.
Step 6
(Optional) Set the distinguished name (DN) for an LDAP database account that has read and search permissions for all objects under the base DN:
Firepower-chassis /security/ldap/server # set binddn binddn-name
The maximum supported string length is 255 ASCII characters.
Step 7
(Optional) Restrict the LDAP search to user names that match the defined filter.
Firepower-chassis /security/ldap/server # set filter filter-value
This value is required unless a default filter has been set for LDAP providers.
Step 8
Specify the password for the LDAP database account specified for Bind DN:
Firepower-chassis /security/ldap/server # set password
You can enter any standard ASCII characters except for space, § (section sign), ? (question mark), or = (equal sign).
To set the password, press Enter after typing the set password command and enter the key value at the prompt.
Step 9
(Optional) Specify the order in which the Firepower eXtensible Operating System uses this provider to authenticate users:
Firepower-chassis /security/ldap/server # set order order-num
Step 10 (Optional) Specify the port used to communicate with the LDAP server. The standard port number is 389.
Firepower-chassis /security/ldap/server # set port port-num
Step 11 Enable or disable the use of encryption when communicating with the LDAP server:
Firepower-chassis /security/ldap/server # set ssl {yes | no}
The options are as follows:
• yes —Encryption is required. If encryption cannot be negotiated, the connection fails.
• no —Encryption is disabled. Authentication information is sent as clear text.
130
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Configuring LDAP Providers
LDAP uses STARTTLS. This allows encrypted communication using port 389.
Step 12 Specify the length of time in seconds the system should spend trying to contact the LDAP database before it times out:
Firepower-chassis /security/ldap/server # set timeout timeout-num
Enter an integer from 1 to 60 seconds, or enter 0 (zero) to use the global timeout value specified for LDAP providers. The default is 30 seconds.
Step 13 Specify the vendor that is providing the LDAP provider or server details:
Firepower-chassis /security/ldap/server # set vendor {ms-ad | openldap}
The options are as follows:
• ms-ad—LDAP provider is Microsoft Active Directory
• openldap—LDAP provider is not Microsoft Active Directory
Step 14 (Optional) Enable the certification revocation list check:
Firepower-chassis /security/ldap/server # set revoke-policy {strict | relaxed}
Note
This configuration only takes effect if the SSL connection is enabled.
Step 15 Commit the transaction to the system configuration:
Firepower-chassis /security/ldap/server # commit-buffer
The following example creates an LDAP server instance named 10.193.169.246, configures the binddn, password, order, port, SSL settings, vendor attribute, and commits the transaction:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope ldap
Firepower-chassis /security/ldap* #
create server 10.193.169.246
Firepower-chassis /security/ldap/server* #
set binddn
"cn=Administrator,cn=Users,DC=cisco-firepower-aaa3,DC=qalab,DC=com"
Firepower-chassis /security/ldap/server* #
set password
Enter the password:
Confirm the password:
Firepower-chassis /security/ldap/server* #
set order 2
Firepower-chassis /security/ldap/server* #
set port 389
Firepower-chassis /security/ldap/server* #
set ssl yes
Firepower-chassis /security/ldap/server* #
set timeout 30
Firepower-chassis /security/ldap/server* #
set vendor ms-ad
Firepower-chassis /security/ldap/server* #
commit-buffer
Firepower-chassis /security/ldap/server #
The following example creates an LDAP server instance named 12:31:71:1231:45b1:0011:011:900, configures the binddn, password, order, port, SSL settings, vendor attribute, and commits the transaction:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope ldap
Firepower-chassis /security/ldap* #
create server 12:31:71:1231:45b1:0011:011:900
Firepower-chassis /security/ldap/server* #
set binddn
"cn=Administrator,cn=Users,DC=cisco-firepower-aaa3,DC=qalab,DC=com"
Firepower-chassis /security/ldap/server* #
set password
Enter the password:
Confirm the password:
Firepower-chassis /security/ldap/server* #
set order 1
Firepower-chassis /security/ldap/server* #
set port 389
Firepower-chassis /security/ldap/server* #
set ssl yes
Firepower-chassis /security/ldap/server* #
set timeout 45
Firepower-chassis /security/ldap/server* #
set vendor ms-ad
Cisco FXOS CLI Configuration Guide, 2.2(1)
131
Platform Settings
Configuring RADIUS Providers
Firepower-chassis /security/ldap/server* #
commit-buffer
Firepower-chassis /security/ldap/server #
Deleting an LDAP Provider
Procedure
Step 1
Enter security mode:
Firepower-chassis# scope security
Step 2
Enter security LDAP mode:
Firepower-chassis /security # scope ldap
Step 3
Delete the specified server:
Firepower-chassis /security/ldap # delete server serv-name
Step 4
Commit the transaction to the system configuration:
Firepower-chassis /security/ldap # commit-buffer
The following example deletes the LDAP server called ldap1 and commits the transaction:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope ldap
Firepower-chassis /security/ldap #
delete server ldap1
Firepower-chassis /security/ldap* #
commit-buffer
Firepower-chassis /security/ldap #
Configuring RADIUS Providers
Configuring Properties for RADIUS Providers
The properties that you configure in this task are the default settings for all provider connections of this type.
If an individual provider includes a setting for any of these properties, the Firepower eXtensible Operating
System uses that setting and ignores the default setting.
Procedure
Step 1
Enter security mode:
Firepower-chassis# scope security
Step 2
Enter security RADIUS mode:
Firepower-chassis /security # scope radius
Step 3
(Optional) Specify the number of times to retry communicating with the RADIUS server before noting the server as down:
Firepower-chassis /security/radius # set retries retry-num
Step 4
(Optional) Set the time interval the system should wait for a response from the RADIUS server before noting the server as down:
132
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Configuring RADIUS Providers
Firepower-chassis /security/radius # set timeout seconds
Step 5
Commit the transaction to the system configuration:
Firepower-chassis /security/radius # commit-buffer
The following example sets the RADIUS retries to 4, sets the timeout interval to 30 seconds, and commits the transaction:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope radius
Firepower-chassis /security/radius #
set retries 4
Firepower-chassis /security/radius* #
set timeout 30
Firepower-chassis /security/radius* #
commit-buffer
Firepower-chassis /security/radius #
What to Do Next
Create a RADIUS provider.
Creating a RADIUS Provider
The Firepower eXtensible Operating System supports a maximum of 16 RADIUS providers.
Procedure
Step 1
Enter security mode:
Firepower-chassis# scope security
Step 2
Enter security RADIUS mode:
Firepower-chassis /security # scope radius
Step 3
Create a RADIUS server instance and enter security RADIUS server mode:
Firepower-chassis /security/radius # create server server-name
Step 4
(Optional) Specify the port used to communicate with the RADIUS server.
Firepower-chassis /security/radius/server # set authport authport-num
Step 5
Set the RADIUS server key:
Firepower-chassis /security/radius/server # set key
To set the key value, press Enter after typing the set key command and enter the key value at the prompt.
Step 6
(Optional) Specify when in the order this server will be tried:
Firepower-chassis /security/radius/server # set order order-num
Step 7
(Optional) Set the number of times to retry communicating with the RADIUS server before noting the server as down:
Firepower-chassis /security/radius/server # set retries retry-num
Step 8
Specify the time interval that the system should wait for a response from the RADIUS server before noting the server as down:
Firepower-chassis /security/radius/server # set timeout seconds
Tip
It is recommended that you configure a higher Timeout value if you select two-factor authentication for RADIUS providers.
Cisco FXOS CLI Configuration Guide, 2.2(1)
133
Platform Settings
Configuring RADIUS Providers
Step 9
Commit the transaction to the system configuration:
Firepower-chassis /security/radius/server # commit-buffer
The following example creates a server instance named radiusserv7, sets the authentication port to 5858, sets the key to radiuskey321, sets the order to 2, sets the retries to 4, sets the timeout to 30, enables two-factor authentication, and commits the transaction:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope radius
Firepower-chassis /security/radius #
create server radiusserv7
Firepower-chassis /security/radius/server* #
set authport 5858
Firepower-chassis /security/radius/server* #
set key
Enter the key:
radiuskey321
Confirm the key:
radiuskey321
Firepower-chassis /security/radius/server* #
set order 2
Firepower-chassis /security/radius/server* #
set retries 4
Firepower-chassis /security/radius/server* #
set timeout 30
Firepower-chassis /security/radius/server* #
commit-buffer
Firepower-chassis /security/radius/server #
Deleting a RADIUS Provider
Procedure
Step 1
Enter security mode:
Firepower-chassis# scope security
Step 2
Enter security RADIUS mode:
Firepower-chassis /security # scope RADIUS
Step 3
Delete the specified server:
Firepower-chassis /security/radius # delete server serv-name
Step 4
Commit the transaction to the system configuration:
Firepower-chassis /security/radius # commit-buffer
The following example deletes the RADIUS server called radius1 and commits the transaction:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope radius
Firepower-chassis /security/radius #
delete server radius1
Firepower-chassis /security/radius* #
commit-buffer
Firepower-chassis /security/radius #
134
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Configuring TACACS+ Providers
Configuring TACACS+ Providers
Configuring Properties for TACACS+ Providers
The properties that you configure in this task are the default settings for all provider connections of this type.
If an individual provider includes a setting for any of these properties, the Firepower eXtensible Operating
System uses that setting and ignores the default setting.
Procedure
Step 1
Enter security mode:
Firepower-chassis# scope security
Step 2
Enter security TACACS+ mode:
Firepower-chassis /security # scope tacacs
Step 3
(Optional) Set the time interval the system should wait for a response from the TACACS+ server before noting the server as down:
Firepower-chassis /security/tacacs # set timeout seconds
Step 4
Commit the transaction to the system configuration:
Firepower-chassis /security/tacacs # commit-buffer
The following example sets the TACACS+ timeout interval to 45 seconds and commits the transaction:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope tacacs
Firepower-chassis /security/tacacs #
set timeout 45
Firepower-chassis /security/tacacs* #
commit-buffer
Firepower-chassis /security/tacacs #
What to Do Next
Create a TACACS+ provider.
Creating a TACACS+ Provider
The Firepower eXtensible Operating System supports a maximum of 16 TACACS+ providers.
Procedure
Step 1
Enter security mode:
Firepower-chassis# scope security
Step 2
Enter security TACACS+ mode:
Firepower-chassis /security # scope tacacs
Step 3
Create a TACACS+ server instance and enter security TACACS+ server mode:
Firepower-chassis /security/tacacs # create server server-name
Cisco FXOS CLI Configuration Guide, 2.2(1)
135
Platform Settings
Configuring TACACS+ Providers
Step 4
Specify the TACACS+ server key:
Firepower-chassis /security/tacacs/server # set key
To set the key value, press Enter after typing the set key command and enter the key value at the prompt.
Step 5
(Optional) Specify when in the order this server will be tried:
Firepower-chassis /security/tacacs/server # set order order-num
Step 6
Specify the time interval that the system should wait for a response from the TACACS+ server before noting the server as down:
Firepower-chassis /security/tacacs/server # set timeout seconds
Tip
It is recommended that you configure a higher timeout value if you select two-factor authentication for TACACS+ providers.
Step 7
(Optional) Specify the port used to communicate with the TACACS+ server:
Firepower-chassis /security/tacacs/server # set port port-num
Step 8
Commit the transaction to the system configuration:
Firepower-chassis /security/tacacs/server # commit-buffer
The following example creates a server instance named tacacsserv680, sets the key to tacacskey321, sets the order to 4, sets the authentication port to 5859, and commits the transaction:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope tacacs
Firepower-chassis /security/tacacs #
create server tacacsserv680
Firepower-chassis /security/tacacs/server* #
set key
Enter the key:
tacacskey321
Confirm the key:
tacacskey321
Firepower-chassis /security/tacacs/server* #
set order 4
Firepower-chassis /security/tacacs/server* #
set port 5859
Firepower-chassis /security/tacacs/server* #
commit-buffer
Firepower-chassis /security/tacacs/server #
Deleting a TACACS+ Provider
Procedure
Step 1
Enter security mode:
Firepower-chassis# scope security
Step 2
Enter security TACACS+ mode:
Firepower-chassis /security # scope tacacs
Step 3
Delete the specified server:
Firepower-chassis /security/tacacs # delete server serv-name
Step 4
Commit the transaction to the system configuration:
Firepower-chassis /security/tacacs # commit-buffer
136
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Configuring Syslog
The following example deletes the TACACS+ server called tacacs1 and commits the transaction:
Firepower-chassis#
scope security
Firepower-chassis /security #
scope tacacs
Firepower-chassis /security/tacacs #
delete server tacacs1
Firepower-chassis /security/tacacs* #
commit-buffer
Firepower-chassis /security/tacacs #
Configuring Syslog
System logging is a method of collecting messages from devices to a server running a syslog daemon. Logging to a central syslog server helps in aggregation of logs and alerts. A syslog service accepts messages and stores them in files, or prints them according to a simple configuration file. This form of logging provides protected long-term storage for logs. Logs are useful both in routine troubleshooting and in incident handling.
Procedure
Step 1
Enter monitoring mode:
Firepower-chassis# scope monitoring
Step 2
Enable or disable the sending of syslogs to the console:
Firepower-chassis /monitoring # {enable | disable} syslog console
Step 3
(Optional) Select the lowest message level that you want displayed. If syslogs are enabled, the system displays that level and above on the console. The level options are listed in order of decreasing urgency. The default level is Critical.
Firepower-chassis /monitoring # set syslog console level {emergencies | alerts | critical}
Step 4
Enable or disable the monitoring of syslog information by the operating system:
Firepower-chassis /monitoring # {enable | disable} syslog monitor
Step 5
(Optional) Select the lowest message level that you want displayed. If the monitor state is enabled, the system displays that level and above. The level options are listed in order of decreasing urgency. The default level is
Critical.
Firepower-chassis /monitoring # set syslog monitor level {emergencies | alerts | critical | errors | warnings
| notifications | information | debugging}
Note
Messages at levels below Critical are displayed on the terminal monitor only if you have entered the
terminal monitor command.
Step 6
Enable or disable the writing of syslog information to a syslog file:
Firepower-chassis /monitoring # {enable | disable} syslog file
Step 7
Specify the name of the file in which the messages are logged. Up to 16 characters are allowed in the file name.
Firepower-chassis /monitoring # set syslog file name filename
Step 8
(Optional) Select the lowest message level that you want stored to a file. If the file state is enabled, the system stores that level and above in the syslog file. The level options are listed in order of decreasing urgency. The default level is Critical.
Firepower-chassis /monitoring # set syslog file level {emergencies | alerts | critical | errors | warnings |
notifications | information | debugging}
Cisco FXOS CLI Configuration Guide, 2.2(1)
137
Platform Settings
Configuring Syslog
Step 9
(Optional) Specify the maximum file size, in bytes, before the system begins to write over the oldest messages with the newest ones. The range is 4096 to 4194304 bytes.
Firepower-chassis /monitoring # set syslog file size filesize
Step 10 Configure sending of syslog messages to up to three external syslog servers: a) Enable or disable the sending of syslog messages to up to three external syslog servers:
Firepower-chassis /monitoring # {enable | disable} syslog remote-destination {server-1 | server-2 |
server-3} b) (Optional) Select the lowest message level that you want stored to the external log. If the remote-destination is enabled, the system sends that level and above to the external server. The level options are listed in order of decreasing urgency. The default level is Critical.
Firepower-chassis /monitoring # set syslog remote-destination {server-1 | server-2 | server-3}
level{emergencies | alerts | critical | errors | warnings | notifications | information | debugging} c) Specify the hostname or IP address of the specified remote syslog server. Up to 256 characters are allowed in the hostname.
Firepower-chassis /monitoring # set syslog remote-destination {server-1 | server-2 | server-3} hostname
hostname
d) (Optional) Specify the facility level contained in the syslog messages sent to the specified remote syslog server.
Firepower-chassis /monitoring # set syslog remote-destination {server-1 | server-2 | server-3} facility
{local0 | local1 | local2 | local3 | local4 | local5 | local6 | local7}
Step 11 Configure the local sources. Enter the following command for each of the local sources you want to enable or disable:
Firepower-chassis /monitoring # {enable | disable} syslog source {audits | events | faults}
This can be one of the following:
• audits—Enables or disables the logging of all audit log events.
• events—Enables or disables the logging of all system events.
• faults—Enables or disables the logging of all system faults.
Step 12 Commit the transaction:
Firepower-chassis /monitoring # commit-buffer
This example shows how to enable the storage of syslog messages in a local file and commits the transaction:
Firepower-chassis#
scope monitoring
Firepower-chassis /monitoring #
disable syslog console
Firepower-chassis /monitoring* #
disable syslog monitor
Firepower-chassis /monitoring* #
enable syslog file
Firepower-chassis /monitoring* #
set syslog file name SysMsgsFirepower
Firepower-chassis /monitoring* #
set syslog file level notifications
Firepower-chassis /monitoring* #
set syslog file size 4194304
Firepower-chassis /monitoring* #
disable syslog remote-destination server-1
Firepower-chassis /monitoring* #
disable syslog remote-destination server-2
Firepower-chassis /monitoring* #
disable syslog remote-destination server-3
Firepower-chassis /monitoring* #
commit-buffer
Firepower-chassis /monitoring #
138
Cisco FXOS CLI Configuration Guide, 2.2(1)
Platform Settings
Configuring DNS Servers
Configuring DNS Servers
You need to specify a DNS server if the system requires resolution of host names to IP addresses. For example, you cannot use a name such as www.cisco.com when you are configuring a setting on the Firepower chassis if you do not configure a DNS server. You would need to use the IP address of the server, which can be either an IPv4 or an IPv6 address. You can configure up to four DNS servers.
Note
When you configure multiple DNS servers, the system searches for the servers only in any random order.
If a local management command requires DNS server lookup, it can only search for three DNS servers in random order.
Procedure
Step 1
Enter system mode:
Firepower-chassis # scope system
Step 2
Enter system services mode:
Firepower-chassis /system # scope services
Step 3
To create or delete a DNS server, enter the appropriate command as follows:
• To configure the system to use a DNS server with the specified IPv4 or IPv6 address:
Firepower-chassis /system/services # create dns {ip-addr | ip6-addr}
• To delete a DNS server with the specified IPv4 or IPv6 address:
Firepower-chassis /system/services # delete dns {ip-addr | ip6-addr}
Step 4
Commit the transaction to the system configuration:
Firepower /system/services # commit-buffer
The following example configures a DNS server with the IPv4 address 192.168.200.105 and commits the transaction:
Firepower-chassis# scope system
Firepower-chassis /system # scope services
Firepower-chassis /system/services # create dns 192.168.200.105
Firepower-chassis /system/services* # commit-buffer
Firepower-chassis /system/services #
The following example configures a DNS server with the IPv6 address 2001:db8::22:F376:FF3B:AB3F and commits the transaction:
Firepower-chassis# scope system
Firepower-chassis /system # scope services
Firepower-chassis /system/services # create dns 2001:db8::22:F376:FF3B:AB3F
Firepower-chassis /system/services* # commit-buffer
Firepower-chassis /system/services #
Cisco FXOS CLI Configuration Guide, 2.2(1)
139
Platform Settings
Configuring DNS Servers
The following example deletes the DNS server with the IP address 192.168.200.105 and commits the transaction:
Firepower-chassis# scope system
Firepower-chassis /system # scope services
Firepower-chassis /system/services # delete dns 192.168.200.105
Firepower-chassis /system/services* # commit-buffer
Firepower-chassis /system/services #
140
Cisco FXOS CLI Configuration Guide, 2.2(1)
C H A P T E R
10
Interface Management
•
About Firepower Security Appliance Interfaces, page 141
•
Edit Interface Properties, page 143
•
Create a Port Channel, page 144
•
Configuring Breakout Cables, page 145
About Firepower Security Appliance Interfaces
The FXOS chassis supports single interfaces as well as EtherChannel (port-channel) Interfaces. EtherChannel interfaces can include up to 16 member interfaces of the same type.
Interface Types
Each interface can be one of the following types:
• Data (the default)--Data interfaces cannot be shared between logical devices.
• Management--Management interfaces can be shared between logical devices. You can only assign one management interface per logical device.
Within the Firepower Threat Defense application, the physical management interface is shared between the Diagnostic logical interface and the Management logical interface. The Management logical interface is separate from the other interfaces on the device. It is used to set up and register the device to the
Firepower Management Center. It runs a separate SSH server and uses its own local authentication, IP address, and static routing. You can configure its settings at the CLI using the configure network command, and also change the IP address from the Management Center Devices > Device Management
> Devices > Management area.
The Diagnostic logical interface can be configured along with the rest of the data interfaces on the
Management Center Devices > Device Management > Interfaces screen. Using the Diagnostic interface is optional. The Diagnostic interface and data interfaces allow for LDAP or RADIUS external authentication. If you do not want to allow SSH access on a data interface, for example, then you may choose to configure the Diagnostic interface for SSH access. The Diagnostic interface only allows management traffic, and does not allow through traffic.
Cisco FXOS CLI Configuration Guide, 2.2(1)
141
Interface Management
Hardware Bypass Pairs
• Firepower-eventing--This interface is a secondary management interface for Firepower Threat Defense 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 configure network commands in the Firepower Management Center command reference.
• Cluster--Special interface type used for a clustered logical device. This type is automatically assigned to the cluster control link for inter-unit cluster communications. By default, the cluster control link is automatically created on Port-channel 48.
Note
You can use the Firepower Management Center or Firepower Threat Defense CLI to configure two uplink, breakout, or data port interfaces into an inline pair. Once two ports are configured in an inline pair, they act as one single interface. This configuration is then propagated to the FXOS chassis.
Note the following restrictions for inline pairs:
• The two port interfaces must be unique. Once joining one inline pair, the ports cannot join another inline pair.
• Only uplink ports, data ports, or breakout ports can be configured into inline pairs.
For more information, see the Configure an Inline Set of IPS-Only Interfaces topic in the Firepower
Management Center Configuration Guide.
Hardware Bypass Pairs
For the Firepower Threat Defense, 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 Hardware Bypass 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
Firepower Threat Defense 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.
The Firepower Threat Defense 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)
142
Cisco FXOS CLI Configuration Guide, 2.2(1)
Interface Management
Jumbo Frame Support
• 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 FXOS chassis has support for jumbo frames enabled by default. To enable jumbo frame support on a specific logical device installed on the FXOS 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 FXOS chassis is 9184.
Edit Interface Properties
Procedure
Step 1
Enter interface mode:
scope eth-uplink scope fabric a
Step 2
Enable the interface:
enter interface interface_id
enable
Example:
Firepower /eth-uplink/fabric # enter interface Ethernet1/8
Firepower /eth-uplink/fabric/interface # enable
Note
Interfaces that are already a member of a port-channel cannot be modified individually. If you use the enter interface or scope interface command on an interface that is a member of a port channel, you will receive an error stating that the object does not exist. You should edit interfaces using the
enter interface command before you add them to a port-channel.
Step 3
(Optional) Set the interface type:
set port-type {data | firepower-eventing | mgmt | cluster}
Example:
Firepower /eth-uplink/fabric/interface # set port-type mgmt
The data keyword is the default type. Do not choose the cluster keyword.
Cisco FXOS CLI Configuration Guide, 2.2(1)
143
Interface Management
Create a Port Channel
Step 4
(Optional) Set the interface speed:
set admin-speed {10gbps | 1gbps}
Example:
Firepower /eth-uplink/fabric/interface* # set admin-speed 1gbps
Step 5
Commit the configuration:
commit-buffer
Create a Port Channel
An EtherChannel (also known as a port-channel) can include up to 16 member interfaces of the same type.
When the FXOS chassis creates an EtherChannel, the EtherChannel stays in a Suspended state 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 port for a standalone logical device
• The EtherChannell is added as a management or CCL port for a logical device that is part of a cluster
• The EtherChannell is added as a data port for a logical device that is part of a cluster and at least one security module 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 state.
Before You Begin
The FXOS chassis only supports EtherChannels in Active Link Aggregation Control Protocol (LACP) mode.
We suggest setting the connecting switch ports to Active mode for the best compatibility.
Procedure
Step 1
Enter interface mode:
scope eth-uplink scope fabric a
Step 2
Create the port-channel:
create port-channel id
enable
Step 3
Assign member interfaces:
create member-port interface_id
Example:
Firepower /eth-uplink/fabric/port-channel* # create member-port Ethernet1/1
144
Cisco FXOS CLI Configuration Guide, 2.2(1)
Interface Management
Configuring Breakout Cables
Firepower /eth-uplink/fabric/port-channel/member-port* # exit
Firepower /eth-uplink/fabric/port-channel* # create member-port Ethernet1/2
Firepower /eth-uplink/fabric/port-channel/member-port* # exit
Firepower /eth-uplink/fabric/port-channel* # create member-port Ethernet1/3
Firepower /eth-uplink/fabric/port-channel/member-port* # exit
Firepower /eth-uplink/fabric/port-channel* # create member-port Ethernet1/4
Firepower /eth-uplink/fabric/port-channel/member-port* # exit
Step 4
(Optional) Set the interface type:
set port-type {data | mgmt | cluster}
Example:
Firepower /eth-uplink/fabric/port-channel # set port-type mgmt
The data keyword is the default type. Do not choose the cluster keyword unless you want to use this port-channel as the cluster control link instead of the default.
Step 5
(Optional) Set the interface speed for all members of the port-channel:
set speed {10gbps | 1gbps}
Example:
Firepower /eth-uplink/fabric/port-channel* # set speed 1gbps
Step 6
Commit the configuration:
commit-buffer
Configuring Breakout Cables
The following procedure shows how to configure breakout cables for use with the FXOS chassis. You can use a breakout cable to provide four 10 Gbps ports in place of a single 40 Gbps port.
Before You Begin
Hardware Bypass-capable interfaces cannot be configured for breakout ports.
Procedure
Step 1
To create a new breakout, use the following commands: a) Enter cabling mode:
scope cabling scope fabric a
b) Create the breakout:
create breakout network_module_slot port
Example:
Firepower /cabling/fabric/ # create breakout 2 1
Cisco FXOS CLI Configuration Guide, 2.2(1)
145
Interface Management
Configuring Breakout Cables
c) Commit the configuration:
commit-buffer
This will cause an automatic reboot. If you are configuring more than one breakout, you should create all of them before you issue the commit-buffer command.
Step 2
To enable/configure the breakout ports, use the following commands: a) Enter interface mode:
scope eth-uplink scope fabric a
scope aggr-interface network_module_slot port
Note
Interfaces that are already a member of a port-channel cannot be modified individually. If you use the enter interface or scope interface command on an interface that is a member of a port channel, you will receive an error stating that the object does not exist. You should edit interfaces using the enter interface command before you add them to a port-channel.
b) Use the set command to configure the interface speed and port type.
Use the enable or disable command to set the administrative state of the interface.
c) Commit the configuration:
commit-buffer
146
Cisco FXOS CLI Configuration Guide, 2.2(1)
C H A P T E R
11
Logical Devices
•
About Logical Devices, page 147
•
Create a Standalone Logical Device, page 148
•
•
Configure Service Chaining, page 179
•
Manage Logical Devices, page 186
About Logical Devices
When you create a logical device, the FXOS chassis supervisor deploys the logical device by downloading the specified software version and pushing the bootstrap configuration and management interface settings to the specified security module/engine, or in the case of an intra-chassis cluster, to all security modules installed in the Firepower chassis.
You can create either of the following two types of logical devices:
• Standalone—You can create a standalone logical device for each security module/engine installed in the Firepower chassis.
• Cluster—Clustering lets you group multiple security modules together as a single logical device. A cluster provides 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.
Note
On an FXOS chassis that supports multiple security modules, you can only create one type of logical device, standalone or cluster. In other words, if you have three security modules installed, you cannot create a standalone logical device on one security module and then create a cluster using the remaining two logical devices.
Cisco FXOS CLI Configuration Guide, 2.2(1)
147
Logical Devices
Create a Standalone Logical Device
Note
If you are configuring standalone logical devices, you must install the same software type on all modules in the chassis; different software types are not supported at this time. Note that modules can run different versions of a particular device type, but all modules must be configured as the same type of logical device.
Create a Standalone Logical Device
You can create a standalone logical device for each security module/engine installed in the Firepower chassis.
Create a Standalone ASA Logical Device
You can create a standalone logical device for each security module/engine installed in the FXOS chassis.
On multiple module devices, like the Firepower 9300, you cannot create standalone logical devices if you have a cluster configured. You will need to delete the cluster before you can configure a standalone device.
Note
Optionally, you can install the third-party Radware DefensePro virtual platform as a DDoS detection and mitigation service that sits in front of the ASA firewall on the security module (see
on page 179 ).
Note
You must install the same software type on all modules in a chassis; different software types are not supported at this time. Note that modules can run different versions of a particular device type, but all modules must be configured as the same type of logical device.
Before You Begin
• If the security module/engine that you want to use for the logical device already has a logical device configured on it, you must first delete the existing logical device (see
Delete a Logical Device, on page
187 ).
• Download the application image you want to use for the logical device from Cisco.com (see
Images from Cisco.com, on page 48
) and then download that image to the FXOS chassis (see
Downloading a Logical Device Software Image to the FXOS chassis, on page 51
).
• Configure a management interface to use with the logical device.
• You can only deploy a routed firewall mode ASA from the FXOS chassis.
Procedure
Step 1
Enter security services mode:
Firepower# scope ssa
Step 2
Create the logical device:
Firepower /ssa # create logical-device device_name asa slot_id standalone
148
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Create a Standalone ASA Logical Device
Step 3
Enter a description for the logical device:
Firepower /ssa/logical-device* # set description "logical device description"
Step 4
Assign the management and data interfaces to the logical device:
Firepower /ssa/logical-device* # create external-port-link name interface_id asa
Firepower-chassis /ssa/logical-device/external-port-link* # exit
The name is used by the FXOS chassis supervisor; it is not the interface name used in the security module configuration. Repeat for each interface.
Step 5
Configure the management bootstrap information: a) Create a bootstrap object:
Firepower /ssa/logical-device* # create mgmt-bootstrap asa b) Create an enable password:
Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key-secret PASSWORD c) Set a password value:
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # set value
Value: password d) Exit the password configuration scope:
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # exit e) Configure the management IP address:
Firepower /ssa/logical-device/mgmt-bootstrap* # create ipv4 slot_id default f) Set a gateway address:
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # set gateway gateway_address g) Set the IP address and mask:
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # set ip ip_address mask network_mask h) Exit the management IP configuration scope:
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # exit i) Exit the management bootstrap configuration scope:
Firepower /ssa/logical-device/mgmt-bootstrap* # exit
Step 6
Commit the configuration:
commit-buffer
Commits the transaction to the system configuration.
Example
Firepower# scope ssa
Firepower /ssa # create logical-device MyDevice1 asa 1 standalone
Firepower /ssa/logical-device* # set description "logical device description"
Firepower /ssa/logical-device* # create external-port-link inside Ethernet1/1 asa
Firepower /ssa/logical-device/external-port-link* # set description "inside link"
Firepower /ssa/logical-device/external-port-link* # exit
Firepower /ssa/logical-device* # create external-port-link management Ethernet1/7 asa
Firepower /ssa/logical-device/external-port-link* # set description "management link"
Firepower /ssa/logical-device/external-port-link* # exit
Firepower /ssa/logical-device* # create external-port-link outside Ethernet1/2 asa
Firepower /ssa/logical-device/external-port-link* # set description "external link"
Firepower /ssa/logical-device/external-port-link* # exit
Cisco FXOS CLI Configuration Guide, 2.2(1)
149
Logical Devices
Create a Standalone Threat Defense Logical Device
+
+
+
+
+
+
+
+
+
+
+
Firepower /ssa/logical-device* # create mgmt-bootstrap asa
Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key-secret PASSWORD
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # set value
Value: <password>
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # create ipv4 1 default
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # set gateway 1.1.1.254
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # set ip 1.1.1.1 mask 255.255.255.0
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # exit
Firepower /ssa/logical-device* # show configuration pending
+enter logical-device MyDevice1 asa 1 standalone enter external-port-link inside Ethernet1/1 asa set decorator "" exit set description "inside link" enter external-port-link management Ethernet1/7 asa set decorator "" exit set description "management link" enter external-port-link outside Ethernet1/2 asa set decorator "" set description "external link"
+
+
+
+
+
+
+ exit enter mgmt-bootstrap asa enter bootstrap-key-secret PASSWORD exit set value enter ipv4 1 default set gateway 1.1.1.254
+
+
+
+ exit exit set ip 1.1.1.1 mask 255.255.255.0
set description "logical device description"
+exit
Firepower /ssa/logical-device* # commit-buffer
Create a Standalone Threat Defense Logical Device
You can create a standalone logical device for each security module/engine installed in the FXOS chassis.
On multiple module devices, like the Firepower 9300, you cannot create standalone logical devices if you have a cluster configured. You will need to delete the cluster before you can configure a standalone device.
Note
Optionally, you can install the third-party Radware DefensePro virtual platform as a DDoS detection and mitigation service that sits in front of the Firepower Threat Defense logical device on the security module
(see
About Service Chaining, on page 179
).
Note
You must install the same software type on all modules in a chassis; different software types are not supported at this time. Note that modules can run different versions of a particular device type, but all modules must be configured as the same type of logical device.
Before You Begin
• If the security module/engine that you want to use for the logical device already has a logical device configured on it, you must first delete the existing logical device (see
Delete a Logical Device, on page
187 ).
150
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Create a Standalone Threat Defense Logical Device
• Download the application image you want to use for the logical device from Cisco.com (see
Images from Cisco.com, on page 48
) and then download that image to the FXOS chassis (see
Downloading a Logical Device Software Image to the FXOS chassis, on page 51
).
• Configure a management interface to use with the logical device. 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).
Procedure
Step 1
Enter security services mode:
Firepower# scope ssa
Step 2
Create the logical device:
Firepower /ssa # create logical-device device_name ftd slot_id standalone
The device_name is used by the FXOS chassis supervisor to configure management settings and to assign interfaces; it is not the device name used in the security module configuration.
Step 3
Assign the management and data interfaces to the logical device:
Firepower /ssa/logical-device* # create external-port-link name interface_id ftd
Firepower-chassis /ssa/logical-device/external-port-link* # exit
The name is used by the FXOS chassis supervisor; it is not the interface name used in the security module configuration. Repeat for each interface.
Step 4
Configure the management bootstrap parameters: a) Create bootstrap object:
Firepower /ssa/logical-device* # create mgmt-bootstrap ftd b) Specify the IP address of the managing Firepower Management Center:
Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key FIREPOWER_MANAGER_IP
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # set value IP_address
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # exit c) Specify the mode in which the logical device will operate (routed or transparent):
Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key FIREWALL_MODE
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # set value firewall_mode
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # exit d) Specify the key to be shared between the device and the Firepower Management Center:
Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key-secret REGISTRATION_KEY
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # set value
Value: registration_key
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # exit e) Specify the password to use for the logical device:
Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key-secret PASSWORD
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # set value
Value: password
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # exit
Cisco FXOS CLI Configuration Guide, 2.2(1)
151
Logical Devices
Create a Standalone Threat Defense Logical Device
f) Specify the fully qualified hostname for the logical device:
Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key FQDN
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # set value fqdn
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # exit g) Specify a comma-separated list of DNS servers to be used by the logical device:
Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key DNS_SERVERS
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # set value dns_servers
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # exit h) Specify a comma-separated list of search domains for the logical device:
Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key SEARCH_DOMAINS
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # set value search_domains
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # exit i) Configure the management interface settings:
To create an IPv4 management interface object:
1
Create management interface object:
Firepower /ssa/logical-device/mgmt-bootstrap* # create ipv4 slot_id firepower
2
Set gateway address:
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # set gateway gateway_address
3
Set IP address and mask:
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # set ip ip_address mask network_mask
4
Exit management IP configuration scope:
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # exit
To create an IPv6 management interface object:
1
Create management interface object:
Firepower /ssa/logical-device/mgmt-bootstrap* # create ipv6 slot_id firepower
2
Set gateway address:
Firepower /ssa/logical-device/mgmt-bootstrap/ipv6* # set gateway gateway_address
3
Set IP address and prefix:
Firepower /ssa/logical-device/mgmt-bootstrap/ipv6* # set ip ip_address prefix-length prefix
4
Exit management IP configuration scope:
Firepower /ssa/logical-device/mgmt-bootstrap/ipv6* # exit j) Exit the management bootstrap mode:
Firepower /ssa/logical-device/mgmt-bootstrap* #exit
Step 5
Accept the end-user license agreement: a) Firepower /ssa/logical-device* # exit b) Firepower /ssa* #show app-instance
Shows the version of the Firepower Threat Defense application.
152
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Create a Standalone Threat Defense Logical Device
c) Firepower /ssa* #scope app ftd application_version d) Firepower /ssa/app* #show license-agreement e) Firepower /ssa/app* #accept-license-agreement f) Firepower /ssa/app* #exit
Step 6
(Optional) Install the Radware DefensePro instance:
Firepower /ssa* # scope slot slot_id
Firepower/ssa/slot* # create app-instance vdp
After you perform the final step in this procedure to commit the logical device configuration, you must continue configuring the Radware DefensePro decorator in a service chain with the Firepower Threat Defense logical device. See the
Configure Radware DefensePro Service Chain on a Standalone Logical Device, on page 180
procedure, starting with step 4. For the Firepower 4110 and 4120, you must create the app-instance before you commit the logical device configuration.
Step 7
Commit the configuration:
commit-buffer
Commits the transaction to the system configuration.
Example
Firepower# scope ssa
Firepower /ssa #create logical-device MyDevice1 ftd 1 standalone
Firepower /ssa/logical-device* # create external-port-link inside Ethernet1/1 ftd
Firepower /ssa/logical-device/external-port-link* # set description "inside link"
Firepower /ssa/logical-device/external-port-link* # exit
Firepower /ssa/logical-device* # create external-port-link management Ethernet1/7 ftd
Firepower /ssa/logical-device/external-port-link* # set description "management link"
Firepower /ssa/logical-device/external-port-link* # exit
Firepower /ssa/logical-device* # create external-port-link outside Ethernet1/2 ftd
Firepower /ssa/logical-device/external-port-link* # set description "external link"
Firepower /ssa/logical-device/external-port-link* # exit
Firepower /ssa/logical-device* # create mgmt-bootstrap ftd
Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key FIREPOWER_MANAGER_IP
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # set value 10.0.0.100
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key FIREWALL_MODE
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # set value routed
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key-secret REGISTRATION_KEY
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # set value
Value:
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key-secret PASSWORD
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # set value
Value:
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # create ipv4 1 firepower
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # set gateway 10.0.0.1
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # set ip 10.0.0.31 mask 255.255.255.0
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key FQDN
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # set value ftd.cisco.com
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key DNS_SERVERS
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # set value 192.168.1.1
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # create bootstrap-key SEARCH_DOMAINS
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # set value search.com
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # exit
Cisco FXOS CLI Configuration Guide, 2.2(1)
153
Logical Devices
Deploy a Cluster
Firepower /ssa/logical-device* # exit
Firepower /ssa* # scope app ftd 6.0.0.837
Firepower /ssa/app* # accept-license-agreement
Firepower /ssa/app* # commit-buffer
Deploy a Cluster
Clustering lets you group multiple devices together as a single logical device. A cluster provides all the convenience of a single device (management, integration into a network) while achieving the increased throughput and redundancy of multiple devices. The Firepower 9300, which includes multiple modules, supports intra-chassis clustering where you group all modules within a single chassis into a cluster. You can also use inter-chassis clustering, where multiple chassis are grouped together; inter-chasis clustering is the only option for single module devices like the Firepower 4100 series.
About Clustering on the FXOS Chassis
The cluster consists of multiple devices acting as a single logical unit. When you deploy a cluster on the FXOS chassis, it does the following:
• Creates a cluster-control link (by default, port-channel 48) for unit-to-unit communication. For intra-chassis clustering (Firepower 9300 only), this link utilizes the Firepower 9300 backplane for cluster communications. For inter-chassis clustering, you need to manually assign physical interface(s) to this
EtherChannel for communications between chassis.
• Creates the cluster bootstrap configuration within the application.
When you deploy the cluster, the FXOS chassis supervisor pushes a minimal bootstrap configuration to each unit that includes the cluster name, cluster control link interface, and other cluster settings. Some parts of the bootstrap configuration may be user-configurable within the application if you want to customize your clustering environment.
• Assigns data interfaces to the cluster as Spanned interfaces.
For intra-chassis clustering, spanned interfaces are not limited to EtherChannels, like it is for inter-chassis clustering.The Firepower 9300 supervisor uses EtherChannel technology internally to load-balance traffic to multiple modules on a shared interface, so any data interface type works for Spanned mode.
For inter-chassis clustering, you must use Spanned EtherChannels for all data interfaces.
Note
Individual interfaces are not supported, with the exception of a management interface.
• Assigns a management interface to all units in the cluster.
The following sections provide more detail about clustering concepts and implementation.
Primary and Secondary Unit Roles
One member of the cluster is the primary unit. The primary unit is determined automatically. All other members are secondary units.
You must perform all configuration on the primary unit only; the configuration is then replicated to the secondary units.
154
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
About Clustering on the FXOS Chassis
Cluster Control Link
The cluster control link is automatically created using the Port-channel 48 interface. For intra-chassis clustering, this interface has no member interfaces. For inter-chassis clustering, you must add one or more interfaces to the EtherChannel. This Cluster type EtherChannel utilizes the Firepower 9300 backplane for cluster communications for intra-chassis clustering.
For a 2-member inter-chassis cluster, do not directly-connect the cluster control link from one chassis to the other chassis. If you directly connect the interfaces, then when one unit fails, the cluster control link fails, and thus the remaining healthy unit fails. If you connect the cluster control link through a switch, then the cluster control link remains up for the healthy unit.
Cluster control link traffic includes both control and data traffic.
Size the Cluster Control Link for Inter-Chassis Clustering
If possible, you should size the cluster control link to match the expected throughput of each chassis so the cluster-control link can handle the worst-case scenarios.
Cluster control link traffic is comprised mainly of state update and forwarded packets. The amount of traffic at any given time on the cluster control link varies. The amount of forwarded traffic depends on the load-balancing efficacy or whether there is a lot of traffic for centralized features. For example:
• NAT results in poor load balancing of connections, and the need to rebalance all returning traffic to the correct units.
• AAA for network access is a centralized feature, so all traffic is forwarded to the primary unit.
• When membership changes, the cluster needs to rebalance a large number of connections, thus temporarily using a large amount of cluster control link bandwidth.
A higher-bandwidth cluster control link helps the cluster to converge faster when there are membership changes and prevents throughput bottlenecks.
Note
If your cluster has large amounts of asymmetric (rebalanced) traffic, then you should increase the cluster control link size.
Cluster Control Link Redundancy for Inter-Chassis Clustering
The following diagram shows how to use an EtherChannel as a cluster control link in a Virtual Switching
System (VSS) or Virtual Port Channel (vPC) environment. All links in the EtherChannel are active. When the switch is part of a VSS or vPC, then you can connect FXOS chassis interfaces within the same EtherChannel to separate switches in the VSS or vPC. The switch interfaces are members of the same EtherChannel port-channel interface, because the separate switches act like a single switch. Note that this EtherChannel is device-local, not a Spanned EtherChannel.
Cisco FXOS CLI Configuration Guide, 2.2(1)
155
Logical Devices
About Clustering on the FXOS Chassis
Cluster Control Link Reliability for Inter-Chassis Clustering
To ensure cluster control link functionality, be sure the round-trip time (RTT) between units is less than 20 ms. This maximum latency enhances compatibility with cluster members installed at different geographical sites. To check your latency, perform a ping on the cluster control link between units.
The cluster control link must be reliable, with no out-of-order or dropped packets; for example, for inter-site deployment, you should use a dedicated link.
Cluster Control Link Network
The FXOS 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. You cannot set this IP address manually, either in FXOS or within the application. The cluster control link network cannot include any routers between units; only Layer 2 switching is allowed. For inter-site traffic, Cisco recommends using Overlay Transport Virtualization (OTV).
Management Network
We recommend connecting all units to a single management network. This network is separate from the cluster control link.
Management Interface
You can assign a Management type interface to the cluster. This interface is a special individual interface as opposed to a Spanned interface. The management interface lets you connect directly to each unit.
For the ASA, the Main cluster IP address is a fixed address for the cluster that always belongs to the current primary unit. You also configure a range of addresses so that each unit, including the current primary unit, can use a Local address from the range. The Main cluster IP address provides consistent management access to an address; when a primary unit changes, the Main cluster IP address moves to the new primary unit, so management of the cluster continues seamlessly. The Local IP address is used for routing, and is also useful for troubleshooting. For example, you can manage the cluster by connecting to the Main cluster IP address, which is always attached to the current primary unit. To manage an individual member, you can connect to the Local IP address. For outbound management traffic such as TFTP or syslog, each unit, including the primary unit, uses the Local IP address to connect to the server.
For the Firepower Threat Defense, assign a management IP address to each unit on the same network. Use these IP addresses when you add each unit to the Management Center.
156
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
About Clustering on the FXOS Chassis
Spanned EtherChannels
You can group one or more interfaces per chassis into an EtherChannel that spans all chassis in the cluster.
The EtherChannel aggregates the traffic across all the available active interfaces in the channel. A Spanned
EtherChannel can be configured in both routed and transparent firewall modes. In routed mode, the
EtherChannel is configured as a routed interface with a single IP address. In transparent mode, the IP address is assigned to the BVI, not to the bridge group member interface. The EtherChannel inherently provides load balancing as part of basic operation.
Inter-Site Clustering
For inter-site installations, you can take advantage of clustering as long as you follow the recommended guidelines.
You can configure each cluster chassis to belong to a separate site ID.
Site IDs work with site-specific MAC addresses and IP addresses. Packets sourced from the cluster use a site-specific MAC address and IP address, while packets received by the cluster use a global MAC address and IP address. This feature prevents the switches from learning the same global MAC address from both sites on two different ports, which causes MAC flapping; instead, they only learn the site MAC address.
Site-specific MAC addresses and IP address are supported for routed mode using Spanned EtherChannels only.
Site IDs are also used to enable flow mobility using LISP inspection and director localization to improve performance and reduce round-trip time latency for inter-site clustering for data centers.
See the following sections for more information about inter-site clustering:
• Sizing the Data Center Interconnect—
Prerequisites for Clustering, on page 158
• Inter-Site Guidelines—
Guidelines for Clustering, on page 159
• Inter-Site Examples—
Examples for Inter-Site Clustering, on page 176
Cisco FXOS CLI Configuration Guide, 2.2(1)
157
Logical Devices
Prerequisites for Clustering
Prerequisites for Clustering
Inter-Chassis Hardware and Software Requirements
All chassis in a cluster:
• For the Firepower 4100 series: All chassis must be the same model. For the Firepower 9300: All security modules 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.
• Must run the identical FXOS software except at the time of an image upgrade.
• 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 inter-chassis clustering.
• Must use the same NTP server. For Firepower Threat Defense, the Firepower Management Center must also use the same NTP server. Do not set the time manually.
• Must be registered with the License Authority when using the ASA; for Firepower Threat Defense, all licensing is handled by the Firepower Management Center.
Switch Prerequisites for Inter-Chassis Clustering
• 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 FXOS chassis.
• For a list of supported switches, see Cisco FXOS Compatibility .
Sizing the Data Center Interconnect for Inter-Site Clustering
You should reserve bandwidth on the data center interconnect (DCI) for cluster control link traffic equivalent to the following calculation:
If the number of members differs at each site, use the larger number for your calculation. The minimum bandwidth for the DCI should not be less than the size of the cluster control link for one member.
For example:
• For 4 members at 2 sites:
◦4 cluster members total
◦2 members at each site
◦5 Gbps cluster control link per member
Reserved DCI bandwidth = 5 Gbps (2/2 x 5 Gbps).
158
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Guidelines for Clustering
• For 6 members at 3 sites, the size increases:
◦6 cluster members total
◦3 members at site 1, 2 members at site 2, and 1 member at site 3
◦10 Gbps cluster control link per member
Reserved DCI bandwidth = 15 Gbps (3/2 x 10 Gbps).
• For 2 members at 2 sites:
◦2 cluster members total
◦1 member at each site
◦10 Gbps cluster control link per member
Reserved DCI bandwidth = 10 Gbps (1/2 x 10 Gbps = 5 Gbps; but the minimum bandwidth should not be less than the size of the cluster control link (10 Gbps)).
Guidelines for Clustering
Models
• ASA on the Firepower 9300—Supported for intra-chassis, inter-chassis, and inter-site clustering.
• ASA on the Firepower 4100 series—Supported for inter-chassis and inter-site clustering.
• Firepower Threat Defense on the Firepower 9300—Supported for intra-chassis and inter-chassis clustering.
• Firepower Threat Defense on the Firepower 4100 series—Supported for inter-chassis clustering.
• Radware DefensePro—Supported for intra-chassis clustering with the ASA.
• Radware DefensePro—Supported for intra-chassis clustering with the Firepower Threat Defense.
Switches for Inter-Chassis Clustering
• For the ASR 9006, if you want to set a non-default MTU, set the ASR interface MTU to be 14 bytes higher than the device MTU. Otherwise, OSPF adjacency peering attempts may fail unless the mtu-ignore option is used. Note that the device MTU should match the ASR IPv4 MTU.
• On the switch(es) for the cluster control link interfaces, you can optionally enable Spanning Tree PortFast on the switch ports connected to the cluster unit to speed up the join process for new units.
• When you see slow bundling of a Spanned EtherChannel on the switch, you can enable LACP rate fast for an Individual interface on the switch.
• On the switch, we recommend that you use one of the following EtherChannel load-balancing algorithms:
source-dest-ip or source-dest-ip-port (see the Cisco Nexus OS and Cisco IOS port-channel
load-balance command). Do not use a vlan keyword in the load-balance algorithm because it can cause unevenly distributed traffic to the devices in a cluster. Do not change the load-balancing algorithm from the default on the device.
Cisco FXOS CLI Configuration Guide, 2.2(1)
159
Logical Devices
Guidelines for Clustering
• If you change the load-balancing algorithm of the EtherChannel on the switch, the EtherChannel interface on the switch temporarily stops forwarding traffic, and the Spanning Tree Protocol restarts. There will be a delay before traffic starts flowing again.
• Network elements on the cluster control link path should not verify the L4 checksum. Redirected traffic over the cluster control link does not have a correct L4 checksum. Switches that verify the L4 checksum could cause traffic to be dropped.
• Port-channel bundling downtime should not exceed the configured keepalive interval.
• On Supervisor 2T EtherChannels, the default hash distribution algorithm is adaptive. To avoid asymmetric traffic in a VSS design, change the hash algorithm on the port-channel connected to the device to fixed: router(config)# port-channel id hash-distribution fixed
Do not change the algorithm globally; you may want to take advantage of the adaptive algorithm for the
VSS peer link.
EtherChannels for Inter-Chassis Clustering
• For connecting switches, set the EtherChannel mode to Active; On mode is not supported on the FXOS chassis, even for the cluster control link.
• FXOS EtherChannels have the LACP rate set to normal by default. This setting can make port-channel members take more than 30 seconds to bundle, which can cause the cluster interface health check to fail causing the unit to be removed from the cluster. We recommend that you change the LACP rate to fast.
The following example modifies the "default" lacp policy: firepower#
scope org
firepower /org #
scope lacppolicy default
firepower /org/lacppolicy#
set lacp-rate fast
firepower /org* #
commit-buffer
• In Catalyst 3750-X Cisco IOS software versions earlier than 15.1(1)S2, the cluster unit did not support connecting an EtherChannel to a switch stack. With default switch settings, if the cluster unit EtherChannel is connected cross stack, and if the master switch is powered down, then the EtherChannel connected to the remaining switch will not come up. To improve compatibility, set the stack-mac persistent timer command to a large enough value to account for reload time; for example, 8 minutes or 0 for indefinite.
Or, you can upgrade to more a more stable switch software version, such as 15.1(1)S2.
• Spanned vs. Device-Local EtherChannel Configuration—Be sure to configure the switch appropriately for Spanned EtherChannels vs. Device-local EtherChannels.
◦Spanned EtherChannels—For cluster unit Spanned EtherChannels, which span across all members of the cluster, the interfaces are combined into a single EtherChannel on the switch. Make sure each interface is in the same channel group on the switch.
160
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Guidelines for Clustering
◦Device-local EtherChannels—For cluster unit Device-local EtherChannels including any
EtherChannels configured for the cluster control link, be sure to configure discrete EtherChannels on the switch; do not combine multiple cluster unit EtherChannels into one EtherChannel on the switch.
Cisco FXOS CLI Configuration Guide, 2.2(1)
161
Defaults for Clustering
Logical Devices
Additional Guidelines
• We recommend connecting EtherChannels to a VSS or vPC for redundancy.
• Within a chassis, you cannot cluster some security modules and run other security modules in standalone mode; you must include all security modules in the cluster.
Defaults for Clustering
The cluster control link uses Port-channel 48.
Configure ASA Clustering
You can easily deploy the cluster from the FXOS chassis supervisor. All initial configuration is automatically generated for each unit. For inter-chassis clustering, you must configure each chassis separately. Deploy the cluster on one chassis; you can then copy the bootstrap configuration from the first chassis to the next chassis for ease of deployment.
162
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Configure ASA Clustering
Before You Begin
• You must enable clustering for all 3 module slots in a Firepower 9300 chassis, even if you do not have a module installed. If you do not configure all 3 modules, the cluster will not come up.
• On the Interfaces tab, the port-channel 48 cluster type interface shows the Operation State as failed if it does not include any member interfaces. For intra-chassis clustering, this EtherChannel does not require any member interfaces, and you can ignore this Operational State.
• You can only deploy a routed firewall mode ASA cluster from the FXOS chassis.
Procedure
Step 1
Configure at least one Data type interface or EtherChannel (also known as a port channel) before you deploy the cluster. See
Create a Port Channel, on page 144
or
Edit Interface Properties, on page 143
.
All interfaces are assigned to the cluster by default. You can also add data interfaces to the cluster after you deploy.
For inter-chassis clustering, all data interfaces must be EtherChannels with at least one member interface.
Add the EtherChannels on each chassis.
Step 2
Add a Management type interface or EtherChannel. See
Create a Port Channel, on page 144
or
.
Step 3
Port-channel 48 is reserved as the cluster control link. For inter-chassis clustering, add at least one member interface to port-channel 48.
Step 4
Enter security services mode:
scope ssa
Example:
Firepower # scope ssa
Firepower /ssa #
Step 5
Create the cluster:
enter logical-device device_name asa "1,2,3" clustered
Example:
Firepower /ssa # enter logical-device ASA1 asa "1,2,3" clustered
Firepower /ssa/logical-device* #
The device_name is used by the FXOS chassis supervisor to configure clustering settings and assign interfaces; it is not the cluster name used in the security module configuration. You must specify all three security modules, even if you have not yet installed the hardware.
Note
You must enable clustering for all 3 module slots in a chassis, even if you do not have a module installed. If you do not configure all 3 modules, the cluster will not come up.
Step 6
Configure the cluster parameters:
enter cluster-bootstrap
Cisco FXOS CLI Configuration Guide, 2.2(1)
163
Logical Devices
Configure ASA Clustering
Example:
Firepower /ssa/logical-device* # enter cluster-bootstrap
Firepower /ssa/logical-device/cluster-bootstrap* #
Step 7
Set the cluster group name in the security module configuration.
set service-type cluster_name
Example:
Firepower /ssa/logical-device/cluster-bootstrap* # set service-type cluster1
Firepower /ssa/logical-device/cluster-bootstrap* #
The name must be an ASCII string from 1 to 38 characters.
Step 8
Set the cluster interface mode:
set mode spanned-etherchannel
Example:
Firepower /ssa/logical-device/cluster-bootstrap* # set mode spanned-etherchannel
Firepower /ssa/logical-device/cluster-bootstrap* #
Spanned EtherChannel mode is the only supported mode.
Step 9
Configure the management IP address information.
This information is used to configure a management interface in the security module configuration.
a) Configure a pool of Local IP addresses, one of which will be assigned to each cluster unit for the interface:
set ipv4 pool start_ip end_ip
set ipv6 pool start_ip end_ip
Include at least as many addresses as there are units in the cluster. Note that for the Firepower 9300, you must include 3 addresses per chassis, even if you do not have all module slots filled. If you plan to expand the cluster, include additional addresses. The Virtual IP address (known as the Main cluster IP address) that belongs to the current primary unit is not a part of this pool; be sure to reserve an IP address on the same network for the Main cluster IP address. You can use IPv4 and/or IPv6 addresses.
b) Configure the Main cluster IP address for the management interface:
set virtual ipv4 ip_address mask mask
set virtual ipv6 ip_address prefix-length prefix
This IP address must be on the same network as the cluster pool addresses, but not be part of the pool.
c) Enter the network gateway address:
set ipv4 gateway ip_address
set ipv6 gateway ip_address
Example:
Firepower /ssa/logical-device/cluster-bootstrap* # set ipv4 gateway 10.1.1.254
Firepower /ssa/logical-device/cluster-bootstrap* # set ipv4 pool 10.1.1.11 10.1.1.27
Firepower /ssa/logical-device/cluster-bootstrap* # set ipv6 gateway 2001:DB8::AA
Firepower /ssa/logical-device/cluster-bootstrap* # set ipv6 pool 2001:DB8::11 2001:DB8::27
Firepower /ssa/logical-device/cluster-bootstrap* # set virtual ipv4 10.1.1.1 mask
164
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Configure ASA Clustering
255.255.255.0
Firepower /ssa/logical-device/cluster-bootstrap* # set virtual ipv6 2001:DB8::1 prefix-length
64
Step 10 Set the chassis ID:
set chassis-id id
Each chassis in the cluster needs a unique ID.
Example:
Firepower /ssa/logical-device/cluster-bootstrap* # set chassis-id 1
Firepower /ssa/logical-device/cluster-bootstrap* #
Step 11 For inter-site clustering, set the site ID between 1 and 8:
set site-id number.
Example:
Firepower /ssa/logical-device/cluster-bootstrap* # set site-id 1
Firepower /ssa/logical-device/cluster-bootstrap* #
Step 12 Configure an authentication key for control traffic on the cluster control link:
set key
Example:
Firepower /ssa/logical-device/cluster-bootstrap* # set key
Key: diamonddogs
Firepower /ssa/logical-device/cluster-bootstrap* #
You are prompted to enter the shared secret.
The shared secret is an ASCII string from 1 to 63 characters. The shared secret is used to generate the key.
This option does not affect datapath traffic, including connection state update and forwarded packets, which are always sent in the clear.
Step 13 Exit the cluster bootstrap mode and logical device mode:
exit exit
Step 14 View the available software versions and then set the version you want to use: a) Show the available versions:
show app
Example:
/ssa # show app
Application:
Name Version Description Author Deploy Type CSP Type Is Default App
---------- ---------- ----------- ---------- --------------------- -------------asa asa asa
9.1.4.152
N/A
9.4.2
N/A
9.5.2.1
N/A cisco cisco cisco
Native
Native
Native
Application Yes
Application No
Application No
Cisco FXOS CLI Configuration Guide, 2.2(1)
165
Logical Devices
Configure ASA Clustering
b) Enter app mode for the version you want to use:
scope app asa version_number c) Set this version as the default:
set-default
d) Exit app mode:
exit
Example:
/ssa* # scope app asa 9.5.2.1
/ssa/app* # set-default
/ssa/app* # exit
/ssa* #
Step 15 Commit the configuration:
commit-buffer
The FXOS chassis supervisor deploys the cluster by downloading the default security module software version and pushing the cluster bootstrap configuration and management interface settings to each security module.
Step 16 To add another chassis to the cluster, repeat this procedure except you must configure a unique chassis-id and the correct site-id; otherwise, use the same configuration for both chassis.
Step 17 Connect to the primary unit security module to customize your clustering configuration.
Example
For chassis 1: scope eth-uplink scope fabric a enter port-channel 1 set port-type data enable enter member-port Ethernet1/1 exit enter member-port Ethernet1/2 exit exit enter port-channel 2 set port-type data enable enter member-port Ethernet1/3 exit enter member-port Ethernet1/4 exit exit enter port-channel 3 set port-type data enable enter member-port Ethernet1/5 exit enter member-port Ethernet1/6 exit exit enter port-channel 4 set port-type mgmt enable enter member-port Ethernet2/1
166
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Configure ASA Clustering
exit enter member-port Ethernet2/2 exit exit enter port-channel 48 set port-type cluster enable enter member-port Ethernet2/3 exit exit exit exit commit-buffer scope ssa enter logical-device ASA1 asa "1,2,3" clustered enter cluster-bootstrap
set chassis-id 1
set ipv4 gateway 10.1.1.254
set ipv4 pool 10.1.1.11 10.1.1.27
set ipv6 gateway 2001:DB8::AA set ipv6 pool 2001:DB8::11 2001:DB8::27 set key
Key: f@arscape set mode spanned-etherchannel set service-type cluster1 set virtual ipv4 10.1.1.1 mask 255.255.255.0
set virtual ipv6 2001:DB8::1 prefix-length 64 exit exit scope app asa 9.5.2.1
set-default exit commit-buffer
For chassis 2: scope eth-uplink scope fabric a create port-channel 1 set port-type data enable create member-port Ethernet1/1 exit create member-port Ethernet1/2 exit exit create port-channel 2 set port-type data enable create member-port Ethernet1/3 exit create member-port Ethernet1/4 exit exit create port-channel 3 set port-type data enable create member-port Ethernet1/5 exit create member-port Ethernet1/6 exit exit create port-channel 4 set port-type mgmt enable create member-port Ethernet2/1 exit create member-port Ethernet2/2 exit exit create port-channel 48
Cisco FXOS CLI Configuration Guide, 2.2(1)
167
Logical Devices
Configure Firepower Threat Defense Clustering
set port-type cluster enable create member-port Ethernet2/3 exit exit exit exit commit-buffer scope ssa enter logical-device ASA1 asa "1,2,3" clustered enter cluster-bootstrap
set chassis-id 2
set ipv4 gateway 10.1.1.254
set ipv4 pool 10.1.1.11 10.1.1.15
set ipv6 gateway 2001:DB8::AA set ipv6 pool 2001:DB8::11 2001:DB8::19 set key
Key: f@rscape set mode spanned-etherchannel set service-type cluster1 set virtual ipv4 10.1.1.1 mask 255.255.255.0
set virtual ipv6 2001:DB8::1 prefix-length 64 exit exit scope app asa 9.5.2.1
set-default exit commit-buffer
Configure Firepower Threat Defense Clustering
You can easily deploy the cluster from the FXOS chassis supervisor. All initial configuration is automatically generated for each unit. For inter-chassis clustering, you must configure each chassis separately. Deploy the cluster on one chassis; you can then copy the bootstrap configuration from the first chassis to the next chassis for ease of deployment.
Before You Begin
• You must enable clustering for all 3 module slots in a Firepower 9300 chassis, even if you do not have a module installed. If you do not configure all 3 modules, the cluster will not come up.
• On the Interfaces tab, the port-channel 48 cluster type interface shows the Operation State as failed if it does not include any member interfaces. For intra-chassis clustering, this EtherChannel does not require any member interfaces, and you can ignore this Operational State.
Procedure
Step 1
Configure at least one Data type interface or EtherChannel (also known as port channels) before you deploy the cluster. See
Create a Port Channel, on page 144
or
Edit Interface Properties, on page 143
.
You can also add data interfaces to the cluster after you deploy.
For inter-chassis clustering, all data interfaces must be EtherChannels with at least one member interface.
Add the EtherChannels on each chassis.
Step 2
(Optional) Configure a Firepower-eventing type interface before you deploy the cluster. See
.
168
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Configure Firepower Threat Defense Clustering
This interface is a secondary management interface for Firepower Threat Defense 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 configure network commands in the Firepower Management Center command reference.
Step 3
Add a Management type interface or EtherChannel. See
Create a Port Channel, on page 144
or
.
Step 4
Port-channel 48 is reserved as the cluster control link. For inter-chassis clustering, add at least one member interface to port-channel 48.
Step 5
Enter security services mode:
scope ssa
Example:
Firepower # scope ssa
Firepower /ssa #
Step 6
Create the cluster:
enter logical-device device_name ftd "1,2,3" clustered
Example:
Firepower /ssa # enter logical-device FTD1 ftd "1,2,3" clustered
Firepower /ssa/logical-device* #
The device_name is used by the FXOS chassis supervisor to configure clustering settings and assign interfaces; it is not the cluster name used in the security module configuration.
Note
You must enable clustering for all 3 module slots in a chassis, even if you do not have a module installed. If you do not configure all 3 modules, the cluster will not come up.
Step 7
Configure the cluster bootstrap parameters: a) Create the cluster bootstrap object:
enter cluster-bootstrap
b) Set the chassis ID:
set chassis-id id
Each chassis in the cluster needs a unique ID.
c) Set the cluster key in the security module configuration:
set key
You are prompted to enter the shared secret.
The shared secret is an ASCII string from 1 to 63 characters. The shared secret is used to generate the key.
This option does not affect datapath traffic, including connection state update and forwarded packets, which are always sent in the clear.
d) Set the cluster interface mode:
set mode spanned-etherchannel
Spanned EtherChannel mode is the only supported mode.
e) Set the cluster group name in the security module configuration:
set service-type cluster_name
Cisco FXOS CLI Configuration Guide, 2.2(1)
169
Logical Devices
Configure Firepower Threat Defense Clustering
The name must be an ASCII string from 1 to 38 characters.
f) Exit the cluster bootstrap mode:
exit
Example:
Firepower /ssa/logical-device* # enter cluster-bootstrap
Firepower /ssa/logical-device/cluster-bootstrap* # set chassis-id 1
Firepower /ssa/logical-device/cluster-bootstrap* # set key
Key: f@arscape
Firepower /ssa/logical-device/cluster-bootstrap* # set mode spanned-etherchannel
Firepower /ssa/logical-device/cluster-bootstrap* # set service-type cluster1
Firepower /ssa/logical-device/cluster-bootstrap* # exit
Firepower /ssa/logical-device/* #
Step 8
Configure the management bootstrap parameters: a) Create the management bootstrap object:
enter mgmt-bootstrap ftd
b) Specify the IP address of the managing Firepower Management Center:
enter bootstrap-key FIREPOWER_MANAGER_IP
set value IP_address
exit
c) Specify the mode in which the logical device will operate (routed or transparent):
enter bootstrap-key FIREWALL_MODE
set value firewall_mode
exit
d) Specify the key to be shared between the device and the Firepower Management Center:
enter bootstrap-key-secret REGISTRATION_KEY set value
registration_key
exit
e) Specify the password to use for the logical device:
enter bootstrap-key-secret PASSWORD set value
password
exit
f) Specify the fully qualified hostname for the logical device:
enter bootstrap-key FQDN
set value fqdn
exit
g) Specify a comma-separated list of DNS servers to be used by the logical device:
enter bootstrap-key DNS_SERVERS
set value dns_servers
170
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Configure Firepower Threat Defense Clustering exit
h) Specify a comma-separated list of search domains for the logical device:
enter bootstrap-key SEARCH_DOMAINS
set value search_domains
exit
i) Configure the management IP addresses for each security module in the cluster.
Note
For the Firepower 9300, you must set the IP address for all 3 module slots in a chassis, even if you do not have a module installed. If you do not configure all 3 modules, the cluster will not come up.
To create an IPv4 management interface object:
1
Create the management interface object:
enter ipv4 slot_id firepower
2
Set the gateway address:
set gateway gateway_address
3
Set the IP address and mask:
set ip ip_address mask network_mask
4
Exit the management IP mode:
exit
5
Repeat for the remaining modules in the chassis.
To create an IPv6 management interface object:
1
Create the management interface object:
enter ipv6 slot_id firepower
2
Set the gateway address:
set gateway gateway_address
3
Set the IP address and prefix:
set ip ip_address prefix-length prefix
4
Exit the management IP mode:
exit
5
Repeat for the remaining modules in the chassis.
j) Exit the management bootstrap mode:
exit
Example:
Firepower /ssa/logical-device* # enter mgmt-bootstrap ftd
Firepower /ssa/logical-device/mgmt-bootstrap* # enter bootstrap-key FIREPOWER_MANAGER_IP
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # set value 10.0.0.100
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # enter bootstrap-key FIREWALL_MODE
Cisco FXOS CLI Configuration Guide, 2.2(1)
171
Logical Devices
Configure Firepower Threat Defense Clustering
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # set value routed
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # enter bootstrap-key-secret REGISTRATION_KEY
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # set value
Value: ziggy$tardust
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # enter bootstrap-key-secret PASSWORD
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # set value
Value: $pidersfrommars
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key-secret* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # enter bootstrap-key FQDN
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # set value example.cisco.com
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # enter bootstrap-key DNS_SERVERS
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # set value 192.168.1.1
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # enter bootstrap-key SEARCH_DOMAINS
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # set value example.com
Firepower /ssa/logical-device/mgmt-bootstrap/bootstrap-key* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # enter ipv4 1 firepower
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # set gateway 10.0.0.1
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # set ip 10.0.0.31 mask 255.255.255.0
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # enter ipv4 2 firepower
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # set gateway 10.0.0.1
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # set ip 10.0.0.32 mask 255.255.255.0
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # enter ipv4 3 firepower
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # set gateway 10.0.0.1
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # set ip 10.0.0.33 mask 255.255.255.0
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* # exit
Firepower /ssa/logical-device/mgmt-bootstrap* # exit
Firepower /ssa/logical-device* #
Step 9
Exit the logical device mode:
exit
Step 10 View the available software versions and then set the version you want to use: a) Show the available versions:
show app
Example:
/ssa # show app
Application:
Name Version Description Author Deploy Type CSP Type Is Default App
---------- ---------- ----------- ---------- ----------- ----------- -------------ftd ftd ftd
6.0.1.37
6.1.0.11
6.1.0.21
N/A
N/A
N/A cisco cisco cisco
Native
Native
Native
Application Yes
Application No
Application No b) Enter app mode for the version you want to use:
scope app ftd version_number c) Set this version as the default:
set-default
d) Accept the end-user license agreement for this version:
accept-license-agreement
e) Exit app mode:
exit
172
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Configure Firepower Threat Defense Clustering
Example:
/ssa # scope app ftd 6.1.0.21
/ssa/app # set-default
/ssa/app* # accept-license-agreement
/ssa/app* # exit
/ssa* #
Step 11 Commit the configuration:
commit-buffer
The FXOS chassis supervisor deploys the cluster by downloading the default security module software version and pushing the cluster bootstrap configuration and management interface settings to each security module.
Step 12 To add another chassis to the cluster, repeat this procedure except you must configure a unique chassis-id and unique management IP addresses; otherwise, use the same configuration for both chassis.
Step 13 Add each security module to the Firepower Management Center using the management IP addresses, and then group them into a cluster at the web interface.
All cluster units must be in a successfully-formed cluster on FXOS prior to adding them to Firepower
Management Center.
Example
scope eth-uplink scope fabric a enter port-channel 1 set port-type data enable create member-port Ethernet1/1 exit create member-port Ethernet1/2 exit exit enter port-channel 2 set port-type data enable create member-port Ethernet1/3 exit create member-port Ethernet1/4 exit exit enter port-channel 3 set port-type firepower-eventing enable create member-port Ethernet1/5 exit create member-port Ethernet1/6 exit exit enter port-channel 4 set port-type mgmt enable create member-port Ethernet2/1 exit enter member-port Ethernet2/2 exit exit enter port-channel 48 set port-type cluster enable enter member-port Ethernet2/3
Cisco FXOS CLI Configuration Guide, 2.2(1)
173
Configure Firepower Threat Defense Clustering
exit exit exit exit commit-buffer scope ssa enter logical-device FTD1 ftd "1,2,3" clustered enter cluster-bootstrap
set chassis-id 1
set key cluster_key set mode spanned-etherchannel set service-type ftd-cluster exit enter mgmt-bootstrap ftd enter bootstrap-key FIREPOWER_MANAGER_IP set value 10.0.0.100
exit enter bootstrap-key FIREWALL_MODE set value transparent exit enter bootstrap-key-secret REGISTRATION_KEY set value
Value: alladinsane exit enter bootstrap-key-secret PASSWORD set value
Value: widthofacircle exit enter bootstrap-key FQDN set value ftd.cisco.com
exit enter bootstrap-key DNS_SERVERS set value 192.168.1.1
exit enter bootstrap-key SEARCH_DOMAINS set value search.com
exit enter ipv4 1 firepower set gateway 10.0.0.1
set ip 10.0.0.31 mask 255.255.255.0
exit enter ipv4 2 firepower set gateway 10.0.0.1
set ip 10.0.0.32 mask 255.255.255.0
exit enter ipv4 3 firepower set gateway 10.0.0.1
set ip 10.0.0.33 mask 255.255.255.0
exit exit exit scope app ftd 6.0.0.837
accept-license-agreement exit commit-buffer
For chassis 2: scope eth-uplink scope fabric a enter port-channel 1 set port-type data enable create member-port Ethernet1/1 exit create member-port Ethernet1/2 exit exit enter port-channel 2 set port-type data enable
174
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Logical Devices
Configure Firepower Threat Defense Clustering
create member-port Ethernet1/3 exit create member-port Ethernet1/4 exit exit enter port-channel 3 set port-type firepower-eventing enable create member-port Ethernet1/5 exit create member-port Ethernet1/6 exit exit enter port-channel 4 set port-type mgmt enable create member-port Ethernet2/1 exit enter member-port Ethernet2/2 exit exit enter port-channel 48 set port-type cluster enable enter member-port Ethernet2/3 exit exit exit exit commit-buffer scope ssa enter logical-device FTD1 ftd "1,2,3" clustered enter cluster-bootstrap
set chassis-id 2
set key cluster_key set mode spanned-etherchannel set service-type ftd-cluster exit enter mgmt-bootstrap ftd enter bootstrap-key FIREPOWER_MANAGER_IP set value 10.0.0.100
exit enter bootstrap-key FIREWALL_MODE set value transparent exit enter bootstrap-key-secret REGISTRATION_KEY set value
Value: alladinsane exit enter bootstrap-key-secret PASSWORD set value
Value: widthofacircle exit enter bootstrap-key FQDN set value ftd.cisco.com
exit enter bootstrap-key DNS_SERVERS set value 192.168.1.1
exit enter bootstrap-key SEARCH_DOMAINS set value search.com
exit enter ipv4 1 firepower set gateway 10.0.0.1
set ip 10.0.0.31 mask 255.255.255.0
exit enter ipv4 2 firepower set gateway 10.0.0.1
set ip 10.0.0.32 mask 255.255.255.0
exit enter ipv4 3 firepower set gateway 10.0.0.1
Cisco FXOS CLI Configuration Guide, 2.2(1)
175
Logical Devices
Examples for Inter-Site Clustering
set ip 10.0.0.33 mask 255.255.255.0
exit exit exit scope app ftd 6.0.0.837
accept-license-agreement exit commit-buffer
Examples for Inter-Site Clustering
The following examples show supported cluster deployments.
Spanned EtherChannel Transparent Mode North-South Inter-Site Example
The following example shows 2 cluster members at each of 2 data centers placed between inside and outside routers (North-South insertion). The cluster members are connected by the cluster control link over the DCI.
The cluster members at each site connect to the local switches using spanned EtherChannels for the inside and outside. Each EtherChannel is spanned across all chassis in the cluster.
The inside and outside routers at each data center use OSPF, which is passed through the transparent ASAs.
Unlike MACs, router IPs are unique on all routers. By assigning a higher cost route across the DCI, traffic stays within each data center unless all cluster members at a given site go down. The lower cost route through the ASAs must traverse the same bridge group at each site for the cluster to maintain asymmetric connections.
In the event of a failure of all cluster members at one site, traffic goes from each router over the DCI to the cluster members at the other site.
The implementation of the switches at each site can include:
• Inter-site VSS/vPC—In this scenario, you install one switch at Data Center 1, and the other at Data
Center 2. One option is for the cluster units at each Data Center to only connect to the local switch, while the VSS/vPC traffic goes across the DCI. In this case, connections are for the most part kept local to each datacenter. You can optionally connect each unit to both switches across the DCI if the DCI can handle the extra traffic. In this case, traffic is distributed across the data centers, so it is essential for the
DCI to be very robust.
• Local VSS/vPC at each site—For better switch redundancy, you can install 2 separate VSS/vPC pairs at each site. In this case, although the cluster units still have a spanned EtherChannel with Data Center
1 chassis connected only to both local switches, and Data Center 2 chassis connected to those local switches, the spanned EtherChannel is essentially “split.” Each local VSS/vPC sees the spanned
EtherChannel as a site-local EtherChannel.
176
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Examples for Inter-Site Clustering
Spanned EtherChannel Transparent Mode East-West Inter-Site Example
The following example shows 2 cluster members at each of 2 data centers placed between the gateway router and two inside networks at each site, the App network and the DB network (East-West insertion). The cluster members are connected by the cluster control link over the DCI. The cluster members at each site connect to the local switches using spanned EtherChannels for both the App and DB networks on the inside and outside.
Each EtherChannel is spanned across all chassis in the cluster.
The gateway router at each site uses an FHRP such as HSRP to provide the same destination virtual MAC and IP addresses at each site. A good practice to avoid unintended MAC address flapping is to statically add the gateway routers real MAC addresses to the ASA MAC address table using the mac-address-table static
outside_interface mac_address command. Without these entries, if the gateway at site 1 communicates with the gateway at site 2, that traffic might pass through the ASA and attempt to reach site 2 from the inside interface and cause problems. The data VLANs are extended between the sites using Overlay Transport
Virtualization (OTV) (or something similar). You must add filters to prevent traffic from traversing the DCI to the other site when the traffic is destined for the gateway router. If the gateway router at one site becomes unreachable, you must remove the filters so traffic can be sent to the other site’s gateway router.
Cisco FXOS CLI Configuration Guide, 2.2(1)
177
History for Clustering
Logical Devices
See
Spanned EtherChannel Transparent Mode North-South Inter-Site Example, on page 176
for information about vPC/VSS options.
History for Clustering
Feature Name Platform
Releases
Intra-chassis Clustering for the Cisco ASA
1.1.1
Feature Information
You can cluster all ASA security modules within the Firepower 9300 chassis.
We introduced the following commands: enter cluster-bootstrap, enter logical-device
clustered, set chassis-id, set ipv4 gateway, set ipv4 pool, set ipv6 gateway, set ipv6 pool, set key, set mode spanned-etherchannel, set port-type cluster, set service-type, set virtual ipv4, set virtual ipv6
Inter-chassis clustering for
6 ASA modules
1.1.3
You can now enable inter-chassis clustering for the ASA. You can include up to 6 modules in up to 6 chassis.
178
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Configure Service Chaining
Feature Name Platform
Releases
Feature Information
Support for intra-chassis clustering on the
Firepower Threat Defense on the Firepower 9300
1.1.4
The Firepower 9300 supports intra-chassis clustering with the Firepower Threat Defense application.
We introduced the following 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
Inter-site clustering improvement for the ASA on the FXOS chassis
2.1.1
Inter-chassis clustering for
6 Firepower Threat
Defense modules
2.1.1
You can now configure the site ID for each FXOS chassis when you deploy the ASA cluster.
Previously, you had to configure the site ID within the ASA application; this new feature eases initial deployment. Note that you can no longer set the site ID within the ASA configuration. Also, for best compatibility with inter-site clustering, we recommend that you upgrade to ASA 9.7(1) and FXOS 2.1.1, which includes several improvements to stability and performance.
We modified the following command: set site-id
You can now enable inter-chassis clustering for the Firepower Threat Defense. You can include up to 6 modules in up to 6 chassis.
Configure Service Chaining
The Cisco FXOS chassis can support multiple services (for example, a firewall and a third-party DDoS application) on a single blade. These applications and services can be linked together to form a Service Chain.
About Service Chaining
In the current supported Service Chaining configuration, the third-party Radware DefensePro virtual platform can be installed to run in front of the ASA firewall, or in front of Firepower Threat Defense. Radware
DefensePro is a KVM-based virtual platform that provides distributed denial-of-service (DDoS) detection and mitigation capabilities on the FXOS chassis. When Service Chaining is enabled on your FXOS chassis, traffic from the network must first pass through the DefensePro virtual platform before reaching the main
ASA or Firepower Threat Defense firewall.
The Radware DefensePro virtual platform may be referred to as Radware vDP (virtual DefensePro), or simply
vDP. The Radware DefensePro virtual platform may occasionally be referred to as a Link Decorator.
Prerequisites for Service Chaining
Prior to deploying Radware DefensePro on your FXOS chassis, you must configure the FXOS chassis to use an NTP Server with the etc/UTC Time Zone. For more information about setting the date and time in your
FXOS chassis, see
Setting the Date and Time, on page 103
.
Cisco FXOS CLI Configuration Guide, 2.2(1)
179
Logical Devices
Guidelines for Service Chaining
Guidelines for Service Chaining
Models
• The Radware DefensePro platform is supported with ASA on the following security appliances:
◦Firepower 9300
◦Firepower 4120 - You must use the CLI to deploy Radware DefensePro on this platform; the
Firepower Chassis Manager does not yet support this functionality.
◦Firepower 4140 - You must use the CLI to deploy Radware DefensePro on this platform; the
Firepower Chassis Manager does not yet support this functionality.
◦Firepower 4150
• The Radware DefensePro platform is supported with Firepower Threat Defense on the following security appliances:
◦Firepower 9300
◦Firepower 4110 - Note you must deploy the decorator at the same time as the logical device. You cannot install the decorator after the logical device is already configured on the device.
◦Firepower 4120 - Note you must deploy the decorator at the same time as the logical device. You cannot install the decorator after the logical device is already configured on the device.
◦Firepower 4140
◦Firepower 4150
Additional Guidelines
• Service Chaining is not supported in an inter-chassis cluster configuration. However, the Radware
DefensePro application can be deployed in a standalone configuration in an inter-chassis cluster scenario.
• The DefensePro application can run as separate instances on up to three security modules.
Configure Radware DefensePro Service Chain on a Standalone Logical Device
The following procedure shows how to install Radware DefensePro in a single Service Chain in front of a standalone ASA or Firepower Threat Defense logical device.
Before You Begin
• Download the vDP image from Cisco.com (see
Downloading Images from Cisco.com, on page 48
) and then download that image to the FXOS chassis (see
Downloading a Logical Device Software Image to the FXOS chassis, on page 51
).
• You can deploy the Radware DefensePro application in a standalone configuration on an intra-chassis cluster; for intra-chassis clustering, see
Configure Radware DefensePro Service Chain on an Intra-Chassis
.
180
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Configure Radware DefensePro Service Chain on a Standalone Logical Device
Procedure
Step 1
If you want to use a separate management interface for vDP, enable the interface and set it to be the mgmt type according to
Edit Interface Properties, on page 143
. Otherwise, you can share the application management interface.
Step 2
Create an ASA or Firepower Threat Defense logical device in standalone configuration (see
ASA Logical Device, on page 148
or
Create a Standalone Threat Defense Logical Device, on page 150
). Note that if you are installing the images on a Firepower 4110 or 4120 security appliance, you must install vDP along with the Firepower Threat Defense image before you commit your configuration.
Step 3
Enter security services mode:
Firepower# scope ssa
Step 4
Create the Radware vDP instance:
Firepower /ssa # scope slot slot_id
Firepower /ssa/slot # create app-instance vdp
Firepower /ssa/slot/app-instance* # exit
Firepower /ssa/slot/* # exit
Step 5
Commit the configuration:
commit-buffer
Step 6
Verify the installation and provisioning of vDP on the security module:
show app-instance
Example:
Firepower /ssa # show app-instance
App Name Slot ID
State Cluster Role
Admin State Oper State ftd 1
Applicable None
Enabled Online
Running Version Startup Version Cluster
---------- ---------- ----------- ---------------- --------------- ---------------
--------------- ------------
6.2.1.62
6.2.1.62
Not vdp 1
Applicable None
Disabled Installing 8.10.01.16-5 Not
Step 7
After the vDP application is in an Online state, access the logical device:
Firepower /ssa # scope logical-device device_name
Step 8
Assign the management interface to vDP. You can use the same physical interface as for the logical device, or you can use a separate interface.
Firepower /ssa/logical-device # enter external-port-link nameinterface_id vdp
Firepower /ssa/logical-device/external-port-link* # exit
Step 9
Configure the external management interface settings for vDP.
a) Create the bootstrap object:
Firepower /ssa/logical-device* # create mgmt-bootstrap vdp b) Configure the management IP address:
Firepower /ssa/logical-device/mgmt-bootstrap* #create ipv4 slot_id default c) Set the gateway address:
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* #set gateway gateway_address
Cisco FXOS CLI Configuration Guide, 2.2(1)
181
Logical Devices
Configure Radware DefensePro Service Chain on an Intra-Chassis Cluster
d) Set the IP address and mask:
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* #set ip ip_address mask network_mask e) Exit the management IP configuration scope:
Firepower /ssa/logical-device/mgmt-bootstrap/ipv4* #exit f) Exit the management bootstrap configuration scope:
Firepower /ssa/logical-device/mgmt-bootstrap* #exit
Step 10 Edit the data interface where you want to place the vDP in front of the ASA or Firepower Threat Defense flow:
Firepower /ssa/logical-device* # scope external-port-link name
Enter the show external-port-link command to view interface names.
Step 11 Add the vDP to the logical device:
Firepower /ssa/logical-device/external-port-link* # set decorator vdp
Repeat for each interface where you want to use vDP.
Step 12 Verify that the third-party app is set for the interface:
Firepower /ssa/logical-device/external-port-link* # show detail
Example:
Firepower /ssa/logical-device/external-port-link # show detail
External-Port Link:
Name: Ethernet11_ftd
Port or Port Channel Name: Ethernet1/1
App Name: ftd
Description:
Link Decorator: vdp
Step 13 Commit the configuration:
commit-buffer
Configure Radware DefensePro Service Chain on an Intra-Chassis Cluster
Before You Begin
• Download the vDP image from Cisco.com (see
Downloading Images from Cisco.com, on page 48
) and then download that image to the FXOS chassis (see
Downloading a Logical Device Software Image to the FXOS chassis, on page 51
).
182
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Configure Radware DefensePro Service Chain on an Intra-Chassis Cluster
Procedure
Step 1
If you want to use a separate management interface for vDP, enable the interface and set it to be the mgmt type according to
Edit Interface Properties, on page 143
. Otherwise, you can share the application management interface.
Step 2
Configure an ASA intra-chassis cluster (see
Configure ASA Clustering, on page 162
) or a Firepower Threat
Defense intra-chassis cluster (see
Configure Firepower Threat Defense Clustering, on page 168
).
Step 3
Decorate the external (client-facing) port with Radware DefensePro:
enter external-port-link name interface_name { asa | ftd } set decorator vdp set description ''''
exit
Step 4
Assign the external management port for the logical device: enter external-port-link { mgmt_asa | mgmt_ftd } interface_id { asa | ftd } set decorator '''' set description ''''
exit
Step 5
Assign the external management port for DefensePro: enter external-port-link mgmt_vdp interface_name { asa | ftd } set decorator '''' set description ''''
Step 6
Configure cluster port channel: enter external-port-link port-channel48 Port-channel48 { asa | ftd } set decorator '''' set description ''''
exit
Step 7
Configure management bootstrap for all three DefensePro instances: enter mgmt-bootstrap vdp enter ipv4 slot_id default
set gateway gateway_address
set ip ip_address mask network_mask
exit
Example:
enter mgmt-bootstrap vdp enter ipv4 1 default set gateway 172.16.0.1
exit set ip 172.16.4.219 mask 255.255.0.0
enter ipv4 2 default
Cisco FXOS CLI Configuration Guide, 2.2(1)
183
Logical Devices
Configure Radware DefensePro Service Chain on an Intra-Chassis Cluster
exit set gateway 172.16.0.1
set ip 172.16.4.220 mask 255.255.0.0
enter ipv4 3 default set gateway 172.16.0.1
exit set ip 172.16.4.221 mask 255.255.0.0
Step 8
Exit management bootstrap configuration scope:
exit
Step 9
On the master blade, set the management IP and enable clustering:
device clusteringmanagement-channel ip
device clusteringmasterset management-channel ip
device clusteringstateset enable
Step 10 Commit the configuration:
commit-buffer
Note
After completing this procedure, you must verify whether the DefensePro instances are configured in a cluster.
Step 11 Use either of the following methods to verify which DefensePro instance is primary, and which one is secondary.
a) Scope the DefensePro instance and show appplication attributes for DefensePro only:
scope ssa
scope slot_number
scope app-instance vdp show app-attri
b) Scope the slot and show the DefensePro instance in expanded detail. This approach displays information for both logical device and vDP application instances on the slot.
scope ssa
scope slot_number
show app-instance expand detail
If the DefensePro application is online but not yet formed in a cluster, the CLI displays:
App Attribute:
App Attribute Key: cluster-role
Value: unknown
If the system displays this "unknown" value, you must enter the DefensePro application and configure the master IP address to create the vDP cluster.
If the DefensePro application is online and formed in a cluster, the CLI displays:
App Attribute:
App Attribute Key: cluster-role
Value: primary/secondary
Example
scope ssa enter logical-device ld asa "1,2,3" clustered enter cluster-bootstrap set chassis-id 1 set ipv4 gateway 172.16.0.1
set ipv4 pool 172.16.4.216 172.16.4.218
184
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Open UDP/TCP Ports and Enable vDP Web Services
set ipv6 gateway 2010::2 set ipv6 pool 2010::21 2010::26 set key secret set mode spanned-etherchannel set name cisco set virtual ipv4 172.16.4.222 mask 255.255.0.0
set virtual ipv6 2010::134 prefix-length 64 exit enter external-port-link Ethernet1-2 Ethernet1/2 asa exit set decorator vdp set description "" enter external-port-link Ethernet1-3_asa Ethernet1/3 asa set decorator "" exit set description "" enter external-port-link mgmt_asa Ethernet1/1 asa set decorator "" exit set description "" enter external-port-link mgmt_vdp Ethernet1/1 vdp set decorator "" set description "" exit enter external-port-link port-channel48 Port-channel48 asa set decorator "" set description "" exit enter mgmt-bootstrap vdp enter ipv4 1 default exit set gateway 172.16.0.1
set ip 172.16.4.219 mask 255.255.0.0
enter ipv4 2 default set gateway 172.16.0.1
exit set ip 172.16.4.220 mask 255.255.0.0
enter ipv4 3 default set gateway 172.16.0.1
exit set ip 172.16.4.221 mask 255.255.0.0
exit commit-buffer scope ssa scope slot 1 scope app-instance vdp show app-attri
App Attribute:
App Attribute Key: cluster-role
Value: unknown
Open UDP/TCP Ports and Enable vDP Web Services
The Radware APSolute Vision Manager interfaces communicate with the Radware vDP appliation using various UDP/TCP ports. In orer for the vDP application to communicate with the APSolute Vision Manager, you must ensure that these ports are accessible and not blocked by your firewall. For more information on which specific ports to open, see the following tables in the APSolute Vision User Guide:
• Ports for APSolute Vision Server-WBM Communication and Operating System
• Communication Ports for APSolute Vision Server with Radware Devices
In order for Radware APSolute Vision to manage the Virtual DefensePro application deployed on the FXOS chassis, you must enable the vDP web service using the FXOS CLI.
Cisco FXOS CLI Configuration Guide, 2.2(1)
185
Logical Devices
Manage Logical Devices
Procedure
Step 1
From the FXOS CLI, connect to the vDP application instance.
connect module slot console
connect vdp
Step 2
Enable vDP web services.
manage secure-web status set enable
Step 3
Exit the vDP application console and return to the FXOS module CLI.
Ctrl ]
Manage Logical Devices
You can delete a logical device, convert an ASA to transparent mode, change the interface configuration, and perform other tasks on existing logical devices.
Connect to the Console of the Application or Decorator
Use the following procedure to connect to the console of the application or decorator.
Note
If you encounter any issues with accessing the console, we recommend that you try a different SSH client or upgrade your SSH client to a newer version.
Procedure
Step 1
To connect to the console of the application or decorator: a) From the FXOS CLI, connect to the security module/engine:
Firepower-chassis # connect module slot_number console
Note
To connect to the security engine of a device that does not support multiple security modules, use 1 as the slot_number.
The first time you connect to the security module, you access the FXOS module CLI.
b) To connect to the application or decorator, enter the appropriate command for your device:
Firepower-module1>connect asa
Firepower-module1>connect ftd
Firepower-module1>connect vdp
Subsequent connections from the supervisor level of the FXOS CLI to the security module/engine access the security module/engine OS directly.
Step 2
(Optional) Exit the application console to the FXOS module CLI by typing Ctrl-A-D.
186
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Delete a Logical Device
Exit the decorator console to the FXOS module CLI by typing Ctrl-]-.
You might want to access the FXOS module CLI for troubleshooting purposes.
Step 3
Return to the supervisor level of the FXOS CLI.
a) To exit the security module/engine console, type ~.
You exit to the Telnet application.
b) To exit the Telnet application, enter: telnet>quit
Example
The following example connects to an ASA on security module 1 and then exits back to the supervisor level of the FXOS CLI.
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>
connect asa
asa>
~
telnet>
quit
Connection closed.
Firepower#
Delete a Logical Device
Procedure
Step 1
Enter security services mode:
Firepower# scope ssa
Step 2
View details for the logical devices on the chassis:
Firepower /ssa # show logical-device
Step 3
For each logical device that you want to delete, enter the following command:
Firepower /ssa # delete logical-device device_name
Step 4
View details for the applications installed on the logical devices:
Firepower /ssa # show app-instance
Step 5
For each application that you want to delete, enter the following commands: a) Firepower /ssa # scope slot slot_number b) Firepower /ssa/slot # delete app-instance application_name c) Firepower /ssa/slot # exit
Step 6
Commit the configuration:
Cisco FXOS CLI Configuration Guide, 2.2(1)
187
Logical Devices
Delete an Application Instance that is not Associated with a Logical Device commit-buffer
Commits the transaction to the system configuration.
Example
Firepower# scope ssa
Firepower /ssa # show logical-device
Logical Device:
Name Description Slot ID Mode Operational State Template Name
---------- ----------- ---------- ---------- ------------------------ -------------
FTD 1,2,3 Clustered Ok
Firepower /ssa # delete logical-device FTD ftd
Firepower /ssa* # show app-instance
Application Name Slot ID
Version Cluster Oper State
Admin State Operational State Running Version Startup
-------------------- ----------- --------------- -------------------- ---------------
--------------- ------------------
1 Disabled Stopping 6.0.0.837
ftd
6.0.0.837
ftd
Not Applicable
2 Disabled Offline 6.0.0.837
6.0.0.837
ftd
Not Applicable
6.0.0.837
Not Applicable
Firepower /ssa* # scope slot 1
3 Disabled
Firepower /ssa/slot # delete app-instance ftd
Firepower /ssa/slot* # exit
Firepower /ssa* # scope slot 2
Firepower /ssa/slot # delete app-instance ftd
Firepower /ssa/slot* # exit
Firepower /ssa* # scope slot 3
Firepower /ssa/slot # delete app-instance ftd
Firepower /ssa/slot* # exit
Firepower /ssa* # commit-buffer
Not Available
Delete an Application Instance that is not Associated with a Logical Device
When you delete a logical device, you are prompted as to whether you want to also delete the application configuration for the logical device. If you do not delete the application configuration, you will not be able to create a logical device using a different application until that application instance is deleted. You can use the following procedure to delete an application instance from a security module/engine when it is no longer associated with a logical device.
Procedure
Step 1
Enter security services mode:
Firepower# scope ssa
Step 2
View details for the installed applications:
Firepower /ssa # show app-instance
Step 3
For each application that you want to delete, enter the following commands: a) Firepower /ssa # scope slot slot_number b) Firepower /ssa/slot # delete app-instance application_name
188
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Change an Interface on a Firepower Threat Defense Logical Device
c) Firepower /ssa/slot # exit
Step 4
Commit the configuration:
commit-buffer
Commits the transaction to the system configuration.
Example
Firepower# scope ssa
Firepower /ssa* # show app-instance
Application Name Slot ID Admin State Operational State Running Version Startup
Version Cluster Oper State
-------------------- ----------- --------------- -------------------- ---------------
--------------- -----------------ftd
6.0.0.837
Not Applicable
1 Disabled ftd
6.0.0.837
Not Applicable
2 Disabled ftd
6.0.0.837
Not Applicable
Firepower /ssa* # scope slot 1
3 Disabled
Firepower /ssa/slot # delete app-instance ftd
Firepower /ssa/slot* # exit
Firepower /ssa* # scope slot 2
Firepower /ssa/slot # delete app-instance ftd
Firepower /ssa/slot* # exit
Firepower /ssa* # scope slot 3
Firepower /ssa/slot # delete app-instance ftd
Firepower /ssa/slot* # exit
Firepower /ssa* # commit-buffer
Stopping
Offline
Not Available
6.0.0.837
6.0.0.837
Change an Interface on a Firepower Threat Defense Logical Device
You can allocate or unallocate an interface on a Firepower Threat Defense logical device. You can then sync the interface configuration in the Firepower Management Center.
Before You Begin
• Configure your interfaces, and add any EtherChannels according to
Edit Interface Properties, on page
143 and
Create a Port Channel, on page 144
.
• You can edit the membership of an allocated EtherChannel without affecting the logical device or requiring a sync on the Firepower Management Center.
• 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 firepower eventing interface, you must use the Firepower
Chassis Manager; the CLI does not support this change.
• For clustering or High Availability, make sure you add or remove the interface on all units before you sync the configuration in the Firepower Management Center. Note that new interfaces are added in an administratively down state, so they do not affect interface monitoring.
Cisco FXOS CLI Configuration Guide, 2.2(1)
189
Logical Devices
Change an Interface on an ASA Logical Device
Procedure
Step 1
Enter security services mode:
Firepower# scope ssa
Step 2
Edit the logical device:
Firepower /ssa # scope logical-device device_name
Step 3
Unallocate an interface from the logical device:
Firepower /ssa/logical-device # delete external-port-link name
Enter the show external-port-link command to view interface names.
Step 4
Allocate a new interface to the logical device:
Firepower /ssa/logical-device* # create external-port-link name interface_id ftd
Step 5
Commit the configuration:
commit-buffer
Commits the transaction to the system configuration.
Step 6
Log into the Firepower Management Center.
Step 7
Select Devices > Device Management and click the edit icon ( ) for your Firepower Threat Defense device.
The Interfaces tab is selected by default.
Step 8
Click the Sync Interfaces from device button on the top left of the Interfaces tab.
Step 9
Click Save.
You can now click Deploy and deploy the policy to assigned devices. The changes are not active until you deploy them.
Change an Interface on an ASA Logical Device
You can allocate, unallocate, or replace a management interface on an ASA logical device. ASDM discovers the new interfaces automatically.
Before You Begin
• Configure your interfaces and add any EtherChannels according to
Edit Interface Properties, on page
143 and
Create a Port Channel, on page 144
.
• You can edit the membership of an allocated EtherChannel without affecting the logical device.
• 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.
• For clustering or failover, new interfaces are added in an administratively down state, so they do not affect interface monitoring.
190
Cisco FXOS CLI Configuration Guide, 2.2(1)
Logical Devices
Change an Interface on an ASA Logical Device
Procedure
Step 1
Enter security services mode:
Firepower# scope ssa
Step 2
Edit the logical device:
Firepower /ssa # scope logical-device device_name
Step 3
Unallocate an interface from the logical device:
Firepower /ssa/logical-device # delete external-port-link name
Enter the show external-port-link command to view interface names.
For a management interface, delete the current interface then commit your change using the commit-buffer command before you add the new management interface.
Step 4
Allocate a new interface to the logical device:
Firepower /ssa/logical-device* # create external-port-link name interface_id asa
Step 5
Commit the configuration:
commit-buffer
Commits the transaction to the system configuration.
Cisco FXOS CLI Configuration Guide, 2.2(1)
191
Change an Interface on an ASA Logical Device
Logical Devices
192
Cisco FXOS CLI Configuration Guide, 2.2(1)
C H A P T E R
12
Configuration Import/Export
•
About Configuration Import/Export, page 193
•
Exporting a Configuration File, page 194
•
Scheduling Automatic Configuration Export, page 195
•
Setting a Configuration Export Reminder, page 197
•
Importing a Configuration File, page 197
About Configuration Import/Export
You can use the configuration export feature to export an XML file containing logical device and platform configuration settings for your FXOS chassis to a remote server. You can later import that configuration file to quickly apply the configuration settings to your FXOS chassis to return to a known good configuration or to recover from a system failure.
Guidelines and Restrictions
• Do not modify the contents of the configuration file. If a configuration file is modified, configuration import using that file might fail.
• Application-specific configuration settings are not contained in the configuration file. You must use the configuration backup tools provided by the application to manage application-specific settings and configurations.
• When you import a configuration to the FXOS chassis, all existing configuration on the FXOS chassis
(including any logical devices) will be deleted and completely replaced by the configuration contained in the import file.
• We recommend that you only import a configuration file to the same FXOS chassis from which the configuration was exported.
• The platform software version of the FXOS chassis to which you are importing should be the same version as when the export was taken. If not, the import operation is not guaranteed to be successful.
We recommend that you export a backup configuration whenever the FXOS chassis is upgraded or downgraded.
Cisco FXOS CLI Configuration Guide, 2.2(1)
193
Configuration Import/Export
Exporting a Configuration File
• The FXOS chassis to which you are importing must have the same Network Modules installed in the same slots as when the export was taken.
• The FXOS chassis to which you are importing must have the correct software application images installed for any logical devices defined in the export file that your are importing.
• If the configuration file being imported contains a logical device whose application has an End-User
License Agreement (EULA), the EULA for that application must be accepted on the FXOS chassis before importing the configuration or the operation will fail.
• To avoid overwriting existing backup files, please be sure to change the filename in the backup operation or copy the existing file to another location.
Exporting a Configuration File
Use the configuration export feature to export an XML file containing logical device and platform configuration settings for your FXOS chassis to a remote server.
Please review the
About Configuration Import/Export
for important information about using the configuration export feature.
Procedure
Step 1
To export a configuration file to a remote server:
scope system
export-config URL enabled commit-buffer
Specify the URL for the file being exported using one of the following syntax:
• ftp://username@hostname/path/image_name
• scp://username@hostname/path/image_name
• sftp://username@hostname/path/image_name
• tftp://hostname:port-num/path/image_name
Note
You must specify the full path including filename. If you do not specify a filename, a hidden file is created in the specified path.
Example:
fxos-chassis# scope system fxos-chassis /system # export-config scp://[email protected]:/export/cfg-backup.xml enabled fxos-chassis /system/export-config # commit-buffer
Step 2
To check the status of the export task:
scope system
scope export-config hostname
show fsm status
Example:
fxos-chassis# scope system fxos-chassis /system # scope export-config 192.168.1.2
fxos-chassis /system/export-config # show fsm status
194
Cisco FXOS CLI Configuration Guide, 2.2(1)
Configuration Import/Export
Scheduling Automatic Configuration Export
Hostname: 192.168.1.2
FSM 1:
Remote Result: Not Applicable
Remote Error Code: None
Remote Error Description:
Status: Nop
Previous Status: Backup Success
Timestamp: 2016-01-03T15:32:08.636
Try: 0
Progress (%): 100
Current Task:
Step 3
To view existing export tasks:
scope system show export-config
Step 4
To modify an existing export task:
scope system
scope export-config hostname
Use the following commands to modify the export task:
• {enable|disable}
• set description <description>
• set password <password>
• set port <port>
• set protocol {ftp|scp|sftp|tftp}
• set remote-file path_and_filename
• set user <user>
Step 5
To delete an export task:
scope system
delete export-config hostname
commit-buffer
Scheduling Automatic Configuration Export
Use the scheduled export feature to automatically export an XML file containing logical device and platform configuration settings for your FXOS chassis to a remote server. You can schedule the exports to be run daily, weekly, or every two weeks. The configuration export will be executed according to the schedule based on the when the scheduled export feature is enabled. So, for example, if you enable weekly scheduled export on a Wednesday at 10:00pm, the system will trigger a new export every Wednesday at 10:00pm.
Please review the
About Configuration Import/Export
for important information about using the configuration export feature.
Cisco FXOS CLI Configuration Guide, 2.2(1)
195
Configuration Import/Export
Scheduling Automatic Configuration Export
Procedure
To create a scheduled export task: a) Set the scope to export policy configuration:
scope org scope cfg-export-policy default
b) Enable the export policy:
set adminstate enable
c) Specify the protocol to use when communicating with the remote server:
set protocol {ftp|scp|sftp|tftp} d) Specify the hostname or IP address of the location where the backup file should be stored. This can be a server, storage array, local drive, or any read/write media that the FXOS chassis can access through the network.
If you use a hostname rather than an IP address, you must configure a DNS server.
set hostname hostname e) If you are using a non-default port, specify the port number:
set port port f) Specify the username the system should use to log in to the remote server. This field does not apply if the protocol is TFTP:
set user username g) Specify the password for the remote server username. This field does not apply if the protocol is TFTP:
set password password h) Specify the full path to where you want the configuration file exported including the filename. If you omit the filename, the export procedure assigns a name to the file:
set remote-file path_and_filename i) Specify the schedule on which you would like to have the configuration automatically exported. This can be one of the following: Daily, Weekly, or BiWeekly:
set schedule {daily|weekly|bi-weekly} j) Commit the transaction to the system configuration:
commit-buffer
Example:
fxos-chassis# scope org fxos-chassis /org # scope cfg-export-policy default fxos-chassis /org/cfg-export-policy # set adminstate enable fxos-chassis /org/cfg-export-policy* # set protocol scp fxos-chassis /org/cfg-export-policy* # set hostname 192.168.1.2
fxos-chassis /org/cfg-export-policy* # set remote-file /export/cfg-backup.xml
fxos-chassis /org/cfg-export-policy* # set user user1 fxos-chassis /org/cfg-export-policy* # set password
Password: fxos-chassis /org/cfg-export-policy* # set schedule weekly fxos-chassis /org/cfg-export-policy* # commit-buffer fxos-chassis /org/cfg-export-policy # fxos-chassis /org/cfg-export-policy # show detail
Config Export policy:
Name: default
Description: Configuration Export Policy
196
Cisco FXOS CLI Configuration Guide, 2.2(1)
Configuration Import/Export
Setting a Configuration Export Reminder
Admin State: Enable
Protocol: Scp
Hostname: 192.168.1.2
User: user1
Remote File: /export/cfg-backup.xml
Schedule: Weekly
Port: Default
Current Task:
Setting a Configuration Export Reminder
Use the Export Reminder feature to have the system generate a fault when a configuration export hasn't been executed in a certain number of days.
Procedure
To create a configuration export reminder:
scope org scope cfg-export-reminder
set frequency days
set adminstate {enable|disable}
commit-buffer
Example:
fxos-chassis# scope org fxos-chassis /org # scope cfg-export-reminder fxos-chassis /org/cfg-export-reminder # set frequency 10 fxos-chassis /org/cfg-export-reminder* # set adminstate enable fxos-chassis /org/cfg-export-reminder* # commit-buffer fxos-chassis /org/cfg-export-reminder # show detail
Config Export Reminder:
Config Export Reminder (Days): 10
AdminState: Enable
Importing a Configuration File
You can use the configuration import feature to apply configuration settings that were previously exported from your FXOS chassis. This feature allows you to return to a known good configuration or to recover from a system failure. Please review the
About Configuration Import/Export
for important information about using the configuration import feature.
Procedure
Step 1
To import a configuration file from a remote server:
scope system
import-config URL enabled
commit-buffer
Specify the URL for the file being imported using one of the following syntax:
Cisco FXOS CLI Configuration Guide, 2.2(1)
197
Configuration Import/Export
Importing a Configuration File
• ftp://username@hostname/path/image_name
• scp://username@hostname/path/image_name
• sftp://username@hostname/path/image_name
• tftp://hostname:port-num/path/image_name
Example:
fxos-chassis# scope system fxos-chassis /system # import-config scp://[email protected]:/import/cfg-backup.xml enabled
Warning: After configuration import any changes on the breakout port configuration will cause the system to reboot fxos-chassis /system/import-config # commit-buffer
Step 2
To check the status of the import task:
scope system
scope import-config hostname
show fsm status
Example:
fxos-chassis# scope system fxos-chassis /system # scope import-config 192.168.1.2
fxos-chassis /system/import-config # show fsm status
Hostname: 192.168.1.2
FSM 1:
Remote Result: Not Applicable
Remote Error Code: None
Remote Error Description:
Status: Import Wait For Switch
Previous Status: Import Config Breakout
Timestamp: 2016-01-03T15:45:03.963
Try: 0
Progress (%): 97
Current Task: updating breakout port configuration(FSM-STAGE:sam:dme:
MgmtImporterImport:configBreakout)
Step 3
To view existing import tasks:
scope system show import-config
Step 4
To modify an existing import task:
scope system
scope import-config hostname
Use the following commands to modify the import task:
• {enable|disable}
• set description <description>
• set password <password>
• set port <port>
• set protocol {ftp|scp|sftp|tftp}
• set remote-file path_and_filename
198
Cisco FXOS CLI Configuration Guide, 2.2(1)
Configuration Import/Export
• set user <user>
Step 5
To delete an import task:
scope system
delete import-config hostname
commit-buffer
Importing a Configuration File
Cisco FXOS CLI Configuration Guide, 2.2(1)
199
Importing a Configuration File
Configuration Import/Export
200
Cisco FXOS CLI Configuration Guide, 2.2(1)
C H A P T E R
13
Packet Capture
•
About Packet Capture, page 201
•
Creating or Editing a Packet Capture Session, page 202
•
Configuring Filters for Packet Capture, page 204
•
Starting and Stopping a Packet Capture Session, page 205
•
Downloading a Packet Capture File, page 206
•
Deleting Packet Capture Sessions, page 206
About Packet Capture
The Packet Capture tool is a valuable asset for use in debugging connectivity and configuration issues and for understanding traffic flows through your FXOS chassis. You can use the Packet Capture tool to log traffic that is going through specific customer-facing ports or application ports on your FXOS chassis.
You can create multiple packet capture sessions and each session can capture traffic on multiple ports. For each port included in a packet capture session, a separate packet capture (PCAP) file will be created.
Backplane Port Mappings
The FXOS chassis uses the following mappings for internal backplane ports:
Security Module
Security Module 1/Security Engine
Port Mapping
Ethernet1/9
Description
Internal-Data0/0
Security Module 1/Security Engine
Security Module 2
Ethernet1/10
Ethernet1/11
Internal-Data0/1
Internal-Data0/0
Security Module 2
Security Module 3
Security Module 3
Ethernet1/12
Ethernet1/13
Ethernet1/14
Internal-Data0/1
Internal-Data0/0
Internal-Data0/1
Cisco FXOS CLI Configuration Guide, 2.2(1)
201
Packet Capture
Creating or Editing a Packet Capture Session
Guidelines and Limitations
The Packet Capture tool has the following limitations:
• Can capture only up to 100 Mbps.
• Packet capture sessions can be created even when there is not enough storage space available to run the packet capture session. You should verify that you have enough storage space available before you start a packet capture session.
• Does not support multiple active packet capturing sessions.
• Captures only at Ingress stage of internal switch.
• Filters are not effective on packets which cannot be understood by internal switch (for example Security
Group Tag and Network Service Header packets).
• Abstractions are not supported (for example, port channels and service chain).
Note
Although capturing traffic on port channels is not supported, you can include the individual member ports that make up a port channel in a packet capture session and the packet capture tool will create separate packet capture files for each of those member ports.
• You cannot copy or export a PCAP file while the capture session is still active.
• When you delete a packet capture session, all packet capture files associated with that session are also deleted.
Creating or Editing a Packet Capture Session
Procedure
Step 1
Enter packet capture mode: fxos-chassis # scope packet-capture
Step 2
To create a new packet capture session: fxos-chassis /packet-capture # create session session_name
To edit an existing packet capture session: fxos-chassis /packet-capture # enter session session_name
Step 3
Specify the buffer size to use for this packet capture session: fxos-chassis /packet-capture/session # set session-memory-usage session_size_in_megabytes
The specified buffer size must be between 1 and 2048 MB.
Step 4
Specify the length of the packet that you want to capture for this packet capture session: fxos-chassis /packet-capture/session # set session-pcap-snaplength session_snap_length_in_bytes
202
Cisco FXOS CLI Configuration Guide, 2.2(1)
Packet Capture
Creating or Editing a Packet Capture Session
The specified snap length must be between 64 and 9006 bytes. If you do not configure the session snap length, the default capture length is 1518 bytes.
Step 5
Specify the ports that should be included in this packet capture session. You can capture from multiple ports and can capture from both customer-facing and application ports during the same packet capture session. A separate packet capture file is created for each port included in the session.
Note
To remove a port from the packet capture session, use delete instead of create in the commands listed below.
a) To add a customer-facing port: fxos-chassis /packet-capture/session* # create {phy-port | phy-aggr-port} port_name
For phy-port, the port_name syntax is Ethernet<slot_id>/<port_id> or Port-Channel<number>. For breakout cables (phy-aggr-port), the port_name syntax is
Ethernet<slot_id>/<port_id>/<breakout_port_id>.
b) To add an application port: fxos-chassis /packet-capture/session* # create app_port security_module_slot_id link_name interface_name
app_name
c) Repeat the steps above as needed to add all desired ports.
Step 6
To filter the traffic being captured:
You can apply filters to any of the interfaces included in a packet capture session. For instructions on creating a filter, see
Configuring Filters for Packet Capture, on page 204
.
a) Enter the scope for the interface to which you want to apply the filter.
fxos-chassis /packet-capture/session* # scope {phy-port | phy-aggr-port} port_name
scope phy-port Ethernet<slot_id>/<port_id> or
scope phy-aggr-port Ethernet<slot_id>/<port_id>/<breakout_port_id> or
scope <security_module_slot_id> <link_name> <interface_name> <app_name> b) Apply the desired filter: fxos-chassis /packet-capture/session/{phy-port|phy-aggr-port|app-port}* # set {source-filter} filtername
Note
To remove a filter from a port, use set source-filter
"".
c) To apply additional filters, repeat the steps above as needed.
Step 7
If you want to start the packet capture session now: fxos-chassis /packet-capture/session* # enable
Newly created packet-capture sessions are disabled by default. Explicit enabling of a session activates the packet capture session when the changes are committed. If another session is already active, enabling a session will generate an error. You must disable the already active packet-capture session before you can enable this session.
Step 8
Commit the transaction to the system configuration: fxos-chassis /packet-capture/session* # commit-buffer
If you enabled the packet capture session, the system will begin capturing packets. You will need to stop capturing before you can download the PCAP files from your session.
fxos-chassis#
scope packet-capture
fxos-chassis packet-capture #
create session asa1inside
Cisco FXOS CLI Configuration Guide, 2.2(1)
203
Packet Capture
Configuring Filters for Packet Capture
fxos-chassis packet-capture/session #
set session-memory-usage 256
fxos-chassis packet-capture/session* #
create phy-port Ethernet3/1
fxos-chassis packet-capture/session* #
create phy-aggr-port Ethernet2/1/1
fxos-chassis packet-capture/session* #
create app-port 1 link1 Ethernet 1/1 asa
fxos-chassis packet-capture/session* #
create filter interface1vlan100
fxos-chassis packet-capture/filter* #
set ivlan 100
fxos-chassis packet-capture/filter* #
set srcIP 6.6.6.6
fxos-chassis packet-capture/filter* #
set srcPort 80
fxos-chassis packet-capture/filter* #
set destIP 10.10.10.10
fxos-chassis packet-capture/filter* #
set destPort 5050
fxos-chassis packet-capture/filter* #
exit
fxos-chassis packet-capture/session* #
scope phy-port Ethernet3/1
fxos-chassis packet-capture/session/phy-port* #
set src-filter interface1vlan100
fxos-chassis packet-capture/session/phy-port* #
exit
fxos-chassis packet-capture/session* #
scope app-port 1 link1 Ethernet1/1 asa
fxos-chassis packet-capture/session/app-port* #
set src-filter interface1vlan100
fxos-chassis packet-capture/session/app-port* #
exit
fxos-chassis packet-capture/session* #
enable
fxos-chassis packet-capture/session* #
commit-buffer
fxos-chassis packet-capture/session #
Configuring Filters for Packet Capture
You can create filters to limit the traffic that is included in a packet capture session. You can select which interfaces should use a specific filter while creating a packet capture session.
Note
If you modify or delete a filter that is applied to a packet capture session that is currently running, the changes will not take affect until you disable that session and then reenable it.
Procedure
Step 1
Enter packet capture mode: fxos-chassis # scope packet-capture
Step 2
To create a new packet capture filter: fxos-chassis /packet-capture # create filter filter_name
To edit an existing packet capture filter: fxos-chassis /packet-capture # enter filter filter_name
To delete an existing packet capture filter: fxos-chassis /packet-capture # delete filter filter_name
Step 3
Specify the filter details by setting one or more filter properties: fxos-chassis /packet-capture/filter* # set <filterprop filterprop_value
Note
You can filter using IPv4 or IPv6 addresses, but you cannot filter on both in the same packet capture session.
Table 9: Supported Filter Properties
ivlan ovlan
Inner VLAN ID (vlan of packet while ingressing port)
Outer VLAN ID (vlan added by the FXOS chassis)
204
Cisco FXOS CLI Configuration Guide, 2.2(1)
Packet Capture
Starting and Stopping a Packet Capture Session
srcip destip srcipv6 destipv6 srcport destport protocol ethertype srcmac destmac
Source IP Address (IPv4)
Destination IP Address (IPv4)
Source IP Address (IPv6)
Destination IP Address (IPv6)
Source Port Number
Destination Port Number
IP Protocol [IANA defined Protocol values in decimal format]
Ethernet Protocol type [IANA defined Ethernet
Protocol type value in decimal format. For eg: IPv4
= 2048, IPv6 = 34525, ARP = 2054, SGT = 35081]
Source Mac Address
Destination Mac Address fxos-chassis#
scope packet-capture
fxos-chassis packet-capture #
create filter interface1vlan100
fxos-chassis packet-capture/filter* #
set ivlan 100
fxos-chassis packet-capture/filter* #
set srcip 6.6.6.6
fxos-chassis packet-capture/filter* #
set srcport 80
fxos-chassis packet-capture/filter* #
set destip 10.10.10.10
fxos-chassis packet-capture/filter* #
set destport 5050
fxos-chassis packet-capture/filter* #
commit-buffer
Starting and Stopping a Packet Capture Session
Procedure
Step 1
Enter packet capture mode: fxos-chassis # scope packet-capture
Step 2
Enter the scope for the packet capture session that you want to start or stop: fxos-chassis /packet-capture # enter session session_name
Step 3
To start a packet capture session: fxos-chassis /packet-capture/session* # enable [append | overwrite]
Note
You cannot start a packet capture session while another session is running.
Cisco FXOS CLI Configuration Guide, 2.2(1)
205
Packet Capture
Downloading a Packet Capture File
While the packet capture session is running, the file size for the individual PCAP files will increase as traffic is captured. Once the Buffer Size limit is reached, the system will start dropping packets and you will see the
Drop Count field increase.
Step 4
To stop a packet capture session: fxos-chassis /packet-capture/session* # disable
Step 5
Commit the transaction to the system configuration: fxos-chassis /packet-capture/session* # commit-buffer
If you enabled the packet capture session, the PCAP files for the interfaces included in the session will start collecting traffic. If the session is configured to overwrite session data, the existing PCAP data will be erased.
If not, data will be appended to the existing file (if any).
fxos-chassis#
scope packet-capture
fxos-chassis packet-capture #
scope session asa1inside
fxos-chassis packet-capture/session #
enable append
fxos-chassis packet-capture/session* #
commit-buffer
fxos-chassis packet-capture/session #
Downloading a Packet Capture File
You can download the Packet Capture (PCAP) files from a session to your local computer so that they can be analyzed using a network packet analyzer.
PCAP files are stored into the workspace://packet-capture directory and use the following naming conventions: workspace://packet-capture/session-<id>/<session-name>-<interface-name>.pcap
Procedure
To copy a PCAP file from the FXOS chassis:
Note
You should stop the packet capture session before you download the PCAP files from that session.
a) Connect to local management: fxos-chassis # connect localmgmt b) Copy the PCAP files:
# copy pcap_file copy_destination fxos-chassis#
connect localmgmt
#
copy workspace:/packet-capture/session-1/test-ethernet-1-1-0.pcap
scp://[email protected]:/workspace/
Deleting Packet Capture Sessions
You can delete an individual packet capture session if it is not currently running or you can delete all inactive packet capture sessions.
206
Cisco FXOS CLI Configuration Guide, 2.2(1)
Packet Capture
Procedure
Step 1
Enter packet capture mode: fxos-chassis # scope packet-capture
Step 2
To delete a specific packet capture session: fxos-chassis /packet-capture # delete session session_name
Step 3
To delete all inactive packet capture sessions: fxos-chassis /packet-capture # delete-all-sessions
Step 4
Commit the transaction to the system configuration: fxos-chassis /packet-capture* # commit-buffer fxos-chassis#
scope packet-capture
fxos-chassis packet-capture #
delete session asa1inside
fxos-chassis packet-capture* #
commit-buffer
fxos-chassis packet-capture #
Deleting Packet Capture Sessions
Cisco FXOS CLI Configuration Guide, 2.2(1)
207
Deleting Packet Capture Sessions
Packet Capture
208
Cisco FXOS CLI Configuration Guide, 2.2(1)
I N D E X
A
AAA
128, 129, 132, 133, 134, 135, 136
LDAP providers
RADIUS providers
TACACS+ providers
accessing the command line interface
accounts
locally authenticated
asa
53, 148, 159, 162, 186, 187, 188
connecting to
creating a cluster
creating a clustered
creating a standalone asa logical device
deleting a logical device
deleting an application instance
exiting from connection
updating image version
asa images
about
downloading from Cisco.com
downloading to the Firepower security appliance
authentication
default
authNoPriv
authPriv
B
banner
pre-login
breakout cables
configuring
breakout ports
C
call home
configure http proxy
certificate
about
chassis
initial configuration
monitoring health
Cisco Secure Package
about
downloading from Cisco.com
downloading to the Firepower security appliance
cli, See
CLI session limits
clustering
cluster control link
redundancy
size
device-local EtherChannels, configuring on switch
management
network
member requirements
software requirements
spanning-tree portfast
upgrading software
clusters
about
creating
defaults when creating
command line interface
accessing
command modes
commands
history
communication services
HTTPS
SNMP
community, SNMP
configuration import/export
guidelines
restrictions
configuring
HTTPS
connecting to a logical device
Cisco FXOS CLI Configuration Guide, 2.2(1)
IN-1
Index
corrupted file system
recovering
creating packet capture session
CSP, See
D
date
setting manually
viewing
date and time
configuring
deleting packet capture sessions
DNS
downloading packet capture file
E
enabling
SNMP
enforcing password strength
exiting from logical device connection
export configuration
F
Firepower chassis
See also
initial configuration
See also
Firepower eXtensible OS
upgrading the platform bundle
Firepower platform bundle
about
downloading from Cisco.com
downloading to the Firepower security appliance
upgrading
verifying integrity
Firepower security appliance
overview
Firepower Threat Defense, See
firmware
upgrading
fpga
upgrading
ftd, See
FXOS chassis
monitoring health
powering off
rebooting
IN-2
Cisco FXOS CLI Configuration Guide, 2.2(1)
H
high-level task list
history, passwords
http proxy
configuring
HTTPS
118, 119, 120, 122, 123, 124, 125, 127
certificate request
changing port
configuring
creating key ring
disabling
importing certificate
regenerating key ring
trusted point
I
image version
updating
images
downloading from Cisco.com
downloading to the Firepower security appliance
managing
upgrading the Firepower eXtensible Operating System platform bundle
verifying integrity
import configuration
informs
about
initial configuration
interfaces
configuring
properties
K
key ring
117, 118, 119, 120, 122, 123, 126
about
certificate request
creating
deleting
importing certificate
regenerating
trusted point
L
LDAP
Index
LDAP providers
creating
deleting
license
registering
license authority
locally authenticated users
change interval
clearing password history
no change interval
password history count
password profile
logical devices
53, 148, 150, 159, 162, 168, 186, 187, 188
connecting to
creating a cluster
creating a standalone
deleting
deleting an application instance
exiting from connection
updating image version
M
managed objects
management IP address
changing
monitoring chassis health
N
noAuthNoPriv
NTP
adding
configuring
deleting
O
object commands
P
packet capture
creating packet capture session
deleting packet capture sessions
downloading PCAP file
filter
starting a packet capture session
stopping a packet capture session
password profile
about
change interval
clearing password history
no change interval
password history count
passwords
change interval
guidelines
history count
strength check
PCAP, See
PCAP file
downloading
pending commands
PKI
platform bundle
about
downloading from Cisco.com
downloading to the Firepower security appliance
upgrading
verifying integrity
policies
role for remote users
port channels
configuring
powering off FXOS chassis
pre-login banner
creating
deleting
modifying
profiles
password
R
RADIUS
RADIUS providers
creating
deleting
rebooting
registering a license
role policy for remote users
rommon
upgrading
RSA
S
smart call home
configure http proxy
Cisco FXOS CLI Configuration Guide, 2.2(1)
IN-3
Index
SNMP
109, 110, 112, 113, 114, 115, 116
about
community
enabling
notifications
privileges
security levels
support
traps
creating
deleting
users
creating
deleting
Version 3 security features
SNMPv3
security features
software failure
recovering
SSH
configuring
syslog
configuring local destinations
configuring local sources
configuring remote destinations
system
initial configuration
system recovery
T
TACACS+
TACACS+ providers
creating
deleting
task flow
Telnet
configuring
threat defense
connecting to
creating a cluster
creating a clustered
threat defense (continued) creating a standalone threat defense logical device
deleting a logical device
deleting an application instance
exiting from connection
threat defense images
downloading to the Firepower security appliance
time
setting manually
viewing
time zone
setting
traps
about
creating
deleting
trusted points
about
creating
deleting
U
upgrading the firmware
user accounts
password profile
users
9, 28, 29, 33, 34, 36, 37, 39, 41, 42, 44, 45, 115, 116
activating
CLI session limits
creating
deactivating
default authentication
deleting
locally authenticated
managing
naming guidelines
password guidelines
password strength check
remote, role policy
roles
SNMP
IN-4
Cisco FXOS CLI Configuration Guide, 2.2(1)
Download
Advertisement
Key features
Modular chassis-based security system
Firepower Chassis Manager
FXOS CLI
FXOS REST API
Frequently asked questions
The Cisco FXOS chassis is a next-generation platform for network and content security solutions. It is part of the Cisco Application Centric Infrastructure (ACI) Security Solution and provides an agile, open, secure platform that is built for scalability, consistent control, and simplified management.
The key features include a modular chassis-based security system, Firepower Chassis Manager, FXOS CLI, and FXOS REST API.
You can use the show environment summary command to view the overall health for the FXOS chassis. This command will display information such as total power consumption, inlet temperature, CPU temperature, power supply status, fan speed, and blade status.