Cisco Security Cloud Control: Secure Firewall ASA Management

PDF

Cisco Security Cloud Control: Secure Firewall ASA Management

NetFlow secure event logging (NSEL) for ASA devices

Updated: August 31, 2026

Want to summarize with AI?

Explains NetFlow Secure Event Logging (NSEL) for ASA devices, including NSEL destinations, class maps, policy maps, macros, packet capture, and event verification.

NetFlow Secure Event Logging (NSEL) is a stateful IP flow tracking method that

provides Security Analytics and Logging with granular data that basic syslog messages from the ASA lack
exports only those records that indicate significant events in a flow, and
supports NetFlow Version 9 services on Cisco ASA devices.

Flow characteristics and implementation details

A flow is defined as a unidirectional sequence of packets with some common properties that pass through a network device. These collected flows are exported to an external device, the NetFlow collector. Network flows are highly granular; for example, flow records include details such as IP addresses, packet and byte counts, timestamps, Type of Service (ToS), application ports, input and output interfaces, etc.¹

The Cisco ASA supports NetFlow Version 9 services. The ASA implementation of NSEL provides a stateful, IP flow tracking method that exports only those records that indicate significant events in a flow. In stateful flow tracking, tracked flows go through a series of state changes.

This documentation describes a straight forward approach to configuring NetFlow for your ASAs using a Security Cloud Control macro. The Cisco ASA NetFlow Implementation Guide provides an extremely detailed discussion of configuring NetFlow on the ASA and you may find it a valuable resource to accompany this content.

What to do Next

Go to Configuring NSEL for ASA Devices Using a Security Cloud Control Macro.

Related Articles

1. ("Cisco Systems NetFlow Services Export Version 9." Internet Engineering Task Force, Network Working Group, Request for Comments: 3954, October 2004, B. Claise, Ed. https://www.ietf.org/rfc/rfc3954.txt)

Configuring NSEL for ASA devices by using a CDO macro

ASAs report detailed connection event data using Netflow Secure Event Logging (NSEL). You can apply Secure Cloud Analytics to this connection event data, which includes bidirectional flow statistics. This procedure describes how to configure NSEL on an ASA device and send those NSEL events to a flow collector. In this case, the flow collector is a Secure Event Connector (SEC).

Summary

The key components involved in configuring NSEL for ASA devices are:

ASA device: Reports detailed connection event data using NSEL
Secure Event Connector (SEC): Acts as the flow collector that receives NSEL events
CDO macro: Automates the configuration process for NSEL settings
Flow-export destination: Defines where NSEL events are sent
Class-map: Defines which NSEL events will be sent to the SEC
Policy-map: Applies the flow-export configuration to specific traffic classes

Workflow

These are the stages of configuring NSEL for ASA devices by using a Security Cloud Control macro:

Before beginning the configuration process, gather the required information including the IPv4 address of the SEC, the ASA interface, the UDP port number, and the global policy name.
- IPv4 address of the SEC that will receive data from the ASA
- Interface on the ASA that will send data to the SEC
- UDP port number used to forward NetFlow events. See Finding your device's TCP, UDP, and NSEL port used for secure logging analytics (SaaS).
- Determine the name of an ASA global policy

Execute the configuration workflow by following each step in sequence to properly configure NSEL using the CDO macro.

This procedure refers to this macro, Configure NSEL:

 flow-export destination {{interface}} {{SEC_IPv4_address}} {{SEC_NetFlow_port}}
flow-export template timeout-rate {{timeout_rate_in_mins}}
flow-export delay flow-create {{delay_flow_create_rate_in_secs}}
flow-export active refresh-interval {{refresh_interval_in_mins}}
class-map {{flow_export_class_name}}
     match {{add_this_traffic_to_class_map}}
policy-map {{global_policy_map_name}}
     class {{flow_export_class_name}}
          flow-export event-type {{event_type}} destination {{SEC_IPv4_address}}
service-policy {{global_policy_map_name}} global
logging flow-export-syslogs disable
show run flow-export
show run policy-map {{global_policy_map_name}}
show run class-map {{flow_export_class_name}}

Here is an example of the Configure NSEL macro with all the default values filled in, a generic name for the class-map, and the class map added to the global_policy, When you are done with these procedures, your macro will resemble this:

 flow-export destination {{interface}} {{SEC_IPv4_address}} {{SEC_NetFlow_port}}
flow-export template timeout-rate 60
flow-export delay flow-create 55
flow-export active refresh-interval 1
class-map flow_export_class_map
     match any
policy-map global_policy
     class flow_export_class_map
          flow-export event-type all destination {{SEC_IPv4_address}}
logging flow-export-syslogs disable
show run flow-export
show run policy-map global_policy
show run class-map flow_export_class_map

Open the configuring NSEL macro

This task allows you to access the Configuring NSEL macro to configure NetFlow Secure Event Logging on ASA devices.

This is the first part in a longer workflow for configuring NSEL on ASA devices using CDO macros.

Before you begin

This is first part in a longer workflow, see Configuring NSEL for ASA devices by using a CDO macro before getting started.

Follow these steps to open the Configuring NSEL macro:

Procedure

	1.	On the Security Devices page, click the Devices tab.
	2.	Click the appropriate device type tab and select the ASA(s) on which you want to configure NetFlow Secure Event Logging (NSEL).
	3.	In the Device Actions pane, click Command Line Interface.
	4.	Click the Macro star to show the list of available macros.
	5.	From the list of macros, select Configuring NSEL.
	6.	Under the Macro box, click View Parameters. Continue to Define the destination of NSEL messages and the interval at which they are sent to the SEC.

The Configuring NSEL macro parameters are displayed, allowing you to proceed with configuring NSEL settings for the selected ASA devices.

Define the destination of NSEL messages and the interval at which they are sent to the SEC

This task configures the destination SEC collector and timing intervals for NSEL message transmission from ASA devices.

NSEL messages can be sent to any one of the SECs you have onboarded to your tenant. These instructions refer to this section of the macro:

flow-export destination {{interface}} {{SEC_IPv4_address}} {{SEC_NetFlow_port}}

flow-export template timeout-rate {{timeout_rate_in_mins}}

flow-export delay flow-create {{delay_flow_create_rate_in_secs}}

flow-export active refresh-interval {{refresh_interval_in_mins}}

Before you begin

This is part of a larger workflow. See Configuring NSEL for ASA devices by using a CDO macro before getting started.

Procedure

	1.	The flow-export destination command defines the collector to which the NetFlow packets are sent. In this case, you are sending them to an SEC. Fill in the fields for these parameters: {{interface}}-Enter the name of the interface on the ASA from which the NetFlow events are sent. {{SEC_IPv4_address}}-Enter the IPv4 address of the SEC. The SEC functions as the flow collector. {{SEC_NetFlow_port}}-Enter the UDP port number on the SEC to which NetFlow packets are sent.
	2.	The flow-export template timeout-rate command specifies the interval at which template records are sent to all configured output destinations. {{timeout_rate_in_mins}}-Enter the number of minutes before templates are resent. We recommend using a value of 60 minutes. The SEC does not process the templates. A large number reduces traffic to the SEC.
	3.	The flow-export delay flow-create command delays the sending of flow-create events by the specified number of seconds. This value matches the recommended Active Timeout value and reduces the number of flow events exported from the ASA. At that rate, expect NSEL events to first appear in Security Cloud Control at the close of a connection or within 55 seconds of the creation of the connection, whichever happens earlier. If this command is not configured, there is no delay, and the flow-create event is exported as soon as the flow is created. {{delay_flow_create_rate_in_secs}}-Enter the number of seconds delay between sending flow-create events. We recommend using a value of 55 seconds.
	4.	The flow-export active refresh-interval command defines the frequency that status updates for long-lived flows will be sent from ASA. Valid values are from 1-60 minutes. In the Flow Update Interval field, configuring the flow-export active refresh-interval to be at least 5 seconds more than the flow-export delay flow-create interval prevents flow-update events from appearing before flow-creation events. {{refresh_interval_in_mins}}-We recommend using a value of 1 minute. Valid values are from 1-60 minutes. Continue to Create a Class-Map that defines which NSEL events will be sent to the SEC

The NSEL message destination and timing parameters are configured for transmission to the specified SEC collector.

Create a Class-Map that defines which NSEL events will be sent to the SEC

Create a class-map that identifies NSEL traffic for export to the SEC and define the matching criteria for traffic classification.

The following commands in the macro group all NSEL events in a class and then export that class to the Secure Event Connector (SEC). These instructions refer to this section of the macro:

class-map {{flow_export_class_name}}

match {{add_this_traffic_to_class_map}}

Before you begin

This is part of a larger workflow. See Configuring NSEL for ASA devices by using a CDO macro before getting started.

Procedure

	1.	The class-map command names the class map that identifies NSEL traffic that will be exported to the SEC. {{flow-export-class-name}}-Enter a name for your class map. The name may be up to 40 characters in length. The names "class-default" and any name that begins with "_internal" or "_default" are reserved. All types of class maps use the same name space, so you cannot re-use a name already used by another type of class map.
	2.	Identify the traffic that is going to be associated with (matched with) your class-map. Choose one of these options for the value of {{add_this_traffic_to_class_map}}: Enter any in the {{add_this_traffic_to_class_map}} field. This monitors all traffic types for NSEL traffic. We recommend using the value "any". Enter access-list name-of-access-list in the {{add_this_traffic_to_class_map}} field. This associates all the traffic associated with an access-list that you have created. See Configure Flow-Export Actions Through Modular Policy Framework in the Cisco ASA NetFlow Implementation Guide for more information. Continue to Define a Policy-Map for NSEL events.

You have created a class-map that defines which NSEL events will be sent to the SEC and specified the traffic matching criteria.

Define a Policy-Map for NSEL events

Create a policy-map that assigns NetFlow export actions to the class and associates the class with a new policy map for managing NSEL events.

This task assigns NetFlow export actions to the class you created in the previous task, and the class to a new policy map. These instructions refer to this section of the macro:

policy-map {{global_policy_map_name}}

class {{flow_export_class_name}}

flow-export event-type {{event_type}} destination {{SEC_IPv4_address}}

Before you begin

This is part of a larger workflow. See Configuring NSEL for ASA devices by using a CDO macro before getting started.

Procedure

	1.	The policy-map command creates a policy-map. In the next task, you associate this policy map with the global policy. {{global_policy_map_name}}-Enter a name for the policy map. We recommend using the name of the firewall's existing global policy if there is one. The default name for the global policy is global_policy. See Determine the Name of an ASA Global Policy. If you create a new policy map and apply it globally according to Configure Flow-Export Actions Through Modular Policy Framework in Cisco ASA NetFlow Implementation Guide, the remaining inspection policies are deactivated.
	2.	The class command inherits the name of the class-map you created in Create a Class-Map that defines which NSEL events will be sent to the SEC.
	3.	The flow-export event-type {{event-type}} destination {{IPv4_address}} command defines which event types should be sent to flow collector, (in this case the SEC). {{event-type}}-The event_type keyword is the name of the supported event being filtered. We recommend using the value "all". {{SEC_IPv4_address}}-This is the IPv4 address of the SEC. Its value is inherited from the value you entered in Define the destination of NSEL messages and the interval at which they are sent to the SEC. Continue to Recommendation: disable redundant syslog messages when using NetFlow.

The policy-map is created with NetFlow export actions assigned to the specified class for managing NSEL events.

Recommendation: disable redundant syslog messages when using NetFlow

When NetFlow is enabled to export flow information, disable redundant syslog messages for improved performance. The same information is exported through NetFlow, making these syslog messages unnecessary.

Enabling NetFlow to export flow information makes certain syslog messages redundant because the same information is exported through NetFlow. Disabling these messages improves performance.

The macro includes the command logging flow-export-syslogs disable to disable redundant syslog messages. You do not need to modify this command.

If you do not want to disable redundant syslog messages, you can edit this macro and delete only this line from it:

logging flow-export-syslogs disable

You can later enable or disable individual syslog messages by following the procedure in the Disabling and Reenabling NetFlow-related Syslog Messages.

Note

When NSEL and syslog messages are both enabled, there is no guarantee of chronological ordering between the two logging types.


Syslog Message	Description	NSEL Event ID	NSEL Extended Event ID
106100	Generated whenever an access control rule (ACL) is encountered.	1-Flow was created (if the ACL allowed the flow). 3-Flow was denied (if the ACL denied the flow).	0-If the ACL allowed the flow. 1001-Flow was denied by the ingress ACL. 1002-Flow was denied by the egress ACL.
106015	A TCP flow was denied because the first packet was not a SYN packet.	3-Flow was denied.	1004-Flow was denied because the first packet was not a TCP SYN packet.
106023	When a flow was denied by an ACL attached to an interface through the access-group command.	3-Flow was denied.	1001-Flow was denied by the ingress ACL. 1002-Flow was denied by the egress ACL.
302013, 302015, 302017, 302020	TCP, UDP, GRE, and ICMP connection creation.	1-Flow was created.	0-Ignore.
302014, 302016, 302018, 302021	TCP, UDP, GRE, and ICMP connection teardown.	2-Flow was deleted.	0-Ignore. > 2000-Flow was torn down.
313001	An ICMP packet to the device was denied.	3-Flow was denied.	1003-To-the-box flow was denied because of configuration.
313008	An ICMP v6 packet to the device was denied.	3-Flow was denied.	1003-To-the-box flow was denied because of configuration.
710003	An attempt to connect to the device interface was denied.	3-Flow was denied.	1003-To-the-box flow was denied because of configuration.

Review and send the macro

Review and send macro commands to the ASA device to complete the NSEL configuration workflow.

This task is performed after filling in the macro fields as part of configuring NSEL for ASA devices using a CDO macro.

Before you begin

This is part of a larger workflow. See Configuring NSEL for ASA devices by using a CDO macro, before getting started.

Follow these steps to review and send the macro:

Procedure

	1.	After filling in the fields of the macro, click Review to review the commands before they are sent to the ASA.
	2.	If you are satisfied with your responses to the commands, click Send.
	3.	After you send the command, you may see the message, "Some commands may have made changes to the running config" along with two links. Clicking Write to Disk saves the changes made by this command, and any other changes in the running-configuration, to the device's startup configuration. Clicking Dismiss dismisses the message.

You have finished the workflow described in Configuring NSEL for ASA devices by using a CDO macro.

DELETE NetFlow secure event logging (NSEL) configuration from an ASA

This task removes the NetFlow Secure Event Logging (NSEL) configuration from an ASA device, which reverses the configuration that specifies the Secure Event Connector (SEC) as the NSEL flow collector.

This procedure reverses the macro described in Configuring NSEL for ASA Devices Using a Security Cloud Control Macro.

Procedure

Use the DELETE NSEL macro to remove the NetFlow configuration.

Example:

policy-map {{flow_export_policy_name}} 
no class {{flow_export_class_name}} 
no class-map {{flow_export_class_name}} 
no flow-export destination {{interface}} {{IPv4_address}} {{NetFlow_port}} 
no flow-export template timeout-rate {{timeout_rate_in_mins}} 
no flow-export delay flow-create {{delay_flow_create_rate_in_secs}} 
no flow-export active refresh-interval {{refresh_interval_in_mins}} 
logging flow-export-syslogs enable 
show run flow-export 
show run policy-map {{flow_export_policy_name}} 
show run class-map {{flow_export_class_name}}

The NetFlow Secure Event Logging (NSEL) configuration is removed from the ASA device.

Open the DELETE-NSEL macro

This task enables you to access and prepare the DELETE-NSEL macro for removing NetFlow Secure Event Logging (NSEL) configuration from ASA devices.

Use this task when you need to DELETE the NetFlow Secure Event Logging configuration from one or more ASA devices using the command line interface and macro functionality.

Procedure

	1.	On the Security Devices page, click the Devices tab.
	2.	Click the appropriate device type tab and select the ASA(s) on which you want to DELETE the configuration of NetFlow Secure Event Logging (NSEL).
	3.	In the Device Actions pane, click Command Line Interface.
	4.	Click the Macros star to show the list of available macros.
	5.	In the list of macros, select DELETE-NSEL.
	6.	Under the Macro box, click View Parameters.

The DELETE-NSEL macro is now open and ready for parameter configuration before execution.

Enter the values in the macro to complete the no commands

Remove NetFlow policy-map configurations by completing the "no" form of commands with appropriate macro values.

The ASA CLI uses the "no" form of a command to delete it. Fill in the fields in the macro to complete the "no" form of the command:

Procedure

	1.	policy-map {{flow_export_policy_name}} {{flow_export_policy_name}}-Enter the value of the policy-map name.
	2.	no class {{flow_export_class_name}} {{flow_export_class_name}}-Enter the value of the class-map name.
	3.	no class-map {{flow_export_class_name}} {{flow_export_class_name}}-The value of the class-map name is inherited from the step above.
	4.	no flow-export destination {{interface}} {{IPv4_address}} {{NetFlow_port}} {{interface}}-Enter the name of the interface on the ASA from which the NetFlow events were sent. {{IPv4_address}}-Enter the IPv4 address of the SEC. The SEC functions as the flow collector. {{NetFlow_port}}-Enter the UDP port number on the SEC to which NetFlow packets were sent.
	5.	no flow-export template timeout-rate {{timeout_rate_in_mins}} {{timeout_rate_in_mins}}-Enter the flow-export template timeout-rate.
	6.	no flow-export delay flow-create {{delay_flow_create_rate_in_secs}} {{delay_flow_create_rate_in_secs}}-Enter the flow-export delay flow-create rate.
	7.	no flow-export active refresh-interval {{refresh_interval_in_mins}} {{refresh_interval_in_mins}}-Enter the flow-export active refresh-interval interval.

The NetFlow policy-map configuration is removed from the ASA device after completing all the "no" commands with the appropriate macro values.

Determine the name of an ASA global policy

This task enables you to identify the specific name assigned to an ASA's global policy configuration.

You may need to determine the name of an ASA's global policy when troubleshooting or configuring security policies on your device.

Before you begin

Follow these steps to determine the name of an ASA global policy:

Procedure

	1.	From the Security Devices page, select the device for which you want to find the name of the global policy.
	2.	In the Device Actions pane, select >_Command Reference.
	3.	In the Command Line Interface window, at the prompt, type: show running-config service-policy In the output of the example below, global_policy is the name of the global policy. Example: >show running-config service-policy service-policy global_policy global

The command output displays the global policy name in the service-policy configuration line.

Troubleshooting NSEL data flows

Troubleshooting NSEL data flows is a verification process that

verifies that NSEL events are being sent from your ASA to the Cisco Cloud
confirms that the Cisco Cloud is receiving NSEL events, and
uses flow-export counters and capture commands to diagnose data flow issues.

NSEL data flow verification requirements

Once you have configured Netflow Secure Event Logging (NSEL), data does not flow immediately. It could take a few minutes for the first NSEL packets to arrive assuming there is NSEL-related traffic being generated on the ASA.

This verification process involves these tasks:

Verify that NetFlow Packets are Being Sent to the SEC
Verify that NetFlow Packets are Being Received by the Cisco Cloud

Note

This workflow shows you a straight-forward use of the "flow-export counters" command and "capture" commands to Troubleshoot NSEL Data Flows. See "Packet Captures" CLI Book 1: Cisco ASA Series General Operations CLI Configuration Guide and "Monitoring NSEL" in the Cisco ASA NetFlow Implementation Guide for a more detailed discussion of the usage of these commands.

Verify that NSEL events are being sent to the SEC

This task verifies that NSEL events are successfully being transmitted from ASA devices to the SEC for security event monitoring.

Use one of two commands to verify that NSEL packets are being sent to the SEC:

flow-export counters
capture

Use the "flow-export counters" Command to Check for flow-export Packets Being Sent and for NSEL errors

Make sure you have configured your ASA to send NSEL events to the SEC. See Configuring NSEL for ASA Devices Using a Security Cloud Control Macro.
The SEC IP address is the flow collector address for NSEL events. If you have onboarded more than one SEC to your tenant, be sure you are using the correct IP address.
Find the UDP port number used to forward NetFlow events. See Finding Your Device's TCP, UDP, and NSEL Port Used for Cisco Security Analytics and Logging.
Our recommended interface on the ASA from which to send NSEL events is the management interface; your interface may be different.

Use the command line interface in Security Cloud Control to send these commands to the ASAs that you have configured for NSEL.

Procedure

	1.	In the navigation pane, click Security Devices.
	2.	Click the Devices tab.
	3.	Click the appropriate device tab and select the ASA you configured to send NSEL events to the SEC.
	4.	In the Device Actions pane on the right, click Command Line Interface.
	5.	Reset the flow export counters by running the clear flow-export counters command. This resets the clear export flow counters to zero so that you can easily tell if new events are coming in. example: >clear flow-export counters Done!
	6.	Run the show flow-export counters command to see the destination of the NSEL packets, how many packets were sent and any errors: example: >show flow-export counters destination: management 209.165.200.225 10425 Statistics: packets sent 25000 Errors: block allocation errors 0 invalid interface 0 template send failure 0 no route to collector 0 source port allocation 0 In the output above, the destination line shows the interface on the ASA from which NSEL events are sent, the IP address of the SEC, port 10425 of the SEC. It also shows packets sent of 25000.

Error descriptions:

block allocation errors-If you receive a block allocation error, the ASA did not allocate memory to the flow-exporter.
- Recovery action: Call Cisco Technical Assistance Center (TAC).
invalid interface-Indicates that you are trying to send NSEL events to the SEC but the interface you've defined for flow export isn't configured to do so.
- Recovery action: Review the interface you chose when configuring NSEL. We recommend using the management interface, your interface may be different.
template send failure-The template you had to define NSEL was not parsed correctly.
- Recovery action: Contact Security Cloud Control support.
no route to collector-Indicates there is no network route from the ASA to the SEC.
- Recovery actions:
  - Make sure that the IP address you used for the SEC when you configured NSEL is correct.
  - Make sure the SEC's status is Active and it has sent a recent heartbeat. See SDC is Unreachable.
  - Make sure the Secure Device Connector's status is Active and it has sent a recent heartbeat.
source port allocation-May indicate that there is a bad port on your ASA.

Use the "capture" command to capture NSEL packets sent from the ASA to the SEC

This task captures NSEL packets to verify that your ASA is successfully sending NSEL events to the SEC.

Use the command line interface in Security Cloud Control to send these commands to the ASAs that you have configured for NSEL.

Before you begin

Make sure you have configured your ASA to send NSEL events to the SEC. See Configuring NSEL for ASA Devices Using a Security Cloud Control Macro.
The SEC IP address is the flow collector address for NSEL events. If you have onboarded more than one SEC to your tenant be sure you are using the correct IP address.
Find the UDP port number used to forward NetFlow events. See Finding Your Device's TCP, UDP, and NSEL Port Used for Cisco Security Analytics and Logging.
Our recommended interface on the ASA from which to send NSEL events is the management interface; your interface may be different.

Follow these steps to capture NSEL packets sent from the ASA to the SEC:

Procedure

	1.	In the navigation pane, click Security Devices.
	2.	Click the Devices tab.
	3.	Click the appropriate device type tab and select the ASA you configured to send NSEL events to the SEC.
	4.	In the Device Actions pane on the right, click Command Line Interface.
	5.	In the command window, run this capture command: `>` capturecapture_nameinterfaceinterface_name match UDP any host IP_of_SECeqNetFlow_port Where capture_name is the name of the packet capture. interface_name is the name of the interface from which NSEL packets leave the ASA. IP_of_SEC is the IP address of the SEC VM. NetFlow_port is the port to which NSEL events are sent. This starts the packet capture.
	6.	Run the show capture command to view the captured packets: > show capturecapture_name Where capture_name is the name of the packet capture you defined in the previous step. Here is an example of the output showing the time of the capture, the IP address from which the packet was sent, the IP address, and the port the packet was sent to. In this example, 192.168.25.4 is the IP address of the SEC and port 10425 is the port on the SEC that receives NSEL events. 6 packets captured `1: 14:23:51.706308 192.168.0.169.16431 > 192.168.25.4.10425: UDP 476` `2: 14:23:53.923017 192.168.0.169.16431 > 192.168.25.4.10425: UDP 248` `3: 14:24:07.411904 192.168.0.169.16431 > 192.168.25.4.10425: UDP 1436` `4: 14:24:07.411920 192.168.0.169.16431 > 192.168.25.4.10425: UDP 1276` `5: 14:24:21.021208 192.168.0.169.16431 > 192.168.25.4.10425: UDP 112` `6: 14:24:27.444755 192.168.0.169.16431 > 192.168.25.4.10425: UDP 196`
	7.	Run the capture stop command to manually stop the packet capture: > capture capture_namestop Where capture_name is the name of the packet capture you defined in the previous step.

The packet capture shows NSEL packets being sent from the ASA to the SEC, confirming that NSEL events are successfully transmitted to the configured destination.

Check for live NSEL events

This task allows you to verify that NSEL events are being properly received and processed by the Cisco Cloud system.

Check for both live and historical events. This procedure will filter for NSEL events that the Cisco Cloud has received within the last hour.

Procedure

	1.	From the Security Cloud Control Home page, click Firewall.
	2.	In the left pane, choose Events & Logs > Events > Event Logging.
	3.	Click the Live tab.
	4.	Pin-open the event filter.
	5.	In the ASA Events section, make sure NetFlow is checked.
	6.	In the Sensor ID field, enter the IP address of the ASA you configured to send NSEL events.
	7.	At the bottom of the filter, make sure that Include NetFlow Events is checked.

The system displays live NSEL events from the specified ASA device, confirming that events are being successfully received and processed.

Check for historical NSEL events

Filter for NSEL events that the Cisco Cloud has received within a specific time-frame to verify event receipt and troubleshoot connectivity issues.

This procedure will filter for NSEL events that the Cisco Cloud has received within the time-frame you specify.

Procedure

	1.	From the Security Cloud Control Home page, click Firewall.
	2.	In the left pane, choose Events & Logs > Events > Event Logging.
	3.	Click the Historical tab.
	4.	Pin-open the event filter.
	5.	In the ASA Events section, make sure NetFlow is checked.
	6.	Set the Start time far enough back in time to check if Security Cloud Control ever did receive NSEL events.
	7.	In the Sensor ID field, enter the IP address of the ASA you configured to send NSEL events.
	8.	At the bottom of the filter, make sure that Include NetFlow events is checked.

The historical event filter displays NSEL events received from the specified ASA within your configured time-frame, confirming successful event transmission to Cisco Cloud.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.