What is ASP? (2024)

What is the Accelerated Security Path ?

The Accelerated Security Path (ASP) on the ASA appliance comprises of 2 components; The Fast Path and The Session Management Path. In addition to the Accelerated Security Paths there is also the Control Plane Path which is also covered below.

The Session Management Path

When a new connection reaches the ASA gateway the first packet is sent to the “Session Management Path”. This path is responsible for

* Performing the access list checks
* Performing route lookups
* Allocating NAT translations (xlates)
* Establishing sessions in the "fast path"

The Fast Path

If the connection is already established, the security appliance does not need to re-check packets and the packets are sent to the Fast Path. The Fast Path is responsible for the following tasks:

* IP checksum verification
* Session lookup
* TCP sequence number check
* NAT translations based on existing sessions
* Layer 3 and Layer 4 header adjustments

For UDP or other connectionless protocols, the security appliance creates connection state information so that it can also use the fast path.

Some established session packets must continue to go through the session management path or the control plane path. Generally packets that require HTTP packet inspection or content filtering will go through to the session management. Packets that go through the control plane path include the control packets for protocols that require Layer 7 inspection. But Data packets for protocols that require Layer 7 inspection can still go through the Fast Path.

The Control Plane Path

Some packets which require adjustments or changes to be made to the packets headers at a Layer 7 level. Or Layer 7 inspection engines which are required for dynamic port based protocols such as FTP and H.323 etc are passed to the Control Plane Path.

How do I Debug ASP Drops ?

There are 3 main ways to confirm whether your ASA appliance has dropped packets at the ASP stage. These are:

1. Viewing the ASP statistics
2. Viewing the ASA Logs
3. Running an ASP Drop packet capture

Viewing the ASP statistics

In order to view the ASP drop statistics you can run the command “sh asp drop”.

This will give you an overview view of the type of drops being encountered. But does not provided the necessary information to isolate and troubleshoot particular hosts.

You can also clear these counters using the clear asp drop command.

Viewing the ASA Logs

Via your Syslog server you will be able to view the logs showing the dropped connections. This will provide the reason along with the source and destination addresses. An example is shown below for an MSS Excedded ASP drop,

%ASA-4-419001: Dropping TCP packet from outside:192.168.9.2/80 to inside:192.168.9.30/1025, reason: MSS exceeded, MSS 460, data 1440

Running an ASP drop packet capture

This is in my opinion the most concise and efficient way of troubleshooting your ASP dropped traffic.
To enable a packet capture on all traffic for all asp-drop types use the following command :

asa-firewall# capture asp-drop type asp-drop all

To then see your buffer for the asp-drop capture run the following command. You can see from the highlighted sections the reason for the drop.

asa-firewall# sh capture asp-drop

2 packets captured
1: 15:15:00.682154 197.2.1.29.2616 > 87.200.42.101.443: S 1239395083:1239395083(0) win 65535 <mss 1260,nop,nop,sackOK> Drop-reason: (acl-drop) Flow is denied by configured rule
4: 15:15:00.750830 10.70.0.162.3812 > 168.252.3.41.15: S 3523756300:3523756300(0) win 65535 <mss 1360,nop,nop,sackOK> Drop-reason: (rpf-violated) Reverse-path verify failed

reference from https://www.fir3net.com/Firewalls/Cisco/what-is-asp-and-how-to-troubleshoot-asp-drops-on-an-asa.html

please do not forget to rate.